本文是基于腾讯云即时通信 IM 构建 AI 对话能力的端到端落地指引。
摘要
本方案给出一条“用户语音/文本输入，经 IM 转发，至接入方业务 Bot，再由 LLM 流式回复，最后 IM TTS 语音播报”的完整 AI 对话链路，80% 链路由腾讯云 IM 原生能力支撑，接入方只需自建 LLM 编排层即可落地。
三句话定位：
IM 是 AI 业务的安全消息总线：不感知模型、不绑定路由，只负责消息可靠、流式、多端送达。
两种接入方式：接入方有公网服务端走服务端回调，无公网/本地部署走客户端长连接，两条路各自最优。
128K 流式消息 + botID 自带记忆 + 端内 ASR/TTS + 内置离线推送：五件套覆盖 LLM 长回答、多轮上下文、语音输入、语音播报、离线触达等核心工程能力。
概述
业务定位
本方案基于腾讯云即时通信（IM）产品，为接入方提供 AI 聊天机器人能力。接入方购买 IM 服务后，可将 AI 机器人接入到自有的聊天场景中，实现用户与机器人的智能对话。
在 IM 系统中，机器人是一类特殊账号：它与普通用户账号一样拥有唯一标识，可被加好友、拉入群聊、单聊或群聊 @，区别在于其消息的接收与回复由接入方的服务端结合 LLM 自动处理，而非真人操作。
典型接入方场景
场景 | 描述 | 典型接入方特征 |
App 内嵌 AI 对话助手 | 用户在 App 内长按说话/打字对话，AI 流式回复并可朗读。 | 工具类 App、内容社区、车机/IoT 控制端。 |
AI 客服 | 用户在客服窗口提问，AI 优先应答，复杂问题转人工。 | 电商、SaaS、金融售前。 |
AI 陪伴/角色扮演 | 用户与 AI 角色多轮对话，长期记忆、人设一致。 | 社交 App、虚拟伴侣、教育陪练。 |
群聊 AI 助理 | 多人群里 @机器人触发 AI 总结、问答、纪要。 | 协作工具、企业内部群。 |
本方案与通过 SSE 自研方案的区别
对比项 | 通过 SSE 自研 | 本方案（基于腾讯云 IM） |
消息可靠送达 | 需自行实现重试、去重、离线补偿。 | IM 原生保证。 |
多端漫游 | 需自建消息存储 + 多端同步逻辑。 | IM 原生多端漫游。 |
流式长消息 | SSE 天然支持流式推送，但需自行管理分片、长度上限与状态。 | 流式消息原生 128K，内置状态机管理。 |
离线推送 | 需自建多厂商推送通道（APNs/FCM/国内厂商），维护证书与对接。 | IM 内置全平台推送，控制台一次配置。 |
语音输入（ASR） | 需端侧集成第三方 ASR 服务。 | IM SDK 内置 convertVoiceToText。 |
语音播报（TTS） | 需自行集成 TTS 服务并管理音频下发。 | IM 服务统一提供一句话 TTS / 流式 TTS。 |
群聊 / AI 助理 | 需自行实现群组管理、成员管理、消息分发。 | IM 原生群组能力，机器人可加群、被 @。 |
消息历史与搜索 | 需自建存储 + 搜索引擎。 | IM 原生历史消息存储 + 搜索。 |
安全与合规 | 需自行实现签名校验、内容审核、权限控制。 | IM 内置内容审核、回调准入机制。 |
开发周期 | 长：需从零搭建消息基础设施。 | 短：聚焦 AI 编排层，消息链路由 IM 承担。 |
运维成本 | 高：消息服务、推送通道、存储均需持续运维。 | 低：消息基础设施由 IM 托管。 |
人人 + 人机混合 | 仅能做人与 AI 的沟通，无法在同一个 App 内同时承载人人通讯。 | 同一套 IM 体系天然支持人人通讯与人机对话并存，用户无需切换通道即可与真人和 AI 对话。 |
结论：SSE 自研方案在“流式推送”这一单点上有天然优势，但构建完整的 AI 对话产品所需的消息可靠送达、多端漫游、离线推送、语音输入/播报、群聊等能力均需从零搭建。更重要的是，如果 App 需要同时支持人与人通讯和人与 AI 对话，SSE 方案无法承载（只能另建一套即时通讯基础设施来处理人人通讯，两套系统割裂）。本方案基于 IM 构建，人人通讯与人机对话天然共存于同一套体系，接入方只需聚焦 LLM 编排与业务逻辑，显著缩短落地周期并降低长期运维成本。
两种接入方式总览
围绕“机器人如何接收用户消息”这一核心差异，本方案提供两种接入方式：
方案 | 方案一：客户端长连接 | 方案二：服务端回调 |
核心定义 | 机器人作为始终在线的客户端，长连接实时接收消息。 | 机器人无需在线，IM 服务端回调到接入方服务端。 |
适用场景 | 无公网 / 本地部署 / IoT。 | 有公网服务端、运维成熟。 |
具体方案 |
总体架构
角色与边界
关键设计原则
IM 不做 AI 编排：所有意图识别、模型路由、RAG、工具调用都在接入方业务侧。IM 只看到 botID 收发文本。
botID = 会话主键：每个 AI 助手对应一个 IM @RBT# 账号，历史消息天然按 botID 维度落库。
消息即记忆：多轮上下文不需要单独存储，每次回复前从 IM 拉历史即可（配合缓存与窗口管理）。
流式可降级：流式消息在 LLM 出错时可回退为整段消息或撤回重发。
双轨解耦：客户端长连接与服务端回调是平行能力，接入方按部署形态二选一，业务层代码完全一致。
机器人账号体系
@RBT# 特殊账号
账号类型 | UserID 前缀 | 适用 |
普通用户 | 无 | 终端用户 |
机器人账号 | @RBT# | AI Bot |
botID 的工程优势（相比普通账号）
特性 | 普通用户账号 | botID（@RBT#） |
好友数上限 | 受套餐限制。 | 不限好友数。 |
加群数上限 | 受套餐限制。 | 不限加群数。 |
好友关系校验 | 若应用开启了好友关系校验，普通用户间需加好友才能发消息。 | 即使开启好友关系校验，botID 仍免校验，任何用户可直接发消息。 |
回调通道 | 公共 C2C/Group 回调。 | 支持独立机器人回调（可单独配置 URL，与普通业务回调隔离）。 |
流式消息发送 | 不支持。 | 专属支持（Bot 至用户方向 128K 流式）。 |
接入方价值：
一个 AI 助手可同时服务海量用户，不受普通账号好友数上限束缚（好友数根据不同套餐定义）。
群聊 AI 助理可无限加群，不需要为“机器人加群超限”做拆分。
独立回调让 AI 业务流量与普通 IM 业务流量天然隔离，监控、限流、路由更清晰。
方案一：基于客户端长连接
原理
用户将消息发送给一个或多个 @RBT# 开头的特殊用户（botID）。接入方服务端使用腾讯云提供的 IM SDK Node 版本，分别以每个 botID 身份登录 IM 服务器并建立持久长连接，机器人此时是一个“始终在线”的客户端，能够实时接收 IM 服务器推送的用户消息。
会话的记忆与上下文管理由接入方侧自行实现，整理后转发给 LLM；机器人的回复由 Node SDK 客户端通过流式消息接口以机器人账号身份逐片下发（注意：不是服务端 REST API 发送，是客户端 SDK 发送）。
关键约束：一个 botID 对应一条长连接。有多少个 @RBT# 特殊用户，就需要维持多少条长连接。
消息流程（端到端）
步骤说明
步骤一：客户端输入
输入方式 | 说明 |
文本输入 | 标准 IM 消息。 |
语音输入 | 录音，随后调 IM SDK 的 convertVoiceToText 转文本，再发文本消息。 |
为什么发文本而不是语音消息？
LLM 直接处理文本，无需额外转换；
文本可被 IM 历史存储和搜索；
多端展示统一。
步骤二：ASR 语音转文字
步骤三：客户端发消息至 botID
目标 UserID：@RBT#xxx（机器人专属前缀）；
消息类型：
TextMessage，可挂 cloudCustomData 携带场景标签（用于 Bot 路由）；会话类型：单聊（C2C）或群聊（GROUP，群里 @机器人触发）。
步骤四：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 长期保存。
步骤五：调用 LLM
接入方自选模型：混元 / 豆包 / DeepSeek / Kimi / 自部署 Llama / Qwen / GLM 等。
步骤六：LLM 流式输出
LLM 以流式模式持续输出 token。
步骤七：Bot 通过 Node SDK 流式发送回复
注意：
方案一中流式消息由客户端 SDK 发送，不是服务端 REST API。
步骤八：IM 流式文本下发 + 客户端发起 TTS + 显示与播报
IM 服务收到 Bot 的流式消息后，文本和音频通过两个独立通道分别送达客户端：
通道 | 内容 | 说明 |
流式消息通道（IM 消息长连接） | 逐片下发文本消息。 | 客户端拼接显示，模拟打字机效果。 |
TTS 音频通道（WebSocket） | 客户端发起 TTS 请求后，IM 服务逐语义片段合成语音并回推音频 chunk。 | 客户端边收边播，首音延迟低。 |
IM SDK 触发
onMessageReceived，每个流式分片都是一次回调，客户端 UI 拼接显示文字。客户端通过 WebSocket 向 IM 服务发起 TTS 请求 ，详见 文字转语音。
TTS 由 IM 服务统一提供（一句话 TTS / 流式 TTS 两种模式），详见 语音播报（TTS）。
部署形态
部署位置：客户端长连接方式可以部署在接入方的服务端，并不局限于本地/边缘场景。
非 Node 技术栈接入方：即便接入方主业务服务端不是 Node.js（Java / Go / Python / .NET / PHP 等），也可以单独起一个 Node 进程作为 IM 接入网关，主业务通过内部 RPC / MQ / HTTP 与该 Node 进程通信。对接入方的额外成本只是“运维一个 Node 服务”，不需要把整套业务迁移到 Node。
特点与限制
特点：
机器人需保持在线（长连接登录）；
由客户端长连接驱动，消息接收实时性强；
会话记忆完全由接入方侧掌控，灵活度高；
主动出站，无需公网回调地址，适用于本地部署、IoT、内网等无法提供公网回调的场景。
限制：
1 botID = 1 条长连接，多机器人场景需多进程编排（如 k8s pod-per-bot）；
非 Node 接入方需额外部署一个 Node 进程。
官网文档指引
基于客户端长连接，所涉及的接收消息、拉取历史、流式发送回复等均走 Node.js 插件能力。下表列出方案一需要用到的核心能力及其官网文档，以官网最终发布为准。
方案二：基于服务端回调
原理
机器人无需在线。IM 服务端提供机器人回调机制：当用户在单聊中给机器人发消息、或在群聊中 @ 机器人时，IM 服务端会将消息回调到接入方预先配置的回调地址。接入方服务端基于回调内容处理消息、转发给 LLM，并将机器人的回复通过服务端 REST API 流式消息接口（发送 C2C 流式消息 / 发送群流式消息）以机器人账号身份逐片下发。
消息流程
构建上下文记忆
机器人收到回调后，需要带上历史对话上下文才能让 LLM 给出连贯回复。方案二基于服务端回调，记忆的构建方式因会话类型不同而有所差异：
单聊（C2C）场景
单聊中，用户发给 @RBT# 机器人的每条消息都会触发回调。接入方可以直接基于回调本身构建会话记忆，回调到达时将消息写入自有存储，需要上下文时从自有存储中取出即可。
优先建议业务侧自行存储会话记忆，优势在于上下文读取延迟低、裁剪策略灵活可控、不依赖 IM 历史消息接口的调用频次与存储时长限制。
群聊场景
群聊中，只有 @机器人 的消息才会触发回调，群内其他用户之间的普通对话不会回调。因此无法仅通过回调获取完整的群聊上下文。
正确的做法是：收到 @机器人 的回调后，通过服务端 REST API 拉取该群的近期历史消息，将群内对话整理为 LLM 可理解的上下文，连同当前 @机器人 的消息一起转发给 LLM。
会话类型 | 记忆来源 | 接口 |
单聊（C2C） | 回调本身即可获取用户发给机器人的全部消息，自行存储构建记忆。 | 回调 + 自有存储 |
群聊 | 回调仅含 @机器人 的消息，需拉取群历史补全上下文。 | 回调 + REST API /v4/group_open_http_svc/group_msg_get_simple |
如有需要，单聊场景也可以通过 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 长期保存。
两类回调（按场景选其一或叠加）
回调类型 | 触发范围 | 适用场景 |
单聊/群聊发消息后回调 | 全量：平台下所有单聊、群聊消息都会触发。 | 已有完整 IM 业务、Bot 只是其中一类消息消费者；接入方侧自行根据 To_Account 是否为 @RBT# 前缀过滤路由。 |
机器人回调（Bot 专属） | 只触发与机器人相关的消息： 单聊里发给 @RBT# 机器人的消息； 群聊里 @机器人 的消息。 | 纯 AI 场景，只关心机器人需要应答的消息；流量天然过滤、链路独立。 |
选型建议：纯 AI 助手场景优先用机器人回调，避免接收无关消息浪费带宽；如果接入方已有成熟的统一回调网关，可继续用单聊/群聊后回调，在网关侧过滤分发。
部署形态
注意事项
2 秒内必须 ACK，否则 IM 重试导致消息重复；
签名验证必做，防止伪造请求；
单接入点托管多 botID：所有机器人消息汇入同一回调，适合大规模 Agent 矩阵。
特点
机器人无需维护长连接；
由 IM 服务端回调驱动，部署与运维更轻量；
回调仅在单聊发消息和群聊 @ 机器人时触发；
成熟、可水平扩展、无长连接维护成本。
官网文档指引
方案二基于服务端回调：接收消息靠机器人回调，拉取历史与发送流式回复均走服务端 REST API；端上语音输入（ASR）与语音播报（TTS）与方案一一致，由客户端 SDK / IM 服务承担。下表列出方案二需要用到的核心能力及其官网文档，未上线的以官网最终发布为准。
能力 | 说明 | 官网文档 |
单聊机器人消息回调 | Bot.OnC2CMessage，用户单聊发给 @RBT# 机器人时触发。 | |
群内 @机器人消息回调 | Bot.OnGroupMessage，群内 @ 机器人时触发。 | |
服务端拉取单聊历史 | REST API /v4/openim/admin_getroammsg，拉取单聊漫游消息构建上下文。 | |
服务端拉取群聊历史 | REST API /v4/group_open_http_svc/group_msg_get_simple，拉取群消息构建上下文。 | |
服务端发送流式消息（单聊） | REST API send_c2c_stream_msg，逐片下发单聊回复。 | |
服务端发送流式消息（群聊） | REST API send_group_stream_msg，逐片下发群聊回复。 | |
客户端语音转文字（ASR） | IM SDK 的 convertVoiceToText，客户端录音后整段转文本。 | |
客户端 TTS 相关 | IM 服务 TTS 在客户端侧的接收与播报（一句话 TTS / 流式 TTS）。 |
两种方案对比
对比项 | 方案一：客户端长连接 | 方案二：服务端回调 |
机器人是否需在线 | 需要（长连接登录）。 | 不需要。 |
消息接收方式 | 客户端长连接实时推送。 | IM 服务端回调到接入方回调地址。 |
驱动方式 | 客户端 SDK 驱动。 | 服务端回调驱动。 |
触发范围 | 单聊：发给该 botID 的消息；群聊：该 botID 所在群的所有消息。 | 单聊发消息、群聊 @ 机器人。 |
单接入点支持 botID 数 | 1 个 botID = 1 条长连接。 | 不限（所有机器人消息汇入同一回调）。 |
会话记忆实现 | 机器人端自行存储，如有需要可通过 Node SDK 拉取历史。 | 单聊可通过回调构建记忆，群聊需拉取群历史。 |
回复方式 | Node SDK 流式消息接口（客户端发送）。 | 服务端 REST API 流式消息接口（send_c2c_stream_msg / send_group_stream_msg）。 |
部署/运维复杂度 | 较高（需维护在线长连接、断线重连等）。 | 较低（无状态回调，按需触发）。 |
公网暴露 | 不需要（主动出站）。 | 必须（开放公网入口）。 |
适用行业 | 无法提供公网回调地址（本地部署、IoT、内网等）。 | 通用。 |
适用场景 | 无法提供公网回调地址的场景（本地部署设备、IoT、边缘计算、内网环境等），或对消息接收范围要求全面。 | 可提供公网回调地址、机器人交互以单聊/群聊 @ 为主、希望轻量接入、大规模 Agent 矩阵。 |
优点 | 实时性强、对消息控制力强、无需公网回调地址。 | 无需常驻在线、接入与扩展简单、单点托管多 botID。 |
缺点 | 需保障长连接稳定性、资源占用相对高、1 botID=1 连接。 | 仅覆盖回调触发的消息类型、必须开放公网入口。 |
语音输入（ASR）
IM SDK 内置 ASR（语音转文字）能力，无需端侧集成第三方 ASR SDK。
当前为一句话 ASR 模式：录音结束后整段送转，返回完整文本。
接口 | 文档链接 |
IM SDK convertVoiceToText |
流式消息
为什么需要流式消息
LLM 单条回答经常超过 8K（尤其长文生成、代码生成、多轮总结场景），普通 IM 文本消息有长度上限。流式消息把一条逻辑消息拆成多个 chunk 下发，单条逻辑消息上限 128K，覆盖 LLM 长回答场景。
接口说明
方案一：Node SDK 客户端发送
接口 | 用途 |
Node SDK 流式消息接口（单聊） | Bot 以客户端身份向单聊会话发送流式消息，逐片追加，最后一片置 IsStreamEnd = true。 |
Node SDK 流式消息接口（群聊） | Bot 以客户端身份向群聊发送流式消息，分片机制同上。 |
发送流式消息
发送流式消息的接口。与普通消息的区别在于 payload 使用流式专用结构，通过分块（chunk）逐次追加内容，服务端下发到接收方后由 SDK 拼装完整内容。首次调用返回消息实例，后续调用携带同一 streamMessageID 追加分块，直到 isStreamEnd = true 结束。
注意：
index 从 1 开始严格自增，不可跳号；服务端按 index 去重、排序。
streamMessageID 由服务端首次响应生成，客户端不要自行拼装。
单个 chunk 的 isStreamEnd = true 后，不应再对同一
streamMessageID 追加。接口
chat.callExperimentalAPI('sendStreamMessage', options);
参数
options 参数如下：
参数 | 类型 | 默认值 | 描述 |
to | String | - | 消息接收方的 userID 或 groupID。 |
conversationType | String | - | 会话类型，取值 'C2C' 或 'GROUP'。 |
payload | Object | - | 流式消息内容容器，字段说明见下方 payload 表。 |
priority | String | Normal | 消息优先级（仅 GROUP 生效）。 |
cloudCustomData | String | '' | 消息自定义数据，随消息一起下发到对端。 |
receiverList | Array | - | GROUP 定向消息接收者列表，最多 50 人。 |
nick | String | - | 发送方昵称，未传时从本地资料读取。 |
avatar | String | - | 发送方头像 URL，未传时从本地资料读取。 |
payload 的描述如下：
参数 | 类型 | 描述 |
streamMessageID | String | 流式消息 ID。首次调用不传；后续追加时必传，取自首次调用返回消息实例的 payload.streamMessageID。 |
chunks | Array | 本次要发送的分块列表，元素结构见下方 chunk 表。 |
chunks 元素的描述如下：
参数 | 类型 | 描述 |
index | Number | 分块序号，从 1 开始严格自增，不能跳号。 |
markdown | String | 该分块的 markdown 文本内容。 |
isStreamEnd | Boolean | 是否为流式结束块。默认 false；设为 true 时服务端认为整条流式消息结束。 |
返回值
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 },],},});
方案二：服务端 REST API 发送
接口 | 用途 | 文档 |
发送单聊流式消息（send_c2c_stream_msg） | 从一个账号向另一个账号发送 C2C 流式消息，单条消息内创建 StreamID 并按 MsgSeq 持续追加，最后一片置 IsStreamEnd = true。 | |
发送群流式消息（send_group_stream_msg） | 从一个账号向一个群发送流式消息，分片机制同上，群聊场景使用（如群里 @ 机器人触发流式回复）。 |
语音播报（TTS）
机器人回复到达客户端后，IM 服务提供 TTS（Text-to-Speech）能力，将文本消息转为语音播报给用户。客户端无需自建 TTS，IM 服务统一提供两种播报模式：一句话语音合成（一句话 TTS） 和 实时语音合成（流式 TTS）。
播报模式
模式 | 一句话 TTS | 流式 TTS |
触发时机 | 流式消息全部完成（IsStreamEnd = true）后，客户端发起 TTS 请求，IM 服务拿全文合成语音。 | 流式消息进行中，客户端即可发起 TTS 请求，IM 服务逐语义片段生成语音并流式回推。 |
首音延迟 | 高（需等 LLM 全部输出完 + TTS 合成完）。 | 低（LLM 首批 chunk 到达后即可开始合成和回推音频）。 |
体验 | 用户先看完全部文字，再听语音；适合短信式通知、短回复。 | 边看边听，体验对齐主流 AI 语音助手；适合长回复、对话式交互。 |
实现复杂度 | 低（全文一次性合成）。 | 较高（需按 chunk 粒度合成、流式回推音频、处理 chunk 边界的断句）。 |
适用场景 | 短回复（< 100 字）、通知类消息、语音信箱。 | 长回复、AI 陪伴/角色扮演、语音对话、车机/车载场景。 |
离线推送
能力概览
腾讯云 IM 内置离线推送（Push）能力，覆盖苹果 APNs、FCM 以及国内主流安卓厂商通道（华为 / 小米 / OPPO / vivo / 魅族 / 荣耀），无需额外集成第三方推送 SDK。
能力 | 说明 |
全平台通道接入 | 自动适配 iOS（APNs）、海外安卓（FCM）、国内安卓厂商通道，统一一套接口。 |
厂商证书托管 | 各厂商证书 / Key 在 IM 控制台一次性配置，IM 侧负责通道分发。 |
消息触达策略 | 支持按消息维度、全局维度、用户维度配置推送规则（声音、角标、跳转、静默时段等）。 |
角标管理 | 支持自动累加 / 重置角标，跨多端保持一致。 |
接收方在线状态判定 | 由 IM 服务端自动判定，无需业务侧维护在线状态。 |
通道协议适配 | 不同厂商透传 / 通知通道协议差异由 IM 内部抹平。 |
在 AI 助手场景下的两类典型用法
1. AI 回复触达通知
当用户发起提问后切走 App / 锁屏，Bot 完成 LLM 处理并通过 IM 回发消息时，若接收方处于离线状态，IM 自动按推送策略下发系统通知，引导用户回到对应会话查看回答。
业务侧无需自建轮询、无需维护推送通道，只要正常发 IM 消息即可触发推送，离线判断与厂商通道分发由 IM 接管。
2. 运营触达
通过 IM REST API 或控制台对指定 userID / 标签人群下发推送通知，支持沉默用户召回、新功能上线提醒、重要事件通知等场景。推送与 IM 消息共用同一套用户体系，无需额外的设备 ID / 标签映射。
关键接口
安全与合规
数据流向
数据类型 | 经过 IM？ | 存储位置 |
用户文本消息 | 经过 IM | IM 历史 + 接入方业务库（可选） |
LLM 输入/输出 | 不经过 IM | 完全在接入方业务服务器 |
RAG 知识库 | 不经过 IM | 接入方业务服务器 |
用户隐私（手机号等） | 由接入方决定 | 接入方业务服务器 |
说明：AI 业务数据（LLM 输入输出、模型权重、RAG 知识库、用户隐私）均在接入方业务服务器内闭环处理，不经过腾讯云 IM。IM 仅负责 botID 与用户之间的文本消息收发，不感知也不存储 AI 业务数据。
业务准入控制（可选）
机器人场景下，接入方常有这类业务诉求：判断某个用户是否被允许向某个机器人发消息、或在群内 @ 某个机器人是否被允许（如 VIP 专属机器人、每日调用次数限制、黑名单、付费开通、灰度等）。这类规则高度业务化，IM 不提供标准方案，由接入方业务侧自行定义。
这一步是可选的。仅当接入方确有准入类业务要求时启用；无相关需求时不配置，不影响主流程。它位于主链路“用户发消息至消息到达机器人”之间，是一个可插拔的准入闸门。
方法一：服务端消息前回调
IM 在消息下发前提供回调，由接入方服务端判断是否放行，并通过返回码控制 IM 后续动作：
回调返回码：
ErrorCode | 含义 | IM 后续动作 |
0 | 允许发送 | 消息正常下发，进入 Bot 接收 / 机器人回调链路。 |
1 | 拒绝发送 | 不下发，给发送方返回错误码（单聊 20006 / 群聊 10016）。 |
2 | 静默丢弃 | 不下发，但给发送方返回成功（发送方无感知）。 |
自定义区间 | 拒绝并携带原因 | 单聊 [120001,130000] / 群聊 [10100,10200] 区间内的错误码会随 ErrorInfo 透传到客户端，便于前端展示“无权限/达上限”等提示。 |
方法二：Bot 侧自行管理
如果接入方不希望或无法使用消息前回调（如方案一零公网暴露场景），也可以在 Bot 侧自行增加管理逻辑：Bot 收到用户消息后，先判断该用户是否被允许与当前机器人交互（如查询自有权限表、调用次数计数、黑名单校验等），若判定不响应则直接丢弃该消息、不调 LLM、不回复。
与方法一的区别：方法一在消息下发前拦截，用户端能看到“发送被拒绝”的反馈；方法二在 Bot 收到消息后判断，无法阻止消息到达 Bot，但可以控制是否响应。两种方法可根据部署形态和业务需求灵活选择。
与两种接入方式的关系
方案一（客户端长连接）：方案一通常面向“无公网”场景，而消息前回调要求一个公网回调入口。若坚持零公网暴露，可在 Bot 侧收到消息后自行做权限校验（方法二），但无法在“消息发出前”拦截，体验上不如消息前回调；若愿意为准入单独开放一个公网回调地址，则可与方案一混合使用。
消息前回调默认 2s 超时，超时默认按“正常下发”处理（控制台可自助配置超时策略）。准入逻辑应尽量轻量，避免拖慢消息发送。
方案二（服务端回调）：接入方本就有公网回调入口，启用消息前回调几乎零额外成本，可与机器人回调共用同一套回调服务，是落地准入控制最自然的方式。
