Anthropic 详解 AI 智能体评测：从评分器设计到落地路线图

引言

好的评估能帮助团队更有信心地交付 AI 智能体。没有评估，团队很容易陷入被动循环——只有在生产环境中才发现问题，而修复一个故障又会引发其他故障。评估能在问题影响用户之前就让问题和行为变化变得可见，而且其价值会随着智能体生命周期的推进不断累积。

正如我们在构建高效智能体中所述，智能体要运行许多轮次：调用工具、修改状态，并根据中间结果进行调整。正是这些让 AI 智能体变得有用的能力——自主性、智能和灵活性——也让它们更难被评估。

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

评估的结构

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

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

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

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

• 一个任务（又称问题或测试用例）是一次带有既定输入和成功标准的测试。
• 对任务的每一次尝试称为一次试验。由于模型输出在不同运行之间会有差异，我们会运行多次试验以获得更一致的结果。
• 评分器是对智能体表现的某个方面进行打分的逻辑。一个任务可以有多个评分器，每个评分器包含多个断言（有时称为检查项）。
• 一份记录（也称为追踪或轨迹）是一次试验的完整记录，包括输出、工具调用、推理、中间结果以及任何其他交互。对于 Anthropic API，这就是一次评估运行结束时完整的 messages 数组——包含评估期间对 API 的所有调用以及所有返回的响应。
• 结果是试验结束时环境中的最终状态。一个航班预订代理可能会在对话记录末尾说“您的航班已预订”，但结果取决于环境 SQL 数据库中是否存在一条预订记录。
• 评估框架是端到端运行评估的基础设施。它提供指令和工具，并发运行任务，记录所有步骤，对输出进行评分，并汇总结果。
• 代理框架（或脚手架）是使模型能够作为代理行动的系统：它处理输入、编排工具调用并返回结果。当我们评估“一个代理”时，我们评估的是框架和模型协同工作。例如，Claude Code 是一个灵活的代理框架，我们通过 Agent SDK 使用其核心原语来构建我们的长时间运行代理框架。
• 评估套件是一组旨在衡量特定能力或行为的任务。套件中的任务通常共享一个宽泛的目标。例如，一个客户支持评估套件可能会测试退款、取消和升级。

为什么要构建评估？

当团队刚开始构建代理时，他们可以通过手动测试、dogfooding 和直觉的结合取得惊人的进展。更严格的评估甚至可能看起来像是拖慢交付的开销。但在早期原型阶段之后，一旦代理投入生产并开始扩展，没有评估的构建就开始崩溃。

临界点通常出现在用户报告代理在更改后感觉更糟，而团队“盲目飞行”，除了猜测和检查之外无法验证。没有评估，调试是被动的：等待投诉，手动复现，修复错误，并希望没有其他东西退化。团队无法区分真正的退化与噪声，无法在发布前自动针对数百个场景测试更改，也无法衡量改进。

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

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

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

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

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

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

如何评估 AI 智能体

我们看到如今有几种常见类型的智能体已大规模部署，包括编码智能体、研究智能体、计算机使用智能体和对话智能体。每种类型可能部署在众多行业中，但都可以使用类似的技术进行评估。你不需要从零开始发明一套评估方法。以下各节描述了几种智能体类型经过验证的技术。将这些方法作为基础，然后扩展到你的领域。

智能体的评分器类型

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

基于代码的评分器

基于模型的评分器

人工评分者

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

能力评估与回归评估

能力或“质量”评估问的是：“这个 agent 擅长做什么？”它们应该从较低的通过率开始，针对 agent 难以完成的任务，给团队一个需要攀登的高峰。

回归评估问的是：“这个 agent 是否仍能处理它过去能处理的所有任务？”并且应该具有接近 100% 的通过率。它们防止倒退，因为分数下降表明某些东西坏了，需要改进。当团队在能力评估上不断攀登时，同时运行回归评估也很重要，以确保更改不会在其他地方引发问题。

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

评估编码 agent

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

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

一旦你有一组用于验证编码任务关键结果的通过或失败测试，通常也很有用的一点是给转录记录评分。例如，基于启发式的代码质量规则可以根据通过测试之外的标准来评估生成的代码，而具有清晰评分标准的基于模型的评分者可以评估 agent 如何调用工具或与用户交互等行为。

