译文-解析 AI Agent 评估-Anthropic

TL;DR

#

核心观点：评估是 AI 智能体从原型走向生产的关键。由于智能体具有多轮交互、状态保持和工具调用等特性，传统的单轮 LLM 评估已不再适用。高效的评估体系应侧重于自动化、多维度评分以及对结果而非路径的考核。

1. 核心评估架构 (The Evaluation Architecture)
智能体评估不再是简单的“提示词-响应”对，而是一个包含完整交互周期的系统：

• 输入 (Task/Input)：定义明确的测试任务和环境初始状态。
• 执行 (Execution)：智能体与环境（工具、API、浏览器）进行多轮交互。
• 记录 (Transcript)：捕获完整的工具调用链、推理过程和中间状态。
• 结果 (Outcome)：环境的最终状态（如：数据库是否更新、文件是否生成）。

2. 分层评分策略 (Grading Strategy)
不要依赖单一的评分方式，应采用混合评分器 (Hybrid Graders) 策略来平衡成本、速度和准确性：

3. 不同类型智能体的评估方案

• 编程智能体 (Coding Agents)：
  • 方案：核心依赖单元测试（通过/失败）。
  • 进阶：结合静态分析（代码风格）和 LLM 评分（代码可读性）。
• 对话智能体 (Conversational Agents)：
  • 方案：引入第二模型模拟用户进行多轮对抗/协作测试。
  • 指标：多维评分（任务是否完成 + 交互质量 + 轮次限制）。
• 研究智能体 (Research Agents)：
  • 方案：事实核查 (Groundedness) + 来源质量验证。
  • 难点：无唯一标准答案，依赖 LLM 对覆盖率和连贯性进行评分。
• 计算机操作智能体 (Computer Use Agents)：
  • 方案：基于沙盒环境，验证最终状态（如订单是否生成）而非中间点击路径。

4. 关键度量指标 (Key Metrics)

• pass@k (探索能力)：在 $k$ 次尝试中至少成功 1 次的概率。适用于“只要有一个方案可行即可”的场景（如编程）。
• pass^k (可靠性)：连续 $k$ 次尝试全部成功的概率。适用于要求高度一致性的场景（如客户服务）。
• 能力 vs. 回归：新功能开发看重能力评估（有难度的任务），维护阶段看重回归评估（确保存量任务 100% 通过）。

5. 落地执行路线图 (Implementation Roadmap)

1. 从错误开始 (Start with Failures)：不需要数百个任务，从 20-50 个基于真实故障或手动测试用例的任务开始。
2. 考核结果而非路径 (Grade Outcomes, Not Paths)：智能体可能会用意想不到的方式解决问题。只要结果正确（如退款成功），不要纠结于它调用的工具顺序，避免评估过拟合。
3. 阅读对话记录 (Read Transcripts)：这是调试评估体系的唯一真理。确保失败是公平的，而不是因为评分器本身的问题。
4. 隔离环境 (Isolate Environments)：杜绝试验间的状态污染（如缓存、残留文件），确保每次运行都是独立的。
5. 警惕饱和 (Watch for Saturation)：当通过率接近 100% 时，评估即失效，需引入更难的任务以推动能力提升。

总结建议：构建评估体系是一个从“手动测试”到“自动化代码检查”，再到“LLM 辅助评分”的演进过程。最有效的团队会将自动化评估（用于快速迭代）、生产环境监控（用于获取真实数据）和定期人工审查（用于校准标准）三者结合使用。

引言 (Introduction)

#

优秀的评估能够帮助团队更自信地发布 AI 智能体 (AI agents)。如果没有评估，团队很容易陷入被动响应的循环——只能在生产环境中发现问题，而修复一个故障又会导致其他故障。评估能够让问题和行为变更在影响用户之前变得可见，其价值会在智能体的整个生命周期中产生复利效应。

正如我们在 构建高效的智能体 (Building effective agents) 一文中所述，智能体的运作涉及多个轮次：调用工具、修改状态以及根据中间结果进行调整。正是这些让 AI 智能体变得有用的能力——自主性、智能性和灵活性——同时也增加了评估它们的难度。

通过我们的内部工作以及与处于智能体开发前沿的客户的合作，我们学会了如何为智能体设计更严谨、更有用的评估。以下是在真实世界的部署中，跨越多种智能体架构和用例的有效经验。

