下面这版我按“可直接投稿的技术方案文章”重写，重点强化了：问题诊断、架构合理性、工程深度、数据闭环、可复现性，不再停留在功能介绍层面。

LikeShop单商户AI智能客服架构升级：基于消息队列的异步化改造与生产级实践

一、引言

随着大模型能力的成熟，AI智能客服已成为电商平台降低人工客服成本、提升咨询响应效率的重要手段。尤其在私域商城、单商户门店和小程序场景中，用户咨询具有频次高、时效性强、业务链路复杂等特点，传统同步调用大模型的架构往往难以支撑稳定运行。

LikeShop单商户标准版本身具备一定的客服与工单基础能力，但在引入AI自动回复后，系统容易暴露出响应延迟、接口超时、资源占用高、故障传导强等问题。这些问题并非源于大模型能力不足，而是因为AI推理属于高耗时操作，不适合直接承载在同步接口链路中。

本文提出一种基于消息队列的AI智能客服异步化改造方案，在LikeShop单商户Java版架构基础上，通过新增消息生产、异步消费、会话状态管理、结果推送与失败补偿模块，将同步调用链路改造为“快速返回、异步处理、结果回调”的生产级架构。改造后，系统在大促峰值、高并发咨询和大模型波动场景下仍能保持稳定运行。

二、业务痛点与问题分析

2.1 AI客服同步调用存在稳定性风险

在初始版本中，AI客服通常采用同步调用方式：用户发送消息后，接口线程直接调用大模型，等待推理完成后返回结果。这种模式实现简单，但在生产环境中存在明显缺陷。

第一，大模型推理延迟较高，单条回复通常需要1至3秒，复杂上下文甚至更久。同步等待会导致接口线程长时间被占用，系统并发能力迅速下降。

第二，活动大促期间咨询量会出现数倍增长。如果大量用户同时进入客服会话，同步接口会迅速耗尽服务线程，进而影响商品详情、下单、支付等主业务接口。

第三，大模型服务本身存在波动。偶发超时、限流或临时不可用，会直接导致用户消息发送失败，影响咨询体验。

2.2 消息丢失与状态混乱问题突出

在客服场景中，消息可靠性和会话顺序性非常重要。同步架构虽然实现简单，但一旦出现网络抖动、服务重启或推理异常，容易出现以下问题：

  • 用户消息已发送但未收到回复；
  • AI回复生成后未通知到前端；
  • 同一用户多条消息顺序错乱；
  • 异常重试导致重复回复；
  • 客服模块故障影响商城主链路。

这些问题在平峰时段可能表现不明显，但在大促、活动和客服高峰期会集中爆发。

2.3 人工客服与AI客服缺乏协同闭环

很多AI客服改造只关注“自动回复”，却没有建立完整的业务闭环。当AI无法回答、用户要求转人工或问题涉及订单、售后、物流时，系统需要具备降级能力。

如果AI结果无法可靠落库，人工客服就无法继续承接上下文；如果异常消息没有补偿机制，问题会直接丢失；如果缺少状态追踪，运营团队也无法判断故障发生在哪个环节。

因此，AI客服升级不能只做模型调用，而必须建立完整的消息生命周期管理。

三、方案设计目标与原则

3.1 设计目标

本方案的核心目标不是简单引入消息队列，而是构建一个稳定、可靠、可观测的AI客服生产架构。具体目标如下：

  1. 提升接口响应速度：用户消息发送后立即返回，不等待大模型推理；
  2. 增强峰值承载能力：通过消息队列削峰填谷，支撑大促咨询洪峰；
  3. 保证消息可靠性：消息不丢失、不重复，异常可追踪、可补偿；
  4. 实现故障隔离：AI推理异常不影响商城主业务链路；
  5. 支持人机协同：AI、人工客服、系统规则之间可灵活切换；
  6. 建立可观测体系：消息状态、消费耗时、失败原因均可监控。

3.2 设计原则

为避免过度设计，方案遵循以下原则：

  1. 低侵入原则：新增独立AI客服扩展模块，不改造LikeShop交易核心链路；
  2. 消息优先原则：以消息为中心组织流程，不以同步调用为中心；
  3. 状态可追溯原则：每条消息都有明确状态和处理日志；
  4. 失败可控原则：允许失败，但不允许静默丢失；
  5. 渐进降级原则：大模型异常时自动降级为规则回复或人工客服。

