Evals：怎样知道 Agent 真的做好了

Demo 成功一次，只能说明这次路径碰巧走通。Agent 可能换一条路径、漏掉一个检查、在高风险任务里越权，或者用更多时间和工具调用得到同样结果。要判断系统是否真的变好，需要把任务和判分方式固定下来，反复重做。

一、先用一道题看懂 Eval

1.1 看一个“说完成了，实际没完成”的案例

支付测试任务的最终回复很漂亮：它解释了失败原因，也说代码已经修复。但执行记录只有“读文件、改代码、输出结论”，没有运行测试；仓库里的目标测试仍然失败。

如果只给最后回复打分，这次任务可能被判为优秀；如果检查真实仓库状态，它就是失败。Eval 是一套可重复的考试：给 Agent 一个确定起点和任务，让它实际运行，再由独立规则判断做得对不对。

1.2 一道 Eval 题目由什么组成

• 起始环境：一份可恢复的仓库或业务状态，保证每次从同一位置开始。
• 任务：例如“修复指定支付测试，不能修改公开 API”。
• 可用工具与限制：允许读哪些文件、能否联网、哪些动作需要批准。
• 期望结果：目标测试通过，相关回归通过，修改范围符合要求。
• 判卷规则：由测试命令、静态规则、模型评审或人来判断结果。

先不用 JSON，也能把这道题写完整：

任务：修复失败的支付测试
起始状态：fixture payment-regression-1
必须保持：公开 API 不变
通过条件：支付测试退出码为 0
还要检查：改动文件范围与未授权副作用

负责判卷的规则或评审者统称 grader。退出码、文件状态这类明确条件优先交给程序；表达质量这类开放问题可以交给模型或人；高风险价值判断最终仍需要人。

上一篇的 verifier 与这里的 grader 都会检查证据，但时间尺度不同：verifier 针对一张真实任务卡，决定它现在能否结束；Eval grader 针对可重复题集，判断一版系统是否稳定做对。前者服务在线工作流，后者服务系统比较和改进。

1.3 判分先看现实结果，再看漂亮过程

评测从“什么算成功”开始，而不是从“现有日志能测什么”开始。Coding agent 的真值可以是测试、静态检查、diff 范围和 reviewer 决策；客服 agent 的真值可以是账户实际状态、政策遵循和客户后续；研究 agent 的真值可以是来源覆盖、引用一致性与冲突标注。Final response 只是证据之一。

题目：修复 payment regression
起点：目标测试失败，公开 API 不变
允许：读写仓库、运行支付测试
通过：目标测试和相关回归都成功
失败：未运行测试、越权修改、声称完成但结果不成立

二、把一道题扩成可信的评测系统

2.1 为什么要从结果逐步增加四层检查

把支付测试的录制 trace 交给四个 grader，就能看到“final 看起来对”为什么不够：

trace = {
  "task_id": "payment-regression-1",
  "final_claim": "fixed",
  "baseline_test_exit_code": 1,
  "final_test_exit_code": null,
  "tool_sequence": ["read", "edit", "final"],
  "effects": [],
  "tool_calls": 3
}

outcome_ok = trace["final_test_exit_code"] == 0
process_ok = "run_tests" in trace["tool_sequence"][:-1]
safety_ok = not forbidden_effects(trace["effects"])
operations_ok = trace["tool_calls"] <= 8

Outcome 回答目标是否达成；Safety 是不能被平均 outcome 抵消的硬门。两者并不冲突：一个修复即使测试通过，只要发生越权写入，发布仍应失败。

Anthropic 强调 agent eval 要结合 outcome 与 transcript/trace，因为 agent 可能通过不同合理路径完成任务。过程评测应约束关键不变量，比如“退款前必须确认授权”，而不是要求每次都调用完全相同的工具序列。

2.2 从一道题扩成一套代表真实风险的题

Eval set 需要覆盖正常、边界、对抗、恢复和长期任务；还要按风险、任务族、能力、语言、数据新鲜度与工具路径切片。生产失败应经过脱敏和标注进入回归集，合成任务补充稀有但重要的边界。

同一道题通常也要运行多次。Agent 的模型选择和工具路径可能有随机性；一次通过只说明“这次做对了”。例如同一题跑十次、八次通过，才暴露出 80% 的成功率与两次失败轨迹。发布时既看平均结果，也看波动和高风险失败是否出现。

• Golden set：少量稳定、人工高质量标注；它可以用于开发、比较或验收，取决于可见边界。
• Regression set：每个真实失败至少形成一个可重放 case。
• Exploration set：更宽分布，用来发现未知失败，不作为唯一门槛。
• Adversarial set：prompt injection、权限诱导、旧证据、重复事件和状态冲突。
• Long-horizon set：跨 compact、重启、checkpoint 与多次 run。

2.2.1 题目用途与可见阶段是两条不同的轴

Golden、regression、adversarial 和 long-horizon 回答的是“这道题用来测什么”；development、validation 和 holdout 回答的是“谁在什么时候能看见并使用它”。一条真实支付回归既可以属于 regression，也可以在修复期间进入 development；标签不会自动让它成为保密验收题。

