内容来源：Anthropic Engineering 官方技术博客。

揭开 AI 智能体评测的神秘面纱

让智能体变得有用的能力，也让它们难以评估。能够在不同部署中奏效的策略，会组合多种技术，以匹配被测系统本身的复杂度。

来源：https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents
发布日期：2026-01-09

引言

好的评测能帮助团队更有信心地发布 AI 智能体。没有评测时，团队很容易陷入被动循环：问题只有到生产环境中才被发现，而修复一个失败又会引入其他失败。评测能在问题和行为变化影响用户之前让它们可见，并且其价值会在智能体的整个生命周期中复利增长。

正如我们在《Building effective agents》中所描述的，智能体会跨多轮运行：调用工具、修改状态，并根据中间结果调整行为。正是这些让 AI 智能体有用的能力，自治性、智能性和灵活性，也让它们更难评估。

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

评测的结构

评测（“eval”）是针对 AI 系统的测试：给 AI 一个输入，然后对其输出应用评分逻辑来衡量成功与否。本文聚焦于可以在开发期间运行、无需真实用户参与的自动化评测。

单轮评测很直接：一个提示、一个回复，以及评分逻辑。对于早期 LLM，单轮、非智能体式评测是主要评测方法。随着 AI 能力进步，多轮评测变得越来越常见。

在简单评测中，智能体处理一个提示，评分器检查输出是否符合预期。在更复杂的多轮评测中，编码智能体会获得工具、任务（此处是构建 MCP 服务器）和环境，执行一个“智能体循环”（工具调用和推理），并用实现更新环境。随后，评分会使用单元测试验证可工作的 MCP 服务器。

智能体评测更加复杂。智能体会跨多轮使用工具，修改环境中的状态，并边执行边适应，这意味着错误可能传播并叠加。前沿模型还可能找到超出静态评测限制的创造性解决方案。例如，Opus 4.5 在一个关于预订航班的 𝜏2-bench 问题中，通过发现政策中的漏洞解决了问题。按照评测书面规则，它“失败”了，但实际上为用户提出了更好的解决方案。

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

• 任务（也称 problem 或 test case）是一个单独测试，具有明确输入和成功标准。
• 对任务的一次尝试称为一次 trial。由于模型输出在不同运行之间会变化，我们会运行多次 trial，以获得更稳定的结果。
• 评分器是对智能体表现的某个方面进行打分的逻辑。一个任务可以有多个评分器，每个评分器可以包含多个断言（有时称为 checks）。
• 转录记录（也称 trace 或 trajectory）是一次 trial 的完整记录，包括输出、工具调用、推理、中间结果，以及任何其他交互。对于 Anthropic API 来说，它是一次评测运行结束时完整的 messages 数组，包含评测过程中所有 API 调用和所有返回响应。
• 结果是 trial 结束时环境中的最终状态。一个订票智能体可能在转录记录结尾说“您的航班已预订”，但结果是环境的 SQL 数据库中是否存在预订记录。
• 评测运行框架是端到端运行评测的基础设施。它提供指令和工具，并发运行任务，记录所有步骤，对输出评分，并汇总结果。
• 智能体运行框架（或 scaffold）是让模型能够以智能体形式行动的系统：它处理输入、编排工具调用并返回结果。当我们评估“一个智能体”时，评估的是运行框架和模型共同工作。例如，Claude Code 是一个灵活的智能体运行框架，我们通过 Agent SDK 使用其核心原语，构建了我们的长时间运行智能体运行框架。
• 评测套件是一组任务，用于衡量特定能力或行为。套件中的任务通常共享一个宽泛目标。例如，客户支持评测套件可能测试退款、取消和升级处理。

智能体评测的组成部分。

为什么要构建评测？

团队刚开始构建智能体时，依靠手动测试、dogfooding 和直觉的组合，常常能走得出乎意料地远。更严谨的评测甚至可能看起来像会拖慢发布的额外负担。但在早期原型阶段之后，一旦智能体进入生产并开始扩展，没有评测的构建方式就会开始失灵。

