AI 智能体评测解密：如何为 Agent 构建可靠、可演进的评测体系

董厂长

385人浏览 · 2026-08-12 14:53:16

董厂长 · 2026-08-12 14:53:16 发布

原文：Demystifying evals for AI agents
来源：Anthropic Engineering
发布日期：2026-01-09
作者：Mikaela Grace、Jeremy Hadfield、Rodrigo Olivares、Jiri De Jonghe
原文链接：https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents

说明：本文是基于原文结构与观点整理的中文技术导读，采用语义级转述与专业术语本地化，不是逐段逐句的替代性译文。文中配图来自原网页，版权归 Anthropic 或相应权利人所有，仅随本资料作学习与研究引用。

摘要

让 Agent 真正有用的特性——自主决策、多轮行动、工具调用、环境状态修改和动态适应——也正是它难以评测的原因。传统的“输入一个提示、检查一次输出”已经不足以覆盖 Agent 的真实行为。可靠的 Agent 评测通常需要同时考察：

最终是否完成任务；
中间过程是否合理、安全且高效；
多次运行是否稳定；
评分器是否公平、可复现、难以被投机绕过；
评测环境是否与生产环境足够一致。

Anthropic 的核心建议可以概括为：尽早开始、从真实失败中收集任务、优先评最终结果而不是固定路径、组合多类评分器、反复阅读执行轨迹，并把评测套件当作需要长期维护的软件资产。

1. 为什么 Agent 评测比普通 LLM 评测更难

单轮模型评测通常只有三个要素：输入、模型输出和评分逻辑。Agent 则会在多轮循环中读取信息、调用工具、修改文件或数据库、观察中间结果，再决定下一步行动。

这会带来几类额外复杂性：

错误会沿轨迹传播：早期一次错误调用，可能导致后续所有行动建立在错误状态之上。
结果与表述可能不一致：Agent 可以声称“预订成功”，但真正的成功标准应是后台数据库中确实出现了有效订单。
正确路径不唯一：更强的模型可能找到评测设计者没有预料到的合理方案，甚至发现规则中的漏洞；僵硬的评分方式可能把优质方案误判为失败。
行为具有随机性：相同任务多次运行，结果可能不同，因此一次通过或失败不能代表稳定能力。
被评测对象是一个组合系统：实际表现不仅取决于模型，还取决于工具、提示词、上下文管理、Agent 脚手架、运行环境和错误恢复策略。

在这里插入图片描述

图 1：单轮评测与 Agent 评测的区别。 单轮评测主要检查回答；Agent 评测还必须提供工具和环境，并验证执行后的实际状态。

2. Agent 评测的基本结构与术语

一个完整的 Agent 评测系统通常包含以下对象。

术语	推荐译法	含义
Eval / Evaluation	评测	向 AI 系统提供输入，并使用评分逻辑衡量表现的测试过程
Task / Test case	任务 / 测试用例	一条具有明确输入、约束和成功标准的测试
Trial	试验轮次 / 一次运行	Agent 对某个任务的一次完整尝试；同一任务通常需要运行多次
Grader	评分器	对表现的某一方面打分或判定的逻辑，可包含多个断言
Assertion / Check	断言 / 检查项	评分器内部的具体判定条件
Transcript / Trace / Trajectory	执行轨迹	一次运行的完整记录，包括消息、工具调用、推理过程和中间结果
Outcome	最终结果 / 最终环境状态	运行结束后环境中的真实状态，而不是 Agent 自己声称完成了什么
Evaluation harness	评测执行框架	负责分发任务、运行试验、记录轨迹、调用评分器并汇总结果的基础设施
Agent harness / Scaffold	Agent 运行框架 / 脚手架	让模型能够使用工具、处理输入并持续行动的系统
Evaluation suite	评测套件	围绕某种能力或行为组织的一组任务

在这里插入图片描述

图 2：Agent 评测的组成部分。 评测套件由多个任务组成；每个任务可运行多次并产生轨迹，评分器结合轨迹和最终状态输出分数。

一个重要认识是：当团队说“评测某个 Agent”时，实际评测的是模型与 Agent 运行框架的整体组合。提示词编排、工具接口、上下文截断、重试机制和环境配置都会影响结果。

3. 为什么值得尽早建立评测体系

