AI Agent 上线的那一刻别急着开香槟。真正决定一个Agent项目能不能站稳脚跟的是它上线之后团队能不能靠质检、自学习和排障这套组合拳把问题一个一个揪出来再摁回去。这个道理我是在几个客服、办公类Agent项目的长期迭代里被反复锤过之后才彻底想明白的。这篇文章就把我实际落地过的那套持续优化闭环完整拆给你看适合正在带Agent项目、或者刚把Agent推到生产环境的同学参考。很多人把“上线”当终点但我的感受恰恰相反上线那天只是项目真正开始运转的起点。开发阶段你再怎么测测试集也是有限的真实用户不会按你的脚本提问多余的口语、错别字、指代不清、情绪化表达、多轮纠缠全都堆到你面前。而且Agent和普通问答机器人不一样它的链路更长——意图识别、知识检索、工具调用、结果生成任何一个环节出问题都会被放大成一次糟糕的用户体验。所以上线之后你必须有一套机制持续盯着它。这套机制就是三个关键词质检、自学习、排障。质检负责“发现问题”自学习负责“消化问题”排障负责“解决突发和根因问题”。三件事互相咬合转成一圈Agent才会越用越稳。1. 为什么上线后的Agent必须“喂”一套优化闭环1.1 再准的评测集也覆盖不了真实世界的“脏输入”开发阶段我们习惯了“给多少测试用例就验多少”。几百条用例跑完准确率九成以上感觉可以上线了。可真实用户根本不按常理出牌。同样一个“怎么退换货”的问题用户可能说“我东西不想要了咋整”、“订单弄错了怎么办”、“发过来的货不对能退吗”。这几句话在语义上高度相似但落到Agent的意图识别模块里可能是完全不同的置信度。更麻烦的是上下文错位。用户先问“你们家发货发到哪儿”Agent答完用户紧接着来一句“那运费谁出呢”这里的“那”指代什么取决于上一轮讨论的商品与场景而这一层动态上下文离线测试集很难穷举。Agent一旦涉及知识库检索和工具调用错误还会逐步叠加检索拿到错误段落生成阶段模型却用惯性知识胡说最后给用户一个看着流畅但完全错的答案。这个现象业界叫“幻觉”本质就是模型一本正经地编造。所以我一直强调上线后出现质量波动不是异常而是常态。你需要建立的不是“防错机制”而是“发现机制修复机制”这就是质检和自学习的价值。1.2 质检、自学习、排障是一套循环不是三个孤岛这三件事如果各干各的效果会大打折扣。质检发现了问题但不流入改进管道那质检报告就是废纸自学习在盲目吸收数据但没有排障环节去定位根因改来改去只是打地鼠排障只修眼前的问题不沉淀成测试用例下个月同款事故必然卷土重来。我把它们的协作关系比喻成医院流程质检是体检科定期告诉你哪里指标异常自学习是康复科根据体检结果制定锻炼计划排障是急诊科真有突发状况时第一时间止血。体检结果反哺康复计划急诊病例也要沉淀进体检标准里。这样才算一个完整的循环。落到执行上就是每天质检抽到的坏样本按主题聚类后交给排障定位根因定位出根因后改进动作交给自学习模块吸收改Prompt、改知识库、补意图示例改完的新版本必须跑一遍质检回归集防止旧问题复发、新问题冒出。循环跑起来之后Agent的质量曲线才会是锯齿向上的而不是一路往下掉。1.3 先搭最小闭环再逐步上复杂系统别一上来就买平台、搭大规范系统。我在项目初期踩过最大的坑就是想把质检体系、标注平台、数据回流管道一次到位结果折腾了一个月真正有用的产出很少。正确做法是先搭一个能跑通的最小闭环日志全量记录用户输入、Agent的中间决策、最终回复全部落盘。每日抽样质检从前一天会话里按主题抽50到100条人工打分。问题分类把坏样本按“意图错、检索漏、工具错、生成错”打标签。热点问题修复挑出最集中的问题簇尝试用Prompt或知识库修复。回归验证把修复后的Agent在昨天的坏样本上重跑一遍看修复率。这个循环一周迭代一次就够人不用多产品/运营负责标注算法/后端负责数据管道与改进测试负责回归。等这个最小闭环走顺了再逐步加实时质检、自动聚类、告警平台这些复杂能力。很多团队一上来就奔着“智能化”去反倒忽略了最基础的日志和标注那不是优化是埋雷。2. 质检体系把“感觉不对”变成硬指标2.1 指标不是越多越好先抓五个关键质检最怕的是“凭感觉”。有些团队上线后只盯一个“回答成功率”觉得只要没报错就算成功结果用户已经气到转人工了后台指标还是全绿。指标要有但必须分层先从五个最关键的入手。第一任务完成率。在客服场景可以定义为用户结束会话时问题已解决的比例在办公场景可以定义为Agent输出的文件、结果被用户采纳的比例。这是最贴近业务价值的指标。第二首次响应正确率。这个比任务完成率更严格它要求Agent在第一个回合就给对方向不依赖用户反复追问纠偏。很多质量差的Agent能靠兜底话术把会话拖完但首响正确率一测就露馅。第三忠实度。衡量回复内容是否严格基于检索到的资料或者工具返回的真实结果这是抓“幻觉”的关键指标。评分标准通常是三档完全忠实、部分忠实夹杂编造、完全不忠实。第四拒答率。合理拒答的意思是Agent明确告诉用户“这个问题我暂时无法回答”。拒答率太低说明它爱瞎编太高说明它太怂、什么问题都不敢接两种都是偏科。第五用户事后反馈。包括点踩、转人工、结尾评价。这个指标有滞后性但很真实因为它直接反映用户的体感。我给一个常用指标表格方便你对照落地指标采集位置口径示例参考警戒值任务完成率会话结束已解决会话数 / 总会话数低于80%报警首响正确率首个回复完人工抽检评分≥3分占比低于70%报警忠实度全量或抽检完全忠实占比低于85%注意幻觉拒答率全量拒答数 / 总请求数高于15%或低于2%都需关注用户点踩率全量点踩数 / 有效反馈数高于10%报警指标选定之后还要定期校准口径。同一个“完成率”不同标注员的理解可能差异很大所以我建议每周拉一次标注一致性检验让两个人同时标50条样本比对一致率低于80%就去对齐标准。2.2 离线评测集让过去的问题永远不再回来离线评测集是质检的“压舱石”。它解决两件事第一Agent版本改动后怎么衡量到底变好还是变坏第二以前修过的问题怎么保证不复发。评测集的素材不要凭空捏造直接从线上日志里抽真实会话回放。按场景分层比如客服Agent就分售前、售后、物流、发票、退换货这几个主题每个主题至少抽20到30条初始规模200条起步覆盖各个高频场景。标注等级我建议用三档完全正确、部分正确、错误。部分正确要写清楚缺了什么或者哪里偏了这样后续改进才知道往哪个方向补。比如用户问“运费险怎么申请理赔”Agent回答“在订单详情页申请”但没说具体步骤这个就得标“部分正确——步骤缺失”。评测集必须动态生长。每周质检发现的新问题确认有代表性的马上追加进评测集变成一条“带刺的用例”。这样每次跑回归都能通过新用例证明你上一波优化是不是真的有效。我见过很多团队评测集半年不更新模型都迭代好几个版本了回归集还躺在去年结果越测越假。跑回归时还要注意一点别只看平均分要看分场景得分。整体准确率从82%涨到85%可能掩盖了“售后场景”从80%跌到60%这个严重回退。所以我每次都要求评测报告按场景、按错误类型拆开输出这样一眼就能看到哪里得了退步。2.3 实时质检硬规则拦截加软性打分离线评测是周期性体检但生产环境不可能天天等人工标注。我们需要上线一套实时质检自动抓出明显异常。我的方案分两层硬规则拦截和软性质量评分。硬规则拦截不需要模型纯规则即可。比如空回复、超时返回、回复里出现敏感词、回复格式不符合业务要求缺少必要字段、调用工具出现了明确报错。这些一旦命中直接进入人工复核队列或触发Agent重新生成一次重试策略但重试要有次数上限最多2次再多就转人工兜底。软性质量评分稍微复杂一点。做法是给每一条回复打一个质量分低于阈值就抽出来人工看。打分方式有三种可选小模型分类器、大模型裁判LLM-as-Judge、规则加关键词的组合。我实际测下来大模型裁判对语义质量的判断比较准推荐程度高但要注意它也有偏见——喜欢吃长回答、喜欢结构清晰的列表式内容可能把“短而准”误杀。所以大模型打分只能当“初筛”最终必须抽20%让人工复核一遍校准分数。阈值怎么定不要拍脑袋设80分然后发现满屏报警。先拿历史数据人工标100条画一个得分分布再结合业务容忍度取P90的位置作为阈值或者直接定“低于业务底线”。我见过一个团队把阈值定得很低结果90%的坏回复都被放过了定得太高又天天误报运维疲劳。所以这一步务必用数据说话。2.4 质量门槛与发布卡点质检体系最终要和发布流程绑在一起否则它就是个展示板没有任何约束力。我的原则是不回归不放行。任何Agent的配置变更——不管是改Prompt、换模型、调检索参数、更新知识库——都必须跑一遍离线评测集。卡点规则可以定成下面这样核心场景指标不得低于当前线上版本基线的95%。任何单一场景的得分回退幅度不得超过10个百分点。上一次发布后新增的“带刺用例”必须全部通过或至少通过率不低于90%。如果改动不达标就拒绝发布并退回优化。一开始开发者会抱怨流程重但跑过一两次“上线即翻车”之后就没人再反对了。我自己经历过一个项目就是因为有一次偷偷改知识库没跑回归结果把另一个场景的准确率直接拉低15个点直到用户大量投诉才发现。之后“不回归不放行”就成了铁律。3. 自学习机制把失败的样本变成Agent的“养料”3.1 数据回流是第一环日志字段必须一次设计好自学习的起点是数据。没有高质量的回流数据后面所有“自动优化”都是空谈。这里最痛的教训是日志字段如果上线前没设计好后面补起来要废特别大的劲甚至根本补不了。我建议日志至少包含以下字段session_id会话唯一ID、trace_id链路追踪ID、时间戳、用户输入、Agent识别到的意图、检索命中的知识块列表与分数、工具调用的入参与返回、最终回复、用户反馈信号、响应耗时与Token消耗量。生产环境不要偷懒宁可多打字段也别等要分析时发现缺胳膊少腿。下面是一个会话日志的简化示例你可以照着这个结构设计自己的落盘格式{ session_id: 2b8a1d4e-9c2f-4f7a-8e3d-0f1c2b3d4e5f, trace_id: 9f2a8e3c-b4d1-4f5a-9e2c-3d4e5f6a7b8c, timestamp: 2025-05-12 14:23:18, user_input: 这个商品能退吗, intent: { label: return_policy, confidence: 0.76 }, retrieval: { hit: false, top_chunks: [] }, tool_call: null, final_response: 亲商品支持7天无理由退货哦~, feedback: { thumbs_down: true, transferred_to_human: false }, metrics: { latency_ms: 832, prompt_tokens: 521, completion_tokens: 48 } }这里有两个容易忽略的点一是用户ID和涉及个人信息的内容落库前必须做脱敏处理这是合规底线二是feedback信号不要只依赖用户主动点踩很多用户懒得点要结合“是否转人工”“是否重复提问”等隐性信号综合判断。3.2 失败样本怎么归类数据回流之后最核心的动作就是把失败样本聚类。不聚类你就只能一单接一单地修修到天荒地老。我日常工作流里会把当日坏样本按话题做向量聚类聚出几个大簇比如“退款到账时间”“运费险理赔”“发票抬头修改”然后按簇的大小排优先级先处理最大的簇。每个簇接着要往下拆失败原因。常见的有五类意图识别漂移用户表达不在预设意图里被分到了错误的兜底意图。检索未命中知识库里有这个内容但向量检索没召回。工具调用失败参数传错、接口报错、权限不足。生成幻觉模型拿到资料还是自己添油加醋。格式与流程错误回复格式不符合要求或漏掉了关键步骤。比如用户问“运费谁出”Agent却识别成了“售前咨询”然后给了一段商品推荐——这就是典型的意图识别漂移。定位到这一步改进方向就很明确给“售后运费”意图补充那几条同义问法。3.3 低风险修正自动化高风险修正走人审失败样本分好类之后改进动作要区分风险级别不能一股脑全自动。低风险修正可以做成半自动流程把失败簇聚类出来后系统自动生成修正建议比如补充意图示例、新增FAQ词条、更新知识库内容然后推给运营或产品做一键确认。我实际效果最好的一条链路是这样聚类失败样本生成“新增意图示例清单”→ 运营在小程序里点确认 → 自动写入意图模型配置 → 带着新的示例抽50条线上会话重测指标过了就更新。高风险修正必须人工复核。比如涉及价格、理赔、法律承诺或者用户要求Agent代替用户做决策的场景自动修改全量上线风险极大。这类内容我建议加一道“领域专家审核”至少看两轮再入库。这里要特别提醒自动更新知识库这条链路一定要配“回滚”能力。某家公司上线了一套自动抓取FAQ的系统结果把一条过期的“满减规则”写进了知识库客服Agent全量答错造成大规模客诉。知识库自动更新按钮看着爽出事时更爽。3.4 什么时候该动Prompt、知识库、微调优先级的顺序我建议是后处理规则和兜底 → Prompt优化 → 知识库与检索优化 → 微调。跟“先吃药再手术”一个道理前面层级的成本低、见效快只有它们都不管用了才动微调这种重武器。Prompt优化的典型场景某个指令没说清导致模型在边界情况上跑偏。比如你发现Agent经常不署引用来源就加一句“你的回答必须基于给定的资料并在句末标注资料编号”。知识库和检索优化的典型场景用户问长尾知识点模型答得模棱两可。优先检查知识切片是不是切得太碎了其次看同义问法和检索topK够不够最后看排序策略是否把“精准短答”压到了“泛泛而谈”后面。微调什么时候才轮到我的判断标准是同一个失败模式在评测集里出现超过一定次数且通过Prompt和知识库的调整试过三轮以上依然收效甚微。微调的成本不仅是钱还有时间——你要准备训练集、精调参数、重新评测、灰度上线一蹲就是一两周期间其他迭代全被堵住。所以我的经验是先穷尽前几层手段微调永远是最后一张牌。3.5 用户反馈信号怎么收集自学习不能只看“失败样本”还要关注“用户没说你错但你其实错了”的情况。主动收集反馈是重要补充。常用手段会话结束弹窗用一两个轻量问题取代评分弹幕比如“这个回答解决你的问题了吗”。回复下方的“有帮助/没帮助”按钮。监测“转人工”事件这个信号很硬核。监测“用户重复提问”用户在Agent回复之后又用更简单的句子重问一遍大概率是没解决。通过响应后的行为推断用户直接关页面、长时间不回复、反复修改问题都是隐性负反馈。最后我会把这些信号和质检指标放在同一个看板里这样就能看到一条“真实体感质量曲线”而不仅是内部自嗨的准确率。4. 排障体系问题出现后最快的定位路径4.1 可观测性三支柱日志、指标、链路追踪排障的本质是回答一个问题这个回答为什么错了。为了快速回答它Agent系统必须具备可观测性。我把它拆成三件事日志、指标、链路追踪。日志是原始素材记录每一步发生了什么。指标是聚合信息告诉你系统整体健康度。链路追踪是把一次完整请求的每一步串起来从用户输入到意图识别到检索到工具调用到最终生成全链路可见。链路追踪的关键是trace_id。每一条用户请求进来就生成一个trace_id并贯穿所有环节。前端传给GatewayGateway传给Agent引擎引擎传给LLM调用、检索服务、工具服务每个子系统打日志时都必须带上这个trace_id。这样一来排查时只要拿到一个trace_id就能把整条链路的日志捞出来按时间排序看到每一步的输入输出。我敢说很多Agent项目的线上问题难排查根源就是日志不带trace_id或者带得不全。这一步没做好后面的排障体系基本瘫痪。4.2 排障看板从“服务正常”到“业务正常”很多团队看板只放“API可用率”“平均响应时间”这类基础设施指标我称它们为“服务正常”看板。服务正常不代表业务正常。你接口全绿但Agent全在答非所问用户一样流失。我建议业务排障看板至少包含这几个维度单轮/多轮请求量、成功率、失败量。平均首响延迟、Token消耗成本监控。检索命中率知识库检索没命中的比例这个指标高说明Agent大概率在裸答或硬编。工具调用失败分布传参错误、权限错误、接口超时分别占多少。用户负反馈分布点踩集中在哪个意图或哪个场景。有了这些维度排障时可以快速收敛。比如某天用户点踩率突然飙升你打开看板发现工具调用失败率同步升高那就直接去查工具服务如果检索命中率暴跌就去查知识库的索引是不是挂了。每一步都有数据指向不用瞎猜。4.3 高频故障现象与排查路径下面是我在Agent项目里最常遇到的故障现象以及对应的排查路径做成一个速查表遇到问题可以对着走。故障现象可能原因排查入口修复方向回复明显胡编检索未命中但模型用常识硬答查检索命中率与召回内容加强Prompt“未命中必须拒答”加后处理引用校验一问三不知拒答规则过严或知识库覆盖不足查拒答率与检索命中率分布放宽拒答策略、扩充知识库/同义问法多轮对话丢上下文上下文拼接策略截断过早查会话上下文日志调整窗口截断策略或引入会话摘要响应明显变慢模型规格过大、并发受限、检索耗时高查链路各阶段耗时换小模型、加并发、优化向量检索工具调用失败参数Schema不匹配、权限缺失查工具调用日志与报错修正Schema、检查鉴权配置模型切换后质量回退新模型与Prompt不适配跑离线回归对比新旧版本按场景对比调整Prompt或回滚知识库更新后效果变差新内容格式杂乱、切片不合理查新知识块的召回记录重构切片并做A/B测试这个表最实用的部分是“排查入口”。我见过太多人排障时从“玄学”入手先怀疑模型本身折腾半天才发现是知识库索引挂了。正确做法是从数据出发锁定异常指标再顺链路往下查。4.4 告警分层与值班机制告警不是越响越好响太多团队会麻。我把告警分成四级P0立即处理全站Agent不可用、大面积报错、涉及合规风险。任何时候收到都要人肉响应。P115分钟内响应核心场景成功率较基线明显下降、用户负反馈陡增。P2当天处理非核心场景的质量波动或指标缓慢恶化趋势。P3排期处理无用户体感影响但可以优化的事项比如Token成本小幅上涨。告警规则要防抖动。不要设一个硬阈值比如“成功率低于95%就报警”结果业务起伏一下就被打爆。我建议用“滑动窗口最小样本数连续触发次数”。比如判断标准设为5分钟窗口内请求量≥50且成功率低于95%并且连续两个窗口都触发才发P1告警。这样既不会漏报也不会因为一次零星抖动就半夜爬起。对于响应指标和成本指标建议先观察7到14天取一个正常基线再在基线之上设置告警线。直接拿业界某个“标准值”套到自己业务里大概率只会制造噪音。5. 完整复盘一个客服Agent“翻车”后我做了什么5.1 现象质检突然拉响警报某电商客服场景的Agent上线两周后质检看板里突然出现一个刺眼的数字“退换货政策”方向的问题错误率高达40%而其它主题平均只有不到10%。大量用户投诉集中在同一类问题“运费险理赔流程到底是怎样的”“退货时运费谁承担”。Agent给出的回答经常自相矛盾有时候说“运费由商家承担”有时候说“消费者自行承担”且无法溯源。第一次看到这个数据我的反应不是去改模型而是先确认这是不是个案。于是拉了48小时内包含关键词“运费”“退货”的所有会话大约500条按错误标签聚类。结果发现90%的失败集中在一个细分知识点上“运费险理赔条件与流程”。问题比想象中集中这让我松了口气——集中就有突破口。5.2 三步拆解日志回溯、链路切片、生成侧检查第一步日志回溯。挑选20条典型失败会话用trace_id把每条会话的完整链路日志拉出来。顺着时间线观察用户的真实意图是什么Agent识别成了什么检索到了什么内容最后生成了什么回复。这一步不需要复杂工具日志查得全就行。第二步链路切片。逐段分析后发现两个根因。第一意图识别把“运费谁出”这类问法分到了“售前咨询”而非“售后政策”导致后面检索用的意图上下文就不对。第二知识库里“运费险”的内容被拆成了三个很短的页面向量检索在召回时只捞到其中一条而且那条内容里连“运费险”三个字都没完整出现。检索结果本身就不全模型怎么可能答对。第三步生成侧检查。Prompt里没有约束“必须严格基于检索内容回答”只写了“你是客服助手”。模型在检索信息不完整时就自然调用了它在预训练阶段学到的“常见退换货运费规则”而这些规则和这家平台的真实政策并不一致幻觉就这么产生了。5.3 改动清单与效果根因清楚之后改动就很小了一共四步。第一重构知识库。把分散的三个“运费险”碎片合并成一个完整主题块补充了常见问法关键词调整切片的粒度确保一条FAQ能覆盖“理赔条件申请入口垫付规则”三个子问题。第二补充意图示例。在“售后政策”意图里加上了“运费谁出”“退货运费谁承担”“运费险怎么用”等20条同义问法降低意图识别漂移的概率。第三修改Prompt生成约束。明确写上只能依据检索到的资料回答如果检索结果为空或与问题无关必须明确告知用户“暂时无法确认建议联系人工客服”。第四新增后处理校验。在生成结果里如果检测不到知识库的引用ID则判定为“未基于资料”自动降级为拒答模板并转人工。改动上线后跑同一批500条历史会话错误率从40%降到8%。再跑一遍离线评测集这次没有引入新的回退。这个案例当时给我最大的启发是大部分Agent质量问题根因往往不在模型本身而在工程链路的细节。修好意图、检索、Prompt约束和后处理效果比盲目换一个大模型要实在得多。5.4 复盘沉淀把个案变成标准作业流程单个问题解决不是终点。如果每次问题都靠临时排查解决团队会一直处于救火状态。所以这个案例之后我沉淀了一个五步SOP热点失败簇识别 → 临时兜底修复 → 根因修复 → 回归验证 → 知识沉淀。热点失败簇识别由质检模块自动完成每天扫一次坏样本聚类临时兜底修复是在根因还没定位时先给Agent加一条规则或话术避免最刺耳的错误持续出现根因修复走链路切片回归验证跑评测集最后把这次的失败样本和修复方式写入知识库和评测集防止下次再犯同一类错误。同时我把质检和排障的看板打通了。质检发现的热点问题会自动生成一个“专项频道”排障时直接在生产环境按这个主题去查链路日志不用再手工翻找关键词。整个团队的响应速度从“第二天发现”变成“两小时定位”。6. 高频问题速查表与几条避坑心得6.1 高频问题速查表之前的内容里已经散落了很多排查路径这里集中成一张速查表建议直接保存。现象可能原因最快排查动作参考处理回复明显胡编乱造检索未命中仍硬答查检索命中率与Prompt约束加“未命中必须拒答”加引用校验不理解长尾问法意图示例覆盖不足聚类用户失败问法补充同义问法与意图样本多轮对话忘了前文上下文截断策略太激进查上下文日志拼接情况调整窗口截断或引入会话摘要回复慢得像卡死模型过大或检索耗时高看链路耗时分布换小模型/加并发/优化检索大量空回复后处理校验过严或超时查降级日志放宽规则、增加重试新模型效果回退新模型与Prompt/参数不匹配跑离线回归对比按场景调Prompt或回滚知识库更新后变差新切片质量差、格式乱查新知识块召回记录重构切片A/B验证用户点踩集中在某主题该主题知识过时或不完整查该主题会话与检索命中更新知识库、调整意图Token成本飙升Prompt太长或模型规格过高看Token消耗分布精简Prompt、分级用模型速查表的用法是“先数据后猜测”。遇到问题时拿表里对应行的“最快排查动作”先做不要一上来就怀疑是模型问题。6.2 避坑心得几条真正让我长记性的经验第一不要只看“回答成功”指标。成功代表“没报错”不代表“答对了”。我见过最离谱的情况是Agent每次回复都是“亲这个问题我建议您联系在线客服哦”成功率99%用户满意度0。内容质量才是质检的核心。第二质检样本不要纯随机抽。随机抽样本问题是分散的每类问题只看到一两个修起来无从下手。改成按主题聚类后再抽先抽到“簇”把主要矛盾找出来。样本利用率能差出好几倍。第三LLM当裁判打分时一定要抽样人工复核。大模型裁判对结构清晰的长答案异常偏爱会把一些冗长但信息密度低的回复打出高分。每次跑LLM质检我都要抽20%让人工看一遍校准分数防止裁判本身偏心。第四日志字段一定要在上线前规划好。上线之后想补字段必须经过去重、补登、迁移成本极高而且历史数据可能根本补不回来。自己项目省过这笔账的都知道晚规划多付的时间成本绝不止一倍。第五告警阈值不要拍脑袋。直接套用其他项目的“95%成功率”可能让运维天天被骚扰也可能让真正的问题漏掉。正确做法是先收集7到14天运行数据把正常基线的上下界画出来再在基线的边界上设阈值外加最小样本量防抖动。第六知识库更新必须走回归。我踩过最痛的坑就是直接改知识库上线结果没回归另一个场景的准确率掉了15个点。自那之后所有知识库变更都纳入发布卡点先跑评测集再上。第七不要一上来就微调。微调成本高、周期长、回归面大很多问题用Prompt调整、知识库优化、后处理规则就能解决。想清楚“动哪一层”比“动不动模型”重要得多。在这几个Agent项目里来回跑过之后我最大的体会是持续优化不是一个技术问题而是一种工程习惯。不要指望模型一劳永逸也不要指望某一天“没有bug”出现。你要做的是让团队每个成员都习惯性地把一次失败会话当成输入把一次质检异常当成线索把一次线上问题当成改进机会。我建议每个Agent项目团队至少每周留一个固定的质检复盘时段把质检、自学习、排障三条线的人拉到同一个会里过一遍上周的热点失败簇、修复情况、新上线版本的回退情况。这半小时可能比蹲两周代码更能提升Agent的整体质量。长期来看AI Agent的竞争力从来不在于上线那天的完美而在于上线后100天里你的迭代速度能不能跑在用户预期恶化之前。
