简介 本文链接

智能体之所以有用，也正是因为它们具备某些功能，而这些功能也使得评估它们变得困难。适用于各种部署环境的策略会结合多种技术，以匹配它们所评估系统的复杂性。

有效的评估有助于团队更有信心地发布人工智能智能体。如果没有评估，很容易陷入被动循环——只能在生产环境中发现问题，而修复一个故障又会引发其他故障。评估能够在问题和行为变化影响用户之前将其显现出来，其价值会在智能体的整个生命周期中不断累积。

正如我们在 《构建高效智能体》 一文中所述，智能体需要经过多个回合才能完成操作：调用工具、修改状态，并根据中间结果进行调整。正是这些使人工智能智能体发挥作用的能力——自主性、智能性和灵活性——也使得评估它们变得更加困难。

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

The structure of an evaluation 评估的结构

evaluation （简称“评估”）是对人工智能系统的一种测试：给人工智能系统输入数据，然后应用评分逻辑对其输出进行评估，以衡量其成功程度。本文重点介绍无需真实用户参与即可在开发过程中运行的自动化评估

• Single-turn evaluations 单轮评估简单明了：一个提示、一个回答和评分逻辑。

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

• Agent evaluations 智能体评估更为复杂。智能体会在多个回合中使用工具，不断修改环境状态并进行调整——这意味着错误可能会传播并累积。前沿模型还能找到超越静态评估局限性的创新解决方案。例如，Opus 4.5 通过发现策略中的一个漏洞，解决了关于预订航班的 𝜏2-bench 问题。虽然它按照既定的评估方法“失败”了，但实际上却为用户提供了一个更优的解决方案。

智能体评估更为复杂。智能体会在多个回合中使用工具，不断修改环境状态并进行调整——这意味着错误可能会传播并累积。前沿模型还能找到超越静态评估局限性的创新解决方案。例如，Opus 4.5 通过发现策略中的一个漏洞，解决了关于预订航班的 𝜏2-bench 问题。虽然它按照既定的评估方法“失败”了，但实际上却为用户提供了一个更优的解决方案。

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

1. 任务 task （又称问题 problem或测试用例 test case ）是指具有明确输入和成功标准的单个测试。

2. 每次尝试完成任务都称为一次试验 trial。由于模型输出在不同运行中会有所变化，因此我们会进行多次试验以获得更一致的结果。

3. 评分器 grader 是一种逻辑，用于对智能体性能的某些方面进行评分。一项任务可以有多个评分器，每个评分器包含多个断言（有时称为检查 checks）。

4. 记录 transcript （也称为轨迹 trace 或跟踪 trajectory）是试验的完整记录，包括输出、工具调用、推理过程、中间结果以及任何其他交互。对于 Anthropic API，它是评估运行结束时的完整消息数组，其中包含评估期间对 API 的所有调用以及所有返回的响应。

5. 结果 outcome 是指试验结束时环境中的最终状态。例如，航班预订智能体可能会在记录的最后说“您的航班已预订成功”，但结果取决于环境中的 SQL 数据库中是否存在相应的预订记录。

6. 评估框架 evaluation harness 是运行端到端评估的基础架构。它提供指令和工具，并发运行任务，记录所有步骤，对输出进行评分，并汇总结果。

7. 智能体框架 agent harness（或脚手架 scaffold）是一个使模型能够作为智能体运行的系统：它处理输入、协调工具调用并返回结果。当我们评估“智能体”时，我们实际上是在评估框架和模型协同工作的情况。例如， Claude Code 是一个灵活的智能体框架，我们通过其智能体 SDK 使用了其核心组件来构建我们长期运行的智能体框架

8. 评估套件 evaluation suite 是一系列旨在衡量特定能力或行为的任务集合。套件中的任务通常具有共同的总体目标。例如，客户支持评估套件可能测试退款、取消订单和升级处理流程。

why need evaluations 为什么要构建评估体系

团队在开发智能体之初，往往凭借手动测试、 内部测试和直觉就能取得令人惊讶的进展。更严格的评估甚至可能被视为一种额外的开销，会拖慢产品发布速度。但是，在早期原型阶段之后，一旦智能体投入生产并开始扩展，不进行评估的开发方式就会失效。