原型阶段仅靠人工试用、内部使用和直觉，往往也能推进很快；但当产品进入生产、用户数量扩大、系统行为变复杂后，这种方式会迅速失效。

没有评测时，团队容易陷入典型的反应式循环：用户投诉某个问题，工程师手工复现并修复，然后只能祈祷没有引入新的回归。团队无法可靠地区分真实退化与随机波动，也很难在发布前对数百种场景进行自动验证。

成熟的评测体系会产生复利效应：

把模糊的产品要求转成可执行的成功标准；
在上线前暴露行为变化；
将生产故障沉淀成永久回归用例；
为模型升级、提示词调整和工具变更提供可比较的基线；
持续跟踪延迟、Token 用量、成本、错误率等工程指标；
让产品、工程与研究团队围绕同一组指标协作；
缩短新模型的评估与迁移周期。

早期成本看得见，而收益通常在后续版本中持续累积，因此评测的长期价值很容易被低估。

4. 三类评分器：代码、模型与人类

可靠的 Agent 评测往往不是依赖一种评分方式，而是把三类评分器组合起来。

4.1 基于代码的评分器

常见方式包括：精确或模糊字符串匹配、正则表达式、单元测试、静态分析、最终状态检查、工具调用检查，以及对轮数、Token 和延迟的轨迹分析。

优势：速度快、成本低、客观、可复现、便于调试。
局限：容易对合法变体过于敏感，难以理解语义和主观质量，也可能因规则过于僵硬而误判。

4.2 基于模型的评分器

常见方式包括：按量表评分、自然语言断言、成对比较、参考答案对照，以及多个模型裁判投票。

优势：灵活、可扩展，适合开放式输出、交互质量和复杂语义。
局限：具有非确定性，成本高于代码评分，而且必须用人类专家结果进行校准。

4.3 人类评分

常见方式包括：领域专家审查、众包判断、抽样复核、A/B 测试和标注者间一致性分析。

优势：能提供最接近真实用户与专家判断的高质量基准，也是校准模型评分器的重要依据。
局限：昂贵、缓慢，专业领域还需要稀缺专家参与。

4.4 如何组合

评分可以采用：

加权评分：各维度合成总分，达到阈值即通过；
全量通过：所有关键评分器都必须通过；
混合模式：安全和正确性采用硬门槛，质量和效率采用加权分。

工程上通常应遵循：能用确定性规则验证的，就优先用代码；需要判断语义与质量时再用 LLM；用人类抽检和标定确保模型评分器没有漂移。

5. 能力评测与回归评测

这两类评测回答的问题不同。

能力评测（Capability / Quality Eval）

它关注：“这个 Agent 目前能把多难的任务做好？”

初始通过率可以较低；
应包含具有挑战性的任务；
作用是为团队提供明确的改进方向；
当分数过高时，需要持续加入更难任务，避免饱和。

回归评测（Regression Eval）

它关注：“过去已经能做好的事情，现在是否仍然可靠？”

目标通过率应接近 100%；
每次修改或模型升级后持续运行；
分数下降通常意味着某处出现了退化；
已经被充分攻克的能力任务，可以转入回归套件。

两者必须同时存在：只追求新能力可能破坏旧功能，只做回归又无法衡量能力上限的提升。

6. 不同类型 Agent 的评测方法

6.1 编码 Agent

编码任务适合使用确定性评分器，因为软件产物通常可以直接执行和测试。关键做法包括：

编写清晰、可复现的任务描述；
使用隔离且稳定的代码环境；
通过单元测试验证功能正确性；
同时确保新代码没有破坏既有测试；
使用 lint、类型检查和安全扫描补充质量信号；
必要时用 LLM 量表评估可读性、过度设计、工具使用和用户沟通。

像 SWE-bench Verified 和 Terminal-Bench 这类基准，核心都在于让 Agent 完成真实工程任务，再通过自动测试检查结果。

一个实用的评测配置可以抽象为：

task:
  id: repair-authentication-edge-case
  objective: 修复空凭证导致的认证绕过

  graders:
    - type: unit_tests
      required:
        - reject_empty_credentials
        - reject_null_credentials

    - type: static_analysis
      tools: [linter, type_checker, security_scanner]

    - type: outcome_check
      expect:
        audit_event: authentication_blocked

    - type: llm_rubric
      dimensions:
        - code_quality
        - change_scope
        - explanation_quality

  metrics:
    - turns
    - tool_calls
    - total_tokens
    - latency

