01 为什么 Agent 评测需要体系化

划重点：Agent 评测是把「不稳定的智能行为」持续收敛成「可发布的工程质量」，不是上线前抽查。

和传统软件相比，Agent 的输入、输出和状态空间都更开放：用户表达不可穷举，模型输出有随机性，多轮对话会累积上下文，工具调用还会改变系统状态。也就是说，Agent 从 Demo 到生产可用，真正要跨过的是三道门槛：非确定性（同样输入不一定同样输出）、黑盒化（内部决策过程不透明）和错误级联放大（前一步小错会在后续被放大）。

所以，“跑几条 case 感觉还行”远远不够：

• 同一 Prompt 跑通一次，不代表稳定可用；
• 每次改模型、改 Prompt 或改工具参数，都可能把原来好用的场景改坏，而且不容易第一时间发现；
• 多步链路里前面一个小偏差，也可能在后面被放大成错误结论；
• 更隐蔽的是，有些样本最终答案看起来对，但执行路径已经偏离或带风险，这类假阳性（结果看起来通过、过程其实有问题）在生产里迟早会暴露。

评测体系必须嵌入研发流程，而不是上线前人工抽查。评测平台不只是“出分工具”，它的核心价值是把问题稳定转化为可执行修复，形成持续迭代闭环：

一套成熟的 Agent 评测体系至少要回答三类问题：

问题	典型回答	产出
能力水位	当前任务完成率、工具正确率、幻觉率、合规通过率是多少	基线分数和趋势
变更风险	新版本是否优于旧版本，哪些场景退化	回归报告和发布门禁
优化方向	失败集中在哪些能力域，应该由谁修、怎么修	根因聚类和行动项

02 Agent 类型与评测侧重

划重点：先分清 Agent 类型，再定义评测指标；类型不分，评测结果基本不可用。

Agent 的系统形态差异很大，不能用一套“万能指标”评所有系统。

Agent 类型	典型场景	评测重点	常见方法
知识问答型	FAQ、政策咨询、内部知识库	准确性、忠实性、引用溯源	RAG 指标、事实核验、人工抽检
任务执行型	退款、下单、预约、工单处理	工具选择、参数正确、状态变更	Trace 校验、数据库状态比对
推理决策型	故障诊断、方案推荐、数据分析	推理过程、证据链、结论可信度	轨迹评测、专家 Judge
多轮引导型	客服、销售、营销转化	记忆、澄清、推进、情绪承接	User Simulator、Session 级评测
创意生成型	文案、图片提示词、活动方案	相关性、风格、合规底线	模型评分、品牌表达标准
多 Agent 协作型	多角色复杂任务	路由、协同、交接、整体完成	子 Agent 评测 + 端到端评测

评测底层骨架可以复用：执行用例、采集 Trace（执行轨迹）、运行 Scorer（评分器）、生成报告、做根因归类。真正需要按业务定制的是“评什么”和“怎么判”。

除了按 Agent 类型设计评测体系，还需要关注 Agent 内部的能力单元。随着 Agent 越来越多地通过 Skill 完成工具调用、数据处理、报告生成和业务动作，Skill 本身也需要测评：它是否该触发、触发后是否走对流程、工具参数是否正确、最终产物是否可用、异常时是否能降级。本文会把 Skill 相关方法拆到指标、数据集、评分、归因和优化各章节中统一说明。

03 对话 Agent 的特殊性

划重点：对话 Agent 不能只看单轮答案，必须把整段会话是否解决问题作为主评判对象。

如果聚焦在“对话形态”的 Agent，客服、营销、导购、售后等系统往往同时包含知识问答、任务执行、推理决策和多轮引导能力，但只要它们通过多轮对话面向用户，就会额外面临上下文、目标切换、情绪回应和人工接管等评测问题。

对话 Agent 至少有五个特殊难点：

维度	核心问题	示例指标	优先级
功能正确性	做对了吗	任务完成率、答案准确率、工具调用准确率、参数正确率	P0
稳定性与安全	会不会闯祸	幻觉率、越界承诺、隐私泄露、拒答正确率	P0
过程质量	路径合理吗	计划质量、工具顺序、重试次数、无效步骤占比	P1
效率与成本	划算吗	平均轮次、耗时、token 成本、工具调用次数	P1
体验与对齐	用户感受好吗	语气自然度、情绪承接、品牌风格、满意度	P2

