揭秘AI智能体的评估方法论
原标题： Demystifying Evals for AI Agents
作者： Mikaela Grace, Jeremy Hadfield, Rodrigo Olivares, Jiri De Jonghe | 发布日期： 2026年1月9日
原文链接： https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents
一句话摘要
Anthropic发布了一份全面的AI智能体评估指南，涵盖核心术语体系、三类评分器设计、四类智能体的评估策略、非确定性处理以及从0到1的实施路线图，将评估从"事后调试"提升为"主动质量保障"。
完整核心内容翻译
为什么智能体评估与传统评估不同
本文开宗明义地指出：AI智能体的评估与早期单轮语言模型评估有本质区别。智能体涉及多轮交互、工具调用、环境状态变化等复杂动态，传统的输入-输出匹配方法已不再适用。有效的评估体系能让团队在生产部署之前识别问题，将被动调试转化为主动质量保障。
核心术语体系
文章首先建立了统一的概念框架：
- 任务/问题/测试用例（Task）： 具有明确输入和成功标准的单个测试
- 试验（Trial）： 对任务的每次尝试；由于模型的随机性，需要多次试验才能得到稳定结果
- 评分器（Grader）： 评判智能体表现的逻辑；每个任务可搭配多个评分器和多种断言
- 轨迹/记录（Transcript/Trace/Trajectory）： "一次试验的完整记录，包括输出、工具调用、推理过程、中间结果"及所有交互
- 结果（Outcome）： 任务完成后的最终环境状态
- 评估框架（Evaluation Harness）： 管理端到端评估执行的基础设施
- 智能体框架/脚手架（Agent Harness/Scaffold）： 使模型能够作为智能体运行的系统
- 评估套件（Evaluation Suite）： 衡量特定能力的任务集合
三类评分器
1. 基于代码的评分器
采用字符串匹配、二元测试、静态分析和结果验证等方法。优势在于速度快且客观，但难以处理预期模式之外的有效变体。
2. 基于模型的评分器
利用评分标准（rubric）和自然语言断言，能够处理细微差别和开放式任务，但引入了非确定性，需要校准。
3. 人工评分器
提供"金标准"的评判质量，但成本高昂且难以规模化。
四类智能体的评估策略
编码智能体
通过确定性的测试执行进行评估。SWE-bench Verified和Terminal-Bench是典型代表，通过运行单元测试来验证生成的代码是否解决了目标问题且未破坏现有功能。
对话智能体
需要同时评估交互质量和任务完成度。成功标准变为多维度的："工单是否已解决（状态检查）、是否在10轮以内完成（轨迹约束）、语气是否得当（LLM评分标准）？"当人机交互质量至关重要时，通常通过用户模拟来驱动评估。
研究智能体
面临独特挑战："专家们可能对综述是否全面存在分歧，参考内容持续变化导致真实标准不断漂移。"应结合多种评分器——事实依据检查、覆盖率分析和信息源质量验证——来缓解这些挑战。
计算机使用智能体
这类智能体像人类一样操作图形界面。评估需要沙箱环境和结果验证，同时检查UI状态和后端修改。
非确定性与关键指标
文章解释了两个核心指标：
- pass@k： 在k次尝试中获得至少一个正确解的概率；k增大时pass@k上升——衡量的是"能否做到"
- pass^k： k次试验全部成功的概率；k增大时pass^k下降——衡量的是"是否稳定可靠"
这两个指标捕捉了能力与一致性这两个不同维度的需求。
从0到1的实施路线图
第一步：初始数据集收集
"从真实失败案例中提取20-50个简单任务开始"，而不是等待构建完整的评估套件。优先选择用户报告的失败案例，确保评估的实际相关性。
第二步：任务质量标准
明确的任务规格至关重要。任务应能被领域专家独立完成，评分器的成功标准对智能体应是透明的。创建参考解决方案以验证任务的可解性。
第三步：平衡的问题集
评估必须同时测试正例（期望行为应该发生的情况）和反例（期望行为不应该发生的情况），防止单向优化和类别失衡。
第四步：健壮的基础设施
隔离的试验环境防止因共享状态导致的关联失败，确保测量的是模型能力而非基础设施伪影。
第五步：审慎的评分器设计
文章警告不要使用"过于脆弱的测试"，这类测试会惩罚有效的替代解法。应使用部分得分机制来表示成功的连续性，而非简单的通过/失败二元判断。
第六步：轨迹审查
"除非你阅读了大量试验的轨迹和评分，否则你不会知道评分器是否运作良好。"这个人工验证步骤能够发现公平性问题和评估逻辑的偏差。
第七步：饱和度监控
当评估性能接近100%时，能力评估应升级为回归测试套件。饱和度信号表明需要更难的任务来维持测量灵敏度。
评估的全景视图
自动化评估只是更广泛质量保障体系的一部分：
- 自动化评估：支持部署前的快速迭代
- 生产监控：大规模揭示真实用户行为
- A/B测试：衡量不同方案的实际效果
- 人工轨迹审查：建立对失败模式的直觉
- 系统性人工研究：校准基于模型的评分器
这些方法形成防御性组合——"没有任何单一评估层能捕捉所有问题。"
实际案例
文章引用了真实应用案例：Descript从人工评分演进到基于LLM的评估，并辅以人工校准；Bolt.ai在三个月内构建了完整的评估系统，涵盖静态分析和浏览器智能体测试。
长期维护
成功的评估项目需要"专门的评估团队拥有核心基础设施，而领域专家和产品团队贡献大部分评估任务。"将评估视为单元测试——常规维护而非事后补救——才能持续保持信号质量。
附录：框架选项
文章回顾了开源和商业评估基础设施：Harbor（容器化环境）、Braintrust（离线/生产可观测性）、LangSmith（链路追踪集成）、Langfuse（自托管方案）以及Arize/Phoenix（LLM链路追踪平台）。
技术要点
pass@k与pass^k的对偶性：前者衡量能力上限（"能否做到"），后者衡量可靠性下限（"是否稳定"）。对于生产环境部署，pass^k往往比pass@k更重要。
多维度评分设计：单一任务可配置多个评分器，分别检查状态、轨迹约束和质量标准，实现对智能体行为的立体评估。
正反例平衡：仅测试"应该做什么"会导致过度触发的模型获得高分。加入"不应该做什么"的反例是确保评估有效性的关键设计原则。
评估饱和度管理：当评估接近100%通过率时，它已不再是有效的能力测量工具，应将其降级为回归测试并引入更具挑战性的新任务。
环境隔离原则：每次试验必须在隔离环境中运行，避免试验之间的状态泄露导致关联失败，这与前文《基础设施噪声》一文的发现高度呼应。
深度解读
这篇文章的价值不在于提出了革命性的新方法，而在于将AI智能体评估的最佳实践系统化、标准化，使之成为一门可教授、可复制的工程学科。
文章最精妙的洞察在于对评估方法论"分层防御"的强调。自动化评估、生产监控、A/B测试、人工审查和系统性研究形成了五层防线，每一层捕捉不同类型的问题。这与安全工程中的"纵深防御"理念一脉相承——不依赖任何单一机制，而是通过冗余来提高整体可靠性。
pass@k和pass^k这对指标的引入也极具洞见。在当前行业实践中，大多数报告仅使用pass@1或pass@5等单一指标，这掩盖了模型在"能力"和"一致性"之间的权衡。一个pass@5很高但pass^5很低的模型，意味着它"偶尔表现出色但经常失败"——这对于生产环境而言可能是不可接受的风险。
值得注意的是，文章将"从20-50个真实失败案例开始"作为实施路线图的第一步。这种务实的起点远比追求"完美的评估覆盖率"更有价值——因为它确保评估从第一天起就与真实用户痛点对齐。
从团队组织角度看，"专门的评估团队 + 领域专家贡献任务"的分工模式值得借鉴。这意味着评估不是AI团队的"业余项目"，而是需要专职投入的核心基础设施——就像测试工程在传统软件开发中的地位。
延伸思考
评估的评估：如何评判一个评估体系本身的质量？是否需要"元评估"（meta-evaluation）来衡量评估套件的覆盖率、区分度和预测效度？
基于模型的评分器的"评分器偏见"：当用Claude评判Claude的输出时，是否存在系统性偏见？跨模型评分（如用GPT评判Claude，反之亦然）是否能提高客观性？
评估驱动开发（EDD）：类似于测试驱动开发（TDD），是否应该在构建智能体功能之前先编写评估用例？这种开发范式是否适合AI智能体的迭代周期？
评估的可解释性：当智能体在评估中失败时，如何快速定位是智能体的问题还是评估本身的问题？评分器的可解释性与模型的可解释性同样重要。
原文链接： https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents