最近看到一个团队做客服 Agent 的经历，感觉挺有代表性，想拿出来和大家讨论一下。 年初大模型 Agent 概念很火的时候，老板开会看到几个案例演示，当场就拍板："客服这块能不能上智能体，把人力成本降下来。"目标很明确：App 在线客服 + 电话客服，全部要接入 Agent。 现实是什么情况呢？我们组清一色 Java 后端加前端，没有一个人真正做过 AI 应用开发。任务下来了，只能硬着头皮上，一边啃资料一边靠 Codex 这类工具连蒙带猜地把系统架构、业务逻辑给堆起来。 说实话，效率是真高，几个月时间系统就能上线了，这一度让我们觉得"AI 编程"这条路走得通。 但上线才是噩梦的开始。 线上表现和预期差距很大：对话卡顿、响应超时、上下文动不动就丢，用户体验很差。更麻烦的是排查问题——代码基本都是 AI 一段段生成拼接起来的,架构风格前后不一致，很多地方套了好几层抽象，逻辑绕来绕去，写代码的人自己隔一周回头看都得重新理解一遍。 于是就陷入一个死循环：看不懂代码 → 只能让 AI 改 → AI 改完这个 Bug，那个模块又出问题 → 继续丢给 AI 修 → 又冒出新的坑。反反复复，代码越改越臃肿，谁也说不清系统现在到底是什么状态。 业务量一上来，问题彻底集中爆发： 电话客服线路并发稍微高一点，系统直接顶不住，出现明显性能瓶颈； 在线客服和语音客服经常莫名其妙沉默好几秒、请求超时，上下文断掉用户得重新说一遍问题； 出问题的频率高到人工客服团队不得不天天盯着，随时准备接管异常会话、安抚被系统坑到的用户。 结果就很讽刺：本来想靠 Agent 减少人工成本，现在人工团队反而要额外承担"系统维护"和"故障公关"的活，整体效率不升反降。 想请教一下遇到过类似情况的朋友： 这种"AI 生成代码但团队看不懂"的历史包袱，除了推倒重来还有没有别的解法？ 是先缩小 Agent 的接待范围，只保留低风险、流程明确的场景？还是暂停新功能，把监控、压测、回归测试和人工接管机制补起来？ 对于已经没人敢动的核心代码，该逐步替换，还是需要重做部分架构？ 问问各位大神，这种情况怎么破局？ 4 个帖子 - 4 位参与者 阅读完整话题

  • 情报分类：服务器与云资源
  • 分类依据：内容涉及服务器、云资源或网络线路
  • 信息来源：服务器 / LINUX DO - 最新话题
  • 发布时间：2026/9/15 16:06:53