对话评测不要只平均每轮分数。一段会话每轮都“答得还行”，但最终没有解决用户问题，仍然是失败。正确做法是同时看历史 Turn（单轮）、Session（整段会话）、Trace（执行轨迹）、Outcome（最终结果）四个层次。

04 指标体系

划重点：指标体系不止用于打分，更用于驱动可落地、可验证的持续优化。

Agent 评测要从“感觉好不好”变成“可量化、可比较、可回归”，关键抓手就是指标体系。指标的作用，是把业务目标和专家经验拆成可观察、可打分、可追踪的检查项，让每次评测不只给分，还能明确好在哪、差在哪、下一步该改什么。

Agent 评测指标建议分成五大类。P0 指标用于上线门禁（不达标不能发），P1 指标用于版本比较和工程优化，P2 指标用于体验改善和长期观察。

难点	表现	示例	评测解法
上下文依赖	单轮看没问题，整段看像失忆	用户先问“成人票多少钱”，下一轮问“那小孩呢”	Session 级指标，检查知识保留和指代消解
目标动态变化	用户中途改需求、插入新问题、拒绝原方案	用户先问“推荐一双跑鞋”，中途改问“我上个订单怎么还没发货”	构造目标切换用例，评估 Agent 能否及时切回新任务，并避免继续执行旧任务相关动作
业务流程约束	要按 SOP、政策、合规话术推进	退款前必须先查订单状态，不能直接承诺“一定能退”	将 SOP（标准作业流程）转成可检查的 workflow（流程）或状态机
情绪与体验	客诉、催促、质疑时不能机械回答	用户说“你们怎么又延迟”，Agent 需要先安抚再解释	制定情绪回应评分标准，检查 Agent 是否先安抚、再解释或处理，并用人工抽样校准
人机协同	需不需要人工接管	用户投诉升级或涉及赔付，Agent 应转人工并带上问题摘要	转人工触发率、时机、交接摘要准确率

如果系统大量依赖 Skill，可以在上述五大维度下再补一组 Skill 子指标：

Skill 子指标	对应风险
Trigger Precision / Recall（触发准确率/召回率）	误触发或漏触发，导致流程错起点
参数正确率	关键槽位缺失、工具调用无效
必须步骤通过率	关键前置校验被跳过
禁止动作违规率	提前执行高风险动作或越界承诺
异常容错通过率	工具失败后无降级或出现编造
产物可用率	输出不可被下游系统或人工接续消费

对于任务执行型，以及客服、营销、导购、售后这类对话型 Agent，要特别重视“多次运行的一致性”。同一个任务建议重复运行多次，观察两类结果：

• 至少一次成功率：同一个任务跑 N 次，只要有一次成功，就说明 Agent 具备完成这个任务的可能性，适合观察能力上限；
• 连续成功率：同一个任务跑 N 次，必须每次都成功，才说明 Agent 稳定可靠，适合客服、支付、退款、合规等生产级场景。

生产系统更关心“连续成功率”。因为用户不会接受“多试几次总有一次成功”，他们需要的是每次都稳定完成。

在版本对比场景里，至少一次成功率和连续成功率还需要配套统计检验，避免把随机波动误判为能力变化。建议在报告中同时给出：

• 关键指标的置信区间：说明结果的稳定范围，避免只看单点分数；
• 与基线版本的显著性判断：判断差异是“真实提升/下降”还是随机波动；
• 最小可感知变化阈值：提前定义“至少提升（或下降）多少才算值得做发布判断”。

简单说，门禁不只看“差了多少”，还要看“这个差异是否超过统计噪声”。

05 评测数据集建设

划重点：评测集并非线上数据的随机抽样，是围绕高风险路径、关键逻辑和失败模式设计出来的质量资产。

评测集不能只靠随机抽样线上数据。线上样本往往有明显幸存者偏差：正常流程占大多数，真正会让 Agent 出错的边缘场景占比很低。只做随机采样，报告通常“看起来不错”，但关键问题会被漏掉。

本文中的“黄金评测集（Golden Set）”默认作为“基线评测集”使用（一组相对稳定、长期复用的核心样本），主要用于版本对比和发布门禁。

推荐的数据集建设路径：

评测集至少包括四类来源：