四、整体架构设计

4.1 架构分层

改造后的AI客服系统分为五层：接入层、会话网关层、消息中间件层、消费推理层、业务能力层。

接入层：商城H5、小程序、公众号客服入口
  ↓
会话网关层：消息接收、会话校验、状态管理、结果查询
  ↓
消息中间件层：消息主题、优先级队列、死信队列、延时队列
  ↓
消费推理层：意图识别、规则拦截、大模型推理、工具调用、结果生成
  ↓
业务能力层：LikeShop商品、订单、用户、售后、物流服务

4.2 核心流程

一条用户消息的完整处理流程如下：

  1. 用户在前端发送消息；
  2. 会话网关校验用户身份和会话状态；
  3. 消息先持久化到数据库，状态标记为“处理中”；
  4. 消息投递到消息队列，接口立即返回发送成功；
  5. 消费者拉取消息，进行意图识别和规则预处理；
  6. 需要业务数据时调用LikeShop内部服务查询订单、物流、售后等信息；
  7. 调用大模型生成AI回复；
  8. AI回复落库并更新消息状态；
  9. 通过轮询或WebSocket将结果推送给前端；
  10. 消费失败时自动重试，超过阈值进入死信队列并转人工。

4.3 消息模型设计

系统中的消息不仅是文本内容，还包含完整的处理上下文。核心消息字段包括：

  • msgId：消息唯一编号；
  • sessionId：会话编号；
  • userId：用户ID；
  • content：消息内容；
  • messageType：消息类型；
  • intentType：意图类型；
  • status：消息状态；
  • retryCount：重试次数；
  • createTime：消息创建时间；
  • updateTime：状态更新时间。

通过统一消息模型，系统可以将“发送、排队、处理、回复、失败、补偿”整个生命周期串联起来。

五、消息队列选型与应用设计

5.1 为什么选择消息队列

消息队列的价值不是为了增加技术复杂度，而是为了解决同步架构中的三个核心问题：解耦、削峰和容错。

在AI客服场景中，消息队列可以将用户请求与AI推理过程分离。用户发送消息后，系统只负责接收和入队，真正的推理工作由后台消费者异步完成。这样即使大模型出现延迟或波动，也不会直接影响前端交互。

5.2 RocketMQ的适用性

本方案采用RocketMQ作为消息中间件，主要原因如下：

  1. 支持顺序消息：同一用户的消息可以按顺序处理；
  2. 支持死信队列：失败消息可进入专门队列处理；
  3. 支持重试机制：消费失败后可自动重试；
  4. 吞吐能力较强：适合电商活动峰值场景；
  5. 生态成熟，适合Java业务系统集成。

5.3 主题与队列划分

为避免所有消息混在一起处理，系统可按业务优先级划分不同主题或标签。

5.3.1 普通咨询主题

适用于商品咨询、活动规则、使用说明、常见问题等普通对话。这类消息对实时性要求相对较低，可按正常速度消费。

5.3.2 高优业务主题

适用于订单查询、物流查询、售后申请、退款咨询等交易相关问题。这类消息涉及用户资金和履约体验，应优先处理。

5.3.3 死信主题

当消息多次消费失败后，不应无限重试，而应进入死信队列，由人工客服或运营人员介入处理。

5.3.4 顺序性设计

同一用户的多条消息需要保持顺序，否则会出现上下文混乱。可采用按用户ID路由队列的方式，保证同一用户消息进入同一分区，从而实现顺序消费。

六、会话状态管理设计

6.1 状态机设计

AI客服会话应采用明确的状态机管理，而不是依赖业务代码中的零散判断。

会话状态可设计为：

  • active：会话进行中；
  • waiting：等待用户输入；
  • processing：AI处理中；
  • replied：AI已回复；
  • transferring：转人工中；
  • human：人工客服处理中；
  • closed：会话已关闭。

消息状态可设计为：

  • pending：待处理；
  • processing：处理中；
  • success：处理成功；
  • failed：处理失败；
  • dead：进入死信队列。

6.2 缓存与数据库结合

会话上下文和热点状态适合使用Redis管理，而完整消息记录和会话历史则应持久化到数据库。

Redis负责：
  • 当前会话状态；
  • 用户最近消息；
  • AI上下文缓存；
  • 临时锁与幂等标记。
