Anthropic 万字长文：AI Agent 评估体系全解析
Anthropic 于 2026 年 1 月 9 日发布的工程博客文章《Demystifying Evals for AI Agents》（揭秘 AI Agent 评估体系）是一篇详尽的技术指南，约 8000-10000 字（英文原版），聚焦于构建可靠的 AI Agent 评估系统（evals）。这篇文章基于 Anthropic 的内部实践和客户经验，系统拆解了 AI Agent 的评估挑战、框架设计和最佳实践。AI Agent 的自主性、智能性和灵活性使其评估难度远高于传统 LLM，但良好的 evals 能帮助团队从“反应式调试”转向“前瞻式开发”，避免生产环境中的连锁故障。
下面，我对文章进行全面解析，按原文章结构逻辑展开，包括关键章节、主旨要点、示例、框架/方法论，以及代码/图表引用。解析基于文章核心内容，力求完整性与实用性。如果你是 AI 开发者或研究者，这篇文章的核心价值在于提供可操作的“评估路线图”，帮助从零构建生产级 evals。
引言：为什么 AI Agent 评估如此重要？
文章开篇强调：AI Agent 的核心优势（自治、多轮交互、工具调用、状态修改）正是评估难题的根源。传统 LLM 评估只需检查单轮输出，但 Agent 可能在多步中累积错误，或找到“创意”解决方案（如绕过政策限制）。缺乏 evals，团队易陷入“生产中发现问题→修复→新问题循环”。
主旨要点：
- Evals 是“测试 AI 系统”的核心工具：输入任务，运行 Agent，应用评分逻辑。
- 好处：自信发布、监控行为、量化改进、基准测试新模型。
- 示例：Anthropic 的 Claude Code Agent 通过 evals 优化了代码简洁性和过度工程问题。
- 文章目标：分享 Anthropic 的经验，帮助开发者构建“严谨 evals”，适用于编码、对话、研究、计算机使用等 Agent 类型。
文章引用了前文《Building Effective Agents》（构建有效 AI Agent），强调 evals 是 Agent 生命周期的核心。
评估的结构：从基础概念到组件拆解
这一节定义了 evals 的核心元素，区分单轮、多轮和 Agent 评估。文章用图表展示 evals 流程：任务 → 试次 → 转录本 → 结果 → 评分器 → 指标。
关键定义与框架：
- 任务（Task）：测试用例，包括输入和成功标准（如“修复认证绕过漏洞”）。
- 试次（Trial）：一次运行，可能多次重复以测一致性。
- 评分器（Grader）：评分逻辑，包括断言（assertions）和检查。
- 转录本（Transcript）：完整记录（如 API 消息数组）。
- 结果（Outcome）：最终环境状态（如数据库变更）。
- 评估框架（Evaluation Harness）：运行 evals 的基础设施。
- Agent 框架（Agent Harness）：启用 Agent 行为的系统（如 Anthropic 的 Agent SDK）。
- 评估套件（Evaluation Suite）：针对特定能力的任务集合（如客户支持套件）。
示例：
- 单轮：提示 → 输出 → 评分。
- 多轮：工具调用循环 → 最终输出。
- Agent 示例：Claude Opus 4.5 在航班预订任务中“失败”——它发现政策漏洞并优化用户体验，但未严格遵守静态规则，展示了 evals 需要捕捉“创意失败”。
图表引用：文章包含一个概念图，展示组件间关系（任务输入 → Agent 运行 → 转录本/结果 → 评分器 → 聚合指标）。
为什么需要构建评估？从原型到生产的转变
早期开发靠手动测试和直觉，但生产级 Agent 需要 evals 来避免隐患。
主旨要点：
- 问题：无 evals 时，回归测试缺失、改进无法量化。
- 好处：基准线、回归保护、指标追踪（如延迟、令牌使用）。
- 方法论：Evals 编码成功标准，解决任务歧义，加速迭代。
示例：
- Claude Code：从用户反馈转向 evals，优化代码质量。
- Descript（视频编辑 Agent）：Evals 标准——“别搞砸、按要求做、做好它”，用 LLM 评分器校准人类判断。
- Bolt AI：结合静态分析、浏览器测试、LLM 判断指令遵循。
框架建议：从定义需求开始，evals 像“产品规格”，越早构建越好。
如何评估 AI Agent？核心方法论与实践
这一节是最长的部分，分类讨论评分器类型、能力 vs. 回归 evals，以及针对不同 Agent 类型的策略。强调混合使用代码/模型/人类评分器。
评分器类型（Graders）
表格总结（文章原表）：
| 类型 | 方法示例 | 优势 | 劣势 |
|---|---|---|---|
| 代码基 | 字符串匹配、二进制测试、静态分析、结果验证、转录本分析 | 快速、廉价、客观、可重复 | 易碎、对变体敏感、缺乏细微差别 |
| 模型基 | 评分标准、断言、配对比较、参考对比、多评委共识 | 灵活、可扩展、处理开放任务 | 非确定性、昂贵、需校准 |
| 人类基 | 专家审查、众包、抽样检查、A/B 测试、标注一致性 | 金标准、匹配专家判断、校准模型 | 昂贵、慢、需专家 |
方法论：结合使用（如代码验证结果 + LLM 评估质量）。评分方式：加权阈值、二进制全通过，或混合。
能力评估 vs. 回归评估
- 能力 evals：针对弱点，低通过率，推动改进。
- 回归 evals：确保可靠性，高通过率。
- 演进：优化后，能力 evals 转为回归套件。
针对特定 Agent 类型的评估
编码 Agent
- 焦点：任务、稳定环境、测试套件。
- 基准：SWE-bench Verified（GitHub 问题 + 测试）、Terminal-Bench（端到端任务）。
- 评分：单元测试 + LLM 标准（如代码质量）。
- YAML 示例（文章代码）：
task:id:"fix-auth-bypass_1"desc:"Fix authentication bypass when password field is empty and ..."graders:-type:deterministic_testsrequired:[test_empty_pw_rejected.py,test_null_pw_rejected.py]-type:llm_rubricrubric:prompts/code_quality.md-type:static_analysiscommands:[ruff,mypy,bandit]-type:state_checkexpect:security_logs:{event_type:"auth_blocked"}-type:tool_callsrequired:-{tool:read_file,params:{path:"src/auth/*"}}-{tool:edit_file}-{tool:run_tests}tracked_metrics:-type:transcriptmetrics:-n_turns-n_toolcalls-n_total_tokens-type:latencymetrics:-time_to_first_token-output_tokens_per_sec-time_to_last_token
对话 Agent
- 焦点：交互质量 + 结果，使用模拟用户（LLM 角色）。
- 基准：τ-Bench、τ2-Bench（多轮支持场景）。
- 评分：多维度（完成度、回合限、语气）。
- YAML 示例：
graders:-type:llm_rubricrubric:prompts/support_quality.mdassertions:-"Agent showed empathy for customer's frustration"-"Resolution was clearly explained"-"Agent's response grounded in fetch_policy tool results"-type:state_checkexpect:tickets:{status:resolved}refunds:{status:processed}-type:tool_callsrequired:-{tool:verify_identity}-{tool:process_refund,params:{amount:"<=100"}}-{tool:send_confirmation}-type:transcriptmax_turns:10tracked_metrics:-type:transcriptmetrics:-n_turns-n_toolcalls-n_total_tokens-type:latencymetrics:-time_to_first_token-output_tokens_per_sec-time_to_last_token
研究 Agent
- 焦点：主观质量（全面性、基于事实），混合评分：基于事实检查、覆盖度、来源质量。
- 基准：BrowseComp（网页搜索任务）。
计算机使用 Agent
- 焦点：GUI 交互环境，结果验证。
- 基准：WebArena（浏览器任务）、OSWorld（OS 控制）。
- 平衡效率（如 DOM vs. 截图）。
如何处理非确定性？
Agent 输出变异性高，使用 pass@k（k 次中至少一次成功）和 pass^k（k 次全成功）。文章图表显示：k=1 时相同，k=10 时 pass@k 近 100%，pass^k 近 0%。
通往优秀 evals 的路线图
收集任务
- 从 20-50 个开始，基于手动测试/失败案例。
- 写明确任务 + 参考方案，平衡正/负例。
设计框架与评分器
- 稳定隔离环境。
- 优先确定性评分；部分分数；避免易碎。
- 检查作弊。
长期维护
- 审查转录本公平性。
- 监控饱和，刷新套件。
- 开放贡献，evals 驱动开发。
流程图：文章图示创建循环（任务收集 → 框架设计 → 运行/分析 → 迭代）。
整体视角：evals 与其他方法的结合
Evals 是基础，但需与监控、A/B 测试、反馈、手动审查、人类研究结合，形成“瑞士奶酪模型”（多层防御）。
比较表（文章原表）：
| 方法 | 优势 | 劣势 |
|---|---|---|
| 自动化 evals | 快速、可重复、可扩展 | 前期成本、维护 |
| 生产监控 | 真实行为、真实数据 | 反应式、噪声大 |
| A/B 测试 | 实际结果、控制组 | 慢、需流量 |
| 用户反馈 | 意外问题、示例 | 稀疏、无解释 |
| 手动审查 | 直觉、细微问题 | 耗时、不一致 |
| 人类研究 | 金标准、主观处理 | 昂贵、复杂 |
结论：evals 的复合价值
Evals 打破反应循环，加速开发。核心：早开始、清晰标准、迭代。领域正演进，多 Agent 系统需新 evals。
附录：推荐评估框架
- Harbor：容器化试次、基准。
- Promptfoo：YAML 提示/断言。
- Braintrust：离线/在线、评分器。
- LangSmith/Langfuse：追踪、数据集。
选择依据需求，焦点在任务/评分器。
鸣谢：列出贡献者和合作伙伴。
这篇文章是 AI Agent 领域的实用宝典，强调“evals 驱动开发”。如果你在构建 Agent，建议从收集 20 个任务起步，结合 YAML 配置实现。如果你有具体场景（如编码或对话 Agent），我可以帮你扩展应用这些方法～
