AI 时代的消息系统应该是什么样的——mq9 的思考与探索
一、mq9 现在在哪里
mq9 是 RobustMQ 为 AI Agent 通信设计的协议。核心语义是 mailbox——每个 Agent 拥有一个持久化的通信地址，消息在其中等待，直到 TTL 过期或被处理。发送方和接收方不需要同时在线。
目前 mq9 的基础能力已经就绪。
每个 Agent 拥有一个独立的 mailbox 作为通信地址，消息持久化存储直到 TTL 过期，发送方和接收方不需要同时在线。消息支持三个优先级（critical / urgent / normal），高优先级消息优先投递，同优先级保证 FIFO 顺序。多个 Agent 可以组成队列组竞争消费同一个 mailbox，每条消息只被处理一次，天然支持任务分发和负载均衡。公共 mailbox 支持自定义名称和描述，Agent 通过 PUBLIC.LIST 发现其他 Agent 的存在和能力。
六种语言的 SDK 可用（Python、Go、JavaScript、Java、Rust、C#），LangChain 和 LangGraph 的集成已经完成，MCP Server 支持进行中。
接下来是什么呢？我们希望 mq9 是 RobustMQ 在通往 AI 架构的门票。所以我们一直在思考 AI 时代消息系统应该是什么样的判断。接下来说一下我们的判断。
二、场景变了，现有的 MQ 不够用了
Kafka 很好。RabbitMQ 很好。NATS 很好。
但它们是为另一个时代设计的。
Kafka 解决的问题是：海量数据如何在系统之间高吞吐地流动。它的核心假设是——消息是数据，中间件是管道，消费者是数据处理程序。这套假设在大数据时代是完全正确的。
AI Agent 出现之后，场景变了。
Agent 之间传递的不只是数据，更多是意图——"帮我分析这份合同"、"任务完成，结果如下"、"我需要一个能处理法律问题的协作者"。意图和数据有本质的差异：数据是结构化的，意图是语义化的；数据的路由靠 Topic，意图的路由靠理解。
当 Agent A 想把一个法律问题交给"最合适的 Agent"处理，Kafka 告诉你：发到哪个 Topic？你需要提前知道目标。但 Agent A 不知道，它只知道自己的问题是什么。
这不是 Kafka 的缺陷，是场景变了。
更深的差异在于时间模型。传统 MQ 的设计假设是消费者在线，消息等待时间越短越好。但 Agent 是自治的，它有自己的节奏，可能在执行另一个任务，可能在等待人类确认，可能在休眠。Agent 之间的通信天然需要异步、持久化、可等待。
还有安全模型。传统 MQ 假设发送方是可信的，中间件只负责送达。但 Agent 是自主决策的，一个配置错误或被攻击的 Agent 可能发出危险指令——"删除数据库"、"转移资金"。传统中间件会忠实地送达这条消息，没有任何拦截。
场景变了，工具需要跟着变。
三、我们认为 AI 时代的消息系统应该是什么样的
这是一个开放的问题，我们没有全部答案。但有一些判断。
异步通信是基础，不是特性
在 AI Agent 的世界里，异步不是一种可选的通信模式，而是默认模式。
Agent 是自治的个体，它有自己的执行节奏。强迫 Agent 之间同步通信，等于强迫它们互相等待，破坏了自治性的根基。mailbox 语义——每个 Agent 有一个持久化的通信地址，消息在里面等你——是 AI 时代通信最自然的基础抽象。
这也是 mq9 设计的出发点。不是因为异步在技术上更复杂，而是因为它更符合 Agent 的工作方式。
服务发现应该内置于通信协议
传统的服务发现是独立的基础设施——Consul、Etcd、ZooKeeper。服务注册在一个地方，消息通信在另一个地方，两套系统需要协调。
但 mq9 的公共 mailbox 天然就是服务注册。Agent 创建一个公共 mailbox，填写 name 和 desc，其他 Agent 通过 PUBLIC.LIST 发现它。不需要额外的注册中心，通信协议本身就承担了服务发现的职责。
这不是刻意为之的设计，是 mailbox 语义的自然延伸。当你给每个 Agent 一个有意义的地址，服务发现就已经完成了。
路由应该理解语义，而不只是匹配地址
这是我们正在探索的方向，还没有确定答案。
传统路由是硬编码的——你知道要发给谁，你填入目标地址，中间件负责送达。这在系统之间的集成场景里工作得很好，因为系统的边界是清晰的。
但 Agent 协作的场景不同。Agent A 有一个需要处理的问题，它不知道应该发给谁，它只知道问题的内容。
如果中间件能理解消息的语义，能感知 Agent 的能力描述，能做向量相似度匹配——那么"发给最合适的 Agent"就不再是 Agent 自己的责任，而是通信基础设施提供的能力。
把 desc 向量化，把消息内容向量化，在路由层做匹配。中间件从"邮局"进化成"智能调度"。这个方向值得探索。
中间件应该理解意图，而不只是传递比特
这是更激进的判断。
现有的消息中间件是"无脑传输"的——它不知道消息内容是什么，不判断这条消息该不该被送达，只负责从 A 到 B。这个设计在人类系统里是合理的，因为安全策略由应用层来做。
但在 AI Agent 的世界里，应用层的安全策略是脆弱的。一个被误导的 Agent 可能发出包含"删除数据库"语义的消息，应用层的策略可能被绕过，但如果中间件在传输层就能识别这个意图并拦截，这就是基础设施级别的安全边界。
不依赖任何应用层的自律，在最底层加一道物理安全阀。
这需要中间件具备意图理解的能力——轻量的策略引擎，可配置的规则，针对高风险操作的意图审计。这不是小改动，是对消息中间件角色的重新定义。
我们认为这个方向有价值，但它是一个探索，不是今天的承诺。
上下文应该在基础设施层流动，而不只是在应用层传递
AI Agent 之间的通信有一个巨大的浪费：每次交互都在重复传递上下文。
Agent A 告诉 Agent B："你好，我是 A，我们之前讨论了 X，现在我需要你帮我做 Y。"这段上下文信息占用了大量 Token，在每次通信里被重复发送。
如果通信基础设施能感知 Session，记住 Agent 之间的对话历史，在消息流转时自动补全缺失的上下文——那么 Agent A 只需要说"做 Y"，中间件知道 A 和 B 的历史，会把必要的上下文一起带过去。
这让中间件从"无状态的管道"变成"有状态的上下文网络"。
这是最激进的探索方向，也是距离现实最远的一个。但我们认为它指向了正确的未来——在 AI 系统里，上下文是最宝贵的资源，基础设施层对上下文的感知和管理，会是下一代通信系统最重要的差异化能力之一。
四、mq9 的下一步
基础的 mailbox 通信能力已经完成。接下来 mq9 会沿着前面的判断，逐步实现这些能力。
第一阶段：语义服务发现
公共 mailbox 的 desc 字段向量化，PUBLIC.LIST 支持语义搜索。Agent 不需要知道目标的确切名字，只需要描述自己的需求，mq9 返回最匹配的 mailbox 列表。
这让 mq9 成为 AI Agent 系统天然的服务注册与发现基础设施。
第二阶段：语义路由
消息在发送时不需要指定确切的目标 mailbox。发送方描述意图，mq9 根据消息内容和已注册 Agent 的能力描述做向量匹配，自动路由给最合适的接收方。
从"我知道要发给谁"进化到"我只知道我要做什么"。
第三阶段：Intent-based Policy（意图感知策略）
在 mailbox 上配置策略规则。消息在传输时经过策略引擎，根据消息的语义内容判断是否符合策略，不符合的直接拦截。
这是传输层的安全边界，不依赖应用层的实现，不依赖 Agent 的自律。高风险操作在基础设施层就被挡住。
这里有一个多协议架构带来的天然优势。当策略引擎识别出风险消息，不需要额外的系统来处理这些审计事件——RobustMQ 内置一个风险 Topic，命中策略的消息自动写入，风险分析系统通过 Kafka 协议直接消费。数据没有任何跨系统的流转，业务代码不需要任何改动，也不需要在 mq9、消息队列、风险系统之间做额外的连接。
一套基础设施，一份数据，多个协议各取所需。这是 RobustMQ 多协议架构在 AI 安全场景下的具体体现——不是为了支持多协议而支持多协议，而是多协议让整个系统的复杂度真正降低了。
第四阶段：上下文感知（探索性）
mq9 感知 Agent 之间的 Session 上下文，消息在流转时自动携带必要的历史信息。Agent 之间的通信不再需要每次重复传递完整上下文，降低 Token 消耗，让 Agent 协作更高效。
这是最长期的探索方向。
这四个阶段不是线性的，会根据真实场景的反馈调整优先级。但方向是确定的——mq9 要成为 AI 时代通信的基础设施，从消息传递出发，逐步具备语义理解、智能路由、意图审计的能力。
mq9 协议文档：https://github.com/robustmq/robustmq-sdk/blob/main/docs/mq9-protocol.mdRobustMQ：https://github.com/robustmq/robustmq