AI Agent上线后持续优化：质检、自学习与排障的协同体系

1. 上线只是起点：AI Agent 持续优化的整体设计思路

很多团队把 AI Agent 的上线当成项目终点，觉得灰度跑完、指标达标就万事大吉。我见过太多这样的案例：上线第一周效果惊艳，第二周开始用户投诉变多，第三周业务方开始质疑“这东西到底有没有用”。问题不在于 Agent 本身不行，而在于上线之后没有人管它了。

AI Agent 和传统软件最大的区别在于，它的输出不是确定性的。传统接口你传 A 返回 B，只要代码没改，行为就不会变。但 Agent 的输出受输入分布、上下文长度、工具调用结果、模型版本甚至温度参数的影响，今天表现好不代表明天表现好。所以上线后的持续优化不是“锦上添花”，而是“保命刚需”。

我把这套持续优化体系拆成三条主线：质检负责发现问题，自学习负责让 Agent 从问题中变强，排障负责在出问题时快速定位和止血。三条线不是串行的，而是并行运转、互相喂数据的。质检产出的 badcase 喂给自学习做优化，自学习的效果验证又依赖质检，排障过程中发现的新问题模式反过来补充质检规则。

1.1 为什么不能只靠人工抽检

早期我们团队就是靠人工每天抽 50 条对话来看，结果两个问题：一是覆盖率太低，一天几千条对话抽 50 条，概率上根本抓不到长尾问题；二是标准不统一，今天张三觉得这个回答不行，明天李四觉得还行，没法形成稳定的质量信号。

后来我们改成“自动质检为主、人工复核为辅”的模式，自动质检覆盖 100% 的对话，人工只处理自动质检标记出来的可疑样本和随机抽样的校准样本。这样既保证了覆盖率，又控制了人力成本。关键是自动质检的规则和模型需要持续迭代，否则它会漏掉新出现的问题类型。

1.2 自学习的边界在哪里

一提到自学习，很多人第一反应是“让 Agent 自己训练自己”。这个想法很危险。Agent 的自学习必须有明确的边界和护栏，否则很容易出现“越学越偏”的情况。我的经验是，自学习分三个层次：

• 第一层：Prompt 和 Few-shot 的动态优化。这是最安全、见效最快的，从质检产出的高质量对话中提取正例，从 badcase 中提取反例，动态更新 Prompt 中的示例。
• 第二层：知识库和工具调用的修正。当 Agent 频繁在某个知识点上出错，说明知识库有缺失或过时；当 Agent 频繁调错工具，说明工具描述或参数设计有问题。
• 第三层：模型微调。这是最重、风险最高的，只有在积累了足够多高质量标注数据、且前两层优化已经触到天花板时才考虑。

大部分团队做到第一层和第二层就能拿到 80% 的收益，第三层不是必须的。

1.3 排障的核心是“可观测性”

Agent 排障比传统服务排障难得多，因为一次对话涉及多个环节：用户输入理解、意图识别、知识检索、工具调用、结果生成。任何一个环节出问题，最终表现都是“回答不对”，但根因可能完全不同。

所以排障的前提是全链路可观测。你需要能回放任意一次对话的完整链路：用户原始输入是什么、Agent 识别出的意图是什么、检索了哪些知识片段、调用了哪些工具、工具返回了什么、最终生成回答时用了哪些上下文。没有这个链路追踪能力，排障就是盲人摸象。

我的建议是，Agent 上线第一天就要把链路追踪做进去，不要等出了问题再补。补的时候你会发现历史数据全丢了，根本没法复盘。

2. 质检体系怎么搭：从规则到模型的分层策略

质检体系的设计目标很明确：用最低的成本，最高效地发现 Agent 的问题。这里的关键词是“分层”，因为不同的问题类型适合不同的质检手段，一刀切要么成本爆炸，要么漏检严重。

2.1 三层质检架构

我把质检分成三层，从下到上依次是规则质检、模型质检、人工质检。