评估的结构 (The structure of an evaluation)

#

评估 (evaluation)（简称 “eval”）是对 AI 系统的一种测试：给 AI 一个输入，然后对其输出应用评分逻辑以衡量是否成功。在这篇文章中，我们要关注的是自动化评估 (automated evals)，即可以在开发过程中运行且无需真实用户参与的评估。

单轮评估 (Single-turn evaluations) 非常直观：包括一个提示词 (prompt)、一个响应和评分逻辑。对于早期的 LLM，单轮、非智能体式的评估是主要的评估方法。随着 AI 能力的提升，多轮评估 (multi-turn evaluations) 正变得越来越普遍。

智能体评估 (Agent evaluations) 则更加复杂。智能体在多个轮次中使用工具，修改环境中的状态，并在此过程中进行调整——这意味着错误可能会传播和累积。前沿模型还能找到超越静态评估限制的创造性解决方案。例如，Opus 4.5 解决了一个关于预订航班的 𝜏2-bench 问题，它是通过发现策略中的漏洞来完成的。按照字面规则它“未通过”评估，但实际上为用户提供了一个更好的解决方案。

在构建智能体评估时，我们使用以下定义：

• 任务 (Task)（也称为问题 (problem) 或 测试用例 (test case)）是一个具有定义好的输入和成功标准的单个测试。
• 对一个任务的每次尝试称为一次 试验 (Trial)。因为模型输出在不同运行间存在差异，我们会运行多次试验以产生更一致的结果。
• 评分器 (Grader) 是对智能体表现的某些方面进行打分的逻辑。一个任务可以有多个评分器，每个评分器包含多个断言（有时称为检查 (checks)）。
• 对话记录 (Transcript)（也称为 轨迹 (Trace) 或 路径 (Trajectory)）是一次试验的完整记录，包括输出、工具调用、推理、中间结果以及任何其他交互。对于 Anthropic API，这是评估运行结束时的完整消息数组——包含评估期间对 API 的所有调用和所有返回的响应。
• 结果 (Outcome) 是试验结束时环境的最终状态。一个航班预订智能体可能会在对话记录的结尾说“您的航班已预订”，但实际结果是环境的 SQL 数据库中是否存在该预订记录。
• 评估框架 (Evaluation harness) 是端到端运行评估的基础设施。它提供指令和工具，并发运行任务，记录所有步骤，对输出进行评分，并汇总结果。
• 智能体框架 (Agent harness)（或 脚手架 (scaffold)）是使模型能够充当智能体的系统：它处理输入，编排工具调用，并返回结果。当我们评估“一个智能体”时，我们评估的是框架和模型协同工作的效果。例如，Claude Code 是一个灵活的智能体框架，我们利用其核心原语通过 Agent SDK 构建了我们的 长时间运行智能体框架 (long-running agent harness)。
• 评估套件 (Evaluation suite) 是旨在衡量特定能力或行为的任务集合。套件中的任务通常共享一个广泛的目标。例如，一个客户支持评估套件可能会测试退款、取消和升级处理。

为什么要构建评估？ (Why build evaluations?)

#

当团队刚开始构建智能体时，依靠手动测试、吃自家的狗粮 (dogfooding) 和直觉的组合，可以取得令人惊讶的进展。更严格的评估甚至可能看起来像是拖慢发布速度的负担。但在早期的原型设计阶段之后，一旦智能体投入生产并开始扩展，没有评估的构建方式就会开始崩溃。

崩溃点通常出现在用户报告变更后智能体体验变差时，而团队处于“盲飞”状态，除了猜测和检查外无法进行验证。缺乏评估时，调试是被动的：等待投诉，手动复现，修复错误，并祈祷没有引起其他回退 (regression)。团队无法区分真正的回退和噪音，无法在发布前自动针对数百种场景测试变更，也无法衡量改进。

我们已经多次看到这种演变过程。例如，Claude Code 最初是基于 Anthropic 员工和外部用户的反馈进行快速迭代。后来，我们添加了评估——首先是针对简洁性和文件编辑等狭窄领域，然后是针对过度设计 (over-engineering) 等更复杂的行为。这些评估有助于发现问题，指导改进，并聚焦研究与产品的协作。结合生产环境监控、A/B 测试、用户研究等手段，评估为 Claude Code 在扩展过程中的持续改进提供了信号。

