揭秘 AI 智能体评估¶

原文链接: English Original

使智能体有用的能力也使它们难以评估。在不同部署中有效的策略结合了多种技术，以匹配其所衡量系统的复杂性。

引言¶

好的评估帮助团队更自信地发布 AI 智能体。没有评估，很容易陷入被动循环——只在生产环境中发现问题，修复一个故障又造成另一个。评估使问题和行为变更在影响用户之前变得可见，其价值在智能体的整个生命周期中不断累积。

正如我们在 building-effective-agents 中描述的，智能体在多轮中操作：调用工具、修改状态、并根据中间结果进行调整。这些使 AI 智能体有用的相同能力——自主性、智能和灵活性——也使它们更难评估。

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

评估的结构¶

评估（"eval"）是对 AI 系统的测试：给 AI 一个输入，然后对其输出应用评分逻辑以衡量成功。在本文中，我们关注可以在开发期间运行的自动化评估，无需真实用户。

单轮评估很简单：一个 prompt、一个响应和评分逻辑。对于早期的 LLM，单轮非智能体评估是主要的评估方法。随着 AI 能力的进步，多轮评估变得越来越普遍。

在一个简单的评估中，智能体处理一个 prompt，一个评分器检查输出是否符合预期。对于更复杂的多轮评估，一个编码智能体接收工具、任务（在这种情况下是构建一个 MCP server）和环境，执行一个"智能体循环"（工具调用和推理），并用实现更新环境。然后评分使用单元测试来验证工作的 MCP server。

智能体评估更加复杂。智能体在多轮中使用工具，修改环境中的状态并随着进行而适应——这意味着错误可以传播和复合。前沿模型还可以找到超越静态评估限制的创造性解决方案。例如，Opus 4.5 通过发现策略中的漏洞"解决"了一个关于预订航班的 τ2-bench 问题。它按原样"失败"了评估，但实际上为用户想出了更好的解决方案。

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

任务（也叫 problem 或 test case）是一个具有定义输入和成功标准的单次测试。
每次尝试任务是一个 trial（试验）。由于模型输出在运行之间变化，我们运行多个 trial 以产生更一致的结果。
评分器（grader）是对智能体性能的某个方面进行评分的逻辑。一个任务可以有多个评分器，每个评分器包含多个断言（有时称为 checks）。
transcript（也叫 trace 或 trajectory）是一个 trial 的完整记录，包括输出、工具调用、推理、中间结果和任何其他相关数据。
一个评估（eval）是一组任务及其相关评分器和配置。

为什么要构建评估？¶

当团队开始构建智能体时，通过手动测试、dogfooding 和直觉的组合，他们可以取得惊人的进展。更严格的评估甚至可能看似减缓发布的开销。但在早期原型阶段之后，一旦智能体投入生产并开始扩展，没有评估的构建就会开始出问题。

崩溃点通常出现在用户报告变更后智能体感觉更差时，团队"盲目飞行"，除了猜测和检查之外无法验证。缺少评估时，调试是被动的：等待投诉、手动复现、修复 bug、希望没有其他回归。团队无法区分真正的回归和噪音、在发布前自动针对数百个场景测试变更、或衡量改进。

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

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

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

一些团队在开发开始时创建评估；其他团队在评估成为改进智能体瓶颈时大规模添加。评估在智能体开发开始时特别有用，可以明确编码预期行为。两个工程师阅读相同的初始规范，可能对 AI 应如何处理边缘情况有不同的理解。评估套件可以解决这种歧义。无论何时创建，评估都有助于加速开发。

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

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

如何评估 AI 智能体¶

我们看到今天大规模部署了几种常见的智能体类型，包括编码智能体、研究智能体、computer use 智能体和对话智能体。每种类型可能部署在各种行业中，但可以使用类似的技术进行评估。你不需要从头发明评估。以下各节描述了几种智能体类型的经过验证的技术。以这些方法为基础，然后将其扩展到你的领域。

智能体评分器类型¶

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

