Agent Basic / 11

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

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

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

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

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

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

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

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

Agent 系统打破了这个假设：

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

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

评估的四个维度

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

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

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

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

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

2. 效率（Efficiency）

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

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

3. 安全与合规（Safety）

Agent 有没有做不该做的事？

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

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

4. 鲁棒性（Robustness）

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

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

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

评测方法

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

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

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

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

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

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

方法 2：LLM-as-Judge

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

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

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

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

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

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

方法 3：A/B 对比

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

适合回答这类问题：

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

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

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

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

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

评测设计的实用建议

先从小测试集开始

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

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

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

注意统计显著性

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

• 同一用例至少跑 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 落地形态

参考资料

• 李博杰《深入理解 AI Agent：设计原理与工程实践》，第六章：Agent 评估，固定提交 e3883f8c。本文按本仓库基础教程定位使用独立结构和表述重新实现。