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 实现也可以是基于业务数据微调的小模型。人工质检是顶层负责两件事一是复核模型质检标记出的可疑样本确认是否真的是问题二是随机抽样校准评估模型质检的准确率和召回率。人工质检的量不需要大但必须持续做否则你无法知道自动质检到底靠不靠谱。质检层级覆盖比例单条成本主要发现问题类型迭代频率规则质检100%极低格式、超时、敏感词、空回答每周模型质检100%低答非所问、事实错误、逻辑问题每两周人工质检1%-5%高校准自动质检、发现新问题类型每天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 的问题表现千奇百怪但根因可以归为几大类。建立分类和对应的排查路径能大幅提升排障效率。问题表现可能根因排查路径答非所问意图识别错误、检索结果不相关检查意图识别结果检查检索片段相关性事实错误知识库错误、模型编造对比知识库原文检查是否有编造痕迹工具调用失败工具描述不清、参数错误、工具本身故障检查工具调用日志验证工具单独调用是否正常回答不完整上下文截断、生成提前终止检查上下文长度检查生成终止原因响应超时检索慢、工具慢、模型推理慢检查各环节耗时定位瓶颈语气不当Prompt 约束不足、示例不当检查 Prompt 中的语气指令和示例排查时按这个表逐项排除能快速缩小范围。大部分问题在前三项就能定位到。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.1badcase 率从 18% 降到了 6%用户投诉率下降了 70%。不是靠某个单点突破而是靠三条线持续运转、互相喂数据形成的飞轮效应。上线只是起点持续优化才是 Agent 真正产生价值的地方。
