揭开 AI Agent 评测的神秘面纱

引言

高质量的评测可以帮助团队更有信心地发布 AI Agent。没有评测，团队很容易陷入一种被动循环：问题只有到了生产环境才暴露出来，而修复一个故障又可能引入新的故障。评测能够在问题影响真实用户之前，让系统中的缺陷和行为变化变得可见，而且随着 Agent 生命周期不断延长，它的价值会持续累积。

正如我们在《构建高效 AI Agent》中所描述的那样，Agent 往往需要跨越许多轮交互运行：调用工具、修改环境状态，并根据中间结果不断调整行为。正是这些让 Agent 变得有用的能力——自主性、智能和灵活性——也让它们更难评测。

通过 Anthropic 内部的实践，以及我们与 Agent 开发前沿客户的合作，我们逐渐总结出一套更加严格、更加实用的 Agent 评测方法。本文介绍这些方法在不同 Agent 架构和真实部署场景中的实践经验。

一个评测由什么组成

评测（evaluation，简称 eval），本质上就是针对 AI 系统的一次测试：向 AI 提供一个输入，然后使用评分逻辑判断输出是否成功。本文主要讨论能够在开发阶段、不依赖真实用户即可运行的自动化评测。

单轮评测相对简单：一个提示词、一个回答，再加一套评分逻辑。对于早期 LLM 来说，单轮、非 Agent 式评测曾经是最主要的评测方式。随着 AI 能力增强，多轮评测变得越来越常见。

在一个简单评测中，Agent 处理一条提示词，grader 判断它的输出是否符合预期。更复杂的多轮评测中，例如评测一个编码 Agent 构建 MCP Server 的能力，Agent 会获得工具、任务和执行环境，并通过持续的 Agent Loop，也就是工具调用和推理，修改环境并完成实现。最后，评测系统再使用单元测试验证这个 MCP Server 是否真正可用。

Agent 评测还要更加复杂。Agent 会在许多轮交互中持续使用工具、修改环境状态并根据结果自适应，因此一次早期错误可能向后传播并不断放大。前沿模型甚至可能发现超出静态评测预期的创造性解法。

例如，Opus 4.5 曾经在一个 𝜏2-bench 航班预订问题中发现政策漏洞。按照原本的评测标准，它“失败”了，但从用户角度看，它实际上找到了一个更好的解决方案。

在构建 Agent 评测时，我们使用以下几个术语：

• 任务（task），也可以称作 problem 或 test case，是一次具有明确输入与成功标准的测试。

• 试验（trial），是对某个任务的一次独立尝试。由于模型每次运行的输出并不完全一致，我们通常会对同一个任务运行多次试验，以获得更稳定的结果。

• 评分器（grader），是用于评估 Agent 某一方面表现的逻辑。一个任务可以包含多个 grader，而每个 grader 又可以包含多个 assertion，也就是检查项。

• 执行记录（transcript），也称 trace 或 trajectory，是一次试验的完整记录，包括模型输出、工具调用、推理、中间结果，以及所有其他交互。对于 Anthropic API，这相当于评测结束时完整的 messages 数组，其中包含评测过程中所有 API 调用和返回结果。

• 最终结果（outcome），是试验结束时环境中的真实最终状态。举例来说，一个航班预订 Agent 可能在 transcript 末尾说“您的航班已经预订成功”，但真正的 outcome 是环境中的 SQL 数据库里是否真的存在一条有效预订记录。

• 评测 Harness（evaluation harness），是负责端到端运行评测的基础设施。它提供任务指令和工具，并发运行任务，记录全部步骤，执行评分并聚合结果。

• Agent Harness，也称 scaffold，是让模型能够作为 Agent 行动的系统。它负责处理输入、编排工具调用并返回结果。因此，当我们说“评测一个 Agent”时，真正评测的是 Harness 与模型的组合。Claude Code 就是一个灵活的 Agent Harness，我们此前也曾使用 Agent SDK 中的核心原语构建长时间运行 Agent Harness。

• 评测套件（evaluation suite），是一组用于衡量特定能力或行为的任务。这些任务通常围绕一个共同目标组织。例如，一个客服 Agent 的评测套件可能包含退款、取消订单和升级人工处理等任务。

以上这些组件共同构成了完整的 Agent 评测体系。

为什么要构建评测

团队刚开始构建 Agent 时，仅仅依靠人工测试、内部实际使用和直觉，就可能推进得相当远。更严格的评测甚至可能看起来像一种额外负担，会拖慢发布速度。

但经过早期原型阶段，Agent 一旦进入生产环境并开始扩大使用规模，没有评测的开发方式就会逐渐失效。

通常，真正的转折点出现在用户开始反馈：

Agent 更新之后好像反而变差了。

此时团队却没有可靠手段验证到底发生了什么，只能靠猜测和反复试验。

如果没有评测，调试流程通常会变成：

1. 等待用户投诉；

2. 人工复现问题；

3. 修复 Bug；

