AI 代理评测去神秘化

• 原文链接：https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents [103]
• 发布时间：2026-01-09
• 作者：Mikaela Grace、Jeremy Hadfield、Rodrigo Olivares、Jiri De Jonghe

让代理有用的能力，也让它更难评测。能跨部署奏效的策略，需要匹配被测系统复杂度的组合方法。

引言

好的评测能让团队更有把握地发布 AI 代理。没有评测，就很容易陷入被动循环——问题只在生产中暴露，而修复一个失败又引出另一个失败。评测能在影响用户之前让问题与行为变化可见，其价值会在代理生命周期中不断复利。

正如我们在《Building effective agents》中所述，代理会跨多轮运行：调用工具、修改状态，并根据中间结果调整策略。这些让 AI 代理有用的能力——自治、智能与灵活——也让它更难被评测。

通过内部实践以及与处在代理开发前沿的客户合作，我们总结了更严格、更有用的代理评测设计方法。以下是在真实部署中、跨多种架构与用例验证有效的做法。

评测的结构

评测（evaluation，简称 eval）是对 AI 系统的测试：给 AI 一个输入，再用评分逻辑对输出打分以衡量成功与否。本文聚焦在开发阶段、无需真实用户即可运行的自动化评测。

单轮评测很直观：一条提示、一条响应、再加评分逻辑。早期 LLM 主要靠单轮、非代理评测，而随着能力提升，多轮评测越来越常见。

图注：在简单评测中，代理处理一个提示，评测器检查输出是否符合预期。在更复杂的多轮评测里，编码代理会获得工具、任务（此处为构建 MCP server）和环境，执行一次“代理循环”（工具调用与推理），并在环境中写入实现。随后用单元测试验证 MCP server 是否可用。

代理评测更复杂。代理跨多轮使用工具、修改环境并随时调整——错误会传播并叠加。前沿模型还会发现超出静态评测假设的创造性解法。比如 Opus 4.5 在 𝜏2-bench 的订票任务中发现政策漏洞而绕过，按评测规则是“失败”，但实际给用户更优解。

构建代理评测时，我们使用以下定义：

• 任务（task，也叫 problem 或 test case）：一个单独的测试，具有明确输入与成功标准。
• 试次（trial）：每次执行任务的尝试。由于模型输出存在随机性，我们会运行多个试次以获得更稳定的结果。
• 评测器（grader）：用于评估代理表现某个方面的打分逻辑。一个任务可以有多个评测器，每个评测器包含多个断言（有时叫 checks）。
• 记录（transcript，也称 trace 或 trajectory）：一次试次的完整记录，包括输出、工具调用、推理、中间结果与其他交互。对 Anthropic API 来说，这对应评测结束时的完整 messages 数组——其中包含所有 API 调用及返回。
• 结果（outcome）：试次结束时环境中的最终状态。比如订票代理在记录里说“已完成订票”，但真正结果是环境的 SQL 数据库里是否存在预约记录。
• 评测框架（evaluation harness）：端到端运行评测的基础设施，负责提供指令与工具、并行运行任务、记录步骤、评分并汇总结果。
• 代理框架（agent harness 或 scaffold）：让模型以代理方式行动的系统，负责处理输入、编排工具调用并返回结果。评测“代理”时，实际评测的是框架与模型的组合。例如 Claude Code 是一个灵活的代理框架，我们通过 Agent SDK 的核心原语构建了长任务代理框架。
• 评测套件（evaluation suite）：一组任务集合，用于衡量特定能力或行为。套件内任务通常共享一个宏观目标，例如客服套件可覆盖退款、取消与升级等场景。

图注：代理评测的组成部分。

为什么要做评测？

团队在刚开始做代理时，往往能靠手工测试、自用（dogfooding）和直觉走得很远。更严格的评测看起来像是拖慢发布的开销。但当代理进入生产并开始规模化后，没有评测的构建方式就会开始失效。

拐点通常出现在用户反馈“改完之后更差了”，而团队只能靠猜测和试错来验证。没有评测时，调试是被动的：等投诉、手工复现、修 bug，然后祈祷没有别的回归。团队无法区分真实回归与噪声，无法在发布前自动跑数百场景，也无法量化改进幅度。