当用户反馈智能体在更改后体验更差时，问题往往会成为转折点。此时，团队只能“盲目摸索”，除了猜测和反复检查之外别无他法。缺乏评估机制，调试只能被动进行：等待用户反馈，手动复现问题，修复错误，然后祈祷没有其他功能回归。团队无法区分真正的回归问题和无关信息，无法在发布前针对数百种场景自动测试更改，也无法衡量改进效果。

我们已经多次见证了这种发展进程。例如，Claude Code 最初是基于 Anthropic 员工和外部用户的反馈进行快速迭代开发的。之后，我们增加了评估环节——最初针对简洁性和文件编辑等具体方面，后来扩展到过度设计等更复杂的行为。这些评估有助于发现问题、指导改进，并聚焦研发与产品之间的合作。结合生产监控、A/B 测试、用户研究等手段，评估结果能够为 Claude Code 的持续改进提供信号，助力其规模化发展。

在智能体生命周期的任何阶段，编写评估报告都非常有用。早期阶段，评估报告能促使产品团队明确智能体的成功标准；后期阶段，评估报告则有助于维持一致的质量标准。

Descript 的智能体帮助用户编辑视频，因此他们围绕成功的编辑工作流程的三个维度构建了评估体系：不破坏功能、执行指令、高质量地完成任务。他们从人工评分发展到使用 LLM 评分器，评分标准由产品团队定义，并定期进行人工校准。现在， 他们定期运行两套独立的测试套件，分别用于质量基准测试和回归测试。Bolt AI 团队在拥有一个广泛使用的智能体之后才开始构建评估体系。他们仅用了 3 个月就构建了一个评估系统，该系统运行他们的智能体并使用静态分析对输出进行评分，使用浏览器智能体测试应用程序，并采用 LLM 评判器来评估诸如指令执行等行为。

有些团队在开发初期就创建评估用例；而另一些团队则会在规模化开发过程中，当评估用例成为改进智能体的瓶颈时才添加。评估用例在智能体开发的初期尤为重要，它可以明确地编码预期行为。两位工程师阅读同一份初始规范后，可能会对人工智能如何处理极端情况产生不同的理解。评估用例套件可以消除这种歧义。无论何时创建，评估用例都能帮助加速开发。

评估结果还会影响你采用新模型的速度。当更强大的模型出现时，没有评估结果的团队需要花费数周时间进行测试，而拥有评估结果的竞争对手则可以迅速确定模型的优势，调整提示信息，并在几天内完成升级。

一旦评估系统建立起来，您就能免费获得基准测试和回归测试：延迟、Token使用量、单项任务成本和错误率都可以在一个静态任务库中进行跟踪。评估系统还可以成为产品团队和研究团队之间带宽最高的沟通渠道，定义研究人员可以据此进行优化的指标。显然，评估系统的好处远不止于跟踪回归和改进。由于成本是前期可见的，而收益是后期积累的，因此评估系统的累积价值很容易被忽视。

如何评估人工智能智能体

以下章节将介绍几种经过验证的智能体评估技术。您可以将这些方法作为基础，然后将其扩展到您的领域。

3 Types of graders for agent 3类 评分器类型

智能体评估通常结合三种类型的评分者：

• code-based 基于代码的评分者、
• model-based 基于模型的评分者
• human 人工评分者

每种评分者都会评估成绩单或结果的某个部分。有效评估设计的关键在于选择合适的评分者。

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

方法:

• String match checks 字符串匹配检查（精确匹配、正则表达式匹配、模糊匹配等
• Binary tests (fail-to-pass, pass-to-pass) 二元测试（不及格测试、及格测试）
• Static analysis (lint, type, security) 静态分析（语法检查、类型检查、安全性检查）
• Outcome verification 结果验证
• Tool calls verification (tools used, parameters) 工具调用验证（使用的工具、参数）
• Transcript analysis (turns taken, token usage) 文字记录分析（回合数、Token使用情况）

优点：

• 快速
• 便宜
• 客观
• 可复现
• 便于调试
• 核实具体条件

缺点：

• 容易出现与预期模式不完全匹配的有效变体
• 缺乏细微差别
• 在评估某些较为主观的任务方面存在局限性

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

方法：