4. 祈祷没有造成其他回归。

团队无法区分真实回归和随机噪声，也无法在发布前自动用数百种场景验证修改，更无法量化判断系统究竟有没有进步。

我们已经多次看到这种发展过程。

Claude Code 在早期就是依靠 Anthropic 员工和外部用户的反馈快速迭代。之后我们逐步加入评测：最开始只覆盖简洁程度、文件编辑等较窄的领域，后来进一步覆盖“过度工程化”等复杂行为。

这些评测帮助我们：

• 发现问题；

• 指导改进方向；

• 让研究团队和产品团队更集中地围绕同一目标协作。

与生产监控、A/B 测试、用户研究等方法结合后，评测为 Claude Code 的持续改进提供了稳定信号。

在 Agent 生命周期的任何阶段编写评测都有价值。

早期，评测会迫使产品团队明确：

对这个 Agent 来说，什么才叫成功？

而在更成熟阶段，它能够帮助团队长期维持统一的质量标准。

Descript 的 Agent 用于帮助用户编辑视频，因此他们把一个成功的视频编辑工作流拆成三个维度：

• 不要把东西弄坏；

• 完成我要求的事情；

• 而且要完成得好。

他们最初使用人工评分，后来逐渐转向由产品团队制定标准的 LLM grader，并定期通过人工重新校准。现在，他们会定期运行两套独立评测：一套用于质量 Benchmark，一套用于回归测试。

Bolt AI 团队则是在产品已经广泛使用之后才开始构建评测。三个月内，他们搭建了一套系统，可以运行自己的 Agent，并使用静态分析为输出评分，使用浏览器 Agent 测试应用，同时使用 LLM Judge 判断指令遵循等行为。

有的团队从开发第一天就建立评测；有的则等产品规模扩大、缺乏评测已经开始阻碍迭代时才加入。

不过，在 Agent 开发早期，评测尤其有价值，因为它能够显式编码预期行为。

两位工程师读到同一份产品规格时，很可能会对某些边缘情况应该如何处理产生不同理解。评测套件能够消除这种歧义。

无论从什么时候开始，评测最终都会帮助开发提速。

评测还会直接影响团队采用新模型的速度。

当更强的新模型发布时，没有评测的团队可能需要几周进行人工验证；而已经拥有评测体系的团队，可以迅速判断：

• 新模型擅长什么；

• 哪些提示词需要调整；

• 是否适合升级。

因此，他们可能在几天内就完成迁移。

一旦评测体系建立起来，很多东西都会顺带获得：

• 性能基线；

• 回归测试；

• 延迟统计；

• Token 用量；

• 单任务成本；

• 错误率。

这些指标都可以在一组静态任务上长期追踪。

评测还可能成为产品团队和研究团队之间最高带宽的沟通渠道，因为它把“希望模型做得更好”变成了研究人员真正能够优化的具体指标。

因此，评测的价值远不只是检测回归或衡量提升。

它的成本通常在一开始非常明显，而收益却随着时间逐渐累积，所以这种复利效应往往很容易被低估。

如何评测 AI Agent

目前大规模部署的 Agent 常见类型包括：

• 编码 Agent；

• Research Agent；

• Computer Use Agent；

• 对话 Agent。

虽然它们可能应用在完全不同的行业，但很多评测技术是共通的。

因此，你通常不需要从零发明一套评测体系。下面介绍几类已经被实践验证的方法，可以先把它们作为基础，再根据自己的领域进行扩展。

Agent 中常见的 grader 类型

Agent 评测通常会组合三类 grader：

• 基于代码的 grader；

• 基于模型的 grader；

• 人工 grader。

每个 grader 可以评价 transcript 的某些部分，也可以直接评价最终 outcome。

设计高质量评测时，一个最重要的问题就是：

当前任务究竟应该使用哪种 grader？

基于代码的 grader

常用方法：

• 字符串匹配，包括精确匹配、正则、模糊匹配等；

• 二元测试，例如 fail-to-pass 和 pass-to-pass；

• 静态分析，例如 lint、类型检查、安全扫描；

• 最终状态验证；

• 工具调用验证，包括用了什么工具、传了什么参数；

• transcript 分析，例如交互轮数、Token 用量。

优点：

• 快；

• 便宜；

• 客观；

• 可复现；

• 容易调试；

• 可以精确验证具体条件。

缺点：

• 对正确但形式不同的答案比较脆弱；

• 缺乏细腻判断；

• 不适合一些主观任务。

基于模型的 grader

常用方法：

• Rubric 打分；

• 自然语言 assertion；

• 两两比较；

• 基于参考答案的评价；

• 多 Judge 共识。

优点：

• 灵活；

• 易扩展；

• 能捕捉细节差异；

• 可以处理开放式任务；

• 可以处理自由文本输出。

缺点：

• 非确定性；

• 成本高于纯代码检查；

• 必须使用人工评分进行校准，才能确保可靠性。