我们多次看到这样的演进路径。例如 Claude Code 起初依赖 Anthropic 内部员工和外部用户反馈进行快速迭代。后来我们引入评测——先覆盖简洁性与文件编辑等狭窄领域，再扩展到“过度工程化”等更复杂的行为。这些评测帮助定位问题、指导改进，并聚焦研究—产品协作。与生产监控、A/B 测试、用户研究等结合后，评测为 Claude Code 的规模化持续改进提供信号。

评测在代理生命周期的任何阶段都很有价值。早期它迫使产品团队明确“成功意味着什么”，后期则帮助维持一致的质量门槛。

Descript 的代理帮助用户剪辑视频，他们围绕一个成功剪辑流程的三个维度建立评测：别把东西弄坏、按我的要求做、而且做得好。他们从人工评分演进到 LLM 评测器，并由产品团队定义标准、定期用人工校准；现在会常态运行“质量基准”与“回归测试”两套套件。Bolt AI 团队是在代理已经广泛使用后才开始做评测的；三个月内，他们搭建了一个评测系统：运行代理并用静态分析评分，用浏览器代理测试应用，并用 LLM 评委评估指令遵循等行为。

有些团队在开发之初就创建评测，有些则在规模化后才补上，以消除改进瓶颈。评测对早期尤为关键，因为它能显式编码预期行为。两个工程师读同一份规格说明，可能对边界情况有不同理解；评测套件能消除这种歧义。无论何时建立，评测都会加速开发。

评测也决定你能多快采用新模型。更强模型出现时，没有评测的团队需要数周测试；有评测的团队能迅速识别模型优势、调整提示词，并在几天内完成升级。

一旦评测存在，你就“免费”拥有基线与回归测试：延迟、token 消耗、单任务成本和错误率都可在固定任务集上跟踪。评测也可能成为产品与研究团队之间最高带宽的沟通通道，让研究有明确可优化的指标。显然，评测价值远不止回归与改进的跟踪。它的复利效应容易被忽视，因为成本在当下可见，而收益在未来累积。

如何评测 AI 代理

如今规模化部署的代理类型主要包括：编码代理、研究代理、计算机使用代理和对话代理。它们可能服务于不同行业，但评测方法高度相似。你不必从零发明一套评测体系。下面是面向多种代理类型的验证方法：先作为基础，再按你的领域扩展。

代理的评测器类型

代理评测通常结合三类评测器：代码型、模型型与人工型。每个评测器会评估记录或结果中的某一部分。有效的评测设计，关键在于为任务选对评测器。

代码型评测器

方法	优点	局限
字符串匹配检查（精确、正则、模糊等） 二值测试（fail-to-pass、pass-to-pass） 静态分析（lint、类型、安全） 结果验证 工具调用验证（工具使用、参数） 轨迹分析（回合数、token 用量）	快速 低成本 客观 可复现 易调试 可验证具体条件	对合理变体很脆弱（不匹配预期模式） 缺乏细腻度 对更主观的任务评估能力有限

模型型评测器

方法	优点	局限
基于 rubric 的评分 自然语言断言 成对比较 参考答案评估 多评委共识	灵活 可扩展 能捕捉细节 适合开放式任务 支持自由输出	非确定性 比代码评测更昂贵 需要与人工评测校准以保证准确性

人工评测器

方法	优点	局限
专家评审（SME） 众包判断 抽样复核 A/B 测试 评审一致性分析	黄金标准质量 更贴近专家用户判断 可用于校准模型评测器	昂贵 慢 常需要规模化的人类专家资源

对每个任务，评分方式可以是加权（多个评测器的综合分需达阈值）、二元（全部评测器都要通过）或混合模式。

能力评测 vs 回归评测

能力（或“质量”）评测回答“这个代理擅长什么？”它们应从较低通过率开始，瞄准代理当前不擅长的任务，为团队提供一个“可攀登的山”。

回归评测回答“这个代理是否还保持原来的能力？”通过率应接近 100%。它们防止性能回退：分数下降意味着某些东西坏了，需要修复。在提升能力评测的同时，必须持续运行回归评测，避免改动带来旁路问题。

当代理上线并优化后，通过率很高的能力评测可以“毕业”成为回归套件，持续运行以捕捉漂移。那些曾经衡量“能不能做到”的任务，会转为衡量“还能不能稳定做到”。

评测编码代理

