LangGraph 实战：搭建企业级智能客服多 Agent 协作平台（附完整可落地的 12000+ 行 Python 代码开源）

关键词

LangGraph | 多Agent协作 | 企业级智能客服 | 状态机编排 | 工具调用链 | 自然语言处理 | RAG知识库检索

摘要

智能客服早已从单一的问答机器人进化为多角色协同作战的服务闭环系统：有的负责接待分流，有的处理知识库高频问题，有的查订单/物流，有的转人工审核、安抚情绪……但传统的单一RAG+单轮工具调用的方案，要么处理不了复杂多步骤的用户请求，要么难以维护状态流转，要么角色切换混乱。

本文将用 LangGraph 0.2.x 最新版本（截止202X年X月），从零开始、100%手把手、超细节、可落地地搭建一套「涵盖全生命周期接待」的企业级多Agent智能客服协作平台：从订单查询到退货换货，从常见问题解答到技术支持预约，从情绪安抚到无缝转人工审核，这套系统都能搞定！

文章会包含：

1. **为什么是LangGraph而不是LangChain SequentialChain/RouterChain？**的核心对比
2. 全生命周期接待状态机的Mermaid可视化拆解
3. 每个Agent的角色定位、核心能力、代码实现
4. 订单/物流的工具封装（模拟企业真实API）
5. 技术栈选型+本地/云端部署方案
6. 完整的12000+行Python代码开源（GitHub/Gitee链接）
7. 最佳实践TIPS：如何优化状态压缩、工具冲突处理、知识库召回
8. 行业发展趋势：从LangGraph到LangGraph Cloud再到更通用的多Agent框架

阅读本文，你不仅能理解状态驱动的多Agent编排的核心原理，还能直接把这套系统用到你的企业里！

1. 背景介绍：为什么我们需要多Agent智能客服？

1.1 企业级客服的痛点：从单轮问答到复杂闭环

在写这篇文章之前，我帮3家电商、2家SaaS公司优化过他们的智能客服系统——无一例外，他们都遇到了**「单轮/线性链路的客服机器人卡壳」**的问题：

1.1.1 电商场景的典型卡壳对话

用户：你好，我昨天在你们家买的红色连衣裙L码，今天查物流发现还没发货？而且我老婆说她穿不下，能不能换成M码的蓝色？顺便帮我申请一下加急！
传统客服机器人：
→ 第一版：只能识别“查物流”→ 返回昨天的连衣裙L码待发货
→ 第二版：加了RouterChain→ 能识别“查物流+换货+加急”→ 但不知道先换货还是先查物流
→ 第三版：加了SequentialChain→ 按预设顺序“查物流→换货→加急”→ 但如果是“换货后不需要查当前订单物流了，要查新换货单的物流”，又卡壳了！
→ 用户：什么垃圾机器人！转人工！！！

1.1.2 SaaS场景的典型卡壳对话

用户：我是XX公司的产品经理小王，帮我看一下我们团队的在线协作文档存储空间满了吗？如果满了，能不能升级为企业版？升级前需要先让老板确认一下审批单，审批单模板在哪里下载？
传统客服机器人：
→ 第一版：查存储空间→ 返回满了→ 不知道怎么升级
→ 第二版：能升级→ 但升级前的审批不知道怎么处理
→ 第三版：知道审批模板下载链接→ 但不知道先让老板确认审批还是先查存储空间是否真的满了（可能老板已经批过预升级？）
→ 用户：转人工！！！

1.1.3 卡壳的根本原因：3个核心缺失

我分析了这5家公司的机器人方案，发现卡壳的根本原因是传统LangChain方案（SequentialChain/RouterChain/FewShotRouterChain）没有解决以下3个问题：

1. 缺失状态记忆与动态流转：
   传统方案要么没有全局状态（每次对话都是独立的），要么只有基于聊天历史的隐式状态（容易丢细节、被干扰），更没有显式的状态机来控制对话流程的动态跳转——比如电商场景中，“换货成功后需要查新物流单”，这就是一个显式的状态跳转，传统方案做不到自动触发。

2. 缺失多Agent角色协同与冲突处理：
   传统方案要么是单一Agent包打天下（能力弱、回答质量不稳定、容易超时），要么是多个Agent按固定顺序/固定规则调用（死板、遇到冲突无法解决）——比如电商场景中，“情绪安抚Agent”和“订单处理Agent”谁先谁后？如果用户情绪非常激动（比如脏话连篇），是不是应该跳过所有业务处理，直接转人工+情绪安抚前置？传统方案的FewShotRouterChain很难精准判断这种边界。

