- AppleWeb_C2026-09-15
最近看到一个团队做客服 Agent 的经历，感觉挺有代表性，想拿出来和大家讨论一下。
年初大模型 Agent 概念很火的时候，老板开会看到几个案例演示，当场就拍板："客服这块能不能上智能体，把人力成本降下来。"目标很明确：App 在线客服 + 电话客服，全部要接入 Agent。
现实是什么情况呢？我们组清一色 Java 后端加前端，没有一个人真正做过 AI 应用开发。任务下来了，只能硬着头皮上，一边啃资料一边靠 Codex 这类工具连蒙带猜地把系统架构、业务逻辑给堆起来。
说实话，效率是真高，几个月时间系统就能上线了，这一度让我们觉得"AI 编程"这条路走得通。
但上线才是噩梦的开始。
线上表现和预期差距很大：对话卡顿、响应超时、上下文动不动就丢，用户体验很差。更麻烦的是排查问题——代码基本都是 AI 一段段生成拼接起来的,架构风格前后不一致，很多地方套了好几层抽象，逻辑绕来绕去，写代码的人自己隔一周回头看都得重新理解一遍。
于是就陷入一个死循环：看不懂代码 → 只能让 AI 改 → AI 改完这个 Bug，那个模块又出问题 → 继续丢给 AI 修 → 又冒出新的坑。反反复复，代码越改越臃肿，谁也说不清系统现在到底是什么状态。
业务量一上来，问题彻底集中爆发：
- 电话客服线路并发稍微高一点，系统直接顶不住，出现明显性能瓶颈；
- 在线客服和语音客服经常莫名其妙沉默好几秒、请求超时，上下文断掉用户得重新说一遍问题；
- 出问题的频率高到人工客服团队不得不天天盯着，随时准备接管异常会话、安抚被系统坑到的用户。
结果就很讽刺：本来想靠 Agent 减少人工成本，现在人工团队反而要额外承担"系统维护"和"故障公关"的活，整体效率不升反降。
想请教一下遇到过类似情况的朋友：
- 这种"AI 生成代码但团队看不懂"的历史包袱，除了推倒重来还有没有别的解法？
- 是先缩小 Agent 的接待范围，只保留低风险、流程明确的场景？还是暂停新功能，把监控、压测、回归测试和人工接管机制补起来？
- 对于已经没人敢动的核心代码，该逐步替换，还是需要重做部分架构？
问问各位大神，这种情况怎么破局？
主楼 - Ming2026-09-15
帮佬换到搞七捻三的分区了，前沿快讯分区不对哦
- lafish2026-09-15
- HanJiang2026-09-15
要不试试让Astra大人全面重构一下
- Carlos2026-09-15
确实，都是阵痛
业务问题就在业务中解决
AI呼叫中心这种东西实际上也不是小厂单靠AI能短期搞定的，技术方案很多时候都需要去和资源方聊
代码问题，我建议现在暂停功能开发，开始整理 specs，梳理业务文档以及开发测试流程，严格执行，边做边改
- ClaudeCode2026-09-15
这种就是一开始用ai开发的时候没写好文档吧？我从opus4.6时代到现在的系统，写的都很规范，人都能看懂（除了注释实在是写的太多了，看着累），但是代码逻辑很好懂。实在不行astra全量重构下？
- Zephyr2026-09-15
感觉人看不懂的开发真挺容易出bug的，反正效率跟可靠目前来看不能兼得，astra这种重构不行的话，要么重来要么等后续更强的AI来重构来 ^-^
- ᴇɴᴄ2026-09-15
- asyu99122026-09-15
看起来像是不如直接全部重新做个新的（
- K.Kang2026-09-15
这就是典型的在电力时代把电动机装进为蒸汽机设计的厂房里
- 寂寞的欧尼酱2026-09-15
架构问题，还是要重做解决地干净、彻底。先制定一个过渡计划，慢慢重构系统。