• Rubric-based scoring 基于评分标准的评分
• Natural language assertions 自然语言断言
• Pairwise comparison 成对比较
• Reference-based evaluation 基于参考的评估
• Multi-judge consensus 多位评委的共识

优点：

• 灵活可扩展
• Captures nuance 捕捉细微差别
• Handles open-ended tasks 处理开放式任务
• Handles freeform output 处理自由格式输出

缺点：

• Non-deterministic 非确定性
• More expensive than code 比代码更昂贵
• Requires calibration with human graders for accuracy 需要人工评分员进行校准以确保准确性

Human graders 人工评分员

方法：

• SME review 中小企业评论
• Crowdsourced judgment 众包判断
• Spot-check sampling 抽样检查
• A/B testing A/B 测试
• Inter-annotator agreement 标注者间一致性

优点：

• Gold standard quality 黄金标准品质
• Matches expert user judgment 与专家用户判断相符
• Used to calibrate model-based graders 用于校准基于模型的评分器

缺点：

• 太贵
• 很慢
• Often requires access to human experts at scale 通常需要大规模地接触人类专家。

Capability vs. regression evals 能力评估与回归评估

Capability or “quality” evals 能力或“质量”评估会问：“这个智能体擅长做什么？”评估应该从较低的通过率开始，针对智能体难以完成的任务，给团队设置一个挑战。

回归评估 Regression evals 旨在询问“智能体是否仍然能够处理之前的所有任务？”，其通过率应接近 100%。回归评估可以防止系统退步，因为分数下降表明某些环节出现问题，需要改进。团队在进行能力评估时，同时运行回归评估至关重要，以确保变更不会在其他地方引发问题。

智能体程序启动并优化后，通过率高的能力评估可以“升级”为回归测试套件，持续运行以检测任何偏差。以前衡量“我们能否完成这项任务？”的任务，现在可以衡量“我们是否仍然能够可靠地完成这项任务？”

也就是说先通过能力评估，具备某种能力，再进行回归评估，可以稳定的完成任务

Evaluating coding agents 评估编码智能体

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

Deterministic graders 确定性评分器 常常被用来评估Coding Agent，对于编码智能体来说，确定性评分器是天然的选择，因为软件的评估通常比较直接：代码能否运行，测试能否通过？两个广泛使用的编码智能体基准测试工具 SWE-bench Verified 和 Terminal-Bench 都采用了这种方法。SWE-bench Verified 会向智能体提供来自热门 Python 代码库的 GitHub 问题，并通过运行测试套件来评估解决方案；只有当解决方案修复了失败的测试且不破坏现有测试时，才能通过评估。在短短一年内，LLM 在该评估中的得分就从 40% 提升到了 3080%。Terminal-Bench 则采用了不同的方法：它测试端到端的技术任务，例如从源代码构建 Linux 内核或训练机器学习模型。

一旦你拥有了一套用于验证编码任务关键结果的合格/不合格测试，通常也需要对代码进行评分 。 例如，基于启发式的代码质量规则可以基于除通过测试之外的其他因素来评估生成的代码，而带有清晰评分标准的基于模型的评分器可以评估诸如智能体如何调用工具或如何与用户交互等行为。

考虑这样一项编码任务：智能体必须修复一个身份验证绕过漏洞。如下面的示例 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 评估对话智能体

对话式智能体在支持、销售或辅导等领域与用户互动。与传统聊天机器人不同，它们会在对话过程中维护状态、使用工具并采取行动。虽然编码和研究型智能体也可能涉及与用户的多次交互，但对话式智能体面临着一个独特的挑战：交互本身的质量也是评估内容的一部分。对对话式智能体进行有效评估通常依赖于可验证的最终状态结果和评估标准，这些标准既能反映任务完成情况，又能反映交互质量。与其他大多数评估方法不同，对话式智能体通常需要第二个逻辑逻辑模型（LLM）来模拟用户。我们在对齐审计智能体中使用了这种方法，通过扩展的对抗性对话来对模型进行压力测试。

对话代理的成功可以从多个维度来衡量：

1. 问题是否已解决（状态检查）
2. 是否在 30 回合内完成（文本记录限制）
3. 语气是否恰当（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 评估研究智能体