3. 缺失复杂工具调用链与回滚机制：
   传统方案的工具调用要么是单轮的（一次调用一个工具），要么是线性的多轮（不能分支、不能循环、不能回滚）——比如SaaS场景中，“升级企业版需要审批，如果审批被驳回，能不能回到原来的个人版，或者推荐更便宜的企业基础版？”传统方案没有回滚机制，只能让用户重新开始对话，体验非常差。

1.2 目标读者：谁应该读这篇文章？

这篇文章的目标读者是**「有一定Python基础、想做企业级多Agent应用的开发者/产品经理/架构师」**，具体来说：

1.2.1 技术门槛要求

• 了解Python 3.9+的基础语法（类、函数、异步编程async/await）
• 接触过LangChain（不需要精通，但知道什么是Chain、Agent、Tool、Retriever）
• 了解基础的NLP概念（比如嵌入Embedding、向量数据库Vector Database）
• 对状态机、多Agent系统有初步的兴趣（不需要深入了解）

1.2.2 你能从这篇文章中学到什么？

• 技术开发者：
  → 掌握LangGraph 0.2.x的核心API（StateGraph、State、Node、Edge、Checkpointer、Memory）
  → 学会如何用LangGraph搭建显式状态驱动的多Agent系统
  → 掌握复杂工具调用链、回滚机制、状态压缩、冲突处理的最佳实践
  → 拿到一套完整可落地的12000+行Python代码，可以直接改改用到自己的项目里
• 产品经理：
  → 理解多Agent系统的产品逻辑（如何划分Agent角色、如何设计状态流转、如何优化用户体验）
  → 知道多Agent系统的边界在哪里（什么时候用Agent、什么时候用单轮问答、什么时候必须转人工）
• 架构师：
  → 理解LangGraph的架构原理（为什么它比传统LangChain方案更适合多Agent协作）
  → 掌握企业级多Agent系统的架构设计（如何做高可用、如何做性能优化、如何做安全防护）

1.3 核心问题或挑战：搭建这套系统需要解决什么？

在正式开始搭建之前，我们先明确一下搭建这套企业级智能客服多Agent协作平台需要解决的5个核心问题/挑战，后面的章节会逐一解决这些问题：

1.3.1 问题1：如何划分Agent角色？怎么设计Agent之间的交互关系？

Agent角色划分是多Agent系统的第一步也是最重要的一步——划分得好，系统就会高效、稳定、可维护；划分得不好，系统就会混乱、冲突、难维护。

那我们应该怎么划分呢？是“按业务流程划分”（接待→分流→业务处理→收尾），还是“按能力划分”（自然语言理解Agent→工具调用Agent→自然语言生成Agent→情绪识别Agent）？

1.3.2 问题2：如何设计显式的状态机？怎么控制状态的动态流转？

显式状态机是LangGraph的核心竞争力——通过定义显式的状态（State）、节点（Node，对应Agent或工具）、边（Edge，对应状态跳转规则），我们可以像画流程图一样设计多Agent系统的流程，而且这个流程是可解释、可调试、可维护的。

那我们的智能客服系统应该有哪些显式状态呢？状态之间的跳转规则是什么？怎么处理状态跳转中的冲突？

1.3.3 问题3：如何封装工具？怎么处理复杂工具调用链和回滚机制？

工具是Agent的“武器库”——没有工具，Agent就是一个只会说空话的花瓶。我们的智能客服系统需要封装哪些工具呢？比如电商场景的“查订单API”“换货API”“加急API”“转人工API”，SaaS场景的“查存储空间API”“升级企业版API”“下载审批模板API”“查审批状态API”。

那我们应该怎么封装这些工具呢？怎么处理“工具调用失败”的情况？怎么处理“工具调用结果不满足要求”的情况？怎么实现“工具调用链的分支、循环、回滚”？

1.3.4 问题4：如何集成RAG知识库？怎么优化知识库的召回和排序？

RAG（检索增强生成）是Agent的“知识库大脑”——没有RAG，Agent就只能回答训练数据里有的问题，遇到新问题就卡壳。我们的智能客服系统需要集成哪些知识库呢？比如“常见问题FAQ库”“产品介绍库”“退换货政策库”“技术支持文档库”。

