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

引言

良好的评估能让团队更有把握地交付 AI 智能体。没有评估，很容易陷入被动循环——直到生产环境才发现问题，而修复一个失败又会引发其他失败。评估能在问题和行为变化影响用户之前将其显现出来，并且它的价值会在智能体的整个生命周期中不断累积。

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

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

评估的结构

评估（“eval”）是对 AI 系统的一项测试：向 AI 提供输入，然后对其输出应用评分逻辑以衡量是否成功。本文聚焦于可在开发期间、无需真实用户即可运行的自动化评估。

单回合评估很直接：一个提示词、一个回答和评分逻辑。对于较早期的 LLM，单回合、非智能体评估是主要的评估方法。随着 AI 能力进步，多回合评估正变得越来越常见。

在简单评估中，智能体处理一个提示词，评分器检查输出是否符合预期。对于更复杂的多回合评估，编码智能体会获得工具、任务（此处是构建一个 MCP 服务器）和环境，执行一个“智能体循环”（工具调用和推理），并用实现结果更新环境。随后评分会使用单元测试来验证 MCP 服务器正常工作。

智能体评估更为复杂。智能体会跨许多回合使用工具、修改环境中的状态并一路适应——这意味着错误可能传播并累积。前沿模型还可能找到超出静态评估限制的创造性解法。例如，Opus 4.5 曾解决了一道关于预订航班的 𝜏2-bench 问题：它通过发现政策中的漏洞。按原先的评估写法它“失败”了，但实际上为用户想出了更好的解决方案。

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

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

智能体评估的组成部分。

为什么要构建评估？

团队刚开始构建智能体时，结合手动测试、自用测试和直觉，往往就能走得很远。更严格的评估甚至看起来像会拖慢交付的额外负担。但早期原型阶段过后，一旦智能体进入生产并开始扩展，没有评估的开发方式就会逐渐失效。

临界点往往发生在用户反馈改动后智能体“感觉变差”，而团队却在“盲飞”，除了猜测和逐项验证外没有办法确认。没有评估，调试只能被动进行：等待投诉、手动复现、修复 bug，然后希望没有其他回归。团队无法区分真正的回归与噪声，无法在交付前自动针对数百个场景测试改动，也无法衡量改进。

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

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

Descript 的智能体帮助用户编辑视频，因此他们围绕成功编辑工作流的三个维度构建了评估：不弄坏东西、完成我要求的事、并且做好。他们从手动评分演变为由产品团队定义标准并定期以人工校准的 LLM 评分器，如今定期运行两套独立套件，分别用于质量基准和回归测试。Bolt 的 AI 团队在较晚阶段才开始构建评估，当时他们的智能体已被广泛使用。在 3 个月里，他们构建了一个评估系统：运行其智能体并通过静态分析为输出评分，使用浏览器智能体测试应用，并用 LLM 裁判判断遵循指令等行为。

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

评估也决定了你能多快采用新模型。更强模型出现时，没有评估的团队要花数周测试；而拥有评估的竞争者则能迅速确定模型的长处、调整提示词，并在数天内完成升级。

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

如何评估 AI 智能体

我们看到当今大规模部署的几类常见智能体，包括编码智能体、研究智能体、计算机使用智能体和对话智能体。每一类都可部署在各行各业，但可使用相似技术进行评估。你不必从零发明一套评估。下面各节介绍了几类智能体已经验证过的技术。以这些方法为基础，再将其扩展到你的领域。

智能体的评分器类型

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

基于代码的评分器

| 方法 | 优势 | 弱点 | | --- | --- | --- | | • 字符串匹配检查（精确、正则、模糊等） • 二元测试（从失败到通过、从通过到通过） • 静态分析（lint、类型、安全） • 结果验证 • 工具调用验证（使用的工具、参数） • 记录分析（回合数、token 用量） | • 快速 • 便宜 • 客观 • 可复现 • 易调试 • 验证特定条件 | • 对不完全匹配预期模式的有效变体很脆弱 • 缺乏细微判断 • 对某些更主观的任务评估能力有限 |

基于模型的评分器

| 方法 | 优势 | 弱点 | | --- | --- | --- | | - 基于量表的评分 - 自然语言断言 - 成对比较 - 基于参考答案的评估 - 多裁判共识 | - 灵活 - 可扩展 - 捕捉细微差别 - 处理开放式任务 - 处理自由形式输出 | - 非确定性 - 比代码更昂贵 - 需要通过人工评分器校准以确保准确性 |

人工评分器

| 方法 | 优势 | 弱点 | | --- | --- | --- | | - 领域专家审查 - 众包判断 - 抽样复核 - 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 会分化。在 k=1 时，它们相同（均等于单次试验成功率）。到 k=10 时，它们讲述相反的故事：pass@k 接近 100%，而 pass^k 降至 0%。