表里向前推进的是候选版本，不是让同一道题依次经过三栏。每条 case 应固定在自己的可见集合里。这里的 train 不一定训练模型权重；它可能只是用于改 Prompt、Context policy 或 Harness。Validation 也不是保密考试，因为它参与候选选择。Holdout 一旦被拿来指导下一轮修改，就不再是未见数据，必须把暴露的失败重建为 development case，并换一组仍然封存的验收题。

独立还需要两层条件。第一，旧版和候选要在相同模型、工具、权限、预算、grader 与干净环境中运行；Anthropic 对 agentic coding eval 基础设施噪声的分析也指出，资源和执行环境不同会改变测试本身。第二，同一会话、同一漏洞家族或只是换了说法的题不能跨阶段泄漏；随机打乱行并不能自动建立这种独立性。任务族分组、语义去重、数据版本和随机种子都应被记录。

2.3 判卷规则本身也可能判错

确定性 grader 适合 schema、测试、状态和规则；LLM grader 适合语义质量、完整性和开放式 rubric；人评适合高风险、价值判断和校准。组合比单一 grader 更可靠。

用一组人类已判定样本校准 grader：对离散标签检查 precision、recall 与混淆矩阵；对开放 rubric 检查与双人标注的一致性、分歧样本和漂移。Grader 不是观测真理的透明窗口，它也是系统组件。

三、让评测真正推动系统改进

3.1 失败以后，先找出是哪一层出了问题

Eval 的最大价值不是报一个 pass rate，而是形成可行动的失败切片。把 trace、context manifest、policy decision、tool result 和 outer-loop state 拼起来，才能区分“模型没遵守”“模型没看到”“运行时没挡住”“循环停错了”“跨 run 丢状态”或“grader 判错了”。

3.1.1 一次失败怎样变成被验证的系统修改

1. 执行基线：在固定 fixture 和运行条件下记录支付任务的 outcome、trace、成本与失败 grader。
2. 解释失败：确认目标测试没跑，是 Prompt 没要求、Context 没带证据、Loop 过早退出，还是 grader 自己判错。
3. 修改 owner：只改变拥有根因的组件，并写下预期出现的可观察差异。
4. 重跑可比较题：先在 development / validation 上确认目标切片改善，再检查关键 regression、成本和稳定性。
5. 保留或撤销：只有证据支持且验收门通过才保留候选；否则回滚，并把新失败加入可重放数据。

OpenAI 的 agent eval 指南把 trace 用于定位 workflow-level 问题，再把单条 trace 升级成可重复的数据集与 eval run。这个顺序很重要：解释失败但不重跑，只得到一个假设；重跑却不固定条件，也无法把改善归因给刚才的修改。

3.2 从固定环境逐步走向真实流量

离线回放快、可重复，但无法覆盖真实用户与外部系统变化；shadow run 能在真实输入上比较新旧系统而不执行副作用，因此只能验证选择、trace、权限决策和候选动作，不能证明真实退款、PR 或通知已经正确发生；sandbox、灰度和生产对账才逐步接近真实 outcome。

1. 提交前：单元级 prompt/tool/context cases。
2. 合并前：固定 regression 与多次采样，按关键 slice 设门。
3. 发布前：shadow / sandbox，比较 outcome、cost 与 trace。
4. 灰度：低风险流量、明确 guardrail 和自动回滚。
5. 生产：监控结果、漂移、人工接管与未知失败，回流新 cases。

3.3 单一分数会诱导系统“刷分”

单一指标会被系统优化：追求工具调用少，agent 可能不调查；追求完成率，可能越权猜测；追求低延迟，可能跳过验证。使用带硬约束的多目标：安全与关键正确性是 gate，完成率、成本、延迟在可行集合内优化。每个指标都要配反指标与 trace 抽查。

四、系列收束：修改、回归、再验证

4.1 把“产出候选”“验证候选”“采用版本”分开

系统生成了一个新 Prompt、选择策略或 Harness 版本，只能说明候选已经产出。它在 development 和 validation 上变好，说明候选通过了搜索期检查；封存题、关键回归、成本与恢复门通过，才说明它具备发布资格。最终是否进入生产、由谁批准、怎样灰度和何时回滚，仍属于采用阶段。

candidate produced
-> development: target failure improves
-> validation: candidate selected under comparable conditions
-> holdout: sealed acceptance cases opened once
-> rollout: low-risk traffic with rollback gate
-> adopted: authorized owner makes it the active version

any gate fails -> reject or rollback
                 -> reproduce the failure in development
                 -> create a new candidate and rerun

4.2 用六层证据决定下一步改哪里

至此，Prompt、Context、Harness、Agent Loop、Outer Loop 与 Evals 形成完整闭环：定义行为，装配证据，控制动作，让一次运行收敛，让多次运行接力，再用外部真值推动下一版系统。所谓 AI Engineering，不是追逐最后出现的名词，而是让每个边界都有 owner、每次变化都有证据，并把“已经产出”“已经验证”“已经采用”始终分开。

官方资料

• OpenAI：Working with evals
• OpenAI：Evaluate agent workflows
• Anthropic：Demystifying evals for AI agents
• Anthropic：Quantifying infrastructure noise in agentic coding evals
• Anthropic：Building and evaluating trustworthy agents

延伸阅读

• 菜鸟教程：Agent 评估、安全与对齐