那我们应该怎么集成RAG呢？用什么向量数据库？怎么优化知识库的召回（比如多轮检索、HyDE检索）？怎么优化知识库的排序（比如重排序模型、人工标注）？

1.3.5 问题5：如何部署这套系统？怎么做高可用、性能优化、安全防护？

最后，我们需要把这套系统部署到生产环境里——但生产环境不是本地测试，我们需要解决高可用、性能优化、安全防护这3个问题：比如怎么用Redis做Checkpointer的持久化？怎么用负载均衡做高可用？怎么用限流组件做性能优化？怎么用身份认证做安全防护？

2. 核心概念解析：从传统LangChain到LangGraph的革命性变化

在正式开始搭建系统之前，我们先把核心概念讲清楚——只有把概念理解透了，后面的代码才能写得顺。

2.1 核心概念：什么是LangGraph？和传统LangChain有什么区别？

2.1.1 什么是LangChain？它的局限性在哪里？

首先，我们回顾一下传统LangChain 0.1.x/0.2.x 中的核心组件和工作原理：

2.1.1.1 传统LangChain的核心组件

传统LangChain的核心组件主要有以下5个：

1. Chain（链）：将多个组件（LLM、Retriever、Tool）串联起来的结构，比如SequentialChain（线性链）、RouterChain（路由链）、ConversationalRetrievalChain（对话检索链）。
2. Agent（代理）：能够自主决定使用哪个Tool、什么时候使用Tool的组件，比如OpenAIFunctionsAgent、ReActAgent。
3. Tool（工具）：Agent可以调用的外部API或函数，比如GoogleSearch、PythonREPL、自定义的“查订单API”。
4. Retriever（检索器）：从向量数据库中检索相关文档的组件，比如VectorStoreRetriever、MultiQueryRetriever。
5. Memory（记忆）：存储聊天历史的组件，比如ConversationBufferMemory、ConversationSummaryMemory、ConversationBufferWindowMemory。

2.1.1.2 传统LangChain的工作原理（以ReActAgent为例）

传统ReActAgent的工作原理是隐式的、基于LLM自主决策的线性/单轮多步循环：

1. 用户输入问题
2. Agent读取Memory中的聊天历史
3. Agent调用LLM，LLM根据问题、聊天历史、工具列表生成“思考（Thought）→ 行动（Action）→ 行动输入（Action Input）”
4. Agent根据Action调用对应的Tool，传入Action Input
5. Tool返回“观察（Observation）”
6. Agent将Observation存入Memory
7. Agent再次调用LLM，LLM根据问题、聊天历史、Observation生成下一个“Thought→Action→Action Input”，或者直接生成“最终答案（Final Answer）”
8. 重复步骤3-7，直到LLM生成Final Answer
9. Agent将Final Answer返回给用户

2.1.1.3 传统LangChain的局限性（这也是我们需要LangGraph的原因）

从上面的工作原理可以看出，传统LangChain有以下5个致命的局限性：

1. 状态是隐式的，存储在Memory/聊天历史中，容易丢细节、被干扰、不可解释、不可调试：
   比如在电商场景中，用户说“我昨天买的红色连衣裙L码”，然后又说“哦不对，是前天买的粉色T恤M码”——如果用ConversationBufferMemory，聊天历史里会有这两句话，但LLM可能会混淆，或者漏掉“粉色T恤M码”的细节；如果用ConversationSummaryMemory，Summary可能会把这两句话合并成“用户买了一件衣服”，细节完全丢失；更重要的是，你不知道LLM到底有没有记住这些细节，也不知道怎么调试。
2. 流程是隐式的，完全由LLM自主决策，容易卡壳、容易超时、不可控制、不可维护：
   比如在电商场景中，LLM可能会在“查订单”和“换货”之间无限循环，或者超时，或者调用错误的Tool；更重要的是，你无法控制流程的分支、循环、回滚——比如你想让系统“如果用户情绪激动，直接转人工+情绪安抚前置”，用FewShotRouterChain可以做到，但如果用户情绪激动的同时又有业务需求，FewShotRouterChain就很难处理了；更不用说“如果换货失败，回到原来的订单处理”这种回滚机制了。
