本文翻译自 Anthropic 官方技术博客：Demystifying evals for AI agents。

主要观点

有效的评估（Evals）是团队自信地发布 AI Agent 的基础。与单轮对话的 LLM 不同，Agent 涉及多轮交互、工具调用和状态修改，这使得它们更难评估。缺乏评估会导致团队陷入被动的“打地鼠”模式，仅能在生产环境中发现问题。相反，建立评估体系能让问题在早期显现，量化改进效果，并促进产品与研究团队的协作。

一个完整的评估体系包括任务（Task）、评分器（Grader）、评估工具（Harness）和数据集（Suite）。针对不同类型的 Agent（如代码、对话、研究、计算机操作），需要采用不同的评估策略。评分器通常结合了基于代码的确定性检查、基于模型的灵活评分（LLM-as-judge）以及人工审核，以平衡速度、成本和准确性。

构建评估体系不需要一开始就追求完美。文章提出了一个实用的路线图：从少量的现实失败案例开始，逐步建立无歧义的任务集，设计稳健的测试环境和评分逻辑，并长期维护。重要的是要结合自动化评估、生产监控、A/B 测试和人工审查，形成一个多层次的质量保障网络（类似瑞士奶酪模型），以全面理解 Agent 的性能。

关键细节

核心定义与组件

构建 Agent 评估时涉及以下关键概念：

  • Task (任务)：具有定义输入和成功标准的单个测试用例。
  • Trial (尝试)：对任务的一次执行，通常需要多次运行以应对非确定性。
  • Grader (评分器)：对 Agent 表现进行打分的逻辑，可包含多个断言。
  • Transcript (实录)：完整的交互记录，包括输出、工具调用和推理过程。
  • Outcome (结果)：试验结束时环境的最终状态（例如数据库中是否存在预定记录）。

不同类型 Agent 的评估策略

  • Coding Agents：通常使用确定性评分器。例如 SWE-bench Verified 通过运行单元测试来验证代码修复是否成功。
  • Conversational Agents：侧重于交互质量和任务完成度。常使用 LLM 模拟用户进行多轮对话，并结合状态检查（如工单是否解决）和语气评分。
  • Research Agents：评估较为主观。策略包括检查内容的依据性（Groundedness）、覆盖率（Coverage）和来源质量。
  • Computer Use Agents：在沙盒环境中运行，通过检查截图或 DOM 状态来验证结果。例如 WebArena 和 OSWorld。

评分器类型

  1. 基于代码 (Code-based)：如字符串匹配、静态分析。优点是快速、便宜、客观；缺点是缺乏灵活性。
  2. 基于模型 (Model-based)：如 LLM 评分量表。优点是灵活、能捕捉细微差别；缺点是成本较高，需人工校准。
  3. 人工评分 (Human)：专家审查。优点是质量金标准；缺点是昂贵且慢，通常用于校准模型评分器。

处理非确定性与指标

由于 Agent 行为在不同运行间存在差异，文章提出了两个关键指标：

  • $ pass@k $：衡量在 $ k $ 次尝试中至少有一次成功的概率。适用于只要有一个解决方案即可的场景（如代码生成）。
  • $ pass^k $：衡量所有 $ k $ 次尝试都成功的概率。计算公式为 $ (success_rate)^k $。适用于要求高度一致性的场景（如面向客户的 Agent）。

构建评估体系的步骤

  1. 尽早开始：从 20-50 个基于真实失败案例的简单任务开始。
  2. 利用现有测试：将手动测试和用户错误报告转化为评估用例。
  3. 编写无歧义任务：确保任务描述清晰，并提供参考答案（Reference Solution）。
  4. 构建平衡的数据集：同时测试“应该做”和“不应该做”的场景（例如防止过度搜索）。
  5. 设计稳健的工具：确保测试环境隔离，避免共享状态干扰结果。
  6. 检查实录 (Transcripts)：阅读交互记录以验证评分器的准确性并调试 Agent 行为。
  7. 监控指标饱和：当评分接近 100% 时，需引入更难的任务以避免指标失效。
  8. 长期维护：鼓励产品经理等非技术人员通过 Claude Code 等工具贡献测试用例。

现有框架与工具

文章提到了一些有助于加速开发的框架，如 Harbor（容器化环境）、Promptfoo（声明式配置）、Braintrust（结合生产监控）、LangSmith 和 Langfuse。但强调工具只是辅助，高质量的测试用例才是核心。

原文：揭开 AI 智能体评估的神秘面纱

发布于 2026年1月9日

让智能体变得有用的能力，同时也让它们难以评估。在各类部署中行之有效的策略，往往结合了多种技术，以匹配其所测系统的复杂性。

引言

优秀的评估（Evaluations，简称 Evals）能帮助团队更自信地发布 AI 智能体（Agents）。如果没有评估，很容易陷入被动的循环——只有在生产环境中才发现问题，而修复一个故障又会导致其他故障。评估能让问题和行为变化在影响用户之前显现出来，其价值会在智能体的整个生命周期中通过复利效应不断累积。

正如我们在 构建高效的智能体 一文中所述，智能体通过多轮交互进行操作：调用工具、修改状态以及根据中间结果进行调整。正是这些让 AI 智能体变得有用的能力——自主性、智能性和灵活性——同时也让它们更难被评估。

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

评估的结构

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