研究代理收集、整合和分析信息，然后生成答案或报告等输出。与编码代理的单元测试提供二元通过/失败信号不同，研究质量只能根据具体任务来判断。何为“全面”、“来源可靠”甚至“正确”，取决于具体情况：市场调研、收购尽职调查和科学报告都需要不同的标准。

研究评估面临着独特的挑战：专家们可能对综合分析是否全面存在分歧；随着参考内容的不断变化，真实情况也会随之改变；篇幅更长、更开放的输出结果更容易出错。例如，像 BrowseComp 这样的基准测试旨在检验人工智能代理能否在开放的互联网中大海捞针般地找到所需信息——这些问题的设计初衷是易于验证但难以解决。

构建研究代理评估的一种策略是结合多种评分类型。基础性检查用于验证论断是否得到检索到的资料支持；覆盖面检查用于定义一个好的答案必须包含的关键事实；来源质量检查用于确认所参考的资料来源是否权威，而不仅仅是检索到的第一个来源。对于有客观正确答案的任务（例如“X 公司第三季度的收入是多少？”），完全匹配即可。LLM（学习逻辑模型）不仅可以标记缺乏依据的论断和覆盖面上的不足，还可以验证开放式综合分析的连贯性和完整性。

Computer use agents 计算机使用代理

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

浏览器应用代理需要在令牌效率和延迟之间取得平衡。基于 DOM 的交互执行速度快，但会消耗大量令牌；而基于屏幕截图的交互速度较慢，但​​令牌效率更高。例如，当让 Claude 总结维基百科内容时，从 DOM 中提取文本效率更高。在亚马逊上查找新的笔记本电脑保护套时，截屏效率更高（因为提取整个 DOM 会消耗大量令牌）。在我们的 Claude for Chrome 产品中，我们开发了评估机制来检查代理是否针对每个上下文选择了正确的工具。这使我们能够更快、更准确地完成基于浏览器的任务。

指标 How to think about non-determinism in evaluations for agents 如何思考代理评估中的非确定性

pass@k 衡量的是智能体在 k 次尝试中获得至少一次正确解的概率。随着 k 的增加，pass@k 得分也会提高：更多的“尝试”意味着至少成功一次的概率更高。50% 的 pass@1 得分意味着模型在评估任务中首次尝试就成功完成了一半的任务。在编程中，我们通常最关心的是智能体能否在首次尝试就找到解决方案——即 pass@1。但在其他情况下，只要有一个解决方案有效，提出多个解决方案也是有效的。

pass^k 衡量的是所有 k 次试验都成功的概率。随着 k 的增加，pass^k 会下降，因为要求在更多试验中保持一致性难度更大。如果你的智能体每次试验的成功率为 75%，并且你进行了 3 次试验，那么三次试验全部成功的概率为 (0.75)³ ≈ 42%。对于面向用户的智能体而言，这个指标尤为重要，因为用户期望每次都能获得可靠的服务。

随着试验次数的增加，pass@k 和 pass^k 的值逐渐趋于一致。当 k=1 时，二者完全相同（均代表每次试验的成功率）。但到了 k=10 时，二者的趋势则截然相反：pass@k 接近 100%，而 pass^k 则降至 0%。

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

Going from zero to one: a roadmap to great evals for agents 从零到一：经纪人获得优秀评估的路线图

本节阐述了我们经过实践检验的实用建议，帮助您从零开始构建可信赖的评估体系。您可以将其视为评估驱动型智能体开发的路线图：尽早定义成功标准，清晰衡量成功指标，并持续迭代。

我们发现，一些团队因为认为需要数百个任务而推迟构建评估模型。实际上，从真实失败案例中提取 20-50 个简单的任务就是一个很好的开始。毕竟，在智能体开发的早期阶段，对系统的每一次更改通常都会产生清晰可见的影响，而这种较大的影响意味着较小的样本量就足够了。更成熟的智能体可能需要更大、更复杂的评估来检测较小的影响，但在初期最好采用 80/20 法则。评估模型构建的难度会随着等待时间的延长而增加。在早期阶段，产品需求自然而然地转化为测试用例。如果等待时间过长，你就只能从运行中的系统中逆向推导成功标准了。

第一步：从你已经手动测试过的内容开始