来源	说明	价值	注意点
专家设计用例	由业务、质检、算法或工程专家定义核心场景、期望行为和判分标准	锚定业务共识，作为评测基准	数量不必大，但要覆盖关键流程和高风险边界
扩展用例	基于专家设计用例、业务规则或场景模板，扩展不同说法、边界条件和异常组合	扩大覆盖面，补齐长尾、异常、对抗场景	不直接创造判分标准，结构字段用规则，语言表达用 LLM
线上真实数据	从真实用户对话、工单、告警或执行记录中抽取样本	贴近真实分布	按业务场景和风险类型分类抽样，不能纯随机
badcase 回流	将线上失败、人工质检发现的问题或告警样本回收成评测用例	最贴近真实失败	要沉淀失败原因和修复状态

• 专家设计用例负责“定标准”，扩展用例负责“扩覆盖”。扩展用例不应脱离专家用例和业务规则自由生成，建议先用规则确定场景类型、订单状态、用户诉求、期望动作等结构字段，再用 LLM 生成更接近真实用户的自然语言表达。
• 先做 50-200 条高质量 golden set，覆盖核心业务路径和高风险边界；成熟后再扩展到分类采样集、长尾集、对抗集、线上回流集。
• 对包含 Skill 的 Agent，用例设计可沿“触发、核心逻辑、产物质量、异常容错”四类组织：
  • 先确认该不该触发 -> 再确认触发后过程对不对 -> 再检查最终产物好不好 -> 最后验证异常输入、工具失败、边界条件下能不能稳住。
  • 核心逻辑用例通常最多，应该覆盖主要分支路径和高风险分支。
• 示例
  • 专家设计用例可以是“用户要求退款但订单已发货，Agent 必须先查订单状态再解释规则”；
  • 扩展用例可以是在同一退款场景下生成不同用户说法、不同订单状态和不同情绪强度；
  • 线上真实数据可以来自真实客服会话或工单记录；
  • badcase 回流可以来自“Agent 直接承诺一定退款成功”这类线上 Badcase。

06 评分

划重点：可以用规则来主判打分，LLM Judge 主要用于语义和策略这类非确定性维度。

评分器可以分三类，优先级从高到低：

Scorer 类型	适用场景	样例	优点	风险
代码/规则 Scorer	明确的结构、字段存在、数值一致、工具状态、敏感词	检查是否调用查订单工具、回复是否包含禁用承诺	稳定、便宜、可复现	覆盖不了复杂语义
LLM-as-Judge	相关性、完整性、情绪承接、策略合理性、事实忠实性	判断回复是否充分解释退款规则、是否先安抚用户情绪、是否忠实于知识库	可扩展，接近专家判断	有偏差、会漂移、需校准
Human Scorer	业务口径未固化、高风险样本、争议 case、Judge 抽检与校准	订单同时命中大促价保、平台券、商家券和会员特批规则，Agent 建议补偿 20 元券，需要业务专家判断是否符合当期补偿口径	最接近业务共识	成本高、规模小，一致性也需管理

1. 整体原则是：

   1. 规则看“硬条件是否满足”（工具、状态、字段、禁用动作），LLM 看“语义/策略是否合理”（解释质量、策略妥当性等）；
   2. 能写成代码的项由规则主判；
   3. 在高风险、抽检、低置信或变更观察期样本上，可以追加 LLM-as-Judge；
   4. 能由规则和 Judge 稳定判断的，不长期依赖人工；人工主要用于确认业务标准、处理冲突和高风险终判。

2. LLM-as-Judge 不能只写“请从 1 到 5 打分”，好的 Judge 至少需要：

   1. 明确评分标准，每个分档有可执行标准；
   2. 输出 reason，方便定位和后续 badcase 聚类；
   3. few-shot 示例，尤其要包含边界样本和判定的 COT 逻辑；
   4. 周期性校准，Judge 与人工复核一致率达到约 85% (参考值)后再进入日常自动化；
   5. 偏差治理（如：评测模型和生成答案的模型是同一个或同系列，它可能更喜欢自己风格的回答），可以引入多个不同的 LLM 进行对抗打分评测。

3. 人工评分不适合承担日常全量打分，更适合用在以下几个环节：

   1. 新建评测集时，确认样本的期望行为和打分标准。例如订单已发货、用户拒收、商家参与运费险且商品属于特殊类目时，Agent 应该解释退款路径、建议拒收、转人工，还是先发起售后单，需要业务先定口径；
   2. 校准 LLM-as-Judge，抽取一批样本由人工先判。例如 Judge 能判断回复是否礼貌、是否解释清楚，但无法可靠判断“叠加优惠后的差价是否应该补偿”这类依赖内部政策和实时活动规则的问题；
   3. 处理争议样本；
   4. 抽查高风险场景。例如赔付、隐私、合规、投诉升级等样本，即使自动评分通过，也要定期人工复核。

