解读 AI 智能体评估 \ Anthropic

来源: https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents 抓取时间: 2026-07-21 16:21:43

简介

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

正如我们在构建有效智能体中所描述的，智能体在多轮中运行：调用工具、修改状态，并基于中间结果进行调整。使 AI 智能体有用的这些相同能力——自主性、智能性和灵活性——也使它们更难评估。

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

评估的结构

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

单轮评估很简单：一个提示词、一个响应和评分逻辑。对于早期的 LLM，单轮、非智能体的评估是主要的评估方法。随着 AI 能力的进步，多轮评估变得越来越普遍。 在简单评估中，智能体处理提示词，评分员检查输出是否符合预期。对于更复杂的多轮评估，编码智能体接收工具、任务（在这种情况下是构建 MCP 服务器）和环境，执行"智能体循环"（工具调用和推理），并使用实现更新环境。然后评分使用单元测试验证工作的 MCP 服务器。

智能体评估甚至更复杂。智能体在多轮中使用工具，修改环境中的状态，并随着进行而调整——这意味着错误可以传播和累积。前沿模型还可以找到超越静态评估限制的创造性解决方案。例如，Opus 4.5 通过发现政策中的漏洞，解决了关于预订航班的𝜏2-bench问题。它按照书面"未通过"评估，但实际上为用户提供了更好的解决方案。

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

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

智能体评估的组成部分。

为什么要构建评估？

当团队刚开始构建智能体时，他们可以通过手动测试、内部试用和直觉的结合走得相当远。更严格的评估甚至可能看起来像是减慢发布速度的开销。但在早期原型设计阶段之后，一旦智能体投入生产并开始扩展，没有评估的构建就会开始崩溃。

突破点通常出现在用户报告更改后智能体感觉更糟的时候，团队"盲目飞行"，除了猜测和检查之外无法验证。没有评估，调试是被动的：等待投诉，手动重现，修复错误，并希望没有其他问题回退。团队无法区分真正的回退与噪音，在发布前自动测试数百个场景的更改，或衡量改进。

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

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

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

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

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

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

如何评估 AI 智能体

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

智能体的评分员类型

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

基于代码的评分员

基于模型的评分员

人类评分员

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

能力评估与回归评估

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

回归评估问："智能体是否仍然处理它过去处理的所有任务？"并且应该有接近 100% 的通过率。它们防止倒退，因为分数下降表明有问题需要改进。当团队在能力评估上攀登时，同时运行回归评估以确保更改不会在其他地方引起问题非常重要。

在智能体启动和优化后，具有高通过率的能力评估可以"毕业"成为持续运行的回归套件，以捕获任何漂移。曾经衡量"我们能做到吗？"的任务然后衡量"我们还能可靠地做到吗？"

评估编码智能体

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

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

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

示例：编码智能体的理论评估 考虑一个编码任务，智能体必须修复身份验证绕过漏洞。如下面的说明性 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

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

评估研究智能体

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

研究评估面临独特的挑战：专家可能会对综合是否全面有不同意见，随着参考内容不断变化，基础事实也在变化，更长、更开放的输出为错误创造了更多空间。例如，BrowseComp这样的基准测试 AI 智能体能否在整个开放网络中"大海捞针"——设计成易于验证但难以解决的问题。

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

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

Computer Use 智能体

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

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

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

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

两个指标有助于捕捉这种细微差别： pass@k衡量智能体在 k 次尝试中至少获得一个正确解决方案的可能性。随着 k 的增加，pass@k 分数上升：更多的"射门"意味着至少 1 次成功的几率更高。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。

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

本节列出了我们从没有评估到您可以信任的评估的实用、经过现场测试的建议。将此视为评估驱动的智能体开发的路线图：尽早定义成功，清晰衡量，并持续迭代。

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

步骤 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.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——一个 SaaS 产品，将 Phoenix 扩展到规模、优化和监控。

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