单轮评估直截了当：一个提示词（prompt）、一个回复和评分逻辑。对于早期的 LLM（大语言模型），单轮、非智能体式的评估是主要的评估方法。随着 AI 能力的提升，多轮评估变得越来越普遍。

xx

在一个简单的评估中，智能体处理提示词，评分器检查输出是否符合预期。对于更复杂的多轮评估，编程智能体接收工具、任务（本例中为构建一个 MCP 服务器）和环境，执行“智能体循环”（工具调用和推理），并用实现代码更新环境。然后，评分环节使用单元测试来验证 MCP 服务器是否正常工作。

智能体评估则更为复杂。智能体在多轮交互中使用工具，修改环境中的状态并随之调整——这意味着错误可能会传播和复合。前沿模型还能找到超越静态评估限制的创造性解决方案。例如，Opus 4.5 解决了一个关于预订航班的 𝜏2-bench 问题，它是通过发现 政策中的漏洞来完成的。它在书面评估上“失败”了，但实际上为用户提出了更好的解决方案。

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

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

xxx 智能体评估的组成部分。

为什么要构建评估？

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

崩溃点通常出现在用户报告变更后智能体体验变差，而团队由于没有验证手段只能“盲目飞行”，靠猜测和检查来应对。缺乏评估，调试就是被动的：等待投诉，手动复现，修复错误，并祈祷没有导致其他功能回退。团队无法区分真正的回退和噪音，无法在发布前针对数百种场景自动测试变更，也无法衡量改进效果。

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

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

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

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

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

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

如何评估 AI 智能体

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

智能体评分器的类型

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

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

xxx

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

xxx

人工评分器 (Human graders)

xxx

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

能力评估 vs 回归评估

能力或“质量”评估问的是“这个智能体能做好什么？”它们应该从低通过率开始，针对智能体难以处理的任务，给团队一个攀登的目标。

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

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

评估编程智能体

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

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

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

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

考虑一个编程任务，智能体必须修复身份验证绕过漏洞。如下面的说明性 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 细则评估整体代码质量，仅在需要时添加额外的评分器和指标。

评估对话智能体

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

对话智能体的成功可以是多维度的：工单是否已解决（状态检查），是否在 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

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

评估研究智能体

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

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

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

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

电脑操作智能体 (Computer use agents)

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

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

如何看待智能体评估中的非确定性

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

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

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

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

xxx

随着试验次数的增加，pass@k 和 pass^k 出现分歧。在 k=1 时，它们是相同的（都等于单次试验成功率）。到了 k=10，它们讲述了相反的故事：pass@k 接近 100%，而 pass^k 降至 0%。

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

从零到一：智能体优秀评估路线图

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

收集初始评估数据集的任务

步骤 0. 尽早开始

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

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

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

步骤 2：编写带有参考答案的明确任务

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

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

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

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

设计评估框架和评分器

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

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

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

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

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

对于包含多个组件的任务，建立部分得分机制。一个正确识别问题并验证客户身份但未能处理退款的支持智能体，明显优于立即失败的智能体。在结果中体现这种成功的连续性很重要。

模型评分通常需要仔细迭代以验证准确性。LLM 裁判评分器应与人类专家紧密校准，以确信人工评分和模型评分之间差异很小。为了避免幻觉，给 LLM 提供一条出路，比如提供一条指令，让它在没有足够信息时返回“未知”。创建清晰、结构化的细则来对任务的每个维度进行评分，然后使用隔离的 LLM 裁判分别对每个维度进行评分，而不是用一个裁判对所有维度评分，这也很有帮助。一旦系统稳健，只需偶尔进行人工审查即可。

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

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

长期维护和使用评估

步骤 6：检查对话记录 (Transcripts)

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

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

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

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

作为一项规则，除非有人深入研究评估的细节并阅读一些记录，否则我们不会仅凭面值接受评估分数。如果评分不公平，任务模棱两可，有效的解决方案受到惩罚，或者框架限制了模型，那么评估应该被修改。

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

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

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

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

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

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

xxx 创建有效评估的过程。

评估如何与其他方法配合以全面了解智能体

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

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

xxx

xxx

xxx

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

xxx 就像安全工程中的瑞士奶酪模型一样，没有任何单一的评估层能捕获所有问题。通过结合多种方法，漏过一层的故障会被另一层捕获。

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

结论

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

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

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

致谢

由 Mikaela Grace, Jeremy Hadfield, Rodrigo Olivares, 和 Jiri De Jonghe 撰写。我们也感谢 David Hershey, Gian Segato, Mike Merrill, Alex Shaw, Nicholas Carlini, Ethan Dixon, Pedram Navid, Jake Eaton, Alyssa Baum, Lina Tawfik, Karen Zhou, Alexander Bricken, Sam Kennedy, Robert Ying 以及其他人的贡献。特别感谢我们在合作评估中学到东西的客户和合作伙伴，包括 iGent, Cognition, Bolt, Sierra, Vals.ai, Macroscope, PromptLayer, Stripe, Shopify, Terminal Bench 团队等。这项工作反映了数个帮助在 Anthropic 发展评估实践的团队的集体努力。

附录：评估框架 (Eval frameworks)

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

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

Promptfoo 是一个轻量级、灵活且开源的框架，专注于使用声明式 YAML 配置进行提示词测试，断言类型从字符串匹配到 LLM 裁判细则不等。我们将 Promptfoo 的一个版本用于我们的许多产品评估。

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

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

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