4. 是否进入人工评分不应只由 LLM Judge 的分数阈值决定，而应做成“人工评分路由”：

   1. 自动评分不确定时进入人工，例如 Judge 分数落在通过/不通过边界附近、置信度低、reason 含糊，或多个 Judge 结论分歧明显；
   2. 新模型、新 Prompt、新工具 Schema（字段结构与校验规则）、新业务活动上线时，抽样进入人工，用于发现自动评分盲区并校准 Judge；
   3. 规则与 LLM-as-Judge 结论冲突时进入人工，由人工做终判和口径回收。

5. 对于 Skill 密集型任务，可以针对 Skill 做专项评测，避免只看端到端结果。这里的 Skill 检查项用于“判分与分流”，不用于“归因与定责”；归因和责任判定统一放到第 7 章的 badcase 分析阶段：

Skill 检查项	典型场景
触发准确性	该触发不触发 / 不该触发却触发
参数正确性	订单号、身份、上下文字段抽取缺失
关键路径合规	必须步骤缺失、顺序错误
禁止动作约束	提前执行高风险动作、越界承诺
异常容错能力	工具失败后编造、无降级策略
产物可用性	输出结构不完整、下游不可消费

6. 持续评测，可以维护一套 Judge 金标校准集，并在每次 Judge Prompt/模型版本升级时固定产出三类统计指标：

   1. 与人工标注一致性（例如和人工标注的一致率或多个大模型对抗打分的一致性 -> Kappa 系数）；
   2. 高风险样本漏判率（尤其是合规、资损、隐私场景）；
   3. 边界样本稳定性（同批样本重复评测时的波动幅度）。

7. 在评分的实际执行阶段，可以采用“分层筛查”识别 badcase，并控制进入 RCA 的样本质量：先用低成本、确定性强的能力快速分流，再对疑似样本做更完整的语义和策略判断，最后把高风险、低置信或冲突样本交给人工终判。

评分结果不应只输出 pass/fail，还应输出初始问题分类、问题现象、置信度和判定依据。这样第 7 章做根因定位时，才能基于“现象入口”收敛候选模块，而不是对所有模块无差别排查。这里的问题分类是现象层分类，例如“事实性错误”“答非所问”“过度承诺”，不等同于最终根因或责任模块。

1. 粗筛层主要使用规则 Scorer，必要时配合轻量级 LLM-as-Judge，用于快速识别明显通过、明显失败和存疑样本；
2. 精判层使用完整规则和 LLM-as-Judge，加载更完整的评分标准，确认样本是否为 badcase，并产出初始问题分类、问题现象、置信度和判定依据；
3. 人工复核层使用 Human Scorer，处理高风险、低置信、规则与 Judge 结论冲突、业务口径未固化的样本。

对结果假阳性 case（最终回复看起来正确，但执行路径或风险检查不通过）可增加过程型和风险型检查：

检查类型	检查内容	示例
必要路径检查	必须调用的工具、必须经过的步骤是否出现	退款结论前必须调用 order.query
禁止路径检查	禁止提前执行的动作、禁止话术是否出现	未确认订单状态前调用 refund.create，或承诺“一定退款”
证据一致性检查	最终回复是否有 Trace 证据支持	回复说“订单已发货”，但 Trace 中没有订单查询结果
风险信号检查	是否出现高风险动作、敏感承诺、隐私暴露或接管缺失	投诉升级未转人工，赔付场景未进入人工复核

综上，除了输出分值、pass/fail，评分结还应输出问题分类（可以提前由产品、业务、研发协商定义出来）、问题现象、置信度和判定依据。这样第 7 章做根因定位时，才能基于“现象入口”收敛候选模块，而不是对所有模块无差别排查。这里的问题分类是现象层分类，例如“事实性错误”“答非所问”“过度承诺”，不等同于最终根因或责任模块。

07 Badcase 分析与根因定位

划重点：Badcase 根因定位的核心是把错例稳定追到责任模块和可修复原因。