在智能体生命周期的任何阶段编写评估都是有用的。在早期，评估迫使产品团队明确智能体成功的定义；而在后期，它们有助于维持一致的质量标准。

Descript 的智能体帮助用户编辑视频，因此他们围绕成功编辑工作流的三个维度构建了评估：不要破坏东西、做我要求的、并把它做好。他们从手动评分演变为由产品团队定义标准并定期进行人工校准的 LLM 评分器，现在定期运行两个独立的套件进行质量基准测试和回归测试。Bolt AI 团队在已经拥有广泛使用的智能体后才开始构建评估。在 3 个月内，他们构建了一个评估系统，运行他们的智能体并通过静态分析对输出评分，使用浏览器智能体测试应用程序，并采用 LLM 裁判来评估指令遵循等行为。

有些团队在开发之初就创建评估；另一些则在规模化后，当缺乏评估成为改进智能体的瓶颈时才添加。评估在智能体开发初期特别有用，可以显式地编码预期行为。两名工程师阅读同一份初始规范，可能会对 AI 应如何处理边缘情况产生不同的解读。一个评估套件可以解决这种歧义。无论何时创建，评估都有助于加速开发。

评估还决定了你采用新模型的速度。当更强大的模型问世时，没有评估的团队面临数周的测试，而拥有评估的竞争对手可以迅速确定模型的优势，调整提示词，并在几天内完成升级。

一旦存在评估，你就免费获得了基线和回归测试：延迟、Token 使用量、单任务成本和错误率都可以在静态任务库上进行跟踪。评估也可以成为产品团队和研究团队之间最高带宽的沟通渠道，定义研究人员可以优化的指标。显然，评估的好处不仅仅在于跟踪回退和改进。鉴于成本是显而易见的，而收益是在后期累积的，其复利价值很容易被忽视。

如何评估 AI 智能体 (How to evaluate AI agents)

#

我们看到如今有几种常见的智能体类型已被大规模部署，包括编程智能体、研究智能体、计算机操作智能体和对话智能体。每种类型可能部署在各行各业，但它们可以使用类似的技术进行评估。你不需要从头发明评估方法。以下部分描述了几种智能体类型的成熟技术。以这些方法为基础，然后将其扩展到你的领域。

智能体评分器的类型 (Types of graders for agents)

#

智能体评估通常结合三种类型的评分器：基于代码的、基于模型的和人工的。每个评分器评估对话记录或结果的一部分。有效评估设计的一个重要组成部分是为工作选择合适的评分器。

基于代码的评分器 (Code-based graders)

基于模型的评分器 (Model-based graders)

人工评分器 (Human graders)

对于每个任务，评分可以是加权的（组合评分必须达到阈值）、二元的（所有评分器必须通过），或者是混合的。

能力评估 vs. 回归评估 (Capability vs. regression evals)

#

能力 (Capability) 或“质量”评估 询问“这个智能体能做好什么？”它们的通过率起点应该较低，针对智能体难以应对的任务，给团队一个攀登的目标。

回归 (Regression) 评估 询问“智能体是否仍然能处理它以前能处理的所有任务？”，其通过率应接近 100%。它们防止倒退，因为分数的下降信号表明某处已损坏并需要改进。当团队在能力评估上攀登高峰时，运行回归评估以确保变更不会在其他地方引起问题同样重要。

在智能体发布并优化后，具有高通过率的能力评估可以“毕业”成为回归套件，持续运行以捕捉任何漂移。曾经衡量“我们可以做这个吗？”的任务，随后变为衡量“我们还能可靠地做这个吗？”。

评估编程智能体 (Evaluating coding agents)

#

编程智能体 (Coding agents) 编写、测试和调试代码，浏览代码库，并像人类开发人员一样运行命令。现代编程智能体的有效评估通常依赖于定义明确的任务、稳定的测试环境以及对生成代码的全面测试。

