给 AI agent 做评估：一份去神秘化的实战指南
好的评估（eval）让团队更有底气地把 AI agent 发出去。没有 eval，你很容易陷进「被动救火」的循环：只能等问题在生产环境暴露，然后修一个 bug 又带出另一个。eval 的价值会随 agent 的生命周期滚雪球式累积。
正如我们在《构建高效的 agent》里讲的，agent 是跨很多轮工作的：调工具、改状态、根据中间结果调整下一步。正是这些让 agent 有用的特质——自主、智能、灵活——也让它更难评估。
下面是我们在内部实践、以及和走在 agent 开发最前沿的客户合作中，学到的一套更严谨、更有用的 agent eval 设计方法。
一个 eval 长什么样
一个评估（eval），本质就是给 AI 系统做的一道测试题：给一个输入，再用打分逻辑去衡量它的输出成不成功。这篇我们聚焦自动化 eval——开发过程中不需要真实用户就能跑的那种。
- 单轮 eval 很直白：一个 prompt、一个回复、一段打分逻辑。早期 LLM 主要靠这个。
- 多轮 eval 越来越常见。比如一个编码 agent 拿到工具、一个任务（造一个 MCP 服务器）、一个环境，跑完整个 agent loop（一连串工具调用 + 推理），最后用单元测试去验证「这个 MCP 服务器是不是真的能跑」。
agent 的 eval 还要更复杂：agent 跨很多轮用工具、改环境状态、边走边调整——错误会传播、会累积放大。而且前沿模型常常能想出超出静态 eval 预设的创造性解法。比如 Opus 4.5 在 τ2-bench 一道订机票的题里，钻了政策的一个空子——按题面判它「没通过」，但它实际给用户找到了更好的方案。
我们用这套词汇来谈 agent eval：
| 术语 | 含义 |
|---|---|
| task（任务/问题/测试用例） | 一道有明确输入和成功标准的测试 |
| trial（试跑） | 对同一个 task 的一次尝试。模型输出有随机性，所以要多跑几次取稳定结果 |
| grader（打分器） | 给 agent 表现的某个方面打分的逻辑。一个 task 可以有多个 grader，每个 grader 里又有多条断言（assertion） |
| transcript（轨迹/trace） | 一次 trial 的完整记录：输出、工具调用、推理、中间结果，全在内。对 Anthropic API 来说，就是 eval 跑完时完整的 messages 数组 |
| outcome（结果态） | trial 结束时环境的最终状态。订票 agent 嘴上说「已为您订好」不算数——outcome 是数据库里到底有没有这条预订 |
| eval harness（评估框架） | 端到端跑 eval 的基础设施：发指令、给工具、并发跑任务、记录每一步、打分、汇总 |
| agent harness（脚手架） | 让模型能当 agent 用的系统：处理输入、编排工具调用、返回结果。我们评估「一个 agent」时，评的是 harness 和模型一起协作的整体 |
| eval suite（评估套件） | 一组测特定能力/行为的 task 集合，通常共享一个大目标（比如客服套件测退款、取消、升级） |
为什么要建 eval
团队刚开始做 agent 时，靠手测 + 自己天天用（dogfooding）+ 直觉，往往能走得出乎意料地远。这时候搞严格的 eval 甚至显得像是拖慢上线的「额外开销」。
但过了早期原型阶段、agent 进了生产并开始上量，没有 eval 就撑不住了。
临界点 通常是这样来的：用户反馈「改完之后 agent 变笨了」，而团队完全盲飞，除了猜和试没别的办法验证。没有 eval，调试只能是被动的：等投诉 → 手动复现 → 修 bug → 祈祷没把别处搞坏。你没法区分真回归和噪声，没法在上线前自动拿几百个场景跑一遍，也没法量化「到底改好了多少」。
Claude Code 自己就走过这条路：早期靠 Anthropic 员工和外部用户的反馈快速迭代，后来才加 eval——先从「简洁度」「文件编辑」这种窄领域开始，再到「过度工程化」这种复杂行为。
写 eval 在 agent 生命周期的任何阶段都有用：早期，它逼产品团队把「成功到底意味着什么」讲清楚；后期，它帮你守住一致的质量底线。
eval 还决定了你多快能用上新模型。强模型一出，没 eval 的团队要花几周测试，有 eval 的竞争对手几天内就能摸清新模型的长短、调好 prompt、完成升级。
怎么评估 agent
今天大规模部署的 agent 大致有几类：编码 agent、研究 agent、computer use agent、对话 agent。它们能落到各行各业，但评估技法是相通的。你不用从零发明——下面是经过验证的套路，拿去作底子、再往你的领域上扩展即可。
三类打分器
agent eval 通常组合三类 grader，各自负责评 transcript 或 outcome 的一部分。挑对 grader 是 eval 设计的核心功夫。
| 类型 | 方法举例 | 强 | 弱 |
|---|---|---|---|
| 代码型 | 字符串匹配、二元测试（fail-to-pass）、静态分析（lint/type/安全）、结果校验、工具调用校验、轨迹分析（轮数/token） | 快、便宜、客观、可复现、好调试 | 对「合理但不完全匹配预期模式」的变体很脆、缺乏细腻、对主观任务力不从心 |
| 模型型 | 打分量规（rubric）、自然语言断言、两两对比、参考答案对照、多评委共识 | 灵活、可扩展、能捕捉细腻差异、能处理开放式/自由文本输出 | 非确定性、比代码贵、需要拿人类打分来校准 |
| 人工型 | 领域专家评审、众包判断、抽检、A/B 测试、标注者一致性 | 黄金标准、贴近专家用户判断、用来校准模型型 grader | 贵、慢、规模化时往往需要专家 |
每个 task 的总分可以是加权（各 grader 分数合起来过阈值）、二元（全部 grader 必须过）或两者混合。
能力 eval vs 回归 eval
| 类型 | 问的问题 | 期望通过率 |
|---|---|---|
| 能力 eval（capability） | 「这 agent 能做好什么？」 | 起步应该低，专挑它搞不定的题，给团队一座要爬的山 |
| 回归 eval（regression） | 「以前会做的，现在还会做吗？」 | 应该接近 100%，分数一掉就说明有东西坏了 |
一个 agent 上线、优化稳定后，通过率很高的能力 eval 可以「毕业」转成回归套件持续跑。当年问「我们能不能做到」的题，现在问「我们还能不能稳定做到」。
各类 agent 怎么评（要点）
-
编码 agent：软件天然好评——代码跑不跑、测试过不过。SWE-bench Verified、Terminal-Bench 都走这条确定性路线。拿到 pass/fail 测试后，再补一个 LLM rubric 评整体代码质量通常很值。实践中：单元测试管正确性 + 一个 LLM rubric 管质量，其余按需再加。
-
对话 agent（客服、销售、教练）：和传统聊天机器人不同，它会维护状态、用工具、对话中途采取行动。难点在于「交互质量本身就是评估对象」。通常需要第二个 LLM 来扮演用户做多轮压测。成功是多维的：工单解决没（状态检查）？10 轮内搞定没（轨迹约束）？语气得体没（LLM rubric）？参考 τ-Bench / τ2-Bench。
-
研究 agent：不像编码有二元信号，研究质量只能相对任务来判。「全不全面」「来源权不权威」「对不对」都依赖语境。策略是组合 grader：接地性检查（论点有没有来源支撑）、覆盖度检查（好答案必须包含哪些关键事实）、来源质量检查（引的是权威源，还是只是搜出来的第一条）。因为主观性强，LLM rubric 要频繁拿专家判断来校准。
-
computer use agent：像人一样通过截图、鼠标、键盘操作软件。必须在真实或沙箱环境里跑，再检查它有没有达成目标。要注意验证后端状态（订单是不是真下了，而不是「确认页出现了」就算）。浏览器 agent 还要在 token 效率和延迟之间权衡：读 DOM 快但费 token，截图慢但省 token——在 Claude for Chrome 里，我们专门做了 eval 检查 agent 有没有为每个场景选对工具。
⭐ 怎么看待 eval 里的「非确定性」
不管哪类 agent，同一个 task 这次跑过、下次可能就挂。有时我们真正想测的，恰恰是「多大比例的 trial 会成功」。两个指标抓这层细微：
| 指标 | 衡量 | 随 k 变大 | 适用 |
|---|---|---|---|
| pass@k | k 次尝试里至少一次对的概率 | 上升（射门越多越可能进一个） | 一次成功就够的场景 |
| pass^k | k 次全部成功的概率 | 下降（要求次次一致更难） | 面向用户、每次都得靠谱的 agent |
举例：单次成功率 75%，跑 3 次，全过的概率是 0.75³ ≈ 42%。在 k=1 时两者相等；到 k=10 它们讲的是相反的故事——pass@k 逼近 100%，pass^k 跌向 0%。用哪个，看产品要求。
从 0 到 1：搭出可信 eval 的八步路线图
收集初始数据集
第 0 步：尽早开始。 很多团队以为要几百个 task 才能动手——其实从真实失败里抽 20~50 个简单 task 就是很好的起点。早期每改一处影响都很明显，效应量大，小样本就够。等得越久越难建：早期产品需求天然能翻译成测试用例，拖太久你就得从一个活系统里反推成功标准了。
第 1 步：从你已经在手测的东西开始。 发版前你会验的那些行为、用户常试的常见任务。已经上生产了？翻 bug tracker 和工单队列，把用户报的失败转成测试用例。
第 2 步：写无歧义、带参考解的 task。 好 task 的标准是「两个领域专家会独立给出同样的过/不过判断」。任务规格里的歧义，会变成指标里的噪声。⭐ 用前沿模型时，多次跑都 0% 通过（0% pass@100）往往不是模型不行，而是 task 写坏了——该回去检查任务描述和 grader 了。给每个 task 配一个参考解（已知能过所有 grader 的答案），证明题可解、且 grader 配对了。
第 3 步：构造平衡的题集。 既测「该发生」的情况，也测「不该发生」的情况。单边 eval 导致单边优化——只测「该搜的时候搜没搜」，最后会养出一个「啥都要搜一遍」的 agent。我们给 Claude.ai 的网页搜索做 eval 时就踩过：既要它该搜时搜（查天气），又要它能从已有知识直接答（「谁创立了苹果」），平衡触发不足和过度触发，花了好多轮才调好。
设计框架与打分器
第 4 步：搭一个稳的 harness + 干净的环境。 eval 里的 agent 必须和生产里的基本一致，环境本身别引入额外噪声。每次 trial 都要从干净环境起，隔离开。残留文件、缓存数据、资源耗尽都会造成「相关性失败」——看着像模型差，其实是基础设施抖动。我们就发现过 Claude 靠翻前几次 trial 留下的 git history 在某些题上占了不公平的便宜。
第 5 步：用心设计 grader。 能用确定性 grader 就用，需要灵活性时用 LLM grader，人工 grader 审慎地用于额外验证。有个常见冲动是去检查「agent 有没有按特定顺序调用一串工具」——这太死板、太脆，agent 经常找到设计者没料到的合理路径。评它产出了什么，别评它走了哪条路。 多组件任务要给部分分（partial credit）：一个客服 agent 正确识别了问题、验证了客户、但退款没成，明显比一上来就崩的强。LLM-as-judge 要和专家紧密校准；为防幻觉，给它一条退路（信息不足就返回「Unknown」）；最好把任务拆成结构化维度、每个维度用独立的 LLM 单独评。
⚠️ 有些 eval 有隐蔽的失败模式：明明 agent 表现不错，却因为打分 bug、脚手架约束、题目歧义得了低分。Opus 4.5 在 CORE-Bench 上一开始只有 42%，研究员一查发现：死板打分把「96.12」判错（期望「96.124991…」）、题目有歧义、还有无法精确复现的随机任务——修完 bug、换上约束更少的脚手架后，分数跳到 95%。
让 grader 抗作弊：通过 task 必须是真解出了问题，而不是钻了非预期的空子。
长期维护并使用
第 6 步：去读 transcript！ 不读多次 trial 的轨迹和打分，你根本不知道 grader 好不好使。task 失败时，transcript 告诉你是agent 真错了，还是你的 grader 把合理解给毙了。「失败要显得公平」——一眼看出 agent 错在哪、为什么错。这是 agent 开发的关键技能。
第 7 步：盯着能力 eval 的「饱和」。 100% 的 eval 只能查回归、给不了改进信号。SWE-Bench Verified 今年从 30% 一路爬到 >80%，逼近饱和——越接近饱和，大的能力提升会显示成很小的分数变化，结果容易骗人。代码审查公司 Qodo 一开始没看出 Opus 4.5 的进步，因为他们的一次性编码 eval 抓不到长任务上的增益；后来他们做了新的 agentic eval 框架，进步才清晰显现。没人深挖细节、没人读 transcript 之前，我们不会把 eval 分数当真。
第 8 步：把 eval 套件当活的资产长期养。 Anthropic 试下来最有效的是：专门的 eval 团队拥有核心基础设施，领域专家和产品团队贡献大部分 task 并自己跑。对产品团队来说，「拥有并迭代 eval」应该像维护单元测试一样日常。我们推荐 eval 驱动开发：先建 eval 定义「计划中、但 agent 还做不到」的能力，再迭代到它能做好——能力 eval 起步低正好让这件事可见，新模型一来跑一遍就知道哪些押注兑现了。
eval 和其他方法怎么配合
自动化 eval 能在几千个 task 上跑而不碰真实用户，但它只是理解 agent 表现的众多手段之一。完整图景还包括：生产监控、用户反馈、A/B 测试、人工读 transcript、系统化人类研究。
像安全工程里的「瑞士奶酪模型」：没有任何单独一层能抓住所有问题，多层叠起来，漏过一层的失败会被另一层接住。
最有效的团队会组合使用：自动化 eval 做快速迭代、生产监控提供 ground truth、定期人工评审做校准。
总结
没有 eval 的团队陷在被动循环里——修一个、坏一个，分不清真回归和噪声。早投入的团队则相反：失败变成测试用例，测试用例挡住回归，指标取代猜测，「agent 好像变差了」变成可执行的东西。
模式因 agent 类型而异，但根本原则恒定：尽早开始，别等完美套件；从你真实见到的失败里取材；定义无歧义、抗作弊的成功标准;用心设计并组合多类 grader;确保题目对模型足够难;不断迭代提升信噪比;去读 transcript！
AI agent 评估还是个年轻、快速演进的领域。随着 agent 接手更长的任务、在多 agent 系统里协作、处理越来越主观的工作，我们的技法也要跟着进化。