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_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

对话 Agent

• 焦点：交互质量 + 结果，使用模拟用户（LLM 角色）。
• 基准：τ-Bench、τ2-Bench（多轮支持场景）。
• 评分：多维度（完成度、回合限、语气）。
• 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

研究 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），我可以帮你扩展应用这些方法～