让智能体有用的能力，也使其难以评估。跨部署有效的策略需要组合多种技术，来匹配被衡量系统的复杂度。

引言

好的评测能帮助团队更有信心地交付 AI 智能体。没有评测，很容易陷入被动循环——只在生产环境里发现问题，而修复一个失败往往会引发其他问题。评测让问题和行为变化在影响用户之前可见，其价值会在智能体的生命周期内不断累积。

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

通过内部实践以及与处在智能体开发前沿的客户合作，我们学会了如何为智能体设计更严格、更有用的评测。下面总结的是在真实部署中、覆盖多种智能体架构与用例的有效做法。

评测的结构

评测（evaluation，“eval”）是对 AI 系统的测试：给 AI 一个输入，再对输出应用评分逻辑来衡量成功与否。在本文中，我们聚焦于自动化评测，它们可在开发期间运行而无需真实用户。

单轮评测很直接：一个提示、一条回复、再加评分逻辑。对于早期 LLM，单轮、非智能体评测是主要评测方法。随着 AI 能力提升，多轮评测变得越来越常见。

智能体评测更加复杂。智能体会在多轮中使用工具、修改环境状态并不断适配——这意味着错误会传播并叠加。前沿模型也能找到超出静态评测设想的创意解法。例如，Opus 4.5 在一个关于订机票的 𝜏2-bench 问题上，通过发现策略漏洞而完成任务。它在既定评测中“失败”了，但其实给出了更好的用户方案。

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

• 任务（task，也称问题或测试用例）是一个具备明确输入与成功标准的单个测试。
• 每次尝试一个任务称为一次试次（trial）。由于模型输出在不同运行间会变化，我们会运行多次试次以获得更一致的结果。
• 评分器（grader）是对智能体表现某个方面进行打分的逻辑。一个任务可以有多个评分器，每个评分器包含多个断言（有时称为检查）。
• 记录（transcript，也称trace或trajectory）是一次试次的完整记录，包含输出、工具调用、推理、中间结果以及其他交互。对于 Anthropic API，这就是一次评测运行结束时的完整消息数组——包含所有 API 调用及其返回。
• 结果（outcome）是试次结束时环境中的最终状态。订票智能体的记录里可能写着“你的机票已预订”，但真正的结果是环境的 SQL 数据库中是否存在预订记录。
• 评测框架（evaluation harness）是端到端运行评测的基础设施。它提供指令和工具、并行运行任务、记录所有步骤、评分输出并汇总结果。
• 智能体框架（agent harness，或 scaffold）是让模型以智能体形式行动的系统：处理输入、编排工具调用并返回结果。我们评测“一个智能体”时，评估的是框架与模型的协作。例如，Claude Code 是一个灵活的智能体框架，我们在构建长程智能体框架时，通过Agent SDK使用了其核心原语。
• 评测套件（evaluation suite）是为衡量特定能力或行为而设计的一组任务。套件中的任务通常有一个共同的宏观目标。例如，客服评测套件可能测试退款、取消和升级处理。

为什么要构建评测？

当团队刚开始构建智能体时，往往可以依靠手动测试、狗粮测试和直觉取得进展。更严格的评测甚至看起来像会拖慢交付的开销。但当智能体进入生产并开始规模化之后，没有评测的开发就会失灵。

转折点通常出现在用户报告“改了之后更差”，而团队“盲飞”，只能靠猜测验证。没有评测时，调试是被动的：等投诉、手动复现、修 bug、再祈祷别回归。团队无法区分真实回归与噪声，也无法在上线前自动对数百种场景做回归测试，更无法衡量改进。

我们多次看到这一过程。例如，Claude Code 起初依赖 Anthropic 员工和外部用户的反馈快速迭代。后来我们加入评测——先在简洁性和文件编辑等窄域，然后扩展到过度工程等更复杂的行为。这些评测帮助识别问题、指导改进，并聚焦研究与产品协作。结合线上监控、A/B 测试、用户研究等，评测为持续提升 Claude Code 提供了信号。

在智能体生命周期的任何阶段编写评测都很有用。早期，评测迫使产品团队明确智能体的成功标准；后期，评测有助于维持一致的质量门槛。

Descript 的智能体帮助用户编辑视频，因此他们围绕成功编辑工作流的三维度构建评测：不破坏东西、做我要求的事、且做得好。他们从人工评分发展到由产品团队制定标准的 LLM 评分器，并定期由人工校准，如今持续运行两个独立套件用于质量基准和回归测试。Bolt AI 团队在智能体已广泛使用后才开始搭建评测。三个月内，他们构建了一个评测系统：运行智能体并用静态分析评分、用浏览器智能体测试应用、并用 LLM 评审诸如遵循指令等行为。

