即时通信 IM AI 聊天机器人

这篇是基于腾讯云即时通信 IM 构建 AI 对话能力的端到端落地指引。

一、摘要

本方案给出一条“用户语音/文本输入，经 IM 转发，至接入方业务 Bot，再由 LLM 流式回复，最后 IM TTS 语音播报”的完整 AI 对话链路，80% 链路由腾讯云 IM 原生能力支撑，接入方只需自建 LLM 编排层即可落地。

三句话定位：

·IM 是 AI 业务的安全消息总线：不感知模型、不绑定路由，只负责消息可靠、流式、多端送达。

·两种接入方式：接入方有公网服务端走服务端回调，无公网/本地部署走客户端长连接，两条路各自最优。

·128K 流式消息 + botID 自带记忆 + 端内 ASR/TTS + 内置离线推送：五件套覆盖 LLM 长回答、多轮上下文、语音输入、语音播报、离线触达等核心工程能力。

三、业务定位

本方案基于腾讯云即时通信（IM）产品，为接入方提供 AI 聊天机器人能力。接入方购买 IM 服务后，可将 AI 机器人接入到自有的聊天场景中，实现用户与机器人的智能对话。

在 IM 系统中，机器人是一类特殊账号：它与普通用户账号一样拥有唯一标识，可被加好友、拉入群聊、单聊或群聊 @，区别在于其消息的接收与回复由接入方的服务端结合 LLM 自动处理，而非真人操作。

四、典型接入方场景

五、本方案与通过 SSE 自研方案的区别

结论：SSE 自研方案在“流式推送”这一单点上有天然优势，但构建完整的 AI 对话产品所需的消息可靠送达、多端漫游、离线推送、语音输入/播报、群聊等能力均需从零搭建。更重要的是，如果 App 需要同时支持人与人通讯和人与 AI 对话，SSE 方案无法承载（只能另建一套即时通讯基础设施来处理人人通讯，两套系统割裂）。本方案基于 IM 构建，人人通讯与人机对话天然共存于同一套体系，接入方只需聚焦 LLM 编排与业务逻辑，显著缩短落地周期并降低长期运维成本。

六、两种接入方式总览

围绕“机器人如何接收用户消息”这一核心差异，本方案提供两种接入方式：

九、关键设计原则

·IM 不做 AI 编排：所有意图识别、模型路由、RAG、工具调用都在接入方业务侧。IM 只看到 botID 收发文本。

·botID = 会话主键：每个 AI 助手对应一个 IM @RBT# 账号，历史消息天然按 botID 维度落库。

·消息即记忆：多轮上下文不需要单独存储，每次回复前从 IM 拉历史即可（配合缓存与窗口管理）。

·流式可降级：流式消息在 LLM 出错时可回退为整段消息或撤回重发。

·双轨解耦：客户端长连接与服务端回调是平行能力，接入方按部署形态二选一，业务层代码完全一致。

十一、@RBT# 特殊账号

机器人在 IM 中以 @RBT# 开头的特殊账号存在。机器人账号通过 独立的 REST API 创建，与普通用户账号的导入接口不同，专门用于创建 @RBT# 前缀的机器人账号。

十二、botID 的工程优势（相比普通账号）

接入方价值：

·一个 AI 助手可同时服务海量用户，不受普通账号好友数上限束缚（好友数根据不同套餐定义）。

·群聊 AI 助理可无限加群，不需要为“机器人加群超限”做拆分。

·独立回调让 AI 业务流量与普通 IM 业务流量天然隔离，监控、限流、路由更清晰。

十四、原理

·用户将消息发送给一个或多个 @RBT# 开头的特殊用户（botID）。接入方服务端使用腾讯云提供的 IM SDK Node 版本，分别以每个 botID 身份登录 IM 服务器并建立持久长连接，机器人此时是一个“始终在线”的客户端，能够实时接收 IM 服务器推送的用户消息。

·会话的记忆与上下文管理由接入方侧自行实现，整理后转发给 LLM；机器人的回复由 Node SDK 客户端通过流式消息接口以机器人账号身份逐片下发（注意：不是服务端 REST API 发送，是客户端 SDK 发送）。

关键约束：一个 botID 对应一条长连接。有多少个 @RBT# 特殊用户，就需要维持多少条长连接。

十七、步骤一：客户端输入

为什么发文本而不是语音消息？

·LLM 直接处理文本，无需额外转换；

·文本可被 IM 历史存储和搜索；

·多端展示统一。

ASR 详细说明见 语音输入（ASR）。

十八、步骤二：ASR 语音转文字

由 IM SDK 的 convertVoiceToText 完成，详见 语音输入（ASR）。