人工 grader

常用方法：

• 领域专家审核；

• 众包判断；

• 抽样检查；

• A/B 测试；

• 标注者一致性分析。

优点：

• 通常代表最高质量标准；

• 更贴近专家用户真正的判断；

• 可以用于校准模型 grader。

缺点：

• 昂贵；

• 缓慢；

• 在专业领域中很难大规模获得足够专家。

每个任务的总评分还可以采用不同聚合方式：

• 加权评分：多个 grader 的综合分数达到某个阈值；

• 二元评分：所有 grader 都必须通过；

• 混合方式：组合以上两种模式。

能力评测与回归评测

能力评测（capability eval），也可以称为质量评测，关注的问题是：

这个 Agent 能把什么事情做好？

这种评测一开始的通过率通常应该比较低，因为它应该专门针对 Agent 当前还不擅长的任务，为团队提供一个明确的“爬坡目标”。

**回归评测（regression eval）**关注的是：

这个 Agent 还能不能继续做好以前已经会做的事情？

这种评测理想情况下应该接近 100% 通过率。

如果分数下降，就说明某处出现了回退，需要修复。

团队在不断优化能力评测时，也应该持续运行回归评测，防止为了改善一个领域却破坏了另一个领域。

随着 Agent 发布并不断优化，一些原本通过率较低的能力评测会逐渐接近饱和。

此时，它们可以“毕业”为回归测试。

原本的问题是：

我们到底能不能做到这件事？

之后就会变成：

我们还能不能持续、可靠地做到这件事？

评测编码 Agent

编码 Agent会像人类开发者一样：

• 编写代码；

• 测试代码；

• Debug；

• 浏览代码库；

• 执行命令。

对于现代编码 Agent 来说，高质量评测通常依赖：

• 明确的任务定义；

• 稳定的测试环境；

• 针对生成代码的充分测试。

编码任务天然适合确定性 grader，因为软件相对容易验证：

• 代码能不能运行？

• 测试能不能通过？

两个被广泛使用的 Coding Agent Benchmark——SWE-bench Verified 和 Terminal-Bench——都采用了这种方式。

SWE-bench Verified 会把流行 Python Repository 中真实存在的 GitHub Issue 交给 Agent，再通过运行测试套件评价解决方案。只有当 Agent 修复了原本失败的测试，同时没有破坏已有测试，任务才算通过。

LLM 在这一评测上的成绩，仅一年时间就从约 40% 提升到了 80% 以上。

Terminal-Bench 则采用另一种方向：评测完整的端到端技术任务，例如：

• 从源码构建 Linux Kernel；

• 训练一个机器学习模型。

一旦已经拥有用于判断关键 outcome 的 pass/fail 测试，通常还值得继续评价 transcript。

例如：

• 使用启发式代码质量规则评价生成代码，而不仅仅判断测试能否通过；

• 使用带有明确 Rubric 的模型 grader，评价 Agent 如何调用工具、如何与用户交互。

示例：编码 Agent 的理论评测

假设有一个编码任务：

Agent 需要修复一个“密码字段为空时可以绕过认证”的漏洞。

可以通过类似下面的 YAML 同时定义 grader 和指标：

task:
  id: "fix-auth-bypass_1"
  desc: "修复密码字段为空时的认证绕过问题，并……"
  graders:
    - type: deterministic_tests
      required: [test_empty_pw_rejected.py, test_null_pw_rejected.py]

    - type: llm_rubric
      rubric: prompts/code_quality.md

    - type: static_analysis
      commands: [ruff, mypy, bandit]

    - type: state_check
      expect:
        security_logs: {event_type: "auth_blocked"}

    - type: tool_calls
      required:
        - {tool: read_file, params: {path: "src/auth/*"}}
        - {tool: edit_file}
        - {tool: run_tests}

  tracked_metrics:
    - type: transcript
      metrics:
        - n_turns
        - n_toolcalls
        - n_total_tokens

    - type: latency
      metrics:
        - time_to_first_token
        - output_tokens_per_sec
        - time_to_last_token

这个例子为了说明概念，刻意展示了多种可用 grader。

真实编码评测通常主要依赖：

• 单元测试验证正确性；

• LLM Rubric 评价整体代码质量。

只有在确实需要时，再加入额外 grader 和指标。

评测对话 Agent

对话 Agent会在客服、销售、辅导等领域与用户交互。

它们不同于传统聊天机器人，因为它们通常会：

• 保持状态；

• 调用工具；

• 在对话过程中真正采取行动。

编码 Agent 和 Research Agent 当然也可能与用户进行多轮交互，但对话 Agent 有一个特别的挑战：

交互本身的质量就是评测目标的一部分。

有效的对话 Agent 评测，通常会同时依赖：

• 可验证的最终环境状态；

• 对任务完成质量和交互质量进行评分的 Rubric。

与其他很多评测不同，对话 Agent 评测还经常需要使用第二个 LLM 来模拟用户。