规则质检是最底层，负责抓那些“确定性”的问题。比如：回答为空、回答超长、包含敏感词、工具调用失败、响应超时、格式不符合要求。这些问题不需要理解语义就能判断，用规则跑一遍，成本几乎为零，能过滤掉 30% 到 40% 的明显问题。

模型质检是中间层，负责抓“语义层面”的问题。比如：答非所问、事实错误、逻辑矛盾、语气不当、信息不完整。这一层通常用一个专门的质检模型来做，输入是用户问题和 Agent 回答，输出是质量评分和问题类型标签。质检模型可以是通用大模型加 Prompt 实现，也可以是基于业务数据微调的小模型。

人工质检是顶层，负责两件事：一是复核模型质检标记出的可疑样本，确认是否真的是问题；二是随机抽样校准，评估模型质检的准确率和召回率。人工质检的量不需要大，但必须持续做，否则你无法知道自动质检到底靠不靠谱。

2.2 质检标准的定义是最大的坑

搭质检体系时，最容易被低估的环节是“质检标准定义”。什么叫“回答质量好”？这个问题不解决，后面全是空中楼阁。

我的做法是把质量标准拆成几个可独立评估的维度，每个维度给出明确的评分标准和示例。常见的维度包括：

• 准确性：回答中的事实信息是否正确，是否有编造。
• 相关性：回答是否直接回应了用户的问题，有没有跑题。
• 完整性：是否覆盖了用户问题的所有方面，有没有遗漏关键信息。
• 可操作性：如果用户问的是“怎么做”，回答是否给出了可执行的步骤。
• 语气与风格：是否符合业务设定的语气，有没有过于生硬或过于随意。

每个维度用 1 到 5 分打分，然后加权汇总。权重的设定取决于业务场景，比如客服场景准确性权重最高，创意场景可能相关性权重更高。

定义标准时一定要拉上业务方一起，不要技术团队自己拍脑袋。我们踩过的坑是技术团队觉得回答“准确完整”，业务方觉得“太啰嗦、用户根本不想看这么长”。标准不一致，质检结果就没法用。

2.3 质检模型的选择与迭代

质检模型的选择有个权衡：用通用大模型加 Prompt，上手快但成本高、稳定性差；用微调小模型，成本低、速度快，但需要标注数据。

我的建议是分阶段走。冷启动阶段用通用大模型加精心设计的 Prompt，快速跑起来，同时积累标注数据。稳定阶段用积累的数据微调一个小模型，把成本降下来。微调数据不需要太多，每个问题类型有 200 到 500 条高质量标注就能有不错的效果。

质检模型的迭代频率建议每两周一次。迭代时重点关注两个指标：准确率（标记为问题的样本中真正有问题的比例）和召回率（真正有问题的样本中被标记出来的比例）。准确率低会导致人工复核量爆炸，召回率低会导致问题漏检。两个指标要平衡，通常召回率优先，因为漏检的代价更大。

2.4 质检结果的结构化沉淀

质检不是为了打分而打分，是为了发现问题、驱动优化。所以质检结果必须结构化沉淀，不能只是一堆分数。

每条质检结果至少包含：对话 ID、用户问题、Agent 回答、各维度评分、问题类型标签、问题严重程度、是否已复核、复核结论。这些字段是后续自学习和排障的基础数据。

我特别想强调的是问题类型标签的设计。标签体系不要太细，太细了标注一致性差；也不要太粗，太粗了没法指导优化。一般 10 到 20 个标签比较合适，覆盖主要问题类型，同时留一个“其他”兜底。标签体系需要定期 review，随着业务发展增减标签。

3. 自学习机制：让 Agent 从 badcase 中真正变强

质检发现了问题，接下来就是让 Agent 从这些问题中学习。但“学习”这个词很容易被误解，不是把 badcase 丢给模型重新训练就完事了。自学习是一个系统工程，需要明确学什么、怎么学、学了之后怎么验证。

3.1 从 badcase 到优化动作的转化路径

