第 22 章 · Agent 优化：Badcase

核心观点 + 逻辑框架（调优篇 · 评估发现问题，实验验证改进：同一批题验证修改是否有效）

原书章节 ↗

▍速览

一句话版（开场，约 20 秒）

评估检查已经发生的执行，实验让修改后的 Agent 重新回答并产生新的输出和轨迹。流程是：先选一个业务问题做出能用的评估器，用真实样本试评再跑第一批历史评估，从结果里选出值得修复的 Badcase，把确认的问题配成实验评估新答案，把企业自己的 Agent 接进来跑通，对比同一道题的前后差异决定是否采用，最后把评估沉淀成可重复的检查让下一轮修改继续使用。

一段话版（完整表达，约 90 秒）

第一次建评估不必覆盖所有业务：先选"回答了概念却没解决用户问题"这类投诉，拿几条专家认可和明显有缺陷的回答讨论差别。通用标准可要求评估器检查三件事——是否回应了实际问题、关键说法是否有材料支持、操作任务是否给了足以继续执行的步骤；涉及退款、权限变更再加业务结果检查，避免只评价回复是否礼貌。评估方式按问题选：格式与必填字段用 Code 规则，切题与遗漏用 LLM 评估，多步骤与工具一致性用 Agent 评估结合轨迹；可以一个任务多个评估器分别评"回答质量"与"业务操作完成"，总分要明确计算方式，不能简单平均。试评阶段：先选对数据和范围（轨迹或 Dataset，多轮要配对话结束判断），采样限制的是候选量不是 Badcase 数，字段映射把问题/回答/轨迹接对——需要"最终回答"的位置不能误接某次工具输出；运行测试至少覆盖一条好回答、一条坏回答、一条信息不完整的样本，坏回答得高分先看收到的输入再查评分条款，调完重评确认好回答没被误判。第一批历史评估结束后，看低分要带上任务和时间范围避免混比，一条结果至少把原始问题、回答、分项判断和解释放一起读，不要看到低分立即改 Prompt；同一种遗漏选代表性几条，同时保留边界场景和正常任务验证退化，人工发现评估器误判的样本留作校准材料，高分也要抽检。确认的问题配成实验：先记录 Baseline，第一轮只改最有依据的一项（同时换模型改 Prompt 添 Skill，分数变化就难以解释）；实验被评分的必须是本次新生成的回答和新轨迹，变量映射参考字段与 rubric；正式比较用独立黄金 Dataset 最新数据，实验期间不写入，同步记录评分标准、版本、Prompt 和关键参数。企业 Agent 接入：在能调用内网服务的环境执行题目，适配会话状态为"创建 Session → 发问题 → 取最终响应"，受理成功不等于题目完成，独立样本用独立会话，先单题测试再跑小批，把连接适配问题和回答质量问题分开定位。对比先确认同一批题同一版标准，从退化题开始读，再看改善题和关键正常场景；输出变长不代表改善；候选总分高但关键条款未过不升级，只有一题改善而其他退化说明把某种回答格式强加给了所有问题；决定采用至少看三件事：严重错误是否消失、正常场景是否退化、耗时与消耗是否可接受。小批通过后扩到历史回归集，再验证未参与修改的独立样本，才进发布流程。一轮实验的价值不只是选出版本，还在于留下可重复的检查：确认有效的题进回归集、评估器误判进校准集、未解决的问题留待下一轮。

• 评估器 三项通用标准；Code/LLM/Agent 三方式按问题选
• 试评 选范围/采样限候选量/字段映射；好·坏·不完整各一条
• 选 Badcase 低分四读（问题/回答/分项/解释）；误判留作校准材料
• 实验 基线+单变量修改；被评分的是新回答新轨迹
• 采用 三件事：严重错误消失/正常不退化/耗时消耗可接受

收尾

看到分数起伏时，先打开对应的回答和运行记录，不能一律归因于 Rubric。

▍逻辑框架（记忆卡片）

① 命题：评估发现问题，实验验证改进

• 评估：检查已经发生的执行——评分、理由与相关证据
• 实验：让修改后的 Agent 重新回答，产生新的输出与轨迹，用同一批题目验证修改是否有效
• 闭环：运行数据 → 持续评估 → 复核与归因 → 数据集沉淀 → 对照实验 → 发布与持续回归 → 回运行数据

