Agent Eval的重要性与构建

anthropic：Demystifying evals for AI agents

需要Eval（评估）的原因：

Agent在多轮交互中调用工具/修改状态/根据结果自适应调整，可能会让错误传播和叠加，比如传统的LLM更难评估，如果没有eval的团队会陷入反应式调试循环：等待用户抱问题——手动复现——修bug然后祈祷没有引入新的问题

 

Eval的核心术语

Task：单个测试用例，包含输入和成功标准

Trial：对一个task的一次尝试

Grader：打分逻辑，一个task可以有多个grader

• code-base：字符串匹配、正则、fail-to-pass 测试、静态分析、结果验证；快速便宜但是死板
• model-base：参考答案对比、多judge共识；灵活可扩展能处理开放性任务 但是非确定性 成本高
• human：专家评审、众包判断、抽样检查；黄金标准但是昂贵难以规模化

关键指标：

• pass@k: k 次独立运行中至少一次成功的概率 → 适合只需一次成功的场景。
• pass^k: 所有 k 次都成功的概率 → 衡量一致性要求高的场景。

 

基于不同类型agent的评估方法

编码类Agent：

• 以 SWE-bench Verified 和 Terminal-Bench 为代表：代码是否能运行，测试是否能通过
• SWE-bench Verified提供热门代码库的github问题，并通过运行测试套件来评估解决方案，只有当解决方案修复了失败的测试且不破坏现有的测试，才会通过评估
• 主要靠确定性的单元测试做正确性验证 + LLM rubric 做代码质量评价

 

对话类Agent

• 参考 benchmark: τ-Bench, τ²-Bench
• 需要第二个LLM来模拟用户角色进行多轮测试
• 多个维度来衡量：问题是否已解决（状态检查）、是否在 10 轮以内完成（文本记录限制）以及语气是否恰当（LLM 评价标准）

 

研究/检索类Agent

• 参考benchmark: BrowseComp
• 研究质量只能根据具体任务来判断，所谓全面，来源可靠，正确都取决于具体情况，同时专家可能对综合分析是否全面产生分歧

 

计算机操作类 Agent

• 与 GUI 应用交互——截图、鼠标点击、键盘输入。
• 关键权衡：DOM 操作快但 token 多 vs 截图方式慢但省 token。
• WebArena(浏览器)、OSWorld(完整操作系统控制)：通过文件系统状态、应用配置、数据库内容等多维度验证最终状态。

 

构建Eval体系

1. Step 0 尽早开始——20–50 个来自真实失败的任务即可起步。早期改动效果大，小样本足够检测信号。
2. Step 1 从手动测试转化——把发布前手动验证的行为和用户反馈的失败转成自动化任务。
3. Step 2 写无歧义的任务+参考解法——两位专家独立打分结论一致才算合格；每个任务应有已知可通过的 reference solution 验证 grader 配置无误。
4. Step 3 构建平衡数据集——同时测正例("应该触发")和反例("不该触发")，避免单侧优化导致过拟合。
5. Step 4 构建稳定隔离环境——每次 trial 从干净状态开始，避免共享 state 导致假阳/假阴。
6. Step 5 设计稳健 Grader
   1. 优先 deterministic > 必要时上 LLM judge > human judiciously 校准；
   2. 评产出不评路径——不要死板规定工具调用顺序，否则惩罚了合理创新;
   3. 任务有多组件就设 partial credit;
   4. 给 LLM judge 提供 "Unknown" 出口防止幻觉;
   5. 防 cheat：确保不能绕过 grader 取巧。
7. Step 6 读 Transcript——光看分数不够，必须读 trial 过程才能知道是 agent 错还是 grader 有bug。"Failures should seem fair."
8. Step 7 监控饱和度——100% 通过率的套件只能防回归无法驱动改进；接近饱和时应增加难度或新增 case。
9. Step 8 持续维护——eval suite 是活文档，需明确 owner 并鼓励产品/客服团队贡献新case; 推行"eval-driven development":先写eval定义目标能力，再迭代到达标。