MySQL负责：
  • 会话主记录；
  • 消息明细；
  • 消费任务记录；
  • 异常与重试日志。

6.3 会话超时控制

客服会话不能长期占用资源。系统应设置会话超时机制，例如30分钟无交互后自动关闭会话，并将会话上下文持久化归档。这样既释放缓存资源，也保证后续人工客服可继续查看历史。

七、消费推理层设计

7.1 消费端整体流程

消费者是异步架构的核心，其处理质量直接决定AI客服稳定性。推荐采用以下流程：

  1. 拉取消息；
  2. 幂等校验；
  3. 规则拦截；
  4. 意图识别；
  5. 业务工具调用；
  6. 大模型推理；
  7. 结果生成；
  8. 状态更新；
  9. 结果通知。

7.2 幂等处理

消息队列可能出现重复投递，因此消费端必须具备幂等能力。

常见做法是为每条消息生成唯一msgId，消费时先检查该消息是否已处理。如果已成功处理，则直接返回；如果正在处理中，则根据业务情况决定是否重试。

幂等表可记录以下字段：

  • msgId；
  • consumerGroup；
  • status；
  • retryCount；
  • lastError；
  • createTime；
  • updateTime。

7.3 规则前置拦截

并不是所有消息都需要调用大模型。对于高频、明确、规则稳定的问题，可以前置拦截，直接返回预设答案。

例如：

  • 发货时间；
  • 退换货政策；
  • 运费说明；
  • 优惠券使用规则；
  • 活动参与条件。

规则拦截有两个好处：一是降低大模型成本，二是提高响应速度，三是减少不确定回答。

7.4 意图识别与路由

对于无法用规则直接回答的问题，应先进行意图识别，再决定处理方式。

常见意图类型包括：

  • product_query：商品咨询；
  • order_query：订单查询；
  • logistics_query：物流查询；
  • after_sale：售后咨询；
  • complaint：投诉建议；
  • transfer_human：转人工；
  • general_chat：闲聊。

根据意图类型，系统可以选择不同处理策略。例如订单类问题调用订单工具，售后类问题调用售后工具，复杂问题直接转人工。

7.5 工具调用设计

AI客服的真正价值在于能访问业务系统数据，而不是只做通用对话。LikeShop单商户版可以提供内部服务接口，供AI工具层调用。

可对接的能力包括：

  • 用户订单查询；
  • 物流信息查询；
  • 售后单状态查询；
  • 商品库存与规格查询；
  • 优惠券与活动规则查询；
  • 售后申请入口。

工具调用应遵循统一接口规范，返回结构化结果，再由大模型组织成自然语言回复。

7.6 大模型推理

当规则和工具无法直接回答时，进入大模型推理环节。输入给大模型的内容应包括：

  • 用户当前问题；
  • 会话历史；
  • 用户画像信息；
  • 商品或订单上下文；
  • 工具返回结果；
  • 平台客服规则。

为提高稳定性，建议对大模型输出进行格式校验。如果返回结果不符合预期，应进行重试、降级或转人工处理。

八、结果推送与前端交互设计

8.1 推送方式选择

异步架构下，前端不能一直等待接口返回，而需要通过轮询或消息推送获取AI结果。

WebSocket推送

如果前端环境支持，WebSocket是更优方案。AI回复生成后，服务端可实时推送到用户端，交互体验接近同步客服。

轮询补偿

在不支持WebSocket或网络不稳定时，可采用轮询方式。前端定期请求最新消息接口，拉取当前会话的新增回复。

8.2 前端状态展示

为避免用户误以为发送失败，前端应明确展示消息状态：

  • 发送中；
  • 已发送；
  • AI处理中；
  • 已回复；
  • 发送失败；
  • 已转人工。

这些状态应与服务端消息状态保持一致，而不是前端单方面判断。

九、失败处理与补偿机制

9.1 失败分类

AI客服中的失败不能一概而论，应按类型处理。

临时失败

例如大模型超时、网络抖动、接口限流等。这类问题适合重试。

业务失败

例如用户问题涉及复杂投诉、敏感内容、特殊售后等。这类问题不一定需要重试，而应转人工。

系统失败

例如数据库异常、服务异常、依赖服务不可用。这类问题需要告警和人工介入。

9.2 重试策略