"不要看到低分便立即改 Prompt"——先判断问题成立、归因清楚，再配实验验证。

② 先选一个业务问题，做出能用的评估器

• 先选一类投诉（如"回答了概念却没解决问题"），拿几条专家认可与明显缺陷的回答讨论差别；通用标准先行、逐题 Rubric 后补
• 通用标准三项：①是否回应实际问题 ②关键说法是否有材料支持 ③操作任务是否给了足以继续执行的步骤；每项写清满足/部分/不满足并给扣分原因；退款、权限变更等操作再加业务结果检查，避免只评价礼貌
• 评估方式按问题选：Code 规则=JSON 格式与必填字段；LLM 评估=切题与遗漏（参考材料+评分细则给齐）；Agent 评估=多步骤完成、工具结果与最终回复一致（结合轨迹，可挂 Skill）
• 可多评估器分别评"回答质量"与"业务操作完成"，直接看出哪项下降；总分需明确计算方式，不能简单平均

预置评估器覆盖目标可先复用；需要产品知识或服务标准再建自定义——Prompt 写评判标准，声明输入/输出/轨迹变量，输出定义配分数、判断与解释，场景分类、逐项得分按需加，不必一次填满。

③ 用真实样本试评，再启动第一批历史评估

• 选对数据和范围：新接入 Agent 选轨迹（单轮/多轮+对话结束判断）；Pipeline 加工后选 Dataset（一行代表什么已定，无需再找开关）；历史评估选已知含目标业务的时段，预览确认确有要查的问题；多轮会话预览为空，先查时间范围内的会话是否已达到设定的结束条件
• 采样限制的是候选量：100% 采样最多 100 条≠得到 100 条 Badcase；先小批让业务看完解释再扩大
• 接好字段：问题→输入变量、最终回答→输出变量、需过程判断→完整轨迹；变量名可自定义但内容必须对应——"最终回答"位置不能误接某次工具输出
• 运行测试：至少覆盖好/坏/信息不完整各一条；问三个问题：扣分依据是否真出现在回答里？是否引用了正确工具结果？缺证据时是否说明无法判断？坏回答高分→先看收到的输入再看评分条款（只查"提到评估器"一词会把泛泛介绍当操作指导），调整后重评确认好回答没被误判
• 多模态：先确认评估器能读材料再核引用页码/片段；判报销金额必须看到票据与填报结果，仅文件链接或一句"已完成"不足以判断；结果数据集与透传字段在创建前安排（创建后不可改）

预览成功只说明单条配置可用，第一批正式运行才暴露选错范围、部分样本缺字段等问题。

④ 从结果里选出值得修复的 Badcase

• 先看整体分布再开具体样本；跨任务用分析洞察按评估器/来源/分数筛选，看低分带上任务与时间范围，避免混比不同标准不同业务
• 一条结果至少把原始问题、Agent 回答、分项判断、解释放一起读：总分看先看哪里、解释判问题是否成立、轨迹确认为什么出现
• 四现象→动作：介绍概念缺运行步骤=回答完整性问题纳调优样本；有关键步骤解释却说没有=修正映射或评估器重评；声称完成轨迹显示工具失败=任务执行问题交负责团队；执行异常或材料缺失=先补执行条件/材料再判 Agent 质量
• 0.25/0.5 的分数本身用处有限，逐项解释指出缺哪些能力点才有用；同种遗漏选代表几条+保留边界与正常任务；人工发现评估器误判留作校准材料；高分适当抽检，避免漏掉评估器未识别的严重问题

历史评估稳定后再开"基于新数据持续评估"：配置间隔与采样，日常优先看关键指标下降、反复出现的问题与新场景，每次选一小组明确问题进实验；大流量下先降低采样比例，重点场景再用专项历史评估补查。

⑤ 把确认的问题配成实验，评估新生成的答案

