AI Agent评测全指南：Anthropic官方实战经验

原文链接：https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents

引言

Anthropic 近期发布了一篇关于 AI Agent 评测的长文，系统性地总结了其在内部研发与客户落地过程中积累的实战经验。

文章开篇即点明核心：高质量的评测是团队发布 Agent 的信心基石。若缺乏有效的评测机制，团队极易陷入“线上救火”的恶性循环——问题只能通过生产环境暴露，修复旧 Bug 的同时可能引入新故障。评测的核心价值，在于将潜在问题拦截在用户感知之前，这一价值贯穿于 Agent 的整个生命周期。

正如 Anthropic 在《构建高效 Agent》中所阐述，Agent 的运行本质是多轮交互：调用工具、更新状态、并根据中间结果动态调整策略。然而，“成也萧何，败也萧何”，正是这些赋予 Agent 自主性、智能性与灵活性的特性，也让其评测工作变得前所未有的复杂。

评测的结构

文章首先界定了评测的本质：即构建一套自动化测试流程，给定特定输入，通过预设的评分逻辑来量化 AI 系统的输出质量。关键在于“开发期”和“自动化”——这意味着在不依赖真实用户介入的情况下，实现快速迭代。

早期的 LLM 评测多为单轮模式：一个提示词，一个回复，一套评分标准，简单直接。但随着 AI 能力的进化，针对多轮交互的 Agent 评测已成为主流。

简单评测：仅检查 Agent 对单一提示词的输出是否符合标准。
复杂 Agent 评测：这是一个动态过程。以编程 Agent 为例，它接收任务（如构建 MCP 服务器）、工具和环境，随即进入“思考-调用工具-调整”的循环，并直接修改环境状态。此时的评分重点不再是它“说了什么”，而是通过单元测试等方式验证它“实际构建的产物”能否正常运行。

为什么 Agent 评测更具挑战性？根源在于其动态性。Agent 在多轮交互中持续修改环境，这意味着错误会像滚雪球一样传播和累积。

此外，前沿模型有时会展现出“超越规则”的创造力。文章提及一个有趣案例：Opus 4.5 在处理航班预订任务时，发现并利用了一个政策漏洞。虽然按照刻板的评测标准，它未能“通过”，但实际上为用户提供了更优的解决方案。这也揭示了静态评测在面对高智能模型时的局限性。

核心术语表

为了规范讨论，文章定义了一套 Agent 评测的标准词汇：

任务 (Task)：包含明确输入和成功标准的单个测试项。
试验 (Trial)：对任务的一次完整尝试。鉴于模型输出的随机性，通常需要多次试验以消除方差。
评分器 (Grader)：用于评估表现的逻辑单元。一个任务可包含多个评分器（含多个断言或检查点）。
记录 (Transcript)：试验的全程实录，包含对话、工具调用、推理过程及中间结果。
结果 (Outcome)：试验结束时的最终环境状态。需注意区分：Agent 可能在“记录”中声称“已帮您预订”，但“结果”要看数据库里是否真实存在该条预订数据。
评测框架 (Evaluation Harness)：运行评测的基础设施。负责发送指令、提供工具、记录日志并汇总得分。
Agent 框架 (Agent Harness)：让模型以 Agent 形态运行的系统（处理输入、编排工具）。评测“一个 Agent”，实际上评测的是 “模型 + 运行框架”的综合能力。
评测套件 (Evaluation Suite)：针对特定能力（如代码能力、规划能力）设计的一组任务集合。

为什么要构建评测？

文章指出，在 Agent 开发的原型期（MVP阶段），依靠手动测试、内部试用和开发者的直觉，确实能快速验证流程。然而，这种“手工作坊”模式在 Agent 进入生产环境并规模化后，会迅速失效。

转折点通常出现在用户反馈“体验变差”时。如果没有评测体系，团队就如同在“盲目飞行”：

调试被动化：只能依赖用户投诉来手动复现 Bug，修复一个问题时，无法预知是否引入了新问题。
归因困难：无法区分问题是源于模型本身的性能波动（噪声），还是真正的逻辑回归。
发布恐惧：无法在上线前自动覆盖数百个边缘场景，导致每次发布都如履薄冰。

以 Anthropic 自家的 Claude Code 为例，其评测体系是分阶段演进的：

初期：基于员工和外部反馈进行快速迭代。
中期：引入评测，最初仅关注代码简洁性和文件编辑等特定领域。
后期：扩展至“过度工程化”检测等复杂行为评测。

这些评测不仅指导了产品改进，还成为了连接研究与产品的桥梁。结合生产监控与 A/B 测试，评测为 Claude Code 的持续扩展提供了关键的导航信号。

结论：评测贯穿 Agent 生命周期的始终。早期，它迫使团队量化成功的定义；后期，它则是维持质量一致性的基石。