一些团队在开发初期就建立评测，另一些团队在规模化时才加评测，当评测成为提升瓶颈后再投入。评测在智能体开发早期尤其有用，因为它明确编码了期望行为。两个工程师读同一份初始规格，可能对 AI 如何处理边缘情况产生不同理解。评测套件能消除这种歧义。无论何时创建，评测都会加速开发。

评测还影响你采用新模型的速度。更强模型出现时，没有评测的团队需要数周测试，而有评测的团队能快速确定模型优势、调整提示，并在数天内升级。

一旦有了评测，就免费获得基线与回归测试：延迟、token 使用、单任务成本、错误率都能在固定任务集上跟踪。评测也能成为产品与研究团队之间带宽最高的沟通渠道，定义研究者可优化的指标。显然，评测的收益远超追踪回归与改进。其复利价值很容易被忽视，因为成本立刻可见，而收益在后期累积。

如何评估 AI 智能体

当下我们看到多种在规模化部署的智能体类型，包括编码智能体、研究智能体、电脑使用智能体，以及对话智能体。每种类型都可能在多行业部署，但它们可以用类似方法评估。你不必从零发明评测。下文描述了多种智能体类型的成熟方法。以此为基础，再扩展到你的领域。

智能体评分器的类型

智能体评测通常结合三类评分器：基于代码、基于模型、以及人工。每个评分器评估记录或结果的一部分。有效评测设计的关键是为工作选择合适评分器。

基于代码的评分器

方法	优势	劣势
• 字符串匹配（精确、正则、模糊等）
• 二元测试（fail-to-pass、pass-to-pass）
• 静态分析（lint、类型、安全）
• 结果验证
• 工具调用验证（使用的工具、参数）
• 记录分析（轮数、token 使用）	• 快
• 便宜
• 客观
• 可复现
• 易调试
• 验证特定条件
• 对合理的变体很脆弱，无法匹配预期模式时会失败
• 缺少细腻性
• 对某些更主观的任务能力有限

基于模型的评分器

方法	优势	劣势

• 基于量表的评分
• 自然语言断言
• 成对比较
• 参考答案评估
• 多评审共识

|

• 灵活
• 可扩展
• 能捕捉细微差别
• 适用于开放式任务
• 能处理自由形式输出

|

• 非确定性
• 比代码评分更贵
• 需要与人工评分器校准以保证准确性

人工评分器

方法	优势	劣势

• 专家评审
• 众包判断
• 抽样复核
• A/B 测试
• 评审一致性

|

• 质量金标准
• 更符合专家用户判断
• 用于校准模型评分器

|

• 昂贵
• 缓慢
• 常常需要规模化的专家资源

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

能力评测 vs. 回归评测

能力评测或“质量”评测回答“这个智能体擅长做什么？”它们应从较低通过率起步，针对智能体不擅长的任务，为团队提供可以攀登的山坡。

回归评测回答“智能体是否仍然能处理过去能处理的所有任务？”它们应该接近 100% 通过率。它们防止回退：分数下降意味着某处出错，需要改进。团队在能力评测上爬坡时，也应同时运行回归评测以确保变更不会引发其他问题。

在智能体上线并优化后，通过率较高的能力评测可以“毕业”为持续运行的回归套件，用于捕捉漂移。曾经衡量“能不能做到”的任务，转而衡量“还能否可靠做到”。

评估编码智能体

编码智能体会写、测、调试代码，浏览代码库并运行命令，方式类似人类开发者。对现代编码智能体的有效评测通常依赖定义清晰的任务、稳定的测试环境以及对生成代码的充分测试。

确定性评分器对编码智能体很自然，因为软件通常易于评估：代码能否运行？测试是否通过？两个广泛使用的编码智能体基准——SWE-bench Verified 与 Terminal-Bench——都采用这种方式。SWE-bench Verified 提供来自流行 Python 仓库的 GitHub 问题，通过运行测试套件评分；只有在修复失败测试且不破坏既有测试时才算通过。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

Copy

请注意，此示例为了说明而展示了完整的评分器范围。实际中，编码评测通常依赖单元测试验证正确性，并用 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

Copy

如同编码智能体示例，本任务为了说明而展示了多种评分器。在实际中，对话智能体评测通常使用基于模型的评分器来评估沟通质量与目标完成度，因为许多任务——例如回答问题——可能有多个“正确”解法。

评估研究智能体

研究智能体会收集、综合和分析信息，然后输出答案或报告。与编码智能体的单元测试提供二元通过/失败信号不同，研究质量只能相对于任务来判断。什么算“全面”“有据可依”甚至“正确”，取决于情境：市场扫描、并购尽调、科学报告各有不同标准。

