揭开 AI 智能体评估的神秘面纱

发布于 2026 年 1 月 9 日

让智能体变得有用的能力，也让它们难以评估。能够在实际部署中奏效的策略，会组合多种技术，以匹配被测系统的复杂性。

引言

好的评估能帮助团队更有信心地发布 AI 智能体。没有评估，团队很容易陷入被动响应的循环——只有到生产环境中才发现问题，而修复一个故障又会制造其他故障。评估能在问题和行为变化影响用户之前让它们显现出来，并且其价值会在智能体的整个生命周期中不断复利。

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

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

评估的结构

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

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

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

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

• 任务（也称为问题或测试用例）是一个具有明确输入和成功标准的单项测试。

• 对某个任务的每一次尝试称为一次试验。由于模型输出在不同运行之间会变化，我们会运行多次试验，以得到更一致的结果。

• 评分器是一段逻辑，用于对智能体表现的某个方面打分。一个任务可以有多个评分器，每个评分器可以包含多个断言（有时称为检查）。

• 转录记录（也称为 trace 或 trajectory）是一次试验的完整记录，包括输出、工具调用、推理、中间结果以及任何其他交互。对于 Anthropic API，这就是一次评估运行结束时完整的 messages 数组——包含评估期间对 API 的所有调用以及返回的所有响应。

• 结果是在试验结束时环境中的最终状态。一个航班预订智能体可能会在转录记录末尾说“您的航班已预订”，但结果是环境的 SQL 数据库中是否真的存在预订记录。

• 评估框架是端到端运行评估的基础设施。它提供指令和工具，并发运行任务，记录所有步骤，对输出评分，并汇总结果。

• 智能体框架（或 scaffold）是让模型能够以智能体方式行动的系统：它处理输入、编排工具调用，并返回结果。当我们评估“一个智能体”时，我们评估的是框架和模型的协同工作。例如，Claude Code 是一个灵活的智能体框架，我们通过 Agent SDK 使用其核心原语来构建我们的长时运行智能体框架。

• 评估套件是一组任务，用于衡量特定能力或行为。一个套件中的任务通常共享一个宽泛目标。例如，客户支持评估套件可能会测试退款、取消和升级处理。

为什么要构建评估？

当团队刚开始构建智能体时，依靠手动测试、内部试用（dogfooding）和直觉的组合，往往也能走得出人意料地远。更严格的评估甚至可能看起来像是会拖慢发布的额外负担。但在早期原型阶段之后，一旦智能体进入生产并开始扩展，在没有评估的情况下继续构建就会开始失灵。

临界点通常出现在用户反馈说智能体在改动后“感觉更差”时，而团队却在“盲飞”，除了猜测和反复试验外没有办法验证。没有评估，调试就是被动的：等待投诉，手动复现，修复 bug，然后希望没有其他地方退化。团队无法区分真实退化和噪声，无法在发布前自动用数百个场景测试改动，也无法衡量改进。

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

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

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

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

评估还会影响你采用新模型的速度。当更强大的模型发布时，没有评估的团队要花数周进行测试；而有评估的竞争对手可以快速判断模型的优势、调优提示，并在几天内完成升级。

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

如何评估 AI 智能体

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

智能体评分器的类型

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

基于代码的评分器

基于模型的评分器

• 基于量规的评分

• 自然语言断言

• 成对比较

• 基于参考答案的评估

• 多裁判共识

• 灵活

• 可扩展

• 能捕捉细微差别

• 能处理开放式任务

• 能处理自由形式输出

• 非确定性

• 比代码更昂贵

• 需要与人工评分器校准以保证准确性

人工评分器

• 主题专家（SME）评审

• 众包判断

• 抽样抽查

• A/B 测试

• 标注者间一致性

• 黄金标准质量

• 匹配专家用户判断

• 用于校准基于模型的评分器

• 昂贵

• 缓慢

• 通常需要大规模访问人类专家

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

能力评估与回归评估

能力或“质量”评估提出的问题是：“这个智能体擅长做什么？”它们应该从较低通过率开始，瞄准智能体感到困难的任务，给团队一座需要攀登的山。

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

当智能体发布并经过优化后，通过率很高的能力评估可以“毕业”，成为持续运行的回归套件，用于捕捉任何漂移。曾经衡量“我们到底能不能做这件事？”的任务，随后会衡量“我们是否仍能可靠地做这件事？”