Tips：Badcase 不只来自离线评测集，也来自线上会话、人工质检、投诉工单、低满意度样本、版本回归失败和监控告警（可以作为评测集的补充）。在进入根因定位前，我们把入口统一为两条通路：

入口	说明	进入根因分析的条件
智能发现驱动	对线上会话或评测输出做自动质量检测，确认问题后直接创建 badcase	LLM/规则判定为明确 badcase，且置信度达到阈值
直接提交	运营、质检、研发、外部系统手动提交问题样本（常规评测集的补充）	提交时带上会话、问题描述、问题分类或问题现象

这两条链路最终应汇入同一个 badcase 任务表和同一套根因分析 Pipeline（处理流水线），这样既能覆盖线上长尾，也能支持运营和研发主动排查。

根因定位要判断「哪里出问题了」。端到端失败通常只是表象，真正原因可能来自用户意图识别、上下文记忆、检索召回、工具选择、参数构造、业务规则理解、模型推理、回复生成、Guardrail（安全护栏）拦截或外部系统异常等等诸多环节。

Badcase RCA（根因分析）可以用一个“先收集证据、再收敛范围、最后定责落盘”的通用链路来表达：

第一步是证据汇总。可以按 sessionId、chatId、traceId 或评测运行 ID 找到对应链路日志，汇总用户输入、Agent 回复、功能模块输入输出、prompt、工具调用、异常、耗时和中间产物。状态以持久化任务记录为准，运行时工作区保存中间产物，便于异步执行、轮询查询和失败恢复。

第二步是范围收敛。不要对全部功能模块无差别分析，否则成本高、噪声大、结论也容易散。更好的方式是维护“问题现象 × 功能模块”的映射。例如“答非所问”优先看意图识别、Query 改写、知识筛选；“过度承诺”优先看风险拦截和回复生成；“订单未澄清”优先看槽位抽取和上下文判断。映射命中走确定性路径，未命中再让 LLM 做兜底缩圈。示例如下：

问题分类	问题现象	优先候选模块	典型判断依据
沟通表达	答非所问	意图识别、Query 改写、知识筛选	用户问题明确，但 Agent 回复偏题或继续处理旧问题
标的物定位	订单未澄清	槽位抽取、上下文判断、范式定位	需要订单号、商品、物流单号时，Agent 没有追问或绑定错对象
业务解答	事实性错误	FAQ 检索、FAQ 精排、知识筛选、回复生成	知识库或工具结果中有正确信息，但最终回复给出错误事实
超出范围	过度承诺	输出质检、风险识别、回复生成	Agent 承诺超出权限或业务规则的结果

这张表只用于缩小候选范围，不直接等同于最终定责。最终责任仍要结合 Trace、模块输入输出、工具返回和规则/Judge 结论确认（见第六章的输出结果）。

第三步是分模块诊断。对候选模块逐个读取 input、output、prompt、工具返回和异常日志，输出要有问题摘要、关键证据、改进建议和可归因的结构化字段。

举例：一条 Badcase 的问题现象是“事实性错误”，优先排查 FAQ 检索、知识检索和回复生成。分模块诊断时可以先看 FAQ 检索是否召回正确政策，再看知识检索是否保留关键片段，最后看回复生成是否忠实使用这些证据。如果前两段都通过但最终回复仍说错，就可以把回复生成标为 FAIL，并把前两个模块标为 PASS 或 SOFT_PASS（基本通过但有轻微瑕疵）。

第四步是责任判定。该阶段消费“问题现象 + 分模块诊断结果 + 根因知识库”，输出责任模块、问题分类、问题枚举和修复建议。

• 这里的问题分类是面向报告和看板的问题大类，比如语义理解、知识召回、工具执行、风险防控；
• 问题枚举则是更细的失败类型。做法是可以不是完全交给 LLM，而是三层策略：先用严重模块结论直接定责，再用规则引擎匹配确定性模式，最后用 LLM 汇总复杂链路中的责任传递关系。这样既保留确定性，又能处理多模块耦合问题。

举例：上面的“事实性错误”样本中，分模块诊断显示 FAQ 检索和知识筛选都通过，只有回复生成把正确业务政策解释错。责任判定阶段就可以把主责落到回复生成模块，问题分类归为“模型指令遵循”，问题枚举归为“证据使用错误”，修复建议则指向回复生成 Prompt、引用约束或忠实性校验。