这不是原文示例的逐句翻译，而是按其方法重新整理的通用模板。

6.2 对话型 Agent

客服、销售、辅导等对话 Agent 不仅要完成任务，还要保证交互本身的质量，因此常常需要第二个 LLM 扮演用户并进行多轮模拟。

可同时检查：

工单或订单的最终状态是否正确；
是否调用了身份验证、退款、确认通知等必要工具；
是否在合理轮数内完成；
语气是否恰当；
是否清楚解释处理结果；
回答是否基于工具返回的政策或数据，而不是编造。

由于许多对话任务存在多个合理答案，模型评分器通常比精确字符串匹配更合适，但仍应通过状态检查锁定关键业务结果。

6.3 研究型 Agent

研究 Agent 负责检索、综合和分析信息，其质量难以用单一正确答案判断。不同任务对“全面”“可靠”和“正确”的定义也不同。

有效评测通常结合：

有据性检查：重要论断是否能被检索到的来源支持；
覆盖度检查：是否包含任务要求的关键事实或维度；
来源质量检查：是否优先使用权威、原始和相关来源；
精确答案检查：对于客观数值或实体，可使用精确或容错匹配；
综合质量评分：由 LLM 判断结构、连贯性、完整性与矛盾；
专家校准：定期将 LLM 评分与领域专家判断进行对照。

研究内容和外部网页会持续变化，因此参考答案也需要维护，不能假设“真值”永久静止。

6.4 计算机操作 Agent

计算机操作 Agent 通过截图、鼠标、键盘和滚动来使用图形界面，而不是直接调用 API。评测时必须在真实或沙箱化的软件环境中运行，并验证其是否真正完成目标。

常见检查包括：

页面 URL、导航状态和 UI 元素；
后端数据库是否发生预期变化；
文件系统、应用配置或生成文件是否正确；
Agent 是否根据场景选择了更合适的交互方式。

在浏览器场景中，DOM 读取通常速度快但可能消耗大量 Token；截图交互较慢，却可能更节省上下文。评测应覆盖工具选择是否合理，而不只是最终是否完成任务。

7. 如何处理非确定性：pass@k 与 pass^k

Agent 的表现会随运行而变化，因此“某次通过”不能等同于“稳定可靠”。原文重点区分了两个指标。

pass@k：多次尝试中至少成功一次

它衡量在 k 次尝试中至少出现一次成功的概率。随着尝试次数增加，pass@k 通常上升。

在每次试验独立、单次成功率为 p 的简化假设下：

[
\mathrm{pass@k}=1-(1-p)^k
]

适合场景：允许生成多个候选，只要其中一个可用即可，例如搜索解、候选代码或创意方案。

pass^k：连续 k 次全部成功

它衡量 k 次运行全部成功的概率。随着 k 增加，要求会快速变严格。

在相同简化假设下：

[
\mathrm{pass^k}=pk
]

例如单次成功率为 75%，连续三次全部成功的概率约为 0.75³ ≈ 42%。

适合场景：用户期望每次都可靠的生产级 Agent，例如客服退款、支付操作或关键业务流程。

在这里插入图片描述

图 3：pass@k 与 pass^k 会随着试验次数增加而走向相反方向。 前者强调“至少一次成功”，后者强调“一致成功”。

产品需要先确定自己真正关心的是“找到一个可行解”，还是“每次都稳定完成”，再选择指标。

8. 从零到一建立 Agent 评测体系

在这里插入图片描述

图 4：优秀评测体系的路线图。 工作分为评测套件建设、执行框架建设和长期维护三个阶段。

第 0 步：立即开始，不要等到“准备充分”

初期并不需要几百个任务。来自真实失败的 20～50 个简单任务就足以建立第一版基线。早期系统改动的影响通常较大，小样本也能提供明显信号。

第 1 步：把现有人工测试转成用例

从每次发布前已经会手工验证的行为开始。若系统已经上线，应优先查看缺陷列表、客服工单和用户反馈，把真实失败转成测试任务，并按用户影响排序。

第 2 步：任务必须明确，并准备参考解

好的任务应让两位领域专家独立判断时得到相同的通过/失败结论。任务描述中必须写明评分器真正会检查的要求，不能让 Agent 因隐藏假设而失败。