首先从开发过程中运行的手动检查入手——每次发布前都要验证的行为以及最终用户经常尝试的任务。如果产品已经上线，请查看缺陷跟踪系统和支持队列。将用户报告的故障转化为测试用例，可以确保测试套件反映实际使用情况；根据用户影响进行优先级排序，有助于将精力投入到真正重要的地方。

步骤 2：编写明确的任务说明，并附上参考答案

确保任务质量远比想象中要难。一个好的任务应该能够让两位领域专家独立地得出相同的通过/失败结论。他们自己能通过这项任务吗？如果不能，那么任务就需要改进。任务规范中的模糊之处会成为评估指标中的噪音。同样的道理也适用于基于模型的评分标准：模糊的评分细则会导致判断结果不一致。

每个任务都应该能够被正确执行指令的智能体顺利完成。这一点可能比较微妙。例如，对 Terminal-Bench 的审计发现，如果一个任务要求智能体编写脚本，但没有指定文件路径，而测试又假定脚本位于某个特定的文件路径下，那么智能体可能会在并非自身过错的情况下失败。评分器检查的所有内容都应该在任务描述中清晰明确；智能体不应该因为规范含糊不清而失败。对于前沿模型，多次试验的通过率均为 0%（即 0% pass@100）通常表明任务存在缺陷，而非智能体能力不足，这提示您需要仔细检查任务规范和评分器。对于每个任务，创建一个参考解决方案非常有用：一个已知可行且能通过所有评分器的输出结果。这可以证明任务是可解决的，并验证评分器的配置是否正确。

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

测试行为应该发生和不应该发生的情况。单向评估会导致单向优化。例如，如果您只测试智能体是否在应该搜索的时候进行搜索，最终可能会得到一个几乎搜索所有内容的智能体。尽量避免 class-imbalanced类别不平衡的评估。我们在为 Claude.ai 构建网络搜索评估时就深有体会。挑战在于既要防止模型在不应该搜索的时候进行搜索，又要保证它在适当的时候能够进行广泛的研究。团队构建了涵盖两个方向的评估：模型应该搜索的查询（例如查找天气）和模型应该根据现有知识回答的查询（例如“谁创立了苹果公司？”）。在触发不足（不应该搜索的时候不搜索）和触发过度（不应该搜索的时候搜索）之间找到合适的平衡点非常困难，需要对提示和评估进行多轮改进。随着更多示例问题的出现，我们会不断增加评估内容，以提高覆盖范围。

测试行为应该发生和不应该发生的情况。单向评估会导致单向优化。例如，如果您只测试智能体是否在应该搜索的时候进行搜索，最终可能会得到一个几乎搜索所有内容的智能体。尽量避免类别不平衡的评估。我们在为 Claude.ai 构建网络搜索评估时就深有体会。挑战在于既要防止模型在不应该搜索的时候进行搜索，又要保证它在适当的时候能够进行广泛的研究。团队构建了涵盖两个方向的评估：模型应该搜索的查询（例如查找天气）和模型应该根据现有知识回答的查询（例如“谁创立了苹果公司？”）。在触发不足（不应该搜索的时候不搜索）和触发过度（不应该搜索的时候搜索）之间找到合适的平衡点非常困难，需要对提示和评估进行多轮改进。随着更多示例问题的出现，我们会不断增加评估内容，以提高覆盖范围。

Design the eval harness and graders 设计评估装置和评分器

步骤 4：构建一个具有稳定环境的强大评估框架

评估中使用的代理必须与生产环境中使用的代理功能大致相同，并且环境本身不应引入额外的干扰因素。每次试验都应从一个干净的环境开始，从而实现“隔离”。运行之间不必要的共享状态（例如残留文件、缓存数据、资源耗尽）会导致基础设施不稳定，而非代理性能问题，从而造成关联性故障。共享状态还会人为地夸大性能。例如，在一些内部评估中，我们观察到 Claude 通过查看先前试验的 Git 历史记录，在某些任务上获得了不公平的优势。如果多个不同的试验由于环境中的同一限制（例如 CPU 内存不足）而失败，则这些试验并非相互独立，因为它们受到同一因素的影响，因此评估结果对于衡量代理性能而言将变得不可靠。

