Demystifying Evals for AI Agents（揭开 AI Agent 评测的面纱）
- 原文标题
- Demystifying Evals for AI Agents（揭开 AI Agent 评测的面纱）
- 原文链接
- https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents
- 作者
- Mikaela Grace、Jeremy Hadfield、Rodrigo Olivares、Jiri De Jonghe 等（Anthropic）
- 发布日期
- 2026-01-09
🎯 一句话
评测的作用不是「打个分」，而是让你的改动能被判断是好是坏。⭐ 没有评测，你所有的优化都只是凭感觉换一个说法。
📑 本页目录
评测（evals）是有信心发布 AI Agent 的前提。Agent 的自主性、智能性和灵活性让评测变难，但组合多种评分器类型的系统化测试方法可以度量各类 Agent 的表现。靠手动测试起步的团队终会在规模化时崩盘——尽早投入评测的价值会复利：问题可见、防止回归、明确质量标准、更快升级模型。
基础术语
| 术语 | 含义 |
|---|---|
| Task（任务） | 有定义好的输入和成功标准的单个测试 |
| Trial（试次） | 对任务的一次尝试；模型输出有随机性，需多次试 |
| Grader（评分器） | 为 Agent 表现打分的逻辑；一个任务可有多个 |
| Transcript / Trajectory | 完整记录：输出、工具调用、推理、交互 |
| Outcome（结果） | 试次后环境的最终状态（如订单是否真的存在于数据库） |
| Eval Harness | 端到端基础设施：并发跑任务、记录、评分、聚合 |
一个警示性例子：Opus 4.5 在 τ2-bench 订机票题上找到了政策漏洞——按写死的评测算「失败」，但实际给了用户更优的解——前沿模型的创造性会超出静态评测的假设。
没有评测 vs 有评测
- 没有：等投诉 → 手动复现 → 修 bug → 祈祷别的地方没退化
- 有：发布前自动测试数百个场景
- 长期价值：评测成为产品团队与研究团队之间带宽最高的沟通渠道
案例：Descript 从手动评分演进到人工校准的 LLM 评分器；Claude Code 针对「简洁性、文件编辑、过度工程」建立定向评测；Bolt 在大规模采用后三个月内建成静态分析+浏览器测试+LLM 评审的综合体系。
三类评分器
代码评分器
字符串匹配、二元测试（fail-to-pass）、静态分析、结果校验、工具调用校验、转录分析。 优点： 快、便宜、客观、可复现。缺点： 对合理变体脆弱、缺乏细腻度。
模型评分器（LLM-as-judge）
Rubric 打分、自然语言断言、两两比较、参照对比、多评委共识。 优点： 灵活、可扩展、能处理开放式输出。缺点： 非确定性、更贵、需要对照人类专家校准。
人工评分器
专家审查、众包、抽检、A/B 测试。 优点： 金标准，用于校准模型评分器。缺点： 贵、慢。
两类评测与生命周期
- 能力评测（Capability）： 「Agent 能做好什么？」起始通过率低，作为改进目标
- 回归评测（Regression）： 「以前会的还会吗？」维持接近 100% 通过率
- 能力评测饱和后「毕业」转入回归套件持续运行
按 Agent 类型的评测策略
- 编码 Agent： 天然适合确定性评分（测试通过与否）。SWE-bench Verified 一年内从 40% 提到 80%+；实践中多用「单元测试管正确性 + LLM rubric 管质量」的组合
- 对话 Agent： 交互质量本身就是评测对象；常需要第二个 LLM 模拟用户（τ-Bench 模式）；多维成功标准——工单解决（状态检查）+ 轮次效率（转录约束）+ 语气（LLM rubric）
- 研究 Agent： 专家意见不一、真相持续变动、长输出错误面大。组合评分：论断有据（groundedness）、要点覆盖、来源质量、客观题精确匹配；LLM rubric 必须频繁对照专家校准
- 计算机使用 Agent： 通过界面交互（截图/点击/键盘）；WebArena、OSWorld 用 URL/页面状态/文件系统检查评分；DOM 交互快但耗 token，截图交互慢但省 token
一致性度量：pass@k 与 pass^k
- pass@k： k 次尝试至少一次成功的概率——随 k 上升（适合「一次成功就够」的工具）
- pass^k： k 次全部成功的概率——随 k 下降（适合要求稳定一致的面向客户 Agent；单次 75% 成功率下 pass^3 ≈ 42%）
从零到可信评测的八步路线图
- 尽早开始： 从真实失败中取 20-50 个简单任务即可，不必等几百个。「评测越晚建越难建——早期产品需求能自然转化为测试用例」
- 把手动测试自动化： 从每次发布前人工核对的行为和常见用户任务入手；bug 单和客服队列是任务来源
- 写无歧义的任务 + 参考解： 两位独立专家应得出相同的通过/失败判定；「多次试验 0% 通过率往往说明任务坏了而不是 Agent 不行」；参考解用于证明任务可解、评分器配置正确
- 平衡的问题集： 正反两个方向都要测（该做的和不该做的）；类别要均衡——Claude.ai 搜索评测在「该搜没搜」与「不该搜乱搜」之间反复调平衡
- 稳健的 harness 与干净环境： 评测中的 Agent 要与生产一致；每次试验从干净状态开始；防止「作弊」（如翻 git 历史找答案）
- 深思熟虑的评分器： 评产出而非路径——不要检查特定工具调用顺序；支持部分得分；LLM 评委要结构化 rubric、分维度打分、定期人工校验
- 读转录： 「不读大量试验的转录和评分，你不会知道评分器是否真的在工作」——投资转录查看工具
- 监控饱和与长期维护： 评测饱和后失去改进信号（SWE-bench Verified 年初 30% → 前沿模型 80%+）；专职团队管基础设施、领域专家和产品团队贡献任务；可实践「评测驱动开发」——先建低通过率的能力评测再驱动改进
评测在整体质量体系中的位置（瑞士奶酪模型）
| 方法 | 强项 | 弱项 |
|---|---|---|
| 自动化评测 | 快速迭代、可复现、每次提交都能跑 | 前期投入、维护成本、与真实用法脱节的虚假信心 |
| 生产监控 | 真实用户行为、抓意外问题 | 被动、信号噪杂 |
| A/B 测试 | 度量真实用户结果 | 慢、只能测已部署的变体 |
| 用户反馈 | 暴露未预料的问题 | 稀疏自选样本、偏向严重问题 |
| 人工转录审查 | 建立失败模式直觉 | 不可扩展、覆盖不一致 |
| 系统性人类研究 | 金标准、校准 LLM 评分器 | 贵、慢 |
没有单层能拦住所有问题；多层组合互补。
结论
评测要当作核心组件而非事后补丁：从小而真实的任务集开始、持续读转录、像迭代产品一样迭代评测质量。「AI Agent 评测仍是一个新兴的快速演化领域」——任务更长、多 Agent 协作、更主观的工作都将要求技术持续适应。
（附录还调研了 Harbor、Braintrust、LangSmith、Langfuse、Arize Phoenix 等评测框架——框架加速进度，但代替不了高质量的任务和评分器。）
✅ 检查点
- 评测最核心的作用是什么？
- 从零开始该怎么建评测集？
- 为什么小而准的评测集好过大而糙的？
👀 答案
- ⭐ 提供一把尺子，让改动的效果可以被判断。没有它，你无法区分「这次真的变好了」和「这次运气好」，迭代就退化成了随机游走。
- ①从真实失败案例开始收集——每次线上出问题就沉淀成一条用例，这是最高质量的来源；②20~50 条就能开始用，不必等攒够几百条；③覆盖不同失败模式而不是同一类的变体；④每条要有明确的期望输出或验收标准。
- 因为评测集本身也会有噪声。一个标注粗糙的大评测集，分数波动主要来自标注错误而不是模型差异，你会被误导。⭐ 而小而准的集合虽然覆盖有限，但每次分数变化都是可信的——可信的信号比全面的噪声有用得多。
🛑 可以停在这里
⚡ 走神救援
⭐评测的作用不是「打个分」，是让你的改动能被判断是好是坏——没有评测，所有优化都只是凭感觉换一个说法，迭代退化成随机游走。从零建评测集四步：①从真实失败案例开始收集（每次线上出问题就沉淀成一条用例，最高质量的来源）②20~50 条就能开始用，不必等攒够几百条③覆盖不同失败模式而非同一类的变体④每条要有明确期望输出或验收标准。⭐⭐小而准好过大而糙：标注粗糙的大评测集，分数波动主要来自标注错误而非模型差异，会误导你；可信的信号比全面的噪声有用得多。