一个团队用 Codex 等 AI 编程工具 最后失控了

寂静回声

一个团队用 Codex 等 AI 编程工具赶了几个月，做出一套客服 Agent 系统，覆盖在线客服和电话客服，首个版本上线后反而开始失控。

今年年初，Agent 的爆发让公司管理层看到了“智能体替代部分客服岗位”的可能性，于是很快给我们下达了客服 Agent 的建设目标，覆盖 App 在线客服和电话线路客服两大场景。
问题在于，我们团队并没有专门的 AI Agent 工程师，成员基本都是 Java 和前端开发。面对全新的技术栈，大家只能一边学习，一边借助 Codex 等 AI 编程工具完成系统设计、架构搭建和业务开发。
经过几个月的赶工，第一版终于上线了。
然而，真正的问题也从这一刻开始暴露。
上线后的实际效果远低于预期。系统频繁出现各种异常，但团队却很难定位真正的原因。大量核心代码都是 AI 自动生成的，代码结构复杂、抽象层级混乱，很多逻辑连开发人员自己都难以理解，更不用说进行维护和排查。
于是形成了一个恶性循环：代码看不懂，只能继续让 AI 帮忙修改；AI 修复了一个 Bug，却往往又引入新的问题。今天修好了 A，明天 B 又坏了，整个系统逐渐进入一种“越修越乱”的状态。
随着业务量增加，问题开始集中爆发。
电话线路一旦并发稍高，系统就会出现性能瓶颈甚至直接崩溃；在线客服和语音客服在对话过程中经常出现长时间沉默、响应超时、上下文丢失等问题，导致用户无法正常服务。
最终的结果并不是提升客服效率，而是让原本稳定运行的人工客服体系也受到影响。客服人员不得不频繁接管异常会话、处理系统故障、安抚用户投诉，整体工作效率反而比上线 Agent 之前更低。

AI 可以把"写代码"这件事变快，但它不会自动替团队定义架构边界，不会自动判断哪些逻辑应该硬编码，哪些能力应该配置化，也不会替你设计灰度、压测、回滚和可观测性。

管理层仅凭行业热点（Agent 爆发）确定项目目标，没有开展技术预研、POC 验证。
团队现状：仅有 Java、前端工程师，无 AI/Agent、大模型应用、语音对话系统专业人员；
决策缺陷：未评估团队能力缺口、未知技术栈风险，直接下达硬性交付指标，默认 “靠 AI 编程工具就能搞定复杂智能体系统”，高估了代码生成工具的能力。

软件工程原则：陌生领域项目必须先做 POC 验证核心风险点（语音并发、对话上下文持久化、Agent 状态管理），不能直接启动正式开发。


只要求 “做客服 Agent，覆盖在线 + 电话场景”，没有提前定义性能指标、准确率、故障率、会话可用率 SLA。
上线后才发现并发瓶颈、超时、上下文丢失，但事前没有设立基准阈值，无法早期识别系统不达标。


客服 Agent 不是简单对话接口，是混合系统：大模型调度、对话状态机、上下文存储、语音 ASR/TTS、电话线路网关、工单打通、会话接管、异常熔断、限流降级。
团队把智能体当成普通业务后台开发，忽视实时语音通信、长会话状态管理、大模型调用不稳定等特有复杂度。



正常流程：人设计架构、定义接口、梳理业务逻辑 → 编写 / 审查代码 → AI 辅助编码。
该团队流程倒置：大量核心业务代码直接由 AI 生成，开发者只负责 “运行、让 AI 改 bug”。
开发者没有吃透业务逻辑与代码实现；
AI 不理解全局架构约束，只解决局部问题；
违背核心准则：开发者必须拥有代码所有权，能够完整读懂、推演所有核心路径。


面对全新技术栈，没有先行输出统一架构规范：模块划分、数据流、状态存储、异步模型调用策略、异常处理规范。
直接后果：AI 产出代码抽象层级混乱、模块边界模糊，无统一设计范式，系统天然难以维护。



智能体系统常见刚需全部缺失：
对话上下文可靠持久化方案（导致上下文丢失）；
异步调用、超时控制、熔断限流（大模型调用不可靠，极易出现长时间沉默、响应超时）；
语音线路高并发下的资源隔离、队列管控（并发上升直接崩溃）；
没有区分 “大模型慢调用” 和传统 Java 同步业务，沿用普通 Web 服务架构承载实时对话场景。


上线前没有配套：链路追踪、会话日志全量留存、大模型调用耗时监控、异常会话告警、状态快照。
系统出故障后无法快速定位根因，只能盲调，陷入反复试错循环。



缺少分层测试策略
无单元测试：AI 生成代码几乎没有配套单测；
无集成测试、压力测试：上线前没有模拟电话高并发压测，性能瓶颈等到真实流量才暴露；
缺少灰度发布策略：没有小流量试运行验证在线客服、语音客服两条链路；直接全量上线冲击现有人工客服体系。


代码审查（CR）形同虚设，大量 AI 生成代码未经充分评审就合并入库。
评审核心前提：评审人能理解代码逻辑；当开发者自身都看不懂代码时，CR 完全失效。



遇到故障的对策：继续交给 AI 改代码，只修复表象。
不做根因分析（为什么超时？上下文在哪丢失？并发瓶颈来自哪一层？）；
缺少回归测试，修改一处引入多处新 Bug；
典型反模式：救火式修复，治标不治本，系统熵持续增加，越维护越混乱。



智能体不稳定时，缺少自动切人工客服的兜底机制。
一旦 Agent 会话异常，直接转化为用户投诉、人工客服被动处理故障，拖累原有稳定业务。
高风险系统必须具备：自动降级、会话一键转接人工、异常会话隔离。


上线前没有同步客服团队：异常如何识别、会话如何接管、故障上报路径。
系统故障出现后，人工客服额外承担排障工作，直接拉低整体效率。