每个任务最好准备一个已知可行的参考解，用于证明：

任务确实可完成；
测试环境可用；
评分器配置正确；
通过标准没有自相矛盾。

对于前沿模型，如果一个任务经过大量尝试仍然完全无法通过，首先应怀疑任务、环境或评分器是否有问题，而不是立即断言模型没有能力。

第 3 步：建立平衡的数据集

不仅要测试“应该触发某行为”的场景，也要测试“不应该触发”的场景。

例如评测 Web 搜索功能时，既要覆盖必须搜索的实时问题，也要覆盖无需搜索即可回答的稳定事实。只测一侧会导致过度触发或触发不足。

第 4 步：构建稳定、隔离的评测环境

评测中的 Agent 应尽量与生产版本一致。每次试验都应从干净环境开始，避免残留文件、缓存、共享数据库、资源耗尽或历史记录造成相关性错误。

如果多个任务因为同一个环境瓶颈同时失败，这些试验并不独立，评测结果也就不能准确反映 Agent 能力。

第 5 步：谨慎设计评分器

几条关键原则：

能验证最终结果时，优先评结果，而不是强制固定的工具调用顺序；
不要因为 Agent 采用了未预料但合法的方案就扣分；
多组件任务应支持部分得分；
LLM 裁判应按维度拆分量表，避免一个模型一次判断所有内容；
当信息不足时，允许评分器返回“未知”，而不是被迫猜测；
定期用人类专家标定模型评分器；
设计防投机机制，确保通过评测必须真正解决问题。

很多看似“模型能力低”的结果，实际来自模糊任务、精度过高的字符串判断、不可复现的随机环境或 Agent 脚手架限制。因此不能只看总分，必须检查评分逻辑。

第 6 步：阅读执行轨迹

评分器是否合理，只有通过阅读大量轨迹和评分结果才能确认。

当任务失败时，轨迹可以帮助区分：

Agent 真的做错了；
Agent 给出了合法方案但评分器不接受；
工具或环境出现故障；
任务描述存在歧义；
评分器被意外绕过。

一个健康的失败应该“看起来公平”：能够明确说清错在哪里，以及为什么应当判失败。

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

当能力评测接近 100% 时，它只能继续充当回归测试，无法为进一步提升提供信号。此时应加入更长、更复杂、更贴近真实分布的任务。

饱和还可能掩盖真实进步：剩余任务极难时，模型能力的大幅提升只会表现为总分的小幅变化。因此评测难度要随模型能力同步演进。

第 8 步：长期维护并明确所有权

评测套件是一项持续演进的工程资产，需要负责人、审查机制和贡献流程。

一个有效的组织方式是：由专门团队维护核心基础设施，领域专家、产品经理、客户成功和工程团队共同贡献任务。最接近用户和产品要求的人，往往最适合定义“什么算成功”。

原文提倡评测驱动开发：在功能尚未完全实现之前，先用评测任务定义目标能力，然后迭代系统直到达到标准。

9. 评测不能单独工作：建立多层质量防线

自动化评测可以在不影响真实用户的情况下快速运行大量任务，但它只能覆盖预先想到的风险。完整的 Agent 质量体系还需要其他方法配合。

方法	主要价值	主要局限
自动化评测	迭代快、可复现、可进入 CI/CD、上线前大规模验证	前期建设和长期维护成本高；任务分布失真时会产生虚假信心
生产监控	反映真实用户行为，能发现合成任务没有覆盖的问题	偏事后，问题已经影响用户；信号噪声大，且常缺少明确真值
A/B 测试	使用真实流量比较方案，能衡量留存和任务完成等业务结果	达到统计显著性需要时间和流量；只能测试已部署版本
用户反馈	暴露未预料的问题，并附带真实案例	稀疏、自选择偏差明显，用户通常不会完整说明失败原因
人工轨迹审查	建立对失败模式的直觉，发现自动规则遗漏的细微质量问题	耗时、难扩展、覆盖不一致，通常偏定性
系统化人类研究	为主观任务提供高质量基准，并校准模型评分器	成本高、周期长；专业领域需要专家参与

在这里插入图片描述

图 5：质量保障的“瑞士奶酪模型”。 每一层都有盲区，多层方法叠加后，某一层漏掉的问题有机会被其他层捕获。

不同阶段的推荐组合：

