Anthropic 再发长文：首次详细揭秘Agent的评估全过程「Claude code开发过程的经验总结」-AI Express News

↑阅读之前记得关注+星标⭐️，😄，每天才能第一时间接收到更新

如何自信地发布AI Agent？

没有好的评估（Evals），团队很容易陷入“头痛医头、脚痛医脚”的被动循环——问题总是在生产环境中才暴露，修复一个bug又引发了新的问题。

评估，能在问题影响用户之前就将其可视化，其价值会在Agent的整个生命周期中不断累积。

Anthropic在自家明星产品Claude Code等Agent的开发过程中，以及与前沿客户的合作中，总结出了一套严谨且实用的AI Agent评估方法

这篇文章，就是对这些实战经验的全面梳理

原文：

https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents

评估的基本结构

一个“评估”（eval），本质上就是对AI系统的测试：给AI一个输入，然后用评分逻辑来衡量其输出是否成功。本文主要关注在开发阶段无需真实用户即可运行的自动化评估。

对于早期的LLM，单轮评估很直接：一个提示（prompt），一个响应，一套评分逻辑。但随着AI能力进化，多轮评估变得越来越普遍

Agent的评估则更为复杂。Agent会在多轮交互中使用工具，修改环境状态，并根据中间结果进行调整——这意味着错误会传播和累积。更重要的是，前沿模型能找到超越静态评估限制的创造性解决方案。例如，Opus 4.5在解决一个预订航班的测试问题时，通过发现政策漏洞，找到了一个对用户更好的方案，虽然它“失败”了评估，但实际上给出了更优解

在构建Agent评估时，Anthropic使用了以下定义：

• 任务（Task）：一个单独的测试，包含明确的输入和成功标准。
• 尝试（Trial）：对一个任务的单次尝试。由于模型输出存在随机性，通常会运行多次尝试以获得更一致的结果。
• 评分器（Grader）：用于对Agent性能某个方面进行评分的逻辑。一个任务可以有多个评分器。
• 记录（Transcript）：一次尝试的完整记录，包括输出、工具调用、思考过程、中间结果等。
• 结果（Outcome）：尝试结束时环境的最终状态。比如，订票Agent可能在记录中说“您的机票已预订”，但真正的结果是环境的SQL数据库中是否存在预订记录。
• 评估框架（Evaluation harness）：运行端到端评估的基础设施。它提供指令和工具，并行运行任务，记录所有步骤，对输出评分并汇总结果。
• Agent框架（Agent harness）：使模型能作为Agent行动的系统，负责处理输入、协调工具调用并返回结果。我们评估“一个Agent”时，实际是在评估Agent框架和模型的组合。
• 评估套件（Evaluation suite）：为衡量特定能力或行为而设计的一系列任务集合

为什么要构建评估？

在Agent开发初期，团队靠手动测试、内部试用和直觉就能走很远。但一旦Agent进入生产并开始规模化，没有评估的开发模式就会崩溃。

转折点通常是：用户反馈Agent在更新后“变差了”，而团队却“盲目飞行”，无法验证问题。调试变成被动响应：等待投诉、手动复现、修复bug，然后祈祷没有引入新的衰退（regression）。

Anthropic的Claude Code就经历了这一过程。初期依赖内外部用户的反馈快速迭代，后期加入了针对简洁性、文件编辑、过度工程化等复杂行为的评估。这些评估与生产监控、A/B测试、用户研究等方法相结合，为Claude Code的持续改进提供了关键信号。

无论是Descript（视频编辑Agent）还是Bolt AI，实践都证明了评估的价值：

• 早期：评估能迫使团队明确定义“成功”的标准，解决对需求的模糊理解。
• 后期：评估有助于维持一致的质量标准，防止产品质量下滑。
• 模型升级：当新模型发布时，有评估的团队能在几天内完成测试、调优和升级，而没有评估的团队则可能需要数周。
• 免费收益：一旦建立评估，就能免费获得基线和衰退测试，追踪延迟、token用量、成本和错误率等指标。

评估的前期投入是可见的，但其复利价值会在后期逐渐显现。

如何评估AI Agent？

Agent评估通常结合三种评分器：基于代码的、基于模型的和人工的

评分器类型