第五步是结构化落盘与查询。根因结果不要只存在一次性报告里，而应结构化写入任务记录，至少包括问题分类、问题现象、问题枚举、责任层、责任模块、置信度、详细报告和修复建议。前端或看板可渐进展示：范围收敛后展示候选列表，分模块诊断后展示逐模块结论，责任判定完成后展示主责、次责和建议动作。

工程实现上，可以把单次 badcase 分析建模成一个异步 Multi-Agent Workflow（第六章的评分能力也可以是 Multi-Agent 形式），例如：

阶段	核心职责	关键输出
上下文构建	查询 Trace、日志、工具调用和模块输入输出	Badcase上下文、模块执行日志
范围收敛	基于问题现象映射表或 LLM 缩小分析范围	关联的候选功能模块、问题现象
分模块诊断	对候选模块逐个用 Skill + Judge 评估	问题模块、明细原因
责任判定	结合规则、模块结论和根因知识库定责	主责模块、次责模块、问题分类、问题枚举

可以把每条 Badcase 拆成三层归因：

层级	归因问题	示例
现象层	用户看到的失败是什么	答案错误、未完成任务、越界承诺、转人工过晚
过程层	Trace 中哪一步先偏离	未检索知识库、选错工具、参数缺字段、忽略工具返回
责任层	应该落到哪个模块、能力或 owner	Prompt、模型、RAG、工具 Schema、业务规则、流程配置、产品策略

而 Skill 相关问题可以进一步快速分流，避免归因时反复拉扯：

失败现象	优先判断路径
Agent 没调用 Skill	看 Agent 路由、意图识别和触发策略
Agent 调用了错误 Skill	看 Skill 选择和任务分类
Skill 被正确调用但结果错	看 Skill 自身逻辑、工具和产物质量
Skill 输出对但 Agent 解释错	看 Agent 对 Skill 结果消费、摘要和回复生成
单个 Skill 都对但整体失败	看 Agent 编排、多 Skill 依赖和会话状态管理

另外，RCA 在落地时，也可以参考第六章的评分逻辑，按「确定性优先、模型辅助、人审兜底」的方式实现：

1. 先用规则定位硬错误。例如工具未调用、调用顺序违反 SOP、参数缺失、工具报错未重试、数据库状态未变化、引用来源不存在；
2. 再用 Trace Scorer 定位过程偏差。例如计划与目标不一致、检索证据不足、工具返回被误读、多轮上下文被覆盖；
3. 然后用映射表缩小候选范围。例如问题现象已知为“事实性错误”，优先检查 FAQ 精排、FAQ 检索、文档召回、知识筛选和生成模块；
4. 最后用 LLM 辅助语义归类和聚类。例如将“解释不完整”“业务口径理解错”“用户意图澄清不足”这类自然语言描述，映射到既有的问题分类和问题枚举，避免同类问题被拆成多个零散标签；
5. 对高风险、低置信或规则与 Judge 冲突的样本进入人工复核，人工结论反向校准规则、Judge Prompt 和根因标签体系。

根因标签要稳定、可统计，并能指向明确 owner 和处理动作，方便后续进入工单流转。一个根因标签体系（供参考）可以从以下几类开始：

根因类型	判断依据	常见修复方向
Intent 识别错误	用户目标、槽位、约束识别错	补意图样本、改澄清策略、优化 Prompt
Context 记忆错误	多轮指代、历史偏好、前序结论丢失	改记忆摘要逻辑、上下文选择逻辑、会话状态管理
Retrieval 召回不足	没召回正确知识或引用无关内容	补知识库、改知识、改分片逻辑、改召回/重排逻辑
Tool 选择错误	没调用工具、选错工具、重复无效调用	改工具描述、Schema、调用策略
Tool 参数错误	参数缺失、格式错、状态未校验	强化参数校验、补槽位、加前置检查
Reasoning 错误	证据存在但推理链断裂或误读	改推理 Prompt、增加中间校验
Policy/SOP 错误	违反业务流程、合规或接管规则	更新流程配置、规则 Scorer、接管策略
Response 生成问题	结论对但表达不完整、不清晰、不安抚	调整回复模板、风格约束、体验指标
System 异常	外部 API、权限、超时、环境导致失败	修工具稳定性、降级策略、监控告警

站在每个问题枚举的角度，是可以绑定解决角色，例如运营可配置、算法需优化、工程需修复、业务需定口径。例如用户申请已发货订单退款时，Agent 没有先查询订单状态就直接承诺“可以退款”。这条 Badcase 可以归到“工具覆盖与执行”，问题枚举是“关键工具未调用”，责任模块是退款 Skill / 退款流程执行模块。