确定性评分器是编程智能体的天然选择，因为软件评估通常很直接：代码能否运行且测试能否通过？两个广泛使用的编程智能体基准测试，SWE-bench Verified 和 Terminal-Bench，都遵循这种方法。SWE-bench Verified 给智能体提供来自流行 Python 仓库的 GitHub issue，并通过运行测试套件来对解决方案评分；只有当解决方案修复了失败的测试且不破坏现有测试时，才算通过。仅一年时间，LLM 在此评估上的通过率已从 40% 提升至 >80%。Terminal-Bench 采取了不同的路径：它测试端到端的技术任务，例如从源码构建 Linux 内核或训练 ML 模型。

一旦你有了一组通过或失败的测试来验证编程任务的关键结果，对对话记录进行评分通常也很有用。例如，基于启发式的代码质量规则可以基于通过测试之外的标准评估生成的代码，而带有清晰量规的模型评分器可以评估诸如智能体如何调用工具或与用户交互等行为。

示例：编程智能体的理论评估

考虑一个编程任务，智能体必须修复一个身份验证绕过漏洞。如下面的说明性 YAML 文件所示，人们可以使用评分器和指标来评估此智能体。

task:
  id: "fix-auth-bypass_1"
  desc: "Fix authentication bypass when password field is empty and ..."
  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

注意，此示例展示了所有可用评分器的范围以作说明。在实践中，编程评估通常依赖单元测试进行正确性验证，并依赖 LLM 量规评估整体代码质量，仅在需要时添加其他评分器和指标。

评估对话智能体 (Evaluating conversational agents)

#

对话智能体 (Conversational agents) 在支持、销售或辅导等领域与用户互动。与传统聊天机器人不同，它们保持状态，使用工具，并在对话中采取行动。虽然编程和研究智能体也可能涉及与用户的多轮交互，但对话智能体提出了一个独特的挑战：交互本身的质量是你评估的一部分。对话智能体的有效评估通常依赖于可验证的最终状态结果以及捕捉任务完成度和交互质量的量规。与大多数其他评估不同，它们通常需要第二个 LLM 来模拟用户。我们在对齐审计智能体 (alignment auditing agents) 中使用这种方法，通过扩展的对抗性对话对模型进行压力测试。

对话智能体的成功可以是多维度的：工单是否解决（状态检查），是否在 <10 轮内完成（对话记录约束），以及语气是否得当（LLM 量规）？包含多维度特性的两个基准测试是 𝜏-Bench 及其后续版本 τ2-Bench。这些基准测试模拟了零售支持和机票预订等领域的跨多轮交互，其中一个模型扮演用户角色，而智能体则处理现实场景。

示例：对话智能体的理论评估

考虑一个支持任务，智能体必须为一位沮丧的客户处理退款。

graders:
  - type: llm_rubric
    rubric: prompts/support_quality.md
    assertions:
      - "Agent showed empathy for customer's frustration"
      - "Resolution was clearly explained"
      - "Agent's response grounded in fetch_policy tool results"
  - 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

正如在我们的编程智能体示例中一样，此任务展示了多种评分器类型以作说明。在实践中，对话智能体评估通常使用基于模型的评分器来评估沟通质量和目标完成情况，因为许多任务——比如回答问题——可能有多个“正确”的解决方案。

评估研究智能体 (Evaluating research agents)

#

研究智能体 (Research agents) 收集、综合和分析信息，然后生成如答案或报告等输出。与单元测试提供二元通过/失败信号的编程智能体不同，研究质量只能相对于任务来判断。什么算作“全面”、“来源可靠”甚至“正确”，取决于上下文：市场扫描、收购尽职调查和科学报告各自需要不同的标准。

研究评估面临独特的挑战：专家可能对综合报告是否全面持不同意见，随着参考内容不断变化，基本事实 (ground truth) 也会发生转变，而且更长、更开放的输出为错误创造了更多空间。例如，像 BrowseComp 这样的基准测试，测试 AI 智能体能否在开放网络中大海捞针——这些问题的设计初衷是易于验证但难以解决。

构建研究智能体评估的一种策略是结合多种评分器类型。基于事实检查 (Groundedness checks) 验证主张是否由检索到的来源支持，覆盖率检查 (Coverage checks) 定义好答案必须包含的关键事实，来源质量检查 (Source quality checks) 确认参考的来源是权威的，而不仅仅是首先检索到的。对于有客观正确答案的任务（“X 公司第三季度的收入是多少？”），精确匹配是有效的。LLM 可以标记不受支持的主张和覆盖范围的缺失，也可以验证开放式综合报告的连贯性和完整性。