转折点常常出现在用户反馈“改动之后智能体感觉更差”时，而团队却在“盲飞”，除了猜测和试错之外没有办法验证。缺少评测时，调试是被动的：等待投诉，手动复现，修复 bug，然后希望其他地方没有回退。团队无法区分真正的回归和噪声，无法在发布前自动针对数百个场景测试变更，也无法衡量改进。

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

在智能体生命周期的任何阶段编写评测都有用。早期，评测迫使产品团队明确智能体成功意味着什么；后期，评测帮助维持一致的质量标准。

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

有些团队在开发一开始就创建评测；有些团队则是在达到规模、评测成为改进智能体的瓶颈时才添加评测。评测在智能体开发初期尤其有用，因为它能显式编码预期行为。两个工程师阅读同一份初始规格，可能会对 AI 应如何处理边界情况得出不同解释。评测套件可以消除这种歧义。无论何时创建，评测都有助于加速开发。

评测还会影响你采用新模型的速度。当更强大的模型发布时，没有评测的团队会面临数周测试，而拥有评测的竞争者可以快速确定模型优势、调整提示，并在几天内升级。

一旦评测存在，你就免费获得了基线和回归测试：延迟、token 使用量、每任务成本和错误率都可以在一组静态任务上跟踪。评测还可以成为产品团队和研究团队之间最高带宽的沟通渠道，定义研究人员可以优化的指标。显然，评测的好处远不止跟踪回归和改进。由于成本一开始可见，而收益在之后累积，它们的复利价值很容易被低估。

如何评估 AI 智能体

我们看到如今有几类常见智能体已被大规模部署，包括编码智能体、研究智能体、计算机使用智能体和对话智能体。每一类都可能部署在各种行业中，但可以用类似技术评估。你不需要从零发明一种评测。下面几节描述了适用于几类智能体的成熟技术。你可以以这些方法为基础，再扩展到自己的领域。

智能体评分器的类型

智能体评测通常组合三类评分器：基于代码的评分器、基于模型的评分器和人工评分器。每个评分器都会评估转录记录或结果的某一部分。有效评测设计的一个关键组成部分，是为任务选择合适的评分器。

基于代码的评分器

方法	优势	弱点
• 字符串匹配检查（精确、正则、模糊等） • 二元测试（fail-to-pass、pass-to-pass） • 静态分析（lint、类型、安全） • 结果验证 • 工具调用验证（使用的工具、参数） • 转录记录分析（轮次、token 使用量）	• 快 • 便宜 • 客观 • 可复现 • 易调试 • 可验证特定条件	• 对不完全匹配预期模式的有效变体很脆弱 • 缺乏细腻度 • 对某些更主观任务的评估能力有限

基于模型的评分器

方法	优势	弱点
基于 rubric 的评分自然语言断言成对比较基于参考答案的评估多裁判共识	灵活可扩展能捕捉细微差异能处理开放式任务能处理自由格式输出	非确定性比代码更昂贵需要与人工评分器校准以保证准确性

人工评分器

方法	优势	弱点
SME 审查众包判断抽样检查A/B 测试标注者一致性	质量金标准符合专家用户判断可用于校准基于模型的评分器	昂贵慢通常需要大规模访问人类专家

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

能力评测 vs. 回归评测

能力评测或“质量”评测会问：“这个智能体能做好什么？”它们应该从较低通过率开始，针对智能体吃力的任务，给团队一座可以攀登的山。

回归评测会问：“智能体是否仍然能处理过去能处理的所有任务？”并且应接近 100% 通过率。它们用于防止倒退，因为分数下降意味着某些东西坏了，需要改进。当团队在能力评测上爬坡时，也必须运行回归评测，确保变更没有在其他地方造成问题。

智能体发布并优化后，通过率高的能力评测可以“毕业”为持续运行的回归套件，用于捕捉任何漂移。过去衡量“我们到底能不能做到？”的任务，随后会衡量“我们是否仍能可靠做到？”

评估编码智能体

