尧图网页设计 
好的架构不是设计出来的是被问题逼出来的。本文以 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咨询类如这个洗衣机有什么功能走 RAGDirect Tool Dispatch简单明确意图如查物流 GD123456绕开 LLM10ms核心原则“一次路由不再回头”——执行器之间绝不互相调用。一句话通用方案简单 RAG和单体 ReAct Agent 都被我们否定了。 最终架构里的 ReAct Agent 已经不是一个全能管家了——它只负责复杂多步推理这一件事工具集被大幅缩减。其余的交给 Direct Dispatch规则路由和 GeneralAgentRAG 问答。决策 2为什么不用 LangGraph Supervisor社区的标准方案是 Supervisor Agent 动态调度子 Agent。我们算了一笔账每次调度多一次 LLM 调用。同一个 qwen-turbo API我们实测 function calling带 5 个工具 schema的延迟是 p50477ms、p95672ms、p991200ms50 条标注 query × 10 repeats 500 次请求。客服场景里多 477ms 意味着用户发完消息后多等一个明显的卡顿。更关键的是可靠性问题。实测 qwen-turbo Top-1 准确率 92%460/500这听起来不错——直到你看到按意图拆开的数字query-order 只有 80%。“我的订单到哪了这个问题被 10 次全部误判为 check-shipping——因为 LLM 看到了到哪了”语义上天然偏向物流。用户问订单状态却被路由到快递查询接下来就是一串错误的工具调用。按每天 1 万次请求算约 800 次会被路由错误——这 800 次不只是延迟是用户收到错误答案。替代方案是规则语义匹配P0P1总延迟 30ms效果等价但零额外 LLM 调用。这不是技术更好而是场景定义的选择。决策 3同义词归一化的三级设计“不想要了”“退了吧”“申请退款”——对于系统来说都是一回事。但怎么做到L1 静态映射表 1ms覆盖绝大多数常见表达L2 文本标准化处理边缘的汉字变体和标点L3 LLM 兜底只在极端情况启用核心取舍95% 的 case 不应该为极少数的边缘场景买单。决策 4技术栈选型原则为什么不用 Coze/Dify因为无法实现我们后面的 P0P1P2 自定义流水线。为什么不用 AutoGen/CrewAI因为对话链路不可控商业场景合规风险高。选型原则只有一个每个组件的引入必须解决一个明确的、可验证的痛点。决策 5依赖拓扑与降级思维从架构阶段就植入最坏情况推演Qwen API 超时 Milvus OOM Redis 断连 Embedding 挂了 → 退化到Qwen2.5-1.5B-Instruct 本地 GPU 推理无 RAG 增强直接回答。不是完美的回答但不再是 500。这引出了贯穿整个系列的哲学“能用工程手段替代 LLM 调用的就不要用 LLM——5ms 的规则能解决的问题凭什么花 500ms 调用大模型”四层架构图资料展示下面是我整理的AI大模型学习资料和工具包预览适合收藏后按主题逐步学习。如果你想看完整资料目录可以在评论区留言「资料」也欢迎告诉我你更关注AI大模型里的哪类内容。 手把手教你搭建智能客服系统
好的架构不是设计出来的是被问题逼出来的。本文以 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咨询类如这个洗衣机有什么功能走 RAGDirect Tool Dispatch简单明确意图如查物流 GD123456绕开 LLM10ms核心原则“一次路由不再回头”——执行器之间绝不互相调用。一句话通用方案简单 RAG和单体 ReAct Agent 都被我们否定了。 最终架构里的 ReAct Agent 已经不是一个全能管家了——它只负责复杂多步推理这一件事工具集被大幅缩减。其余的交给 Direct Dispatch规则路由和 GeneralAgentRAG 问答。决策 2为什么不用 LangGraph Supervisor社区的标准方案是 Supervisor Agent 动态调度子 Agent。我们算了一笔账每次调度多一次 LLM 调用。同一个 qwen-turbo API我们实测 function calling带 5 个工具 schema的延迟是 p50477ms、p95672ms、p991200ms50 条标注 query × 10 repeats 500 次请求。客服场景里多 477ms 意味着用户发完消息后多等一个明显的卡顿。更关键的是可靠性问题。实测 qwen-turbo Top-1 准确率 92%460/500这听起来不错——直到你看到按意图拆开的数字query-order 只有 80%。“我的订单到哪了这个问题被 10 次全部误判为 check-shipping——因为 LLM 看到了到哪了”语义上天然偏向物流。用户问订单状态却被路由到快递查询接下来就是一串错误的工具调用。按每天 1 万次请求算约 800 次会被路由错误——这 800 次不只是延迟是用户收到错误答案。替代方案是规则语义匹配P0P1总延迟 30ms效果等价但零额外 LLM 调用。这不是技术更好而是场景定义的选择。决策 3同义词归一化的三级设计“不想要了”“退了吧”“申请退款”——对于系统来说都是一回事。但怎么做到L1 静态映射表 1ms覆盖绝大多数常见表达L2 文本标准化处理边缘的汉字变体和标点L3 LLM 兜底只在极端情况启用核心取舍95% 的 case 不应该为极少数的边缘场景买单。决策 4技术栈选型原则为什么不用 Coze/Dify因为无法实现我们后面的 P0P1P2 自定义流水线。为什么不用 AutoGen/CrewAI因为对话链路不可控商业场景合规风险高。选型原则只有一个每个组件的引入必须解决一个明确的、可验证的痛点。决策 5依赖拓扑与降级思维从架构阶段就植入最坏情况推演Qwen API 超时 Milvus OOM Redis 断连 Embedding 挂了 → 退化到Qwen2.5-1.5B-Instruct 本地 GPU 推理无 RAG 增强直接回答。不是完美的回答但不再是 500。这引出了贯穿整个系列的哲学“能用工程手段替代 LLM 调用的就不要用 LLM——5ms 的规则能解决的问题凭什么花 500ms 调用大模型”四层架构图资料展示下面是我整理的AI大模型学习资料和工具包预览适合收藏后按主题逐步学习。如果你想看完整资料目录可以在评论区留言「资料」也欢迎告诉我你更关注AI大模型里的哪类内容。