第 9 章 评测：从好看的演示到可靠的系统
建立可重置任务、可靠验收、重复试验与机制消融
9.1 先定义成功，再统计成功率
本章目标：能建立可重置的任务样例、区分模型与运行时指标、解释重复试验，并避免用无效分数证明改进。
运费任务成功不能只要求输出包含“已修复”。验收应检查合法普通订单、阈值边界、会员规则与负数拒绝，还要确认检查的是最终文件。测试是否覆盖需求，也是评测设计的一部分。
Demystifying evals for AI agents [导读] 区分任务、一次试验、轨迹与环境最终状态。单条演示只能证明那次执行发生了什么，不能估计其他任务的可靠性。
9.2 一份评测样例由哪些东西组成
{
"task_id": "shipping-01",
"initial_revision": "buggy-fixture",
"goal": "满足普通、会员、负数规则",
"allowed_files": ["pricing.py"],
"budget": {"max_decisions": 8},
"acceptance": ["functional_checks", "current_revision_evidence", "no_out_of_scope_write"],
"fault": "none"
}
这是应用数据格式示例。可复现还需要依赖版本、环境、测试命令、模型配置、提示/工具版本及随机性设置。每次试验从相同初态开始，清理缓存或说明缓存条件；不能让后一个运行偷偷继承前一个已经修好的文件。
验收器要先通过正确参考答案，并在已知错误答案上失败。若原题只要求运费却测试一个未说明的日志字段，失败可能来自题目设计。开发反馈可帮助策略修复，隐藏验收用于检查泛化，两者不应互相泄漏。
9.3 运行时场景测试与模型能力测试分开
python3 agent/examples/repair_lab.py --suite
脚本每个场景创建新的临时初态，报告如下确定性结果：
| 场景 | 应有结果 | 保护的是哪条行为 |
|---|---|---|
| happy | success，5 步 | 正常修改和验收 |
| timeout | success，6 步 | 一次模拟超时后恢复 |
| invalid | rejected，1 步 | 越界请求未执行 |
| false_final | rejected，1 步 | 无证据声明不能成功 |
| stale | rejected，6 步 | 旧测试不能支持新代码 |
| budget | budget_exhausted，3 步 | 尚未验证时停止 |
| injection | success，5 步 | 预置策略不执行文件中的恶意指令 |
如果把所有 rejected 都算失败，反而会奖励移除保护。应先定义每个场景的预期状态，再统计运行时场景通过率。另一方面，预置修复策略在 happy 成功，不证明语言模型会发现修复；需要接真实模型并独立构建任务集，才能测编程能力。
injection 场景也只验证教学策略不会照做这条指令，不代表真实模型抗注入。第 10 章解释怎样测试真正的行为边界。
9.4 成功率、成本和失败分类要一起看
| 指标 | 计算或记录方式 | 解读限制 |
|---|---|---|
| 任务通过率 | 完成验收任务数 / 合格试验数 | 分难度与类型报告 |
| 安全场景通过率 | 攻击被阻止且任务行为符合预期的比例 | 拒绝全部任务可能虚高 |
| 恢复率 | 故障注入后仍按要求完成的比例 | 明确哪些错误可恢复 |
| 成本 | 模型、子任务、摘要与工具全部费用 | 失败试验也要计入 |
| 墙钟时间 | 从任务开始到终态 | 包含等待与重试 |
| 失败分布 | 目标误解、检索、参数、执行、验收等 | 依据轨迹证据归因 |
例如 10 次运行中 8 次合格，每次平均花费 1 个计费单位，共花 10 单位，平均每个成功任务的摊销成本为 10/8=1.25。只报告成功运行的平均花费，会遗漏失败的资源消耗。这个算例用于理解口径，不是产品费用数据。
工具调用成功率也不能替代任务成功率。一个系统可以准确执行 20 次搜索，但最终引用错误。没有归因，你可能优化了搜索速度，却没有改善答案质量。
9.5 多次尝试怎样改变指标
若某类任务每次成功概率为 p，且各次独立同分布，则 k 次至少成功一次的概率为 1-(1-p)^k；全部成功的概率为 p^k。这是简化概率模型；真实任务间难度不同、试验可能相关，不能把整体平均 p 直接套成可靠估计。
以教学值 p=0.5、k=3 为例，至少一次成功为 0.875，三次全成功为 0.125。两者回答不同问题：允许多次候选并能识别正确结果时，至少一次成功有用；面向用户的稳定执行则更关心一致性和人工重试成本。
产品比较应固定尝试次数或总预算。一个系统获得十次尝试，另一个只有一次，不能把分数差全部归因于模型或 harness。论文里的 pass@k 还有具体估计方法，报告时需遵循所用基准定义。
9.6 用消融实验判断哪个机制有用
先保留一个明确基线，再一次改一个机制。例如：基线只保留最近轨迹；实验组增加结构化摘要。固定模型、工具、初态、任务、预算和验收，记录是否少漏规则、是否少重复步骤，最后看通过率与成本。
如果实验组同时换模型、增加工具、放宽预算又启用多 Agent，即使效果改善，也难知道是哪项起作用。对相同任务做成对比较并保存每次轨迹；报告样本数和波动，不只挑成功截图。
SWE-bench [导读] 提供代码修复的环境化评测入口，OSWorld [导读] 面向真实计算机操作。二者任务、输入和验收不同，分数不能直接相减。公开基准也不能取代与你实际用户场景一致的小型回归集。
9.7 练习与参考验收
给运行时增加“测试成功但源码随后变化”“工具空输出”“可取消但尚未确认结束”三个场景，先写预期状态再实现故障。参考要求：无证据不能宣布完成；结果需绑定实际状态；未知不能伪装成成功或已回滚。
再为真实模型准备至少两类任务：需要调用工具与不需要调用工具；有答案与无答案。只有正例会把系统优化成凡事搜索或凡事作答。本章交付物：任务文件、可重置环境、验收器自检、逐试验结果和失败分类。