拿到一个 badcase，第一步不是急着改，而是归因。这个 badcase 的根因是什么？是 Prompt 写得不好？是知识库缺失？是工具调用逻辑有问题？还是模型本身能力不够？

归因清楚了，优化动作就明确了：

• Prompt 问题：调整 Prompt 的指令、示例或约束条件。
• 知识库问题：补充缺失知识、修正错误知识、优化检索策略。
• 工具问题：修正工具描述、调整参数设计、增加工具调用的校验逻辑。
• 模型问题：如果前三个都排除了，才考虑微调或换模型。

我见过很多团队一上来就想着微调，结果花了两周标注数据、跑完训练，效果提升还不如改两句 Prompt。归因的优先级应该是：Prompt > 知识库 > 工具 > 模型，从轻到重，从快到慢。

3.2 Prompt 动态优化的实操方法

Prompt 优化是自学习里性价比最高的手段。具体怎么做？

首先，从质检结果中筛选出高质量正例和典型反例。正例的标准是各维度评分都在 4 分以上，反例的标准是某个维度评分低于 2 分且问题类型明确。

然后，把这些正例和反例整理成 Few-shot 示例，动态插入到 Prompt 中。注意示例的数量不要太多，一般 3 到 5 个就够了，太多了会占用上下文窗口，反而影响效果。示例的选择要有代表性，覆盖不同的用户意图和问题类型。

一个实操技巧：示例的顺序会影响效果。把最相关的示例放在最后（离用户输入最近的位置），模型参考的权重会更高。这个技巧在多个模型上都验证过，效果稳定。

Prompt 优化后需要 A/B 测试验证。不要直接全量替换，先拿 10% 的流量跑一天，对比优化前后的质检评分和用户反馈。确认有效再逐步放量。

3.3 知识库的自动巡检与修正

知识库是 Agent 的“事实来源”，知识库有问题，Agent 回答必然有问题。但知识库往往是人工维护的，容易过时、遗漏、出错。

我的做法是建立知识库自动巡检机制。具体来说，定期用一批标准问题去问 Agent，对比 Agent 回答和知识库中的标准答案，发现不一致的就标记出来人工复核。这个巡检可以每周跑一次，成本不高但能持续发现知识库问题。

另外，从质检结果中也能反推知识库问题。如果某个知识点频繁出现在 badcase 中，大概率是知识库这块有问题。这时候需要定位到具体的知识条目，检查是缺失、过时还是表述不清。

知识库修正后，要验证 Agent 的回答是否改善。验证方法是用之前出错的那些问题重新问一遍，看回答是否正确。这个过程可以自动化，形成一个“发现问题-修正-验证”的闭环。

3.4 自学习的护栏与风险控制

自学习最大的风险是“学歪了”。比如从 badcase 中提取反例时，如果反例本身标注错了，Agent 就会学到错误的东西。或者 Prompt 优化时改过了头，导致 Agent 在另一类问题上表现变差。

所以自学习必须有护栏：

• 变更审核：任何 Prompt、知识库、工具的变更都要经过审核，不能自动生效。
• 灰度验证：变更先在少量流量上验证，确认无副作用再放量。
• 回归测试：每次变更后跑一遍回归测试集，确保之前修好的问题没有复发。
• 回滚机制：变更导致效果下降时能快速回滚到上一版本。

回归测试集是自学习的基础设施，需要持续维护。每次发现新的问题类型，就把对应的样本加入回归测试集。测试集规模控制在几百条，覆盖主要问题类型，每次变更后全量跑一遍，几分钟就能出结果。

4. 排障实战：快速定位 Agent 问题的系统方法

排障是上线后最紧急的工作。用户投诉来了，业务方催着要原因，你必须在最短时间内定位问题、给出解决方案。没有系统的方法，很容易陷入“东查西查查不出来”的困境。

4.1 全链路追踪的搭建要点

排障的前提是能回放问题对话的完整链路。这需要在 Agent 的每个环节埋点，记录输入输出和关键中间状态。

具体来说，一次对话需要记录的信息包括：