我们在 Alignment Auditing Agent 中就使用这种方法，通过长时间、对抗性的对话对模型进行压力测试。

对话 Agent 的成功往往是多维度的。

例如：

• 工单最终是否真的被解决？——State Check

• 是否在 10 轮以内完成？——Transcript Constraint

• 语气是否合适？——LLM Rubric

𝜏-Bench 及其后继 τ2-Bench 就体现了这种多维评测方式。

这些 Benchmark 会模拟零售客服、航班预订等多轮交互场景，其中一个模型扮演用户角色，而被评测的 Agent 则处理真实感较强的任务。

示例：对话 Agent 的理论评测

假设一个客服 Agent 需要为一位情绪不满的客户处理退款：

graders:
  - type: llm_rubric
    rubric: prompts/support_quality.md
    assertions:
      - "Agent 对客户的挫败感表现出了共情"
      - "清楚解释了解决方案"
      - "Agent 的回答基于 fetch_policy 工具返回的政策"

  - type: state_check
    expect:
      tickets: {status: resolved}
      refunds: {status: processed}

  - type: tool_calls
    required:
      - {tool: verify_identity}
      - {tool: process_refund, params: {amount: "<=100"}}
      - {tool: send_confirmation}

  - type: transcript
    max_turns: 10

tracked_metrics:
  - type: transcript
    metrics:
      - n_turns
      - n_toolcalls
      - n_total_tokens

  - type: latency
    metrics:
      - time_to_first_token
      - output_tokens_per_sec
      - time_to_last_token

和编码 Agent 示例一样，这里为了说明不同 grader 类型，展示得比较完整。

实际的对话 Agent 评测通常更依赖模型 grader，因为很多任务，例如回答问题，可能存在多种同样正确的解决方式。

评测 Research Agent

Research Agent负责：

• 收集信息；

• 综合信息；

• 分析信息；

• 最终生成回答或报告。

与可以依赖单元测试提供二元 pass/fail 信号的 Coding Agent 不同，研究质量只能相对任务本身来判断。

所谓：

• 全面；

• 来源充分；

• 正确；

这些标准具体意味着什么，会随着使用场景变化。

一次市场扫描、一次收购尽调和一篇科学研究报告，显然需要完全不同的评价标准。

Research Eval 还面临一些独特挑战：

• 专家之间可能对“是否全面”存在分歧；

• 参考内容会持续变化，因此 ground truth 也会变化；

• 输出更长、更开放，也意味着产生错误的空间更大。

例如 BrowseComp 就用于测试 AI Agent 是否能够在开放网络中寻找“藏在草堆里的针”。

它的问题被刻意设计成：

• 很难找到；

• 但一旦找到就容易验证。

构建 Research Agent 评测的一种有效策略，是组合多种 grader：

• Groundedness Check：确认结论是否有检索来源支持；

• Coverage Check：定义一个优秀回答必须包含哪些关键信息；

• Source Quality Check：判断 Agent 使用的是权威来源，而不是搜索结果中最先出现的内容。

对于存在客观答案的问题，例如：

X 公司第三季度营收是多少？

可以直接使用 Exact Match。

LLM grader 则可以进一步检查：

• 有没有无来源支持的观点；

• 是否存在重要遗漏；

• 开放式综合是否连贯、完整。

由于研究质量本身具有主观性，LLM Rubric 应该经常使用领域专家的人工判断进行校准。

评测 Computer Use Agent

Computer Use Agent不是通过 API 或代码执行，而是像人类一样使用软件界面：

• 看截图；

• 点击鼠标；

• 输入键盘；

• 滚动页面。

因此，它理论上可以操作任何拥有 GUI 的应用，包括：

• 设计工具；

• 老旧企业软件；

• 浏览器应用。

要评测这种 Agent，必须让它在真实或沙箱环境中操作软件，然后检查它是否真正达成了目标。

例如 WebArena 会测试浏览器任务，并通过：

• URL；

• 页面状态；

• 后端状态；

来判断 Agent 是否正确完成操作。

如果任务会修改数据，还需要直接检查后台状态。

例如购买商品时，不能只因为界面显示了“下单成功”就认为任务完成，而应该确认订单真的存在。

OSWorld 将这一方法扩展到了完整操作系统控制。

评测脚本会在任务结束后检查各种 Artifact，例如：

• 文件系统状态；

• 应用配置；

• 数据库内容；

• UI 元素属性。

浏览器 Agent 还存在 Token 效率与延迟之间的权衡。

基于 DOM 的交互：

• 执行更快；

• 但会消耗更多 Token。

基于截图的交互：

• 速度更慢；

• 但通常更加节省 Token。

例如：

如果让 Claude 总结 Wikipedia 页面，直接从 DOM 中提取文本更有效率。

如果让 Claude 在 Amazon 上寻找一个新的笔记本电脑保护壳，使用截图往往更合适，因为提取整个 DOM 会消耗大量 Token。