行业案例：殊途同归的评测之路

文章分享了两个不同阶段团队的实践，印证了评测的普适性：

Descript（视频编辑 Agent）
- 策略：确立了成功编辑的三个核心维度——不破坏原意、遵循指令、高质量执行。
- 演进：从全人工评分，进化为“产品团队定义标准 + 定期人工校准”的 LLM 自动评分体系。目前并行运行两套评测套件：一套用于质量基准，一套用于回归测试。
Bolt.ai（全栈开发 Agent）
- 策略：在产品已有一定规模后才开始构建评测体系，但在 3 个月内迅速完成了搭建。
- 手段：综合运用静态代码分析（检查输出代码）、浏览器 Agent（进行端到端应用测试）、LLM 裁判（评估指令遵循能力）。

评测即速度

评测不仅关乎质量，更关乎竞争速度。当更强的新模型发布时：

无评测团队：需要数周的人工测试来摸索新模型的特性。
有评测团队：几天内就能通过自动化跑分量化新模型的优势，并针对性地调整 Prompt 以快速上线。

如何评测AI Agent

尽管 Agent 类型各异（如编程、研究、计算机操作、对话），但其评测架构在底层是通用的。Anthropic 建议采用组合拳策略。

一个成熟的评测体系通常是以下三种评分器的混合：

基于代码的评分器
- 方法：字符串匹配（正则/模糊）、二值测试（Pass/Fail）、静态分析（Lint/类型检查）、工具调用验证。
- 特点：快速、成本低、客观。这是评测体系的基石，适合验证格式、语法和硬性逻辑，但对语义理解缺乏弹性。

基于模型的评分器
- 方法：基于量表打分、自然语言断言、成对比较、多模型共识。
- 特点：灵活、语义化。能处理开放性任务，但存在非确定性，且成本较高，必须通过人工校准以确保其可信度。

人工评分器
- 方法：专家审查、A/B 测试、抽样质检。
- 特点：黄金标准。虽然昂贵且耗时，但它是校准“基于模型评分器”的基准事实。

针对每个具体任务，可以将上述评分器进行组合：

加权模式：综合得分需超过预设阈值。
一票否决模式：所有检查项必须全部通过。

能力评测 vs 回归评测

构建评测套件时，需明确区分两种测试目的：

能力评测 —— “进攻”
- 核心问题：“这个 Agent 能做到多好？”
- 特征：针对 Agent 尚不擅长的困难任务设计。初始通过率可能很低，它是团队需要攀登的“北极星指标”，用于指引研发方向。
回归评测 —— “防守”
- 核心问题：“这个 Agent 是否还在正常工作？”
- 特征：针对 Agent 已知能够解决的任务设计。通过率应接近 100%。它是质量安全网，任何分数的下降都意味着系统可能出现了退化。

最佳实践：当一个“能力评测”的任务被攻克并稳定后，它就应该“毕业”，转入“回归评测”套件中，确保持续监控。

四类Agent的评测方法

Coding Agents

核心逻辑：像人类开发者一样写代码、运行命令、修复 Bug。
评测手段：这是最适合进行确定性评分的场景。
- 执行验证：代码能否成功运行？单元测试是否通过？
- 基准参考：业界常用的 SWE-bench Verified 和 Terminal-Bench 都基于此逻辑——只看结果（测试通过率），不关心过程。
架构建议：通常需要一个沙箱环境来安全地执行代码，并配合 LLM 评分器来辅助评测代码风格。

示例：编程Agent的评测配置
文章给出了一个编程任务的示例，Agent必须修复一个身份验证绕过漏洞：
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 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评分标准评测整体代码质量，仅在需要时添加额外的评分器和指标。

Conversational Agents

核心逻辑：在销售、客服等场景中维护对话状态、调用工具并解决问题。
挑战：交互质量本身就是产品的一部分。与传统 Chatbot 不同，需要验证它是否在多轮对话后达成了目标。
评测手段：
- 用户模拟器：通常需要引入第二个 LLM 来扮演用户，发起挑战。
- 多维评分：参考 τ-bench，评分维度包括：
  - 状态检查：工单真的解决了吗？（查询数据库状态）
  - 约束检查：是否在 10 轮内完成？
  - 语气审查：是否礼貌且专业？（LLM 打分）

示例：对话Agent的评测配置
文章给出了一个示例 —— Agent必须处理一个情绪沮丧的客户的退款：
graders: - type: llm_rubric rubric: prompts/support_quality.md assertions: - "Agent对客户的沮丧表示同理心" - "解决方案被清楚解释" - "Agent的响应基于fetch_policy工具结果" - 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

Research Agents

