AI Agent 评测详解

本文翻译自 Anthropic 官方博客：Demystifying evals for AI agents

引言

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

正如我们在《构建有效的 agents》中所描述的，agents 在多轮对话中运行：调用工具、修改状态、根据中间结果进行调整。这些让 AI agents 有用的能力——自主性、智能和灵活性——也使它们更难评估。

通过我们的内部工作以及与处于 agent 发展前沿的客户合作，我们学会了如何为 agents 设计更严格、更有用的评估。以下是在实际部署中，各种 agent 架构和用例中证明有效的方法。

评估的结构

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

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

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

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

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

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

Agent 评估的组件。

为什么要构建评估？

当团队开始构建 agents 时，他们可以通过手动测试、内部试用和直觉的组合取得惊人的进展。更严格的评估甚至可能看起来是减缓发布的开销。但在早期原型阶段之后，一旦 agent 投入生产并开始扩展，没有评估的构建就开始崩溃。

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

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

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

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

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

评估还影响您采用新模型的速度。当更强大的模型出现时，没有评估的团队面临数周的测试，而拥有评估的团队可以快速确定模型的优势，调整他们的提示，并在几天内升级。

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

如何评估 AI agents

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

Agent 评分器的类型

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

基于代码的评分器

基于模型的评分器

人工评分器

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

能力评估 vs 回归评估

能力或"质量"评估问"这个 agent 能做什么好？"它们应该以低通过率开始，针对 agent 挣扎的任务，给团队一个攀登的山坡。

回归评估问"agent 是否仍然处理它以前处理的所有任务？"，应该具有几乎 100% 的通过率。它们防止倒退，因为分数下降表明有问题需要改进。当团队在能力评估上爬山时，运行回归评估以确保更改不会在其他地方引起问题也很重要。

在 agent 发布和优化后，具有高通过率的能力评估可以"毕业"成为连续运行的回归套件，以捕捉任何漂移。曾经测量"我们能否做到这一点？"的任务然后测量"我们能否可靠地做到这一点？"

评估编码 agents

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

确定性评分器对于编码 agents 是自然的，因为软件通常很容易评估：代码是否运行，测试是否通过？两个广泛使用的编码 agent 基准，SWE-bench Verified 和 Terminal-Bench，遵循这种方法。SWE-bench Verified 给 agents 来自流行 Python 存储库的 GitHub 问题，并通过运行测试套件来评分解决方案；只有解决方案修复了失败的测试而没有破坏现有的测试才能通过。LLM 在一年内在这个评估上从 40% 进步到 >80%。Terminal-Bench 采取不同的轨道：它测试端到端的技术任务，例如从源代码构建 Linux 内核或训练 ML 模型。

一旦您有一组通过或失败的测试来验证编码任务的关键结果，通常也对记录评分很有用。例如，基于启发式的代码质量规则可以基于通过测试来评估生成的代码，而具有明确标准的基于模型的评分器可以评估行为，如 agent 如何调用工具或与用户交互。

示例：编码 agent 的理论评估

考虑一个编码任务，其中 agent 必须修复身份验证绕过漏洞。如下面的说明性 YAML 文件所示，可以使用评分器和指标来评估此 agent。

task:
  id: "fix-auth-bypass_1"
  desc: "修复密码字段为空时的身份验证绕过..."
  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 标准评估整体代码质量，仅在需要时添加额外的评分器和指标。

评估对话 agents

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

对话 agents 的成功可能是多维的：票是否解决（状态检查）、是否在 < 10 轮内完成（记录约束）、语气是否适当（LLM 标准）？两个结合多维度的基准是 𝜏-Bench 及其继任者 τ2-Bench。这些模拟跨零售支持和航空公司预订等领域的多轮互动，其中一个模型扮演用户角色，而 agent 导航现实场景。

示例：对话 agent 的理论评估

考虑一个支持任务，其中 agent 必须为愤怒的客户处理退款。

graders:
  - type: llm_rubric
    rubric: prompts/support_quality.md
    assertions:
      - "Agent 对客户的挫败感表示同情"
      - "解决方案得到了清楚的解释"
      - "Agent 的响应基于 fetch_policy 工具结果"
  - 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

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

评估研究 agents

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

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

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

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

计算机使用 agents

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