两个指标都很有用，选择哪个取决于产品要求：对于一次成功即可的工具使用 pass@k；对于一致性至关重要的智能体使用 pass^k。

从零到一：通往出色智能体评估的路线图

本节给出从没有评估到拥有可信评估的实战建议。这是一张评估驱动智能体开发的路线图：尽早定义成功、清晰衡量它，并持续迭代。

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

第 0 步：尽早开始

我们看到团队因认为需要数百个任务而推迟构建评估。实际上，从真实失败中选出的 20–50 个简单任务就是很好的开始。毕竟，在智能体开发早期，对系统的每次改动通常都有清晰、显著的影响，这种大的效应量意味着小样本量已经足够。更成熟的智能体可能需要更大、更难的评估来检测较小效应，但一开始最好采用 80/20 方法。等待越久，评估越难构建。早期，产品要求会自然转化为测试用例；等待太久，你就在从一个线上系统反向工程成功标准。

第 1 步：从你已手动测试的内容开始

从开发期间运行的手动检查开始——每次发布前验证的行为以及终端用户常尝试的常见任务。如果你已经在线上运行，查看 bug 跟踪器和支持队列。将用户报告的失败转化为测试用例，确保套件反映实际使用；按用户影响排序，可让你把精力投入最关键的地方。

第 2 步：编写具有参考解、无歧义的任务

把任务质量做好比看起来更难。好的任务是两位领域专家能独立得出相同通过/失败结论的任务。他们自己能通过该任务吗？如果不能，任务需要改进。任务规格中的歧义会成为指标噪声。基于模型评分器的标准也是如此：模糊量表会产生不一致判断。

每项任务应当能被正确遵循指令的智能体通过。这可能很微妙。例如，对 Terminal-Bench 的审计发现：如果任务要求智能体写一个脚本却未指定文件路径，而测试假定脚本位于特定路径，智能体可能并非自身原因而失败。评分器检查的每一点都应从任务描述中明确得知；智能体不应因含糊规格而失败。对于前沿模型，跨许多试验的 0% 通过率（即 0% pass@100）大多数时候说明任务有问题，而不是智能体没有能力，也提醒你复查任务规格和评分器。对每项任务，创建一个参考解很有用：一个已知有效、通过所有评分器的输出。这证明任务可解，并验证评分器配置正确。

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

既测试某个行为应当发生的情形，也测试它不应当发生的情形。单边评估会带来单边优化。例如，如果你只测试智能体该搜索时是否搜索，可能最终得到一个几乎什么都搜索的智能体。尽量避免类别不平衡的评估。我们在为 Claude.ai 构建网络搜索评估时亲身体会到这一点。挑战在于防止模型不该搜索时搜索，同时保留其在合适时进行广泛研究的能力。团队构建了覆盖两个方向的评估：模型应该搜索的查询（如查天气）和应从既有知识回答的查询（如“谁创办了 Apple？”）。在触发不足（该搜索却没搜索）与过度触发（不该搜索却搜索）之间取得正确平衡非常困难，并且对提示词和评估都经历了多轮改进。随着更多示例问题出现，我们持续加入评估以改善覆盖面。

设计评估 harness 和评分器

第 4 步：构建具有稳定环境的稳健评估 harness

评估中的智能体必须与生产中使用的智能体大致以相同方式工作，并且环境本身不应引入额外噪声，这一点至关重要。每次试验应从干净环境开始，从而彼此“隔离”。运行之间不必要的共享状态（遗留文件、缓存数据、资源耗尽）会因基础设施不稳定造成相关失败，而不是由智能体表现造成。共享状态也能人为抬高表现。例如，在一些内部评估中，我们发现 Claude 通过检查先前试验的 git 历史，获得了不公平优势。如果多个不同试验都因同一个环境限制（如有限 CPU 内存）失败，这些试验就不是独立的，因为它们受同一因素影响，评估结果也就无法可靠地衡量智能体表现。

第 5 步：周到地设计评分器

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

常见的冲动是检查智能体是否严格遵循了非常具体的步骤，例如按正确顺序调用一串工具。我们发现这种方法过于死板，会导致测试很脆弱，因为智能体经常会找到评估设计者未预见的有效路径。为了不无谓地惩罚创造性，通常最好评估智能体产出了什么，而不是它走过的路径。

对于包含多个组成部分的任务，应内置部分得分。一个正确识别问题并验证客户身份、但未能处理退款的支持智能体，显然优于一开始就失败的智能体。结果中必须体现这种成功的连续谱。

模型评分常需要仔细迭代来验证准确性。应将 LLM-as-judge 评分器与人类专家紧密校准，以确信人工评分与模型评分之间偏差很小。为避免幻觉，给 LLM 一个退出选项会有帮助，例如指示它在信息不足时返回“Unknown”。还可以创建清晰、结构化的量表来为任务每个维度评分，并让孤立的 LLM-as-judge 分别评估每个维度，而不是让一个模型评估所有维度。一旦系统稳健，偶尔进行人工审查就已足够。

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

