> 本文基于阿里技术《Agent 评测：方法论与体系设计》整理，提炼核心方法论，转化为可直接执行的操作手册。
核心前提：为什么评测必须体系化
Agent 的本质问题是三道门槛：非确定性（同样输入不保证同样输出）、黑盒化（内部决策不透明）、错误级联放大（前一步小偏差会在后续放大）。
所以"跑几条 case 感觉还行"远远不够。你需要一套持续运转的评测体系，而不是上线前的人工抽查。
评测平台的核心价值：把问题稳定转化为可执行修复，形成持续迭代闭环。
---
STEP 1：先分类型，再定指标
不要用一套万能指标评所有 Agent——这是最常见的失败起点。
Agent 类型映射
| Agent 类型 | 核心评测侧重 | |------------|------------| | 对话型（客服/营销/导购） | 会话解决率、多轮上下文一致性、情绪识别 | | 任务执行型（代码/数据处理） | 任务完成率、工具调用正确率、结果可验证性 | | 推理决策型 | 推理链完整性、结论可靠性、不确定性识别 | | 多 Agent 协作型 | 子任务分配准确性、结果一致性、异常传播 |
对话 Agent 的特殊难点
对话评测不要只平均每轮分数。每轮都"答得还行"，但最终没解决用户问题，仍然是失败。
- 正确做法：同时看四个层次：
- Turn：单轮问答质量
- Session：整段会话是否解决了问题
- Trace：执行轨迹是否符合预期路径
- Outcome：最终业务结果（退款成功了吗？问题解决了吗？）
---
STEP 2：搭建指标体系
五大维度 × 三级优先级
- P0（上线门禁，不达标不能发）
- 安全合规：禁用动作触发率为 0
- 关键工具调用：核心业务工具调用准确率 ≥ 阈值
- 严重错误率：过度承诺、事实性错误 < 阈值
- P1（版本比较 & 工程优化）
- 任务完成率
- 意图识别准确率
- 工具参数正确率
- 多轮上下文保持率
- P2（体验改善 & 长期观察）
- 回复流畅度
- 用户满意度代理指标（转人工率、重复追问率）
- 响应延迟
一致性指标：生产系统最关心这个
同一任务需要跑多次，观察两类结果：
- 至少一次成功率：N 次中有一次成功 → 反映能力上限
- 连续成功率：N 次全部成功 → 反映稳定性，是生产系统真正需要的
> 用户不会接受"多试几次总有一次成功"。
版本对比的统计严谨性
- 版本 A → 版本 B，分数有变化，不代表真的变了。必须配套：
- 关键指标的置信区间
- 与基线的显著性检验（是真实提升还是随机波动？）
- 最小可感知变化阈值（提前定义"多少变化才值得发布"）
---
STEP 3：建设评测数据集
核心原则：评测集不是线上数据的随机抽样，而是围绕高风险路径设计的质量资产。
随机采样的问题：正常流程占大多数，边缘场景太少，报告"看起来不错"但关键问题被漏掉。
数据集的四类来源
| 来源 | 作用 | 优先级 | |------|------|--------| | 专家设计用例 | 定标准、覆盖高风险边界 | 最高，先做 50-200 条 Golden Set | | 扩展用例 | 扩覆盖，同场景不同表达 | 用规则定结构字段，LLM 生成自然语言变体 | | 线上真实数据 | 覆盖真实分布 | 定期回流，注意幸存者偏差 | | Badcase 回流 | 覆盖已知失败模式 | 持续补充 |
针对 Skill 的用例设计框架
- 按四类组织：
- 触发：该不该触发这个 Skill？
- 核心逻辑：触发后流程走对了吗？（通常用例最多，覆盖主要分支）
- 产物质量：最终产出好不好？
- 异常容错：输入异常、工具失败时能稳住吗？
样本治理
- 回归集不能无限膨胀：
- 同簇样本保留代表例
- P0/P1 风险长期保留
- 稳定多版本通过且风险低的降级为抽样集
---
STEP 4：评分策略
三层评分优先级
- 层级 1：规则 Scorer（最高优先级）
- 看"硬条件是否满足"：工具是否调用、状态是否正确、禁用动作是否触发
- 能写成代码的项，都由规则主判
- 层级 2：LLM-as-Judge
- 看"语义/策略是否合理"：解释质量、策略妥当性
- 好的 Judge 需要：明确评分标准（每档可执行）、输出 reason、few-shot 示例含边界样本、周期性校准（与人工一致率达 ~85%）
- 偏差治理：评测模型和生成模型是同系列时，可能有自我偏好。引入多个不同 LLM 对抗打分
- 层级 3：人工评分（兜底）
- 不适合日常全量打分
- 适合：新建评测集时定口径、校准 Judge、处理争议样本、高风险场景定期抽查
人工评分路由
- 以下情况自动路由到人工：
- Judge 分数在通过/不通过边界附近、置信度低
- 新模型/新 Prompt/新工具 Schema 上线的抽样观察期
- 规则与 Judge 结论冲突
分层筛查流程
粗筛层（规则 Scorer）→ 快速分流明显通过/失败/存疑
↓
精判层（完整规则 + LLM Judge）→ 确认 badcase，输出问题分类/现象/置信度/判定依据
↓
人工复核层 → 高风险、低置信、冲突样本终判评分输出标准
- 不要只输出 pass/fail，还要输出：
- 问题分类（现象层：事实性错误、答非所问、过度承诺）
- 问题现象（具体描述）
- 置信度
- 判定依据
这是第 5 步 Badcase 根因分析的输入——基于"现象入口"收敛候选模块，而不是无差别排查所有模块。
---
STEP 5：Badcase 根因分析（RCA）
目标：把错例稳定追到责任模块和可修复原因。
Badcase 来源不只是离线评测集，还有：线上会话、人工质检、投诉工单、低满意度样本、版本回归失败、监控告警。两条入口最终汇入同一个 badcase 任务表和同一套 RCA Pipeline。
五步 RCA 流程
第一步：证据汇总
- 按 sessionId / traceId 找到链路日志，汇总：
- 用户输入、Agent 回复
- 各模块的输入/输出、prompt
- 工具调用记录（入参、返回值、耗时、错误）
- 异常信息和中间产物
第二步：范围收敛
维护"问题现象 × 功能模块"映射表，避免无差别分析：
| 问题现象 | 优先排查模块 | |---------|------------| | 答非所问 | 意图识别、Query 改写、知识筛选 | | 过度承诺 | 风险拦截、回复生成 | | 事实性错误 | FAQ 检索、知识检索、回复生成 | | 工具参数错误 | Slot 抽取、工具 Schema 理解 | | 多轮上下文丢失 | 上下文管理、记忆模块 |
映射命中走确定性路径，未命中再让 LLM 兜底缩圈。
第三步：分模块诊断
- 对候选模块逐个读 input/output/prompt/工具返回，输出：
- 问题摘要
- 关键证据
- 改进建议
- 模块判定：PASS / SOFT_PASS / FAIL
第四步：责任判定
- 三层策略（不完全交给 LLM）：
- 严重模块结论直接定责
- 规则引擎匹配确定性模式
- LLM 汇总复杂链路的责任传递关系
输出：责任模块、问题分类（面向报告的大类）、问题枚举（细粒度失败类型）、修复建议。
第五步：结构化落盘
结构化写入任务记录，至少包括：问题分类、问题现象、问题枚举、责任层、责任模块、置信度、详细报告、修复建议。
支持 Badcase 聚类——报告不是列 100 条，而是："退款已发货场景中，Agent 23 次跳过订单状态校验，主要集中在 v1.8 Prompt"。
RCA 落地的执行顺序
- 规则定位硬错误（工具未调用、参数缺失、工具报错未重试）
- Trace Scorer 定位过程偏差（计划与目标不一致、工具返回被误读）
- 映射表缩小候选范围
- LLM 辅助语义归类和聚类（避免同类问题被拆成多个零散标签）
- 高风险/低置信/冲突样本进入人工复核，人工结论反向校准规则和 Judge
---
STEP 6：产出结构化优化建议
原则：建议要落到明确 owner、修复动作和回归验证，而不是"优化 Prompt""提升准确率"这类泛化表述。
标准行动项格式
- 每条优化建议至少包含：
- 失败范围：哪些用例、哪个场景
- 证据：支撑判断的关键 Trace/数据
- 具体动作：Prompt 修改？训练数据补充？工具调用逻辑调整？业务口径定义？
- Owner：运营可配置 / 算法需优化 / 工程需修复 / 业务需定口径
- 验收方式：回归用例通过率、人工确认
- 优先级：P0/P1/P2
四个优化等级
| 等级 | 触发条件 | 典型动作 | |------|---------|---------| | 紧急修复 | P0 风险触发，生产级问题 | 立即回滚或热修复 | | 迭代优化 | P1 问题，影响版本质量 | 当期 sprint 修复 | | 体验改善 | P2 问题，长尾场景 | 纳入下期迭代 | | 能力边界 | 当前模型能力上限 | 标记，等待模型升级后重评 |
---
STEP 7：全链路闭环
离线 → 线上联动
离线通过 ≠ 线上一定变好。
- 发布阶段跟踪三类信号：
- 离线质量信号：核心场景通过率、P0 风险数、关键工具参数正确率
- 线上体验信号：转人工率、重复追问率、投诉率、满意度
- 业务结果信号：任务完成率、工单闭环率
> 如果离线提升但线上关键信号恶化——触发回滚或降级！
Badcase → 研发资产
- 每条 Badcase 至少生产三类反馈：
- 回归用例：入库评测集，防止同类问题复发
- 训练数据：正负样本对，用于模型微调
- 配置/规则更新：Prompt 修改、业务规则补充、工具 Schema 调整
反馈入库标准（避免回归集无限膨胀）
- 满足以下条件再入库：
- 失败可复现，或有稳定 Trace + 人工确认
- 期望行为明确，可以写成规则或 Judge 标准
- 根因标签清楚，能归到具体能力域
- 样本有代表性（覆盖一类问题，不是一次性抖动）
- 已完成脱敏
评测平台最终沉淀的质量资产库
- 用例库
- Trace 库
- 根因标签库
- 修复建议库
- Judge 校准集
- 回归集
质量资产越厚，Agent 迭代越不需要靠个人经验和临时救火。
---
快速检查清单
上线前自查：
- [ ] 已区分 Agent 类型，针对性定义指标？
- [ ] Golden Set 覆盖了核心业务路径和高风险边界？
- [ ] P0 门禁指标已定义且有明确阈值？
- [ ] 连续成功率 > 至少一次成功率 → 稳定性是否达标？
- [ ] 版本对比做了统计检验，不只看单点分数？
- [ ] LLM Judge 校准过，与人工一致率 ~85%？
- [ ] Badcase 有结构化落盘，有明确 owner 和修复建议？
- [ ] 离线门禁和线上灰度联动，设置了回滚触发条件？