十九、步骤三：客户端发消息至 botID

·目标 UserID：@RBT#xxx（机器人专属前缀）；

·消息类型：TextMessage，可挂 cloudCustomData 携带场景标签（用于 Bot 路由）；

·会话类型：单聊（C2C）或群聊（GROUP，群里 @机器人触发）。

20、步骤四：IM 投递消息到 botID

IM 服务将消息投递至 botID（@RBT# 开头的特殊账号）。对 IM 而言，botID 是一个可登录的账号，IM 不感知其背后是否对接了 AI，AI 逻辑全部在接入方业务侧。

由于 botID 已通过长连接登录并保持在线，IM 会把消息通过该长连接实时推送给接入方业务服务端。

·构建上下文记忆

机器人收到消息后，需要带上历史对话上下文才能让 LLM 给出连贯回复。

·优先建议：优先建议机器人端自行存储会话记忆，优势在于上下文读取延迟低、裁剪策略灵活可控、不依赖 IM 历史消息接口的调用频次与存储时长限制。

机器人在线接收消息的过程中，按会话维度持续将消息写入本地记忆，做好不同会话之间的隔离。收到新消息时从本地记忆中取出对应会话的上下文，连同当前消息一起转发给 LLM。

·特点：上下文的组织与裁剪策略完全由接入方掌控，灵活度高、读取延迟低、不依赖 IM 历史消息接口；但需自行处理会话隔离、记忆存储与一致性。

如有需要，也可以通过 Node SDK 拉取该会话的历史消息来获取上下文。

·上下文窗口管理（必做）：无论哪种记忆方式，都必须做上下文窗口管理，否则 LLM 上下文将超出 Token 上限（需将最早摘要、中间摘要及最近 N 轮原文拼接成 prompt 给 LLM）。推荐 N=20-50 条，在 Bot 进程做 LRU + TTL 内存缓存，避免每条消息都打底层接口。

·云端消息存储时长约束：IM 云端消息存储时长受套餐包档位限制（可选 7/30/90/180/360 天），超过存储时长的历史消息无法再拉取。多轮对话场景下若依赖远期上下文，必须在 Bot 侧自建消息归档（写入接入方自有数据库 / 对象存储），不能假设 IM 长期保存。

21、步骤五：调用 LLM

接入方自选模型：混元 / 豆包 / DeepSeek / Kimi / 自部署 Llama / Qwen / GLM 等。

22、步骤六：LLM 流式输出

LLM 以流式模式持续输出 token。

23、步骤七：Bot 通过 Node SDK 流式发送回复

Bot 以客户端身份通过 Node SDK 的流式消息接口将回复逐片下发。

注意：方案一中流式消息由客户端 SDK 发送，不是服务端 REST API。

24、步骤八：IM 流式文本下发 + 客户端发起 TTS + 显示与播报

IM 服务收到 Bot 的流式消息后，文本和音频通过两个独立通道分别送达客户端：

·IM SDK 触发 onMessageReceived，每个流式分片都是一次回调，客户端 UI 拼接显示文字。

·客户端通过 WebSocket 向 IM 服务发起 TTS 请求 ，详见 文字转语音。

·TTS 由 IM 服务统一提供（一句话 TTS / 流式 TTS 两种模式），详见 语音播报（TTS）。

25、部署形态

部署位置：客户端长连接方式可以部署在接入方的服务端，并不局限于本地/边缘场景。

非 Node 技术栈接入方：即便接入方主业务服务端不是 Node.js（Java / Go / Python / .NET / PHP 等），也可以单独起一个 Node 进程作为 IM 接入网关，主业务通过内部 RPC / MQ / HTTP 与该 Node 进程通信。对接入方的额外成本只是“运维一个 Node 服务”，不需要把整套业务迁移到 Node。

26、特点与限制

特点：

·机器人需保持在线（长连接登录）；

·由客户端长连接驱动，消息接收实时性强；

·会话记忆完全由接入方侧掌控，灵活度高；

·主动出站，无需公网回调地址，适用于本地部署、IoT、内网等无法提供公网回调的场景。

限制：

·1 botID = 1 条长连接，多机器人场景需多进程编排（如 k8s pod-per-bot）；

·非 Node 接入方需额外部署一个 Node 进程。

27、页面文档指引

基于客户端长连接，所涉及的接收消息、拉取历史、流式发送回复等均走 Node.js 插件能力。下表列出方案一需要用到的核心能力及其页面文档，以页面最终发布为准。

29、原理