1. 基于代码的评分器 (Code-based graders)

• 方法：字符串匹配、单元测试、静态分析、结果验证（如数据库状态）、工具调用验证等。
• 优点：快速、廉价、客观、可复现、易于调试。
• 缺点：对于有效的变体可能过于脆弱，缺乏细微差别判断，不适用于主观任务。

2. 基于模型的评分器 (Model-based graders)

• 方法：基于评分规则（rubric）的打分、自然语言断言、成对比较、多评委共识等。
• 优点：灵活、可扩展、能捕捉细微差别、处理开放式任务和自由格式输出。
• 缺点：非确定性、比代码评分器昂贵、需要与人工评分器进行校准以保证准确性。

3. 人工评分器 (Human graders)

• 方法：领域专家（SME）审查、众包判断、抽样检查、A/B测试等。
• 优点：黄金标准质量，能匹配专家用户的判断，用于校准模型评分器。
• 缺点：昂贵、缓慢、需要规模化的人类专家。

能力评估 vs. 衰退评估

• 能力评估（Capability evals）：回答“这个Agent擅长做什么？”。初始通过率应较低，为团队设定一个“需要攀登的高山”。
• 衰退评估（Regression evals）：回答“Agent是否还能处理好以前的任务？”。通过率应接近100%，防止产品质量倒退。

当能力评估的通过率很高时，可以“毕业”成为一个衰退评估套件，持续运行以捕捉任何性能漂移。

针对不同类型Agent的评估方法

1. 编码Agent

这类Agent编写、测试和调试代码。由于软件评估标准明确（代码能跑吗？测试通过吗？），确定性评分器是自然的选择。

• 基准：SWE-bench Verified（通过运行测试套件来验证GitHub issue修复）和Terminal-Bench（测试端到端技术任务，如编译Linux内核）是典型例子。
• 方法：除了单元测试外，还可以用基于启发式规则的代码质量检查，或使用LLM评分器来评估工具调用、用户交互等行为。

示例：一个修复认证漏洞的编码任务评估配置（YAML格式）

task:
  id: "fix-auth-bypass_1"
  desc: "修复当密码字段为空时的认证绕过问题..."
  graders:
    - type: deterministic_tests  # 确定性测试
      required: [test_empty_pw_rejected.py, test_null_pw_rejected.py]
    - type: llm_rubric            # LLM评分
      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评分规则评估代码质量为主。

2. 对话Agent

这类Agent（如客服、销售）的挑战在于，交互质量本身就是评估的一部分。评估通常依赖可验证的最终状态和评估交互质量的规则。一个独特之处是，它们常需要另一个LLM来模拟用户。

• 基准：τ2-Bench模拟了零售、航空等领域的多轮交互，由一个模型扮演用户，另一个扮演Agent。
• 方法：成功是多维度的。例如，一个客服任务可能要求：工单状态为“已解决”（状态检查），交互在10轮以内（记录约束），且语气恰当（LLM评分规则）。

3. 研究Agent

这类Agent负责收集、综合和分析信息。评估的挑战在于“全面”、“来源可靠”甚至“正确”都是上下文相关的，且基准信息（ground truth）会不断变化。

• 基准：BrowseComp测试Agent在开放网络上“大海捞针”的能力。
• 方法：组合多种评分器。Groundedness检查验证声明是否有来源支持，Coverage检查定义好答案必须包含的关键事实，Source quality检查确认信源的权威性。对于主观性强的综合报告，LLM评分规则需要频繁与人类专家进行校准。

4. 计算机使用Agent

这类Agent通过GUI（截图、鼠标点击、键盘输入）与软件交互，而非API。评估需要在真实或沙盒化的环境中运行Agent。

• 基准：WebArena通过URL和页面状态检查浏览器任务，OSWorld则通过检查文件系统、应用配置、数据库等来评估操作系统级别的任务。
• 方法：需要在token效率和延迟之间取得平衡。例如，Anthropic在Claude for Chrome产品中开发了评估，以确保Agent能根据上下文选择合适的工具（DOM提取文本 vs. 截图）。

如何看待评估中的不确定性？

Agent的行为在每次运行时都可能不同，这使得评估结果的解读变得复杂。