鉴于研究质量的主观性，基于 LLM 的量规应经常根据专家的人工判断进行校准，以便有效地对这些智能体进行评分。

计算机操作智能体 (Computer use agents)

#

计算机操作智能体 (Computer use agents) 通过与人类相同的界面——截图、鼠标点击、键盘输入和滚动——与软件交互，而不是通过 API 或代码执行。它们可以使用任何带有图形用户界面 (GUI) 的应用程序，从设计工具到旧的企业软件。评估需要在真实或沙盒环境中运行智能体，让它可以操作软件应用程序，并检查它是否达到了预期的结果。例如，WebArena 测试基于浏览器的任务，使用 URL 和页面状态检查来验证智能体是否导航正确，并结合后端状态验证用于修改数据的任务（确认订单实际上已下达，而不仅仅是确认页面出现）。OSWorld 将此扩展到完整的操作系统控制，使用评估脚本在任务完成后检查各种工件：文件系统状态、应用程序配置、数据库内容和 UI 元素属性。

浏览器操作智能体需要在 Token 效率和延迟之间取得平衡。基于 DOM 的交互执行速度快，但消耗大量 Token，而基于截图的交互较慢，但 Token 效率更高。例如，当要求 Claude 总结维基百科时，从 DOM 中提取文本效率更高。当在亚马逊上寻找新的笔记本电脑包时，截图效率更高（因为提取整个 DOM 会占用大量 Token）。在我们的 Claude for Chrome 产品中，我们开发了评估来检查智能体是否为每个上下文选择了正确的工具。这使我们能够更快、更准确地完成基于浏览器的任务。

如何看待智能体评估中的非确定性 (How to think about non-determinism in evaluations for agents)

#

无论智能体类型如何，智能体行为在不同运行之间都会有所不同，这使得评估结果比表面上看起来更难解释。每个任务都有自己的成功率——可能在一个任务上是 90%，在另一个任务上是 50%——并且在一个评估运行中通过的任务可能会在下一个运行中失败。有时，我们想要衡量的是智能体在一个任务上成功的频率（试验的比例）。

两个指标有助于捕捉这种细微差别：

pass@k 衡量智能体在 k 次尝试中获得至少一个正确解决方案的可能性。随着 k 的增加，pass@k 分数上升——更多的“射门”意味着至少 1 次成功的几率更高。50% 的 pass@1 分数意味着模型在第一次尝试时成功完成了评估中一半的任务。在编程中，我们通常最感兴趣的是智能体在第一次尝试时找到解决方案——pass@1。在其他情况下，只要有一个方案有效，提出多个解决方案也是可以的。

pass^k 衡量所有 k 次试验都成功的概率。随着 k 的增加，pass^k 下降，因为要求在更多试验中保持一致性是一个更难跨越的门槛。如果你的智能体有 75% 的单次试验成功率，并且你运行 3 次试验，全部通过的概率是 (0.75)³ ≈ 42%。这个指标对于面向客户的智能体尤为重要，因为用户期望每次都有可靠的行为。

这两个指标都很有用，使用哪一个取决于产品需求：对于只要一次成功就很重要的工具使用 pass@k，对于一致性至关重要的智能体使用 pass^k。

从零到一：通往优秀智能体评估的路线图 (Going from zero to one: a roadmap to great evals for agents)

#

本节列出了我们将评估从无到有并建立可信评估的实用、经过实战检验的建议。把它看作是评估驱动的智能体开发路线图：尽早定义成功，清晰地衡量它，并持续迭代。

收集初始评估数据集的任务 (Collect tasks for the initial eval dataset)

#

步骤 0. 尽早开始

我们看到团队推迟构建评估，因为他们认为需要数百个任务。实际上，从真实失败中提取 20-50 个简单任务就是一个很好的开始。毕竟，在智能体开发早期，系统的每一次变更通常都有明显、显著的影响，这种巨大的效应意味着小样本量就足够了。更成熟的智能体可能需要更大、更难的评估来检测较小的效应，但在开始时最好采取 80/20 原则。等待的时间越长，评估就越难构建。早期，产品需求自然转化为测试用例。如果等太久，你就得从现有系统中反向工程成功标准。