评估中使用的代理必须与生产环境中使用的代理功能大致相同，并且环境本身不应引入额外的干扰因素。每次试验都应从一个干净的环境开始，从而实现“隔离”。运行之间不必要的共享状态（例如残留文件、缓存数据、资源耗尽）会导致基础设施不稳定，而非代理性能问题，从而造成关联性故障。共享状态还会人为地夸大性能。例如，在一些内部评估中，我们观察到 Claude 通过查看先前试验的 Git 历史记录，在某些任务上获得了不公平的优势。如果多个不同的试验由于环境中的同一限制（例如 CPU 内存不足）而失败，则这些试验并非相互独立，因为它们受到同一因素的影响，因此评估结果对于衡量代理性能而言将变得不可靠。

第五步：精心设计评分标准

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

人们通常倾向于检查智能体是否遵循了非常具体的步骤，例如按正确的顺序调用一系列工具。我们发现这种方法过于僵化，导致测试过于脆弱，因为智能体经常会找到评估设计者未预料到的有效方法。为了避免不必要地扼杀创造力，通常更好的做法是评估智能体最终产出的结果，而不是它所采取的路径。

对于包含多个步骤的任务，应采用部分计分制 。 一位能够正确识别问题并核实客户身份，但未能成功处理退款的客服人员，其表现也明显优于一位立即失败的客服人员。在结果中体现这种成功与失败的连续性至关重要。

模型评分通常需要反复迭代以验证其准确性。LLM（逻辑推理模型）评分器应与人类专家进行密切校准，以确保模型评分与人类评分之间的差异很小。为避免模型出现错误，应为 LLM 提供退出机制，例如，当信息不足时返回“未知”。此外，还可以创建清晰、结构化的评分标准，分别对任务的每个维度进行评分，然后使用独立的 LLM 评分器对每个维度进行评分，而不是使用同一个 LLM 评分器对所有维度进行评分。一旦系统稳定可靠，只需偶尔进行人工审核即可。

有些评估存在一些不易察觉的故障模式，即使智能体表现良好，也会导致得分偏低，因为智能体由于评分错误、智能体框架限制或歧义而无法完成任务。即使是经验丰富的团队也可能忽略这些问题。例如， Opus 4.5 最初在 CORE-Bench 测试中得分仅为 42% ，直到 Anthropic 的一位研究人员发现了多个问题：评分机制过于僵化，预期得分为“96.124991…”时却被扣分；任务规范含糊不清；以及随机任务难以精确复现。修复错误并使用限制较少的框架后，Opus 4.5 的得分跃升至 95%。类似地， METR 在其时间范围基准测试中发现了几个配置错误的任务，这些任务要求智能体优化到预设的分数阈值，但评分却要求超过该阈值。这导致像 Claude 这样遵循指令的模型受到惩罚，而忽略既定目标的模型反而获得了更高的分数。仔细核对作业和评分者可以避免这些问题。

确保评分系统能够抵御绕过或破解。测试人员不应能够轻易“作弊”通过评估。任务和评分系统的设计应确保及格需要真正解决问题，而不是利用无意中存在的漏洞。

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

第六步：查看成绩单

除非您阅读大量试验的记录和成绩，否则您无法了解评分员的工作是否高效。在 Anthropic，我们投资开发了用于查看评估记录的工具，并且我们定期抽出时间阅读这些记录。当任务失败时，记录会告诉您智能体是犯了真正的错误，还是评分员拒绝了有效的解决方案。记录通常还会揭示智能体和评分员行为的关键细节。

失败结果应该公平合理：清楚地说明智能体错在哪里以及错在哪里。当分数没有提升时，我们需要确信这是智能体表现的问题，而不是评估本身的问题。阅读评估记录是验证评估是否真正衡量了关键指标的方法，也是智能体开发的关键技能。

步骤 7：监测能力 capability eval 评估饱和度