基于代码的评分器 - 方法：字符串匹配检查（精确、regex、模糊等）、二元测试（fail-to-pass、pass-to-pass）、静态分析（lint、类型、安全）、结果验证、工具调用验证（使用的工具、参数）、transcript 分析（轮次数、token 使用量） - 优势：快速、便宜、客观、可重现、易于调试、可验证特定条件 - 劣势：对不精确匹配预期模式的有效变体很脆弱、缺乏细微差别、对评估一些更主观的任务有限

基于模型的评分器 - 方法：基于 rubric 的评分、自然语言断言、成对比较、基于参考的评估、多 judge 共识 - 优势：灵活、可扩展、捕捉细微差别、处理开放式任务、处理自由格式输出 - 劣势：非确定性、比代码更昂贵、需要与人类评分器校准以确保准确性

人工评分器 - 方法：SME 审查、众包判断、抽样检查、A/B 测试、标注者间一致性 - 优势：黄金标准质量、匹配专家用户判断、用于校准基于模型的评分器 - 劣势：昂贵、缓慢、通常需要大规模获取人类专家

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

Capability 评估 vs. 回归评估¶

Capability 或"质量"评估问的是"这个智能体能做好什么？"它们应该从低通过率开始，目标是智能体感到困难并给团队一个攀登的目标。

回归评估问的是"智能体是否仍然能处理它以前能做的所有任务？"应该有接近 100% 的通过率。它们防止倒退，因为分数下降表明有问题需要改进。随着团队在 capability 评估上攀登，同时运行回归评估以确保变更不会在其他地方造成问题也很重要。

在智能体启动和优化后，高通过率的 capability 评估可以"毕业"成为持续运行的回归套件，以捕获任何漂移。曾经衡量"我们到底能不能做这个？"的任务，随后衡量"我们是否仍然能可靠地做到？"

评估编码智能体¶

编码智能体编写、测试和调试代码，像人类开发者一样导航代码库和运行命令。现代编码智能体的有效评估通常依赖明确定义的任务、稳定的测试环境和对生成代码的全面测试。

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

一旦你有了一组用于验证编码任务关键结果的通过/不通过测试，对 transcript 进行评分通常也很有用。例如，基于启发式的代码质量规则可以不仅仅基于通过测试来评估生成的代码，具有明确 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 来模拟用户。我们在对齐审计智能体中使用这种方法，通过扩展的对抗性对话来压力测试模型。

对话智能体的成功可以是多维度的：工单是否解决（状态检查）、是否在合理时间内完成、交互质量如何等。这种复杂性使得对话智能体评估变得困难。一些框架如 τ-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: "<correct_amount>"}}

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

评估研究智能体¶

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

研究评估面临独特的挑战：专家可能对综合是否全面有分歧，真实情况随着参考内容不断变化而移动，更长更开放的输出创造更多出错空间。像 BrowseComp 这样的基准测试 AI 智能体能否在开放网络上大海捞针——被设计为容易验证但难以解决的问题。

构建研究智能体评估的一种策略是结合评分器类型。基于事实的检查验证声明是否得到检索来源的支持，覆盖检查定义好的答案必须包含的关键事实，来源质量检查确认咨询的来源是权威的，而不仅仅是首先检索到的。对于有客观正确答案的任务（"X 公司的 Q3 收入是多少？"），精确匹配有效。LLM 可以标记不支持的声明和覆盖空白，还可以验证开放性综合的连贯性和完整性。

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

Computer use 智能体¶

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

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

如何思考智能体评估中的非确定性¶

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

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

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

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

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

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

从零到一：构建优秀智能体评估的路线图¶

本节列出了我们经过实践检验的建议，从没有评估到你可以信赖的评估。把这当作评估驱动的智能体开发路线图：尽早定义成功、清晰衡量、持续迭代。

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

第 0 步：尽早开始

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

第 1 步：从你已有的手动测试开始

从你在开发期间运行的手动检查开始——每次发布前验证的行为和终端用户尝试的常见任务。如果你已经在生产中，查看你的 bug 跟踪器和支持队列。将用户报告的故障转换为测试用例可确保你的套件反映实际使用；按用户影响优先级排序帮助你将精力投入在重要之处。

第 2 步：编写明确的任务和参考解决方案

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

