Agent 评测体系：三层分类与一条流程

一个能让 AI 独立工作的系统，怎么知道它好不好：

"这个东西到底行不行？"

凡是亲手搭过 Agent 的人------能自主拆解任务、调用工具、多步推进的那种系统------迟早会被问到这个问题，或者自己问出这个问题；给自己一个能说服别人也能说服自己的答案，就是 Agent 评测要做的事

一个完整的 Agent 评测体系可以浓缩成一个公式：

Agent 评测 = 三层分类（评什么） × 一条流程（怎么评）

三层分类：① 端到端 → ② 轨迹 → ③ 表现

一条流程：① 定数据集 → ② 定标准 → ③ 跑测试 → ④ 看指标归因 → ⑤ 持续迭代

两个维度相互正交：三层分类讲 "评什么"，按层次划分；一条流程讲 "怎么评"，按顺序执行；任何一次具体的评测动作，都落在 "某一层 × 某一步" 的交叉点上

评测是伴随着大模型应用出现的；业界并不缺评测方法，缺的是对评测对象的精准界定------同样的评测体系，评的对象不同，重心就不同；因此先把两个容易混淆的概念分开：

Agent 评测：评的是 "一条多步执行的轨迹"
RAG 评测：评的是 "一问一答的质量"

之所以要拆开讲，是因为 Agent 是多步的：拿 RAG 那套 "输入一个 query、看答案好不好" 的做法套在 Agent 上，会丢掉大量过程信息，埋在过程中的错误根本暴露不出来

评什么：三层分类

端到端评测：把 Agent 当黑盒，只看输入与最终输出

第一个层次最直觉：给 Agent 一个任务，跑完，看最终结果对不对

它评的是 "任务有没有完成"，以及最终答案的正确性、可用性；对应的指标是 Task Completion（任务完成率）

优点：全自动，成本低------部署个 Agent、跑完、比对结果就出分；典型代表是 τ-bench：让 Agent 执行客服任务，Agent 与用户多轮交互、调用后台工具修改数据库，评测时比对 "会话结束时数据库状态" 与 "目标状态"，一致才算任务完成，相当于直接考业务结果
缺点：诊断能力有限------端到端只告诉你 "做没做成"，不告诉你 "为什么没做成"：完成率从 68% 掉到 55%，它能拉响警报，但说不清是哪一环坏了

这就需要第二层

轨迹评测：Agent 做的每一步，都拿来评

轨迹评测评的是 Agent 的完整决策与行动序列；所谓轨迹，就是 Agent 一路走来的完整执行过程，从三个维度看：

维度	指标	含义
规划	Plan Quality	计划本身合理吗
规划	Plan Adherence	实际执行按计划走了吗
步骤	Step Efficiency	有没有绕路、无效步骤
工具调用	Tool Correctness	每一步工具选对了吗
工具调用	Argument Correctness	工具参数传对了吗

一个容易混淆的术语：trace（执行轨迹的原始记录，通常是采集到的完整数据流）和 trajectory（完成任务的有序动作序列）不是一回事------后者是从前者中提取出来、被评的那个序列

表现评测：非功能性指标

第三层看的是非功能性指标，分三类：

效率类：延迟（P99、首字延迟）、Token 消耗、完成任务所用步数；
稳定类：成功率、pass^k------同一个任务跑 k 次全部成功的比例；
安全类：越权操作、危险操作、数据泄露

这一层的原则：一个 Agent 能答对但极慢、极贵，在生产里同样是不可接受的

三层不是并列关系，而是一个逐层下钻的诊断栈：端到端评结果------结果不好，用轨迹评过程------过程哪步坏了，再看具体组件的表现指标定位原因；先看宏观，再看微观，层层深入

生产环境主看六个指标：

评测框架 DeepEval 提供了 50 多个 Agent 指标，但生产不是全都要，实际主要看六个：

	指标	所属层	关注什么
①	Task Completion	端到端	总账：任务到底完没完成
②	Plan Adherence	轨迹	跑偏没：是否按计划执行
③	Tool Correctness	轨迹	工具选对没
④	Argument Correctness	轨迹	参数传对没
⑤	Token 成本 / 延迟	表现	贵不贵、快不快
⑥	pass^k	表现	稳不稳：同一任务跑 k 次全部成功的比例

其中 ③④ 要成对看：只评 Tool Correctness 不评 Argument Correctness，工具选对了但参数传错，一样不达标

另有一批 "场景指标"，按业务需要选用，默认不开：