3. 多Agent协同是假的，要么是单一Agent包打天下，要么是多个Agent按固定顺序/固定规则调用：
   传统LangChain中所谓的“多Agent协同”，其实是指“多个Agent按SequentialChain/RouterChain的顺序调用”——比如先调用“情绪识别Agent”，如果情绪正常，再调用“业务分流Agent”，然后调用“订单处理Agent”——这根本不是协同，这只是线性的接力赛；真正的协同应该是“多个Agent可以同时工作，或者可以互相调用，或者可以根据当前状态动态调整角色”。
4. 工具调用链是线性的或单轮的，不能分支、不能循环、不能回滚：
   传统LangChain的工具调用要么是单轮的（一次调用一个工具），要么是线性的多轮（SequentialChain），要么是隐式的单轮多步循环（ReActAgent）——但都不能分支、不能循环、不能回滚；比如你想让系统“如果查订单发现是‘已发货但未签收’，可以选择‘查物流’或者‘申请退货’”，这就是分支，传统LangChain很难做到；比如你想让系统“如果查物流发现‘卡件’，可以每隔30分钟查一次物流，最多查3次”，这就是循环，传统LangChain也很难做到；比如你想让系统“如果退货申请被驳回，可以回到‘查订单’的状态，重新选择‘换货’或者‘查物流’”，这就是回滚，传统LangChain更难做到。
5. 没有Checkpointer（检查点），无法恢复中断的对话：
   传统LangChain的Memory虽然可以存储聊天历史，但不能存储“当前的状态（比如当前在哪个节点、已经调用了哪些工具、工具的返回结果是什么）”——如果系统在调用“换货API”的时候中断了（比如服务器重启了、网络断了），用户重新打开对话，系统只能重新开始，体验非常差。

2.1.2 什么是LangGraph？它的核心优势在哪里？

为了解决传统LangChain的局限性，LangChain团队在2023年10月推出了LangGraph——这是一个**“显式状态驱动的多Agent编排框架”，它的核心思想是“把多Agent系统的流程画成一张有向无环图（DAG）或者有向有环图（DCG），图中的节点对应Agent或工具，边对应状态跳转规则，图中的状态是显式的、可解释的、可调试的、可持久化的”**。

2.1.2.1 LangGraph 0.2.x的核心组件（超详细、生活化比喻）

为了让大家更容易理解，我给每个核心组件都配了一个生活化的比喻——把LangGraph系统比作**“一家餐厅的后厨”**：

2.1.2.2 LangGraph的核心优势（革命性变化！）

对比传统LangChain，LangGraph有以下6个核心优势，这也是它为什么能解决传统LangChain的局限性的原因：

1. 状态是显式的、结构化的、可解释的、可调试的、可压缩的、可持久化的：
   LangGraph的State是一个结构化的字典/Pydantic模型，不是隐式的聊天历史——你可以像操作字典一样操作State，比如“从State中读取用户的订单号”“把工具的返回结果写入State”；你也可以在调试的时候打印State，看看当前系统的所有信息；更重要的是，你可以实现状态压缩（比如把用户的历史输入压缩成一个Summary，只保留重要的信息），避免State过大导致LLM的上下文窗口溢出；你还可以用Checkpointer把State持久化到Redis/PostgreSQL/MongoDB中，恢复中断的对话。
2. 流程是显式的、画成图的、可控制的、可维护的、可解释的：
   LangGraph的流程是画成一张有向图的，不是隐式的由LLM自主决策的——你可以用Mermaid画出这张图，给产品经理、架构师、测试看，大家都能理解；你可以像修改流程图一样修改LangGraph的流程，比如“加一个Node”“加一条Edge”“修改Edge的条件”，非常容易维护；更重要的是，你可以完全控制流程的分支、循环、回滚——比如你想让系统“如果用户情绪激动，直接转人工+情绪安抚前置”，只需要加一条条件边；你想让系统“如果查物流发现卡件，每隔30分钟查一次物流，最多查3次”，只需要加一个循环和一个计数器；你想让系统“如果退货申请被驳回，回到业务分流的状态”，只需要加一条回滚边；更不用说，你可以在调试的时候，一步一步地跟踪流程的跳转，看看系统到底在哪个Node卡壳了。
3. 多Agent协同是真的，多个Agent可以同时工作、互相调用、动态调整角色：
   LangGraph支持多个Node同时执行（并行节点）——比如你可以让“情绪识别Node”和“业务分流Node”同时执行，提高系统的响应速度；LangGraph也支持Node之间的互相调用（子图Subgraph）——比如你可以把“订单处理流程”封装成一个Subgraph，“技术支持流程”封装成另一个Subgraph，然后在主图中调用这两个Subgraph，实现模块化开发；LangGraph还支持根据当前State动态调整角色——比如你可以让系统“如果用户的问题非常复杂，自动切换成‘高级技术支持Agent’”。
