---
layout: default
title: Agent 评估：怎么知道你的 Agent 好不好
description: 从指标设计到评测方法，建立 Agent 质量的工程判断标准
eyebrow: Agent Basic / 11
---

# Agent 评估：怎么知道你的 Agent 好不好

很多人做 Agent 的流程是：搭起来 → 试几个样例 → 看着能跑 → 上线。

但“能跑”和“好用”之间的距离，远比想象中大。

如果你没有评估体系，就只能靠直觉判断系统质量。而直觉在以下场景里会失效：

- 改了 Prompt，不知道效果变好还是变差
- 换了模型，不知道要不要迁移
- 加了新工具，不知道是否引入了退化
- 系统跑了一个月，不知道质量有没有下降

这一篇解决的核心问题是：**用什么标准、什么方法来判断 Agent 的表现？**

## 为什么 Agent 评估比传统软件更难

传统软件测试的基本假设是：相同输入产生相同输出。

Agent 系统打破了这个假设：

- 模型输出有随机性
- 工具调用路径可能不同
- 同一个任务有多种“正确”完成方式
- 中间过程和最终结果都需要评估

所以 Agent 评估不能只套用单元测试的思路，需要一套更贴合实际的方法。

## 评估的四个维度

### 1. 任务完成率（Task Success Rate）

最基本的指标：Agent 是否真正完成了任务？

这里的“完成”不是指模型说“我完成了”，而是可以被外部验证的结果。例如：

- 代码生成：测试是否通过
- 信息检索：答案是否包含关键事实
- 数据处理：输出格式是否符合规范
- 工单处理：是否正确分类并执行了操作

设计这个指标的关键是：**定义明确的验收条件**，而不是人工看一眼觉得“差不多”。

### 2. 效率（Efficiency）

同样完成任务，用了多少资源？

| 指标 | 衡量什么 |
| --- | --- |
| 迭代次数 | 模型调用了几轮才完成 |
| Token 消耗 | 总输入+输出 token |
| 工具调用次数 | 是否有无效或重复调用 |
| 端到端延迟 | 用户等了多久 |
| 费用 | 一次任务花了多少钱 |

完成率相同的情况下，用 3 轮完成和用 12 轮完成，系统质量差距很大。

### 3. 安全与合规（Safety）

Agent 有没有做不该做的事？

- 是否调用了超出权限的工具
- 是否泄露了不该暴露的信息
- 是否生成了不合规的内容
- 是否在信息不足时编造了事实

这个维度在 Demo 阶段几乎不会被测试，但在生产环境中可能是最重要的。

### 4. 鲁棒性（Robustness）

面对异常输入和环境变化时，系统是否仍然可控？

- 模糊或恶意的用户输入
- 工具返回错误或超时
- 上下文极长或极短
- 中途网络中断后恢复

鲁棒性不是“永远不出错”，而是“出错时行为可预测且可恢复”。

## 评测方法

### 方法 1：固定测试集 + 自动验证

最基础的方法：准备一组有明确预期结果的测试用例，自动运行并比对。

```text
测试用例：
  输入: "帮我查询上海今天的天气"
  预期行为: 调用 get_weather 工具，参数包含 city="上海"
  预期结果: 输出包含温度数值和天气描述

执行 → 检查行为 → 检查结果 → 记录通过/失败
```

优点：可重复、可自动化、可以做回归测试。

局限：只能覆盖有限场景，不能发现“未预见”的问题。

### 方法 2：LLM-as-Judge

用另一个模型来评估 Agent 的输出质量。

```text
Prompt 给评判模型：
  "以下是一个 Agent 对用户问题的回答。
   请从准确性、完整性、相关性三个维度打分（1-5）。
   用户问题：...
   Agent 回答：..."
```

优点：可以评估开放式任务、扩展性好。

局限：评判模型本身可能有偏差、评分标准需要校准。

使用 LLM-as-Judge 时的关键原则：

- 给评判模型明确的评分标准和示例
- 多次运行取平均，减少随机性
- 定期用人工评估校准评判模型的准确性
- 不要用同一个模型既当运动员又当裁判

### 方法 3：A/B 对比

