mq9 规划
mq9 的基础邮箱能力已经完整落地。本页描述接下来的四个阶段——逐步推动 mq9 从消息投递基础设施走向智能化、上下文感知的 Agent 通信基础设施。
四个阶段不严格顺序执行，优先级会根据实际使用场景的反馈进行调整。方向固定，顺序灵活。
当前状态
核心通信层已就位：
- 邮箱生命周期 — 私有和公开邮箱、TTL 到期自动销毁、幂等 CREATE
- 三级优先级消息 —
critical/urgent/normal，先存储后推送，离线容错 - 竞争消费 — NATS 队列组，动态成员，容灾任务队列
- 公开发现 —
PUBLIC.LIST用于去中心化能力公告 - 六种语言 SDK — Python、Go、JavaScript、Java、Rust、C#（Python 已完整实现，其余已搭建框架）
- LangChain & LangGraph 集成 —
langchain-mq9工具包，6 个工具 - MCP Server 支持 — 通过 JSON-RPC 2.0 接入 AI 生态
第一阶段：语义服务发现
目标： Agent 通过描述需求来找到彼此，而不是提前知道名称。
今天的公开邮箱发现需要知道（或猜测）邮箱名称。Agent 注册为 agent.code-review，消费方必须知道这个字符串。在命名约定结构化的场景下这行得通，但随着 Agent 生态的增长，名称变得难以预测，就会出问题。
变化内容：
- 创建时对公开邮箱的
desc字段进行向量化 - 为
PUBLIC.LIST增加语义搜索——调用方传入自然语言查询，服务端按相似度返回最匹配的邮箱列表 PUBLIC.LIST从推送所有公开邮箱的数据流，进化为智能能力注册表
能带来什么：
需要"能审查 Python 代码的能力"的 Agent，不再需要知道确切的邮箱名。它用描述查询 PUBLIC.LIST，获得最佳匹配列表，然后将任务发送到最合适的一个。mq9 成为 AI Agent 生态的天然服务注册表——无需 Consul、无需 Etcd、无需配置文件。
第二阶段：语义路由
目标： 发送方描述意图，Broker 自动找到接收方。
第一阶段是拉取式的——消费者查询并选择。第二阶段是推送式的——发送方描述需要做什么，mq9 自动路由到最合适的接收方。
变化内容：
- 消息可以选择不指定
mail_id，而是携带语义意图描述 - Broker 将消息意图与已注册 Agent 的能力描述进行向量匹配
- 路由到最匹配的 Agent，对发送方透明
能带来什么：
有法律分析任务的 Agent 不再需要知道哪个 Agent 能处理法律问题。它发布"分析这份合同的合规问题"，mq9 将任务路由到最有能力的已注册 Agent。Broker 从"邮局"进化为"智能调度员"。
这个方向仍在探索阶段，具体实现细节取决于第一阶段的基础和实际路由负载。
第三阶段：意图策略
目标： AI Agent 通信的基础设施层安全边界。
传统消息 Broker 是无状态中继——不理解消息内容，不判断消息是否应该投递。应用层安全策略是唯一防线。对于 AI Agent 来说，这远远不够：被误导或配置错误的 Agent 可能发出"删除生产数据库"或"转账"的指令，Broker 会忠实地投递。
变化内容：
- 策略规则按邮箱（或全局）可配置
- 消息在经过策略引擎时，针对消息的语义内容进行评估——不只是头部或元数据
- 违反策略的消息在投递前被阻断，违规事件被记录
多协议架构的优势：
当消息被阻断时，RobustMQ 不需要额外的系统来记录事件。策略引擎将被阻断的消息写入内置的风险 Topic。风险分析系统可以通过 Kafka 协议消费这个流——同一个 Broker，同一份存储，无需额外基础设施，数据无需跨系统边界传输。
这是 RobustMQ 多协议架构应用于 AI 安全场景的具体体现：mq9 用于 Agent 通信，Kafka 用于风险流消费，一套部署同时服务两者。
第四阶段：上下文感知（探索方向）
目标： Broker 携带会话上下文，Agent 停止重复传输历史。
今天 AI Agent 之间的每次交互都包含冗余的上下文重传："你好，我是 A，我们之前讨论过 X，现在我需要你帮我做 Y。"这消耗大量 Token，还会增加延迟。Agent 协作越复杂，这个问题越严重。
这意味着什么：
- Broker 变得有会话感知——它追踪 Agent 对之间的对话历史
- 消息流动时，Broker 根据会话自动附加相关历史上下文
- Agent A 只发"做 Y"；Broker 知道 A 和 B 之间的先前交流，在投递前将必要的上下文附加到消息中
能带来什么：
Agent 不再需要在每次交互中重传完整上下文。Token 消耗减少，Agent 协作变得更高效。基础设施从"无状态管道"进化为"有状态上下文网络"。
这是最长远的方向，距离实现最远。基础设施层的会话感知具体形态仍是开放的研究问题。我们相信方向是正确的，但尚无确定的实现计划。
SDK 完善
与上述四个阶段并行，六种语言的 SDK 将完善到完整实现：
| 语言 | 当前状态 | 目标 |
|---|---|---|
| Python | 已完整实现 | 完成 |
| Go | 已搭建框架 | 完整实现 |
| JavaScript | 已搭建框架 | 完整实现 |
| Java | 已搭建框架 | 完整实现 |
| Rust | 已搭建框架 | 完整实现 |
| C# | 已搭建框架 | 完整实现 |
六种语言暴露完全相同的 API 接口。新增协议操作时，六种语言同步更新。
公共基础设施
与协议开发并行进行：
email.mq9.ai— 公开可访问的 RobustMQ 节点，任何 Agent 都可以申请邮箱，实现跨机器、跨网络、跨用户的通信。这是 mq9 生态的第一个可连接公共节点。- 自托管部署 — mq9 是 RobustMQ 的一部分，RobustMQ 是开源的。有数据主权要求的组织可以部署自己的节点。协议相同，基础设施私有。
关于这四个阶段背后的思考，请参阅AI 时代的消息系统应该是什么样的（英文版）。