编码代理会写代码、测试、调试，像人类开发者一样导航代码库和运行命令。现代编码代理的有效评测通常依赖：清晰的任务规格、稳定的测试环境，以及对生成代码的充分测试。

确定性评测器对编码代理尤其自然，因为软件评测相对直观：代码能跑吗？测试通过吗？两个广泛使用的编码代理基准——SWE-bench Verified 与 Terminal-Bench——都采用这种方法。SWE-bench Verified 给代理提供热门 Python 仓库的 GitHub issue，用测试套件来评分：只要修复失败测试且不破坏既有测试才算通过。LLM 在一年内从 40% 提升到 >80%。Terminal-Bench 则测试端到端技术任务，比如从源码构建 Linux 内核或训练一个 ML 模型。

当你已有一套“通过/失败”的结果测试时，也常常需要评估记录本身。例如，可以用启发式的代码质量规则评估生成代码，不止看测试结果；也可用具备清晰 rubric 的模型评测器，评估代理如何调用工具、如何与用户交互等行为。

示例：编码代理的理论评测

考虑一个编码任务：代理必须修复“密码为空时可绕过认证”的漏洞。如下示例 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 rubric 评估整体代码质量，只有在必要时才补充额外评测器与指标。

评测对话代理

对话代理应用于客服、销售、教练等场景。与传统聊天机器人不同，它们会维持状态、调用工具并在对话中执行动作。虽然编码与研究代理也可能多轮交互，但对话代理有一个独特挑战：对话质量本身就是评测目标。有效评测通常依赖可验证的最终状态，以及同时覆盖任务完成度与交互质量的 rubric。与大多数评测不同，对话代理往往需要第二个 LLM 来模拟用户。我们在对齐审计代理中就采用了这种方法，通过长时对抗对话进行压力测试。

对话代理的成功是多维度的：工单是否解决（状态检查）、是否在 10 轮内结束（记录约束）、语气是否恰当（LLM rubric）等。两个多维度基准是 𝜏-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 基准要求代理在开放网络中找“草堆里的针”——问题易验证但难解。

构建研究代理评测的一种策略是组合评测器：用“可溯源性”检查验证论断是否由检索来源支持；用“覆盖度”检查确保关键事实被包含；用“来源质量”检查确认参考来源权威，而不仅是最先检索到的内容。对于有客观答案的问题（例如“公司 X 的 Q3 收入是多少？”），可用精确匹配。LLM 可以标注缺失与不被支持的论断，也能评估开放式综合的连贯性与完整性。

鉴于研究质量的主观性，LLM rubric 应频繁与专家人工判断校准，才能有效评估研究代理。

Computer use 代理

Computer use 代理通过与人类相同的界面操作软件——截图、鼠标点击、键盘输入与滚动——而不是通过 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 也会升高——“射门次数”更多意味着至少一次成功的概率更大。pass@1 为 50% 意味着模型在首次尝试中成功解决一半任务。在编码场景里，我们经常关心 pass@1；在其他场景，只要多次尝试中有一个方案可行也可以接受。

pass^k 衡量的是 k 次试次全部成功的概率。k 增大时，pass^k 会下降，因为要求一致性更难。如果代理单次成功率为 75%，运行 3 次的全部成功概率是 (0.75)^3 ≈ 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：写清晰且可判定的任务，并提供参考解

任务质量比想象中难。一个好的任务是：两个领域专家独立阅读后，会得出相同的通过/失败判断。任务本身他们能完成吗？如果不能，任务就需要改。规格含糊会变成指标噪声，模型评测 rubric 也是同理：模糊的标准只会产生不一致判断。

每个任务都应当可被“正确遵循指令”的代理完成。这很微妙。例如在审计 Terminal-Bench 时我们发现：任务要求代理写脚本，但没规定脚本路径，而测试却假设特定路径，代理可能“无辜失败”。评测器检查的内容必须从任务描述中清晰推断。对于前沿模型，如果在大量试次下通过率仍为 0（例如 0% pass@100），这往往不是模型能力问题，而是任务或评测器出错的信号。请回头检查任务规格与评测器。

对每个任务，最好准备一个参考解：已知可以通过全部评测器的输出。这证明任务可解，并验证评测器配置正确。

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

既要覆盖“应当发生的行为”，也要覆盖“不该发生的行为”。单边评测会导致单边优化。例如如果只测试“该搜索时是否搜索”，就可能训练出一个“什么都搜”的代理。尽量避免类别不平衡评测。

