好的架构不是设计出来的，是被问题逼出来的。本文以 5 个关键的架构决策为主线，串起整个系统的设计。

先想清楚问题：为什么通用RAG问答系统方案不适用？

电商客服 Agent 和通用RAG问答系统看起来很像——都是一个对话框。大多数团队的自然起步是搭一个标准 RAG 问答系统：文档切片 → 向量嵌入 → 语义检索 → LLM 生成。但在客服场景下，这个通用RAG问答系统方案有四个致命缺陷：

• 意图混合：用户可能在同一句话里混了"查物流+问退款"。RAG 只会从文档里搜，无法区分"这个问题要调 API 查订单"还是"这个问题要翻商品说明书"——它只能把所有相关内容都塞给 LLM，让模型自己去猜
• 信息源异构：知识库（商品说明书，非结构化）和业务 API（查订单/退款，结构化）是完全不同的信息源，却要在同一个回答里整合。标准 RAG 只吃文档，对实时 API 数据毫无编排能力
• 延迟硬约束：用户等 2 秒就烦躁了，但一次完整的 Agent 对话（问题改写→安全审查→混合检索→答案生成，4 步流水线）动辄 10 秒级（qwen3.6-plus，最新实测 ~9.1s，详见第二篇）。通用方案没有任何"绕过 LLM"的快速通道
• 安全边界：退款这种操作不能 AI 说了算。通用 RAG 方案没有内置的人机协同机制——它要么回答，要么不回答，不存在"让我请示一下"的中间状态

这四个缺陷不是细节问题，是架构层面的约束。它们直接决定了后面的五个决策——下面逐一展开。

---

决策 1：为什么不做一个"全能 Agent"，而是拆成三个执行器？

最初只有一个 ReAct Agent，拿着全部 10 个工具。问题很快暴露：用户说"我的洗衣机到哪了？退款的话要多久？"，Agent 在 query-order、check-shipping、request-return 之间反复横跳，循环了 12 轮才停下来，答案还是错的。

根因不是模型不够好，而是工具的底层逻辑不同：查订单调 API（结构化、确定性），搜文档做 RAG（非结构化、语义化）。塞给一个 Agent 等于让它"同时做翻译和数学题"。

解法：用编排器在请求入口做一次路由分发，根据意图选择专职执行器：

• ReAct Agent：复杂多步任务（如"先查订单再退款"）
• GeneralAgent Executor：咨询类（如"这个洗衣机有什么功能"），走 RAG
• Direct Tool Dispatch：简单明确意图（如"查物流 GD123456"），绕开 LLM，<10ms

核心原则：“一次路由，不再回头”——执行器之间绝不互相调用。

一句话：通用方案（简单 RAG）和单体 ReAct Agent 都被我们否定了。 最终架构里的 ReAct Agent 已经不是一个"全能管家"了——它只负责复杂多步推理这一件事，工具集被大幅缩减。其余的交给 Direct Dispatch（规则路由）和 GeneralAgent（RAG 问答）。

---

决策 2：为什么不用 LangGraph Supervisor？

社区的标准方案是 Supervisor Agent 动态调度子 Agent。我们算了一笔账：每次调度多一次 LLM 调用。同一个 qwen-turbo API，我们实测 function calling（带 5 个工具 schema）的延迟是 p50=477ms、p95=672ms、p99=1200ms（50 条标注 query × 10 repeats = 500 次请求）。客服场景里，多 477ms 意味着用户发完消息后多等一个明显的卡顿。

更关键的是可靠性问题。实测 qwen-turbo Top-1 准确率 92%（460/500），这听起来不错——直到你看到按意图拆开的数字：query-order 只有 80%。“我的订单到哪了"这个问题被 10 次全部误判为 check-shipping——因为 LLM 看到了"到哪了”，语义上天然偏向物流。用户问订单状态，却被路由到快递查询，接下来就是一串错误的工具调用。按每天 1 万次请求算，约 800 次会被路由错误——这 800 次不只是延迟，是用户收到错误答案。

替代方案是规则+语义匹配（P0+P1，总延迟 <30ms），效果等价但零额外 LLM 调用。这不是"技术更好"，而是"场景定义的选择"。

---

决策 3：同义词归一化的三级设计

“不想要了”“退了吧”“申请退款”——对于系统来说都是一回事。但怎么做到？

• L1 静态映射表 <1ms：覆盖绝大多数常见表达
• L2 文本标准化：处理边缘的汉字变体和标点
• L3 LLM 兜底：只在极端情况启用

核心取舍：95% 的 case 不应该为极少数的边缘场景买单。

---

决策 4：技术栈选型原则

为什么不用 Coze/Dify？因为无法实现我们后面的 P0+P1+P2 自定义流水线。
为什么不用 AutoGen/CrewAI？因为对话链路不可控，商业场景合规风险高。
选型原则只有一个：每个组件的引入必须解决一个明确的、可验证的痛点。

---

决策 5：依赖拓扑与降级思维（从架构阶段就植入）

最坏情况推演：Qwen API 超时 + Milvus OOM + Redis 断连 + Embedding 挂了 → 退化到"Qwen2.5-1.5B-Instruct 本地 GPU 推理，无 RAG 增强直接回答"。不是完美的回答，但不再是 500。

这引出了贯穿整个系列的哲学：“能用工程手段替代 LLM 调用的，就不要用 LLM——5ms 的规则能解决的问题，凭什么花 500ms 调用大模型？”

---

四层架构图