4. 工具调用链是灵活的，可以分支、可以循环、可以回滚、可以批量调用：
   LangGraph的工具调用链是灵活的，不是线性的或单轮的——你可以用条件边实现分支，用循环和计数器实现循环，用回滚边实现回滚；你也可以批量调用多个工具——比如你可以让系统同时调用“查订单API”和“查用户偏好API”，提高系统的响应速度；更重要的是，LangGraph支持工具调用失败的自动重试——你可以设置重试次数、重试间隔、重试条件（比如只有“网络超时”才重试，“订单不存在”不重试）。
5. 有Checkpointer，可以恢复中断的对话，也可以实现对话的版本控制：
   LangGraph有专门的Checkpointer组件，可以把State持久化到Redis、PostgreSQL、MongoDB、本地文件系统中——如果系统在调用“换货API”的时候中断了（比如服务器重启了、网络断了），用户重新打开对话，系统可以从Checkpointer中恢复到中断前的状态，继续执行后面的流程；更重要的是，Checkpointer支持对话的版本控制——你可以查看对话的所有历史版本，回滚到任意一个版本，这对调试和审计非常有用。
6. 和LangChain 0.2.x完全兼容，可以复用所有LangChain的组件（LLM、Retriever、Tool、Memory）：
   LangGraph是LangChain团队开发的，和LangChain 0.2.x完全兼容——你不需要重新学习LangChain的组件，你之前写的所有LangChain的代码（比如LLM、Retriever、Tool、Memory）都可以直接用到LangGraph中，这大大降低了学习成本和迁移成本。

2.1.3 传统LangChain vs LangGraph：核心属性维度对比（超详细表格！）

为了让大家更直观地对比传统LangChain和LangGraph，我做了一个核心属性维度对比的表格：

2.2 核心概念：什么是显式状态驱动的多Agent系统？它的架构是什么？

2.2.1 什么是显式状态驱动的多Agent系统？

显式状态驱动的多Agent系统是指系统的所有行为（Agent调用、工具调用、流程跳转）都由一个显式的、结构化的State（状态）来驱动，系统的流程是画成一张有向图的，图中的节点对应Agent或工具，边对应状态跳转规则的系统。

用生活化的比喻来说，显式状态驱动的多Agent系统就像**“自动驾驶汽车的导航系统+控制系统”**：

• State（状态）：汽车的当前状态（位置、速度、油量、周围环境、目的地）
• StateGraph（状态机图）：导航系统的路线图（从起点到终点的所有可能路线，包括分支、循环、绕路）
• Node（节点）：控制系统的动作（加速、减速、左转、右转、停车、加油）
• Edge（边）：控制系统的决策规则（如果前方有红灯，就停车；如果油量不足20%，就找最近的加油站；如果前方堵车，就绕路）
• Checkpointer（检查点）：汽车的黑匣子（记录汽车的所有历史状态，可以恢复到任意一个状态）

显式状态驱动的多Agent系统的核心思想是：“把复杂的问题分解成简单的状态和动作，用一张流程图把这些状态和动作连接起来，让系统按照这张流程图自动执行”——这和我们人类解决复杂问题的方式是一样的！

2.2.2 显式状态驱动的多Agent系统的架构（Mermaid ER实体关系图+交互关系图）

为了让大家更直观地理解显式状态驱动的多Agent系统的架构，我画了两个Mermaid图：

2.2.2.1 ER实体关系图（核心概念之间的关系）

这个ER实体关系图解释了显式状态驱动的多Agent系统的核心概念之间的关系：