示例：编码 agent 的理论评估

考虑一个编码任务，agent 必须修复一个认证绕过漏洞。如下面的示例 YAML 文件所示，可以使用评分者和指标来评估这个 agent。 

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

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

评估研究智能体

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

研究评估面临独特的挑战：专家们可能对综合是否全面存在分歧，随着参考内容不断变化，真实基准也会发生变化，而更长、更开放式的输出为错误留下了更多空间。例如，像 BrowseComp 这样的基准测试 AI 智能体能否在开放网络中大海捞针——这些问题被设计为易于验证但难以解决。

构建研究型 agent 评估的一种策略是组合多种评分器类型。Groundedness 检查验证论断是否有检索到的来源支持，coverage 检查定义了一个好答案必须包含的关键事实，而 source quality 检查则确认所查阅的来源具有权威性，而不仅仅是首次检索到的来源。对于有客观正确答案的任务（“公司 X 的 Q3 营收是多少？”），精确匹配即可奏效。LLM 可以标记出无支持的论断和覆盖缺口，同时也能验证开放式综合内容的连贯性和完整性。

鉴于研究质量具有主观性，基于 LLM 的评分标准应经常与专家人工判断进行校准，以有效评估这些 agent。

Computer use agents

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

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

如何看待 agent 评估中的非确定性

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

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

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

pass^k 衡量的是 全部 k 次试验都成功的概率。随着 k 增大，pass^k 会下降，因为在更多次试验中都要求保持一致是一个更难达到的标准。如果你的 agent 单次试验成功率为 75%，而你运行 3 次试验，那么三次全部通过的概率是 (0.75)³ ≈ 42%。这一指标对于面向客户的 agent 尤为重要，因为用户期望每次都能获得可靠的行为。

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

从零到一：为 agent 打造优秀评估的路线图

本节阐述我们从无评估走向可信评估的实用且经过实践检验的建议。可以把它看作一条以评估驱动 agent 开发的路线图：尽早定义成功，清晰地衡量它，并持续迭代。

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

第 0 步：尽早开始

我们看到团队迟迟不构建评估，因为他们认为自己需要数百个任务。实际上，从真实失败中提取的 20-50 个简单任务就是一个很好的起点。毕竟，在 agent 开发的早期，系统的每一次改动往往都有清晰、显著的影响，而这种较大的效应量意味着小样本量就足够了。更成熟的 agent 可能需要更大、更困难的评估来检测更小的效应，但一开始最好采用 80/20 方法。等待越久，评估就越难构建。早期阶段，产品需求会自然地转化为测试用例。等得太久，你就只能从运行中的系统反向推导成功标准。

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

从你在开发过程中运行的手动检查开始——也就是每次发布前你验证的行为，以及最终用户会尝试的常见任务。如果你已经上线，就查看你的缺陷跟踪系统和支持队列。把用户报告的失败转化为测试用例，可以确保你的测试套件反映实际使用情况；按用户影响排序，有助于你把精力投入到最关键的地方。

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

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

每个任务都应能被一个正确遵循指令的 agent 通过。这一点可能很微妙。例如，审计 Terminal-Bench 时发现，如果某个任务要求 agent 编写一个脚本，但没有指定文件路径，而测试却假定脚本位于某个特定文件路径，那么 agent 可能会在并非自身过错的情况下失败。评分器所检查的一切都应当能从任务描述中清晰得知；agent 不应因规格含糊而失败。对于前沿模型而言，在多次试验中通过率为 0%（即 pass@100 为 0%）通常更多是任务本身有问题的信号，而非 agent 能力不足，也是提醒你仔细检查任务规格和评分器的信号。对于每个任务，创建一个参考解是很有用的：一个已知能通过所有评分器的可用输出。这可以证明该任务是可解的，并验证评分器配置正确。

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

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

设计评估框架和评分器

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

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

第 5 步：精心设计评分器

如上所述，出色的评估设计涉及为 agent 和任务选择最合适的评分器。我们建议在可能的情况下选择确定性评分器，在必要时或为了额外灵活性选择 LLM 评分器，并审慎使用人工评分器进行额外验证。

