揭秘 AI Agent 评估¶

原文发布于 2026 年 1 月 9 日，作者 Mikaela Grace, Jeremy Hadfield, Rodrigo Olivares, Jiri De Jonghe

引言¶

好的评估（Eval）让团队能够更有信心地交付 AI Agent。 没有评估体系的团队会陷入"被动循环——只能在生产环境中发现问题，修一个 bug 又引入另一个"。评估让问题在影响用户之前就变得可见，其价值随着 Agent 的生命周期不断累积。

正如 Anthropic 此前在构建高效 Agent 一文中所述，Agent 跨越多个回合运作——调用工具、修改状态、根据中间结果调整行为。这些让 Agent 变得有用的能力，同时也让评估变得更加困难。

评估的结构¶

评估（Eval）本质上就是 AI 系统的测试：给定输入，对输出施加评分逻辑来衡量成功。 本文聚焦于开发阶段无需真实用户参与的自动化评估。

单轮评估包含提示词、响应和评分逻辑。随着 AI 能力的进步，多轮评估变得日益普遍。

在简单评估中，Agent 处理一个 prompt，评分器检查输出是否符合预期。对于更复杂的多轮评估，编码 Agent 接收工具、任务和环境，执行 Agent 循环，然后通过单元测试验证结果。

Agent 评估更为复杂。Agent 跨多个回合使用工具，修改状态并自适应——错误会传播和累积。前沿模型能找到超出静态评估预期的创造性解决方案。例如，Opus 4.5 在 t2-bench 航班预订问题中发现了一个政策漏洞——它"未通过"评估但实际上找到了更好的方案。

核心术语¶

Agent 评估的各组成部分。

为什么要构建评估？¶

从原型到生产的临界点在于：不可能再靠手动测试和直觉来保证质量。 团队在早期可以"通过手动测试、内部试用和直觉走得出乎意料地远"。但一旦 Agent 进入生产环境并开始扩展，没有评估就寸步难行。

临界点出现在用户反馈"改了之后感觉变差了"，而团队却无法验证。没有评估，调试就是被动的：等投诉、手动复现、修复、祈祷不引入新问题。

实际案例：

评估还决定了模型升级的速度——有评估的团队几天内就能完成升级，没有评估的团队则需要数周手动测试。

一旦评估就位，你免费获得了基线和回归测试：延迟、token 用量、每任务成本、错误率——全部在固定任务集上追踪。

如何评估 AI Agent¶

不同类型的 Agent 可以使用相似的评估技术。 目前大规模部署的主要 Agent 类型包括：编码 Agent、研究 Agent、计算机操作 Agent 和对话 Agent。

评分器类型¶

Agent 评估通常组合使用三类评分器：基于代码的、基于模型的和人工的。

评分方式可以是加权的（组合分数需达阈值）、二元的（全部通过）或混合的。

能力评估 vs 回归评估¶

优化后通过率提高的能力评估可以"毕业"为回归测试套件。

评估编码 Agent¶

编码 Agent 天然适合确定性评分——代码能否运行、测试能否通过。 编码 Agent 编写、测试和调试代码，有效的评估依赖于明确的任务规范、稳定的测试环境和完善的测试用例。

两个广泛使用的基准：

除了通过/失败的结果测试外，评估 Transcript 也很有价值——代码质量规则和模型评分器可以评估工具使用和交互模式。

编码 Agent 评估示例配置：

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 评分规则评估代码质量为主，按需添加其他评分器。

评估对话 Agent¶

对话 Agent 的评估是多维度的——交互本身的质量也是评估对象。 对话 Agent 在客服、销售、教练等领域与用户交互，维护状态、使用工具并在对话中采取行动。通常需要第二个 LLM 来模拟用户。

成功是多维度的：工单是否解决了（状态检查）、是否在 10 轮内完成（Transcript 约束）、语气是否恰当（LLM 评分规则）？

