作者阿里云消息团队Apache RocketMQ 5.5.0 已正式发布。本次版本的重要特性之一是社区提案RIP-83 定义的全新消息模型 LiteTopic 进入开源版本。LiteTopic 面向 AI Agent、异步任务和海量轻量会话场景支持百万级轻量会话通道共存并在轻量通道管理、消费状态持久化和事件驱动分发等方面进行了针对性设计。此前阿里云云消息队列 RocketMQ 版已围绕相关 AI 通信场景提供能力随着 LiteTopic 进入开源版本这一消息模型也首次以开源形式面向全球开发者开放。行业正在收敛Agent 异步通信成为共识在 RocketMQ 5.5.0 发布前后AI 行业的协议和框架演进也在不约而同地指向同一个方向。Anthropic MCP 2026 Roadmap高度关注 Transport 可扩展性、Agent Communication、任务生命周期管理以及会话状态外化等问题。其核心矛盾在于有状态 Agent 会话与负载均衡、水平扩展之间存在天然冲突而任务失败后的重试、结果过期后的清理等生产级生命周期语义也需要更稳定的运行时支撑。Google ADK也发布了 Long Running Agent 方案指出标准对话循环并不适合所有长时任务场景系统需要更显式的状态持久化、事件驱动唤醒以及多 Agent 委托协同。两条路径收敛到同一组基础设施需求1. 海量会话通道每个 Agent 会话都需要独立通信通道不能因水平扩展而丢失。2. 状态持久化与断点续传服务重启、冷启动后需要能够从上次中断处精确恢复。3. 异步生命周期管理任务失败有重试结果过期有回收调度由事件驱动而非客户端轮询。这三个需求不只是协议层或框架层的问题也对消息通信基础设施提出了更高要求。LiteTopicAI 时代消息通信的开源答案面对 AI 时代海量轻量会话、状态持久化与事件驱动调度等消息通信基础设施需求Apache RocketMQ 社区在 2025 年发起 RIP-83Lite Topic: A New Message Model提案从消息模型层面设计了应对方案。随着 5.5.0 发布LiteTopic 已进入开源版本。为什么不能用传统的 Topic Consumer Group 组合来解决核心原因是当每个 Agent 会话都使用独立 Group 订阅独立 Topic 时读请求会随 Topic 数量快速膨胀Broker 轮询全量 Topic 检查新消息无效扫描的 CPU 开销也会随规模线性增长传统 Topic 需要预先创建无法很好适配按需动态分配而 Group 模型天然偏向共享消费也不完全适合会话级独占订阅。LiteTopic 的设计目标就是绕过这些限制。三个行业需求对应三类优化方向需求 1 → 父 Topic 动态子 TopicLiteTopic 采用“父 Topic 命名空间 轻量子 Topic 会话通道”双层结构。父 Topic 除了起到隔离命名空间的作用之外还承担同一业务域的集中管控解决海量 Topic 场景下的服务发现问题。子 LiteTopic 支持按需创建和轻量化管理底层以 RocksDB 替代传统 ConsumeQueue 文件从而提升单个 Broker 对海量 LiteTopic 的承载能力。需求 2 → Broker 侧消费位点持久化LiteTopic 将消费位点以“内存快照 增量持久化”方式存储在 Broker 端。Agent 节点异常重启后重新订阅时可以基于已保存状态继续消费降低业务层自行维护会话状态的复杂度。与 Google ADK 的DatabaseSessionService解决的是同一类问题区别在于 LiteTopic 将这类能力内置于消息队列层无需业务层另行实现。需求 3 → 事件驱动调度 生命周期自管理面对大量低频、分散的轻量主题如果仍采用传统全量轮询方式系统会在无效扫描上消耗较多资源。LiteTopic 通过事件驱动的 Ready Set 结构在有消息写入或可读事件触发时再进行精准唤醒而非全量轮询。同时RocketMQ 本身具备的消费重试能力也为 Agent 通信提供了生产级的失败兜底机制。订阅关系更贴近 ClientID 维度而非传统 Consumer Group 维度Agent 节点上下线时也更有利于降低集群级重平衡带来的开销。LiteTopic 与传统 Topic 的核心差异如下核心机制深度拆解3.1 RocksDB百万级共存的存储基础传统 Topic 的每个 Queue 对应一个 ConsumeQueue 文件——百万个 Topic 意味着数百万个小文件文件系统碎片化读写是性能衰退的根因。LiteTopic 将索引层切换为 RocksDB以键值对方式统一管理消费位点写入路径不变消息仍走 CommitLog 顺序追加不改变高性能写入链路。索引统一管理一个 RocksDB 引擎支撑海量 LiteTopic 共存。结合 TTL 自动回收机制开发者无需长期手动清理历史会话资源也能降低历史会话持续累积带来的资源占用压力。这使 LiteTopic 更适合承载大量轻量、动态的会话通道也更适合长期运行的 AI 应用场景。3.2 事件驱动 Ready Set减少无效扫描的调度跃迁传统 Pop 模式以长轮询驱动消费者周期性向 Broker 发起请求Broker 遍历全量主题检查新消息。如果百万级 LiteTopic 仍使用这种读模式全量扫描效率低会消耗大量 CPU。5.5.0 引入专用的 LiteTopic 专用的事件驱动读取机制Broker 内部维护“就绪集合”。有新消息写入或者可读事件触发时才将对应 LiteTopic 放入就绪队列。事件触发时直接定位订阅的客户端实现按需精准唤醒。这与 Google ADK Long Running Agent 的“wake up only when an external event arrives”在设计思路上是一致的——区别在于 LiteTopic 是消息队列层面的原生机制。3.3 消费位点持久化与会话续传LiteTopic 的两个关键语义构成了 Agent 通信稳定性的基础订阅关系更贴近单会话通信语义与传统消费模式中 Consumer Group 共享消费进度不同LiteTopic 的订阅关系更贴近特定客户端连接有助于降低海量会话并发场景下的系统调度复杂度。Broker 仅对绑定连接投递消息Agent 节点上下线只更新该条绑定记录不触发集群级重平衡——这是百万级会话并发场景下系统稳定性的核心保障。消费位点 Broker 持久化内存快照 增量持久化存储在 Broker 端Agent 异常重启后 Broker 自动定位断点、继续投递无需业务层实现状态管理。五分钟跑通 Multi-Agent 异步通信以“主控 Agent 分发任务 → 执行 Agent 处理 → 结果异步回传”场景为例。注具体配置项、启动方式和管理命令请以 Apache RocketMQ 5.5.0 官方文档及示例为准。完整示例参考 rocketmq-clients[1]仓库中的LiteProducerExample和LitePushConsumerExample。Step 1启动 RocketMQ 5.5.0# 1. 下载并解压 wget https://mirrors.aliyun.com/apache/rocketmq/5.5.0/rocketmq-all-5.5.0-bin-release.zip unzip rocketmq-all-5.5.0-bin-release.zip cd rocketmq-all-5.5.0-bin-release # 2. 追加 LiteTopic 配置到 broker.conf cat conf/broker.conf EOF enableLmqtrue enableMultiDispatchtrue storeTypedefaultRocksDB EOF # 3. 启动 NameServer nohup sh bin/mqnamesrv # 4. 启动 Broker nohup sh bin/mqbroker -n localhost:9876 -c conf/broker.conf # 5. 启动 Proxy nohup sh bin/mqproxy -n localhost:9876 # 6. 创建 LiteTopic sh bin/mqadmin updateTopic -b localhost:10911 -t AGENT_TASK_NS -a message.typeLITE # 7. 创建 LiteGroup sh bin/mqadmin updateSubGroup -b localhost:10911 -g executor-group -o true --attributes lite.bind.topicAGENT_TASK_NSStep 2主控 Agent 投递任务// 父 Topic 作为命名空间所有 LiteTopic 共享 static final String PARENT_TOPIC AGENT_TASK_NS; Producer producer provider.newProducerBuilder() .setClientConfiguration(clientConfig) .setTopics(PARENT_TOPIC) .build(); // setLiteTopic() 指定目标 Agent 的专属通道无需预创建 Message task provider.newMessageBuilder() .setTopic(PARENT_TOPIC) .setLiteTopic(TASK_ executorAgentId) .setBody(taskPayload.getBytes(StandardCharsets.UTF_8)) .build(); producer.send(task);Step 3执行 Agent 订阅并处理LitePushConsumer worker provider.newLitePushConsumerBuilder() .setClientConfiguration(clientConfig) .setConsumerGroup(executor-group) .bindTopic(PARENT_TOPIC) .setMessageListener(msg - { String result llmService.invoke(new String(msg.getBody())); replyProducer.send(buildReply(PARENT_TOPIC, RESULT_ sessionId, result)); return ConsumeResult.SUCCESS; }) .build(); // 动态订阅专属 LiteTopic首次订阅自动创建 worker.subscribeLite(TASK_ executorAgentId); // 宕机重启后 Broker 自动恢复消费位点从断点继续投递父 Topic AGENT_TASK_NS 作为命名空间每个执行 Agent 独占一个 LiteTopic 接收任务结果通过另一个 LiteTopic 异步回传。动态上下线不触发集群重平衡宕机后消费位点自动续接TTL 到期自动清理。const consumer await new LitePushConsumerBuilder() .setClientConfiguration({ endpoints, namespace, sessionCredentials }) .setConsumerGroup(consumerGroup) .bindTopic(inboundTopic) .setMessageListener({ async consume(messageView: MessageView) { await messageHandler({ accountId, messageView, cfg }); return ConsumeResult.SUCCESS; } }) .startup();阿里云商业版开源之上的企业级增强开源 5.5.0 提供 LiteTopic 核心模型轻量存储、事件驱动分发、Broker 侧会话续传。阿里云云消息队列 RocketMQ 版在此基础上针对企业级 AI 生产诉求做了专项增强LiteTopic 还提供了 Consume Suspend 能力在 GPU 资源紧缺的背景下AI 服务平台基于这个能力能够实现“千人千面”的精细化流量控制做到分级服务和优先级资源调度。传统限流的困境在于单个用户的慢任务会阻塞其他用户的消息处理限流等待直接阻塞消费线程影响整体吞吐而且预创建的 High/Mid/Low 队列粒度太粗。LiteTopic 为每个用户/会话创建独立通道后限流策略就可以独立执行——AI 服务平台通过消费挂起Suspend机制实现平滑限流不粗暴拒绝而是将超限请求顺延到下个时间窗口目前阿里云大模型服务平台百炼网关已基于 LiteTopic 构建异步事件工作流在生产环境以“千人千面”流控管理 AI 推理请求的流量峰值与算力调度。与社区共建 AI 原生消息基础设施5.5.0 是 Apache RocketMQ 走向 AI 原生的重要一步。Anthropic 和 Google 在协议层和框架层定义异步 Agent 通信标准消息队列在基础设施层提供运行时保障——两个层次彼此互补。值得关注的是MCP 已成立 Triggers Events Working Group方向是补齐“Server 主动推送”能力——这恰恰是消息队列发布/订阅模型的天然能力。同时 MCP 正在推进 Server Registry类似 A2A Agent Card意味着 MCP 正向通用 Agent 通信协议演进。社区正在探索的下一阶段方向LiteTopic 作为 MCP 会话外化层为 MCP Streamable HTTP 提供持久化、可异步投递的会话状态管理。LiteTopic 与 MCP Tasks 协议层对接探索 RocketMQ Transport 承接 MCP 的传输、Task 调度和状态保持。集成到 Openclaw/Hermes Agent/QwenPaw 等开源通用 Agent 框架用 Litetopic 扩展 Agent Channel将对话型 Agent 升级为事件驱动型 Agent更深入地嵌入企业业务流程中。如果你对 RocketMQ for AI 方向感兴趣欢迎通过以下方式参与共建参与 RIP-83 及后续 RIP 讨论贡献对 AI Agent 通信场景的设计思路。在 GitHub 提交 Issue、PR或分享使用案例。加入钉钉技术交流群44552972。相关链接[1] rocketmq-clientshttps://github.com/apache/rocketmq-clients[2] Apache RocketMQ 5.5.0 Release Noteshttps://github.com/apache/rocketmq/releases/tag/rocketmq-all-5.5.0[3] RIP-83 提案原文https://github.com/apache/rocketmq/wiki/RIP%E2%80%9083-Lite-Topic:-A-New-Message-Model[4] 阿里云 RocketMQ for AI 解决方案https://www.aliyun.com/solution/tech-solution/rocketmq-for-multi-agent-communication[5] 阿里云 RocketMQ for AI 内容合集https://www.aliyun.com/activity/middleware/ai-mq[6] Apache RocketMQ 中文社区https://rocketmq-learning.com/延伸阅读《Apache RocketMQ for AI 战略升级开启 AI MQ 新时代》《Apache RocketMQ × AI面向 Multi-Agent 的事件驱动架构》《AgentScope x RocketMQ打造企业级高可靠 A2A 智能体通信基座》《AI 推理精细化流量治理实战RocketMQ LiteTopic 的“千人千面”流控方案》《官宣上线RocketMQ for AI企业级 AI 应用异步通信首选方案》
AI 时代的消息底座变了！RocketMQ 5.5.0 发布，LiteTopic 开启 AI 原生通信新时代
发布时间：2026/5/28 4:32:24
作者阿里云消息团队Apache RocketMQ 5.5.0 已正式发布。本次版本的重要特性之一是社区提案RIP-83 定义的全新消息模型 LiteTopic 进入开源版本。LiteTopic 面向 AI Agent、异步任务和海量轻量会话场景支持百万级轻量会话通道共存并在轻量通道管理、消费状态持久化和事件驱动分发等方面进行了针对性设计。此前阿里云云消息队列 RocketMQ 版已围绕相关 AI 通信场景提供能力随着 LiteTopic 进入开源版本这一消息模型也首次以开源形式面向全球开发者开放。行业正在收敛Agent 异步通信成为共识在 RocketMQ 5.5.0 发布前后AI 行业的协议和框架演进也在不约而同地指向同一个方向。Anthropic MCP 2026 Roadmap高度关注 Transport 可扩展性、Agent Communication、任务生命周期管理以及会话状态外化等问题。其核心矛盾在于有状态 Agent 会话与负载均衡、水平扩展之间存在天然冲突而任务失败后的重试、结果过期后的清理等生产级生命周期语义也需要更稳定的运行时支撑。Google ADK也发布了 Long Running Agent 方案指出标准对话循环并不适合所有长时任务场景系统需要更显式的状态持久化、事件驱动唤醒以及多 Agent 委托协同。两条路径收敛到同一组基础设施需求1. 海量会话通道每个 Agent 会话都需要独立通信通道不能因水平扩展而丢失。2. 状态持久化与断点续传服务重启、冷启动后需要能够从上次中断处精确恢复。3. 异步生命周期管理任务失败有重试结果过期有回收调度由事件驱动而非客户端轮询。这三个需求不只是协议层或框架层的问题也对消息通信基础设施提出了更高要求。LiteTopicAI 时代消息通信的开源答案面对 AI 时代海量轻量会话、状态持久化与事件驱动调度等消息通信基础设施需求Apache RocketMQ 社区在 2025 年发起 RIP-83Lite Topic: A New Message Model提案从消息模型层面设计了应对方案。随着 5.5.0 发布LiteTopic 已进入开源版本。为什么不能用传统的 Topic Consumer Group 组合来解决核心原因是当每个 Agent 会话都使用独立 Group 订阅独立 Topic 时读请求会随 Topic 数量快速膨胀Broker 轮询全量 Topic 检查新消息无效扫描的 CPU 开销也会随规模线性增长传统 Topic 需要预先创建无法很好适配按需动态分配而 Group 模型天然偏向共享消费也不完全适合会话级独占订阅。LiteTopic 的设计目标就是绕过这些限制。三个行业需求对应三类优化方向需求 1 → 父 Topic 动态子 TopicLiteTopic 采用“父 Topic 命名空间 轻量子 Topic 会话通道”双层结构。父 Topic 除了起到隔离命名空间的作用之外还承担同一业务域的集中管控解决海量 Topic 场景下的服务发现问题。子 LiteTopic 支持按需创建和轻量化管理底层以 RocksDB 替代传统 ConsumeQueue 文件从而提升单个 Broker 对海量 LiteTopic 的承载能力。需求 2 → Broker 侧消费位点持久化LiteTopic 将消费位点以“内存快照 增量持久化”方式存储在 Broker 端。Agent 节点异常重启后重新订阅时可以基于已保存状态继续消费降低业务层自行维护会话状态的复杂度。与 Google ADK 的DatabaseSessionService解决的是同一类问题区别在于 LiteTopic 将这类能力内置于消息队列层无需业务层另行实现。需求 3 → 事件驱动调度 生命周期自管理面对大量低频、分散的轻量主题如果仍采用传统全量轮询方式系统会在无效扫描上消耗较多资源。LiteTopic 通过事件驱动的 Ready Set 结构在有消息写入或可读事件触发时再进行精准唤醒而非全量轮询。同时RocketMQ 本身具备的消费重试能力也为 Agent 通信提供了生产级的失败兜底机制。订阅关系更贴近 ClientID 维度而非传统 Consumer Group 维度Agent 节点上下线时也更有利于降低集群级重平衡带来的开销。LiteTopic 与传统 Topic 的核心差异如下核心机制深度拆解3.1 RocksDB百万级共存的存储基础传统 Topic 的每个 Queue 对应一个 ConsumeQueue 文件——百万个 Topic 意味着数百万个小文件文件系统碎片化读写是性能衰退的根因。LiteTopic 将索引层切换为 RocksDB以键值对方式统一管理消费位点写入路径不变消息仍走 CommitLog 顺序追加不改变高性能写入链路。索引统一管理一个 RocksDB 引擎支撑海量 LiteTopic 共存。结合 TTL 自动回收机制开发者无需长期手动清理历史会话资源也能降低历史会话持续累积带来的资源占用压力。这使 LiteTopic 更适合承载大量轻量、动态的会话通道也更适合长期运行的 AI 应用场景。3.2 事件驱动 Ready Set减少无效扫描的调度跃迁传统 Pop 模式以长轮询驱动消费者周期性向 Broker 发起请求Broker 遍历全量主题检查新消息。如果百万级 LiteTopic 仍使用这种读模式全量扫描效率低会消耗大量 CPU。5.5.0 引入专用的 LiteTopic 专用的事件驱动读取机制Broker 内部维护“就绪集合”。有新消息写入或者可读事件触发时才将对应 LiteTopic 放入就绪队列。事件触发时直接定位订阅的客户端实现按需精准唤醒。这与 Google ADK Long Running Agent 的“wake up only when an external event arrives”在设计思路上是一致的——区别在于 LiteTopic 是消息队列层面的原生机制。3.3 消费位点持久化与会话续传LiteTopic 的两个关键语义构成了 Agent 通信稳定性的基础订阅关系更贴近单会话通信语义与传统消费模式中 Consumer Group 共享消费进度不同LiteTopic 的订阅关系更贴近特定客户端连接有助于降低海量会话并发场景下的系统调度复杂度。Broker 仅对绑定连接投递消息Agent 节点上下线只更新该条绑定记录不触发集群级重平衡——这是百万级会话并发场景下系统稳定性的核心保障。消费位点 Broker 持久化内存快照 增量持久化存储在 Broker 端Agent 异常重启后 Broker 自动定位断点、继续投递无需业务层实现状态管理。五分钟跑通 Multi-Agent 异步通信以“主控 Agent 分发任务 → 执行 Agent 处理 → 结果异步回传”场景为例。注具体配置项、启动方式和管理命令请以 Apache RocketMQ 5.5.0 官方文档及示例为准。完整示例参考 rocketmq-clients[1]仓库中的LiteProducerExample和LitePushConsumerExample。Step 1启动 RocketMQ 5.5.0# 1. 下载并解压 wget https://mirrors.aliyun.com/apache/rocketmq/5.5.0/rocketmq-all-5.5.0-bin-release.zip unzip rocketmq-all-5.5.0-bin-release.zip cd rocketmq-all-5.5.0-bin-release # 2. 追加 LiteTopic 配置到 broker.conf cat conf/broker.conf EOF enableLmqtrue enableMultiDispatchtrue storeTypedefaultRocksDB EOF # 3. 启动 NameServer nohup sh bin/mqnamesrv # 4. 启动 Broker nohup sh bin/mqbroker -n localhost:9876 -c conf/broker.conf # 5. 启动 Proxy nohup sh bin/mqproxy -n localhost:9876 # 6. 创建 LiteTopic sh bin/mqadmin updateTopic -b localhost:10911 -t AGENT_TASK_NS -a message.typeLITE # 7. 创建 LiteGroup sh bin/mqadmin updateSubGroup -b localhost:10911 -g executor-group -o true --attributes lite.bind.topicAGENT_TASK_NSStep 2主控 Agent 投递任务// 父 Topic 作为命名空间所有 LiteTopic 共享 static final String PARENT_TOPIC AGENT_TASK_NS; Producer producer provider.newProducerBuilder() .setClientConfiguration(clientConfig) .setTopics(PARENT_TOPIC) .build(); // setLiteTopic() 指定目标 Agent 的专属通道无需预创建 Message task provider.newMessageBuilder() .setTopic(PARENT_TOPIC) .setLiteTopic(TASK_ executorAgentId) .setBody(taskPayload.getBytes(StandardCharsets.UTF_8)) .build(); producer.send(task);Step 3执行 Agent 订阅并处理LitePushConsumer worker provider.newLitePushConsumerBuilder() .setClientConfiguration(clientConfig) .setConsumerGroup(executor-group) .bindTopic(PARENT_TOPIC) .setMessageListener(msg - { String result llmService.invoke(new String(msg.getBody())); replyProducer.send(buildReply(PARENT_TOPIC, RESULT_ sessionId, result)); return ConsumeResult.SUCCESS; }) .build(); // 动态订阅专属 LiteTopic首次订阅自动创建 worker.subscribeLite(TASK_ executorAgentId); // 宕机重启后 Broker 自动恢复消费位点从断点继续投递父 Topic AGENT_TASK_NS 作为命名空间每个执行 Agent 独占一个 LiteTopic 接收任务结果通过另一个 LiteTopic 异步回传。动态上下线不触发集群重平衡宕机后消费位点自动续接TTL 到期自动清理。const consumer await new LitePushConsumerBuilder() .setClientConfiguration({ endpoints, namespace, sessionCredentials }) .setConsumerGroup(consumerGroup) .bindTopic(inboundTopic) .setMessageListener({ async consume(messageView: MessageView) { await messageHandler({ accountId, messageView, cfg }); return ConsumeResult.SUCCESS; } }) .startup();阿里云商业版开源之上的企业级增强开源 5.5.0 提供 LiteTopic 核心模型轻量存储、事件驱动分发、Broker 侧会话续传。阿里云云消息队列 RocketMQ 版在此基础上针对企业级 AI 生产诉求做了专项增强LiteTopic 还提供了 Consume Suspend 能力在 GPU 资源紧缺的背景下AI 服务平台基于这个能力能够实现“千人千面”的精细化流量控制做到分级服务和优先级资源调度。传统限流的困境在于单个用户的慢任务会阻塞其他用户的消息处理限流等待直接阻塞消费线程影响整体吞吐而且预创建的 High/Mid/Low 队列粒度太粗。LiteTopic 为每个用户/会话创建独立通道后限流策略就可以独立执行——AI 服务平台通过消费挂起Suspend机制实现平滑限流不粗暴拒绝而是将超限请求顺延到下个时间窗口目前阿里云大模型服务平台百炼网关已基于 LiteTopic 构建异步事件工作流在生产环境以“千人千面”流控管理 AI 推理请求的流量峰值与算力调度。与社区共建 AI 原生消息基础设施5.5.0 是 Apache RocketMQ 走向 AI 原生的重要一步。Anthropic 和 Google 在协议层和框架层定义异步 Agent 通信标准消息队列在基础设施层提供运行时保障——两个层次彼此互补。值得关注的是MCP 已成立 Triggers Events Working Group方向是补齐“Server 主动推送”能力——这恰恰是消息队列发布/订阅模型的天然能力。同时 MCP 正在推进 Server Registry类似 A2A Agent Card意味着 MCP 正向通用 Agent 通信协议演进。社区正在探索的下一阶段方向LiteTopic 作为 MCP 会话外化层为 MCP Streamable HTTP 提供持久化、可异步投递的会话状态管理。LiteTopic 与 MCP Tasks 协议层对接探索 RocketMQ Transport 承接 MCP 的传输、Task 调度和状态保持。集成到 Openclaw/Hermes Agent/QwenPaw 等开源通用 Agent 框架用 Litetopic 扩展 Agent Channel将对话型 Agent 升级为事件驱动型 Agent更深入地嵌入企业业务流程中。如果你对 RocketMQ for AI 方向感兴趣欢迎通过以下方式参与共建参与 RIP-83 及后续 RIP 讨论贡献对 AI Agent 通信场景的设计思路。在 GitHub 提交 Issue、PR或分享使用案例。加入钉钉技术交流群44552972。相关链接[1] rocketmq-clientshttps://github.com/apache/rocketmq-clients[2] Apache RocketMQ 5.5.0 Release Noteshttps://github.com/apache/rocketmq/releases/tag/rocketmq-all-5.5.0[3] RIP-83 提案原文https://github.com/apache/rocketmq/wiki/RIP%E2%80%9083-Lite-Topic:-A-New-Message-Model[4] 阿里云 RocketMQ for AI 解决方案https://www.aliyun.com/solution/tech-solution/rocketmq-for-multi-agent-communication[5] 阿里云 RocketMQ for AI 内容合集https://www.aliyun.com/activity/middleware/ai-mq[6] Apache RocketMQ 中文社区https://rocketmq-learning.com/延伸阅读《Apache RocketMQ for AI 战略升级开启 AI MQ 新时代》《Apache RocketMQ × AI面向 Multi-Agent 的事件驱动架构》《AgentScope x RocketMQ打造企业级高可靠 A2A 智能体通信基座》《AI 推理精细化流量治理实战RocketMQ LiteTopic 的“千人千面”流控方案》《官宣上线RocketMQ for AI企业级 AI 应用异步通信首选方案》