评估编程智能体

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

确定性评分器非常适合编程智能体，因为软件通常很容易评估：代码能否运行、测试是否通过？两个被广泛使用的编程智能体基准 SWE-bench Verified 和 Terminal-Bench 就采用了这种方法。SWE-bench Verified 给智能体提供来自热门 Python 仓库的 GitHub issue，并通过运行测试套件来为解决方案评分；只有当解决方案修复了失败测试且没有破坏现有测试时才算通过。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 的量规应经常与专家人工判断进行校准，才能有效地为这些智能体评分。

计算机使用智能体

计算机使用智能体通过与人类相同的界面与软件交互——截图、鼠标点击、键盘输入和滚动——而不是通过 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 分数会上升：更多“射门机会”意味着至少成功 1 次的概率更高。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 的网页搜索构建评估时就亲身学到了这一点。挑战在于防止模型在不该搜索时搜索，同时保留它在适当时进行广泛研究的能力。团队构建了覆盖两个方向的评估：模型应该搜索的查询（例如查找天气），以及模型应该基于已有知识回答的查询（例如“谁创立了 Apple？”）。在触发不足（该搜索时不搜索）和过度触发（不该搜索时搜索）之间取得正确平衡很困难，并且需要对提示和评估都进行多轮改进。随着更多示例问题出现，我们会继续加入评估，以提高覆盖率。

设计评估框架和评分器

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

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

步骤 5：用心设计评分器

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

人们常有一种直觉，想检查智能体是否按非常具体的步骤执行，例如按正确顺序进行一系列工具调用。我们发现这种方法过于僵硬，会导致测试非常脆弱，因为智能体经常找到评估设计者没有预料到的有效方法。为了不必要地惩罚创造性，通常更好的是评估智能体产出了什么，而不是它走了哪条路径。

对于包含多个组成部分的任务，要内置部分得分。一个支持智能体如果正确识别问题并验证了客户身份，但未能处理退款，显然比一开始就失败的智能体更好。在结果中表示这种成功连续谱很重要。

模型评分通常需要仔细迭代来验证准确性。LLM-as-judge 评分器应与人类专家密切校准，以确信人工评分和模型评分之间几乎没有偏差。为了避免幻觉，要给 LLM 一个退路，例如指示它在信息不足时返回“Unknown”。创建清晰、结构化的量规来给任务的每个维度评分也会有帮助，然后用隔离的 LLM-as-judge 分别评分每个维度，而不是用一个 LLM 给所有维度评分。一旦系统足够稳健，偶尔进行人工评审就足够了。

有些评估存在微妙的失败模式，即使智能体表现良好也会得到低分，因为智能体由于评分 bug、智能体框架约束或歧义而无法解决任务。即便是成熟团队也可能错过这些问题。例如，Opus 4.5 最初在 CORE-Bench 上得分为 42%，直到一位 Anthropic 研究人员发现了多个问题：僵硬评分会在期待“96.124991…”时惩罚“96.12”，任务规格含糊，以及随机任务无法精确复现。修复 bug 并使用限制更少的 scaffold 后，Opus 4.5 的分数跃升到 95%。类似地，METR 在其时间跨度基准中发现了几个配置错误的任务，这些任务要求智能体优化到一个声明的分数阈值，但评分却要求超过该阈值。这惩罚了像 Claude 这样遵循指令的模型，而忽略声明目标的模型反而获得更高分。仔细复查任务和评分器可以帮助避免这些问题。

让你的评分器能抵抗绕过或 hack。智能体不应能够轻易“作弊”通过评估。任务和评分器的设计应确保通过评估确实需要解决问题，而不是利用非预期漏洞。

长期维护和使用评估

步骤 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 扩展到规模化、优化和监控。许多团队会组合多个工具，自己构建评估框架，或只是从简单评估脚本起步。我们发现，虽然框架可以成为加速进展和标准化的有价值方式，但它们的好坏取决于你通过它们运行的评估任务。通常最好快速选择一个适合你工作流的框架，然后把精力投入到评估本身，通过迭代高质量测试用例和评分器来改进。

获取开发者新闻通讯

产品更新、操作指南、社区亮点等内容。每月发送到你的收件箱。

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