在 Claude for Chrome 中，我们专门构建了评测，用来判断 Agent 是否能根据场景选择正确工具。

这让浏览器任务能够更快、更准确地完成。

如何理解 Agent 评测中的非确定性

无论哪一种 Agent，它在不同运行之间的行为都会变化。

因此，Agent 评测结果比表面上看起来更难解释。

每个任务都会有自己的成功率。

例如：

• 一个任务成功率可能是 90%；

• 另一个任务可能只有 50%。

同一个任务在一次评测中通过，下一次却可能失败。

很多时候，我们真正想衡量的是：

Agent 在多次尝试中，有多大比例能够成功？

有两个指标特别适合描述这种情况。

pass@k

pass@k 衡量的是：

在 k 次尝试中，Agent 至少得到一次正确答案的概率。

随着 k 增加，pass@k 会提高。

因为尝试次数越多，至少命中一次的机会越大。

例如：

50% 的 pass@1 意味着模型第一次尝试时，能够成功完成评测集中一半的任务。

在编码任务中，我们通常最关心：

第一次就解决问题的能力，也就是 pass@1。

但在另一些场景中，只要最终有一个候选方案可用，多次提出方案也是合理的。

pass^k

pass^k 衡量的是：

k 次试验全部成功的概率。

随着 k 增加，pass^k 会降低，因为要求所有尝试都成功，会越来越困难。

如果一个 Agent 每次独立试验的成功率是 75%，连续运行三次，那么三次全部成功的概率是：

0.75³ ≈ 42%

这一指标对面向客户的 Agent 尤其重要，因为用户通常希望每次使用时都能获得可靠表现。

当 k=1 时，pass@k 与 pass^k 完全相同。

但随着试验次数增加，两者会向相反方向变化。

例如在 k=10 时：

• pass@k 可能逐渐接近 100%；

• pass^k 却可能逐渐接近 0%。

因此，两种指标都有意义。

应该根据产品需求选择：

• 如果“只要有一次成功就可以”，使用 pass@k；

• 如果“每次都要稳定成功”，使用 pass^k。

从零到一：构建高质量 Agent Eval 的路线图

下面介绍一套经过实际验证的流程，帮助团队从“没有任何 Eval”走到“拥有真正可信的 Eval”。

可以把它理解成一套 Eval-Driven Agent Development 方法：

• 尽早定义成功；

• 清晰地测量成功；

• 持续迭代。

收集初始评测数据集中的任务

第 0 步：尽早开始

我们经常看到团队推迟建立 Eval，因为他们认为：

至少需要几百个任务才有意义。

实际上，从真实失败案例中抽取 20～50 个简单任务，就已经是很好的起点。

Agent 开发早期，每次系统改动通常都会带来非常明显的影响。

由于 Effect Size 很大，小样本就足以观察变化。

随着 Agent 成熟，变化幅度越来越小，确实需要：

• 更多任务；

• 更困难的任务；

才能检测差异。

但在最开始阶段，更适合采用 80/20 原则。

而且，Eval 拖得越晚越难做。

早期产品需求往往可以直接转化成测试用例。

如果等系统上线很久之后再做，就需要反过来从已经运行的产品中推断：

当初“成功”的定义到底是什么？

第 1 步：从你已经在手工测试的内容开始

先把日常开发中本来就在手工检查的东西写成 Eval。

例如：

• 每次发布前都会验证的行为；

• 最常见的用户任务。

如果产品已经上线，可以直接查看：

• Bug Tracker；

• 客服 Support Queue。

把用户真实报告的问题转换成测试用例，可以保证评测套件反映真实使用情况。

再根据问题对用户的影响程度排序，就能把评测资源集中在最重要的地方。

第 2 步：编写无歧义任务，并准备参考解

任务质量比想象中更难做好。

一个好的任务应该满足：

两位领域专家独立阅读后，能够得到相同的 pass/fail 结论。

可以问自己：

如果把这个任务交给领域专家，他们自己能完成吗？

如果连人类专家都不能明确判断，任务本身就需要改写。

任务规格中的歧义会直接变成评测指标里的噪声。

模型 grader 的 Rubric 也是同样道理：模糊标准只会产生不一致评分。

每个任务都应该确保：

一个正确遵循指令的 Agent 理论上能够完成它。

有些问题非常隐蔽。

例如，在审查 Terminal-Bench 时我们发现：

如果一个任务要求 Agent 编写脚本，却没有指定文件路径，而测试代码又默认脚本必须位于某个特定路径，那么 Agent 即使正确完成了用户要求，也可能因为猜错路径而失败。

Grader 检查的一切，都应该从任务描述中明确推导出来。

Agent 不应该因为模糊规格而失败。

对于前沿模型，如果一个任务在大量试验中依然是：

0% pass@100

通常更应该首先怀疑：

• 任务是不是坏了？

• grader 是不是配置错了？

而不是立刻断定：

• Agent 能力不足。

每个任务还应该尽可能准备一个 Reference Solution：