让你的评分器能够抵抗绕过或黑客式利用。智能体不应能轻易“作弊”通过评估。任务和评分器的设计应确保通过真正需要解决问题，而非利用意外漏洞。

长期维护和使用评估

第 6 步：检查记录

除非你阅读了许多试验的记录与评分，否则不会知道评分器是否工作良好。在 Anthropic，我们投入工具来查看评估记录，并经常花时间阅读它们。当任务失败时，记录会告诉你智能体是否犯了真正错误，还是评分器拒绝了有效解。它也常常揭示智能体和评估行为的关键细节。

失败应该看起来公平：应能清楚知道智能体做错了什么、为什么错。当分数不提升时，我们需要确信原因是智能体表现，而不是评估。阅读记录是验证评估是否在衡量真正重要内容的方式，也是智能体开发的一项关键技能。

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

一项达到 100% 的评估能跟踪回归，却不能为改进提供信号。评估饱和发生在智能体通过所有可解决任务、没有改进空间时。例如，SWE-Bench Verified 的分数今年起始为 30%，而前沿模型如今正接近 >80% 的饱和状态。随着评估趋于饱和，进步也会变慢，因为只剩最难任务。这样可能导致结果具有欺骗性：巨大的能力改进表现为分数的小幅增长。例如，代码审查创业公司 Qodo 起初对 Opus 4.5 印象不深，因为他们的一次性编码评估没有捕捉到它在更长、更复杂任务上的收益。为此，他们开发了新的智能体评估框架，提供了清晰得多的进展图景。

作为一条规则，在有人深入评估细节并阅读一些记录之前，我们不会照单全收评估分数。如果评分不公平、任务含糊、有效解被惩罚，或 harness 限制模型，评估就应修改。

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

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

在 Anthropic，我们尝试过多种维护评估的方法。最有效的做法是建立专门的评估团队来负责核心基础设施，同时由领域专家和产品团队贡献大多数评估任务，并自行运行评估。

对于 AI 产品团队，拥有并迭代评估应像维护单元测试一样日常。团队可能在“早期测试中可用”的 AI 功能上浪费数周，但这些功能无法满足精心设计的评估本应早早揭示的未声明期望。定义评估任务是检验产品需求是否具体到足以开始构建的最佳方式之一。

我们建议实践评估驱动开发：在智能体能够完成计划能力之前，先构建评估来定义它们，然后不断迭代直至智能体表现良好。内部而言，我们经常构建“今天已经足够好用”的功能，但这是对几个月后模型能力的押注。从低通过率开始的能力评估能让这种押注可见。新模型发布时，快速运行套件会揭示哪些押注获得回报。

最接近产品要求和用户的人最适合定义成功标准。以当前模型能力，产品经理、客户成功经理或销售人员都可以使用 Claude Code 通过 PR 贡献一个评估任务——让他们做！更好的是，积极地赋能他们。

创建有效评估的过程。

评估如何与其他方法配合，以全面理解智能体

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

理解 AI 智能体表现的方法概览

| 方法 | 优点 | 缺点 | | --- | --- | --- | | 自动化评估 以编程方式运行测试而不涉及真实用户 | - 迭代更快 - 完全可复现 - 不影响用户 - 可在每次提交运行 - 可大规模测试场景，无需部署到生产 | - 构建需要更多前期投入 - 随产品和模型演化需要持续维护以避免漂移 - 如不匹配真实使用模式，可能产生虚假信心 | | 生产监控 追踪线上系统中的指标和错误 | - 大规模揭示真实用户行为 - 捕捉合成评估遗漏的问题 - 提供智能体实际表现的事实依据 | - 被动；问题会在你知晓前触达用户 - 信号可能有噪声 - 需要投入可观测性建设 - 缺乏评分的事实基准 | | 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 发布，因此可轻松运行已有基准和自定义评估套件。

Braintrust 是结合离线评估、生产可观测性和实验跟踪的平台——适合既需在开发时迭代、又需在线上监控质量的团队。其 autoevals 库包含事实性、相关性等常见维度的预构建评分器。

LangSmith 提供追踪、离线和在线评估以及数据集管理，并与 LangChain 生态紧密集成。Langfuse 则提供类似能力，作为满足数据驻留要求的自托管开源替代方案。

Arize 提供 Phoenix——一个用于 LLM 追踪、调试和离线或在线评估的开源平台——以及 AX（一项将 Phoenix 扩展至规模化、优化和监控的 SaaS 服务）。

许多团队会组合多种工具、自建评估框架，或仅以简单评估脚本作为起点。我们发现，框架虽然可以成为加快进展和标准化的宝贵方式，但它们的质量取决于你运行的评估任务。通常最好快速选择符合工作流的框架，然后将精力投入评估本身，持续迭代高质量测试用例和评分器。