• 先记录当前方案为 Baseline，再准备候选；第一轮只改最有依据的一项——同时换模型、改 Prompt、添 Skill，分数变化就难以解释
• 实验类型：在线实验（平台配置模型直接运行，≠向生产用户 A/B 分流）；本地实验（SDK 执行企业自己的 Agent）
• 关键区别：被评分的必须是本次新生成的回答与新轨迹；映射：用户输入=本次实际问题、Agent 输出=新答案、轨迹=本次执行、参考答案与 rubric=Dataset 字段
• 实验计划可接 Pipeline：需要工具状态/结构化业务结果时让新 Trace 经同一加工规则，用 pipeline. 开头字段映射；只比最终回答可先不配
• 正式比较用独立黄金 Dataset 最新数据，实验期间不写入不修改，创建版本留档；同步记录评分标准、Agent/模型版本、Prompt 与关键参数；历史版本视图只用于留档回看，当前界面不支持从历史版本直接发起实验，实验从最新数据发起

逐题 Rubric 录入后在评估器声明 rubric 变量按传入条款评分；先跑两道题确认各自使用对应标准，仍评到旧回答或共用不适用标准就修正映射再重跑。

⑥ 把企业 Agent 接进来，对比同一道题的前后差异

• 接入：获取本地实验配置 → 装依赖/配环境变量 → HTTP/本地命令/自定义执行；在能调用内网服务的环境运行题目，回传结果；管理多个连接与定时任务的团队可用客户侧实验平台（页面化执行端）：先配 AgentSpace/地域/访问凭证 → 测试连接 → 新增目标 Agent 连接，初次接入可直接从 SDK 指引开始，不必先搭管理页面
• 会话适配："创建 Session → 发问题 → 获取最终响应"；API 先返受理信息须继续等最终回答，受理成功≠题目完成；相互独立样本用独立会话避免上下文污染
• 先单题测试（问题发出/最终回答完整返回/记录对应），再跑小批——把连接适配问题与回答质量问题分开定位；Tool/Skill/Workflow/Harness 修改通过接入修改后的版本参与比较，版本写入上下文或记录
• 对比：概览对比看整体、配置对比核对本轮改了什么、样本对比同题输出与指标；先确认同一批题同一版标准再解释分数升降
• 阅读顺序：退化题 → 改善题 → 关键正常场景；输出变长≠改善（新增内容须对应评分要求）；候选总分提高但关键条款未过不升级；只有一题改善而其他退化→检查是否把某种格式强加给所有问题

决定采用至少看三件事：严重错误是否消失 / 正常场景是否退化 / 耗时与消耗是否可接受（补齐状态查询多一次工具调用但避免"失败仍告知成功"，成本结合业务价值判断；省略必要步骤的低耗时不能当升级理由）。失败题先说明原因，不要在结果出来后临时改统计方式；若比的是回答质量，可修复执行条件后重跑，若比的是整套服务交付能力，这些失败本身也属于需要改善的表现；小批通过→扩历史回归集→验证未参与修改的独立样本→才进发布流程。

⑦ 让下一次修改继续使用这套评估

• 一轮实验的价值不仅是选出版本，还在于留下可重复的检查：确认有效的题进回归集、评估器误判进校准集、未解决的问题留待下一轮
• 定期回归：实验计划+目标 Agent+调度周期（或已验证的执行脚本接入定时任务/发布检查）；按发布频率与预算安排每天或每次变更后回归
• 趋势：先关注连续下降或关键题退化，再下钻到具体执行；升级效果不佳沿实验记录找回对应版本与变更，决定继续修复还是回退
• 发布后的真实轨迹继续进入评估，新的 Badcase 又成为下一轮实验题目

补知识、改 Prompt、换模型或调整 Skill，都可以从这套材料重新运行——评估体系本身就是可持续改进的资产。

▍逻辑全景图（评估发现问题 → 实验验证改进 → 发布回归闭环）

运行数据为起点，持续评估、复核归因、数据集沉淀、对照实验、发布回归，再回传形成循环

• 数据与评估
• 复核与沉淀
• 实验与发布

示意 · 按原书图"评估发现问题，实验验证改进"闭环重构，节点内补充各阶段要点

▍书中关键图（SVG 重绘版·示意）① 一致条件下比较两个方案

示意 · 按原书图"在一致条件下比较两个方案"重构

▍书中关键图（SVG 重绘版·示意）② 多模态 Agent 评估：输入 → 过程 → 结果三层证据链

示意 · 按原书图"多模态 Agent 评估三层证据链"重构