目标：建立一套可落地的 Agent 评测方法论——既能回答「好不好」，也能回答「哪里不好」，并把评测嵌入迭代闭环。
前置要求：了解 Agent 基本概念与工具调用。若不熟悉评估基础指标，可先阅读 速通 AI（九）：RAG 与 Agent 评估体系。
本文综合美团《Agent 评测白皮书》系列 01：Agent 评测全览与淘宝 AI 购物助手在线评测落地实践：前者给出体系全景，后者给出日级工业化经验。两者拼在一起，正好覆盖「怎么建体系」和「怎么把体系跑稳」。
为了让抽象方法论好读，全文用一个贯穿例子：商家经营分析 Agent（美团白皮书中的例子）。它是典型的长程 Agent——多步骤、多 Skill 调用、有中间产物、和环境频繁交互，而且没有唯一正确答案。文中的数字与关键结论均来自两篇原文；为了讲清楚，部分类比和检查项会换到这个语境下重述。用户可能会说：
- 「帮我看一下三家门店上周的经营情况，做一页周报 PPT。」
- 「投放数据为什么这周掉得这么厉害？」
- 「把 A 店和 B 店的客单价对比一下。」
后面每讲一个概念，都尽量回到这个例子上看「具体长什么样」。
1. 核心问题：评测要同时回答两件事
评测不是算完一个分数就结束。它必须同时回答两件事：
- 好不好——给出判断，形成发布门禁
- 哪里好、哪里不好——定位问题，给出改进方向
拿商家 Agent 举例：
- 好不好：本周端到端交付率从 68% 掉到 55%，这版能不能发？
- 哪里不好：是「投放数据 Skill」挂了，还是「生成 PPT」这一步写崩了，还是评测标准本身判错了？
做不到第二点，评测只是报数；做不到第一点，评测没有门禁价值。后面所有模块，都是在服务这两个问题。
2. 总体框架：四模块 · 三能力 · 两 Loop · 一资产
先给一张全景图。完备的评测体系可以概括成四个数字：
| 维度 | 内容 | 在商家 Agent 里是什么 |
|---|---|---|
| 四个模块 | 离线评测、在线评测与监控、Case 挖掘与归因、观测基建 | 发版前回测、线上看板、坏 case 排查、日志 Trace |
| 三种能力 | 发现问题、定位问题、驱动演进 | 看得见、查得出、改得掉 |
| 两条 Loop | Agent 迭代 Loop、评测体系迭代 Loop | 修产品能力、校准量具 |
| 一套资产 | 评测集（问题 + 参考答案 + 评价标准） | 「做 PPT」这类任务的标准题库 |
两条 Loop 共享入口（Case 挖掘与归因）和共享资产（评测集），互相咬合：Agent Loop 修产品能力，评测 Loop 校准量具本身。
flowchart LR
M1["离线评测<br/>守住已知"] --> H["Case 挖掘与归因"]
M2["在线评测与监控<br/>发现未知"] --> H
H --> L1["Agent 迭代 Loop<br/>修能力"]
H --> L2["评测体系迭代 Loop<br/>校准量具"]
L1 --> S["评测集资产"]
L2 --> S
S --> M1
S --> M2
O["观测基建"] -.托底.-> H
2.1 为什么需要两条 Loop
可以把评测体系想成体温计 + 医生：
- Agent Loop：发现病人发烧，吃药、复查，把病治好
- 评测 Loop：发现体温计量不准了，重新校准体温计
只修 Agent 不校准量具，容易把「量具判错」当成「产品有病」；只校准量具不修 Agent，产品还是老样子。两条 Loop 必须一起转。
具体到商家 Agent：用户反馈「PPT 做得不对」。如果是 Agent 调错了 Skill，走 Agent Loop 修复；如果是评测标准把「风格不喜欢」也判成失败，那要改 Rubric，走评测 Loop。
3. 离线评测：变更门控
离线评测的核心职责是变更门控：发版前守住已知能力，防止版本回归。可以类比软件工程里的回归测试——改一行 Prompt、换一个模型、加一个 Skill，都要先过一遍固定考题。
3.1 四条原则
| 原则 | 做法 | 比喻 |
|---|---|---|
| 固定 | 固定评测集 + 固定执行环境，只变 Agent 版本 | 考卷不变，只换考生 |
| 门禁 | 嵌入 CI/CD | 不及格就不发版 |
| 多次试验 | 用 Pass@k / Pass Rate，而非单次通过与否 | 大模型有随机性，要多考几次取稳定结论 |
| 分层门禁 | 安全、数据准确性一票否决；体验类设阈值 | 安全题错一道就挂科，风格题可以扣到某个分数 |
为什么强调「固定」？回测本质是控制变量：只让 Agent 版本变化，其他一切不变，分数差才能归因到变更上。实践中最容易被破坏的是执行环境。比如评测时调用测试环境接口，而测试环境数据和生产不一致；或者沙箱里没预置用户历史文件，Agent 拿不到必要上下文。这类环境差异会让离线分数和线上表现系统性偏离，最终团队不再信任离线评测。
一个实用检验方法：拿同一批样本，分别在离线环境和线上影子流量里跑一遍，看两边结论是否一致。差异过大，说明环境保真度不够。
3.2 评测集结构
每个 Task 由三元组构成：问题 + 参考答案 + 评价标准（Metrics & Rubric）。
举个例子：
| 三元组 | 商家 Agent 示例 |
|---|---|
| 问题 | 「帮我看一下三家门店上周的经营情况，做一页周报 PPT。」 |
| 参考答案 | 对执行路径与最终环境状态的描述：应正确调用经营数据 Skill、取到三家门店数据、PPT 含核心指标 |
| 评价标准 | 一系列是 / 否检查项：是否选对 Skill？数据是否完整？图表是否可读？是否编造了不存在的指标？ |
从 ChatBot 迁移到 Agent 时，参考答案的形态要跟着变：
| 迁移项 | 短程（ChatBot） | 长程（Agent） |
|---|---|---|
| 参考答案 | 逐字比对的字符串 | 对执行路径与最终环境状态的描述 |
| 评测对象 | 答案评测 | 行为评测 |
Rubric 原则是二元化下钻：把「这个 PPT 好不好」这种模糊判断，拆成一组可回答是 / 否的检查项。
模糊版：「PPT 做得还行，但感觉差点意思。」
二元版：
- 是否包含三家门店的营收对比？（是 / 否）
- 图表是否标注了时间范围？（是 / 否）
- 是否出现参考数据里不存在的「毛利率」？（是 / 否）
下钻之后，人人一致、人机一致才有可能。
3.3 评测集分类与分层
| 类型 | 回答的问题 | 比喻 | 商家 Agent 示例 |
|---|---|---|---|
| 端到端 | 事有没有办成 | 期末总分 | 「100 个任务里有 68 个交付了可用的 PPT」 |
| 过程 | 中间哪一步出了问题 | 单科成绩 | 「投放数据 Skill 成功率从 95% 掉到 70%」 |
两类都必要：
- 只有端到端：知道「坏了」，但不知道「哪坏了」
- 只有过程：每个模块都达标，用户就是不满意
端到端评测集回答「要不要拉响警报」，过程评测集回答「警报响了该找谁」。
进一步可按功能模块拆：知识库评测集、Skill 评测集、子场景评测集。和组织分工对齐后，某层分数下降能直接找到负责人。比如门店经营、门店百科是两个功能模块，就分别建端到端评测集。
拆解边界：不要过早拆太细。先建端到端 + 核心模块过程评测集，被真实问题驱动再细化。评测集分层是演进结果，不是设计起点。
3.4 离线的固有局限
离线评测只能发现已知问题。评测集里全是「制作 PPT」类任务时，用户开始大量问「帮我对比三家门店数据」，回测永远测不出来。所以必须有在线能力来发现未知。
4. 在线评测与监控：发现未知
| 视角 | 回答 | 比喻 | 手段 |
|---|---|---|---|
| 在线评测（质量） | 系统工作得好不好 | 顾客满意度 | AB、影子模式、巡检 |
| 在线监控（运维） | 系统有没有在正常工作 | 机器有没有在转 | 成功率、失败率、Token、耗时、行为分布 |
一个直观例子：Skill 调用成功率 100%，但每次都返回了错误的数据——监控是绿的，评测是红的。
巡检是二者交集：从评测集抽代表性 Task，周期性检查线上表现。它既有评测属性（质量判断），也有监控属性（信号产出）。
监控要看三个维度：
- 可用性：Skill / Tool 成功率、失败率、超时率
- 成本：Token、平均步数、耗时
- 行为：任务类型分布、Skill 调用频次——新任务占比上升往往意味着评测集需要扩充
稳定性指标和行为指标要一起看。举例：任务完成率下降 5 个点——
- 如果「投放数据 Skill」失败率从 2% 涨到 15%，大概率是工程问题
- 如果 Skill 都正常，但「数据对比类」任务占比从 10% 涨到 35%，那是用户结构变了、Agent 在新场景能力不足
这两种情况的应对完全不同，也正是 Case 挖掘和归因的范畴。
5. Case 挖掘与归因：双环枢纽
Case 挖掘与归因是两条 Loop 的共享入口。没有它，离线只能回测旧题，在线只能看大盘，问题落不到具体样本。
5.1 四类来源与盲区互补
| 来源 | 盲区 | 比喻 |
|---|---|---|
| 线上反馈 | 只看到用户愿意抱怨的 | 只听客诉 |
| 监控告警 | 只看到能被指标刻画的 | 只看仪表盘 |
| 规则挖掘 | 只看到自己已想到的风险 | 只查自己写的检查单 |
| 随机采样 | 唯一能发现「你根本没想到的问题」 | 随机抽查聊天记录 |
随机采样成本最高、命中率最低，但不可省略。它是唯一能发现「你根本没想到的问题」的手段。
5.2 Case 池分化
| Good Case | Bad Case |
|---|---|
| 黄金集（定义「好的下限」） | 错题集（每一个坑不犯第二次） |
| 挑战集（标定能力边界） | 归因后分路处理 |
错题集回报最直接：每个曾经犯过的错，都不该再犯第二次。
黄金集容易被低估：Bad Case 告诉你哪里不行，但不能告诉你「到什么程度才算行」。没有黄金集，团队讨论质量只能各说各话；有了黄金集，「我们要做到这个水平」就变成了可以指着看的具体样本。比如一份公认优秀的经营周报 PPT，就是黄金集里的样本。
5.3 四层归因
单条 Bad Case 只能说明「这里出了问题」，还不能说明「为什么出问题」。必须逐层归因，才能避免把评测方法问题误当成 Agent 质量问题。
flowchart TD
B["Bad Case"] --> D["数据层"]
D -->|"脏数据、字段映射、工具内部提示词污染"| DF["修数据清洗 SQL / 解析逻辑"]
D -->|"数据正确"| P["Prompt 层"]
P -->|"Judge 对规则理解有偏差"| PF["补 Prompt 判定规则或示例"]
P -->|"理解正确"| R["Rubric 层"]
R -->|"标准与业务认知不一致"| RF["改 Rubric 并同步离在线快照"]
R -->|"标准正确"| A["Agent 真实质量问题"]
A --> AF["反馈 Agent 团队修复"]
淘宝原文里的四类典型坏 case，换到商家 Agent 语境下走一遍：
| 层 | 具体表现 | 该怎么修 |
|---|---|---|
| 数据层 | 工具返回里混进了接口内部提示词，Judge 误以为 Agent 答非所问 | 修数据清洗 SQL，剔除干扰信号 |
| Prompt 层 | 数据是对的，但 Judge 没见过「查无数据也算正确兜底」这类边界 case | 补 few-shot 示例 |
| Rubric 层 | 技术同学认为「如实说查不到」是对的，但 Rubric 写成了「没给出具体数据就判 0」 | 改 Rubric，并同步离在线快照 |
| Agent 真实质量问题 | 排除以上后，确实是 Agent 编造了不存在的「毛利率」 | 反馈 Agent 团队修复 |
关键警告：只走「评测说不行 → 改 Agent」这条路径，会把 Agent 优化成「迎合评测标准」而非「解决用户问题」。必须定期检查「是不是评测判错了」。
归因可以类比排查线上 bug：先看日志有没有脏（数据层），再看告警规则写没写错（Prompt 层），再看监控指标定义对不对（Rubric 层），最后才断定是服务本身挂了（Agent 层）。
6. LLM-as-a-Judge 工业化落地要点
LLM-as-a-Judge 就是让大模型当阅卷老师，按 Rubric 给 Agent 打分。学术验证已经较充分，但要在日均百万条会话、多域异构的线上场景里全量落地，公开讨论还很少。淘宝实践给出的关键约束是：评测可信度的瓶颈不在 Judge 模型本身，而在数据质量和评测标准的持续校准。
6.1 四层数据清洗 Pipeline
喂给 Judge 的数据不干净，Judge 再强也会误判。清洗 pipeline 按需演进，不是一次设计到位：
| 层 | 做什么 | 例子 |
|---|---|---|
| 格式修复 | 离在线字段对齐、超长截断 | 某域卡片文本长达数千字，拼接后超长导致推理超时 |
| 语义对齐 | 用户表达与系统状态映射 | 用户说「已揽收」，系统状态是英文枚举值，二者并不等于「已发货」 |
| 干扰屏蔽 | 剔除工具内部提示词 | tool_calls 里混着接口内部系统指令，会被 Judge 误读成 Agent 回复 |
| 过滤精化 | 按 skill 标识精确过滤 | 大量无关 query 被算进分母，把「评测方法问题」误判成「Agent 质量差」 |
实测：不做过滤精化，会把「评测方法问题」误判为「Agent 质量差」。
6.2 Rubric：统一框架 + 分域子项
CNT 六层漏斗像机场安检：先看有没有票（CTX），再看是不是走错航站楼（OOSR），再看有没有带违禁品（RED 独立检查）……
| 层 | 名称 | 职责 | 通俗理解 |
|---|---|---|---|
| CTX | 上下文门控 | 证据不足则 N/A | 「没看清卷子，不打分」 |
| OOSR | 越界拒答 | 不该由本 skill 承接时是否正确拒答 | 「这题不该我答，我转交」 |
| OOC | 能力边界诚实 | 超出能力时是否诚实说明 | 「我不会，但我不瞎编」 |
| TCC | 工具执行链路 | 工具、参数、链路是否正确 | 「用对了工具、传对了参数」 |
| CNT | 内容与文本 | 内容正确性、完整性、表达 | 「答案本身对不对」 |
| RED | 安全红线 | 五条红线独立核查 | 「安全题永不短路」 |
短路机制：串行层任一层判 0，则整体 0；但 RED 并联恒评，安全红线不被短路跳过。这样评测结果同时具备「主因定位」和「安全兜底」。
分域差异要注意边界：框架统一不等于 Rubric 统一。CNT 层子项按域定制。比如时效类域盯「有没有凭空说已签收」，检索类域盯「时间、商品、状态有没有召回对」。
用户型产品还有几项特有设计：
- 模式判定与诚实兜底放行（有数据 / 无数据，正确回答不同）
- 意图码驱动评测路径分流
- 数据盲区兜底（看不见的数据输出 N/A，严禁猜 0）
例如「查无结果且系统如实返回空态」时直接判通过，因为「查不到」本身就是正确答案。
版本化：Rubric 以 Markdown + YAML 存在代码仓库，带 changelog；Prompt 直接从 Rubric 文件生成，避免「文档一套、Prompt 一套」。
6.3 Prompt 工程：让 Judge 稳定可信
Judge 天然想「自由发挥」，Prompt 工程就是逼它「只按规则判卷」。
| 实践 | 作用 | 例子 |
|---|---|---|
| 锚定事实来源 | 压制幻觉 | 「仅基于输入判断，禁止外部知识」 |
| 反向验证 | 保证 grounded | 「先摘录原文再判断」 |
| 边界 case few-shot | 定义判定边界 | 给「用户问得模糊、Agent 答对一半」的标注示例 |
| 禁止推断 | 信息不足不硬猜 | 不足时输出「剔除」，而不是猜 0 或 1 |
| 时间锚点拼接 | 解决时间误判 | 注入提问时间戳，才能判断「明天」「近一年」 |
| 跨轮信息隔离 | 避免跨轮串扰 | 只传当条 tool_calls；上下文不是越多越好 |
| Temperature 约 0.1 | 稳定可复现 | 过高同一 case 多次结果不一致，设为 0 偶发输出僵死 |
| 解析三层兜底 | 防非标输出 | Prompt 约束 → 输出校验器 → 标签归一化 |
反直觉结论：把全对话工具链传给 Judge，会因跨轮串扰导致大量误判；只传当条后，通过率显著跃升。原因类似：卷面上印了前后几道题的答案，阅卷老师容易看串行。
6.4 多轮打标：逼近真实水位
打标闭环是：
抽样打标 → Judge-Human 一致性校验 → 归因 → 优化 Prompt / Rubric → 发车 → 重抽样
操作上注意三点：
- 纯随机采样（HASH%）保证无偏
- 用 CI 精度反推样本量：约 ±1pp 需要 4k，约 ±0.5pp 需要 15k
- 波动远超 CI 时，查 Rubric / 模型实质变化，而不是抽样噪声
目标不是「让通过率变高」，而是「让通过率更可信」。早期低通过率往往不是 Agent 真差，而是评测方法没调对。就像老师一开始评分标准没对齐，全班都低分；标准校准之后，每一次下降才指向真实能力问题。
7. 指标与归因产出
7.1 复合指标设计
复合指标要把链路拆开。例如淘宝定义的执行成功率：
执行成功率 = 路由准确率 × 回复正确率
三层漏斗：任何一层出问题都会拉低综合数字；拆开看才能定位。同样的拆法可以套到商家 Agent：「交付可用 PPT」约等于「数据取对了」×「PPT 生成对了」——这是为方便理解做的类比，不是原文给出的业务指标。
7.2 归因两层次
| 层次 | 做法 | 回答 |
|---|---|---|
| 宏观 | 按漏斗层 + 子项码拆解失败分布 | 低在哪一层、集中在哪些子项 |
| 微观 | SQL 可复跑的检测规则，修复前后分区对比命中数 | 修复是否生效、未收敛的进下一轮 |
微观核验可以想成「体检报告复查」：修完一个问题后，再跑同一套检测规则，看命中数有没有下降。
7.3 指标异动归因套路
骤跌不一定是能力回归。固定动作：
- 拆分子 / 分母趋势（分子平稳 + 分母暴涨，往往是分母被污染）
- 按子 label 拆解，定位异常抬升的来源
- 剔除不属于真实业务动作的 label 后复算
- 若跌幅消失，则是评测口径问题，不是线上 bug
真实案例（淘宝）：某域路由成功率骤跌，直觉像是 skill 能力回归。逐日拆分子分母后发现：分子平稳，分母两天内翻了几倍。进一步定位到某个 label 被上游意图模型误标，把大量使用类咨询塞进了分母。剔除后，跌幅全部消失。不做归因就会以为线上有个紧急 bug，其实只要从评测过滤条件里去掉一个 label。
8. 观测基建：看不见的问题修不掉
「看不见的问题，几乎不可能被稳定解决。」
公式：观测 + 评测 = 持续迭代（观测排第一）
Agent 的一次执行是一条长链路：用户输入 → 意图理解 → 任务规划 → 工具 / Skill 调用 → 环境交互 → 中间结果处理 → 策略调整 → 最终输出。任意一层出问题，最终效果都可能劣化。如果系统只看到「用户说了什么」和「最后回复了什么」，几乎无法定位根因。
这就像只看进菜和出菜，不看后厨——菜咸了不知道是盐放多了还是酱本身咸。
冷启动时的最小可归因底线：
- 完整的模型调用输入输出
- Skill 调用记录
- 能凭 Trace 复现一个 Bad Case 到底发生了什么
建设思路是需求反向设计：当发现「想自动化判断某件事，但数据里没有」，就该补埋点了。不必一开始就建完备系统。
9. 成熟度与演进路径
不要追求所有维度同时到顶。按阶段补短板：
| 阶段 | 优先动作 | 比喻 |
|---|---|---|
| 冷启动 | 观测 L1 + 评测集 L1 + 回测门禁 L1 | 先有体温计和病历本 |
| 扩量 | 评测标准 + 在线评测推到 L2，少量指标 L3 | 加上定期体检 |
| 全量运营 | L3 自动化与规模化（SFT 小 Judge、级联、Batch API） | 体检流水线化 |
| 自进化 | 坏样本回流训练、Release Gate、Drift 检测 | 指标异常自动挂号 |
最有价值的用法是看「短板」和「错配」：体系上限由最短的板决定。例如机评已经很精，但 Case 挖掘还靠用户投诉，投入就应转向补齐挖掘，而不是继续精修机评。
优先级判断（淘宝）：成本是入场券，精度是护城河，闭环是复利。
10. 可直接执行的 Checklist
10.1 评测体系
- 是否同时回答「好不好」和「哪里不好」？
- 离线评测是否固定了评测集与执行环境？是否接入发布流程？
- 是否同时有端到端评测集和过程评测集？
- Rubric 是否二元化、可回答是 / 否？
- 是否有黄金集（定义好的下限）+ 错题集（坑不二犯）？
- 四类 Case 来源是否都在用（尤其随机采样）？
- 归因是否能区分数据层、Prompt 层、Rubric 层、Agent 真实质量？
- Trace 能否复现 Bad Case？
10.2 在线 Judge
- 数据是否做了格式、语义、干扰、过滤四层清洗？
- 漏斗框架是否跨域统一？子项是否分域定制？
- Prompt 是否有：事实锚定、反向验证、禁止推断、时间锚点、跨轮隔离？
- 是否做过 Judge-Human 一致性校验？样本量是否按 CI 反推？
- 多轮打标目标是「更可信」而非「更高」？
- 指标异动是否先拆分子分母再下结论？
10.3 运行保障
- 数据与推理是否解耦（改 Prompt 不重跑数据逻辑）？
- 是否有输入输出条数 Check 节点？
- 超长 Prompt 是否预检 / 截断？回刷是否先清空分区？
- 是否按域独立 Workflow（避免短板效应与故障扩散）？
11. 一句话方法论
评测是精密量具：既要量得准（方差小），又要能定期校准（消除独裁者偏差）。
以「固定评测集回测」守住已知，以「在线评测 + 监控」发现未知，以「Case 挖掘 + 四层归因」定位分派，以「观测 Trace」托底。
两条 Loop 共享 Case 入口与评测集资产，持续把业务质量的隐性认知，转化为可量化、可复用、可自动执行的显性资产。
起步阶段让数据飞轮转起来，远大于设计一个复杂精妙的体系。
12. 参考资料
| 来源 | 链接 | 本文覆盖内容 |
|---|---|---|
| 美团技术团队《Agent 评测白皮书》系列 01：Agent 评测全览 | 微信公众号原文 | 四模块三能力两 Loop、离线门禁、在线评测与监控、Case 挖掘、观测基建、成熟度自查 |
| 大淘宝技术：淘宝 AI 购物助手在线评测落地实践 | 微信公众号原文 | LLM-as-a-Judge 日级工业化、四层数据清洗、CNT 六层漏斗、Prompt 工程、多轮打标与四层归因 |
如果你更关心 RAGAS、幻觉检测这类评估基础指标，可以继续阅读 速通 AI（九）：RAG 与 Agent 评估体系。本文更偏「体系怎么建、Judge 怎么工业化」，两篇合起来覆盖从指标到运营的完整链路。