编码智能体会编写、测试和调试代码，像人类开发者一样浏览代码库并运行命令。现代编码智能体的有效评测通常依赖规格清晰的任务、稳定的测试环境，以及对生成代码的充分测试。

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

一旦你拥有一组通过/失败测试，用于验证编码任务的关键结果，通常也值得对转录记录评分*。*例如，基于启发式的代码质量规则可以基于通过测试之外的因素评估生成代码，而带有清晰 rubric 的基于模型评分器可以评估智能体如何调用工具或与用户交互。

示例：编码智能体的理论评测

考虑一个编码任务，其中智能体必须修复一个身份验证绕过漏洞。如下方示例 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 rubric 评估整体代码质量，只有在需要时才添加额外评分器和指标。

评估对话智能体

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

对话智能体的成功可以是多维的：工单是否已解决（状态检查），是否在 <10 轮内完成（转录记录约束），语气是否恰当（LLM rubric）？两个纳入多维性的基准是 𝜏-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

复制

和编码智能体示例一样，这个任务是为了说明而展示多个评分器类型。实践中，对话智能体评测通常使用基于模型的评分器来同时评估沟通质量和目标完成情况，因为许多任务，例如回答问题，可能有多个“正确”解决方案。

评估研究智能体

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

研究评测面临独特挑战：专家可能会对一份综合是否全面意见不一；随着参考内容不断变化，真值也会变化；更长、更开放的输出会给错误留下更多空间。例如，BrowseComp 这样的基准测试 AI 智能体能否在开放网络中大海捞针，其问题设计成容易验证但难以解决。

构建研究智能体评测的一种策略是组合评分器类型。 groundedness 检查会验证主张是否得到检索来源支持，coverage 检查定义优秀答案必须包含的关键事实，source quality 检查确认所咨询来源是权威的，而不只是最先检索到的来源。对于有客观正确答案的任务（“X 公司 Q3 收入是多少？”），精确匹配有效。LLM 可以标记无支持主张和覆盖缺口，也可以验证开放式综合的连贯性和完整性。

鉴于研究质量的主观性，基于 LLM 的 rubric 应频繁与专家人工判断校准，以有效为这些智能体评分。

计算机使用智能体

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

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

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

无论智能体类型如何，智能体行为都会在不同运行之间变化，这使评测结果比乍看起来更难解释。每个任务都有自己的成功率，也许某个任务是 90%，另一个是 50%；某个任务在一次评测运行中通过，下一次可能失败。有时，我们想衡量的是智能体对某个任务成功的频率（trial 中有多大比例成功）。

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

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

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

随着 trial 增加，pass@k 和 pass^k 会分化。在 k=1 时，它们相同（都等于单次 trial 成功率）。到 k=10 时，它们讲述相反的故事：pass@k 接近 100%，而 pass^k 下降到 0%。

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

从零到一：通往优秀智能体评测的路线图

本节给出我们经过实践检验的建议，说明如何从没有评测走向可信评测。你可以把它看作评测驱动智能体开发的路线图：尽早定义成功，清晰衡量，并持续迭代。

为初始评测数据集收集任务

Step 0. 尽早开始

我们看到团队推迟构建评测，是因为他们认为需要数百个任务。实际上，从真实失败中抽取 20-50 个简单任务就是很好的起点。毕竟，在智能体开发早期，对系统的每次更改往往都有清晰且可感知的影响，而这种大效应量意味着小样本量已经足够。更成熟的智能体可能需要更大、更难的评测来检测更小的效果，但一开始最好采用 80/20 方法。等待越久，评测越难构建。早期，产品需求会自然转化为测试用例。等太久，你就会从一个线上系统中反向工程成功标准。

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

从开发期间运行的手动检查开始，也就是每次发布前验证的行为，以及最终用户常尝试的常见任务。如果你已经在生产环境中，查看 bug 跟踪器和支持队列。把用户报告的失败转换成测试用例，可以确保套件反映真实使用情况；按用户影响排序，有助于把精力投入到最重要的地方。

Step 2: 编写无歧义任务并提供参考解决方案