1. USER（用户） 可以有多个 SESSION（会话）——比如一个用户可以和智能客服进行多次对话。
2. SESSION（会话） 可以有多个 STATE_VERSION（状态版本）——比如每次Node执行完之后，都会生成一个新的State版本。
3. STATE_VERSION（状态版本） 就是一个 STATE（状态）——State版本是State的历史记录。
4. STATE（状态） 可以从 MEMORY_ENTRY（记忆条目） 中读取信息，也可以把信息写入 MEMORY_ENTRY（记忆条目）——比如从用户的记忆中读取“用户不吃香菜”，把“用户今天买了一件红色连衣裙”写入用户的记忆。
5. STATE（状态） 属于一个 CURRENT_NODE（当前节点）——比如当前系统在“情绪识别Node”。
6. STATE（状态） 存储了多个 TOOL_CALL_RESULT（工具调用结果）——比如存储了“查订单API的返回结果”“查物流API的返回结果”。
7. STATE（状态） 存储了多个 USER_INPUT（用户输入）——比如存储了用户的所有历史输入。
8. STATE_GRAPH（状态机图） 包含了多个 NODE（节点） 和多个 EDGE（边）。
9. NODE（节点） 可以是 AGENT（代理）、TOOL（工具）、STATE_HANDLER（状态处理函数）、或者 SUBGRAPH（子图）。
10. AGENT（代理） 使用 LLM（大语言模型），也可以调用 TOOL（工具）。
11. RETRIEVER（检索器） 使用 VECTOR_STORE（向量数据库） 和 EMBEDDING_MODEL（嵌入模型）。
12. TOOL（工具） 可以调用 EXTERNAL_API（外部API）。
13. EDGE（边） 从 SOURCE_NODE（源节点） 开始，到 TARGET_NODE（目标节点） 结束，可能有 CONDITION（条件）。
14. CHECKPOINTER（检查点） 存储了多个 STATE_VERSION（状态版本）。
15. MEMORY（记忆） 存储了多个 MEMORY_ENTRY（记忆条目）。

2.2.2.2 交互关系图（系统的工作流程）

这个交互关系图解释了显式状态驱动的多Agent系统的完整工作流程：

1. 用户发起对话：用户在前端输入问题，前端发送请求给后端（包含用户ID、会话ID、用户输入）。
2. 后端初始化/恢复会话：后端检查Checkpointer中是否有该会话的历史State版本——如果有，就恢复最新的State版本；如果没有，就从Memory中读取用户的长期记忆，初始化新的State，然后保存初始State版本到Checkpointer。
3. 后端执行StateGraph的流程：后端进入一个循环，执行StateGraph的流程：
   a. 获取当前State的CURRENT_NODE。
   b. 根据当前Node的类型（AGENT、TOOL、STATE_HANDLER、SUBGRAPH）执行对应的逻辑：
   • 如果是AGENT：从State中提取需要的信息，发送Prompt给LLM，LLM返回响应——如果是最终答案，就把最终答案写入State，保存新的State版本，跳出循环；如果是行动，就把思考、行动、行动输入写入State，保存新的State版本，调用对应的工具。
   • 如果是TOOL：调用对应的工具（传入State中的信息）。
   • 如果是STATE_HANDLER：执行状态处理函数（比如状态压缩、数据清洗）。
   • 如果是SUBGRAPH：执行子图的流程。
     c. 工具执行完之后，返回结果给后端。
     d. 后端把工具调用结果写入State，保存新的State版本到Checkpointer。
     e. 后端执行Edge跳转（根据当前State的信息，选择下一个Node），更新State的CURRENT_NODE。
4. 后端返回最终答案给前端，前端展示给用户：后端跳出循环之后，把最终答案返回给前端，前端展示给用户。

2.3 核心概念：我们的智能客服多Agent协作平台的核心要素组成

2.3.1 我们的智能客服多Agent协作平台的业务场景定义

在正式开始设计核心要素之前，我们先明确一下我们的智能客服多Agent协作平台的业务场景——为了让系统更通用、更可落地，我们选择了**「综合电商+在线教育SaaS」**的混合业务场景（这样既能覆盖电商的高频业务，也能覆盖SaaS的低频复杂业务）：

我们的平台是**「一家名为“智选科技”的公司的智能客服系统」**，智选科技有两个业务线：

1. 智选商城（综合电商业务线）：销售服装、电子产品、家居用品等，核心业务包括：查订单、查物流、换货、退货、申请加急、联系客服。
2. 智选学堂（在线教育SaaS业务线）：提供编程、AI、数据分析等在线课程，核心业务包括：查课程、查学习进度、查考试成绩、申请课程退款、申请企业团购、下载学习资料、联系技术支持。

2.3.2 我们的智能客服多Agent协作平台的核心要素组成（模块化设计！）

为了让系统更可维护、更可扩展，我们采用了模块化设计，把系统分成了以下8个核心要素模块：