机器人无需在线。IM 服务端提供机器人回调机制：当用户在单聊中给机器人发消息、或在群聊中 @ 机器人时，IM 服务端会将消息回调到接入方预先配置的回调地址。接入方服务端基于回调内容处理消息、转发给 LLM，并将机器人的回复通过服务端 REST API 流式消息接口（发送 C2C 流式消息 / 发送群流式消息）以机器人账号身份逐片下发。

31、构建上下文记忆

机器人收到回调后，需要带上历史对话上下文才能让 LLM 给出连贯回复。方案二基于服务端回调，记忆的构建方式因会话类型不同而有所差异：

32、单聊（C2C）场景

单聊中，用户发给 @RBT# 机器人的每条消息都会触发回调。接入方可以直接基于回调本身构建会话记忆，回调到达时将消息写入自有存储，需要上下文时从自有存储中取出即可。

优先建议业务侧自行存储会话记忆，优势在于上下文读取延迟低、裁剪策略灵活可控、不依赖 IM 历史消息接口的调用频次与存储时长限制。

33、群聊场景

群聊中，只有 @机器人 的消息才会触发回调，群内其他用户之间的普通对话不会回调。因此无法仅通过回调获取完整的群聊上下文。

正确的做法是：收到 @机器人 的回调后，通过服务端 REST API 拉取该群的近期历史消息，将群内对话整理为 LLM 可理解的上下文，连同当前 @机器人 的消息一起转发给 LLM。

如有需要，单聊场景也可以通过 REST API 拉取历史消息来获取上下文（/v4/openim/admin_getroammsg）。

·上下文窗口管理（必做）：无论哪种记忆方式，都必须做上下文窗口管理，否则 LLM 上下文将超出 Token 上限（需将最早摘要、中间摘要及最近 N 轮原文拼接成 prompt 给 LLM）。推荐 N=20-50 条，在 Bot 进程做 LRU + TTL 内存缓存，避免每条消息都打底层接口。

·云端消息存储时长约束：IM 云端消息存储时长受套餐包档位限制（可选 7/30/90/180/360 天），超过存储时长的历史消息无法再拉取。多轮对话场景下若依赖远期上下文，必须在 Bot 侧自建消息归档（写入接入方自有数据库 / 对象存储），不能假设 IM 长期保存。

34、两类回调（按场景选其一或叠加）

选型建议：纯 AI 助手场景优先用机器人回调，避免接收无关消息浪费带宽；如果接入方已有成熟的统一回调网关，可继续用单聊/群聊后回调，在网关侧过滤分发。

35、部署形态

接入方在 IM 控制台自助配置回调 URL（如 单聊机器人消息回调），无需 IM 团队介入。

36、注意事项

·2 秒内必须 ACK，否则 IM 重试导致消息重复；

·签名验证必做，防止伪造请求；

·单接入点托管多 botID：所有机器人消息汇入同一回调，适合大规模 Agent 矩阵。

37、特点

·机器人无需维护长连接；

·由 IM 服务端回调驱动，部署与运维更轻量；

·回调仅在单聊发消息和群聊 @ 机器人时触发；

·成熟、可水平扩展、无长连接维护成本。

38、页面文档指引

方案二基于服务端回调：接收消息靠机器人回调，拉取历史与发送流式回复均走服务端 REST API；端上语音输入（ASR）与语音播报（TTS）与方案一一致，由客户端 SDK / IM 服务承担。下表列出方案二需要用到的核心能力及其页面文档，未上线的以页面最终发布为准。

39、两种方案对比

40、语音输入（ASR）

IM SDK 内置 ASR（语音转文字）能力，无需端侧集成第三方 ASR SDK。

当前为一句话 ASR 模式：录音结束后整段送转，返回完整文本。

42、为什么需要流式消息

LLM 单条回答经常超过 8K（尤其长文生成、代码生成、多轮总结场景），普通 IM 文本消息有长度上限。流式消息把一条逻辑消息拆成多个 chunk 下发，单条逻辑消息上限 128K，覆盖 LLM 长回答场景。

44、方案一：Node SDK 客户端发送

发送流式消息

发送流式消息的接口。与普通消息的区别在于 payload 使用流式专用结构，通过分块（chunk）逐次追加内容，服务端下发到接收方后由 SDK 拼装完整内容。首次调用返回消息实例，后续调用携带同一 streamMessageID 追加分块，直到 isStreamEnd = true 结束。

接口

chat.callExperimentalAPI('sendStreamMessage', options);

参数

options 参数如下：

payload 的描述如下：

chunks 元素的描述如下：

返回值

Promise<Message>：resolve 时返回消息实例，message.payload.streamMessageID 已由服务端返回值回填；reject 时抛出错误对象。

示例

1. 创建流式消息（首次发送，不传 streamMessageID）。