两个指标有助于捕捉这种细微差别：

• pass@k：衡量Agent在k次尝试中至少有一次成功的概率。尝试次数k越多，这个分数越高。这适用于“只要有一个方案能成功就行”的场景。
• pass^k：衡量k次尝试全部成功的概率。k越大，分数越低，因为它要求极高的一致性。这对于用户期望每次都可靠的面向客户的Agent至关重要。

在k=1时，两者相等。但随着k增加，两者会迅速分化。选择哪个指标取决于产品需求：pass@k关注“找到解”，pass^k关注“稳定性”。

从0到1：构建优秀Agent评估的路线图

第一阶段：收集初始评估数据集

• 步骤0：尽早开始。 不要等到需要数百个任务才动手。从20-50个源自真实失败案例的简单任务开始就足够了。
• 步骤1：从手动测试开始。 将开发中手动检查的行为、用户常试的任务、以及从bug报告和客服工单中发现的问题，转化为测试用例。
• 步骤2：编写无歧义的任务和参考解决方案。 一个好的任务标准是：两个领域专家会独立得出相同的通过/失败结论。为每个任务创建一个“标准答案”，以验证任务本身是可解的，且评分器配置正确。
• 步骤3：构建平衡的问题集。 既要测试行为应该发生的情况，也要测试不应该发生的情况。例如，在为Claude.ai构建网页搜索评估时，团队同时测试了“应该搜索”的查询（如天气）和“不应该搜索”的查询（如“谁创立了苹果公司？”），以平衡欠触发和过触发问题。

第二阶段：设计评估框架和评分器

• 步骤4：构建稳健的评估框架和稳定的环境。 确保每次尝试都在一个干净、独立的环境中开始，避免因文件残留、缓存、资源耗尽等基础设施问题导致评估结果不准确。
• 步骤5：深思熟虑地设计评分器。
- • 评分内容：通常，评判Agent产出的结果，而不是它采取的具体路径。过于僵化的步骤检查会扼杀模型的创造力。
- • 部分得分：对于多组件任务，设计部分得分机制。
- • 校准LLM评分器：与人类专家密切校准，确保评分一致性。可以提供“未知”选项，避免LLM幻觉。
- • 避免评分陷阱：仔细检查任务和评分器，防止因评分bug或任务描述模糊而惩罚正确的解决方案。例如，Opus 4.5在CORE-Bench上的得分从42%跃升至95%，就是因为修复了评分器对数字精度要求过严、任务描述模糊等问题。

第三阶段：长期维护和使用评估

• 步骤6：检查记录（Transcripts）。 这是验证评估是否有效的关键。通过阅读失败任务的记录，才能判断是Agent真的犯了错，还是评分器拒绝了一个有效的解决方案。
• 步骤7：监控能力评估的饱和度。 当一个评估的通过率达到100%时，它就失去了衡量“进步”的信号。当模型在某个基准上接近饱和（如SWE-Bench Verified上从30%到超过80%），就需要开发更难的、新的评估框架来捕捉更复杂的任务上的进步。
• 步骤8：通过开放贡献和维护保持评估套件的健康。 Anthropic的经验是，设立专门的评估团队负责核心基础设施，而领域专家和产品团队贡献具体的评估任务。推荐评估驱动开发（eval-driven development）：先构建评估来定义期望的能力，然后迭代Agent直到其表现良好。

评估如何与其他方法协同？

自动化评估只是理解Agent性能的多种方法之一。一个完整的图景还应包括：

方法	优点	缺点
自动化评估	迭代快、可复现、无用户影响、可大规模测试场景	前期投入大、需持续维护、可能与真实使用模式不符
生产监控	反映真实用户行为、捕捉合成评估遗漏的问题	被动，问题已影响用户、信号可能有噪声
A/B测试	衡量真实用户结果、可控、系统化	慢，需要足够流量、只能测试已部署的变更
用户反馈	发现意料之外的问题、来自真实用户	稀疏、有偏见、通常只报告严重问题、非自动化
人工记录审查	建立对失败模式的直觉、捕捉细微质量问题	耗时、不具规模、信号偏定性
系统化人类研究	黄金标准质量判断、处理主观任务、校准模型评分器	昂贵、慢、难以频繁运行