研究评测面临独特挑战：专家可能对综合内容是否全面存在分歧，参考内容持续变化导致真实标准漂移，且更长、更开放的输出带来更多出错空间。比如 BrowseComp 测试 AI 智能体能否在开放网络中找“草堆里的针”——问题易验证但难解决。

构建研究智能体评测的一种策略是组合不同类型的评分器。基于来源的可信度检查验证主张是否由检索来源支持；覆盖性检查定义一个好答案必须包含的关键事实；来源质量检查确保所用来源权威，而非只是最先检索到的。对于有客观正确答案的问题（如“公司 X 的 Q3 收入是多少？”），精确匹配就足够。LLM 可以标记未经支持的主张和覆盖缺口，也能验证开放式综合的连贯性与完整性。

鉴于研究质量的主观性，基于 LLM 的量表应经常与专家人工判断校准，以有效评估这些智能体。

电脑使用智能体

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

浏览器使用智能体需要在 token 效率与延迟之间取得平衡。基于 DOM 的交互执行快但耗 token，多截图的交互更慢但更省 token。比如，让 Claude 总结维基百科时，从 DOM 提取文本更高效；而在亚马逊寻找新的笔记本电脑壳时，用截图更高效（提取整页 DOM 的 token 成本很高）。在我们的 Claude for Chrome 产品中，我们开发了评测来检查智能体是否在不同情境选择了正确工具，从而更快更准确地完成浏览器任务。

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

无论智能体类型如何，行为都会在不同运行间变化，这使评测结果比看起来更难解释。每个任务都有自己的成功率——可能某任务 90%，另一个 50%——同一任务在一次评测中通过，下一次却失败。有时我们真正想衡量的是智能体成功的频率（在试次中成功的比例）。

两个指标有助于捕捉这种细节：

pass@k 衡量在 k 次尝试中至少获得一个正确解的概率。随着 k 增大，pass@k 提升——“射门”越多，至少一次成功的概率越高。pass@1 为 50% 表示模型在评测中的任务有一半能在第一次尝试就成功。在编码中，我们往往最关注首次尝试就找到答案——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 评分器应与人类专家紧密校准，以确保人类评分与模型评分之间差异很小。为避免幻觉，应给 LLM 一个退出通道，例如指示其在信息不足时返回“Unknown”。也可用清晰、结构化的量表来评分任务各维度，并用独立的 LLM 逐维评分，而不是用一个模型评分所有维度。系统一旦稳健，人工复核只需偶尔进行。

一些评测存在微妙的失败模式，即使智能体表现良好也会得低分，因为评分器有 bug、智能体框架受限、或任务规格含糊。即使是成熟团队也会错过这些问题。例如，Opus 4.5 起初在 CORE-Bench 仅得 42%，直到 Anthropic 研究员发现多个问题：僵硬评分惩罚了“96.12”而期待“96.124991…”，任务规格含糊，以及随机性任务无法精确复现。修复 bug 并使用更少约束的脚手架后，Opus 4.5 的分数跃升至 95%。同样，METR 发现其时间跨度基准中存在多个配置错误的任务：任务要求智能体优化到指定阈值，但评分器要求超过阈值。这惩罚了遵循指令的模型，而忽略目标的模型反而得分更高。认真复查任务与评分器可避免这些问题。

让评分器具备抗绕过或作弊能力。智能体不应能轻易“作弊”通过评测。任务与评分器应设计为只有真正解决问题才能通过，而不是利用意外漏洞。

长期维护并使用评测

第 6 步：检查记录

不阅读大量试次的记录与评分，你就无法确认评分器是否有效。在 Anthropic，我们投入了查看评测记录的工具，并定期阅读。当任务失败时，记录能告诉你是智能体真实失误，还是评分器拒绝了有效解。记录还常常揭示智能体与评测行为的关键细节。

失败看起来必须公平：要清楚智能体错在哪里、为何错。当分数不提升时，我们需要确信原因是智能体表现，而不是评测问题。阅读记录能验证评测是否衡量了真正重要的东西，是智能体开发的一项关键技能。

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

评测达到 100% 能跟踪回归，但对改进不再有信号。评测饱和是指智能体通过了所有可解任务，已经没有改进空间。例如，SWE-Bench Verified 的分数今年从 30% 起步，前沿模型如今接近 >80% 的饱和。随着评测趋近饱和，进步也会变慢，因为只剩下最难的任务。这会使结果具有欺骗性：能力大幅提升却只表现为小幅分数上涨。比如代码审查创业公司 Qodo 最初对 Opus 4.5 不太满意，因为他们的一次性编码评测未能捕捉长链复杂任务上的增益。后来他们开发了新的智能体评测框架，才更清晰地看到进展。

我们的原则是：除非有人深入评测细节并读过一些记录，否则不要把分数当作最终结论。如果评分不公平、任务含糊、有效解被惩罚、或框架限制模型，评测就应修订。