人们有一种常见的本能，就是检查智能体是否遵循了非常具体的步骤，比如按正确顺序执行一系列工具调用。我们发现这种方法过于僵化，会导致测试极其脆弱，因为智能体经常会找到评估设计者未曾预料到的有效方法。为了不无谓地惩罚创造力，通常更好的做法是评估智能体产出的结果，而不是它采取的路径。

对于包含多个组件的任务，要设置部分得分。一个能正确识别问题并验证客户身份、但未能处理退款的客服智能体，明显优于一个一开始就失败的智能体。在结果中体现这种成功程度的连续性很重要。

模型评分通常需要仔细迭代以验证准确性。LLM-as-judge 评分器应与人类专家密切校准，以确信人类评分与模型评分之间几乎没有分歧。为避免幻觉，要给 LLM 留一条退路，比如提供一条指令，让它在信息不足时返回“Unknown”。创建清晰、结构化的评分标准来评估任务的每个维度，然后用独立的 LLM-as-judge 分别评估每个维度，而不是用一个来评估所有维度，这也会有所帮助。一旦系统足够稳健，只需偶尔使用人工审核即可。

有些评估存在微妙的失败模式，即使智能体表现良好也会导致低分，因为智能体未能解决任务是由于评分缺陷、智能体运行框架限制或任务描述含糊。即使是经验丰富的团队也可能忽略这些问题。例如，Opus 4.5 最初在 CORE-Bench 上得分 42%，直到一位 Anthropic 研究员发现了多个问题：僵化的评分在期望“96.124991…”时却对“96.12”扣分、任务描述含糊，以及无法精确复现的随机性任务。在修复缺陷并使用限制更少的运行框架后，Opus 4.5 的得分跃升至 95%。同样，METR 发现其时间跨度基准中有若干任务配置错误，这些任务要求智能体优化到某个指定的分数阈值，但评分却要求超过该阈值。这惩罚了像 Claude 这样遵循指令的模型，而忽略既定目标的模型反而获得了更好的分数。仔细复核任务和评分器有助于避免这些问题。

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

长期维护并使用评估

第 6 步：检查对话记录

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

失败应当显得公平：智能体错在哪里以及为什么错都清清楚楚。当分数上不去时，我们需要确信这是智能体表现所致，而非评估本身的问题。阅读对话记录是你验证评估是否在衡量真正重要之事的方式，也是智能体开发的一项关键技能。

第 7 步：监控能力评估饱和

100% 的评估能追踪回归，但无法提供改进信号。评估饱和发生在智能体通过了所有可解任务、再无改进空间之时。例如，SWE-Bench Verified 的分数今年年初为 30%，而前沿模型如今已接近饱和，达到 >80%。随着评估接近饱和，进展也会放缓，因为只剩下最困难的任务。这会让结果具有欺骗性，因为巨大的能力提升可能只表现为分数的小幅增长。例如，代码审查初创公司 Qodo 起初对 Opus 4.5 印象平平，因为他们的单次编码评估未能捕捉到在更长、更复杂任务上的提升。为此，他们开发了一套新的智能体评估框架，从而更清晰地呈现了进展。

作为一条规则，在有人深入评估细节并阅读一些记录之前，我们不会只看评估分数就信以为真。如果评分不公平、任务含糊不清、有效解法被扣分，或测试框架限制了模型，那么该评估就应当修订。 

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

评估套件是一件活的产物，需要持续关注和明确的归属才能保持有用。

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

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

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

最贴近产品需求和用户的人最有资格定义成功。以当前的模型能力，产品经理、客户成功经理或销售人员都可以使用 Claude Code 以 PR 的形式贡献评估任务——让他们去做吧！或者更好的是，主动赋能他们。

评估如何与其他方法结合，以全面理解智能体

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

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

这些方法对应智能体开发的不同阶段。自动化评估在发布前和 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 专为在容器化环境中运行智能体而设计，提供跨云服务商大规模运行试验的基础设施，以及用于定义任务和评分器的标准化格式。Terminal-Bench 2.0 等流行基准通过 Harbor 注册表发布，因此可以轻松运行既有基准以及自定义评估套件。

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

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

Arize 提供 Phoenix——一个用于 LLM 追踪、调试以及离线或在线评估的开源平台，以及 AX——一个扩展 Phoenix 以实现规模化、优化和监控的 SaaS 产品。

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