重试不是越多越好，而应设置上限。建议：

  • 最多重试3次；
  • 采用递增间隔；
  • 不同类型异常采用不同重试策略；
  • 超过次数后进入死信队列。

9.3 死信队列处理

死信队列不是终点，而是异常治理入口。进入死信队列的消息应触发以下动作：

  • 记录失败原因；
  • 发送告警；
  • 进入人工处理列表；
  • 补偿处理后重新入队或关闭消息。

9.4 降级策略

当大模型不可用时，系统不能直接瘫痪。建议建立降级链路：

  1. 大模型不可用；
  2. 优先使用规则回复；
  3. 规则也无法回答则转人工；
  4. 人工客服繁忙时给出提示或排队状态。

十、数据模型设计

10.1 会话主表

会话主表用于记录用户与AI客服的交互过程。

CREATE TABLE ls_ai_chat_session (
  id BIGINT PRIMARY KEY AUTO_INCREMENT,
  session_id VARCHAR(64) NOT NULL,
  user_id BIGINT NOT NULL,
  channel TINYINT NOT NULL,
  status TINYINT NOT NULL,
  create_time DATETIME NOT NULL,
  update_time DATETIME NOT NULL,
  last_message_time DATETIME,
  message_count INT DEFAULT 0,
  UNIQUE KEY uk_session_id(session_id),
  KEY idx_user_id(user_id),
  KEY idx_status(status)
);

10.2 消息明细表

消息明细表记录每一条用户消息和AI回复。

CREATE TABLE ls_ai_chat_message (
  id BIGINT PRIMARY KEY AUTO_INCREMENT,
  msg_id VARCHAR(64) NOT NULL,
  session_id VARCHAR(64) NOT NULL,
  sender_type TINYINT NOT NULL,
  content TEXT NOT NULL,
  status TINYINT NOT NULL,
  intent_type VARCHAR(64),
  reply_content TEXT,
  fail_reason VARCHAR(255),
  create_time DATETIME NOT NULL,
  update_time DATETIME NOT NULL,
  UNIQUE KEY uk_msg_id(msg_id),
  KEY idx_session_id(session_id)
);

10.3 消费任务表

消费任务表用于追踪消息处理状态，保证幂等和可重试。

CREATE TABLE ls_ai_chat_task (
  id BIGINT PRIMARY KEY AUTO_INCREMENT,
  msg_id VARCHAR(64) NOT NULL,
  consumer_group VARCHAR(128) NOT NULL,
  status TINYINT NOT NULL,
  retry_count INT DEFAULT 0,
  last_error VARCHAR(255),
  create_time DATETIME NOT NULL,
  update_time DATETIME NOT NULL,
  UNIQUE KEY uk_msg_group(msg_id, consumer_group),
  KEY idx_status(status)
);

十一、关键代码实现思路

11.1 消息发送与快速返回

用户消息到达后，系统先落库，再投递消息队列，最后立即返回。

核心逻辑如下：

  1. 生成msgId和sessionId；
  2. 保存用户消息；
  3. 设置消息状态为处理中；
  4. 投递消息到MQ；
  5. 返回前端发送成功。

11.2 消息消费与AI回复生成

消费者收到消息后，按以下步骤处理：

  1. 检查幂等状态；
  2. 识别消息意图；
  3. 调用业务工具；
  4. 调用大模型；
  5. 生成AI回复；
  6. 更新消息状态；
  7. 通知前端。

11.3 失败重试与死信处理

消费失败时：

  1. 记录异常原因；
  2. 增加重试次数；
  3. 未达到上限则重试；
  4. 达到上限则进入死信队列；
  5. 触发人工客服转接和告警。

十二、监控与运维体系设计

12.1 核心监控指标

为保证AI客服稳定运行，必须建立监控体系。

消息生产指标
  • 消息发送量；
  • 消息发送成功率；
  • 消息投递耗时。
消息消费指标
  • 消费成功率；
  • 消费失败率；
  • 平均消费耗时；
  • 消息堆积数量；
  • 死信数量。
业务结果指标
  • AI回复率；
  • 转人工率；
  • 平均响应时长；
  • 用户满意度；
  • 问题解决率。

12.2 告警策略

建议设置以下告警：

  • 消息堆积超过阈值；
  • 消费成功率低于阈值；
  • 死信数量突增；
  • 大模型调用失败率升高；
  • AI客服接口响应变慢。

