解读：把评测做成代理系统的“控制面”¶
- 对应原文：https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents [103]
一句话主旨¶
评测不是上线后的补救，而是把代理行为变成可度量合同的“控制面”，帮助团队在规模化迭代中稳定地爬坡。[103]
关键概念再对齐¶
- 任务/试次/评测器/记录/结果/评测框架/代理框架/评测套件：这组概念把“代理系统”拆成可测对象和可比较口径，避免团队各说各话。[103]
- pass@k 与 pass^k：前者衡量“至少一次成功”，后者衡量“一致可靠”。这是工具型与面向用户型代理的核心分水岭。[103]
- 能力评测与回归评测：能力评测负责爬坡，回归评测负责守城；高通过率能力评测应“毕业”成回归套件。[103]
这篇文章对本书的补充位置¶
- 把第 2 章的“工具合同”延展为“评测合同”，把代理行为收敛为可验证结果。[103]
- 与第 8 章“长任务 harness”形成闭环：长任务需要稳定的运行框架，而评测提供持续回归与质量门禁。[103]
工程落地要点（可执行）¶
- 评测器组合：优先确定性评测，必要时引入 LLM 评测，再用人工校准；避免把“工具调用顺序”写死，以免误杀有效解。[103]
- 部分得分与抗绕过：为多组件任务设计部分得分，且确保通过必须解决问题而非钻漏洞。[103]
- 记录审阅机制：定期抽样阅读记录，区分“代理错误”与“评测器误判”，否则分数无意义。[103]
- 评测饱和治理：当通过率趋近 100%，引入更难任务或新维度，否则进步被压扁。[103]
落地流程（目标 → 前提 → 步骤 → 验证 → 失败判定 → 回滚）¶
目标
在 4 周内建立一个覆盖核心任务的回归评测套件，能够在每次模型/提示词变更时自动运行并给出可解释的结果。[103]
前提
- 有可复现的评测环境（干净初始化脚本 + 数据快照）。
- 已整理 20–50 个来自真实失败的任务样本。
- 选定一个可运行的评测框架（或最小脚本）。
步骤
- 将现有手工检查与用户失败案例转为任务，并为每个任务写清晰成功标准。
- 为每个任务准备参考解，确保评测器能在“已知正确解”上通过。
- 先用确定性评测器跑通，再补充必要的 LLM rubric（先小范围校准）。
- 建立最小回归套件并接入 CI；记录 pass@1 与 pass^k 的基线。
- 每周抽样审阅 10–20 条记录，修正评测器误判与任务歧义。
验证
- 套件在 3 次连续运行中稳定通过（方差可解释）。
- 回归套件能捕捉一次刻意引入的回归（例如删掉关键工具调用）。
失败判定
- 参考解无法通过评测器。
- 多次运行分数波动大且无法解释（环境污染或评测器不稳定）。
回滚
- 回滚到上一次稳定的评测配置与环境快照，重新定位错误来源。
读后结论¶
评测不是“锦上添花”，而是代理系统规模化的前置条件：没有评测，团队只能靠直觉；有评测，才有可复用的工程控制力。[103]