我们在 Claude.ai 的网页搜索评测中就经历过这种难题：既要避免模型在不该搜索时搜索，又要保留其需要时深度检索的能力。团队为两类问题建立评测：应搜索的问题（如查天气）与应直接回答的问题（如“苹果公司创始人是谁？”）。在“触发不足”与“触发过度”之间找到平衡很难，需要多轮迭代提示词与评测。随着新问题出现，我们持续扩充评测覆盖。

设计评测框架与评测器

步骤 4：构建稳健的评测框架与稳定环境

评测中的代理应当与生产中的代理基本一致，环境也不应引入噪声。每个试次都应从干净环境开始以确保“隔离”。不必要的共享状态（残留文件、缓存、资源耗尽）会导致基础设施层面的相关失败，而不是代理能力问题；也会虚假抬高性能。例如我们在内部评测中发现 Claude 会利用前一次试次留下的 git 历史获得不公平优势。如果多个试次因为同一环境限制（如 CPU 内存不足）失败，它们就不是独立的，评测结果将无法可靠衡量代理能力。

步骤 5：慎重设计评测器

如上所述，优秀评测设计的关键是为任务与代理选择合适的评测器。我们建议：能用确定性评测就用确定性评测，需要灵活性时用 LLM 评测器，人工评测只在必要时使用。

很多人本能地要求代理遵循特定步骤（例如工具调用顺序）。我们发现这种方式过于僵硬，容易导致脆弱评测，因为代理经常找到评测设计者未预料的有效路径。为了不惩罚创造性，通常更应评估“产出结果”，而不是“走过的路径”。

对于多组件任务，应引入“部分得分”。一个客服代理若能正确识别问题并验证身份，却未能完成退款，明显好过直接失败。结果应体现这种“成功程度”的连续性。

模型评测需要反复迭代以验证准确性。LLM-as-judge 必须与人类专家紧密校准，确保模型评分与人工评分差异足够小。为避免幻觉，应提供“退路”，例如要求信息不足时返回“Unknown”。也可通过清晰、结构化 rubric 评估每个维度，再用多个 LLM 分别评分，而不是用一个 LLM 评所有维度。系统稳定后，只需偶尔进行人工复核。

一些评测存在隐蔽失败模式，即便代理表现良好也会低分，原因可能是评测器 bug、代理框架限制或任务歧义。即便成熟团队也可能忽略这些问题。例如 Opus 4.5 在 CORE-Bench 上最初只有 42%，后来研究员发现多处问题：严格评分导致“96.12”无法匹配“96.124991…”，任务描述含糊，以及随机任务无法精确复现。修复后并放宽脚手架约束，Opus 4.5 得分跃升至 95%。类似地，METR 在时间跨度基准中发现多项任务配置错误：任务要求代理达到某个分数阈值，但评分却要求“超过”该阈值。结果是遵循指令的模型被惩罚，忽略目标的模型反而得分更高。仔细复核任务与评测器能避免这类问题。

让评测器能抵抗“绕过”或“作弊”。任务与评测器应设计为：只有真正解决问题才能通过，而不是利用意外漏洞。

长期维护与使用评测

步骤 6：检查记录

不阅读大量试次的记录与评分，你无法知道评测器是否有效。在 Anthropic，我们投入了查看评测记录的工具，并定期阅读。当任务失败时，记录能告诉你是代理真的犯错，还是评测器错误地否定了有效解；它也常揭示代理与评测行为的关键细节。

失败应当“看起来公平”：清楚知道代理错在哪、为什么错。当分数无法提升时，你需要确信原因在于代理能力，而不是评测本身。阅读记录是验证“评测是否在衡量真正重要的东西”的关键技能。

步骤 7：监控能力评测的饱和

一个达到 100% 的评测只能监控回归，却无法带来改进信号。评测饱和意味着代理已经通过所有可解任务，没有提升空间。例如今年 SWE-Bench Verified 从 30% 起步，前沿模型已接近 >80% 的饱和区。随着评测趋近饱和，进展会放缓，因为剩下的都是最难任务。这会使结果具有欺骗性：能力提升很大，但分数提升很小。例如代码审查创业公司 Qodo 最初对 Opus 4.5 不满意，因为他们的一次性编码评测没有捕捉到长任务的提升；于是他们开发了新的 agentic 评测框架，才获得更清晰的进步信号。