把任务质量做好比看起来更难。一个好任务，是两个领域专家会独立得出相同通过/失败判断的任务。他们自己能通过这个任务吗？如果不能，任务需要进一步打磨。任务规格中的歧义会变成指标中的噪声。基于模型评分器的标准也一样：含糊的 rubric 会产生不一致判断。

每个任务都应该能被一个正确遵循指令的智能体通过。这一点可能很微妙。例如，对 Terminal-Bench 的审计发现，如果任务要求智能体编写一个脚本，却没有指定文件路径，而测试又假设脚本位于某个特定文件路径，那么智能体可能并非自身过错而失败。评分器检查的所有内容都应该能从任务描述中清楚看出；智能体不应因为规格含糊而失败。对于前沿模型，如果许多 trial 上通过率为 0%（即 0% pass@100），这通常是任务损坏的信号，而不是智能体没有能力，也是重新检查任务规格和评分器的标志。对每个任务，创建一个参考解决方案很有用：一个已知可工作、能通过所有评分器的输出。这证明任务可解，也验证评分器配置正确。

Step 3: 构建平衡的问题集

既测试某种行为应该发生的情况，也测试它不应该发生的情况。单边评测会造成单边优化。例如，如果你只测试智能体在应该搜索时是否搜索，最终可能得到一个几乎什么都搜索的智能体。尽量避免类别不平衡评测。我们在为 Claude.ai 构建网页搜索评测时亲身体会到了这一点。挑战在于防止模型在不应搜索时搜索，同时保留其在适当情况下进行广泛研究的能力。团队构建了覆盖两个方向的评测：模型应该搜索的查询（如查天气），以及模型应该基于已有知识回答的查询（如“谁创立了 Apple？”）。在触发不足（该搜索时不搜索）和触发过度（不该搜索时搜索）之间找到正确平衡很困难，需要多轮改进提示词和评测。随着更多示例问题出现，我们会继续加入评测以改善覆盖范围。

设计评测运行框架和评分器

Step 4: 构建具备稳定环境的稳健评测运行框架

评测中的智能体必须与生产中使用的智能体大致相同，且环境本身不能引入额外噪声。每个 trial 都应该从干净环境开始，以实现“隔离”。运行之间不必要的共享状态（残留文件、缓存数据、资源耗尽）可能会因为基础设施不稳定而造成相关失败，而不是反映智能体表现。共享状态也可能人为抬高表现。例如，在一些内部评测中，我们观察到 Claude 通过查看之前 trial 的 git 历史，在某些任务上获得不公平优势。如果多个不同 trial 因环境中的同一限制（例如 CPU 内存有限）而失败，这些 trial 就不是独立的，因为它们受到同一因素影响，评测结果也就无法可靠衡量智能体表现。

Step 5: 审慎设计评分器

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

一种常见直觉是检查智能体是否遵循了非常具体的步骤，例如按正确顺序执行一系列工具调用。我们发现这种方法过于刚性，会导致测试过于脆弱，因为智能体经常找到评测设计者没有预料到的有效方法。为了不无谓惩罚创造性，通常最好评估智能体产出了什么，而不是它走了哪条路径。

对于包含多个组成部分的任务，应内置部分得分**。**一个支持智能体如果正确识别了问题并验证了客户身份，但未能处理退款，仍然明显好于一开始就失败的智能体。在结果中表达这种成功连续谱很重要。

模型评分通常需要仔细迭代来验证准确性。LLM-as-judge 评分器应与人类专家紧密校准，以确信人工评分和模型评分之间几乎没有偏差。为了避免幻觉，要给 LLM 一个退路，例如指示它在信息不足时返回 “Unknown”。创建清晰、结构化的 rubric 来分别评估任务的每个维度，也会有所帮助；随后用彼此隔离的 LLM-as-judge 对每个维度评分，而不是用一个模型评估所有维度。一旦系统足够稳健，只需偶尔使用人工审查即可。