基准测试：t-Bench 和 t2-Bench 模拟零售客服和航空公司预订等领域的多轮交互。

对话 Agent 评估示例配置：

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 评估通常使用基于模型的评分器同时评估沟通质量和目标完成度。

评估研究 Agent¶

研究 Agent 的评估核心挑战是"全面"和"正确"都是相对概念。 研究 Agent 收集、综合和分析信息。与编码 Agent 的二元通过/失败信号不同，研究质量需要结合任务上下文来判断。

独特挑战：
- 专家对"全面性"可能存在分歧
- 事实真相不断变化
- 更长的输出意味着更多犯错空间

BrowseComp 测试 Agent 能否在开放互联网上找到难以发现的信息。

评估策略组合多种评分器：
- 扎实性检查（claims 是否有来源支持）
- 覆盖度检查（关键事实是否包含）
- 来源质量检查（来源是否权威）
- 精确匹配（客观正确的答案）
- LLM 标记无支撑的声明并验证综合能力

基于 LLM 的评分规则应频繁与人工专家判断进行校准。

评估计算机操作 Agent¶

计算机操作 Agent 通过截图、鼠标和键盘与软件交互，评估需要在真实或沙盒环境中运行并检查最终状态。

浏览器使用 Agent 需要在 token 效率和延迟之间取得平衡。基于 DOM 的交互执行快但消耗大量 token；基于截图的方式较慢但更省 token。对于 Claude for Chrome，Anthropic 开发了专门的评估来检查 Agent 是否为每个上下文选择了正确的工具。

如何看待非确定性¶

Agent 行为在不同运行之间存在差异，需要用 pass@k 和 pass^k 两个指标来捕捉。 每个任务都有自己的成功率，某次通过的任务下次可能失败。

例如：50% 的 pass@1 意味着首次尝试能解决一半任务。75% 的单次成功率在 3 次试验下：pass^3 = (0.75)^3 约为 42%。

pass@k 和 pass^k 随试验次数增加而分化。在 k=1 时两者相同。到 k=10 时，pass@k 接近 100% 而 pass^k 降至接近 0%。

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

收集初始评估数据集的任务¶

第 0 步：尽早开始

20-50 个基于真实失败的简单任务就是一个很好的起点。 Agent 开发早期，每次改动的效应量大，小样本即可。拖得越久，评估越难建。

第 1 步：从已有的手动测试开始

从开发中已经在做的手动检查入手——每次发版前验证的行为和常见用户任务。如果已经在生产环境，查看 bug 跟踪器和支持队列。将用户报告的失败按影响优先级转化为测试用例。

第 2 步：编写无歧义的任务并附带参考方案

好的任务是两个领域专家独立判断会得出相同通过/失败结论的任务。 任务规范中的歧义会变成指标中的噪声。评分器检查的一切都应在任务描述中清晰说明。

"对于前沿模型，多次试验全部失败（即 0% pass@100）通常说明任务本身有问题，而非 Agent 能力不足。"

为每个任务创建参考方案——一个已知能通过所有评分器的有效输出。

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

同时测试行为应该发生和不应该发生的场景。"单向评估导致单向优化。"

例如：Claude.ai 网络搜索评估覆盖了两个方向——模型应该搜索的查询（查天气）和应该从知识回答的查询（苹果公司创始人是谁）。在触发不足和触发过度之间取得平衡经历了多轮优化。

设计评估框架和评分器¶

第 4 步：构建稳健的评估框架和稳定的环境

评估中的 Agent 必须与生产环境中的表现大致一致。每次试验都应从干净环境开始。 运行之间的共享状态（残留文件、缓存数据）会导致因基础设施问题而产生的关联失败。也可能人为拉高性能——例如 Claude 通过检查前次试验的 git 历史获得不公平优势。

第 5 步：精心设计评分器

能用确定性评分器的地方用确定性的，需要灵活判断的地方用 LLM 评分器，用人工评分进行校准验证。