也就是一个已知能够通过全部 grader 的正确解。

这样可以证明：

• 任务确实可解；

• grader 配置确实正确。

第 3 步：构建平衡的问题集

既要测试：

• 某种行为应该发生的时候；

也要测试：

• 某种行为不应该发生的时候。

单边 Eval 会产生单边优化。

例如：

如果你只检查 Agent 在“应该搜索”时有没有搜索，最终可能训练出一个：

几乎什么问题都先搜索的 Agent。

因此，应尽量避免严重类别不平衡的 Eval。

我们在 Claude 网页搜索功能中就亲身遇到过这一问题。

挑战在于：

既要防止模型在不应该搜索时乱搜，

又要保留它在真正需要时进行深度研究的能力。

因此，团队同时建立了两类测试：

应该搜索，例如：

今天的天气怎么样？

不应该搜索，例如：

Apple 是谁创立的？

在：

• Undertriggering：该搜却没搜；

• Overtriggering：不该搜却搜；

之间找到正确平衡非常困难。

我们对提示词和 Eval 都进行了许多轮调整。

随着新的问题不断出现，我们仍然会持续把它们加入评测，以提高覆盖范围。

设计 Eval Harness 和 grader

第 4 步：建立稳定、可靠的 Eval Harness 和执行环境

评测中的 Agent 应该尽可能与生产中的 Agent 保持一致。

同时，执行环境本身不能额外引入噪声。

每一个 Trial 都应该从一个干净环境开始，并彼此隔离。

不同试验之间不必要的共享状态，例如：

• 遗留文件；

• Cache；

• 资源耗尽；

可能导致多个 Trial 同时失败。

此时失败的真正原因是基础设施不稳定，而不是 Agent 能力。

共享状态也可能人为抬高分数。

例如，在 Anthropic 的一些内部 Eval 中，我们曾发现 Claude 会查看前几次 Trial 留下的 Git History，从而在某些任务上获得不公平优势。

如果多个不同 Trial 都因为同一个环境限制而失败，例如：

• CPU Memory 不足；

那么这些试验就不再彼此独立，因为它们受到同一个公共因素影响。

最终 Eval 结果就无法可靠衡量 Agent 能力。

第 5 步：认真设计 grader

如前所述，高质量 Eval 的关键，是为 Agent 和任务选择真正合适的 grader。

我们的建议是：

• 能使用确定性 grader 时，优先使用；

• 需要灵活判断时，再使用 LLM grader；

• 人工 grader 用于重要验证和校准。

很多人会本能地检查 Agent 是否严格按照某一组特定步骤完成任务，例如：

• 必须先调用工具 A；

• 然后调用工具 B；

• 再调用工具 C。

我们的经验是，这种评测通常过于僵硬，也非常脆弱。

Agent 经常会发现设计者完全没有预料到、但同样有效的解决路线。

为了避免惩罚创造力，通常更应该评价：

Agent 最终产出了什么？

而不是：

Agent exactly 是怎么走到这里的？

对于包含多个组成部分的任务，还应该支持部分得分。

例如，一个客服 Agent：

• 正确识别了问题；

• 验证了客户身份；

• 但最终退款操作失败。

它显然比一个一开始就完全失败的 Agent 表现更好。

Eval 应该能够表达这种连续的成功程度。

模型 grader 通常需要多轮调优才能可靠。

LLM-as-a-Judge 应该与人类专家评分仔细校准，确保两者差异足够小。

为了降低幻觉，可以给 Judge 一个“退出选项”。

例如明确规定：

如果信息不足，请返回 Unknown。

还可以：

• 为任务不同维度设计清晰的结构化 Rubric；

• 每个维度由独立 LLM Judge 评分；

而不是让一个 Judge 一次判断所有维度。

当整套机制稳定后，人工审核就只需要偶尔执行即可。

有些 Eval 会因为一些非常隐蔽的问题得到很低分，即使 Agent 实际表现并不差。

可能原因包括：

• grader Bug；

• Agent Harness 限制；

• 任务定义歧义。

即使成熟团队也可能踩坑。

例如，Opus 4.5 最初在 CORE-Bench 上只有 42%。

后来 Anthropic 研究人员发现多个问题：

• 预期答案是 96.124991… 时，回答 96.12 会被僵硬 grader 判错；

• 一些任务描述存在歧义；

• 部分随机性任务本身无法精确复现。

修复这些问题并使用限制更少的 Scaffold 后，Opus 4.5 的得分直接上升到了 95%。

METR 也曾在其 Time Horizon Benchmark 中发现多个错误配置任务。

这些任务要求 Agent：

优化到某个指定分数阈值。

但真正评分时，却要求结果：

必须超过这个阈值。

于是，像 Claude 这样严格遵循指令的模型反而被惩罚，而忽略任务目标的模型可能拿到更高分。

因此，一定要仔细检查：

• Task；

• grader。

此外，grader 还应该尽量抵抗绕过和作弊。