有些评测存在微妙失败模式，即使智能体表现良好，也会因评分 bug、智能体运行框架约束或歧义而得低分。即使成熟团队也可能错过这些问题。例如，Opus 4.5 最初在 CORE-Bench 上得分 42%，直到一位 Anthropic 研究员发现多个问题：刚性评分会在期望 “96.124991…” 时惩罚 “96.12”，任务规格含糊，以及随机任务无法精确复现。修复 bug 并使用约束较少的 scaffold 后，Opus 4.5 的分数跃升到 95%。类似地，METR 发现其时间跨度基准中有几个配置错误的任务，要求智能体优化到一个声明的分数阈值，但评分却要求超过该阈值。这惩罚了像 Claude 这样遵循指令的模型，而忽略声明目标的模型反而得分更高。仔细复查任务和评分器有助于避免这些问题。

让评分器能够抵抗绕过或 hack。智能体不应能轻易“作弊”通过评测。任务和评分器的设计应确保通过确实需要解决问题，而不是利用意外漏洞。

长期维护和使用评测

Step 6: 检查转录记录

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

失败应该看起来是公平的：智能体错在哪里、为什么错，都应很清楚。当分数不上升时，我们需要确信原因是智能体表现，而不是评测本身。阅读转录记录是验证你的评测是否衡量真正重要内容的方式，也是智能体开发的一项关键技能。

Step 7: 监控能力评测饱和

达到 100% 的评测可以跟踪回归，但无法提供改进信号。评测饱和发生在智能体通过了所有可解任务之后，此时没有提升空间。例如，SWE-Bench Verified 分数今年从 30% 开始，而前沿模型如今正接近 >80% 的饱和。随着评测接近饱和，进展也会放慢，因为只剩下最难的任务。这可能让结果具有误导性，因为大的能力提升看起来只是分数的小幅增加。例如，代码审查创业公司 Qodo 最初对 Opus 4.5 印象不深，因为他们的一次性编码评测没有捕捉到更长、更复杂任务上的增益。作为回应，他们开发了新的智能体式评测框架，提供了清晰得多的进展图景。

作为规则，在有人深入评测细节并阅读一些转录记录之前，我们不会按表面值接受评测分数。如果评分不公平、任务含糊、有效解决方案被惩罚，或运行框架限制了模型，就应该修订评测。

Step 8: 通过开放贡献和维护，让评测套件长期保持健康

评测套件是一个活的产物，需要持续关注和清晰所有权，才能保持有用。

在 Anthropic，我们尝试过多种评测维护方法。最有效的方法是建立专门的评测团队来负责核心基础设施，同时由领域专家和产品团队贡献大部分评测任务，并自行运行评测。

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

我们建议实践评测驱动开发：在智能体能够实现计划能力之前，先构建评测来定义这些能力，然后迭代直到智能体表现良好。在内部，我们经常构建今天“足够好”的功能，但它们押注的是模型几个月后能做到什么。以低通过率开始的能力评测会让这一点可见。当新模型发布时，快速运行套件就能揭示哪些押注兑现了。

最接近产品需求和用户的人最适合定义成功。以当前模型能力，产品经理、客户成功经理或销售人员可以使用 Claude Code 以 PR 形式贡献一个评测任务，请让他们这样做！或者更进一步，主动赋能他们。

创建有效评测的流程。

评测如何与其他方法结合，形成对智能体的整体理解

自动化评测可以针对一个智能体运行数千个任务，而无需部署到生产环境，也不会影响真实用户。但这只是理解智能体表现的众多方式之一。完整图景包括生产监控、用户反馈、A/B 测试、手动转录记录审查，以及系统性人工评估。

理解 AI 智能体表现的方法概览