场景	加看指标
带 RAG 检索	Faithfulness（忠实度）、Answer Relevancy（答案相关性）
涉及用户隐私	PII Leakage（个人信息泄露）
涉及敏感操作（转账、删库）	Tool Permission（工具权限）、Tool Misuse（工具滥用）
面向 C 端用户	Toxicity（毒性）、Bias（偏见）

一条重要原则：指标是渐进的，不要一上来全开；推荐顺序：

先只上 Task Completion，看总账；
有问题，再加轨迹指标，定位是哪步坏；
再按业务场景，补挂场景指标

背后是美团和 Anthropic 共同的共识：先做 error analysis（错误分析），再决定写哪些指标；反面例子就是 50 个指标全开：成本爆炸、噪音淹没信号、指标没人看，最后系统反而更难评测

怎么评：一条流程

① 定数据集：

一个用例就是一个三元组：问题 + 参考答案 + 评价标准；数据集按用途分三类：

类型	英文	作用	规模与通过率
黄金集	golden set	人工精标，定义 "好的下限"	起步 20~50 条
回归集	regression set	以前能做对的，防止回退	通过率要求 ≈100%
挑战集	capability set	专攻当前难题，标定能力边界	通过率从低起步

三类集分工明确：黄金集定义及格线，回归集守住既有能力，挑战集专门暴露短板

② 定标准：

标准按 "判得清不清" 分三类，对应三种判据：

程序判断：适用于清晰的指标------工具名、参数、格式、终态状态这类；用代码做确定性断言（EQ / CONTAINS / REGEX），快、稳、可复现；例如 ToolCorrectness 就是实际工具序列与期望序列相等才算通过
大模型判断：适用于模糊的指标------答案质量、规划合理性、沟通质量这类；关键手法是把 rubric（评分细则）二元化，将模糊概念拆成一组可判断的 "是 / 否 / 未知" 检查项；例如 AnswerCorrectness 的分档：0-2 错 / 3-6 大体对 / 7-9 漏细节 / 10 全对，阈值 ≥ 7；前提是人机一致率要达标------机器评测与人工评测结果一致，否则只能叫机器标注，不能叫自动化评测
人工判断：主要用于校准前两者，尤其是校准大模型的 rubric；组织原则是 "1 个独裁者好过 10 个民主者"------统一标准、由一个人拍板，比多人各执一词更能保持一致性

三类判据的分工原则一句话：清晰的指标用程序，模糊的指标用大模型加 rubric，人工负责校准

③ 跑测试：

按 "在哪跑、有没有参考答案" 分两种场景：

离线评测：在评测集上跑，有参考答案（reference-based）；用于上线前回归测试、对比新旧版本；实现方式包括跑评测集和回放（replay------用线上真实 trace 重新跑，验证新版本行为）；
在线评测：在生产真实流量上评，无参考答案（reference-free）；用于发现未知问题；实现方式包括影子模式（上线前用真实流量兜底）、AB 测试（上线后确认业务价值）、巡检（日常监控基本盘）

一句话概括：离线守已知，在线发现未知

④ 看指标归因：

指标按层取用：

端到端层看 Task Completion；
轨迹层看 Tool Correctness 和 Plan Adherence；
表现层看延迟、成本、稳定性、安全

归因就是把失败的 trace 归类成 failure taxonomy（失败分类法），定位 "哪一层的哪一步坏了"；两个关键认知：先做 error analysis，再决定写哪些指标；离线评测只是门控，线上 AB 测出来的业务指标才是黄金标准

⑤ 持续迭代：

把线上失败的 case 回灌进评测集，闭环越滚越大；上一版没发现的问题，沉淀成下一版的回归用例，门槛越卡越准

上线与迭代：

评测做完不等于结束，还要接进研发流程

放行标准（和上一版比）：

优化项 ≥ 上一版，且统计显著------防止 0.901 对 0.900 这种波动被误判为进步；
其余指标下降在容差内（如 ±2%）；
红线指标（延迟、安全）不超预算，超了一票否决

发布节奏用灰度：影子流量 → 小流量 AB → 放量 → 全量；线上监控盯三块：系统指标（延迟、成本）、质量指标（在线 judge）、漂移检测（query 分布变化）；指标掉了立即回滚，bad case 回流评测集，闭环继续转

回顾：

回到开头的问题：Agent 到底行不行，要拆成三层看------端到端看结果（Task Completion）、轨迹看过程（工具、参数、规划）、表现看代价（成本、延迟、pass^k）；无论评哪层，都走同一条五步流程------定数据集、定标准、跑测试、看指标归因、持续迭代；指标别贪多：先上 Task Completion，先做 error analysis，再渐进加码；离线守已知，在线发现未知，线上 bad case 回灌评测集，评测体系才能随业务一起长大