Demystifying evals for AI agents

简介

良好的评估能帮助团队更有信心地发布 AI 智能体。没有评估，团队很容易陷入被动应对的循环——只有在生产环境中才发现问题，而修复一个故障又会引发其他故障。评估能在问题影响用户之前使其显现，其价值会在智能体的整个生命周期中不断累积。

正如我们在构建高效智能体一文中所描述的，智能体需要经过多轮运行：调用工具、修改状态，并根据中间结果进行调整。让 AI 智能体发挥作用的这些能力——自主性、智能和灵活性——也让它们更难评估。

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

评估的结构

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

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

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

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

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

为什么要构建评估？

当团队刚开始构建代理时，仅凭手动测试、自用测试和直觉的组合，就能取得惊人的进展。更严格的评估甚至可能显得像是在拖慢发布进度的额外开销。但在早期原型阶段过后，一旦代理进入生产环境并开始扩展规模，没有评估的开发方式就会开始失灵。

临界点往往出现在用户反馈代理在改动后表现变差、而团队只能“盲飞”的时刻——除了反复猜测验证，别无他法确认问题。没有评估，调试只能被动进行：等待投诉、手动复现、修复 bug，然后祈祷没有其他地方出现回归。团队无法区分真正的回归与噪声，无法在发布前针对数百个场景自动测试改动，也无法衡量改进效果。

我们已经多次目睹这一演进过程。例如，Claude Code 最初依靠 Anthropic 员工和外部用户的反馈进行快速迭代。后来，我们加入了评估——首先针对简洁性和文件编辑等较窄的领域，随后扩展到过度工程化等更复杂的行为。这些评估帮助发现问题、指导改进，并聚焦研究与产品之间的协作。结合生产环境监控、A/B 测试、用户研究等手段，评估为 Claude Code 在规模化过程中的持续改进提供了信号。

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

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

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

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

一旦建立了评估，你就能免费获得基线和回归测试：延迟、token 使用量、每个任务的成本和错误率都可以在静态任务库上进行跟踪。评估还可以成为产品团队与研究团队之间带宽最高的沟通渠道，定义研究人员可以据此优化的指标。显然，评估的益处远不止于跟踪回归和改进。由于成本在前期显而易见，而收益要日积月累才能体现，评估的复利价值很容易被忽视。

如何评估 AI 智能体

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

智能体评分器的类型

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

基于代码的评分器

基于模型的评分器

人工评分员

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

能力评估与回归评估

能力评估或“质量”评估要回答的是：“这个智能体能做好什么？”它们应该从较低的通过率起步，瞄准智能体难以应对的任务，给团队一个可以攀登的高峰。

回归评估要回答的是：“智能体是否还能处理以前能处理的所有任务？”并且通过率应接近 100%。它们能防止性能倒退，因为分数下降意味着某些地方出了问题，需要改进。当团队在能力评估上不断攻坚时，同时运行回归评估也很重要，以确保改动不会在其他地方引发问题。

智能体上线并经过优化后，通过率较高的能力评估可以“毕业”，成为持续运行、用于捕捉任何性能漂移的回归测试套件。曾经衡量“我们究竟能不能做到？”的任务，之后衡量的则是“我们还能否可靠地做到？”

评估编码智能体

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

确定性评分器对编码智能体而言是自然而然的选择，因为软件通常很容易评估：代码能否运行、测试能否通过？两个广泛使用的编码智能体基准——SWE-bench Verified 和 Terminal-Bench——都采用了这种方式。SWE-bench Verified 向智能体提供来自热门 Python 代码库的 GitHub issue，并通过运行测试套件为解决方案评分；只有修复了失败的测试且不破坏现有测试的解决方案才算通过。短短一年间，LLM 在这项评估上的成绩就从 40% 提升到了 >80%。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 评分标准来评估整体代码质量，仅在需要时才添加额外的评分器和指标。

评估对话式智能体