方法	优点	缺点
自动化评测 无需真实用户，以编程方式运行测试	迭代更快完全可复现不影响用户可在每次 commit 上运行无需生产部署即可规模化测试场景	需要更多前期投入来构建随着产品和模型演进，需要持续维护以避免漂移如果不匹配真实使用模式，可能产生虚假信心
生产监控 跟踪线上系统中的指标和错误	规模化揭示真实用户行为捕捉合成评测遗漏的问题提供智能体实际表现的真实依据	被动；问题会先到达用户，之后你才知道信号可能有噪声需要投入埋点缺乏评分真值
A/B 测试 用真实用户流量比较变体	衡量真实用户结果（留存、任务完成）控制混杂因素可扩展且系统化	慢；需要数天或数周达到显著性，且需要足够流量只测试你部署的变更如果不能彻底审查转录记录，就很难解释指标变化背后的“为什么”
用户反馈 点赞/踩或 bug 报告等显式信号	浮现你没有预料到的问题包含来自真实人类用户的真实示例反馈通常与产品目标相关	稀疏且自选择偏向严重问题用户很少解释某件事为什么失败不是自动化主要依赖用户捕捉问题可能对用户造成负面影响
手动转录记录审查 人类阅读智能体对话	建立对失败模式的直觉捕捉自动化检查遗漏的细微质量问题帮助校准什么算“好”并把握细节	耗时无法扩展覆盖不一致审查者疲劳或不同审查者会影响信号质量通常只给出定性信号，而非清晰量化评分
系统性人工研究 由训练有素的评分者结构化评估智能体输出	来自多位人类评分者的金标准质量判断处理主观或含糊任务为改进基于模型的评分器提供信号	相对昂贵且周转慢难以频繁运行评分者分歧需要协调复杂领域（法律、金融、医疗）需要人类专家开展研究

这些方法对应智能体开发的不同阶段。自动化评测在发布前和 CI/CD 中尤其有用，可在每次智能体变更和模型升级时运行，作为防止质量问题的第一道防线。生产监控在发布后开始发挥作用，用于检测分布漂移和未预料到的真实世界失败。一旦你拥有足够流量，A/B 测试就可以验证重要变更。用户反馈和转录记录审查是填补空白的持续实践：持续分诊反馈，每周抽样阅读转录记录，并在需要时深入调查。将系统性人工研究保留给 LLM 评分器校准，或评估主观输出且人类共识可作为参考标准的场景。

就像安全工程中的瑞士奶酪模型，没有单一评估层能够捕捉所有问题。组合多种方法后，穿过一层的失败会被另一层捕获。

最有效的团队会组合这些方法：用自动化评测快速迭代，用生产监控获得真实依据，并定期进行人工审查以校准。

结论

没有评测的团队会陷入被动循环：修复一个失败，制造另一个失败，无法区分真正的回归和噪声。早期投入评测的团队会发现相反情况：随着失败变成测试用例、测试用例防止回归、指标取代猜测，开发会加速。评测给整个团队一个明确的改进目标，把“智能体感觉更差”转化为可操作事项。价值会复利增长，但前提是你把评测当作核心组件，而不是事后补充。

不同智能体类型的模式各不相同，但本文描述的基本原则是不变的。尽早开始，不要等待完美套件。从你看到的失败中获取真实任务。定义无歧义、稳健的成功标准。审慎设计评分器，并组合多种类型。确保问题对模型来说足够难。迭代评测，以提高信噪比。阅读转录记录！

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 发展出评测实践。

附录：评测框架

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

Harbor 专为在容器化环境中运行智能体而设计，提供跨云提供商规模化运行 trial 的基础设施，并提供定义任务和评分器的标准化格式。Terminal-Bench 2.0 等流行基准会通过 Harbor registry 发布，便于与自定义评测套件一起运行成熟基准。

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

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

Arize 提供 Phoenix，这是一个用于 LLM tracing、调试，以及离线或在线评测的开源平台；同时提供 AX，这是一个 SaaS 产品，将 Phoenix 扩展到规模化、优化和监控场景。

许多团队会组合多个工具，自行构建评测框架，或仅用简单评测脚本作为起点。我们发现，虽然框架可以成为加速进展和标准化的有价值方式，但它们的好坏取决于你通过它们运行的评测任务质量。通常最好快速选择一个适合你工作流的框架，然后把精力投入评测本身，迭代高质量测试用例和评分器。