每个任务应该可以被正确遵循指令的智能体通过。这可能很微妙。例如，审计 Terminal-Bench 揭示了如果一个任务要求智能体编写脚本但没有指定文件路径，而测试假设了特定的脚本文件路径，智能体可能不是自己的过错而失败。评分器检查的一切应该从任务描述中明确可见；智能体不应因模糊的规范而失败。对于前沿模型，许多 trial 的 0% 通过率（即 0% pass@100）通常是任务损坏的信号，而不是智能体无能，这是需要仔细检查任务规范和评分器的标志。对于每个任务，创建一个参考解决方案很有用：一个已知的工作输出，通过所有评分器。这证明任务是可解的，并验证评分器配置正确。

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

测试行为应该发生和不应该发生的情况。单方面的评估创造单方面的优化。例如，如果你只测试智能体是否在应该搜索时搜索，最终可能得到一个几乎搜索一切的智能体。尽量避免类别不平衡的评估。我们在为 Claude.ai 的网页搜索构建评估时亲身体验了这一点。挑战是防止模型在不应该搜索时搜索，同时保持其在适当时进行广泛研究的能力。团队构建了覆盖两个方向的评估：模型应该搜索的查询（如查找天气）和模型应该从现有知识回答的查询（如"谁创立了 Apple？"）。在触发不足（应该搜索时不搜索）和触发过度（不应该搜索时搜索）之间找到合适的平衡很困难，对 prompt 和评估都进行了多轮改进。随着更多示例问题的出现，我们继续添加到评估中以改善覆盖率。

设计评估框架和评分器¶

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

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

第 5 步：精心设计评分器

如上所述，优秀的评估设计涉及为智能体和任务选择最佳评分器。我们建议在可能的情况下选择确定性评分器，在必要时或需要额外灵活性时使用 LLM 评分器，并明智地使用人工评分器进行额外验证。

人们通常有一种直觉，想检查智能体是否遵循了非常具体的步骤，如按正确顺序的工具调用序列。我们发现这种方法过于僵化，导致过于脆弱的测试，因为智能体经常找到评估设计者没有预料到的有效方法。为了不不必要地惩罚创造性，通常最好评分智能体产出了什么，而不是它采取了什么路径。

对于有多个组件的任务，建立部分学分。一个正确识别问题并验证客户但未能处理退款的支持智能体，比立即失败的智能体要有意义地好。重要的是在结果中表示这种成功的连续体。

模型评分通常需要仔细迭代以验证准确性。LLM-as-judge 评分器应与人类专家密切校准，以确信人类评分和模型评分之间分歧很小。为避免幻觉，给 LLM 一条退路，如提供指令在信息不足时返回"Unknown"。创建清晰、结构化的 rubric 来评分任务的每个维度，然后用隔离的 LLM-as-judge 评分每个维度，而不是用一个评分所有维度，也可能有所帮助。一旦系统健壮，偶尔使用人工审查就足够了。

一些评估有微妙的失败模式，即使智能体性能良好也会导致低分，因为智能体因评分 bug、智能体框架约束或歧义而未能完成任务。即使是成熟的团队也可能遗漏这些问题。例如，Opus 4.5 最初在 CORE-Bench 上得分为 42%，直到 Anthropic 研究人员发现了多个问题：僵化的评分在期望"96.124991…"时惩罚"96.12"、模糊的任务规范、以及不可能精确复现的随机任务。修复 bug 并使用限制较少的框架后，Opus 4.5 的分数跃升至 95%。类似地，METR 在其时间跨度基准中发现了几个配置错误的任务，要求智能体优化到声明的分数阈值，但评分要求超过该阈值。这惩罚了遵循指令的 Claude 等模型，而忽略声明目标的模型获得了更好的分数。仔细检查任务和评分器可以帮助避免这些问题。

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

长期维护和使用评估¶

第 6 步：检查 transcript

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

失败应该是公平的：清楚智能体做错了什么以及为什么。当分数不上升时，我们需要确信这是因为智能体性能而非评估。阅读 transcript 是你验证评估确实衡量了重要事项的方法，是智能体开发的关键技能。

第 7 步：监控 capability 评估饱和度

