领导拍板要做客服 Agent，现在代码没人看得懂了，求破局

最近看到一个团队做客服 Agent 的经历，感觉挺有代表性，想拿出来和大家讨论一下。

年初大模型 Agent 概念很火的时候，老板开会看到几个案例演示，当场就拍板："客服这块能不能上智能体，把人力成本降下来。"目标很明确：App 在线客服 + 电话客服，全部要接入 Agent。

现实是什么情况呢？我们组清一色 Java 后端加前端，没有一个人真正做过 AI 应用开发。任务下来了，只能硬着头皮上，一边啃资料一边靠 Codex 这类工具连蒙带猜地把系统架构、业务逻辑给堆起来。

说实话，效率是真高，几个月时间系统就能上线了，这一度让我们觉得"AI 编程"这条路走得通。

但上线才是噩梦的开始。

线上表现和预期差距很大：对话卡顿、响应超时、上下文动不动就丢，用户体验很差。更麻烦的是排查问题——代码基本都是 AI 一段段生成拼接起来的,架构风格前后不一致，很多地方套了好几层抽象，逻辑绕来绕去，写代码的人自己隔一周回头看都得重新理解一遍。

于是就陷入一个死循环：看不懂代码 → 只能让 AI 改 → AI 改完这个 Bug，那个模块又出问题 → 继续丢给 AI 修 → 又冒出新的坑。反反复复，代码越改越臃肿，谁也说不清系统现在到底是什么状态。

业务量一上来，问题彻底集中爆发：

• 电话客服线路并发稍微高一点，系统直接顶不住，出现明显性能瓶颈；


• 在线客服和语音客服经常莫名其妙沉默好几秒、请求超时，上下文断掉用户得重新说一遍问题；


• 出问题的频率高到人工客服团队不得不天天盯着，随时准备接管异常会话、安抚被系统坑到的用户。

结果就很讽刺：本来想靠 Agent 减少人工成本，现在人工团队反而要额外承担"系统维护"和"故障公关"的活，整体效率不升反降。

想请教一下遇到过类似情况的朋友：

1. 这种"AI 生成代码但团队看不懂"的历史包袱，除了推倒重来还有没有别的解法？


2. 是先缩小 Agent 的接待范围，只保留低风险、流程明确的场景？还是暂停新功能，把监控、压测、回归测试和人工接管机制补起来？


3. 对于已经没人敢动的核心代码，该逐步替换，还是需要重做部分架构？

问问各位大神，这种情况怎么破局？