避免检查 Agent 是否遵循了非常具体的步骤序列——这样做"太僵硬且导致测试极其脆弱"。评判 Agent 产出了什么，而非走了什么路径。

为有多个组成部分的任务设置部分得分。

模型评分需要仔细迭代。LLM-as-judge 评分器应与人工专家校准。给 LLM 一个退出选项（如返回"Unknown"）。创建结构化评分规则，分别对每个维度评分。

评分陷阱案例：
- Opus 4.5 最初在 CORE-Bench 上仅得 42%，直到发现问题：期望"96.124991..."时判"96.12"为错、规范含糊、任务具有随机性。修复后分数跃升至 95%
- METR 发现配置错误的任务——要求超过阈值而指令说的是优化到阈值

确保评分器能抵抗绕过或 hack。

长期维护和使用评估¶

第 6 步：检查 Transcript

"不读大量试验的 Transcript 和评分，你不会知道评分器工作得好不好。" 任务失败时，Transcript 告诉你 Agent 是犯了真正的错误还是评分器拒绝了一个有效方案。"读 Transcript 是验证评估是否在衡量真正重要的事情的方式。"

第 7 步：监控能力评估饱和

评估饱和发生在 Agent 通过了所有可解任务时。SWE-Bench Verified 起始于 30%，前沿模型现已接近 >80%。当评估趋近饱和，大的能力提升只体现为微小的分数增长。

例如：Qodo 最初对 Opus 4.5 印象不深，因为单次编码评估未能捕捉到在更长、更复杂任务上的进步。他们开发了新的 Agentic 评估框架。

"我们不会直接采信评估分数，除非有人深入研究了评估细节并读了一些 Transcript。"

第 8 步：长期保持评估套件健康

评估套件是一个活的产物，需要持续关注和明确的所有权。

在 Anthropic，专门的评估团队拥有核心基础设施，而领域专家和产品团队贡献任务并自行运行评估。

"拥有和迭代评估应该像维护单元测试一样成为日常。"

实践评估驱动开发：在 Agent 能够完成之前就构建评估来定义计划中的能力，然后迭代直到 Agent 表现良好。起始通过率较低的能力评估让对未来模型能力的押注变得可见。

"产品经理、客户成功经理或销售人员都可以使用 Claude Code 以 PR 的形式贡献一个评估任务。"

创建有效评估的流程。

评估如何与其他方法配合¶

自动化评估只是理解 Agent 性能的方式之一，完整画面需要多种方法的组合。 包括生产监控、用户反馈、A/B 测试、手动 Transcript 审查和系统性人工评估。

方法总览¶

这些方法对应不同的开发阶段：
- 自动化评估：发布前和 CI/CD，第一道防线
- 生产监控：发布后追踪分布漂移
- A/B 测试：有足够流量时验证重大变更
- 用户反馈和 Transcript 审查：持续进行的日常实践
- 系统性人工研究：为主观输出校准 LLM 评分器

如同安全工程中的瑞士奶酪模型，没有任何单一评估层能捕获所有问题。多种方法组合后，从一层漏过的失败会被另一层捕获。

结论¶

没有评估的团队深陷被动循环；尽早投入评估的团队发现开发在加速。 失败变成测试用例，测试用例防止回归，指标替代猜测。

核心原则：
- 尽早开始，不要等待完美的套件
- 从观察到的失败中获取真实任务
- 定义无歧义、稳健的成功标准
- 精心设计评分器并组合多种类型
- 确保问题对模型来说足够难
- 迭代评估以提高信噪比
- 读 Transcript

随着 Agent 承担更长的任务、在多 Agent 系统中协作、处理越来越主观的工作，评估技术也需要不断演进。

附录：评估框架¶

很多团队会组合使用多个工具、自建框架或使用简单的评估脚本。框架的好坏取决于通过它运行的评估任务——快速选一个适合你工作流的，然后将精力投入到高质量的测试用例和评分器上。