十三、与LikeShop业务能力的集成方式

13.1 集成原则

AI客服不是独立系统，而应作为LikeShop的增强模块。集成时应遵循以下原则：

  1. 通过服务接口调用，不直接操作业务表；
  2. 复用用户、订单、商品、售后能力；
  3. 保持客服模块与交易模块边界清晰；
  4. 异常时不影响主业务链路。

13.2 可集成能力

LikeShop单商户版可向AI客服开放以下能力：

  • 用户信息查询；
  • 订单列表与详情查询；
  • 物流信息查询；
  • 售后单查询与创建；
  • 商品信息查询；
  • 活动与优惠券规则查询。

通过这些能力，AI客服可以从“会聊天”升级为“能办事”。

十四、效果评估指标

改造完成后，建议从技术稳定性和业务价值两个维度评估效果。

14.1 技术指标

指标说明
消息发送接口耗时用户发送消息后的响应速度
消息消费成功率AI消息处理成功比例
大模型调用失败率推理环节异常比例
消息堆积量峰值时MQ积压情况
死信率最终失败消息比例
故障隔离效果客服异常是否影响主业务

14.2 业务指标

指标说明
AI自动回复率AI独立解决问题比例
转人工率需要人工介入比例
平均响应时长用户发出到收到回复的间隔
人工客服效率人工接待量变化
用户满意度咨询体验评价

十五、常见问题与避坑建议

15.1 不要只关注模型能力，忽略消息可靠性

很多团队把AI客服等同于大模型调用，这是错误的。在生产环境中，消息可靠性、异常处理和故障恢复比模型准确率更基础。

15.2 不要让异步化变成“用户等待更久”

异步化的目标是提升稳定性，不是牺牲体验。必须配合状态提示、轮询或推送，让用户知道系统正在处理。

15.3 不要无限重试

无限重试会放大故障，浪费资源。合理的做法是设置重试上限，并对不同异常分类处理。

15.4 不要绕过业务接口直接操作数据库

AI客服需要订单、售后等数据时，应通过LikeShop服务接口获取，而不是直接查询业务表。否则会破坏系统边界，增加后续升级难度。

15.5 不要缺少监控

没有监控的异步系统几乎无法运维。消息堆积、消费失败、死信增长都必须可观测。

十六、结语

AI智能客服从“能回复”到“稳定可用”，关键不在于模型本身，而在于底层架构是否具备承载高并发、波动和异常的能力。

对于LikeShop单商户版而言，通过消息队列进行异步化改造，本质上是将AI推理从同步链路中剥离出来，形成一个独立、可靠、可运维的消息处理系统。这种改造方式对原有交易系统侵入低，适合私域商城、小程序门店和单商户平台快速落地。

真正优秀的AI客服系统，并不是追求每次都由AI回答，而是保证用户咨询有记录、有处理、有结果、有兜底。消息队列带来的不仅是性能提升，更是整个客服链路的可靠性升级。

# 人工智能 # 架构
Logo
北京朝阳AI社区

更多推荐

cover

Agent记忆四组件与dreaming：128轮达标率13%到48%，建一次wiki约19美元

avatar 北京朝阳AI社区

【无标题】

但会有一些问题：所以我们需要解决这些问题：1、文件大，我们要尝试把文件做一个拆分成以目录结构为文件2、提示词记不住不统一，我们则可以通过Skills的方式进行生成。什么是skills？· 定义：Skills 是预定义好的任务执行流程或工具调用结合，让助手能够完成某一类专门的工作（比如生成测试用例、查询数据库、发送邮件等）。· 类比：就像给一个人（智能体工具）配上了“会计技能”，他就能做账；配上“测

avatar 北京朝阳AI社区

小白 AI 入门首选：AgentDoctor 实战效果全景展示

很多开发者在尝试引入 AI 工作流时，往往还没开始解决业务问题，就先卡在了环境配置上。安装依赖、配置密钥、调试网络连通性，这一套流程下来，大半天的时间就没了，最后可能连个"Hello World"都没跑通。更让人头疼的是，即便勉强跑通了，面对高昂的 Token 消耗和不稳定的模型连接，实际落地效果也大打折扣。对于非技术背景的运营、内容或管理人员来说，这种技术门槛几乎是一道不可逾越的高墙。其实，AI

avatar 北京朝阳AI社区