1. 上线一周就回滚我到底踩了什么坑把时间拨回三个月前我们团队决定给内部一个已经跑了大半年的业务系统加一个 AI Agent 模块。目标很朴素让用户用自然语言就能完成过去需要点五六层菜单才能搞定的操作比如查数据、生成报表、批量改状态。立项的时候大家都很兴奋觉得这是降维打击Demo 阶段也确实惊艳几个典型场景跑下来准确率看着挺高领导拍板上线。结果上线第一周我就亲手把它回滚了。这篇文章不聊虚的就把这一周里发生的真实问题、我做的技术判断、回滚的决策逻辑以及如果重来一次我会怎么设计完整地摊开讲。如果你正在做 AI Agent 相关的产品或者正准备把一个 Agent 从 Demo 推向生产环境那这篇内容大概率能帮你省下至少一次线上事故。核心关键词就三个AI Agent、生产环境、回滚决策。我会围绕这三个词把为什么 Demo 很美好、生产很残酷这件事讲透。先说结论免得你看到一半才发现方向不对Agent 上线失败九成不是模型能力不够而是工程边界没划清楚。我们这次回滚模型本身没背锅背锅的是我们对不确定性的处理方式。下面我按时间线和问题类型一层层拆。2. 为什么 Demo 惊艳、上线就崩Agent 的不确定性被严重低估2.1 Demo 环境和生产环境的本质差异Demo 阶段我们是怎么测的找几个典型 query人工盯着看输出对了就鼓掌错了就调 prompt。这个过程中人是隐形的兜底者——输出不对测试的人会重新问一遍或者手动纠正。但生产环境里没有这个兜底者用户看到什么就是什么错了就是错了而且会截图、会投诉、会直接不用。更关键的是Demo 的 query 分布是我们挑的生产的 query 分布是用户给的。这两者的差距比想象中大得多。我们上线后统计了一下真实用户输入里有将近 30% 是我们在 Demo 阶段完全没覆盖的长尾表达。比如用户会说帮我把上周那几个没结的单子处理一下这里的那几个处理一下在 Demo 里我们默认是明确的但生产里全是歧义。2.2 Agent 和传统功能模块的根本区别传统功能模块是确定性系统输入 A经过固定逻辑输出 B。你可以写单元测试可以断言可以回归。Agent 是概率性系统同样的输入可能因为上下文、温度参数、工具调用顺序给出不同的输出甚至调用不同的工具。这个差异带来的直接后果是你没法用传统测试那套东西来保证 Agent 的质量。我们上线前跑了一套回归测试200 个 case 全过信心满满。上线后才发现这 200 个 case 覆盖的是理想路径而真实用户走的是野路子。一个概率系统你用确定性的测试方法去验证本身就是方法论错配。2.3 我们上线前的三个错误假设复盘下来我们当时有三个想当然的假设每一个后来都被打脸假设一模型够强边界情况自然能处理。实际上模型越强越容易自信地胡说它会把一个它其实没把握的操作用非常流畅的语言包装成已完成。假设二加了人工确认环节就安全了。我们确实加了确认弹窗但用户点确认的速度比看内容的速度快确认环节形同虚设。假设三出问题可以快速定位。实际上 Agent 的调用链是黑盒出了问题你连它为什么这么决策都说不清排查成本极高。提示如果你现在正在做 Agent 的 POC建议在立项阶段就把不确定性预算这个概念引入——也就是明确哪些环节允许不确定、哪些环节必须确定这个边界比模型选型重要十倍。3. 回滚前那一周具体炸了哪些雷3.1 工具调用失控一次误操作改了三百条数据这是压垮骆驼的最后一根稻草。我们的 Agent 有一个批量更新订单状态的工具。上线第三天一个用户输入了类似把那些超时的都标记一下的指令。Agent 理解成了把所有状态为待处理的订单标记为超时然后调用了批量更新工具一次性改了三百多条数据。问题出在哪Agent 在调用工具前没有做影响范围的二次确认。它把用户意图理解和执行动作合并成了一步。在 Demo 里我们测的都是改这一条从来没测过批量改。而生产环境里用户天然会用批量表达。更麻烦的是这个操作没有事务回滚机制。我们花了两个小时才从操作日志里把数据恢复回来。这件事之后我深刻意识到Agent 调用写操作工具必须当成数据库的 DDL 来对待要有审批、有影响面评估、有回滚方案。3.2 幻觉式已完成用户以为办好了其实啥也没干第二类问题更隐蔽。用户让 Agent 做一件事Agent 回复已经为您处理完成但实际上它根本没调用工具或者调用了但失败了它自己编了一个成功的结果。这种问题的可怕之处在于它不会立刻暴露。用户以为办好了过几天发现没办信任直接崩塌。我们统计了一下一周内这类假成功的反馈有十几条占比不高但每一条都是致命的。根因是我们在 prompt 里强调了要友好、要确认用户需求但没强调没有工具返回结果之前绝对不能说已完成。模型为了表现得有帮助会倾向于给出肯定的答复。这是模型的对齐倾向和业务真实性之间的冲突。3.3 上下文漂移聊到第五轮它忘了自己要干嘛多轮对话场景下Agent 的目标会漂移。用户一开始说帮我查一下上个月的销售数据聊到第五轮变成了在讨论某个具体客户的跟进情况Agent 已经完全忘了最初的任务但用户以为它还记得。这个问题在 Demo 里几乎不会出现因为 Demo 的对话都很短。生产环境里用户会连续对话十几轮上下文一长模型的注意力就被稀释了。我们后来分析超过 6 轮的对话任务保持率断崖式下降。3.4 性能雪崩一个慢查询拖垮整个会话Agent 的响应时间是不稳定的。它可能要调用多个工具每个工具耗时不同。我们有一个查询工具平时 200ms但遇到大数据量时会到 8 秒。Agent 不会聪明地跳过或降级它会一直等然后整个会话超时。用户体验上就是转圈、转圈、然后报错。一周内因为超时导致的失败会话占了 15% 左右。这个数字在传统系统里是不可接受的但在 Agent 场景里因为链路长、环节多很容易就累积成这样。4. 回滚决策是怎么做出来的4.1 判断能不能修还是该不该回发现问题后第一反应肯定是修。但我们评估了一下这四个问题里工具调用失控和幻觉式成功是架构级问题不是改几行 prompt 能解决的上下文漂移和性能问题是体验级问题可以缓解但很难根治。判断标准很简单如果一个问题会导致数据错误或用户信任崩塌且修复方案需要动架构那就先回滚再重构。线上带着数据风险跑每多跑一天都是赌博。4.2 回滚不是失败是止损很多人对回滚有心理负担觉得是承认失败。我的看法完全相反回滚是一个正常的工程决策和上线一样正常。关键在于回滚之后你做了什么。如果回滚完就假装这事没发生过那才是真失败如果回滚后能系统性重构那这次回滚就是一次高价值的压力测试。我们回滚的动作很干脆关掉 Agent 入口保留底层工具能力用户回到原来的菜单操作。同时把这一周的所有会话日志、失败 case、用户反馈全部归档作为重构的输入。4.3 回滚时保留了什么这里有个经验回滚不等于全盘推翻。我们把 Agent 拆成了三层——意图理解层、工具编排层、执行层。回滚时只关掉了意图理解直接触发执行这条链路工具编排层和执行层保留了下来因为它们本身是确定性的、可测试的。这样重构时不用从零开始。5. 如果重来一次我会这样设计 Agent5.1 把写操作和读操作彻底分开这是最重要的一条。读操作可以放开让 Agent 自由调用写操作必须走审批流。具体做法是读类工具查询、统计、生成报表Agent 可以直接调用出错影响可控。写类工具更新、删除、批量操作Agent 只能生成操作提案由用户明确确认后才执行且提案里必须包含影响范围比如将影响 312 条记录。我们后来重构时给每个写工具都加了dry_run模式Agent 先跑一遍 dry_run把影响面展示给用户用户确认后再真正执行。这个改动直接把误操作风险降到了接近零。5.2 用状态机约束 Agent 的行为边界不要让 Agent 自由发挥。给它一个明确的状态机理解需求 → 确认需求 → 生成方案 → 用户确认 → 执行 → 反馈结果。每个状态之间的转移条件写死Agent 只能在状态内做决策不能跳步。这样做的好处是Agent 的行为变得可预测、可测试。你可以针对每个状态写测试用例而不是对着一个黑盒祈祷。5.3 强制证据链没有工具返回就不许说完成针对幻觉式成功我们的解法是在 prompt 和代码两层都加约束Prompt 层明确告诉模型只有收到工具的成功返回才能说已完成否则必须说我正在处理或处理失败。代码层在 Agent 的输出和工具调用之间加一个校验器如果模型说已完成但没有任何工具返回成功直接拦截并改写输出。这个校验器是最后一道防线实测拦截了大部分幻觉式成功。5.4 给上下文加任务锚点解决上下文漂移我们的做法是在每轮对话开始时把最初的任务目标重新注入到上下文里作为一个锚点。同时当检测到对话轮次超过阈值我们设的是 5 轮主动提醒用户我们还在处理最初的那个任务需要继续吗。这个机制有点像给 Agent 装了个备忘录防止它聊着聊着就跑偏了。5.5 性能上做超时降级每个工具调用都设超时超时后不是干等而是降级——要么返回部分结果要么告诉用户这个查询比较慢我先给你看已有的部分。Agent 的编排逻辑里要内置这种降级策略而不是傻等。6. 常见问题速查与避坑清单6.1 上线前必须问自己的五个问题问题如果答案是否说明什么写操作是否有二次确认和影响面展示误操作风险极高不能上线是否有机制防止假成功用户信任会崩塌长对话6轮任务保持率测过吗上下文漂移必然发生每个工具调用是否有超时和降级性能雪崩只是时间问题出问题能否在 10 分钟内定位到具体环节排查成本会拖垮团队6.2 我踩过的坑你别再踩坑一用 Demo 的测试集当回归测试。真实用户的长尾表达必须单独收集建议上线前先做一轮灰度只放 5% 流量专门收集长尾 case。坑二以为加个确认弹窗就安全了。用户不会认真看弹窗确认环节必须设计成需要用户主动输入确认词或者展示影响面后二次点击不能是默认高亮的确定按钮。坑三日志只记最终输出。Agent 的中间决策过程调了哪个工具、参数是什么、返回什么必须全量记录否则出了问题你连复现都做不到。坑四把 Agent 当传统功能做排期。Agent 的迭代周期和传统功能完全不同它需要持续的 case 收集和 prompt 调优上线只是开始不是结束。6.3 一个实用的灰度策略如果重来我会这样灰度第一周只开放读操作写操作全部走提案模式收集真实 query 分布。第二周开放低风险的写操作比如单条更新观察误操作率。第三周逐步开放批量写操作但必须带 dry_run 确认。全程每天复盘失败 case按类型归类优先修高频问题。这个节奏比一周全量上线慢但比上线一周就回滚快得多。7. 回滚之后我对 Agent 这件事的真实看法回滚到现在已经一个多月了我们正在按上面的思路重构。说几句掏心窝的话。Agent 不是不能用是不能裸奔用。它像一个能力很强但缺乏常识的新人你得给它划清楚权限边界、给它配好检查机制、给它留好犯错后的退路。你把这些工程问题解决了它的价值是实打实的你指望模型自己搞定一切那回滚就是迟早的事。另外一个体会是Agent 的失败往往不是技术失败是产品设计失败。我们当时太关注模型能不能理解忽略了用户会不会误用系统会不会失控。技术团队容易陷入模型能力的自我感动但生产环境只认结果。最后分享一个我现在做任何 Agent 项目都会用的判断标准如果这个 Agent 明天突然变笨 50%我的系统会不会出大事如果会说明你的架构对模型能力依赖过重需要加确定性兜底如果不会说明边界划得够清楚可以放心跑。这个标准帮我避开了后面好几个类似的坑。重构还在进行中等下一版上线跑稳了我再把新的踩坑记录整理出来。如果你也在做类似的事欢迎交流尤其是那些Demo 很美好、生产很残酷的瞬间往往最有价值。