• 用户原始输入、时间戳、用户标识、会话 ID
• 意图识别的结果和置信度
• 检索到的知识片段及其来源和评分
• 调用的工具名称、参数、返回结果、耗时
• 最终生成回答时使用的完整上下文
• 模型版本、温度参数等配置信息

这些信息要能通过一个对话 ID 串起来，支持快速检索和回放。存储上可以用结构化日志加对象存储的组合，日志存索引字段，完整上下文存对象存储。

埋点要注意隐私合规，用户敏感信息要脱敏后再存储。这个不是技术问题，是合规底线，上线前必须处理好。

4.2 问题分类与排查路径

Agent 的问题表现千奇百怪，但根因可以归为几大类。建立分类和对应的排查路径，能大幅提升排障效率。

排查时按这个表逐项排除，能快速缩小范围。大部分问题在前三项就能定位到。

4.3 典型排障案例复盘

说一个我们遇到过的典型案例。用户反馈 Agent 在回答某类问题时经常给出过时信息。按排查路径走：

第一步，检查意图识别，正常。第二步，检查检索片段，发现检索到的知识片段确实是过时的。第三步，检查知识库，发现这个知识点有两个版本的条目，旧版本没有被删除，检索时旧版本评分更高被优先返回了。

根因是知识库更新时没有清理旧版本。解决方案是知识库更新流程中增加“旧版本失效”步骤，同时优化检索策略，对同一知识点的多个版本按时间排序，优先返回最新版本。

这个问题从发现到修复用了半天，如果没有链路追踪，可能要排查好几天。所以再次强调，可观测性是排障的生命线。

4.4 排障后的复盘与沉淀

每次排障结束后，必须做复盘。复盘不是走形式，要产出三样东西：

• 问题根因报告：清晰描述问题现象、根因、影响范围、修复方案。
• 预防措施：如何避免同类问题再次发生，比如增加质检规则、优化流程。
• 回归测试用例：把这次问题的样本加入回归测试集，确保修复后不会复发。

这些沉淀会逐渐积累成团队的“排障知识库”，下次遇到类似问题能快速参考。我建议每季度对排障记录做一次汇总分析，看看哪类问题最高频，从系统层面做优化。

5. 三条线的协同：让优化形成飞轮

质检、自学习、排障单独做好已经不容易，但真正的价值在于三条线的协同。协同好了，优化会形成飞轮，越转越快；协同不好，三条线各干各的，重复劳动还互相打架。

5.1 数据流转与闭环设计

三条线之间的数据流转是这样的：排障发现的问题，补充到质检规则中；质检产出的 badcase，喂给自学习做优化；自学习的变更效果，通过质检来验证；质检发现的新的高频问题，触发排障深入分析。

这个闭环的关键是数据格式统一。三条线用同一套问题类型标签、同一套严重程度定义、同一套对话 ID 体系。否则数据流转时要做大量转换，效率极低还容易出错。

我们团队的做法是建一个统一的“问题中心”，所有问题都往这里沉淀，每条问题记录包含来源（质检/排障/用户反馈）、状态（待处理/处理中/已解决/已验证）、关联的优化动作。这样任何人都能看到当前有哪些问题、进展如何。

5.2 优化效果的量化评估

优化做了，效果怎么衡量？不能凭感觉说“好像好了一点”。需要建立量化评估体系。

核心指标包括：

• 质检评分均值：所有对话的平均质量分，反映整体质量水平。
• badcase 率：质检标记为有问题的对话占比，反映问题发生的频率。
• 问题解决率：标记的问题中已解决的比例，反映优化动作的执行力。
• 复发率：已解决的问题再次出现的比例，反映优化的彻底性。
• 用户反馈指标：点赞率、投诉率、转人工率等，反映真实用户体验。

这些指标要按周跟踪，画成趋势图。优化有效果，指标会下降；优化没效果或引入新问题，指标会上升。指标异常时触发排查。

指标要设置合理的基线，不要追求完美。Agent 不可能 100% 正确，追求过高的指标会导致过度优化，成本收益不成正比。找到业务能接受的平衡点就好。