Agent 不应该通过利用意外漏洞就轻易通过 Eval。

真正的通过条件应该是：

确实解决了问题。

而不是：

找到了评测系统的漏洞。

长期维护和使用 Eval

第 6 步：阅读 Transcript

如果你从来不读 Transcript 和 grader 输出，就很难知道自己的评测到底好不好。

Anthropic 专门投入了工程资源建设用于查看 Eval Transcript 的工具，而且我们会定期真正去阅读这些记录。

当一个任务失败时，Transcript 可以告诉你：

• Agent 是否真的犯错；

• 还是 grader 错误拒绝了一个有效解。

它还经常暴露很多 Agent 和 Eval 行为上的关键细节。

失败应该让人觉得：

这个判定是公平的。

你应该能够清楚解释：

• Agent 哪里错了；

• 为什么错。

如果分数一直无法提高，我们需要有信心判断：

真正限制成绩的是 Agent 本身，而不是 Eval 的问题。

阅读 Transcript，是确认 Eval 是否真的在衡量重要内容的核心手段之一。

它也是 Agent 开发中的一项关键技能。

第 7 步：监控能力 Eval 是否饱和

如果一个 Eval 已经达到 100%，它仍然可以追踪回归，但已经无法继续提供改进方向。

Eval Saturation 指的是：

Agent 已经通过了其中所有可解任务，没有进一步提升空间。

例如，SWE-Bench Verified 的分数今年早期大约还在 30%，而前沿模型如今已经逐渐接近 80% 以上的饱和区。

随着 Eval 越来越接近饱和：

• 剩下的任务只会越来越难；

• 进步速度也会看起来越来越慢。

这可能产生误导。

模型实际能力发生了很大提升，最终分数却只增加一点点。

例如，代码审查创业公司 Qodo 最初对 Opus 4.5 并不特别满意，因为他们原来的 One-shot Coding Eval 没有捕捉到模型在：

• 更长任务；

• 更复杂任务；

上的提升。

于是，他们开发了新的 Agentic Eval Framework，之后才更加清楚地看到模型真实进步。

我们的原则是：

在有人真正检查 Eval 细节并阅读一部分 Transcript 之前，不会直接把一个 Eval 分数当成真相。

如果发现：

• grader 不公平；

• 任务含糊；

• 有效方案被惩罚；

• Harness 限制了模型能力；

那么应该修改 Eval。

第 8 步：通过开放贡献和持续维护，让 Eval Suite 长期健康

Eval Suite 是一个活的 Artifact。

要想长期有用，它必须持续维护，并且拥有明确 Owner。

Anthropic 尝试过很多不同的 Eval 维护模式。

最终效果最好的是：

• 由专门的 Eval 团队负责核心基础设施；

• 由领域专家和产品团队贡献大多数具体任务，并自己运行评测。

对于 AI 产品团队来说，维护和迭代 Eval 应该像维护 Unit Test 一样日常。

团队可能会在一个 AI 功能上浪费数周，因为它在早期看起来“可以工作”，但实际上没有达到那些从未被明确写出来的预期。

如果一开始就设计好 Eval，这些问题往往会更早暴露。

因此，定义 Eval Task 本身就是一种非常好的产品需求压力测试：

我们现在对这个产品的成功标准定义得够不够具体，已经适合开始开发了吗？

我们推荐采用 Eval-Driven Development：

1. 在 Agent 还无法实现某种能力之前，先通过 Eval 定义它；

2. 然后持续迭代，直到 Agent 在这组 Eval 上表现良好。

在 Anthropic 内部，我们有时会提前构建一些：

以当前模型来看只是“勉强够用”，但赌几个月后模型会明显进步的功能。

低通过率的 Capability Eval 能够把这种“未来押注”清楚展示出来。

新模型发布后，只需要运行 Eval Suite，就能立即知道：

哪些押注已经兑现。

最接近产品需求和用户的人，通常也最适合定义成功标准。

以当前模型能力，产品经理、客户成功经理或销售人员完全可以直接使用 Claude Code：

• 编写一个新的 Eval Task；

• 以 PR 的方式提交。

应该允许他们这样做。

更进一步，还应该主动为他们提供这样的能力。

Eval 如何与其他方法结合，形成对 Agent 的完整理解

自动化 Eval 可以在完全不部署到生产环境、不影响真实用户的情况下，让 Agent 在数千个任务上运行。

但它只是理解 Agent 表现的一种方式。

完整的 Agent 质量体系通常还包括：

• 生产监控；

• 用户反馈；

• A/B 测试；

• 人工阅读 Transcript；

• 系统化人工评测。

自动化 Eval

通过程序运行测试，不使用真实用户。

优点：

• 迭代快；

• 完全可复现；

• 不影响用户；

• 每次 Commit 都可以运行；

• 不需要生产部署，就能大规模测试大量场景。

缺点：

• 前期建设成本较高；

