我们都知道，AI Agent 之所以强大有用，恰恰因为它们自主、灵活、智能。
但这也恰恰让评估变得棘手。
真正有效的评估策略，是把多种技术组合起来，让评估方法的复杂度匹配上被评估系统的复杂度。
刚刚，一手打造出 Claude Code 的Anthropic 工程团队发布了一篇名为《Demystifying evals for AI agents》的关于 Agent 评估的博客，揭秘了内部如何对 AI Agent 进行评估，把 Agent 评估这事，从头到尾都讲了一遍，从为什么要做评估、怎么设计评估任务、如何选择评分器、到长期维护评估体系，可谓是干货满满。
对于正在开发 AI Agent 的团队来说，这可能是目前最实用的参考指南。
原文地址：https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents
下为其博客全文：
引言
好的评估能帮助团队更有信心地发布 AI Agent。
没有评估，很容易陷入被动循环：只能在生产环境中发现问题，而修一个 bug 又会引发新的问题。评估能让问题和行为变化在影响用户之前就被看到，其价值会在 Agent 的整个生命周期中持续累积。
正如我们在《构建有效 Agent》[1]中描述的，Agent 需要多轮运行：调用工具、修改状态、根据中间结果进行调整。
这些让 Agent 变得有用的能力（自主性、智能和灵活性），也让它们更难评估。
通过内部工作和与处于 Agent 开发前沿的客户合作，我们学会了如何为 Agent 设计更严谨、更有用的评估。以下是在各种 Agent 架构和真实部署场景中行之有效的方法。
评估的结构
评估（eval） 是对 AI 系统的测试：给 AI 一个输入，然后用评分逻辑对其输出进行评判以衡量成功。本文重点讨论可以在开发过程中无需真实用户参与运行的自动化评估。
单轮评估很直接：一个 prompt、一个响应、一套评分逻辑。对于早期的 LLM，单轮非 Agent 评估是主要的评估方法。随着 AI 能力的提升，多轮 Agent 评估逐渐成为主流。
在简单评估中，Agent 处理一个 prompt，评分器检查输出是否符合预期。在更复杂的多轮评估中，一个编码 Agent 获得工具、任务（比如构建一个 MCP 服务器）和环境，执行「Agent 循环」（工具调用和推理），并用实现代码更新环境。然后用单元测试来验证 MCP 服务器是否正常工作。
Agent 评估更加复杂。
Agent 跨多轮使用工具，在环境中修改状态并随着进展进行调整。这意味着错误可能传播和累积。前沿模型还能找到超越静态评估限制的创造性解决方案。例如，Opus 4.5 在解决 𝜏2-bench[2] 中关于预订航班的问题时，发现[3]了政策中的一个漏洞。虽然它按评估标准「失败」了，但实际上为用户找到了更好的解决方案。
构建 Agent 评估时，我们使用以下定义：
任务（task）（又称问题或测试用例）是一个具有明确输入和成功标准的单个测试
每次对任务的尝试是一个试验（trial）。由于模型输出在不同运行之间会有变化，我们运行多次试验以产生更一致的结果
评分器（grader） 是对 Agent 表现某个方面进行打分的逻辑。一个任务可以有多个评分器，每个评分器包含多个断言（有时称为检查点）
记录（transcript）（也称轨迹或路径）是一次试验的完整记录，包括输出、工具调用、推理、中间结果和任何其他交互。对于 Anthropic API，这是评估运行结束时的完整 messages 数组，包含评估期间对 API 的所有调用和所有返回的响应
结果（outcome） 是试验结束时环境的最终状态。航班预订 Agent 可能在记录末尾说「您的航班已预订」，但结果是环境的 SQL 数据库中是否存在预订记录
评估框架（evaluation harness） 是端到端运行评估的基础设施。它提供指令和工具、并发运行任务、记录所有步骤、对输出评分并汇总结果
Agent 框架（agent harness）（或脚手架）是使模型能够作为 Agent 行动的系统：它处理输入、编排工具调用并返回结果。当我们评估「一个 Agent」时，我们实际上是在评估框架和模型的协同工作。例如，Claude Code[4] 是一个灵活的 Agent 框架，我们通过 Agent SDK[5] 使用其核心原语来构建我们的长时运行 Agent 框架[6]
评估套件（evaluation suite） 是设计用于测量特定能力或行为的任务集合。套件中的任务通常有一个共同的大目标。例如，客户支持评估套件可能测试退款、取消和升级处理
为什么要构建评估？
团队刚开始构建 Agent 时，通过手动测试、内部试用[7]和直觉的组合，往往能走得出乎意料地远。更严格的评估甚至可能看起来像是拖慢发布的额外开销。但在早期原型阶段之后，一旦 Agent 投入生产并开始规模化，没有评估的开发方式就会崩溃。
转折点通常出现在用户反馈说 Agent 在改动后感觉变差了，而团队「两眼一抹黑」，除了猜测和试错之外无法验证。
没有评估，调试是被动的：等待投诉、手动复现、修复 bug，然后祈祷其他地方没出问题。团队无法区分真正的回退和噪音，无法在发布前自动针对数百个场景测试变更，也无法量化改进。
我们见过这种演变很多次。
例如，Claude Code 一开始是基于 Anthropic 员工和外部用户的反馈进行快速迭代。后来，我们添加了评估：首先是针对精简性和文件编辑等狭窄领域，然后是过度工程化等更复杂的行为。这些评估帮助识别问题、指导改进，并聚焦研究与产品团队的合作。结合生产监控、A/B 测试、用户研究等，评估提供了持续改进 Claude Code 规模化的信号。
在 Agent 生命周期的任何阶段编写评估都是有用的。早期，评估迫使产品团队明确 Agent 成功的定义，而后期它们帮助维持一致的质量标准。
Descript[8] 的 Agent 帮助用户编辑视频，所以他们围绕成功编辑工作流的三个维度构建评估：不要破坏东西、按我说的做、做得好。他们从手动评分演进到由产品团队定义标准并定期进行人工校准的 LLM 评分器，现在定期运行两个独立的套件用于质量基准测试和回归测试。
Bolt[9] AI 团队在已经有了广泛使用的 Agent 之后才开始构建评估。在 3 个月内，他们构建了一个评估系统，能运行 Agent 并用静态分析对输出评分，使用浏览器 Agent 测试应用，并用 LLM 评判器评估指令遵循等行为。
有些团队在开发之初就创建评估；另一些则在规模化后才添加，那时评估成为改进 Agent 的瓶颈。评估在 Agent 开发之初尤其有用，可以明确编码预期行为。两个工程师读同一份初始规格说明，可能对 AI 应如何处理边缘情况有不同的理解。评估套件消除了这种歧义。
无论何时创建，评估都有助于加速开发。
评估还影响你采用新模型的速度。当更强大的模型发布时，没有评估的团队面临数周的测试，而有评估的竞争对手可以快速确定模型的优势、调整 prompt 并在几天内完成升级。
一旦评估存在，你就免费获得了基线和回归测试：延迟、token 使用量、每任务成本和错误率都可以在静态任务库上进行跟踪。评估还可以成为产品和研究团队之间最高带宽的沟通渠道，定义研究人员可以优化的指标。显然，评估的好处远不止跟踪回退和改进。由于成本在前期可见而收益在后期累积，其复合价值很容易被忽视。
如何评估 AI Agent
我们今天看到几种常见类型的 Agent 大规模部署，包括编码 Agent、研究 Agent、计算机使用 Agent 和对话 Agent。每种类型可能跨越多种行业部署，但可以使用类似的技术进行评估。你不需要从零发明评估方法。
以下章节描述了几种 Agent 类型的经过验证的技术。使用这些方法作为基础，然后将其扩展到你的领域。
Agent 评分器的类型
Agent 评估通常结合三种类型的评分器：基于代码的、基于模型的和人工的。每个评分器评估记录或结果的某些部分。有效评估设计的一个关键组成部分是为任务选择正确的评分器。
基于代码的评分器
| 方法 | 优势 | 劣势 |
|---|---|---|
基于模型的评分器
| 方法 | 优势 | 劣势 |
|---|---|---|
人工评分器
| 方法 | 优势 | 劣势 |
|---|---|---|
对于每个任务，评分可以是加权的（组合评分器分数必须达到阈值）、二元的（所有评分器必须通过）或混合的。
能力评估 vs 回归评估
能力或「质量」评估 问的是「这个 Agent 能做好什么？」它们应该从低通过率开始，针对 Agent 难以处理的任务，给团队一个可以攀登的山峰。
回归评估问的是「Agent 是否仍然能处理它以前能处理的所有任务？」应该有接近 100% 的通过率。它们防止倒退，分数下降意味着有东西坏了需要改进。当团队攀登能力评估的山峰时，同时运行回归评估也很重要，以确保变更不会在其他地方造成问题。
在 Agent 发布并优化后，高通过率的能力评估可以「毕业」成为持续运行的回归套件以捕捉任何漂移。曾经衡量「我们能做到这个吗？」的任务，此时变成了衡量「我们还能可靠地做到这个吗？」
评估编码 Agent
编码 Agent 编写、测试和调试代码，导航代码库，并像人类开发者一样运行命令。现代编码 Agent 的有效评估通常依赖于明确定义的任务、稳定的测试环境和对生成代码的全面测试。
确定性评分器对编码 Agent 来说很自然，因为软件通常很容易评估：代码能运行吗？测试通过了吗？两个广泛使用的编码 Agent 基准测试 SWE-bench Verified[10] 和 Terminal-Bench[11] 遵循这种方法。SWE-bench Verified 给 Agent 来自流行 Python 仓库的 GitHub 问题，通过运行测试套件对解决方案评分；只有修复了失败的测试且没有破坏现有测试的解决方案才能通过。LLM 在这个评估上的成绩在短短一年内从 40% 提升到超过 80%。Terminal-Bench 采用不同的路径：它测试端到端技术任务，如从源码构建 Linux 内核或训练 ML 模型。
一旦你有了一组用于验证编码任务关键结果的通过/失败测试，通常也有必要对记录进行评分。例如，基于启发式的代码质量规则可以根据通过测试之外的标准评估生成的代码，具有明确评分标准的基于模型的评分器可以评估 Agent 如何调用工具或与用户交互等行为。
示例：编码 Agent 的理论评估
考虑一个编码任务，Agent 必须修复一个身份验证绕过漏洞。如下面示例 YAML 文件所示，可以使用评分器和指标来评估这个 Agent。
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 评分标准评估整体代码质量，只在需要时添加额外的评分器和指标。
评估对话 Agent
对话 Agent 在支持、销售或辅导等领域与用户交互。与传统聊天机器人不同，它们维护状态、使用工具并在对话中采取行动。虽然编码和研究 Agent 也可能涉及与用户的多轮交互，但对话 Agent 提出了一个独特的挑战：交互本身的质量也是你要评估的一部分。
对话 Agent 的有效评估通常依赖可验证的最终状态结果和捕捉任务完成度与交互质量的评分标准。与大多数其他评估不同，它们通常需要第二个 LLM 来模拟用户。我们在对齐审计 Agent[12] 中使用这种方法，通过扩展的对抗性对话对模型进行压力测试。
对话 Agent 的成功可以是多维的：工单是否解决了（状态检查）、是否在 10 轮内完成（记录约束）、语气是否合适（LLM 评分标准）？两个包含多维性的基准测试是 𝜏-Bench[13] 及其后续版本 τ2-Bench[14]。它们模拟跨零售支持和航空预订等领域的多轮交互，其中一个模型扮演用户角色，而 Agent 导航真实场景。
示例：对话 Agent 的理论评估
考虑一个支持任务，Agent 必须处理一位沮丧客户的退款。
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: 10tracked_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与我们的编码 Agent 示例一样，这个任务展示了多种评分器类型以作说明。在实践中，对话 Agent 评估通常使用基于模型的评分器来评估沟通质量和目标完成度，因为许多任务，比如回答问题，可能有多个「正确」的解决方案。
评估研究 Agent
研究 Agent 收集、综合和分析信息，然后产生答案或报告等输出。与编码 Agent 的单元测试提供二元通过/失败信号不同，研究质量只能相对于任务来判断。什么算是「全面」、「有据可查」甚至「正确」取决于上下文：市场扫描、并购尽职调查和科学报告各有不同的标准。
研究评估面临独特的挑战：专家可能对综合是否全面存在分歧，基准真相随着参考内容不断变化而移动，更长、更开放的输出为错误创造了更多空间。例如，像 BrowseComp[15] 这样的基准测试验证 AI Agent 能否在开放网络的大海捞针中找到答案，这些问题被设计为容易验证但难以解决。
构建研究 Agent 评估的一种策略是组合评分器类型。可靠性检查验证声明是否有检索到的来源支持，覆盖率检查定义好答案必须包含的关键事实，来源质量检查确认咨询的来源是权威的，而不仅仅是第一个检索到的。对于有客观正确答案的任务（「X 公司 Q3 的收入是多少？」），精确匹配有效。LLM 可以标记无支持的声明和覆盖缺口，但也可以验证开放式综合的连贯性和完整性。
鉴于研究质量的主观性，基于 LLM 的评分标准应该经常与专家人工判断进行校准，以有效评估这些 Agent。
计算机使用 Agent
计算机使用 Agent 通过与人类相同的界面与软件交互：截图、鼠标点击、键盘输入和滚动，而不是通过 API 或代码执行。它们可以使用任何带有图形用户界面（GUI）的应用程序，从设计工具到遗留企业软件。评估需要在 Agent 可以使用软件应用的真实或沙盒环境中运行它，并检查是否达到了预期结果。例如，WebArena[16] 测试基于浏览器的任务，使用 URL 和页面状态检查来验证 Agent 是否正确导航，以及对修改数据的任务进行后端状态验证（确认订单实际上已下单，而不仅仅是确认页面出现了）。OSWorld[17] 将此扩展到完整的操作系统控制，评估脚本在任务完成后检查各种工件：文件系统状态、应用配置、数据库内容和 UI 元素属性。
浏览器使用 Agent 需要在 token 效率和延迟之间取得平衡。基于 DOM 的交互执行速度快但消耗很多 token，而基于截图的交互较慢但 token 效率更高。例如，当要求 Claude 总结 Wikipedia 时，从 DOM 中提取文本更高效。当在 Amazon 上寻找新的笔记本电脑包时，截图更高效（因为提取整个 DOM 会消耗大量 token）。在我们的 Claude for Chrome 产品中，我们开发了评估来检查 Agent 是否为每个上下文选择了正确的工具。这使我们能够更快、更准确地完成基于浏览器的任务。
如何看待 Agent 评估中的非确定性
无论 Agent 类型如何，Agent 行为在不同运行之间会有变化，这使得评估结果比初看起来更难解释。每个任务都有自己的成功率，也许一个任务 90%，另一个 50%，而且在一次评估运行中通过的任务可能在下一次失败。有时，我们想要衡量的是 Agent 在一个任务上成功的频率（试验中的比例）。
两个指标有助于捕捉这种细微差别：
pass@k[18] 衡量 Agent 在 k 次尝试中至少获得一个正确解决方案的可能性。随着 k 增加，pass@k 分数上升：更多「射门机会」意味着至少成功 1 次的几率更高。50% 的 pass@1 分数意味着模型在第一次尝试时成功完成了评估中一半的任务。在编码中，我们通常最感兴趣的是 Agent 第一次就找到解决方案：pass@1。在其他情况下，提出多个解决方案是有效的，只要有一个有效。
pass^k[19] 衡量所有 k 次试验都成功的概率。随着 k 增加，pass^k 下降，因为要求在更多试验中保持一致是更难达到的标准。如果你的 Agent 每次试验成功率为 75%，运行 3 次试验，三次都通过的概率是 (0.75)³ ≈ 42%。这个指标对于用户期望每次都有可靠行为的面向客户的 Agent 尤为重要。
随着试验次数增加，pass@k 和 pass^k 出现分化。在 k=1 时，它们相同（都等于每次试验的成功率）。到 k=10 时，它们讲述了相反的故事：pass@k 接近 100%，而 pass^k 下降到 0%。
两个指标都有用，使用哪个取决于产品要求：pass@k 用于一次成功就够的工具，pass^k 用于一致性至关重要的 Agent。
从零到一：优秀 Agent 评估的路线图
本节提出了我们从无评估到可信赖评估的实用、经过实战检验的建议。把这看作评估驱动 Agent 开发的路线图：早期定义成功、清晰地衡量它、持续迭代。
为初始评估数据集收集任务
第 0 步：尽早开始
我们看到团队推迟构建评估是因为他们认为需要数百个任务。实际上，从真实失败中提取的 20-50 个简单任务就是一个很好的开始。毕竟，在早期 Agent 开发中，系统的每次变更通常都有明确、明显的影响，这种大效应意味着小样本量就足够了。更成熟的 Agent 可能需要更大、更困难的评估来检测更小的效应，但最好在开始时采用 80/20 法则。评估等得越久越难构建。早期，产品需求自然转化为测试用例。等太久你就得从线上系统反向工程成功标准了。
第 1 步：从你已经手动测试的内容开始
从你在开发过程中进行的手动检查开始，你在每次发布前验证的行为和终端用户尝试的常见任务。如果你已经在生产环境中，查看你的 bug 跟踪器和支持队列。将用户报告的失败转换为测试用例可确保你的套件反映实际使用情况；按用户影响确定优先级有助于你在重要的地方投入精力。
第 2 步：编写明确的任务和参考解决方案
保证任务质量比看起来更难。好的任务是两个领域专家能够独立得出相同通过/失败判定的任务。他们自己能通过这个任务吗？如果不能，任务需要改进。任务规格中的歧义会变成指标中的噪音。这同样适用于基于模型的评分器的标准：模糊的评分标准产生不一致的判断。
每个任务应该能被正确遵循指令的 Agent 通过。这可能很微妙。例如，审计 Terminal-Bench 发现，如果任务要求 Agent 编写脚本但没有指定文件路径，而测试假设脚本在特定文件路径，Agent 可能会在没有自身过错的情况下失败。评分器检查的所有内容都应该在任务描述中清楚说明；Agent 不应该因为规格歧义而失败。对于前沿模型，在多次试验中 0% 的通过率（即 0% pass@100）通常是任务有问题的信号，而不是 Agent 能力不足，是需要仔细检查任务规格和评分器的信号。
对于每个任务，创建一个参考解决方案很有用：一个已知可工作并通过所有评分器的输出。这证明任务是可解决的，并验证评分器配置正确。
第 3 步：构建平衡的问题集
同时测试行为应该发生和不应该发生的情况。单边评估会产生单边优化。例如，如果你只测试 Agent 是否在应该搜索时搜索，你可能最终得到一个几乎什么都搜索的 Agent。尽量避免类别不平衡[20]的评估。
我们在为 Claude.ai[21] 构建网络搜索评估时亲身体会到了这一点。挑战是防止模型在不应该搜索时搜索，同时保持其在适当时进行广泛研究的能力。团队构建了涵盖两个方向的评估：模型应该搜索的查询（如查找天气）和模型应该从现有知识回答的查询（如「谁创立了 Apple？」）。在触发不足（应该搜索时不搜索）和触发过度（不应该搜索时搜索）之间取得正确平衡很困难，需要多轮改进 prompt 和评估。随着更多示例问题出现，我们继续添加到评估中以提高覆盖率。
设计评估框架和评分器
第 4 步：构建具有稳定环境的健壮评估框架
评估中的 Agent 与生产中使用的 Agent 功能大致相同至关重要，环境本身不应引入额外噪音。每次试验应该从干净的环境开始来「隔离」。运行之间不必要的共享状态（遗留文件、缓存数据、资源耗尽）可能导致由于基础设施不稳定而非 Agent 性能的相关失败。共享状态也可能人为地提高性能。例如，在一些内部评估中，我们观察到 Claude 通过检查之前试验的 git 历史在某些任务上获得不公平的优势。如果多个不同的试验因为环境中的相同限制（如有限的 CPU 内存）而失败，这些试验不是独立的，因为它们受到相同因素的影响，评估结果对于衡量 Agent 性能变得不可靠。
第 5 步：深思熟虑地设计评分器
如上所述，优秀的评估设计涉及为 Agent 和任务选择最佳评分器。我们建议在可能的情况下选择确定性评分器，在必要时或需要额外灵活性时使用 LLM 评分器，并谨慎使用人工评分器进行额外验证。
有一种常见的本能是检查 Agent 是否遵循了非常具体的步骤，比如按正确顺序进行的工具调用序列。我们发现这种方法过于僵化，导致过于脆弱的测试，因为 Agent 经常找到评估设计者没有预料到的有效方法。为了不必要地惩罚创造性，通常最好评分 Agent 产生了什么，而不是它采取的路径。
对于有多个组成部分的任务，建立部分得分机制。一个正确识别问题并验证客户但未能处理退款的支持 Agent，明显比一个立即失败的 Agent 更好。在结果中表示这种成功的连续性很重要。
模型评分通常需要仔细迭代以验证准确性。LLM 作为评判者的评分器应该与人类专家密切校准，以确信人工评分和模型评分之间差异很小。为避免幻觉，给 LLM 一个出路，比如在信息不足时提供返回「未知」的指令。创建清晰、结构化的评分标准来评分任务的每个维度也有帮助，然后用独立的 LLM 作为评判者对每个维度评分，而不是使用一个来评分所有维度。一旦系统健壮，只需偶尔使用人工审查即可。
一些评估有微妙的失败模式，即使 Agent 表现良好也会导致低分，因为 Agent 由于评分 bug、Agent 框架限制或歧义而未能解决任务。即使是经验丰富的团队也可能错过这些问题。例如，Opus 4.5 最初在 CORE-Bench 上得分 42%[22]，直到 Anthropic 研究员发现多个问题：严格的评分惩罚「96.12」而期望「96.124991…」、歧义的任务规格和不可能精确重现的随机任务。在修复 bug 并使用限制较少的脚手架后，Opus 4.5 的分数跃升至 95%。同样，METR 发现[23]他们的时间范围基准中有几个配置错误的任务，要求 Agent 优化到指定的分数阈值，但评分要求超过该阈值。这惩罚了像 Claude 这样遵循指令的模型，而忽略指定目标的模型反而获得了更好的分数。仔细检查任务和评分器有助于避免这些问题。
使你的评分器抵抗绕过或黑客攻击。Agent 不应该能够轻易「作弊」评估。任务和评分器的设计应该使得通过真正需要解决问题，而不是利用意外的漏洞。
长期维护和使用评估
第 6 步：检查记录
除非你阅读许多试验的记录和评分，否则你不会知道你的评分器是否工作良好。在 Anthropic，我们投资了用于查看评估记录的工具，并定期花时间阅读它们。当任务失败时，记录告诉你 Agent 是真的犯了错误还是你的评分器拒绝了一个有效的解决方案。它还经常揭示关于 Agent 和评估行为的关键细节。
失败应该看起来是公平的：很清楚 Agent 做错了什么以及为什么。当分数没有攀升时，我们需要确信这是由于 Agent 性能而不是评估。阅读记录是你验证评估正在衡量真正重要内容的方式，是 Agent 开发的关键技能。
第 7 步：监控能力评估饱和
100% 的评估跟踪回归但不提供改进信号。当 Agent 通过所有可解决的任务时，就会发生评估饱和，没有改进空间。例如，SWE-Bench Verified 分数今年从 30% 开始，前沿模型现在接近 80% 的饱和点。随着评估接近饱和，进展也会放缓，因为只剩下最困难的任务。这可能使结果具有欺骗性，因为大的能力提升表现为分数的小幅增加。例如，代码审查初创公司 Qodo[24] 最初对 Opus 4.5 印象不深，因为他们的一次性编码评估没有捕捉到更长、更复杂任务上的收益。作为回应，他们开发了一个新的 Agent 评估框架，提供了更清晰的进展图景。
作为规则，在有人深入研究评估细节并阅读一些记录之前，我们不会轻信评估分数。如果评分不公平、任务模糊、有效解决方案被惩罚或框架限制模型，评估应该修订。
第 8 步：通过开放贡献和维护保持评估套件长期健康
评估套件是一个活的工件，需要持续关注和明确的所有权才能保持有用。
在 Anthropic，我们尝试了各种评估维护方法。最有效的是建立专门的评估团队来拥有核心基础设施，而领域专家和产品团队贡献大部分评估任务并自己运行评估。
对于 AI 产品团队，拥有和迭代评估应该像维护单元测试一样例行。团队可能在「有效」的早期测试但未能满足设计良好的评估本会早期发现的未明确期望的 AI 功能上浪费数周。定义评估任务是压力测试产品需求是否足够具体以开始构建的最佳方式之一。
我们建议实践评估驱动开发：在 Agent 能够完成之前构建评估来定义计划的能力，然后迭代直到 Agent 表现良好。在内部，我们经常构建今天「足够好」但押注几个月后模型能做什么的功能。从低通过率开始的能力评估使这变得可见。当新模型发布时，运行套件可以快速揭示哪些押注得到了回报。
最接近产品需求和用户的人最有能力定义成功。凭借当前的模型能力，产品经理、客户成功经理或销售人员可以使用 Claude Code 贡献评估任务作为 PR：让他们这样做！或者更好的是，积极赋能他们。
评估如何与其他方法配合以全面理解 Agent
自动化评估可以在数千个任务中对 Agent 运行而无需部署到生产或影响真实用户。但这只是理解 Agent 性能的众多方式之一。
完整的图景包括生产监控、用户反馈、A/B 测试、手动记录审查和系统性人工评估。
理解 AI Agent 性能的方法概述
| 自动化评估 | ||
| 生产监控 | ||
| A/B 测试 | ||
| 用户反馈 | ||
| 手动记录审查 | ||
| 系统性人工研究 |
这些方法对应 Agent 开发的不同阶段。自动化评估在发布前和 CI/CD 中特别有用，在每次 Agent 变更和模型升级时运行，作为质量问题的第一道防线。生产监控在发布后启动以检测分布漂移和未预料的真实世界失败。A/B 测试在你有足够流量时验证重大变更。用户反馈和记录审查是填补空白的持续实践：持续分类反馈、每周抽样阅读记录，并根据需要深入挖掘。将系统性人工研究保留用于校准 LLM 评分器或评估人类共识作为参考标准的主观输出。
就像安全工程中的瑞士奶酪模型[25]一样，没有单一的评估层能捕捉每个问题。多种方法组合起来，穿过一层的失败会被另一层捕捉。
最有效的团队结合这些方法，自动化评估用于快速迭代、生产监控用于基准真相、定期人工审查用于校准。
结论
没有评估的团队会陷入被动循环：修一个失败、制造另一个、无法区分真正的回退和噪音。早期投资的团队发现相反的情况：开发加速，因为失败变成测试用例、测试用例防止回退、指标取代猜测。评估给整个团队一个明确的目标来攀登，把「Agent 感觉变差了」变成可操作的东西。价值是复合的，但只有当你把评估作为核心组件而不是事后想法时。
模式因 Agent 类型而异，但这里描述的基本原则是不变的。尽早开始，不要等待完美的套件。从你看到的失败中获取真实的任务。定义明确、健壮的成功标准。深思熟虑地设计评分器并组合多种类型。确保问题对模型来说足够难。迭代评估以提高信噪比。阅读记录！
AI Agent 评估仍然是一个新生的、快速发展的领域。随着 Agent 承担更长的任务、在多 Agent 系统中协作、处理越来越主观的工作，我们将需要调整我们的技术。随着我们学到更多，我们会继续分享最佳实践。