100% 的评估追踪回归但不提供改进信号。评估饱和度发生在智能体通过了所有可解任务时，没有改进空间。例如，SWE-Bench Verified 分数今年以 30% 起步，前沿模型现在正接近 >80% 的饱和度。随着评估接近饱和，进展也会放缓，因为只有最困难的任务仍然存在。这可能使结果具有欺骗性，大的能力改进表现为分数的小幅增长。例如，代码审查初创公司 Qodo 最初对 Opus 4.5 印象不深，因为他们的一次性编码评估没有捕捉到在更长更复杂任务上的收益。作为回应，他们开发了一个新的智能体评估框架，提供了进展的更清晰画面。

作为规则，我们不会面值接受评估分数，直到有人深入研究评估细节并阅读一些 transcript。如果评分不公平、任务模糊、有效解决方案被惩罚，或框架限制了模型，评估应该修改。

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

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

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

对于 AI 产品团队，拥有和迭代评估应该与维护单元测试一样常规。团队可能在一个"有效"的早期测试中浪费数周的 AI 功能，但未能满足一个设计良好的评估会早早暴露的未声明期望。定义评估任务是压力测试产品需求是否足够具体以开始构建的最佳方法之一。

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

最接近产品需求和用户的人最适合定义成功。以当前的模型能力，产品经理、客户成功经理或销售人员可以使用 Claude Code 贡献一个评估任务作为 PR——让他们来！或者更好的是，主动启用他们。

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

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

方法	优势	劣势
自动化评估	更快迭代；完全可重现；无用户影响；可在每次提交时运行；无需生产部署即可大规模测试场景	需要更多前期投入；随着产品和模型演进需要持续维护以避免漂移；如果不匹配真实使用模式可能产生虚假信心
生产监控	揭示大规模真实用户行为；捕获合成评估遗漏的问题；提供智能体实际表现的真实数据	被动；问题在你知道之前已到达用户；信号可能嘈杂；需要投资仪器化；缺少评分的真实基准
A/B 测试	衡量实际用户结果（留存、任务完成）；控制混淆因素；可扩展和系统化	慢；需要数天或数周达到显著性且需要足够流量；只测试你部署的变更；如果没有彻底审查 transcript 则缺少指标变化背后的"为什么"
用户反馈	揭露你没有预料到的问题；附带真实人类用户的真实示例；反馈通常与产品目标相关	稀疏且自我选择；偏向严重问题；用户很少解释失败原因；非自动化；主要依赖用户发现问题可能产生负面用户影响
手动 transcript 审查	建立失败模式的直觉；捕获自动检查遗漏的微妙质量问题；帮助校准什么是"好的"并理解细节	耗时；不可扩展；覆盖率不一致；审查者疲劳或不同审查者可能影响信号质量；通常只提供定性信号而非清晰的定量评分
系统化人类研究	多个人类评分者的黄金标准质量判断；处理主观或模糊任务；提供改进基于模型的评分器的信号	相对昂贵且周转慢；难以频繁运行；评分者间不一致需要协调；复杂领域（法律、金融、医疗保健）需要人类专家进行研究

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

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

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

结论¶

没有评估的团队陷入被动循环——修复一个故障，造成另一个，无法区分真正的回归和噪音。早期投资的团队发现相反：开发加速，因为故障变成测试用例，测试用例防止回归，指标取代猜测。评估给整个团队一个明确的攀登目标，将"智能体感觉更差"变成可操作的事情。价值是复合的，但前提是你将评估视为核心组件而非事后补充。

模式因智能体类型而异，但此处描述的基本原则是不变的。尽早开始，不要等待完美的套件。从你看到的失败中获取真实任务。定义明确的、健壮的成功标准。精心设计评分器并组合多种类型。确保问题对模型足够难。迭代评估以提高信噪比。阅读 transcript！

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 注册表发布，使运行既定基准和自定义评估套件变得容易。

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

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

Arize 提供 Phoenix（一个用于 LLM 跟踪、调试和离线或在线评估的开源平台）和 AX（一个扩展 Phoenix 用于规模、优化和监控的 SaaS 产品）。

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

另请参阅¶

本文与 anthropic-multi-agent-research-system 中的评估实践密切相关，也可以参考 anthropic-code-execution-mcp 了解工具效率相关内容。