目录
你搭好了一套多智能体系统，给它配上工具，并用 Agent SDK 运行起来——那么，你要怎么衡量这个智能体到底有没有把活干好呢？对于单条输出，你可以用 AI 评估来打分。但智能体会跨越多步进行规划、调用工具、并带着状态去行动。哪怕最后一句话看起来没错，它也可能在途中走过一座危险的桥。这正是 Agent Evals（智能体评估）登场的地方。
本文基于官方信息，梳理 Agent Evals 是什么、它与 LLM 评估有何不同、评估什么（5 个维度）、如何打分（3 种打分器）、特有的陷阱，以及实战工作流加基准测试。要点先放在前面。① Agent Evals 衡量的不只是「最终输出」，还包括行动的「trajectory」。 ② Anthropic 建议给结果（最终状态）而非路径打分——因为机械地逐步核对很脆弱。③ 先用 20～50 个取自真实失败的任务组成一个小评估集，并运行自动打分。
同时衡量「最终答案」与「走过的路」
— 只看输出的评估不够；智能体是多步骤、用工具、带状态的
Anthropic 建议给结果而非路径打分——但 trajectory 能告诉你它为什么失败。两者各司其职，按需取用。
1. 什么是 Agent Evals？
Agent Evals 是系统性地衡量一个「智能体」——会使用工具、分多步去达成目标的那种——是否真的能完成其任务的过程。它是 LLM 评估（判断单条提示词质量）的演进，评估对象从「一条输出」扩展到「一连串行动」。
为何重要：Anthropic 在其关于 Agent Evals 的指南中指出，「评估拖得越久就越难搭建。在早期，产品需求会自然地转化为测试用例」，并建议「用 20～50 个取自真实失败的简单任务起步就很不错」。换句话说，Agent Evals 把「看起来好像能用」变成可复现的数字。它与 AI 可观测性（观察运行过程）相辅相成——你观察到的轨迹就成了评估的素材。
2. 为何不同于 LLM 评估（输出 vs trajectory）
传统的 LLM 评估本质上是对「输入 → 一条输出」打分。但智能体会规划、调用工具、查看结果、决定下一步动作，并更新状态。所以只看最终输出是不够的。Google 同样表示，「仅仅检查输出还不够，我们需要理解智能体行动背后的『为什么』」，并把评估分为两大类：「最终响应」和「trajectory」。Microsoft 也说，你必须「不仅评估最终输出，还要评估每一步的质量与效率」，将其分为系统级（端到端）评估和过程级（逐步）评估。
💡 核心思想：一个「正确的最终答案」可能掩盖了一个崩坏的过程。反过来，答案可能是对的，但却是靠运气、巧合，或一条危险的捷径得到的。所以对智能体而言，你要同时看「结果」和「过程」。关于单条输出评估与 LLM-as-judge 的基础，请参阅 AI 评估这篇文章。
3. 评估什么：5 个维度
以下是智能体评估中常用的五个视角。
是否达成了目标？以最终状态来判断——DB 中是否存在一条预订记录——而不是以那句话「我订好了」来判断。
它采取的步骤是否合理？是否以正确的顺序和次数使用了对的工具？有没有无谓的绕路或危险动作？
它是否选了对的工具并传入了对的参数？检查函数名、参数类型和取值（并检测多余的调用）。
用了多少步、多少 token、多少钱、多少秒？如果成本暴涨，再正确的答案也不实用。需要与观测到的指标相关联。
输出是否相关、准确、完整？用 LLM-as-judge 或评分量表（rubric）来给开放式内容打分。
注意：4. 效率（token、成本、延迟）并没有被任何单一厂商正式定义为一项「评估指标」；在实践中它往往是被引入评估的 可观测性信号。即便如此，它也是叫停那种陷入循环、失控狂奔的智能体所不可或缺的维度。
4. 如何打分：3 种打分器与「结果 vs 路径」
打分器大致分为三类。按照 Anthropic 的框架，每一类都有其取舍。
| 打分器 | 优势 | 劣势 |
|---|---|---|
| 代码（程序化） | 快、便宜、客观、可复现 | 对合理的变体／替代方案很脆弱 |
| LLM-as-judge（模型） | 灵活、可扩展、能捕捉细微差别 | 非确定性、更贵、需要与人工做校准 |
| 人工 | 质量评判的黄金标准 | 昂贵、缓慢（能避免就避免） |
标准打法：能用代码打分的就用代码，只把主观、开放式的部分交给另一个模型充当 LLM-as-judge，并在关键节点用人工做抽查。LLM-as-judge 的设计（详细的评分量表、离散的输出、评判偏差）在 LLM 评估这篇文章中有深入讲解。
机械的「trajectory 匹配」很脆弱
那么，trajectory 该怎么打分呢？这里 Anthropic 立场鲜明：「人们有一种常见的本能，就是去核对智能体是否按照非常具体的步骤行事，比如按正确顺序进行的一连串工具调用。我们发现这种做法太死板，会产生过于脆弱的测试，因为智能体经常会找到评估设计者没有预料到的合理方案。为了不无谓地惩罚创造力，通常更好的做法是给智能体产出的东西打分，而不是给它走的路径打分。」例如订机票时，你衡量的是环境的 SQL DB 中是否真的存在一条预订记录这一最终状态——而不是「我订好了」这句话。
另一方面，Google 和 Microsoft 把 trajectory 匹配的不同程度（精确／按序／不计顺序等）作为正式指标提供。这两者并不矛盾——trajectory 评估擅长诊断「它为什么失败」，而结果评估则避免惩罚合理的创造力。在实践中，现实的折中是避免严格的精确匹配，放宽为关键动作核对：「是否调用了那些关键工具？」
5. Agent Evals 特有的难题
Agent Evals 带有一些单条输出评估所没有的难点。
- 非确定性（同样的输入走出不同的路径）：成功一次并不意味着能复现。你需要可靠性指标，比如在全部 k 次运行中是否都成功（pass^k）。τ-bench 论文报告称「随着 k 增大，模型显著退化，暴露出它们的不可靠」（这些数字是某一时点的）。
- 误差累积：如果单步以概率 p 成功，那么 t 步大约以 pt 成功。链条越长，崩溃得越快——这正是长程任务上成功率急剧下降的原因。
- 奖励黑客／规约博弈（reward hacking / specification gaming）：满足了打分器字面要求、却没有达成真正目标的行为。在 DeepMind 的例子里，一只机械臂把自己摆在摄像头和物体之间，骗过了评估者，让它们以为机械臂抓住了物件，而其实并没有。要抓住「看起来对、路径却危险」的情况，就需要评估 trajectory 和副作用。
- 评估集过时／被污染：当某个基准测试泄漏进训练数据（污染），分数就不再反映真实能力。随着智能体不断成熟，你必须持续更新你的回归评估。
「危险路径」这个问题与 AI 护栏是连续相通的。一个只看最终答案的评估，会径直从这些陷阱旁边走过去。
6. 工作流与基准测试
以 Anthropic 的建议为依托，工作流很简单。
- 从真实失败出发，从小做起：你不需要成百上千个。把生产环境里发生过的 20～50 个失败变成测试用例。
- 运行自动打分：代码优先，只对开放式部分用 LLM-as-judge。把数量优先于手工打分的质量。
- 区分两类：能力评估（它擅长什么？）和回归评估（它还能不能做到以前能做的？）。
- 纳入生命周期：① 上线前的自动评估（嵌入 CI）→ ② 生产监控 → ③ A/B 测试 → ④ 用户反馈与轨迹复盘，层层叠加。
- 尽早编写：评估拖得越久就越难搭建。
知名的智能体基准测试对于搭建你自己的评估也是有用的参考（关键是读懂「每个基准在测什么」；分数会随模型和版本变化，所以别照单全收）。
| 基准测试 | 它测什么 |
|---|---|
| SWE-bench / Verified | 用补丁解决真实的 GitHub issue，由测试套件判定通过／失败（基于执行） |
| τ-bench / τ²-bench | 零售、航空等场景下的多轮 工具×用户 对话＋遵循策略；以最终 DB 状态打分 |
| WebArena | 在逼真的站点副本上完成自主 Web 操作任务 |
| GAIA | 对人类容易、对 AI 困难的通用助手任务（推理＋工具＋浏览） |
| OSWorld | 在真实 OS 上操作 GUI 的计算机使用，基于执行进行评估 |
| BFCL | 函数／工具调用的准确性（函数名、参数结构、可执行性） |
至于工具，LangSmith、Braintrust、DeepEval 和 Arize Phoenix 都支持 trajectory 与工具调用评估。大多数都构建在 轨迹（traces）之上，在步骤、运行、数据集三个层级上打分。要注意，Claude Managed Agents 内置了基于结果的打分——由一个独立的打分器对照你的评分量表进行评估。
总结
Agent Evals 是衡量一个会用工具、分多步的智能体是否真的能完成其任务的过程。与只看单条输出的 LLM 评估不同，它同时审视「最终答案（结果）」和「走过的路（trajectory）」。维度包括① 结果 ② trajectory ③ 工具使用 ④ 效率 ⑤ 最终质量。打分顺序为代码 → LLM-as-judge → 人工，而 Anthropic 建议「给结果（最终状态）而非路径打分」（机械逐步核对很脆弱）。
特有的陷阱有非确定性（pass^k）、误差累积、奖励黑客，以及评估集过时。在实践中，标准打法是从 20～50 个取自真实失败的用例小规模起步，在 CI 中运行自动打分，区分能力评估与回归评估，并尽早编写。相关阅读：AI 评估、可观测性、如何搭建多智能体系统、Managed Agents。
FAQ
Q. 什么是 Agent Evals？
A. 系统性地衡量一个会用工具、分多步的智能体是否真的能完成其任务的过程。它是 LLM 评估（对单条提示词打分）的演进，评估对象从「一条输出」扩展到「一连串行动」。其标志是不仅看最终答案，还看通向它的 trajectory（调用了哪些工具、如何调用）。
Q. 它与普通的 LLM 评估有何不同？
A. 区别在于你看的是「一条输出」还是「一连串行动」。因为智能体会规划、调用工具并更新状态，仅凭最终输出是不够的。一个正确的答案可能掩盖了崩坏的过程，而一个对的答案也可能是经由危险的捷径得来的。所以你要同时评估结果（最终状态）和 trajectory（过程）。
Q. 我该评估什么？
A. 常见的五个维度：① 结果（任务成功＝最终状态是否与目标一致？）② trajectory（步骤是否合理？）③ 工具使用的正确性（对的工具、对的参数？）④ 效率（步数、token、成本、延迟）⑤ 最终响应的质量（相关、准确、完整？）。第 4 个维度引入了可观测性信号，对于叫停失控运行很重要。
Q. 我该不该对 trajectory（步骤）做精确匹配？
A. 不该——严格的精确匹配往往很脆弱。Anthropic 建议：「核对工具调用是否遵循了正确顺序太死板、太脆弱；智能体会找到合理的替代方案，所以更好的做法是给结果而非路径打分。」在实践中，避免精确匹配，放宽为关键动作核对：「是否调用了那些关键工具？」话虽如此，trajectory 对于诊断它为什么失败很有用，所以要各取所长、按需使用。
Q. 我该如何起步？
A. 先把 20～50 个生产环境的失败变成测试用例。正如 Anthropic 所说，「你不需要成百上千个；用 20～50 个取自真实失败的简单任务起步就很不错」。然后自动打分——代码能衡量的就用代码，只对开放式部分用一个独立模型的 LLM-as-judge——并把它放进 CI 以捕捉回归。区分能力评估（它擅长什么）和回归评估（守住已经能用的），并尽早编写你的评估。