浏览器使用 agents 需要在 token 效率和延迟之间取得平衡。基于 DOM 的交互执行很快但消耗许多 token，而基于截图的交互较慢但更 token 高效。例如，当要求 Claude 总结 Wikipedia 时，从 DOM 中提取文本更有效。在 Amazon 上找到新的笔记本电脑壳时，截图更有效（因为提取整个 DOM 是 token 密集的）。在我们的 Chrome 版 Claude 产品中，我们开发了评估来检查 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%。这个指标对于面向客户的 agents 尤其重要，用户期望每次都有可靠的行为。

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

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

从零到一：构建优秀 agent 评估的路线图

本节概述了我们从没有评估到可以信任的评估的实用、经过现场测试的建议。将此视为评估驱动的 agent 开发的路线图：尽早定义成功，清楚地衡量它，持续迭代。

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

步骤 0. 尽早开始

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

步骤 1. 从您已经手动测试的开始

从您在开发过程中运行的手动检查开始——您在每个发布之前验证的行为和最终用户尝试的常见任务。如果您已经投入生产，请查看您的错误跟踪器和支持队列。将用户报告的失败转换为测试用例可确保您的套件反映实际使用；按用户影响优先级有助于您在重要地方投资。

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

使任务质量正确比看起来更难。一个好的任务是两个领域专家可以独立达到相同通过/失败判定的任务。他们自己能通过任务吗？如果不能，任务需要细化。任务规范中的歧义成为指标中的噪声。这同样适用于基于模型的评分器的标准：模糊的标准会产生不一致的判断。

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

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

测试行为应该发生和不应该发生的情况。单方面的评估创造单方面的优化。例如，如果您只测试 agent 是否在应该的时候搜索，您可能最终得到一个几乎搜索所有内容的 agent。尽量避免类别不平衡的评估。

我们在为 Claude.ai 中的网络搜索构建评估时亲身学到了这一点。挑战是防止模型在不应该的时候搜索，同时保留它在适当时候进行广泛研究的能力。团队构建了涵盖两个方向的评估：模型应该搜索的查询（如查找天气）和应该从现有知识回答的查询（如"谁创立了 Apple？"）。在触发不足（应该在时没有搜索）或过度触发（不应该搜索时搜索）之间取得正确的平衡是困难的，并且需要对提示和评估进行多轮改进。随着更多示例问题的出现，我们继续添加到评估中以改进我们的覆盖范围。

设计评估框架和评分器

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

评估中的 agent 功能与生产中使用的 agent 大致相同，并且环境本身不会引入进一步的噪声，这至关重要。每个试验应该通过从干净的环境开始来"隔离"。运行之间不必要的共享状态（剩余文件、缓存数据、资源耗尽）可能导致由于基础设施不稳定性而不是 agent 性能的相关失败。共享状态还可能人为地提高性能。例如，在一些内部评估中，我们观察到 Claude 通过检查以前试验的 git 历史记录在某些任务上获得不公平的优势。如果多个不同的试验由于环境中的相同限制（如有限的 CPU 内存）而失败，这些试验不是独立的，因为它们受到相同因素的影响，评估结果对于衡量 agent 性能变得不可靠。

步骤 5：深思熟虑地设计评分器

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

有一种常见的本能来检查 agents 是否遵循了非常具体的步骤，比如按正确顺序的工具调用序列。我们发现这种方法太僵化，导致过于脆弱的测试，因为 agents 经常找到评估设计者没有预料到的有效方法。为了不必要地惩罚创造力，最好评估 agent 产生的内容，而不是它采取的路径。

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

模型评分通常需要仔细迭代来验证准确性。LLM 作为判官的评分器应与人类专家密切校准，以获得信心，即人工评分和模型评分之间分歧很小。为避免幻觉，给 LLM 一条出路，比如提供指令，当它没有足够信息时返回"Unknown"。创建清晰、结构化的标准来评估任务的每个维度，然后使用孤立的 LLM 作为判官来评估每个维度，而不是使用一个来评估所有维度，这也很有帮助。一旦系统强大，偶尔使用人工审查就足够了。