原则上，我们不会在有人深入评测细节并阅读部分记录前，就把分数当真。如果评分不公平、任务含糊、有效解被惩罚，或脚手架限制了模型，评测就必须修订。

步骤 8：通过开放贡献与持续维护保持评测套件健康

评测套件是“活的资产”，需要长期维护与明确责任，才能持续有效。

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

对 AI 产品团队而言，维护评测应像维护单元测试一样常规。团队可能在早期测试中浪费数周做“看起来能用”的功能，但这些功能未达成未写明的预期，而一个设计良好的评测本可以更早暴露问题。定义评测任务是检验产品需求是否足够具体的最佳方式之一。

我们建议实践“评测驱动开发”：先用评测定义计划能力，再迭代到代理表现良好。内部实践中，我们经常构建“当前刚好够用”的功能，并押注未来几个月的模型能力。低通过率的能力评测会让这种押注变得可见。当新模型发布时，快速运行套件即可判断哪些押注兑现。

最接近产品需求与用户的人，最有资格定义成功标准。凭现有模型能力，产品经理、客户成功或销售人员都可以用 Claude Code 提交一个评测任务 PR——让他们来做！或者更好，主动支持他们。

图注：创建有效评测的过程。

评测如何与其他方法组合，形成对代理的整体理解

自动化评测可以在不部署生产、不影响真实用户的情况下，对代理运行成千上万的任务。但这只是理解代理表现的其中一种方法。完整视角还包括生产监控、用户反馈、A/B 测试、人工记录审阅与系统性人工评估。

理解 AI 代理性能的手段概览

方法	优点	局限
自动化评测 在没有真实用户的情况下以程序方式运行测试	迭代更快 完全可复现 不影响用户 可在每次提交上运行 可在不部署生产的情况下规模化测试场景	需要更高的前期投入 产品与模型演进时需要持续维护以避免漂移 如果与真实使用不匹配，可能造成虚假信心
生产监控 跟踪线上系统指标与错误	揭示真实用户行为 捕捉合成评测遗漏的问题 提供真实的代理表现信号	反应式，问题会先影响用户 信号可能嘈杂 需要持续的监测投入 缺乏“评分”的真值
A/B 测试 用真实流量比较不同版本	测量真实用户结果（留存、任务完成） 控制混杂因素 可规模化且系统化	速度慢，往往需要数天或数周达到统计显著 只能测试已发布变更 缺少“为什么”的解释信号，且难以充分审阅记录
用户反馈 明确的差评/故障反馈	能暴露未预料的问题 带来真实用户案例 反馈往往与产品目标相关	稀疏且自选择 偏向严重问题 用户很少解释失败原因 不可自动化 过度依赖用户会产生负面体验
人工记录审阅 人工阅读代理对话记录	建立对失败模式的直觉 捕捉自动检查遗漏的细微问题 帮助校准“好”的标准	耗时 难规模化、覆盖不一致 评审疲劳/差异会影响信号质量 通常只能给定性信号而非定量评分
系统性人工研究 由训练过的评审对代理输出进行结构化评分	多名人工评审给出黄金标准 适合主观或模糊任务 为模型评测器校准提供信号	相对昂贵且反馈慢 难以高频运行 评审分歧需要协调 复杂领域（法律、金融、医疗）需专家参与

这些方法对应代理开发的不同阶段。自动化评测适合上线前与 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 发布，便于运行既有基准与自定义套件。Promptfoo 轻量、灵活、开源，强调声明式 YAML 配置，断言类型从字符串匹配到 LLM-as-judge rubric；我们在不少产品评测中使用它的一个版本。Braintrust 将离线评测与生产可观测、实验跟踪结合，适合既要开发迭代又要线上监控的团队，其 autoevals 库内置事实性、相关性等评分器。LangSmith 提供追踪、离线与在线评测、数据集管理，并与 LangChain 生态深度集成。Langfuse 提供类似能力，是支持数据驻留需求的可自托管开源替代。许多团队会组合多个工具、自建评测框架，或仅用简单脚本起步。我们的经验是：框架能加速并标准化，但它们的价值最终取决于你运行的评测任务质量；最好先选一个符合工作流的框架，再把精力投入到高质量任务与评测器的迭代上。