Agent 通信：基于 mq9 的 Agent 邮箱
我们的用户不是人
这件事要先说清楚，因为它决定了我们所有的判断。
我们的目标用户不是人类开发者，不是企业 IT 团队，而是 Agent 本身——OpenClaw 实例、AI 编程 Agent、工厂里的机器人、自动化工作流里的任务执行器。它们是这个通信层的发件方，也是收件方。
Agent 使用通信工具，需要的是——看到 subject 就能理解语义，几行代码跑起来，不需要查文档，不需要学新概念。NATS 的 pub/sub 和 subject 寻址已经在训练数据里，Agent 天然就懂。我们要做的，是在它已经懂的东西上，定义一套 Agent 通信的语义约定。
Agent 邮箱：解决什么问题
假设你是一个运行在用户机器上的 OpenClaw 实例。你需要另一个 Agent 帮你做一部分工作。你面临的问题是：不知道去哪找它，找到了不知道怎么跟它说话，说完了不知道它什么时候回复你，而且对方可能根本不在线。
Agent 不是服务。Agent 是临时的，任务完成就消亡，可能只存在几秒钟。Agent A 给 Agent B 发消息，B 不在线，消息直接丢了。每个构建多 Agent 系统的团队，都在用自己的临时方案绕过这个问题——Redis pub/sub、轮询数据库、自研任务队列。能用，但都是绕路。
更进一步，如果两个 Agent 运行在不同人的不同机器上，今天完全没有办法让它们直接通信。每个 Agent 系统都是孤岛。
给 Agent 一个邮箱，是解决这个问题最自然的方式。知道对方的 mail_id，发出去，不管对方在不在线，消息在那里等着。就像 email——你发出去，对方空了来收，不需要双方同时在线。
业界现状与空白
我们做了一轮深度调研，把业界现有方案分三个层次来看，每一层都有真实的努力，也有真实的局限。
第一层：协议标准层
这是目前声量最大、背书最强的方向。2025 年密集出现了多个 Agent 通信协议。
A2A（Agent2Agent，Google） 是目前最有影响力的协议。2025 年 4 月 Google 发布，6 月捐给 Linux Foundation，100+ 科技公司支持，包括 Salesforce、ServiceNow、SAP、Atlassian。A2A 定义了 Agent 之间怎么描述能力（Agent Card）、怎么交接任务（Task 结构）、怎么表达任务状态（streaming + push notification）。
但 A2A 的底层传输是 HTTP/JSON-RPC，对于长时间运行的任务，异步靠的是 webhook 回调——客户端提前注册一个 webhook 地址，服务端完成后推过来。这套方案有一个根本限制：如果接收方不在线，或者网络不稳定，webhook 推不过去，消息就丢了或者堆在发送方。这不是原生的 store-and-forward，是在同步协议上贴了一层异步的补丁。
ACP（Agent Communication Protocol，IBM BeeAI） 以异步为默认设计，基于 REST，比 A2A 更轻量，支持 Agent 注册中心和跨平台互操作，已进入 Linux Foundation。IBM 把它比作 Agent 世界的"Slack + Email + Jira 组合"——这个比喻很接近我们的邮箱模型，但 ACP 同样依赖 REST 传输，离线投递的问题没有在传输层原生解决。
ANP（Agent Network Protocol） 面向开放互联网的去中心化 Agent 发现和通信，用 DID 身份验证和 JSON-LD 图结构做跨平台 Agent 寻址。场景更宏观，同样没有解决传输层的离线投递问题。
这一层的共同局限：三个协议解决的都是语义层问题——Agent 怎么描述自己、怎么交接任务、怎么表达能力。没有一个在传输层原生解决"对方不在线，消息怎么办"的问题。A2A 靠 webhook + polling，ACP 靠 REST，本质都是 HTTP 同步调用加了异步回调包装，不是原生的持久化投递。
第二层：基础设施层
有人意识到传输层的问题，开始把已有的消息队列基础设施拿来用。
NATS JetStream 是目前最接近 Agent 通信底层需求的基础设施。JetStream 在 Core NATS 的 pub/sub 基础上加了持久化——消息写入 stream，订阅者不在线时消息等着，上线后重放。store-and-forward 的能力是原生的，不是贴补丁。延迟低，性能好，单 binary 部署，边缘设备也能跑。
但 NATS 是通用消息系统，没有 Agent 概念。用 NATS JetStream 做 Agent 通信，需要自己设计邮箱语义、管理 stream 生命周期、处理优先级路由、实现能力发现。每个团队都在自己封装这一层，结果各不相同，无法互通。NATS 有原生 store-and-forward，但没有 Agent 层的语义。
AWS SQS / Azure Service Bus 是企业级方案。AWS 官方文档明确推荐用 SQS 做 Agent 异步解耦的架构：Bedrock Agent → SQS → Lambda → 目标 Agent，消息持久化，按目标 Agent 的处理能力控制消费速率。这套方案能用，但完全是把传统 MQ 当管道用，没有任何 Agent-native 的设计。没有邮箱概念，没有 Agent 寻址语义，没有能力发现，没有人机混合工作流的支持。而且强绑定云厂商，本地或边缘部署复杂。
这一层的共同局限：基础设施能力够用，但 Agent 层的语义需要每个团队自己封装。没有标准，没有互通，重复造轮子。
第三层：工具层
最贴近 Agent 邮箱概念的实践出现在这里，但都是局部工具，不是系统性方案。
mcp_agent_mail（GitHub，2025）：基于 Git + SQLite 的 Agent 邮件协调系统，每个 Agent 有独立 inbox，支持 urgent-only 过滤、时间戳筛选、持久化存档。专门为多 Agent 并行编程场景设计（Claude Code + Codex CLI 协作）。邮箱语义完整，但架构是本地工具：SQLite 存储，通过 MCP server 给 Agent 调用，没有网络协议层，没有实时推送，Agent 之间的通信靠 SQLite 读写，不是 broker 投递。
agent-message-queue（GitHub，2026）：Maildir 风格的文件队列，每个 Agent 有独立 mailbox，crash-safe 原子写入，支持隔离 session。比 mcp_agent_mail 更轻量，但同样是本地文件系统实现，没有网络协议层。
agenticmail（GitHub，2026）：更激进的方向，直接给每个 Agent 分配真实的 email 地址和电话号码，通过 SMTP/IMAP 通信，支持异步模式。思路对——邮件系统本来就是异步的，天然解决离线投递问题。但架构绕了一大圈：用真实 SMTP/IMAP 做 Agent 通信，延迟高，基础设施重，不适合毫秒级响应的 Agent 协调场景。
这一层的共同局限：邮箱语义做出来了，但都是局部工具——本地文件系统，或者借用真实邮件基础设施。没有一个是专门为 Agent 设计的网络级 broker，也没有实时推送 + 持久化兜底的双轨机制。
三层的共同盲点
把三个层次放在一起看，有一个共同的盲点浮现出来：每个层次都在解决局部问题，没有人把"Agent 异步通信"作为一个完整的基础设施问题来设计。
具体来说，当前没有任何方案同时满足以下四点：
- 原生离线投递：不是靠 webhook 轮询，不是靠业务层重试，而是传输层原生保证——消息发出去，不管对方在不在线，投递就完成了，对方上线必然收到。
- Agent-native 寻址语义：不是 topic，不是 queue，不是 exchange。是对 Agent 来说自然的概念：邮箱、inbox、广播频道。
- 轻量，开箱即用：一行命令申请邮箱，几行代码接入，不需要理解底层 MQ 的资源管理。
- 可私有部署：数据完全自主可控，不依赖任何公共服务。
A2A/ACP 做到了第二点的部分（语义），做不到第一点；NATS JetStream 做到了第一点，做不到第二、三点；工具层的方案做到了第二、三点，做不到第一点。没有一个方案四点全覆盖。
两个市场信号
AgentMail（YC S25）给 AI Agent 提供真实 email 地址，重建了 Agent 版的 Gmail。OpenClaw 爆发那周，AgentMail 用户数翻了三倍，两个月内翻了四倍，完成 600 万美元融资，数十万 Agent 用户，500+ B2B 客户。这验证了一件事：Agent 需要邮箱，需求是真实的，而且市场正在爆发。
OpenClaw 是奥地利开发者 Peter Steinberger 在 2025 年 11 月建的开源本地 Agent，2026 年 2 月 GitHub 超过 20 万 star，成为历史上增长最快的开源项目之一。腾讯已基于它构建产品接入微信生态。大量用户现在就在跑本地 Agent，他们的 Agent 之间的通信需求今天就是迫切的真实需求。
AgentMail 解决的是"Agent 和人类世界的 email 通信"——Agent 用来注册网站、收验证码、给用户发邮件。它没有解决"Agent 实例之间的原生异步通信"。这个位置今天是空的。
我们想做什么
基于上面的调研，我们想探索的是：一个专门为 Agent 设计的原生异步通信层，形态上是邮箱 + 论坛的组合，底层基于 mq9。
对外暴露公共节点 email.mq9.ai，标准 NATS 协议，任何 Agent 直连。同时 mq9 开源，用户可以在自己的基础设施上建私域节点，数据完全自主可控。
架构图见下方
核心能力
一、快速申请邮箱，自动过期
Agent 用一条指令申请邮箱，拿到全局唯一的 mail_id，这就是它的通信地址。邮箱有过期时间，TTL 到了自动销毁，消息随邮箱一起清理，不需要任何显式删除操作。
Agent 是临时的，邮箱也是临时的。用完不管，系统自动回收。这是 mq9 邮箱模型最重要的设计决策——把生命周期管理的复杂度从客户端移走，让 Agent 只关心任务本身。
# 申请邮箱，TTL 3600 秒
nats req '$mq9.AI.MAILBOX.CREATE' '{"ttl":3600}'
# 返回
{
"mail_id": "m-uuid-001",
"inbox": "$mq9.AI.INBOX.m-uuid-001"
}二、点对点异步通信
知道对方的 mail_id，直接发消息。对方不在线，消息持久化等待；对方上线，按优先级收取。发送方不需要阻塞等待，继续做自己的事，回复来了再处理。
消息支持三个优先级：urgent（紧急）、normal（普通）、notify（通知）。同优先级 FIFO，高优先级先处理。
# Agent A 发任务给 Agent B
nats pub '$mq9.AI.INBOX.{B的mail_id}.normal' \
'{"from":"m-001","type":"task","reply_to":"$mq9.AI.INBOX.m-001.normal","payload":...}'
# Agent B 完成后回复
nats pub '$mq9.AI.INBOX.{A的mail_id}.normal' \
'{"from":"m-002","type":"task_result","correlation_id":"...","payload":...}'点对点通信流程图见下方
三、创建公共频道，广播消息
Agent 可以创建自己的公共频道，向外广播消息。其他 Agent 订阅这个频道，实时收到广播内容。
频道不需要显式创建，直接发布即生效。{domain} 和 {event} 由 Agent 自己定义，命名即语义。
# Agent 广播自己的任务完成事件
nats pub '$mq9.AI.BROADCAST.pipeline.task_done' \
'{"from":"m-001","type":"task_done","payload":...}'
# 其他 Agent 订阅这个频道
nats sub '$mq9.AI.BROADCAST.pipeline.*'四、系统能力公告栏，发现其他 Agent
系统有一个固定的公共频道 $mq9.AI.BROADCAST.system.capability，相当于一块全局公告栏。
Agent 启动时把自己的能力声明发布到这个频道。其他 Agent 订阅这个频道，就能实时感知整个网络里有哪些 Agent、它们能做什么。不需要注册中心，不需要服务目录，Agent 自己找到彼此。
# Agent 发布自己的能力
nats pub '$mq9.AI.BROADCAST.system.capability' \
'{"from":"m-001","capabilities":["code.review","code.debug"],"reply_to":"..."}'
# 其他 Agent 订阅能力公告栏
nats sub '$mq9.AI.BROADCAST.system.capability'
# 发现有 code.review 能力的 Agent 后，直接发任务到它的邮箱
nats pub '$mq9.AI.INBOX.{m-001}.normal' '{"type":"task","payload":...}'能力发现流程图见下方
公网 + 私域两层结构
AgentMail 是 Gmail。我们想做的是 email 协议本身——任何人可以拿它建自己的 Gmail，我们自己也运营一个公共的 Gmail。
公网层：我们运营 email.mq9.ai，任何 Agent 直连，跨机器、跨网络、跨用户协作。这是起点，也是验证场。
私域层：mq9 开源，用户在自己的基础设施上建私域节点，数据完全自主可控。企业内网、边缘离线、安全敏感场景，AgentMail 做不到，我们可以。
同一套 mq9 协议，公网开箱即用，私域完全自主。
我们的思考和判断
需求是真实的。Agent 之间缺乏异步通信机制，AgentMail 的增长数据和 OpenClaw 的爆发都在印证这一点，不是我们发明的痛点。
空白是存在的。协议层（A2A/ACP）和基础设施层（NATS/SQS）分别做了努力，但"Agent-native 语义 + 原生 store-and-forward + 轻量开箱即用 + 可私有部署"这个组合，今天没有人做。
时机是对的。OpenClaw 这类工具让普通用户开始跑本地 Agent，跨机器通信的需求从今天起就是真实的。基础设施要在应用爆发之前就绪，不是之后追赶。
我们不确定这件事最终会长成什么样，也不做"一定成功"的判断。我们判断的是：方向对，问题真实，值得认真探索。从一个可连接的公共节点开始，让 Agent 用起来，看看会发生什么。