• 产品和模型变化后必须持续维护，否则会发生漂移；

• 如果与真实使用分布不匹配，可能产生虚假的安全感。

生产监控

追踪真实系统中的指标和错误。

优点：

• 可以看到大规模真实用户行为；

• 能捕捉合成 Eval 遗漏的问题；

• 反映 Agent 在真实环境中的实际表现。

缺点：

• 属于被动方式，问题会先影响用户；

• 信号可能非常嘈杂；

• 需要额外建设可观测性基础设施；

• 通常缺少明确 Ground Truth 用于评分。

A/B 测试

使用真实用户流量比较不同版本。

优点：

• 直接衡量真实用户结果，例如留存和任务完成率；

• 可以控制混杂变量；

• 可规模化、系统化运行。

缺点：

• 慢，通常需要数天甚至数周才能获得统计显著性；

• 需要足够流量；

• 只能测试真正部署出去的变化；

• 如果无法充分查看 Transcript，仅从指标变化中很难判断“为什么”。

用户反馈

例如：

• 点踩；

• Bug Report；

• 显式意见。

优点：

• 能暴露你原本没有预料到的问题；

• 自带真实用户案例；

• 通常与实际产品目标高度相关。

缺点：

• 稀疏；

• 存在严重自选择偏差；

• 往往更偏向特别严重的问题；

• 用户通常不会解释为什么失败；

• 无法自动化；

• 如果主要依靠用户替你发现问题，会直接损害用户体验。

人工 Transcript Review

由人直接阅读 Agent 对话和执行过程。

优点：

• 能建立对失败模式的直觉；

• 能发现自动检查难以捕捉的微妙质量问题；

• 有助于校准什么叫“好”，以及真正理解执行细节。

缺点：

• 耗时；

• 无法大规模扩展；

• 覆盖范围不稳定；

• Reviewer 疲劳或不同 Reviewer 之间差异会影响信号质量；

• 通常只能得到定性反馈，而不是非常明确的量化评分。

系统化人工研究

由训练过的标注员按结构化流程评价 Agent 输出。

优点：

• 多个人类评分者可以提供高质量 Gold Standard；

• 适合主观或含糊任务；

• 能为改善模型 grader 提供可靠信号。

缺点：

• 相对昂贵；

• 周期慢；

• 很难高频运行；

• 不同评分者之间可能出现分歧，需要协调；

• 法律、金融、医疗等复杂领域需要真正的领域专家。

这些方法适用于 Agent 开发的不同阶段。

自动化 Eval特别适合：

• 上线之前；

• CI/CD；

• 每次 Agent 修改；

• 每次模型升级。

它可以成为质量问题的第一道防线。

生产监控则应该在上线后持续运行，用来发现：

• 用户分布发生变化；

• 合成测试从未覆盖的真实失败。

A/B 测试适合在拥有足够流量之后，验证重要产品改动。

用户反馈和 Transcript Review应该成为持续进行的日常工作：

• 不断处理反馈；

• 每周抽样阅读 Transcript；

• 发现异常后再深入分析。

而系统化人工评测更适合：

• 校准 LLM grader；

• 评测高度主观的输出；

• 人类共识本身就是 Reference Standard 的任务。

这与安全工程中的“瑞士奶酪模型”非常相似。

没有任何一层评测能够发现全部问题。

但如果多种方法叠加：

某一层漏掉的问题，就可能被下一层捕捉。

最有效的团队通常会组合使用：

• 自动化 Eval：快速迭代；

• 生产监控：获取 Ground Truth；

• 定期人工 Review：进行校准。

结论

没有 Eval 的团队，很容易陷入被动循环：

• 修复一个故障；

• 又制造一个故障；

• 还无法区分真实回归与随机噪声。

而尽早投资 Eval 的团队，通常会看到相反结果：

• 开发速度加快；

• 失败案例转化成测试；

• 测试阻止未来回归；

• 指标逐渐取代猜测。

Eval 会为整个团队提供一座明确的“山”去爬。

原本模糊的：

“Agent 感觉好像变差了。”

会转化成真正可操作的问题。

这种价值会不断复利增长，但前提是：

把 Eval 当作核心组件，而不是事后补上的东西。

不同类型 Agent 的具体模式会有所差异，但本文讨论的基本原则始终相同：

• 尽早开始；

• 不要等一个“完美 Eval Suite”才动手；

• 从真实失败中收集真实任务；

• 定义无歧义、稳健的成功标准；

• 仔细设计 grader，并组合多种 grader；

• 确保问题足够困难，能够真正区分模型能力；

• 持续迭代评测，提高信噪比；

• 阅读 Transcript。

一定要读 Transcript。

AI Agent Eval 仍然是一个非常年轻、快速变化的领域。

随着 Agent 开始：

• 执行更长的任务；

• 在多 Agent 系统中协作；

• 处理越来越主观的工作；

我们的评测技术也必须继续演进。

随着获得更多经验，我们也会持续分享新的最佳实践。