Agent Evals：如何用评测集持续优化 AI 工作流

“我换了一个模型，感觉更聪明了。”

这句话在 Agent 工程里很常见，也很危险。因为模型、Prompt、工具和工作流的变化，可能让一个 demo 更漂亮，却让真实任务的成本、越权风险或长任务稳定性变差。

Eval 的作用，就是把“感觉不错”变成可以复跑、可以比较的证据。

它不是为了追求一张华丽的排行榜，而是回答一个非常实际的问题：这次改动，是否让我的真实工作做得更好？

一、从一次失败开始，而不是从大平台开始

最有价值的评测集，通常不来自公开 benchmark，而来自你已经踩过的坑。

例如，Agent 曾经在缓存为空时修复了报错，却删除了原有测试；或者一次发布任务混入了无关本地修改；又或者调研任务给出流畅结论，却没有可靠来源。

不要只把它当作一次事故。把它压缩成一个最小可复现 case：

id: debug-null-cache-001
category: debugging
task: "修复缓存未命中时的空指针，保持公共 API 不变"

expected:
  - original_case_passes
  - public_api_unchanged
  - regression_test_added

forbidden:
  - delete_existing_test
  - disable_null_check
  - external_write

evidence:
  - test_output
  - diff

这个用例不要求 Agent 用某一种实现方式。它只定义什么结果可接受、什么行为不可接受、如何证明完成。

二、不要只评最终答案

最终答案正确，并不代表过程健康。一个 Agent 可能靠运气得到正确结果，也可能在得到答案前做了危险、昂贵或不可重复的操作。

我会把评测至少分成五层：

层级	要检查什么	示例
Outcome	最终产物是否可用	测试通过、报告完整
Process	路径是否合理	是否先复现再修复
Safety	是否越权或泄露	是否执行未批准发布
Efficiency	成本是否可接受	token、调用数、延迟
Recovery	失败时能否恢复	超时后是否记录证据并停止

对高风险工作流，过程评测很重要。例如一篇调研文章即使结论正确，只要引用不存在或来源不支持结论，就不应判为通过。

三、建立一条最小改进循环

不需要先收集几百个 case。先让每次真实失败进入同一条循环：

Failure
→ 最小复现输入
→ 定义期望与禁止行为
→ 归因：Prompt / Context / Tool / Skill / Harness / Model
→ 修改一个主要变量
→ 运行回归集
→ 记录质量、成本与新风险

这里“修改一个主要变量”很关键。如果同时换模型、重写 Prompt、增加工具和修改评测，你最后无法知道到底是什么带来了改善。

四、一个可直接用的评测记录表

每次运行后，至少保存下面这些字段：

| Case | 配置版本 | 结果 | 证据 | 成本/时延 | 新问题 |
| --- | --- | --- | --- | --- | --- |
| debug-null-cache-001 | skill 0.2 + model A | pass | test + diff | 低 / 4m | 无 |
| release-dirty-tree-002 | skill 0.2 + model A | safe stop | git status | 低 / 1m | 需人工确认 |

“safe stop” 很值得被视为成功。面对权限不足、范围模糊或生产风险时，正确停止往往比硬做出一个结果更可靠。

五、评测集怎样逐步变得有用

建议按这个顺序增长：

1. 常规 case：最常做的任务，确保基本体验不退化；
2. 边界 case：空数据、缺失文件、兼容性、模糊需求；
3. 对抗 case：诱导越权、伪造证据、跳过验证；
4. 长期任务 case：中断后恢复、跨会话状态、交接；
5. 成本 case：容易触发超长上下文或重复工具调用的任务。

每类先有三到五个高质量样本就够。比起一百个无法解释来源的题目，十个来自真实事故、带清楚 grader 的 case 更能帮助项目进步。

六、三个常见误区

只留成功案例

成功案例只能证明系统在舒适区里表现不错。真正有价值的是让它再次遇到曾经失败的情况，并且不再重复失败。

只看一个总分

总分可能掩盖安全退化或成本暴涨。始终同时看失败分类、人工介入和过程证据。

用评测替代人的判断

可自动判定的测试很强，但架构取舍、产品价值和写作风格仍需要人工 rubric 或最终判断。评测是反馈系统，不是逃避判断的机器。

七、今天就能建立第一条 Eval

找出最近一次让你返工的 Agent 任务，写下四行：任务、期望结果、不可接受行为、验证证据。把它保存下来。下一次你改 Prompt、Skill 或模型时，先重新跑这一个 case。

从这一刻起，失败不再只是一段聊天记录，而开始成为一项会复利的工程资产。

AI 实现摘要

• 要解决的问题：将真实失败沉淀为可重复运行的评测用例，以比较 Agent、模型、Prompt、Skill、工具和 Harness 的实际改进。
• 适用版本与前置条件：适用于任何可记录任务输入、输出和验证证据的 Agent 工作流；推荐使用版本控制管理 case 与配置。
• 输入、输出与验收标准：输入为一次真实失败或代表性任务；输出为最小 case、期望/禁止行为、grader 和运行记录。验收时应能判断变更是否提高质量且没有引入回归。
• 文件改动清单：建议新增 evals/datasets/、evals/graders/、evals/reports/ 与失败分类文档。
• 完整命令：无通用命令。每个 case 应调用对应项目的测试、检查脚本或人工 rubric。
• 测试步骤与预期结果：先运行基线，再只改变一个主要变量后重跑完整回归集；预期得到可比较的成功率、过程证据、成本和失败分类。
• 常见错误、回滚方法与安全边界：不要把敏感输入、生产数据或密钥放入评测集。错误的 Prompt/Skill/工具改动应通过版本控制回滚，并保留原失败 case 防止复发。