# 揭秘AI智能体评估：构建可靠系统的关键 - 来源：Anthropic：Engineering（事故复盘 + 工程实践 · 网页） - 发布时间：2026-01-09 00:00 - AIHOT 分数：75 - AIHOT 标记：精选 - AIHOT 链接：https://aihot.virxact.com/items/cmorb7ml0008eslhfvf3i9h8u - 原文链接：https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents ## 精选理由 Anthropic 把内部踩过的坑全摊开了，从 eval 设计到 grader 选型到 transcript 审读，是目前最完整的 Agent 评估工程指南，做 Agent 产品的团队可以直接当手册用。 ## AI 摘要 有效的评估能帮助团队更自信地发布AI智能体，避免陷入仅在生产环境被动发现问题、修复可能引发新问题的循环。智能体因其多轮操作的自主性与灵活性，评估更为复杂。一个完整的评估结构包含任务、评分器、记录、结果、评估框架与评估套件等核心组件。缺乏系统评估将导致团队无法区分真实的质量倒退与随机波动。建立评估体系能帮助团队在智能体规模化过程中持续监控质量、自动测试变更并量化改进效果，其价值在智能体整个生命周期内持续累积。 ## 正文 让智能体变得有用的能力，也让它们难以评估。那些在多种部署场景中行之有效的策略，会结合多种技术手段，以匹配其所衡量系统的复杂性。 引言 良好的评估能帮助团队更自信地交付 AI 智能体。没有评估，团队很容易陷入被动循环——只在生产环境中发现问题，而修复一个问题又会导致其他问题。评估能在问题和行为变化影响用户之前就将其暴露出来，并且其价值会在智能体的整个生命周期中不断累积。 正如我们在《构建高效智能体》中所描述的，智能体需要执行多轮操作：调用工具、修改状态，并根据中间结果进行调整。正是这些让 AI 智能体变得有用的能力——自主性、智能性和灵活性——也让它们更难被评估。 通过我们的内部工作以及与处于智能体开发前沿的客户合作，我们学会了如何为智能体设计更严谨、更有用的评估方法。以下是在实际部署中，针对多种智能体架构和用例被证明行之有效的做法。 评估的结构 评估是对 AI 系统的一种测试：给 AI 一个输入，然后对其输出应用评分逻辑来衡量成功与否。在本文中，我们重点关注那些可以在开发过程中无需真实用户即可运行的自动化评估。 单轮评估很简单：一个提示词、一个回复，以及评分逻辑。对于早期的大语言模型来说，单轮、非智能体的评估是主要的评估方法。随着 AI 能力的提升，多轮评估变得越来越普遍。 在一个简单的评估中，智能体处理一个提示词，评分器检查输出是否符合预期。对于一个更复杂的多轮评估，一个编码智能体会获得工具、一个任务（本例中是构建一个 MCP 服务器）和一个环境，执行一个“智能体循环”（工具调用和推理），并用实现结果更新环境。然后，评分环节会使用单元测试来验证这个可正常工作的 MCP 服务器。 智能体评估甚至更为复杂。智能体在多个轮次中使用工具，修改环境中的状态并随过程进行调整——这意味着错误可能会传播和累积。前沿模型还能找到超越静态评估限制的创造性解决方案。例如，Opus 4.5 通过发现政策中的一个漏洞，解决了一个关于预订航班的 τ2-bench 问题。它按照评估标准“失败了”，但实际上为用户想出了一个更好的解决方案。 在构建智能体评估时，我们使用以下定义： 一个任务（也称为问题或测试用例）是一个具有定义好的输入和成功标准的单一测试。 对任务的每一次尝试称为一次试验。由于模型输出在不同运行之间会有差异，我们会运行多次试验以产生更一致的结果。 评分器是对智能体表现的某个方面进行评分的逻辑。一个任务可以有多个评分器，每个评分器包含多个断言（有时称为检查项）。 记录（也称为轨迹或路径）是一次试验的完整记录，包括输出、工具调用、推理过程、中间结果以及任何其他交互。对于 Anthropic API，这指的是评估运行结束时完整的消息数组——包含评估期间所有对 API 的调用以及所有返回的响应。 结果是指试验结束时环境中的最终状态。一个预订航班的智能体可能在记录结束时说“您的航班已预订成功”，但结果取决于环境中的 SQL 数据库中是否存在该预订记录。 评估框架是端到端运行评估的基础设施。它提供指令和工具，并发运行任务，记录所有步骤，对输出进行评分，并汇总结果。 智能体框架（或脚手架）是使模型能够充当智能体的系统：它处理输入、编排工具调用并返回结果。当我们评估“一个智能体”时，我们评估的是框架和模型协同工作的整体。例如，Claude Code 是一个灵活的智能体框架，我们通过 Agent SDK 使用其核心原语来构建我们的长时间运行智能体框架。 评估套件是一组旨在衡量特定能力或行为的任务集合。套件中的任务通常共享一个宏观目标。例如，一个客户支持评估套件可能会测试退款、取消订单和问题升级处理。 智能体评估的组成部分。 为什么要构建评估？ 当团队刚开始构建智能体时，通过手动测试、内部试用和直觉判断的组合，他们能取得令人惊讶的进展。更严格的评估甚至可能看起来像是拖慢发布进度的额外负担。但在早期原型阶段之后，一旦智能体投入生产并开始规模化，在没有评估的情况下进行构建就会开始出现问题。 转折点通常出现在用户反馈智能体在更新后感觉更差时，而团队处于“盲目飞行”状态，除了猜测和检查之外，无法进行验证。缺乏评估，调试就是被动的：等待投诉，手动复现，修复错误，然后希望没有其他功能退化。团队无法区分真正的性能退化与随机波动，无法在发布前自动用数百个场景测试变更，也无法衡量改进效果。 我们多次目睹过这种发展过程。例如，Claude Code 最初是基于 Anthropic 员工和外部用户的反馈进行快速迭代。后来，我们增加了评估——最初是针对简洁性和文件编辑等狭窄领域，随后扩展到过度工程等更复杂的行为。这些评估帮助识别问题、指导改进并聚焦研究与产品的协作。结合生产监控、A/B 测试、用户研究等，评估为 Claude Code 在规模化过程中持续改进提供了信号。 在智能体生命周期的任何阶段编写评估都是有用的。早期，评估迫使产品团队明确智能体的成功标准；后期，它们则有助于维持一致的质量水平。 Descript 的智能体帮助用户编辑视频，因此他们围绕成功编辑工作流的三个维度构建了评估体系：不破坏内容、执行我的指令、并且执行到位。他们从人工评分逐步演进到由产品团队定义标准、定期进行人工校准的大语言模型评分器，现在定期运行两套独立的测试套件，分别用于质量基准测试和回归测试。Bolt AI 团队则是在已经拥有广泛使用的智能体之后，才开始构建评估体系。在 3 个月内，他们建立了一套评估系统，该系统运行其智能体，并通过静态分析对输出进行评分，使用浏览器智能体测试应用，并采用大语言模型裁判来评估指令遵循等行为。 有些团队在开发初期就创建评估；另一些团队则是在规模化阶段，当评估成为改进智能体的瓶颈时才加入。评估在智能体开发初期尤其有用，可以明确编码预期的行为。两位工程师阅读相同的初始规格说明，可能会对 AI 应如何处理边缘情况产生不同的理解。一套评估套件可以解决这种歧义。无论评估是在何时创建的，它们都有助于加速开发。 评估还决定了你能以多快的速度采用新模型。当更强大的模型问世时，没有评估的团队将面临数周的测试，而拥有评估的竞争对手则能迅速确定模型的优势、调整提示词，并在数天内完成升级。 一旦评估体系建立起来，你就能免费获得基线和回归测试：可以在一个静态任务库上追踪延迟、模型 token 用量、单任务成本和错误率。评估还可以成为产品团队与研究团队之间带宽最高的沟通渠道，定义研究人员可以优化的指标。显然，评估的好处远不止追踪回归和进步。鉴于前期成本显而易见，而收益是后期累积的，其复合价值很容易被忽视。 如何评估 AI 智能体 如今我们观察到几种常见类型的智能体正在大规模部署，包括编码智能体、研究智能体、计算机使用智能体和对话智能体。每种类型可能部署在多种不同的行业中，但都可以使用类似的技术进行评估。你不需要从头发明一种评估方法。以下章节描述了针对几种智能体类型的成熟技术。将这些方法作为基础，然后将其扩展到你的领域。 智能体的评分器类型 智能体评估通常结合三种评分器：基于代码的、基于模型的和人工的。每种评分器评估记录或结果的某一部分。有效评估设计的一个关键组成部分是为任务选择合适的评分器。 基于代码的评分器 方法优势劣势 • 字符串匹配检查（精确、正则、模糊等）• 二元测试（失败转通过、通过转通过）• 静态分析（代码检查、类型检查、安全检查）• 结果验证• 工具调用验证（使用的工具、参数）• 记录分析（交互轮次、token 使用量）• 快速• 廉价• 客观• 可复现• 易于调试• 验证特定条件• 对于不完全符合预期模式的合理变体较为脆弱• 缺乏细微差别• 在评估某些更主观的任务时存在局限 基于模型的评分器 方法优势劣势 基于评分标准的打分 自然语言断言 成对比较 基于参考的评估 多评分器共识 灵活 可扩展 捕捉细微差别 处理开放式任务 处理自由格式输出 非确定性 比基于代码的方式更昂贵 需要与人工评分器进行校准以确保准确性 人工评分器 方法优势劣势 领域专家评审 众包判断 抽查采样 A/B 测试 标注者间一致性 黄金标准质量 匹配专家用户判断 用于校准基于模型的评分器 昂贵 缓慢 通常需要大规模接触人类专家 对于每个任务，评分可以是加权（组合评分器得分必须达到阈值）、二元（所有评分器必须通过）或混合方式。 能力评估与回归评估 能力评估或“质量”评估要回答的问题是：“这个智能体在哪些方面表现良好？”这类评估应从较低的通过率起步，聚焦于智能体难以完成的任务，为团队提供逐步攻克的目标。 回归评估要回答的问题是：“智能体是否仍能处理它过去能完成的所有任务？”这类评估应接近 100% 的通过率。它们用于防止性能倒退，因为分数下降意味着某些环节出了问题，需要改进。当团队在能力评估上逐步攻坚时，同时运行回归评估也很重要，以确保变更不会在其他方面引发问题。 在智能体上线并完成优化后，通过率较高的能力评估可以“升级”为回归测试套件，持续运行以捕捉任何性能漂移。曾经用于衡量“我们到底能不能做到？”的任务，转而用于衡量“我们还能稳定地做到吗？” 评估编码智能体 编码智能体负责编写、测试和调试代码，它们像人类开发者一样浏览代码库并运行命令。对现代编码智能体进行有效评估，通常依赖于定义明确的任务、稳定的测试环境，以及对生成代码的全面测试。 确定性评分器天然适用于编码智能体，因为软件通常很容易评估：代码能否运行？测试能否通过？两个广泛使用的编码智能体基准测试——SWE-bench Verified 和 Terminal-Bench——都采用了这种方法。SWE-bench Verified 向智能体提供来自热门 Python 仓库的 GitHub 问题，并通过运行测试套件来评分；解决方案只有在修复了失败的测试且不破坏现有测试的情况下才算通过。大语言模型在该评估上的表现，在短短一年内就从 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 请注意，此示例展示了所有可用评分器的完整范围，仅供说明之用。在实际应用中，编程评估通常依赖单元测试来验证正确性，并使用大语言模型评分标准来评估整体代码质量，仅在需要时才会添加额外的评分器和指标。 评估对话式智能体 对话式智能体在客服、销售或辅导等领域与用户进行交互。与传统聊天机器人不同，它们会维护状态、使用工具，并在对话过程中执行操作。虽然编程和研究类智能体也可能涉及与用户的多轮交互，但对话式智能体面临一个独特的挑战：交互质量本身也是评估的一部分。有效的对话式智能体评估通常依赖于可验证的最终状态结果，以及能够同时捕捉任务完成情况和交互质量的评分标准。与大多数其他评估不同，这类评估通常需要第二个大语言模型来模拟用户。我们在对齐审计智能体中采用了这种方法，通过扩展的对抗性对话对模型进行压力测试。 对话式智能体的成功可以是多维度的：工单是否已解决（状态检查）、是否在 10 轮以内完成（对话记录约束）、语气是否恰当（大语言模型评分标准）。两个体现多维度的基准测试是 𝜏-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 公司第三季度营收是多少？”），精确匹配即可。大语言模型可以标记出无依据的主张和覆盖范围的缺口，同时也能验证开放式综合报告在连贯性和完整性方面的表现。 鉴于研究质量具有主观性，基于大语言模型的评分标准应频繁对照人类专家判断进行校准，以便有效评估这些智能体。 计算机使用智能体 计算机使用智能体通过与人相同的界面与软件交互——即截图、鼠标点击、键盘输入和滚动——而不是通过 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 得分会上升：更多的“射门机会”意味着至少成功一次的概率更高。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 法则。拖延越久，评估就越难构建。在早期，产品需求自然能转化为测试用例。等得太久，你就得从运行中的系统反向推导成功标准。 第一步：从你已经手动测试的内容开始 从你在开发过程中执行的手动检查开始——即每次发布前验证的行为以及终端用户尝试的常见任务。如果你已经上线，可以查看你的缺陷跟踪器和支持队列。将用户报告的故障转化为测试用例，可以确保你的测试套件反映实际使用情况；按用户影响程度排序，有助于你把精力投入到关键之处。 第二步：编写带有参考答案的明确任务 保证任务质量比看起来要难。一个好的任务，是两位领域专家能独立得出相同的通过/不通过结论的任务。他们自己能通过这个任务吗？如果不能，就需要改进任务。任务说明中的歧义会成为指标中的噪声。同样的原则也适用于基于模型的评分标准：模糊的评分规则会产生不一致的判断。 每个任务都应能被正确遵循指令的智能体完成。这一点可能很微妙。例如，审计 Terminal-Bench 时发现，如果任务要求智能体编写脚本但未指定文件路径，而测试又假设了特定文件路径，智能体可能会因非自身原因而失败。评分器检查的所有内容都应在任务描述中清晰说明；智能体不应因规格模糊而失败。对于前沿模型而言，多次试验中通过率为 0%（即 0% pass@100）通常意味着任务本身有问题，而非智能体能力不足，这也是需要重新检查任务规范和评分器的信号。为每个任务创建参考解决方案很有用：即一个已知能通过所有评分器的工作输出。这能证明任务可解，并验证评分器配置正确。 第三步：构建平衡的问题集 既要测试行为应该发生的情况，也要测试行为不应发生的情况。单方面的评估会导致单方面的优化。例如，如果只测试智能体在应该搜索时是否搜索，最终可能会得到一个几乎对所有事情都进行搜索的智能体。尽量避免类别不平衡的评估。我们在为 Claude.ai 构建网络搜索评估时亲身学到了这一点。挑战在于既要防止模型在不该搜索时进行搜索，又要保留其在适当情况下进行广泛研究的能力。团队构建了涵盖两个方向的评估：模型应该搜索的查询（如查找天气）和模型应基于已有知识回答的查询（如"谁创立了苹果？"）。在欠触发（应该搜索时未搜索）和过触发（不该搜索时却搜索）之间找到恰当的平衡非常困难，需要经过多轮对提示词和评估的优化。随着更多示例问题的出现，我们会持续向评估集中添加内容以提升覆盖范围。 设计评估框架和评分器 第四步：构建具有稳定环境的稳健评估框架 评估中的智能体必须与生产环境中使用的智能体在功能上大致相同，并且环境本身不应引入额外的噪声。每次试验都应从干净的环境开始，实现“隔离”。运行之间不必要的共享状态（残留文件、缓存数据、资源耗尽）可能导致因基础设施不稳定而非智能体性能引起的关联性失败。共享状态还可能人为地提升性能。例如，在一些内部评估中，我们观察到 Claude 通过查看先前试验的 git 历史记录，在某些任务上获得了不公平的优势。如果多个不同的试验因环境中的同一限制（如有限的 CPU 内存）而失败，那么这些试验并非独立，因为它们受到相同因素的影响，评估结果对于衡量智能体性能而言也变得不可靠。 步骤 5：精心设计评分器 如上所述，优秀的评估设计包括为智能体和任务选择最佳的评分器。我们建议在可能的情况下选择确定性评分器，在必要时或为获得额外灵活性时使用大语言模型评分器，并审慎地使用人工评分器进行额外验证。 人们通常有一种本能，即检查智能体是否遵循了非常具体的步骤，例如按正确顺序进行一系列工具调用。我们发现这种方法过于僵化，会导致测试过于脆弱，因为智能体经常会找到评估设计者未曾预料到的有效方法。因此，为了不无谓地惩罚创造性，通常更好的做法是评估智能体产出的结果，而不是它采取的过程。 对于包含多个组成部分的任务，应设置部分得分。一个能够正确识别问题并验证客户身份，但未能处理退款的客服智能体，其表现明显优于一个从一开始就失败的智能体。在结果中体现这种连续的成功程度非常重要。 模型评分通常需要反复迭代才能验证其准确性。以 LLM 作为评判者的评分机制，应与人类专家进行紧密校准，以确保人工评分与模型评分之间几乎没有偏差。为避免模型幻觉，应给大语言模型留一条退路，例如提供一条指令，要求其在信息不足时返回“未知”。此外，为任务的每个维度制定清晰、结构化的评分标准，并使用独立的 LLM 评判者分别对每个维度进行评分，而不是用一个评判者评估所有维度，也会有所帮助。一旦系统足够稳健，仅需偶尔进行人工审核即可。 某些评估存在微妙的失败模式，即使智能体表现良好，得分也可能很低，原因是智能体因评分错误、智能体框架限制或任务歧义而未能解决问题。即使是经验丰富的团队也可能忽略这些问题。例如，Opus 4.5 在 CORE-Bench 上最初得分仅为 42%，直到一位 Anthropic 研究员发现了多个问题：僵化的评分标准惩罚了“96.12”这样的答案，而期望的是“96.124991…”；任务规范存在歧义；以及随机性任务无法精确复现。在修复错误并使用约束较少的框架后，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 智能体性能的方法概览 方法优点缺点 自动化评估：无需真实用户，以编程方式运行测试 迭代速度更快 完全可复现 不影响用户 可在每次提交时运行 无需生产部署即可大规模测试场景 需要更多的前期投入来构建 随着产品和模型的演进，需要持续维护以避免漂移。 若与真实使用模式不符，可能造成虚假信心。 生产监控：跟踪在线系统中的指标和错误。 大规模揭示真实用户行为。 捕捉合成评估遗漏的问题。 提供智能体实际表现的客观事实。 被动响应；问题在您知晓之前就已触及用户。 信号可能带有噪声。 需要在监测工具上投入资源。 缺乏用于评分的客观事实。 A/B 测试：使用真实用户流量比较不同版本。 衡量实际用户成果（留存率、任务完成度）。 控制混杂变量。 可扩展且系统化。 速度慢；需要数天或数周才能达到统计显著性，且需要足够的流量。 仅测试您部署的变更。 在无法彻底审查对话记录的情况下，对指标变化的根本“原因”提供的信号较少。 用户反馈：明确的信号，如点踩或错误报告。 揭示您未曾预料到的问题。 附带来自真实人类用户的实际案例。 反馈通常与产品目标相关。 稀疏且具有自我选择性。 偏向于严重问题。 用户很少解释失败原因。 非自动化。 主要依赖用户发现问题可能对用户产生负面影响。 人工对话记录审查：人工阅读智能体对话。 建立对失败模式的直觉。 捕捉自动化检查遗漏的细微质量问题。 有助于校准“好”的标准并把握细节。 耗时。 不可扩展。 覆盖范围不一致。 审查员疲劳或不同的审查员可能影响信号质量。 通常仅提供定性信号，而非清晰的定量评分。 系统性人工研究：由经过培训的评分员对智能体输出进行结构化评分。 来自多位人工评分员的黄金标准质量判断。 处理主观或模糊的任务。 为改进基于模型的评分器提供信号。 相对昂贵且周转慢。 难以频繁进行。 评分员间分歧需要协调。 复杂领域（法律、金融、医疗）需要人类专家进行研究。 这些方法对应智能体开发的不同阶段。自动化评估在发布前和 CI/CD 流程中尤其有用，每次智能体变更和模型升级时运行，作为质量问题的第一道防线。生产监控在发布后启动，用于检测分布漂移和未预料到的真实世界故障。A/B 测试在流量充足时验证重大变更。用户反馈和对话记录审查是持续进行的实践，用于填补空白：持续分类反馈，每周抽样阅读对话记录，并根据需要深入挖掘。保留系统性人工研究用于校准大语言模型评分器，或评估以人类共识作为参考标准的主观输出。 如同安全工程中的瑞士奶酪模型，没有任何单一评估层能捕获所有问题。通过多种方法结合，从某一层漏过的失败会被另一层捕获。 最高效的团队会结合这些方法：自动化评估用于快速迭代，生产监控用于获取真实数据，定期人工审查用于校准。 结论 没有评估的团队会陷入被动循环——修复一个故障，又制造另一个，无法区分真正的性能回退与噪声。而早期投入评估的团队则发现相反的情况：随着故障变成测试用例，测试用例防止回退，指标取代猜测，开发速度反而加快。评估为整个团队提供了清晰的攀登目标，将"智能体感觉变差了"转化为可操作的事项。这种价值会不断累积，但前提是你把评估视为核心组件，而非事后补救。 具体模式因智能体类型而异，但这里描述的基本原理是恒定的。尽早开始，不要等待完美的评估套件。从你看到的故障中获取真实任务。定义明确、稳健的成功标准。精心设计评分器并组合多种类型。确保问题对模型来说足够困难。迭代评估以提升其信噪比。阅读对话记录！ 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，这是一个用于大语言模型追踪、调试以及离线或在线评估的开源平台，以及 AX，这是一个 SaaS 产品，可扩展 Phoenix 以实现规模化、优化和监控。许多团队会组合使用多种工具，自行构建评估框架，或者仅使用简单的评估脚本作为起点。我们发现，虽然框架可以成为加速进展和实现标准化的宝贵工具，但其价值完全取决于你通过它们运行的评估任务。通常，最佳做法是快速选择一个适合你工作流程的框架，然后将精力投入到评估本身，通过迭代高质量测试用例和评分器来不断改进。 获取开发者通讯 产品更新、操作指南、社区亮点等。每月发送到您的邮箱。