步骤 1. 从你已经手动测试的内容开始

从你在开发过程中运行的手动检查开始——那些你在每次发布前验证的行为以及最终用户尝试的常见任务。如果你已经在生产环境中，请查看你的错误跟踪器和支持队列。将用户报告的故障转换为测试用例，确保你的套件反映实际使用情况；按用户影响优先级排序有助于你将精力投入到最重要的地方。

步骤 2：编写带有参考答案且无歧义的任务

确保任务质量比看起来要难。一个好的任务是两位领域专家能够独立得出相同通过/失败结论的任务。他们自己能通过这个任务吗？如果不能，任务就需要改进。任务规范中的歧义会变成指标中的噪音。这也适用于基于模型的评分器的标准：模糊的量规会产生不一致的判断。

每个任务都应该能被正确遵循指令的智能体通过。这可能很微妙。例如，审计 Terminal-Bench 时发现，如果一个任务要求智能体编写脚本但没有指定文件路径，而测试假设脚本在特定路径下，智能体可能会非因自身过错而失败。评分器检查的所有内容都应在任务描述中清晰明了；智能体不应因模棱两可的规范而失败。对于前沿模型，如果在多次试验中通过率为 0%（即 0% pass@100），这通常是任务损坏的信号，而不是智能体无能，这提示需要仔细检查你的任务规范和评分器。对于每个任务，创建一个参考答案 (reference solution) 是很有用的：一个已知能通过所有评分器的工作输出。这证明了任务是可解的，并验证了评分器配置正确。

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

既要测试行为应该发生的情况，也要测试不应该发生的情况。片面的评估会导致片面的优化。例如，如果你只测试智能体在应该搜索时是否搜索，你可能会得到一个几乎对所有事情都进行搜索的智能体。尽量避免类别不平衡 (class-imbalanced) 的评估。我们在为 Claude.ai 构建网络搜索评估时亲身体会到了这一点。挑战在于防止模型在不应该搜索时进行搜索，同时保留其在适当时候进行广泛研究的能力。团队构建了覆盖两个方向的评估：模型应该搜索的查询（如查找天气）和应该根据现有知识回答的查询（如“谁创立了苹果？”）。在触发不足（应该搜索时不搜索）或过度触发（不应该搜索时搜索）之间取得适当平衡是困难的，需要对提示词和评估进行多轮改进。随着更多示例问题的出现，我们将继续添加到评估中以提高覆盖率。

设计评估框架和评分器 (Design the eval harness and graders)

#

步骤 4：构建具有稳定环境的健壮评估框架

评估中的智能体必须与生产中使用的智能体功能大致相同，且环境本身不引入额外的噪音，这一点至关重要。每次试验都应通过从干净的环境开始来“隔离”。运行之间不必要的共享状态（残留文件、缓存数据、资源耗尽）可能会因基础设施的不稳定而非智能体性能导致相关性故障。共享状态也可能人为地提高性能。例如，在一些内部评估中，我们观察到 Claude 通过检查先前试验的 git 历史记录，在某些任务上获得了不公平的优势。如果多个不同的试验因环境中相同的限制（如受限的 CPU 内存）而失败，这些试验就不是独立的，因为它们受相同因素影响，评估结果在衡量智能体性能时就变得不可靠。

步骤 5：深思熟虑地设计评分器

如上所述，优秀的评估设计包括为智能体和任务选择最佳评分器。我们建议尽可能选择确定性评分器，必要时或为了增加灵活性使用 LLM 评分器，并审慎使用人工评分器进行额外验证。

有一种常见的本能是检查智能体是否遵循了非常具体的步骤，如按正确顺序调用一系列工具。我们发现这种方法过于僵化，导致测试过于脆弱，因为智能体经常找到评估设计者未曾预料到的有效方法。为了不必要地惩罚创造力，通常最好是对智能体生产的内容进行评分，而不是其采取的路径。

对于包含多个组件的任务，应建立部分得分 (partial credit) 机制。一个能正确识别问题并验证客户身份但未能处理退款的支持智能体，比起那些立即失败的智能体有意义上的更好。在结果中体现这种成功的连续性很重要。