一些评估有微妙的失败模式，即使 agent 性能良好也会导致低分，因为 agent 由于评分错误、agent 框架约束或歧义而无法解决任务。即使是复杂的团队也可能错过这些问题。例如，Opus 4.5 在 CORE-Bench 上最初得分 42%，直到 Anthropic 研究人员发现了多个问题：僵化的评分，当期望"96.124991..."时惩罚"96.12"，模糊的任务规范，以及不可能完全重现的随机任务。修复错误并使用较少受限的框架后，Opus 4.5 的分数跳升至 95%。同样，METR 在他们的时间范围基准中发现了几个错误配置的任务，要求 agents 优化到声明的分数阈值，但评分要求超过该阈值。这惩罚了像 Claude 这样遵循指令的模型，而忽略既定目标的模型获得更好的分数。仔细检查任务和评分器有助于避免这些问题。

使您的评分器抵抗绕过或黑客攻击。Agent 不应该能够轻易"欺骗"评估。任务和评分器应设计为通过真正需要解决问题而不是利用意外漏洞。

长期维护和使用评估

步骤 6：检查记录

除非您阅读来自多次试验的记录和成绩，否则您不会知道您的评分器是否工作良好。在 Anthropic，我们投资了查看评估记录的工具，我们经常花时间阅读它们。当任务失败时，记录会告诉您 agent 是否犯了真正的错误或您的评分器拒绝了有效的解决方案。它还经常显示有关 agent 和评估行为的关键细节。

失败应该是公平的：清楚 agent 错在哪里以及为什么。当分数没有上升时，我们需要信心这是由于 agent 性能而不是评估。阅读记录是您验证评估是否衡量真正重要的东西的方法，这是 agent 开发的一项关键技能。

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

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

作为一个规则，我们不相信评估分数，直到有人深入研究评估的细节并阅读一些记录。如果评分不公平、任务模糊、有效的解决方案受到惩罚，或者框架限制了模型，则应修改评估。

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

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

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

对于 AI 产品团队，拥有和迭代评估应该像维护单元测试一样例行。团队可能会在 AI 功能上浪费数周，这些功能在早期测试中"工作"，但未能满足精心设计的评估会早期暴露的未说明期望。定义评估任务是压力测试产品需求是否足够具体以开始构建的最佳方法之一。

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

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

创建有效评估的过程。

评估与其他方法如何结合以全面理解 agents

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

理解 AI agent 性能的方法概述

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

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

最有效的团队结合这些方法 - 自动化评估用于快速迭代，生产监控用于基本事实，定期人工审查用于校准。

结论

没有评估的团队陷入被动循环 - 修复一个失败，创建另一个，无法区分真正的回归和噪声。早期投资的团队发现相反：随着失败变成测试用例、测试用例防止回归、指标取代猜测工作，开发加速。评估给整个团队一个明确的山坡攀登，将"agent 感觉更差"变成可操作的东西。价值复合，但只有当您将评估视为核心组件而不是事后想法时。

模式因 agent 类型而异，但这里描述的基本原理是不变的。尽早开始，不要等待完美的套件。从您看到的失败中获得现实任务。定义明确、强大的成功标准。深思熟虑地设计评分器并组合多种类型。确保问题对模型来说足够困难。迭代评估以提高其信噪比。阅读记录！

AI agent 评估仍然是一个新兴的、快速发展的领域。随着 agents 承担更长的任务，在多 agent 系统中协作，并处理越来越主观的工作，我们需要调整我们的技术。我们将继续分享最佳实践，因为我们会了解更多。

致谢

由 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 开发了评估实践。

附录：评估框架

几个开源和商业框架可以帮助团队从零开始构建基础设施来实现 agent 评估。正确的选择取决于您的 agent 类型、现有堆栈，以及您是否需要离线评估、生产可观察性或两者兼而有之。

Harbor 专为在容器化环境中运行 agents 而设计，具有跨云提供商大规模运行试验的基础设施，以及定义任务和评分器的标准化格式。像 Terminal-Bench 2.0 这样的流行基准通过 Harbor 注册表提供，使运行既定基准和自定义评估套件变得容易。

Promptfoo 是一个轻量级、灵活和开源的框架，专注于用于提示测试的声明性 YAML 配置，断言类型从字符串匹配到 LLM 作为判官的标准。我们在许多产品评估中使用了一个版本的 Promptfoo。

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

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

许多团队结合多个工具，推出自己的评估框架，或者只是使用简单的评估脚本作为起点。我们发现，虽然框架可以是加速进步和标准化的有价值方式，但它们只有与您运行的评估任务一样好。通常最好快速选择适合您工作流程的框架，然后通过迭代高质量测试用例和评分器将精力投入到评估本身。