const streamMessage = await chat.callExperimentalAPI('sendStreamMessage', { to: 'group1', conversationType: 'GROUP', payload: { chunks: [ { index: 1, markdown: '这是第一块内容', isStreamEnd: false }, ], },});// 保存 streamMessageID 用于后续追加const streamMessageID = streamMessage.payload.streamMessageID;

2. 追加流式内容（携带 streamMessageID，末块 isStreamEnd = true）。

await chat.callExperimentalAPI('sendStreamMessage', { to: 'group1', conversationType: 'GROUP', payload: { streamMessageID, chunks: [ { index: 2, markdown: '这是第二块内容', isStreamEnd: false }, { index: 3, markdown: '这是第三块内容', isStreamEnd: true }, ], },});

45、方案二：服务端 REST API 发送

46、语音播报（TTS）

机器人回复到达客户端后，IM 服务提供 TTS（Text-to-Speech）能力，将文本消息转为语音播报给用户。客户端无需自建 TTS，IM 服务统一提供两种播报模式：一句话语音合成（一句话 TTS） 和 实时语音合成（流式 TTS）。

具体功能介绍详见 功能介绍文档。

47、播报模式

终端发起语音播报功能详见文档：文字转语音。

49、能力概览

腾讯云 IM 内置离线推送（Push）能力，覆盖苹果 APNs、FCM 以及国内主流安卓厂商通道（华为 / 小米 / OPPO / vivo / 魅族 / 荣耀），无需额外集成第三方推送 SDK。

50、在 AI 助手场景下的两类典型用法

1. AI 回复触达通知

当用户发起提问后切走 App / 锁屏，Bot 完成 LLM 处理并通过 IM 回发消息时，若接收方处于离线状态，IM 自动按推送策略下发系统通知，引导用户回到对应会话查看回答。

业务侧无需自建轮询、无需维护推送通道，只要正常发 IM 消息即可触发推送，离线判断与厂商通道分发由 IM 接管。

2. 运营触达

通过 IM REST API 或控制台对指定 userID / 标签人群下发推送通知，支持沉默用户召回、新功能上线提醒、重要事件通知等场景。推送与 IM 消息共用同一套用户体系，无需额外的设备 ID / 标签映射。

51、关键接口

53、数据流向

说明：AI 业务数据（LLM 输入输出、模型权重、RAG 知识库、用户隐私）均在接入方业务服务器内闭环处理，不经过腾讯云 IM。IM 仅负责 botID 与用户之间的文本消息收发，不感知也不存储 AI 业务数据。

54、业务准入控制（可选）

机器人场景下，接入方常有这类业务诉求：判断某个用户是否被允许向某个机器人发消息、或在群内 @ 某个机器人是否被允许（如 VIP 专属机器人、每日调用次数限制、黑名单、付费开通、灰度等）。这类规则高度业务化，IM 不提供标准方案，由接入方业务侧自行定义。

这一步是可选的。仅当接入方确有准入类业务要求时启用；无相关需求时不配置，不影响主流程。它位于主链路“用户发消息至消息到达机器人”之间，是一个可插拔的准入闸门。

55、方法一：服务端消息前回调

IM 在消息下发前提供回调，由接入方服务端判断是否放行，并通过返回码控制 IM 后续动作：

回调返回码：

56、方法二：Bot 侧自行管理

如果接入方不希望或无法使用消息前回调（如方案一零公网暴露场景），也可以在 Bot 侧自行增加管理逻辑：Bot 收到用户消息后，先判断该用户是否被允许与当前机器人交互（如查询自有权限表、调用次数计数、黑名单校验等），若判定不响应则直接丢弃该消息、不调 LLM、不回复。

与方法一的区别：方法一在消息下发前拦截，用户端能看到“发送被拒绝”的反馈；方法二在 Bot 收到消息后判断，无法阻止消息到达 Bot，但可以控制是否响应。两种方法可根据部署形态和业务需求灵活选择。

57、与两种接入方式的关系

·方案一（客户端长连接）：方案一通常面向“无公网”场景，而消息前回调要求一个公网回调入口。若坚持零公网暴露，可在 Bot 侧收到消息后自行做权限校验（方法二），但无法在“消息发出前”拦截，体验上不如消息前回调；若愿意为准入单独开放一个公网回调地址，则可与方案一混合使用。

消息前回调默认 2s 超时，超时默认按“正常下发”处理（控制台可自助配置超时策略）。准入逻辑应尽量轻量，避免拖慢消息发送。

·方案二（服务端回调）：接入方本就有公网回调入口，启用消息前回调几乎零额外成本，可与机器人回调共用同一套回调服务，是落地准入控制最自然的方式。