Apache RocketMQ 面向 AI 演进：LiteTopic 支撑百万级多 Agent 会话协作

随着大语言模型技术的快速发展，AI Agent 正在从单智能体向多智能体协作演进。在这一过程中，异步通信与状态管理成为支撑大规模 Agent 系统的关键基础设施。传统消息中间件在应对 AI 场景时面临新的挑战：通道拓扑由静态转为动态、任务执行时长从毫秒级扩展至分钟甚至天级别、GPU 算力成本使得任何资源空转都不可接受。这些变化促使消息系统必须进行针对性演进。

AI 异步协作的三大新约束

Apache RocketMQ 团队推出的 LiteTopic 正是为解决上述问题而生。其核心设计思想是将每个 AI 会话映射为一个独立的轻量级 Topic，实现会话级的有序性、隔离性与可重放能力。在这一架构下，消息通道可以按需创建、自动回收，调度成本与活跃会话数而非总会话数相关，使得百万级通道共存成为工程上可行的方案。

LiteTopic 的核心架构设计

与传统应用相比，AI Agent 系统在异步协作维度产生了根本性变化。首先是通道拓扑的动态化——传统应用的业务流在设计期确定，而 AI Agent 的执行路径由运行期决策动态派生，通道数量无法预先枚举。其次是任务时长的显著延长——单次 AI 任务常达分钟级，长会话可跨越数天，中间状态的频繁读写对基础设施提出更高要求。第三是成本结构的根本改变——GPU 单位算力成本远高于 CPU，任何形式的算力空转都直接反映在成本上。这些约束共同导致传统事件驱动模型出现三处不适配：积压斜率剧变、队头阻塞严重、重复推理造成资源浪费。

会话级消费与精细化调度

LiteTopic 采用 Parent Topic 与 LiteTopic 两层结构。Parent Topic 承担命名空间与控制边界职责，数量较少；而 LiteTopic 作为运行期的动态单位，无需预创建，第一条消息到达时自动生成，空闲后按 TTL 自动回收。在消费模型上，LiteTopic 将订阅粒度从 Group 级下沉到 Client 级，消息可精确投递至单个实例，保证每个 LiteTopic 在任一时刻仅被一个 Client 独占消费。这一设计既避免了会话内消息被拆分导致的顺序错乱，又使同一消费组内的不同实例可订阅不同的 LiteTopic 子集，实现会话级隔离。

在存储层面，LiteTopic 采用单份写入、多路索引的策略。消息体统一顺序追加至 CommitLog，后台 dispatch 线程并行构建两套索引：按 Parent Topic 组织的标准 ConsumeQueue 和按 LiteTopic 组织的 LiteCQ。为支撑百万级 LiteTopic，索引引擎从文件实现迁移至 RocksDB KV 引擎，Key 由 Topic、QueueID、Offset 组成，实现 O(1) 元数据查询。在投递机制上，LiteTopic 引入 Ready Set 替代全量轮询，仅聚合当前确实有消息可投的通道，调度成本从 O(订阅总数) 降为 O(活跃数)。

如有侵权，请联系删除。