站在评测整体的角度，可以支持 Badcase 的聚类：同一根因、同一业务场景、同一工具或同一知识点的失败应该自动聚成问题簇。这样报告里不只是列出 100 条 Badcase，而是产出“退款已发货场景中，Agent 23 次跳过订单状态校验，主要集中在 v1.8 Prompt”的问题簇。

08 自动优化建议产出

划重点：优化建议要落到明确 owner、修复动作和回归验证，不能只停留在报告结论里。

完成根因定位后，下一步就是把“原因”翻译成“动作”。建议项不能只停留在“优化 Prompt”“加强训练”“提升准确率”这类泛化表述，而要明确失败范围、证据、具体动作、owner、验收方式和优先级。

工程化落地时，不应只生成自然语言结论，要产出结构化行动项。行动项要能被工单系统、看板、配置平台和研发流水线直接消费。换句话说，建议是质量工程里的标准任务对象。

继续使用第 7 章“已发货退款未查订单状态”的例子，可以把“为什么这么建议”展开成一条证据链：

根因归属	优化手段
Prompt/策略	修改系统 Prompt、工具选择说明、思考步骤约束、拒答和接管策略
RAG/知识	补知识、更新文档、改 chunk、改召回重排、增加引用校验
工具/API	优化工具描述、参数 Schema、错误码、幂等、超时和降级
业务流程	将 SOP 显式化为状态机、规则、工作流或可校验节点
产品交互	增加澄清入口、确认步骤、人工接管、风险提示
模型能力	换模型、蒸馏/微调、增加 few-shot、拆分复杂任务

这条证据链落到标准行动项里，可以写成：

字段	说明	示例
问题摘要	用业务语言描述失败模式	已发货退款场景中，Agent 未先查订单状态就承诺退款
影响范围	关联场景、样本数、失败率、风险等级	售后退款 / 18 条失败 / P0 资损风险
根因判断	归因到能力域和组件	退款 Skill / 退款流程步骤约束缺失，导致关键工具未调用
证据	关键 Trace、工具调用、Judge reason	Trace 显示未调用 order.query，回复含“一定可以退”
建议动作	可执行修复方案	修改退款 Skill / 退款流程的步骤描述，要求先查询订单状态，再根据状态解释退款路径或转人工
owner	应由谁处理	Skill owner + Prompt owner
验收标准	修复后怎么判断有效	回归集中同类 case 通过率 100%，越界承诺率为 0
优先级	按风险和规模排序	P0

不同根因对应的优化手段也应该区分处理（仅供参考）：

等级	说明	适用场景
L0 只报告	只输出问题和证据	归因低置信、业务口径不明确
L1 生成工单	自动带上样本、Trace、owner 和验收标准	通用
L2 生成配置建议	给出可审阅的规则、知识、Prompt 或阈值变更	运营可配置、风险较低的问题
L3 自动修复候选 PR	自动生成代码或配置 PR，但仍需人审和回归（RCA 可以结合代码分支深入分析）	明确的 Schema 校验、规则补充、测试用例补充

甚至可以分成四个等级：

反馈产物	用途	生产方式
回归用例	防止同类问题再次出现	从 badcase 抽取输入、期望动作、评分规则和根因标签
Prompt/工具改进建议	修复当前 Agent 行为	基于根因生成可审阅 diff（修改对比）或修改说明
业务规则/知识库修订	修正事实、政策和流程源头	生成知识缺口、冲突规则、过期内容清单

09 全链路闭环：从 Bug 到生产反馈

划重点：评测平台的终点不是报告，而是把线上失败持续转化为可复用的研发资产。

第 7、8 章分别解决“为什么错”和“怎么修”，第 9 章要解决的是“如何持续运转”。一套完整评测系统不能停在报告和建议上，还要把 Badcase 变成 bug、工单、配置变更、知识库修订、训练数据和回归用例，并在每个版本周期里持续运行。

一个完整的 Agent 评测平台通常包含九个能力模块：

离线评测通过不等于线上一定变好。发布阶段建议把离线门禁和线上灰度联动，至少跟踪三类信号：

• 离线质量信号：核心场景通过率、P0 风险数、关键工具参数正确率；
• 线上体验信号：转人工率、重复追问率、投诉率、满意度变化；
• 业务结果信号：任务完成率、工单闭环率、退款/赔付成功率等。

