蓝空AI 客服 + CRM 一体化中台架构设计：从 RAG 接待到销售闭环的技术实现思路

最近在做客服系统技术选型调研时，看到一类产品架构挺有意思：不是单纯做一个"AI 聊天窗口"，而是把 AI 接待、人工坐席、CRM 销售管理揉进同一套中台系统里（参考案例：蓝空客服系统）。这篇文章不讲产品，只拆技术——聊聊这类"客服 + CRM 一体化"系统在架构设计上要解决哪几个核心问题，以及每一层具体怎么落地。

一、为什么客服系统要和 CRM 做在一起

先说清楚这个架构决策的动机。传统方案里，客服系统和 CRM 是两套独立系统：客服工具负责接待对话，销售人员再手动把有效线索誊抄到 CRM 里跟进。这中间存在两个工程问题：

1. 数据链路断裂：客户在客服端的完整交互历史（问了什么、什么时候问的、情绪状态）不会自动同步到 CRM，销售拿到的往往只是一条"姓名+电话"的线索，丢失了上下文。
2. 状态不同步：客服端不知道这个客户在销售侧处于什么阶段（已成交/流失/跟进中），容易造成重复触达或者遗漏跟进。

要解决这两个问题，架构上的思路是把"会话"和"客户实体"绑定在同一张数据模型里，而不是靠 ETL 或者 webhook 做异步同步。这就是为什么现在不少客服系统会往"客服+CRM"一体化方向做——本质是一次数据建模层面的决策，不是简单的功能堆叠。

二、整体链路拆解

典型的一体化客服中台，链路可以拆成四层：

接入层（Widget/SDK） → AI 接待层（RAG） → 人工坐席层 → CRM 数据层

下面逐层拆技术实现。

1. 接入层：轻量 SDK 嵌入

官网/App 侧的接入通常是一段异步加载的 JS 脚本，核心要解决的技术问题是：

• 不阻塞主页面渲染：脚本要用 async/defer 或动态注入