模型评分通常需要仔细迭代来验证准确性。作为裁判的 LLM (LLM-as-judge) 评分器应与人类专家紧密校准，以获得人类评分与模型评分之间偏差很小的信心。为了避免幻觉，给 LLM 一个退路，比如提供指令让其在信息不足时返回“未知”。创建清晰、结构化的量规来对任务的每个维度进行评分，然后用隔离的作为裁判的 LLM 对每个维度进行评分，而不是用一个 LLM 对所有维度评分，也会有所帮助。一旦系统稳健，偶尔进行人工审查就足够了。

有些评估存在微妙的失败模式，即使智能体表现良好得分也很低，因为智能体因评分漏洞、智能体框架限制或歧义而未能解决任务。即使是成熟的团队也会忽略这些问题。例如，Opus 4.5 最初在 CORE-Bench 上得分 42%，直到一位 Anthropic 研究员发现了多个问题：僵化的评分在期望 “96.124991…” 时惩罚了 “96.12”，任务规范模糊，以及无法精确复现的随机任务。修复错误并使用限制较少的框架后，Opus 4.5 的得分跃升至 95%。同样，METR 发现 他们的时间跨度基准测试中有几个配置错误的任务，要求智能体优化到规定的分数阈值，但评分却要求超过该阈值。这惩罚了像 Claude 这样遵循指令的模型，而那些忽略既定目标的模型却获得了更高的分数。仔细复查任务和评分器有助于避免这些问题。

让你的评分器能够抵御绕过或黑客攻击。智能体不应能轻易“欺骗”评估。设计任务和评分器时，应确保通过测试真正需要解决问题，而不是利用意外的漏洞。

长期维护和使用评估 (Maintain and use the eval long-term)

#

步骤 6：检查对话记录

除非你阅读许多试验的对话记录和评分，否则你无法知道你的评分器是否工作良好。在 Anthropic，我们投资了用于查看评估对话记录的工具，并定期花时间阅读它们。当任务失败时，对话记录会告诉你智能体是犯了真正的错误，还是你的评分器拒绝了一个有效的解决方案。它通常还会暴露出关于智能体和评估行为的关键细节。

失败应该看起来是公平的：清楚智能体哪里错了以及为什么错。当分数没有攀升时，我们需要确信这是由于智能体性能而非评估本身。阅读对话记录是你验证评估是否衡量了真正重要内容的途径，也是智能体开发的一项关键技能。

步骤 7：监控能力评估的饱和度

一个 100% 的评估可以跟踪回退，但无法提供改进信号。评估饱和 (Eval saturation) 发生在智能体通过所有可解任务时，没有留下改进空间。例如，SWE-Bench Verified 分数今年从 30% 开始，前沿模型现在正接近 >80% 的饱和度。随着评估接近饱和，进展也会放缓，因为只剩下最困难的任务。这可能使结果具有欺骗性，因为巨大的能力提升仅表现为分数的微小增加。例如，代码审查初创公司 Qodo 最初对 Opus 4.5 不以为然，因为他们的单次尝试 (one-shot) 编程评估没有捕捉到其在更长、更复杂任务上的收益。作为回应，他们开发了一个新的智能体评估框架，提供了更清晰的进展图景。

作为一项规则，在有人深入研究评估细节并阅读一些对话记录之前，我们不会轻信评估分数。如果评分不公、任务模糊、有效方案被罚或框架限制了模型，则应修改评估。

步骤 8：通过开放贡献和维护保持评估套件的长期健康

评估套件是一个活的工件，需要持续关注和明确的所有权才能保持有用。

在 Anthropic，我们尝试了各种评估维护方法。证明最有效的是建立专门的评估团队来拥有核心基础设施，而领域专家和产品团队贡献大部分评估任务并自己运行评估。

对于 AI 产品团队来说，拥有并迭代评估应该像维护单元测试一样常规。团队可能会在 AI 功能上浪费数周时间，这些功能在早期测试中“有效”，但未能满足那些设计良好的评估本可以尽早暴露的未明示预期。定义评估任务是压力测试产品需求是否具体到足以开始构建的最佳方法之一。

我们建议实行评估驱动开发：在智能体能够实现之前，先构建评估来定义计划中的能力，然后迭代直到智能体表现良好。在内部，我们经常构建目前“足够好”的功能，但这是对几个月后模型能力的押注。起步通过率较低的能力评估使这一点变得可见。当新模型发布时，运行套件会迅速揭示哪些押注得到了回报。