开发和上线前：自动化评测作为第一道防线；
上线后：生产监控捕获分布漂移和真实世界异常；
重大版本比较：使用 A/B 测试验证实际业务影响；
持续运营：定期处理用户反馈并抽查轨迹；
主观或高风险领域：安排系统化人类研究和专家校准。

10. 实践中的常见反模式

根据原文案例，可以归纳出以下高频问题：

只检查 Agent 说了什么，不检查环境中真正发生了什么。
把工具调用顺序写死，惩罚合法的新路径。
任务描述没有公开评分器暗中要求的条件。
只测试正例，导致系统过度触发某种行为。
多次试验共享状态，造成数据泄漏或相关性故障。
用单一总分掩盖关键安全维度的失败。
使用未经人类校准的 LLM 裁判。
只看排行榜分数，不阅读轨迹和失败样本。
能力评测已经饱和，却继续把微小分差当作主要进步信号。
没有明确的维护负责人，导致任务、环境和产品逐渐失配。

11. 一份可直接采用的评测设计清单

任务设计

每个任务都有明确输入、约束和成功标准。
两位领域专家能独立得到一致的通过/失败判断。
评分器检查的每项要求都能从任务描述中得知。
每个任务至少有一个已验证的参考解。
数据集同时包含正例、反例和边界情况。
任务来自真实用户场景、生产故障或手工测试。

环境与运行

评测中的模型、提示词、工具和 Agent 框架与生产版本一致。
每次试验从干净、隔离的环境开始。
外部依赖和随机因素被固定、模拟或记录。
同一任务运行多个试验轮次。
记录完整轨迹、工具参数、最终状态、延迟和成本。

评分器

正确性优先使用确定性检查。
语义质量使用结构化 LLM 量表。
关键安全条件采用不可被平均分抵消的硬门槛。
支持部分得分，并区分不同失败层级。
LLM 评分器允许输出“未知”。
模型评分定期与人类专家结果对齐。
评分器经过防投机和绕过测试。

长期运营

每次发布或模型升级自动运行回归套件。
定期阅读失败和随机抽样的成功轨迹。
将生产问题持续转成新测试用例。
监控能力评测是否接近饱和。
明确评测基础设施和任务集的所有者。
定期删除、修复或更新失效任务。

12. 原文附录提到的评测框架

工具	原文概述
Harbor	面向容器化 Agent 运行，支持跨云大规模试验，并提供标准化任务与评分器格式
Braintrust	结合离线评测、生产可观测性和实验追踪，提供常见预置评分器
LangSmith	提供轨迹追踪、离线和在线评测、数据集管理，并与 LangChain 生态紧密集成
Langfuse	提供类似的可观测与评测能力，支持自托管，适合有数据驻留要求的团队
Arize Phoenix / AX	Phoenix 面向开源追踪、调试和评测；AX 提供面向规模化优化与监控的托管能力

原文的态度很务实：框架能减少基础设施工作，但框架本身不会自动产生高质量评测。真正决定价值的是任务、评分器和持续迭代质量。

13. 术语对照表

英文	推荐中文	备注
agentic evaluation	Agent 化评测 / 智能体评测	强调多轮行动、工具和环境状态
deterministic grader	确定性评分器	输出由代码规则决定，可复现
model-based grader	模型评分器	通常指 LLM-as-judge
human calibration	人类标定 / 人类校准	用专家评分校验模型裁判
rubric	评分量表 / 评分准则	应按维度写清等级定义
state check	状态检查	验证数据库、文件或应用状态
trajectory	执行轨迹	与 trace、transcript 常互换使用
groundedness	有据性 / 可溯源性	判断论断是否被来源支持
coverage	覆盖度	判断必要事实或维度是否齐全
regression	回归 / 退化	原有能力因修改而下降
capability eval	能力评测	衡量上限和可改进空间
regression eval	回归评测	确保已有能力持续稳定
eval saturation	评测饱和	大多数可解任务均已通过，失去区分度
scaffold	脚手架	让模型成为 Agent 的运行与编排层
harness	执行框架	负责端到端运行评测或 Agent
partial credit	部分得分	反映任务完成程度，而非只有二元结果
signal-to-noise ratio	信噪比	有效能力信号相对于环境和评分噪声的比例
eval-driven development	评测驱动开发	先定义可测能力，再迭代实现