第 8 步：通过开放贡献与维护让评测套件长期健康

评测套件是需要持续关注与明确责任的“活”产物。

在 Anthropic，我们尝试过多种评测维护方式。最有效的是建立专门的评测团队负责核心基础设施，而领域专家与产品团队贡献大部分评测任务**，并自己运行评测。

对 AI 产品团队而言，拥有并迭代评测应像维护单元测试一样常规。团队可能浪费数周在早期测试“能跑”的 AI 功能上，但这些功能未满足隐含期望；设计良好的评测本可更早暴露问题。定义评测任务是检验产品需求是否足够具体、可开始构建的最佳方式之一。

我们建议实践评测驱动开发：先构建评测定义计划能力，然后迭代直到智能体表现良好。内部我们常常构建“眼下够用”的功能，这是对未来模型能力的投注。低通过率的能力评测能让这种投注显性化。当新模型发布时，快速运行套件即可揭示哪些投注奏效。

最接近产品需求和用户的人，最适合定义成功标准。以当前模型能力，产品经理、客户成功或销售人员都可以用 Claude Code 提交评测任务 PR——就该这么做！更好的是，主动为他们赋能。

评测如何与其他方法一起构建对智能体的整体理解

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

理解 AI 智能体性能的方法概览

Method	Pros	Cons
**自动化评测
** 在没有真实用户的情况下通过程序化方式运行测试

• 更快迭代
• 完全可复现
• 不影响用户
• 可在每次提交上运行
• 在不需上线部署的情况下规模化测试场景

|

• 前期投入更高
• 需要持续维护以避免产品与模型演化导致漂移
• 若不能匹配真实使用模式，可能造成虚假信心

**生产监控
** 跟踪线上系统的指标与错误
|

• 在规模化环境中揭示真实用户行为
• 捕捉合成评测遗漏的问题
• 提供智能体实际表现的真实依据

|

• 被动，问题会先影响用户后才被发现
• 信号可能很噪
• 需要在监测与采集上投入
• 缺乏评分的真实标准

**A/B 测试
** 用真实用户流量比较不同版本
|

• 衡量真实用户结果（留存、任务完成）
• 控制混杂因素
• 可扩展且系统化

|

• 慢，需数天或数周才能显著且需要足够流量
• 只能测试已部署变更
• 没有深入审查记录时，对指标变化“为什么”的解释信号较弱

**用户反馈
** 显式信号如点踩或 bug 报告
|

• 揭示你未预期的问题
• 带来真实用户的实际例子
• 反馈通常与产品目标相关

|

• 稀疏且自选择
• 偏向严重问题
• 用户很少解释为何失败
• 非自动化
• 主要依赖用户发现问题会带来负面影响

**人工记录审查
** 人类阅读智能体对话
|

• 建立对失败模式的直觉
• 捕捉自动化检查遗漏的细微质量问题
• 有助于校准“好”的标准并理解细节

|

• 耗时
• 难以规模化
• 覆盖不一致
• 审阅疲劳或不同审阅者影响信号质量
• 通常只提供定性信号，而非清晰量化评分

**系统化人工研究
** 由训练有素的评审员进行结构化评分
|

• 来自多名人类评审的质量金标准判断
• 处理主观或歧义任务
• 为改进模型评分器提供信号

|

• 相对昂贵且周转慢
• 难以频繁开展
• 评审不一致需要协调
• 复杂领域（法律、金融、医疗）需要专家参与研究

这些方法对应智能体开发的不同阶段。自动化评测在上线前与 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 registry 分发，使得运行既有基准与自定义评测套件更容易。

Promptfoo 是一个轻量、灵活的开源框架，侧重于声明式 YAML 的提示测试配置，断言类型从字符串匹配到 LLM 量表。我们在很多产品评测中使用了 Promptfoo 的一个版本。

Braintrust 是一个结合离线评测、生产可观测性与实验追踪的平台——适合既要在开发中迭代又要在线监控质量的团队。其 autoevals 库包含事实性、相关性等维度的预置评分器。

LangSmith 提供追踪、离线与在线评测、数据集管理，并与 LangChain 生态紧密集成。Langfuse 作为自托管开源替代方案，适合有数据驻留需求的团队。

许多团队会组合多种工具、自建评测框架，或仅用简单评测脚本作为起点。我们发现，框架虽能加速与标准化，但其有效性取决于你运行的评测任务。通常最好先快速选择适合工作流的框架，然后把精力投入到评测本身：迭代高质量测试用例与评分器。

获取开发者通讯

产品更新、使用指南、社区亮点等，每月一次发送到你的邮箱。

如果你希望接收我们的开发者月度通讯，请提供你的电子邮箱地址。你可以随时取消订阅。