同一批任务，用两个版本的系统分别处理，比较各维度指标。

适合回答这类问题：

- 新 Prompt 比旧 Prompt 好多少？
- 换模型后质量有没有下降？
- 加了 Reflection 步骤是否值得额外成本？

### 方法 4：对抗性测试（Red Teaming）

专门设计试图让系统出错的输入：

- Prompt 注入攻击
- 边界条件和极端输入
- 误导性或矛盾的指令
- 试图让 Agent 越权的请求

这类测试不追求“正常情况下成功率多少”，而是“最差情况下系统会不会失控”。

## 评测设计的实用建议

### 先从小测试集开始

不需要一开始就搭建完整的评测平台。一个包含 20-50 个代表性用例的测试集，加上自动化运行脚本，已经比“人工试几个例子”好很多。

### 区分“能力评测”和“集成评测”

| 类型 | 测什么 | 怎么测 |
| --- | --- | --- |
| 能力评测 | 模型+Prompt 在理想条件下的表现 | 固定上下文、Mock 工具、控制变量 |
| 集成评测 | 完整系统在真实条件下的表现 | 真实工具、真实延迟、端到端运行 |

先用能力评测验证基本逻辑，再用集成评测验证生产可行性。

### 注意统计显著性

模型输出有随机性，跑一次不能说明问题。

- 同一用例至少跑 3-5 次
- 比较两个版本时，样本量要足够
- 不要因为一次成功就说“问题解决了”

### 持续监控 > 一次性评测

上线后的持续监控比上线前的一次性评测更重要。

应该持续追踪的指标：

- 任务成功率趋势
- 平均迭代次数变化
- token 消耗是否异常增长
- 用户反馈和投诉模式
- 工具调用失败率

如果这些指标突然变化，往往意味着外部依赖（模型更新、API 变更）或数据分布发生了漂移。

## 常见的评测陷阱

### 只测 happy path

如果测试集全是“完美输入”，你永远不知道系统面对异常时会怎样。至少 30% 的测试应该覆盖异常和边界场景。

### 把“模型说完成了”当成真的完成了

模型非常擅长生成“看起来正确”的输出。评估必须基于可验证的外部标准，而不是模型的自我声明。

### 忽略成本维度

一个花 10 轮完成任务的系统，和一个花 3 轮完成的系统，即使成功率相同，运营成本可能差 3 倍。评测时必须把效率纳入考量。

### 过度依赖 Benchmark

公开 Benchmark 能帮助你了解模型的通用能力，但它不能代替你自己的业务评测。因为：

- 你的任务分布和 Benchmark 不同
- 你的工具环境和 Benchmark 不同
- 你的成功标准和 Benchmark 不同

Benchmark 用来选模型和定基线，业务评测用来验证系统。

## 和 Loop Engineering 的关系

评估体系和 Loop 设计是相互支撑的：

- Loop 的退出条件需要评估结果来触发（Verification Loop 的验证器本质就是一个实时评估器）
- 评估体系的指标可以驱动 Loop 策略的调优（平均迭代次数太高 → 调整 Reflection 条件）
- 持续监控发现退化时 → 触发评测分析根因

## 小结

Agent 评估不是“上线前跑一遍测试”就结束的事，而是贯穿系统全生命周期的工程实践。

先记住最核心的四件事：

1. 定义可验证的成功标准，不要靠人工主观判断
2. 从小测试集开始，自动化执行
3. 评估不只看成功率，还要看效率、安全和鲁棒性
4. 上线后持续监控比上线前一次性评测更重要

如果你的 Agent 没有评估体系，它就只是一个“看起来能跑”的系统。有了评估体系，它才是一个“可以持续改进”的系统。

下一篇建议继续看：

- [Coding Agent：最成功的 Agent 落地形态](../12-coding-agent-patterns/index.html)

## 参考资料

- 李博杰《深入理解 AI Agent：设计原理与工程实践》，[第六章：Agent 评估](https://github.com/bojieli/ai-agent-book/blob/e3883f8cec222c31e59c646be96641120863027e/book/chapter6.md)，固定提交 `e3883f8c`。本文按本仓库基础教程定位使用独立结构和表述重新实现。