100% 的评估结果会追踪退步，但无法提供任何改进的迹象。当智能体通过所有可解决的任务时， 评估就会达到饱和 ，没有改进的空间。例如，SWE-Bench Verified 的初始分数今年为 30%，而前沿模型的分数目前已接近饱和，达到 80%。随着评估接近饱和，进步速度也会放缓，因为只剩下最困难的任务。这可能会使结果具有欺骗性，因为能力的显著提升可能只体现在分数的微小增长上。例如，代码审查初创公司 Qodo 最初对 Opus 4.5 的表现并不满意，因为他们的一次性编码评估无法捕捉到在更长、更复杂的任务中取得的进步。为此，他们开发了一个新的智能体评估框架，从而能够更清晰地展现进步情况。

通常情况下，我们不会轻易相信评估分数，而是会深入研究评估细节并阅读一些评估记录。如果评分不公平、任务含糊不清、有效解决方案受到惩罚，或者评估框架限制了模型，则应修改评估结果。

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

评估套件是一个动态的产物，需要持续的关注和明确的所有权才能保持其有效性。

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

对于人工智能产品团队而言，评估的制定和迭代应该像维护单元测试一样成为日常工作。团队可能会在早期测试中“运行正常”的人工智能功能上浪费数周时间，但这些功能却无法满足未明确设定的预期，而精心设计的评估本应及早发现这些问题。定义评估任务是检验产品需求是否足够具体，从而启动开发的最佳方法之一。

我们建议采用评估驱动开发：在智能体能够实现预期功能之前，先构建评估模型来定义计划的功能，然后迭代开发，直到智能体性能良好。在内部，我们经常构建一些目前“足够好用”的功能，但这些功能实际上是对模型几个月后性能的押注。从较低的通过率开始的能力评估可以清晰地展现这一点。当新模型发布时，快速运行评估套件即可发现哪些押注最终得到了回报。

最了解产品需求和用户的人最能定义成功。借助当前模型的功能，产品经理、客户成功经理或销售人员可以使用 Claude Code 以 PR 的形式提交评估任务——让他们去做吧！或者，更好的是，积极地赋能他们。

如何将评估与其他方法结合起来，以全面理解代理人

自动化评估可以在不部署到生产环境或影响真实用户的情况下，对代理进行数千次任务测试。但这只是了解代理性能的众多方法之一。要全面了解代理性能，还需要进行生产环境监控、用户反馈、A/B 测试、人工转录审核以及系统性的人工评估。

An overview of approaches for understanding AI agent performance

理解 AI Agent 性能的几种方法概览

这些方法对应于代理开发的不同阶段。自动化评估在上线前和持续集成/持续交付 (CI/CD) 阶段尤为有用，每次代理变更和模型升级都会运行评估，作为抵御质量问题的第一道防线。上线后，生产监控会启动，以检测分布漂移和意外的实际故障。一旦流量足够，A/B 测试即可验证重大变更。用户反馈和文本审查是持续改进的实践：不断筛选反馈，每周阅读样本文本，并根据需要进行深入挖掘。系统性的人工研究应保留用于校准 LLM 评分员或评估主观输出，其中人类共识可作为参考标准。

就像安全工程中的瑞士奶酪模型一样，没有哪一层评估方法能够发现所有问题。通过结合多种方法，漏掉一层的故障会被另一层发现。

最有效的团队会将这些方法结合起来：自动化评估以实现快速迭代，生产监控以获取真实数据，以及定期人工审查以实现校准。

Conclusion 结论

缺乏评估的团队会陷入被动循环——修复一个故障，又制造另一个故障，无法区分真正的回归问题和噪音。而早期投入评估的团队则恰恰相反：随着故障转化为测试用例，测试用例能够预防回归问题，指标取代了猜测，开发速度也随之加快。评估为整个团队指明了前进的方向，将“代理感觉更糟”转化为可执行的行动。评估的价值会不断累积，但前提是必须将其视为核心组成部分，而不是事后补救。

不同类型的智能体模式各不相同，但这里描述的基本原则是一致的。尽早开始，不要等待完美的解决方案。从你看到的失败案例中寻找实际的任务。定义明确、可靠的成功标准。精心设计评分器，并结合多种类型。确保问题对模型来说足够困难。不断迭代评估，以提高信噪比。阅读记录！

人工智能代理评估仍是一个新兴且快速发展的领域。随着代理承担更长的任务、在多代理系统中协作以及处理日益主观的工作，我们需要调整我们的评估技术。我们将随着学习的深入，持续分享最佳实践。