最接近产品需求和用户的人最有资格定义成功。以目前的模型能力，产品经理、客户成功经理或销售人员可以使用 Claude Code 将评估任务作为 PR 贡献出来——让他们做吧！或者更好的是，积极地赋能他们。

评估如何与其他方法配合以全面了解智能体 (How evals fit with other methods for a holistic understanding of agents)

#

自动化评估可以在不部署到生产环境或影响真实用户的情况下，针对数千个任务运行智能体。但这只是了解智能体性能的众多方法之一。完整的图景包括生产环境监控、用户反馈、A/B 测试、手动对话记录审查和系统性的人类评估。

了解 AI 智能体性能的方法概览

这些方法对应智能体开发的不同阶段。自动化评估在发布前和 CI/CD 中特别有用，在每次智能体变更和模型升级时运行，作为防止质量问题的第一道防线。生产环境监控在发布后启动，以检测分布漂移和未预料到的现实世界故障。一旦你有足够的流量，A/B 测试用于验证重大变更。用户反馈和对话记录审查是填补空白的持续实践——不断分流反馈，每周抽样阅读对话记录，并在需要时深入挖掘。保留系统性人类研究用于校准 LLM 评分器或评估以人类共识为参考标准的主观输出。

最高效的团队结合了这些方法——自动化评估用于快速迭代，生产环境监控用于获取基本事实，定期人工审查用于校准。

结论 (Conclusion)

#

没有评估的团队会陷入被动响应的泥潭——修复一个故障，制造另一个，无法区分真正的回退和噪音。早期投资的团队发现了相反的情况：随着故障变成测试用例，开发加速，测试用例防止回退，指标取代猜测。评估给整个团队一个清晰的攀登目标，将“智能体感觉变差了”转化为可操作的事情。价值会产生复利，但前提是你将评估视为核心组件，而不是事后的想法。

不同智能体类型的模式各异，但这里描述的基本原理是不变的。尽早开始，不要等待完美的套件。从你看到的故障中获取现实任务。定义明确、稳健的成功标准。深思熟虑地设计评分器并结合多种类型。确保问题对模型来说足够难。迭代评估以提高信噪比。阅读对话记录！

AI 智能体评估仍然是一个新生、快速发展的领域。随着智能体承担更长的任务，在多智能体系统中协作，并处理日益主观的工作，我们需要调整我们的技术。随着我们了解更多，我们将继续分享最佳实践。

附录：评估框架 (Appendix: Eval frameworks)

#

几个开源和商业框架可以帮助团队实施智能体评估，而无需从头构建基础设施。正确的选择取决于你的智能体类型、现有技术栈，以及你需要离线评估、生产可观测性还是两者兼有。

Harbor 专为在容器化环境中运行智能体而设计，拥有跨云提供商大规模运行试验的基础设施，以及定义任务和评分器的标准化格式。流行的基准测试如 Terminal-Bench 2.0 通过 Harbor 注册表发布，使得运行已建立的基准测试和自定义评估套件变得容易。

Promptfoo 是一个轻量级、灵活且开源的框架，专注于提示词测试的声明式 YAML 配置，断言类型范围从字符串匹配到作为裁判的 LLM 量规。我们在许多产品评估中使用 Promptfoo 的某个版本。

Braintrust 是一个结合了离线评估与生产可观测性和实验跟踪的平台——对于既需要在开发期间迭代又需要监控生产质量的团队很有用。其 autoevals 库包括针对真实性、相关性和其他常见维度的预构建评分器。

LangSmith 提供追踪、离线和在线评估以及数据集管理，并与 LangChain 生态系统紧密集成。Langfuse 作为自托管的开源替代方案，为有数据驻留要求的团队提供类似的功能。

许多团队结合多种工具，推出自己的评估框架，或者仅仅使用简单的评估脚本作为起点。我们发现，虽然框架是加速进展和标准化的宝贵方式，但它们的价值取决于你通过它们运行的评估任务。通常最好的做法是快速选择一个适合你工作流的框架，然后将精力投入到评估本身，通过迭代高质量的测试用例和评分器来实现。