Agent 评测不是排行榜，而是上线门禁
如果你最近在做 Agent，我建议你先别急着问“哪个模型更强”。
更应该问的是：这个 Agent 真能上线吗？能扩权吗？能自动执行吗？出了问题，我们能复盘吗？
Anthropic 这篇《Demystifying evals for AI agents》，我觉得最适合被转译成一句工程话：Agent 评测不是排行榜，而是上线门禁。
来源与关键概念
资料来自 Anthropic Engineering，文章发表于 2026 年 1 月 9 日。
原文把 eval 定义为：给 AI 系统一个输入，然后用 grading logic 衡量结果。
如果只是单轮模型，这件事相对简单：prompt、response、grader。但 Agent 更麻烦，因为它会多轮调用工具、修改环境、根据中间结果调整路径。
Anthropic 在文中定义了几个关键词：task 是测试任务，trial 是一次尝试，grader 是判分逻辑，transcript 是完整运行轨迹，outcome 是环境最终状态，evaluation harness 是跑评测的基础设施，agent harness 是让模型能像 Agent 一样行动的脚手架。
这组概念听起来抽象，但落到工程里非常直接：你不能只看 Agent 说了什么，还要看它到底把系统改成了什么样。
机制一：看轨迹，更要看最终状态
第一个机制，叫 transcript 和 outcome 分离。
transcript 是 Agent 的运行记录：它说了什么，调用了哪些工具，中间怎么推理。这个东西很重要，因为你要靠它复盘失败。
但真正决定成败的是 outcome，也就是环境最终状态。
比如订票 Agent 说“票已经订好了”，这不是 outcome。真正的 outcome 是数据库里有没有订单、支付有没有成功、用户有没有收到确认。
代码 Agent 说“我已经修好了”，也不是 outcome。真正的 outcome 是目标测试有没有从失败变通过，原有测试有没有保持通过，diff 有没有只改相关文件，有没有安全问题。
内容生产 Agent 说“我核对了来源”，同样不够。我们要看稿件里的关键事实有没有 URL，数字有没有写清“原文称”，标题有没有超过证据边界，视频脚本有没有把生产提示语暴露给观众。
所以 Agent 评测的第一条，不是问它解释得好不好，而是问系统状态对不对。
机制二：grader 不是一个模型，而是一组门禁
第二个机制，是 grader 组合。
Anthropic 把 grader 分成三类：code-based、model-based 和 human。
code-based grader 很适合客观条件，比如单元测试、静态分析、状态检查、字符串匹配、工具调用校验。它的优点是快、便宜、可复现；缺点是容易脆，对开放任务不够灵活。
model-based grader 更适合开放文本和复杂行为。比如一篇稿件是否有逻辑，一段客服回复是否得体，一个研究报告是否覆盖关键证据。但它有不稳定和幻觉风险，所以要写清 rubric，并且用人工样本校准。
human grader 是金标准，但慢、贵、不可能覆盖所有 case。它更适合用来校准模型 grader，或者处理高风险边界。
这对普通团队的启发是：不要迷信“再找一个大模型当裁判”。能用脚本检查的，先脚本检查；需要语义判断的，再用模型；最关键的地方，保留人工门禁。
一个内容生产线的例子：脚本检查来源链接、敏感词、字数和结构；模型检查标题是否夸大、论证是否跳跃；人工最后判断选题价值和观众节奏。
机制三：能力评测和回归评测要分开
第三个机制，是 capability eval 和 regression eval 分开。
能力评测问的是：这个 Agent 能不能做更难的事？它适合拿来爬坡，任务可以难一点，初始通过率低一点也正常。
回归评测问的是：这个 Agent 以前能做好的事，现在有没有退化？它更像 CI，应该在每次重要变更时跑。
这个区别非常实际。你换了一个更强模型，也许它会更敢改代码，但同时开始误改无关文件。你把 prompt 改得更有创造力，也许标题更吸引人，但事实边界开始变松。你给运维 Agent 加了更多工具，也许它诊断更快，但危险操作建议也变多了。
如果只有能力评测，你会觉得系统越来越强。如果没有回归评测，你可能不知道它正在把旧能力弄坏。
所以，Agent 上线前跑回归 eval；Agent 扩权前跑更严格的边界 eval；模型升级前后，要跑同一批任务做对比。
机制四：最好的 eval 来自真实失败
Anthropic 文章里有一个很接地气的建议：不要等你有几百个任务才开始。早期可以从 20-50 个简单任务起步，而且最好来自真实失败、人工检查、bug tracker、support queue。
这点非常适合普通团队。
很多人一提 eval，就先想搭平台、选框架、买工具。但最重要的不是平台，而是 case。你有没有把真实失败变成测试任务？
内容生产线可以先收集 20 个历史问题：标题过度、来源缺失、数字归属错误、英文标题生硬翻译、脚本没有结论、PPT 露出制作提示语、字幕过密、事实风险表缺失。
开发工作台可以收集历史 issue、失败 PR、误改文件、没跑测试、修一个 bug 引入另一个 bug 的案例。
智能运维可以收集事故复盘、误判告警、证据不足的诊断、危险控制建议。
每一个 case 都写成清晰任务：输入是什么，允许 Agent 用哪些工具，成功标准是什么，禁止行为是什么，参考答案是什么。
这就是 eval-driven development。不是先等 Agent 强了再评测，而是先用评测定义你希望它会什么。
普通团队的最小上线门禁
如果今天就要做，我建议用六步。
第一，每个 Agent 场景先收集 20 个真实任务。不要追求覆盖全部，只要覆盖最常见、最危险、最容易误判的场景。
第二，每个任务写清规格。输入、工具、成功标准、禁止行为、参考结果，一个都别省。
第三，优先验证 outcome。能用测试、文件检查、数据库状态、链接检查解决的，不要先交给模型主观判断。
第四，开放质量项拆成 rubric。比如内容稿件可以拆成事实准确、来源完整、标题边界、结构清晰、可执行动作五项。
第五，每次换模型、改 prompt、加工具、放权限，都跑一遍回归集。
第六，定期读 transcript。因为 eval 本身也会错。任务含糊、grader 太死、环境状态污染，都会让评测失真。
如何连接到真实业务
这件事和你的内容生产线很直接。你现在真正需要的不是“稿件好像还行”，而是每个发布包都有证据：来源完整、标题不过界、脚本有结构、视频不露生产痕迹、事实风险明确。
它也和 develop_os 很直接。未来一个 AI 工作台的核心不只是派 Agent 干活，而是给每个任务配门禁：理解 issue、限制改动范围、运行测试、提交证据包、进入人工 review。
它也和智能运维有关。诊断 Agent 可以先给建议，但如果要让它自动执行、自动扩权、自动触发控制动作，就必须在历史事故和边界案例里证明它稳定可靠。
所以这期不是一篇“评测方法论”而已，它其实是在讲 Agent 进入真实业务之前，应该补上的工程地基。
收束
最后给一个判断：Agent 工程化的分水岭，不是有没有更聪明的模型，而是有没有证据证明它稳定、可控、可回滚、值得扩权。
任何 Agent 上线前，都应该回答一个问题：我们用什么 evidence 证明它真的完成了任务，而不是只是在 transcript 里说自己完成了？
如果答不上来，它可以 demo，但还不该上线。
参考资料与延伸阅读
- Anthropic：Demystifying evals for AI agents
- LangChain：Agent trajectory evaluations
- OpenAI：A practical guide to building AI agents
资料核验日期：2026-08-23。