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