核心逻辑：搜集信息、综合分析、生成报告。
挑战：缺乏二进制的“对/错”标准。什么叫“全面”？什么叫“准确”？而且事实依据是动态变化的（网上的信息在变）。
评测手段：组合式评分器策略。
- 引用检查：每一句断言是否有来源支撑？
- 覆盖率检查：是否包含了预定义的关键事实？
- 信源权威性：引用的来源是否可信？

Computer Use Agents

核心逻辑：端到端（E2E）的 GUI 交互——看截图、点鼠标、敲键盘。
评测手段：必须在真实或虚拟化 OS 中运行。
- WebArena 模式：基于浏览器的页面状态和 URL 验证。
- OSWorld 模式：基于操作系统的副作用验证——检查文件是否生成、配置是否修改、数据库是否更新。

如何量化“非确定性”：pass@k 与 pass^k

Agent 的输出天生带有随机性。为了科学地衡量这种波动，Anthropic 推荐使用两个关键指标：
* pass@k (命中率)：
* 定义：给 k 次机会，至少有一次成功的概率。
* 场景：适用于辅助人类的工具（如代码补全）。只要它能给出一个好建议，用户就满意了。k 越大，分数越高。
* pass^k (一致性/鲁棒性)：
* 定义：连续 k 次试验，全部成功的概率。
* 场景：适用于无人值守的自动化任务（如自动退款）。如果成功率是 75%，跑 3 次全对的概率只有 42%。这对企业级应用是不可接受的。k 越大，分数越低。

结论：做 Copilot 类产品看 pass@k，做全自动 Agent 必须死磕 pass^k。

从零到一：构建优秀评测的路线图

不要被“大数据”吓倒，Anthropic 强调：早做比做大更重要。

第一阶段：冷启动 (Steps 0-3)

拒绝拖延：不需要几百个测试用例。从 20-50 个真实失败案例开始，因为早期改动的波及效应很大，小样本足以发现问题。
取材实战：从 Bug 追踪器和客服工单里提取素材。
黄金标准：一个好的任务必须是无歧义的（两个专家能得出相同结论）。必须包含参考答案，用来验证评分器本身是否通过。
正负样本均衡：既要测“它该做什么”，也要测“它不该做什么”（例如：不该搜索时是否乱搜索）。

第二阶段：架构与评分 (Steps 4-5)

环境隔离：每次试验必须从干净环境开始，避免状态污染导致测试不稳定。
重结果，轻过程：这是许多团队的误区。不要评测 Agent 的具体步骤，除非必须要按顺序调用。因为模型往往能找到你意想不到的“捷径”。如果你惩罚了捷径，就扼杀了创造力。
部分给分机制：对于复杂任务，建立“部分学分”。识别出问题但没能退款，优于直接崩溃。
优先确定性评分：设计评分器时，应首选快速、客观的代码评分（如单元测试、正则匹配）。仅在无法用规则衡量时，才使用 LLM 评分器。

第三阶段：维护与运营 (Steps 6-8)

解读分数与日志：不要盲信分数，必须定期阅读评测日志，确认是 Agent 出错，还是评分器误判。警惕“评测饱和”：当分数接近 100% 时，这套评测集就失去了指导意义（仅能做回归测试，无法指导改进）。
评测驱动开发：在开发新功能之前，先定义并写好对应的评测。让评测成为 Agent 能力的定义者。
长期维护：评测套件是活的产品。最有效的模式是：核心团队维护基础设施，产品/领域专家贡献测试用例。

评测如何与其他方法配合以全面理解Agent

没有任何单一的评测层能拦截所有问题。需要构建类似安全工程中的“瑞士奶酪模型”，实现多层防御：

核心理念：自动化评测负责高频、低成本地拦截大部分问题，而将昂贵的人工和风险较高的生产环境测试留给最后 10% 的长尾问题。

思考

这篇文章堪称 Agent 评测领域的“实战圣经”。几点洞察尤为深刻：

指标的二象性：pass@k 和 pass^k 的区分极其精准。很多团队觉得 Agent 演示效果不错（pass@1 尚可），但上线就崩，往往是因为忽视了 pass^k 所代表的工程稳定性。
结果导向 > 路径导向：“评分产出物而非路径” 这一原则直击要害。过度约束 Trace 实际上是在把 Agent 降级为传统的工作流自动化，扼杀了 LLM 处理模糊问题的核心优势。
EDD (评测驱动开发)：在 Agent 领域，TDD（测试驱动开发）升级为 EDD。因为 Agent 的“需求”往往是模糊的，只有先写出评测（比如：这就叫好的回答），开发才有方向。这不仅是测试手段，更是产品定义的工具。

关注“鲸栖”小程序，掌握最新AI资讯

本文来自网络搜集，不代表鲸林向海立场，如有侵权，联系删除。转载请注明出处：http://www.itsolotime.com/archives/17865