对话式智能体 在支持、销售或辅导等领域与用户交互。与传统聊天机器人不同，它们会维护状态、使用工具，并在对话过程中采取行动。虽然编程和研究智能体也可能涉及与用户的多轮交互，但对话式智能体带来了一个独特的挑战：交互本身的质量也是你评估对象的一部分。有效的对话式智能体评估通常依赖可验证的最终状态结果，以及能同时捕捉任务完成度和交互质量的评分标准。与大多数其他评估不同，这类评估往往需要第二个 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 的评分标准与专家的人工判断进行校准，以便有效地为这些智能体评分。

计算机使用智能体

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

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

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

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

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

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 适用于一致性至关重要的智能体。

从零到一：打造卓越智能体评估的路线图

本节给出了我们经过实践检验的实用建议，帮助你从没有评估发展到拥有值得信赖的评估。可以把它看作评估驱动的智能体开发路线图：尽早定义成功标准，清晰地衡量它，并持续迭代。

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

第 0 步. 尽早开始

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

第 1 步. 从你已在手动测试的内容入手

从你在开发过程中执行的手动检查入手——也就是你每次发布前验证的行为，以及终端用户常尝试的任务。如果你已经上线，可以查看你的 bug 跟踪器和支持队列。把用户报告的失败转化为测试用例，能确保你的测试套件反映实际使用情况；按用户影响排定优先级，有助于你把精力投入到关键之处。

第 2 步：编写带有参考答案的无歧义任务

把任务质量做好比看上去更难。一个好的任务应当是：两名领域专家各自独立评判时会得出相同的通过/失败结论。他们自己能通过这个任务吗？如果不能，该任务就需要改进。任务规范中的歧义会变成指标中的噪音。对于基于模型的评分器的评判标准也是如此：模糊的评分规则会导致不一致的判断。

每个任务都应该能被一个正确遵循指令的智能体完成。这一点可能很微妙。例如，审计 Terminal-Bench 时发现，如果一个任务要求智能体编写脚本但没有指定文件路径，而测试却假定了脚本的某个特定路径，那么智能体可能会在自身没有过错的情况下失败。评分器检查的所有内容都应该能从任务描述中清楚得知；智能体不应因规范含糊而失败。对于前沿模型来说，在多次试验中 0% 的通过率（即 0% pass@100）往往表明任务本身有问题，而不是智能体能力不足，这是需要复查你的任务规范和评分器的信号。对于每个任务，创建一个参考解决方案很有用：一个已知可正常工作且能通过所有评分器的输出。这既证明了任务是可解的，也验证了评分器配置正确。

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

既要测试行为应该发生的情况，也要测试行为不应该发生的情况。单方面的评估会造成单方面的优化。例如，如果你只测试智能体在应该搜索时是否搜索，最终可能会得到一个对几乎所有内容都进行搜索的智能体。尽量避免类别不均衡的评估。我们在为 Claude.ai 构建网页搜索评估时亲身吸取了这一教训。挑战在于防止模型在不该搜索时搜索，同时保留它在适当情况下进行深入研究的能力。团队构建了覆盖两个方向的评估：模型应该搜索的查询（比如查找天气）以及模型应该基于已有知识回答的查询（比如“苹果是谁创立的？”）。在触发不足（该搜索时不搜索）与过度触发（不该搜索时搜索）之间取得恰当的平衡非常困难，需要对提示词和评估进行多轮改进。随着更多示例问题的出现，我们会继续充实评估，以提高覆盖面。

设计评估框架和评分器

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

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

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

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

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

对于包含多个组件的任务，应设置部分得分。一个能正确识别问题并核实客户身份、但未能处理退款的客服智能体，明显好于立即失败的智能体。在结果中体现这种成功的连续性非常重要。

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

有些评测存在微妙的失效模式，即使智能体表现良好，分数也会很低，因为智能体由于评分错误、agent harness 的限制或任务描述的歧义而无法解决任务。即使是最成熟的团队也可能遗漏这些问题。例如，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 产品。

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