Evals是AI时代的CI：对Agent产出建立验收层

你的 agents 效率很高。Pull request 量在涨，Demos 效果不错，每次合并后流水线都是绿的。但尴尬的地方在于：绿只意味着代码编译通过、测试通过，而测试本身越来越多也是写代码的那个 agent 写的。没有任何一道关卡在衡量这个工作是否真的正确。"看起来对"正在承担"已验证对"曾经承担的那份重量。

你现在面临的选择是：要不要为 agent 产出的工作构建一层验收层——就像 CI 成为人类代码的验收层那样——还是继续在视觉检查的基础上不断扩大 agent 的自主权。Agents 不会大声失败。某个模型更新发版后，某个 support agent 开始漏掉升级信号，没有报错，几周后你才从流失指标里发现。真正能规模化安全 autonomy 的团队，靠的不是最好的 prompt，而是最严格的 evals。

先说这个词本身，因为它承载着整套论点。Eval 是一种可重复的、对 agent 输出按你定义的标准打分的测试：不是"测试通过了吗"，而是"这次改动是否正确、是否局限在工单范围内、是否安全到可以合并"。单元测试对确定性代码返回通过或失败，而 eval 在多个维度上对判断力打分，用的 grader 从简单脚本到"用模型按书面 rubric 评判其他模型"不等。这样一组 eval，每次变更都像 CI 每次 commit 那样运行，我称之为 eval estate。在本系列前文中，我论证过"写的 agent 不能是检查的 agent"；这解决了谁来裁判的问题。更难的问题是——裁判怎么知道什么叫好。

整个行业正在重建验收层

Anthropic 工程团队在 2026 年 1 月发表的文章"Demystifying evals for AI agents"中提出了这个重构：评估不是研究的后续思考，而是 agentic 系统的 CI/CD 流水线。几周内，Braintrust 将这个类比精确化了，推出了 eval-driven development，即 agentic 时代的 test-driven development，只有一个关键区别：TDD 是二元的，EDD 是多维打分的，因为一个答案可能事实正确但太长，或者格式良好但缺失关键信息。同期多家厂商落在了同一运营规则上：如果 agent 的指标在你的基准集上未达阈值，部署自动失败。如果你在读这篇文章，我认为不需要说服你 evals 的重要性了，我会试着向你展示团队实际上是怎么构建它们的，以及他们常在哪里出错。

Braintrust 的工作实例最能说明日常节奏：团队换上一个更新的模型，第一次 eval 运行显示 tone 从 0.85 降到 0.72，他们调整 prompt，重新运行，tone 恢复到 0.88 而准确率保持不变。全程二十分钟。没有这个 estate，那个回归要等两周后才以客户投诉的形式浮出水面。

为什么你的测试套件做不了这件事

单元测试能工作是因为同样的输入返回同样的输出。Agents 打破了这个契约：同样的 prompt 在不同运行和模型版本下产生不同输出，错误在多轮交互中叠加，agents 选择的解决路径你从未预料到。你的测试套件在检查代码。没有人在检查判断力。

还有一个在人类写代码时不存在的失败模式：test-gaming。开发者很少去 gaming 自己的测试套件。对于 agent，除非你刻意从架构层面规避，否则默认行为就是为测试通过做优化。

评什么：正确性只是容易的三分之一

Anthropic 的分类给了你机制：

• code-based graders 用于确定性检查
• model-based graders 用于 rubric 判断
• human graders 少量使用，主要用于校准 model-based graders

但最有用的问题"评什么"的答案来自 FrontierCode，Cognition 自己搭建的基准，由 36 位外部开源维护者共同参与：他们对补丁在六个维度上打分：

• behavioural correctness
• mechanical cleanliness

你的流水线今天测量了这份清单上的几项？

playbook：從你已有的东西开始构建 Estate

标准的反对意见是 eval 集合需要大量人工标注。你所在的组织已经坐在原材料上了。四步，按实际经历生产验证的顺序来。

1. 从你的 PR 历史和 postmortems 中播种。SWE-bench 确立了这个模板：从已合并的 PR 中挖掘——那些修复了关联 issue 且动了测试的 PR，重建修复前的 repo 状态，只保留测试在补丁前失败、补丁后通过、同时其他一切保持绿色的 case。他们从约 90,000 个 PR 过滤到 2,294 个干净 case，这告诉你一个真实 repo 持有多少素材，也告诉你过滤应该有多严格。你的 review comments 是第二条矿脉；Cursor Bugbot、Qodo、Greptile 和 CodeRabbit 已经在从这类数据构建学习规则了。你的 incidents 是第三条：一份 postmortem 直到有一项东西真正改变了才算完成，比如加一个回归 eval；否则那只是文档，不是工程。陷阱：凭想象写 eval cases；你会测试你恐惧的东西，而不是实际发生的东西。信号：每个 eval case 都能追溯到真实 PR、incident 或生产 trace。

2. 把 behavioral 场景存在 agent 读不到的地方。StrongDM 的结构性修复是我见过最干净的：behavioral 场景保存在代码库之外，在 agent 工作时对其不可见，功能类似机器学习的 holdout set。Agent 无法优化它从未见过的标准。Judge 同样适用：不能看到 maker 的推理过程，否则它会继承 maker 的假设。陷阱：把 eval 标准放在 repo 里"为了透明"，agent 会读到它们然后按检查的字面意思优化。信号：agent 在 holdout 场景上的通过率明显低于 repo 内测试的通过率。