如果离线提升但线上关键信号恶化，应该触发回滚或降级！

工程化时要把 Trace 输出当作被测 Agent 的标准能力，而不是事后补救。Trace 至少需要稳定记录工具名、入参、返回值、时间戳、耗时和错误；复杂 Agent 还应记录计划、检索、Guardrail 等。评测执行环境也要隔离，避免多个用例共享状态导致分数不可复现。

反馈生产是评测闭环里最容易被低估的一环。发现问题本身不会自动带来收益，只有把问题沉淀成可复用资产，下一轮迭代成本才会下降。

反馈生产要把“线上失败”变成“研发资产”。一个成熟闭环通常长这样：

一条 Badcase 至少可以生产 3 类反馈：

生产线	产物	目标
评测生产线	golden case、regression case、对抗 case 等	防止问题复发，扩大覆盖面
运营生产线	知识缺口、SOP 缺口、规则缺口、转人工配置缺口	修正业务源头和流程配置
模型生产线（视情况而定）	偏好数据、SFT（监督微调）样本、DPO/IPO（偏好优化）对比样本、工具调用轨迹样本	提升模型和策略能力

更进一步，平台可以把反馈分成三条生产线：

难点	常见误区	推荐解法
指标不可解释	只给综合分 78	每个指标只测一件事，并绑定可行动原因
线上抽样失真	随机抽 1000 条日志	按业务语义、风险、轮次、渠道分
合成数据太完美	让 LLM 随便生成对话	规则生成结构，Persona 生成表达噪声
Judge 漂移	Prompt 写完长期不动	金标集校准、周抽检、版本化 Judge Prompt
端到端无法归因	只看成功/失败	采集 Trace，按组件和步骤打分
非确定输出难比较	期待完全一致答案	评底线、目标完成和约束满足，不评唯一最优
成本太高	所有 case 都 LLM Judge	P0 规则化，抽样 Judge，高风险人工复核
组织协同困难	评测团队单独定标准	业务、算法、工程、质检共同维护评分标准。有时候‘人’的问题，才是最大的问题。

反馈生产要有“入库标准”，不能把所有失败都无差别塞进回归集。建议满足以下条件再入库：

1. 失败可复现，或至少有稳定 Trace 和人工确认；
2. 期望行为明确，可以写成规则、Judge 标准或人工验收标准；
3. 根因标签清楚，能归到具体能力域或业务流程；
4. 样本有代表性，能覆盖一类问题，而不是一次性环境抖动；
5. 已完成脱敏，符合隐私和数据合规要求。

为了避免回归集无限膨胀，还需要做样本治理：同簇样本保留代表例，关键 P0/P1 风险长期保留，已稳定多版本通过且风险低的样本可以降级为抽样集；线上新分布出现时，通过主动学习优先抽取低置信、高影响、新意图、新工具和新知识点样本进入人工确认。

最终，评测平台要沉淀的是一套可复用的质量资产库：用例库、Trace 库、根因标签库、修复建议库、Judge 校准集和回归集。质量资产越厚，Agent 迭代越不会靠个人经验和临时救火。

10 难点与解法

划重点：评测体系的成败，取决于它能否在跨团队协作中长期、稳定地产生可执行行动项。

推导环节	示例内容
用户输入	“我这个订单已经发货了，现在不想要了，能不能直接退款？”
过程数据	意图识别为 refund_request，槽位里有 orderId，但 Trace 中 toolCalls=[]，没有调用 order.query 或售后规则查询工具
Agent 回复	“可以的，我会帮你申请退款。”
期望流程约束	退款结论必须基于订单状态；已发货订单需要先确认是否签收、是否支持拒收、是否需要走售后或人工
诊断结论	意图识别 PASS，槽位抽取 PASS，退款Skill1 执行 FAIL：有订单号却跳过订单查询，直接进入回复生成
根因判断	不是知识库缺失，也不是回复语气问题，而是退款 Skill / 退款流程的步骤描述缺少硬约束，导致没有落实“先查订单状态再给退款结论”的前置动作
行动项草案	修改退款 Skill / 退款流程的步骤描述，明确“退款意图 + 已有订单号”时必须先调用订单查询工具，再根据订单状态决定回复路径

评测体系必须把低分稳定转成行动项，否则再精细的分数也只是报表。