持续改进闭环

一句话理解：线上每一个有价值的失败 Trace，都应该变成一条评测用例；每一次修改，都要先通过回归再上线——这个闭环转起来，Agent 才会越用越好，而不是“修一个、坏一片”。

很多 Agent 项目上线后会进入一种疲惫的节奏：用户投诉 → 工程师看一眼 → 改一句 Prompt → 发布 → 另一个用户投诉了别的问题 → 再改一句……三个月后，Prompt 变成了一堆补丁，没人敢动，也没人说得清现在的 Agent 比上线时好了还是差了。

问题不在于修得不够快，而在于每次修复都没有沉淀：失败案例没有进入测试集，修改没有经过回归，线上效果没有被度量。这一课把前面学过的 Trace、指标、评测串成一个可以持续运转的改进闭环。

闭环的六个环节

图 1 画出这六个环节如何首尾相接：

图 1 · 持续改进闭环：六个环节首尾相接，每转一轮都沉淀下新的评测用例

环节	输入	输出	本课程相关内容
1 线上运行	真实用户任务	带版本信息的 Trace	Tracing
2 发现问题	指标、告警、反馈、抽样	待分析的问题 Trace 列表	日志、指标与告警
3 归因	问题 Trace	失败类型与根因	错误归因
4 沉淀为用例	根因明确的案例	新增评测用例	构建评测集
5 修改	根因 + 用例	新版本的工具、指令或流程	Prompt 的迭代与版本管理
6 回归与灰度	新版本	是否全量发布的决策	线上评估与回归

这一课不重复评测方法本身，而是关注“怎么让这六步真的每周都在发生”。

问题从哪里来

只靠用户投诉发现问题太慢，也太偏：会投诉的用户很少，而最危险的问题（比如 Agent 自信地给出错误结论）用户往往意识不到。建议同时使用这些信号：

信号	优点	局限
用户点踩、投诉	直接反映体验	量少，有偏差
人工接管、修改 Agent 产物	行为数据，比打分更真实	需要埋点记录“改了什么”
验证失败、护栏拦截	自动、实时	只覆盖已设计验证的动作
达到步数上限、成本异常	暴露死循环与低效路径	不代表结果一定错
定期随机抽样	能发现“碰巧成功”的隐患	需要人力
高风险任务全量抽检	保障关键业务	成本高，只适合少数任务

实践上可以每周固定一个“Trace 评审会”：从上面各类信号里挑 20–30 条运行，产品、工程和业务专家一起读。Anthropic 在关于 Agent 评测的工程文章中也强调，只有真正去读大量运行记录，才能知道评分器是否在测量你真正关心的东西。

一个完整的例子：SEO 诊断 Agent

1. 发现。 看板显示“用户修改报告”的比例本周从 12% 升到 19%。抽出 20 条被修改的报告，发现有 7 条里，用户删除了“页面缺少 meta description”这一问题项。

2. 归因。 打开对应 Trace：fetch_page 工具抓取的是未经 JavaScript 渲染的原始 HTML，而这几个站点的 meta 标签由前端框架在渲染时注入。模型根据工具结果得出了“缺少”的结论，推理本身没有错，根因在工具。同时发现指令里没有要求“对缺失类问题进行二次确认”。

3. 沉淀为用例。 从这 7 个站点里挑出 5 个，构造评测用例：

{
  "id": "seo-render-001",
  "source": "prod-trace:91c0…",
  "input": { "url": "https://example-spa-site.com/pricing" },
  "expect": {
    "must_not_contain_issue": "missing_meta_description",
    "tool_called_with": { "fetch_page": { "render_js": true } }
  },
  "tags": ["spa", "false_positive", "tool"]
}

同时补充 3 个“确实缺少 meta description”的反例，防止修复后矫枉过正、漏报真实问题。

4. 修改。 为 fetch_page 增加 render_js 参数，并在工具描述里说明何时需要渲染；指令中加入“判定元素缺失前，若页面疑似由前端渲染，先以渲染模式复查”。

5. 回归。 跑完整评测集：新增的 8 条用例全部通过；原有的 120 条用例里，有 2 条因为多了一次渲染调用而超过了耗时阈值。团队决定为渲染结果加缓存，再跑一轮，全部通过。同时记录到：单任务平均成本上升约 8%，耗时上升约 15%，在可接受范围内。

6. 灰度。 新版本先给 10% 的流量，一周后对比新旧版本：“用户修改报告”比例回落到 11%，成本变化符合预期，全量发布。

注意这个例子里最重要的不是修复本身，而是：问题变成了永久的测试用例。以后任何人改动 fetch_page 或相关指令，这 8 条用例都会第一时间报警。

图 2 把这个例子沿闭环走过的一圈串起来：

图 2 · SEO 诊断 Agent 的一轮闭环：问题最终变成 8 条永久用例

让闭环持续运转的机制

版本化一切。 Trace 必须带上 Agent、Prompt、工具集、模型的版本号，否则无法回答“是哪次改动引起的”。
用例带出处。 每条来自线上的用例记录来源 Trace，方便日后回看上下文；进入评测集前完成脱敏。
能力评测与回归评测分开。 Anthropic 的评测文章将其区分为：能力评测衡量“它能做好什么”，起始通过率可以很低；回归评测确保“以前能做的现在仍然能做”，通过率应接近 100%。能力评测里稳定通过的用例，可以逐步“毕业”进入回归集。
小步起步。 不必等攒够几百条用例。同一篇文章建议从 20–50 个来自真实失败的简单任务开始。
每个改动同时看质量、成本、延迟。 修复一个问题却让成本翻倍，也需要被看见并做出取舍。
明确负责人和节奏。 谁每周组织 Trace 评审、谁维护评测集、发布前谁签字确认回归结果，写进团队流程。

常见误区

“直接改 Prompt 修掉就好。” 没有用例的修复不可验证，也无法防止将来被再次改坏。
“评测集建好就不用动了。” 用户行为和业务规则在变，评测集必须持续从线上吸收新案例，否则会越来越脱离现实。
“所有失败都要修。” 有些失败源于用户输入本身不可完成，或者修复成本远高于收益。归因之后要排优先级，允许“接受并在界面上坦诚说明”。
“离线评测通过就能全量。” 离线评测覆盖不了真实流量的多样性，高风险改动仍需要灰度与线上对比。

产品经理检查清单

是否有固定节奏（例如每周）的 Trace 评审？信号来源是否不止用户投诉？
每个修复是否都对应新增的评测用例，并标注了来源 Trace？
发布前是否必须通过回归评测？谁有权在回归失败时放行？
每次发布是否同时对比了质量、成本、延迟三类指标？
高风险改动是否有灰度与回滚方案？
线上数据进入评测集前是否完成脱敏，是否符合数据使用授权？

练习

为「订单售后诊断 Agent」设计一次完整的改进闭环（45–60 分钟）：

以本模块第一课中“退款记录为空 → 错误结论”的 Trace 为起点，写出归因结论（属于工具、数据、推理还是规则问题）。
设计 3 条正例用例和 2 条反例用例，写成上文的 JSON 格式。
写出修改方案，以及回归时你会同时关注的质量、成本、延迟指标。
写一段灰度计划：多少流量、观察多久、什么条件下回滚。

下一步

生产可靠性的四块拼图到此完成。下一阶段进入架构与产品，第一课「什么时候需要多 Agent」先回答一个关键问题：为什么一个 Agent 加多个 Skill 做不到？

持续改进闭环