5.3 团队协作与流程固化

持续优化不是一个人能干的，需要质检、算法、工程、业务多方协作。协作效率取决于流程是否清晰。

我建议固化几个关键流程：

• 每日质检例会：15 分钟，同步昨天的质检结果和待处理问题。
• 每周优化评审：1 小时，评审本周的优化动作和效果，决定下周优化重点。
• 每月质量复盘：2 小时，全面复盘质量指标、重大问题、流程改进。

流程不要太多太重，否则团队会疲于应付。关键是每个流程都要有明确的输入输出和决策点，不能开成“同步会”。

5.4 常见协同陷阱与规避

协同过程中有几个常见的坑：

坑一：质检和自学习脱节。质检产出的 badcase 没有及时喂给自学习，或者自学习不知道哪些 badcase 优先级高。解法是建立 badcase 的优先级排序机制，按问题严重程度和出现频率排序，自学习优先处理高优先级。

坑二：排障和质检重复劳动。排障发现的问题没有补充到质检规则中，下次同类问题还要靠排障发现。解法是排障结束后必须产出质检规则补充建议，纳入质检迭代。

坑三：优化动作没有验证。自学习做了优化，但没有通过质检验证效果，不知道有没有用。解法是任何优化动作都必须有验证方案，验证不通过的要回滚。

坑四：指标口径不一致。不同团队对“badcase 率”的定义不一样，导致数据对不上。解法是统一指标定义，写进文档，所有人按同一口径计算。

6. 实操心得与避坑指南

最后分享一些实操中积累的心得，都是踩过坑之后总结出来的，常规文档里不会写。

6.1 质检规则不是越多越好

刚开始搭质检体系时，我们恨不得把所有能想到的规则都加上，结果规则之间互相冲突，误报率飙升，人工复核量爆炸。后来砍掉了一半规则，只保留高准确率的，整体效率反而提升了。

规则的质量比数量重要。每条规则上线前都要验证准确率，准确率低于 80% 的规则不要上，否则误报会淹没真问题。

6.2 自学习的节奏要控制

自学习太慢，问题积累；太快，变更频繁导致不稳定。我们的节奏是：Prompt 优化每周一次，知识库修正每周一次，工具调整按需但不超过每周两次，模型微调每季度最多一次。

每次变更后至少观察 24 小时再决定是否继续下一次变更，否则多个变更叠加，出了问题不知道是哪个引起的。

6.3 排障要先止血再根治

用户投诉来了，第一优先级是止血，不是找根因。止血手段包括：临时下线有问题的功能、切换到备用方案、人工接管。止血之后再慢慢排查根因。

我见过团队为了找根因，让问题持续了好几个小时，用户投诉越来越多。正确的做法是先止血，把影响控制住，再从容排查。

6.4 回归测试集要持续维护

回归测试集是自学习和排障的基础设施，但很容易被忽视。我们的做法是每次排障和质检发现新问题类型，就往回归测试集里加样本。测试集每季度清理一次，去掉已经不可能再出现的过时样本。

测试集规模控制在 300 到 500 条，每次变更后全量跑一遍，5 分钟内出结果。太慢了没人愿意跑，太快了覆盖不够。

6.5 用户反馈是最宝贵的信号

自动质检再完善，也有盲区。用户反馈是发现盲区的重要渠道。我们会在产品里设置便捷的反馈入口，用户点一下就能标记“这个回答有问题”。这些反馈会直接进入问题中心，优先级高于自动质检发现的问题。

用户反馈的量可能不大，但质量很高，往往能发现自动质检漏掉的新问题类型。定期分析用户反馈，是优化质检规则的重要输入。

这套体系跑下来，我们团队的 Agent 在三个月内把质检评分均值从 3.2 提升到了 4.1，badcase 率从 18% 降到了 6%，用户投诉率下降了 70%。不是靠某个单点突破，而是靠三条线持续运转、互相喂数据形成的飞轮效应。上线只是起点，持续优化才是 Agent 真正产生价值的地方。