LLM智能客服架构重构与优化

一次从"让 LLM 自由发挥"到"用状态机精确控制"的架构重构实践

最近我对自研的 AI 智能客服系统做了一次比较彻底的架构重构——V4 版本。这次重构的核心变化是：从向量记忆驱动转向了状态机驱动。

V4架构图：

简单说就是：以前每个环节都丢给 LLM 去"自由发挥"，现在用结构化状态 + 显式规则来控制流程。效果很直接——Token 消耗大幅降低、流程完全可控、可观测性也好了很多。

这篇文章分享一下这次重构的思路、做法和一些具体的代码实现。

先快速回顾一下这个系统的演化路径：

V3 已经是一个功能相对完整的系统了，但也暴露出一些问题。

在实际使用中，V3 有几个比较突出的问题：

这些问题本质上都是一个根源：过度依赖 LLM + 向量记忆，缺乏结构化的状态管理。

V4 的核心理念很简单：关键信息进槽位，流程控制靠规则，向量检索只在需要时调用。

整个架构由五个新模块支撑：

替代了 V3 中扁平的 dict 状态管理，将会话状态分为三层：

每个方法的返回值都是清晰的结构化数据，不再需要从一大段对话历史中去"猜测"当前状态。

V3 中每个用户输入都要调 LLM 来分析当前处于哪个阶段，V4 直接用规则搞定：

五个阶段构成完整销售流程：

每个阶段有明确的进入条件和推进规则，100% 可预测，零 token 消耗。

V3 中 prompt 是内联拼接的，随着对话进行越来越长。V4 用结构化构建器来严格控制：

每个部分都有限制上限，prompt 不会无限膨胀。

V4 最关键的一个变化：只有在 recommend / quote 阶段才触发向量检索。

这意味着：

减少了约60%+ 的向量检索调用。

用正则规则替代 LLM 提取关键信息，纯规则匹配，零消耗：

一个完整的 V4 对话处理流程如下：

关键节点模型分布：

V3 开始集成的 MCP（Model Context Protocol）在 V4 中继续发挥作用，让 AI 客服能直接调用企业现成的业务 API：

例如客户问"帮我查一下订单 ORD20240515001"，系统自动调用 MCP 工具实时查询订单状态并回复。整个过程对客户透明，对开发者来说就是配置一个 MCP Server 地址的事。

V4 重构的核心哲学变化是：

V3：所有记忆进向量库，LLM 自由发挥V4：结构化状态控制流程，向量检索仅作补充

这个思路其实不只在 AI 客服场景有用，任何依赖 LLM 做多轮交互的系统都可以借鉴：

项目地址：Ai 智能客服系统 V4 大升级/

如果你也在做类似的 AI 客服或对话系统，欢迎交流讨论。下篇可以聊聊具体的使用效果和一些踩坑记录。