3. 在让 judge 把关之前先校准它。LLM-as-judge 是这一切的规模化机制，也是纪律通常崩塌的地方：2026 年行业流传的数据是，约 93% 的团队没能把 judge 实现好。我把这个数字当作方向性的，但根本原因是缺失校准，而不是模型弱。我以最直接的方式学到了这一点。我们在 Betsson 的 AI-DLC 工具链内运行的第一个 Reviewer agent 几乎批准了它看到的一切：它回答一个二元问题，通过还是失败，而一个能力足够的模型对看起来合理的代码问一个二元问题，答案就是通过。只有当我们把 yes/no 检查替换为从人类 reviewer 实际拒绝过的内容构建的计分 rubric 时，门禁才开始拦住工作：从中学到的 workflow：用平实的语言定义每个分数段（0.2 是什么样的，0.8 是什么样的）；保持一组固定的已知失败的 ground-truth 集；测量 judge 与人类 reviewer 的一致率；在一致率大约达到 75% 到 90% 之前不让它把关任何东西。要求先出理由再出分数，因为先出分数的模型会无论如何都捍卫它。当一致率停滞时，调试 rubric 而不是 agent prompt。无聊、重复的工作，却是我们做过的杠杆最高的工作。陷阱：因为在十个样本上与你一致就信任一个 judge。信号：持续用新的人类审核样本测量一致率。

4. 把门禁接入晋升流程，然后观察它漂移。Eval 分数成为环境间晋升的标准：某个变更让指标跌破阈值就不发版。然后把 estate 当作活的 artifacts 来对待。套件 100% 通过不是健康套件，是死掉的传感器。每个模型变化都会让 estate 老化：Anthropic 工程师描述同一个 tool-use prompt 在一个模型版本上严重触发不足，在下一个版本上严重过度触发，所以那个打分它的 eval 在升级前后都给了虚假信号。陷阱：把饱和套件当作成功来庆祝。信号：门禁大多数星期都会拦住真实的东西，而且每月都会新增 case。

成本是多少，以及那个 Kill Metric

诚实的成本是资深人类的时间——定义你们自己工作流中"完成"意味着什么；没有人给出了一个可信的美元数字，我也不会编一个。先资助：一个回归套件加一个针对你最有价值的 agent 工作流的已校准 judge，用它的 PR 历史和 incidents 播种。后续资助：fleet 级别的覆盖和对抽样生产流量的漂移监控。季度内的 kill metric：门禁必须在生产之前拦住真实回归，judge 必须对新鲜人类样本保持一致率。九十天门禁什么都没拦住过，就是装饰。修复 rubric 或者停止假装你有个门禁。

这笔投入是会复利的，就像测试有效性取代测试覆盖率成为真正重要的指标一样：每个从真实失败中挖掘出的 eval 都在每次未来运行、每次模型切换、每次供应商谈判中持续回报。信任差距是可以量化的：DORA 2025 年报告发现只有 24% 的开发者"很大程度"信任 AI 输出，LinearB 2026 年基准发现 AI 生成的 PR 以不到人工一半的速率合并，而领导者们把 Context 和信任，而非正确性，列为障碍。Evals 让信任有了一个数字。

Start, Stop, Continue

管理者 Start：把 eval estate 作为验收基础设施来资助，指定负责人，就像 CI 曾经有一个负责人一样；在批准任何 autonomy 提升之前要求 judge-人类一致率。Stop：接受"流水线是绿的"作为 agent 工作正确的证据；只基于 agent 自己写的测试来批准 agent 部署。Continue：让每个人对每次合并的变更负责，evals 决定他们可以委托多少检查工作。

工程师 Start：本周就把上季度被拒绝的 PR 和 incidents 挖掘成播种 eval 集；要求每个 judge 在分数之前先出理由。Stop：把任何东西交给未校准的 judge 把关；庆祝 100% 通过率；用二元检查给质量打分。Continue：读 agents 发出来的东西。Eval estate 扩展你的判断力；它不取代判断力。

一个 eval estate 会复利：每次挖掘到的失败和每次校准过的 rubric 都让下一个 agent、下一个模型、下一次 autonomy 决策更便宜、更安全。Inspection 会遇到瓶颈：它的扩展速度恰好等同于资深注意力的增速，而资深注意力已经是你最大的瓶颈。Anthropic Institute 自己叙述在超过 80% 的 AI 编写生产代码的环境下运行，将人类 review 列为新的瓶颈，而他们事后诸葛 mandatory automated reviewer 大约能捕获过去 incidents 背后三分之一的 bug。验收层是瓶颈下一步移动的地方。谁先把它工业化，谁就掌握了自己的节奏。

所以对你的组织做这个测试：如果明天发版了一个更好的模型，你能在这天结束前用一个数字说明你最重要的 agent 工作流是变好了还是变差了吗？如果答案是不能，你批准的每次 autonomy 提升都是在盲目下注。告诉我哪里说得不对。如果你的团队在没有 eval estate 的情况下自信地发版 agent 工作，我想知道你们在做什么，如果论点成立，把这篇文章发给负责你们 CI 流水线的人，问问谁来负责 evals。