mq9 怎么和 A2A 配合，我想了几轮

最近一直在琢磨 mq9 和 A2A 之间应该是什么关系。

mq9 自己的协议设计已经做了一段时间。mailbox 抽象、持久化、TTL、按 key 压缩、订阅时全量推送、轻量注册中心，这些能力在 mq9 内部跑得通。但 mq9 不可能脱离生态独立活，要落地必须找到具体的应用场景。

A2A 是当前 Agent 通信领域最活跃的协议，Linux Foundation 标准，IBM ACP 已经合并进来，目前有 100 多个采纳者。如果 mq9 能在 A2A 的生态里找到位置，就能避免另起炉灶造一个新协议。

那 mq9 和 A2A 的关系应该是什么？这件事翻来覆去想过几轮。这篇文章把过程梳理一下。

先说 A2A

A2A 协议本身不复杂，读完 spec 一两天就能掌握。Agent Card 描述能力，Task 状态机管理任务，Message 和 Artifact 承载内容，JSON-RPC over HTTP 做传输。一个工程师写 A2A server，用 Python 几百行代码就够。

但实际把 A2A 在企业里跑通，会发现 spec 留下了几个空白。这些不是 A2A 的设计失误，是 A2A 主动留给生态的——它定义了协议层（Agent 之间说什么），把传输和发现层（消息怎么到达）留给底层基础设施。

第一个空白是发现机制不完整。A2A spec 规定 Agent 在 /.well-known/agent.json 暴露 Agent Card，但这只解决了"知道域名后怎么读 Agent Card"，没解决"怎么知道域名"。Spec 自己写了一句"The mechanism for this registration is outside the scope of the A2A protocol itself."，明确把注册中心留给生态做实验。GitHub Discussion #741 讨论了几个月也没收敛。当前实践要么写死 URL，要么内部 wiki 维护列表，要么用 MCP 当 agent registry（明显是 hack），要么自己用 KV 存映射。每种都不完整。

第二个是异步通信不可靠。A2A 当前的异步机制是三种：SSE 流、webhook、polling。SSE 适合 client 在线等待结果，网络抖动断了就完了。Webhook 是 fire-and-forget，client 必须有公网可达端点，失败处理 spec 没规定。Polling 最简单但最浪费。三种都不是"专门为异步设计的基础设施"。

第三个是长任务的状态恢复。Task 可能跑几小时甚至几天，client 离线再上线后怎么拿到错过的状态更新？A2A 给了 tasks/resubscribe 让 server 重放历史。但这要求 server 端记录完整 Task 状态历史，每次 resubscribe 都从历史回放，是不小的实现负担。

第四个是 N-to-N 协作。A2A 是 client-server 非对称模型，但真实多 Agent 协作经常是 N-to-N 的——主 Agent 协调多个子 Agent，子 Agent 之间也可能互相通信。这种拓扑下，每个 Agent 都要知道其他 Agent 的 URL、维护连接池、处理重试，复杂度上去后没人愿意写这种代码。

第五个是每个框架都要自己实现一遍。Agent 框架想完整支持 A2A，得写客户端、服务端、Agent Card 生成、SSE 流处理、Task 状态机、INPUT_REQUIRED 多轮交互、注册表、能力匹配、认证、TLS、可观测性。NousResearch 的 Hermes 团队在 issue #514 里把要做的事列了一遍，光看清单就能感觉到分量。一个团队做这件事都很慢，LangChain、AutoGen、CrewAI 每家都做一遍，重复劳动巨大。

把这五个空白放在一起看，会发现它们的共同点——都不是协议本身的问题，是基础设施缺位。A2A 协议本身设计合理，它把传输和发现留给了底层，但底层基础设施还没成熟，导致每个用户都要自己造一遍。

类比一下，HTTP 协议本身简单，但 HTTP 在生产环境跑起来要靠 DNS、CDN、负载均衡、HTTPS 证书、连接池、重试库这一整套。这些不是 HTTP 协议的内容，但缺了它们 HTTP 没法用。A2A 现在缺的就是这一层——协议落地需要的传输和发现基础设施。

想到这里我才回过头看 mq9

mq9 之前为通用 Agent 通信做的设计，放到"A2A 落地的传输和发现层"这个具体场景下看，每个能力刚好都对应一个空白。

A2A 缺发现机制，mq9 内置了 Agent 注册中心，支持 tag 检索和语义检索。A2A 缺可靠的异步通信，mq9 是 mailbox 持久化加可靠投递。A2A 缺长任务状态恢复，mq9 有订阅时全量推送加按 key 压缩。A2A 缺 N-to-N 协作的简单方式，mq9 用 mailbox 灵活组合天然支持任意拓扑。A2A 让每个框架重复实现，mq9 通过 SDK 让框架共享同一份实现。

不是 mq9 为了配合 A2A 做了什么特殊设计，是 mq9 之前为通用 Agent 通信做的能力，放到 A2A 落地这个具体场景上，每条都能用。两条独立的设计路径，结果撞在了同一个点。

这件事让我重新理解 mq9 该怎么定位自己。之前 mq9 的设计是从"Agent 通信需要什么"反推过来的，但放到当前生态里看，mq9 的能力是"刚好能做 A2A 落地的传输和发现基础设施"。这不是巧合——A2A 把传输和发现留给底层，底层需要的能力跟"通用 Agent 通信"需要的能力高度重合。

那 mq9 是不是该专门做 A2A 的传输和发现层？想了几轮，我的结论是可以，但要想清楚边界。

不冲突的几个原则

如果 mq9 真的做 A2A 的传输和发现层，要避免几个陷阱。

不要去重做 A2A 协议层的事。Task、Message、Artifact、状态机这些是 A2A 的内容，mq9 协议层不解析这些。mq9 mailbox 传的是字节流，A2A 包是什么格式 mq9 不关心，原样传输。这样 A2A 协议演进时 mq9 不用改。

不要去抢 A2A 工作组的标准位。A2A 工作组在讨论注册中心标准、PKI 信任模型、跨企业发现这些问题，这些是协议层的事，mq9 不去做正式标准。

不要去绑定 A2A。mq9 的设计应该让"A2A 是当前主要承载的协议，但不是唯一"。如果 MCP 未来扩展到 Agent-Agent 通信、出现新的 Agent 协议、企业有自定义协议，mq9 也能承载。这一点对长期重要——Agent 协议这个领域还在演进，押注单一协议的项目脆弱。

要利用 A2A spec 留下的扩展空间。A2A 的 pushNotification.url 字段接受任何 URL，符合 RFC 3986 即可。mq9 用 mq9:// URL scheme，A2A SDK 拿到 URL 后做协议分发——https:// 走 webhook，mq9:// 走 mailbox。A2A spec 一行不用改，A2A 工作组什么都不用做。

这是"利用 spec 留下的扩展空间"和"改动 spec"的区别。前者不冲突，后者才会冲突。

拿 Hermes 当例子看一下

抽象的关系想清楚了，看一个具体场景能更直观。

Hermes 是 NousResearch 的 AI Agent 框架，他们 issue #514 是 A2A 集成提案，分三个 phase——客户端、服务端、多 agent 编排。提案 2026 年 3 月开的，到现在还是 open 状态。每个 phase 都有详细的实施清单。

如果 Hermes 接 mq9 而不是自己实现 A2A 集成，会变成什么样？

第一个 phase 是把 Hermes 做成 A2A client，能调用远程 Agent。Hermes 自己实现的方案是写两个工具 a2a_discover 和 a2a_call，集成 a2a-sdk，处理 HTTP 客户端、Agent Card 缓存、SSE 流。

接 mq9 之后，发现 Agent 直接 mq9.discover(query="能写 Python 代码的 Agent")，给 Agent 发消息直接 mq9.send(target.mailbox, message)，订阅自己的回调 mailbox 收响应。框架不需要 a2a-sdk，不需要 HTTP 客户端，不需要 SSE 流处理，不需要 Agent Card 缓存。

第二个 phase 是把 Hermes 暴露为 A2A server。Hermes 自己实现的方案是做一个 AgentExecutor 包装 Hermes AIAgent，自动从 toolsets 生成 Agent Card，起 HTTP server，处理 well-known URL 和 A2A 端点。

接 mq9 之后，启动时调一次 mq9.register() 把自己的 AgentCard 注册上去，后台订阅自己的 mailbox 接收任务。框架不需要起 HTTP server，不需要管端口，不需要暴露 well-known URL。

第三个 phase 是多 Agent 编排。Hermes 自己实现的方案是维护 agent 注册表，基于 task description 自动选择 agent，做 fan-out 工作流。接 mq9 之后，注册表已经在 mq9 broker 里，语义检索是 mq9 注册中心的能力，多 Agent 编排在应用层用 mailbox 灵活组合。

这个对照让我意识到，mq9 和 A2A 结合不是"再做一个轮子"，是把每个 Agent 框架都要重复做的轮子集中做一次。框架接 mq9 之后，自己只用关心 Agent 的业务逻辑，A2A 协议落地的传输和发现工作 mq9 包了。

不只是 Hermes

把 Hermes 的例子推广，每个主流 Agent 框架都能做类似的适配——LangChain、AutoGen、CrewAI、OpenClaw 都是。每个适配器的核心是把 mq9 的 mailbox 操作封装成框架原生 API。不同框架形态不一样（Hermes 是 drop-in 目录，LangChain 是 pip 包，AutoGen 是配置项），但底层接口一致——register、discover、send、subscribe 几个核心操作。这意味着 mq9 SDK 是 thin core，每个框架适配器是 thin wrapper。

值得提一下 Hermes 和 OpenClaw 是兼容的，Hermes 可以从 OpenClaw 迁移。所以 mq9 Hermes plugin 做好后，OpenClaw 适配几乎是同一份代码。一份代码覆盖两个框架。

几个还没想清楚的问题

把上面思路捋清楚之后，还有几个问题不确定。

A2A SDK 当前还是 pre-1.0（v0.3.24），spec 可能 break，这对 mq9 的影响怎么算。我的判断是影响小，因为 mq9 协议层不解析 A2A 消息，mq9 mailbox 传的是字节流，A2A 包是什么格式 mq9 不关心。A2A spec 改了，mq9 不用改。框架的 A2A 集成代码可能要改，但 mq9 transport 这一层不动。

A2A 工作组未来可能定一个注册中心标准，那 mq9 注册中心怎么办。可能性有几种：mq9 注册中心兼容 A2A 标准、和 A2A 标准互通、或者继续做企业内部场景而 A2A 标准做跨企业场景。具体走哪条路要看 A2A 工作组最终定的是什么。当前能做的是把 mq9 注册中心的接口设计得灵活——AgentCard 原样存取（不绑定具体格式），API 简单（容易扩展），不预设 A2A 工作组会怎么标准化，但要让 mq9 有适应能力。

A2A 支持 SSE 流式响应，Hermes 也支持 token-by-token streaming，这两个流怎么经过 mq9 mailbox。可能的方案是每个 token 一条消息，按 task_id 用 key 压缩保留最新累积内容，或者保留全部消息让 client 拼接。前者节省存储但语义有损，后者完整但消息量大，需要实测看效果。

A2A 的 INPUT_REQUIRED 状态要 server agent 暂停、等 client 提供输入、继续执行，在 mailbox 模型上怎么实现。一个思路是用两个 mailbox，server 推送状态用一个，client 提供输入用另一个，task_id 关联。Server 暂停时订阅 input mailbox 等待，收到输入后恢复执行。这个思路可行但需要 SDK 层封装好，不让上层应用感知到 mailbox 切换。

Hermes 这种 agent 框架已经有 messaging gateway，让人通过 Telegram、Slack 和 agent 对话。mq9 Hermes plugin 让 agent 和 agent 通信。这两个独立还是有交集？一个值得想的场景：人通过 Telegram 给 agent A 发消息，agent A 通过 mq9 找 agent B 协作，agent B 的回复经 mq9 回给 agent A，agent A 再通过 Telegram 回给人。这条链路 plugin 怎么支持？可能需要在 mq9 消息里携带原始 messaging gateway 的上下文（来自哪个平台、哪个用户）。具体怎么做还要想。

当前的判断

把上面这些梳理完，对 mq9 和 A2A 结合这件事的判断是这样。

A2A 协议层成熟但落地不完整。协议本身简单，但 spec 留了几个空白——发现、异步、状态恢复、N-to-N、每个框架重复实现。mq9 已有的能力对得上这些空白，不是 mq9 为了配合 A2A 做了什么特殊设计，是 mq9 之前为通用 Agent 通信做的能力放到 A2A 落地这个具体场景上每条都能用。

mq9 和 A2A 是层次关系，不是竞争关系。A2A 做协议内容，mq9 做传输和发现的基础设施。两者结合时 A2A 协议一行不用改。

这条路径还需要验证。思路在脑子里能走通，但实际能不能成立要看几件事——mq9 SDK 易用性如何、第一批接入的框架反馈如何、A2A 工作组的演进方向如何。当前能做的是先把 mq9 broker 和 SDK 做扎实，做一个 Hermes plugin 当 PoC 跑通端到端流程，然后看实际使用反馈。

这篇文章是思考过程，不是结论。mq9 和 A2A 结合的具体形态可能还会变——A2A spec 的演进、注册中心标准化的方向、不同 Agent 框架的接入反馈，都会影响下一步怎么走。短期能做的是把基础打实，broker 稳定、SDK 多语言覆盖、第一个框架适配跑通。这些做扎实了，后面 A2A 怎么演进，mq9 都有适应空间。

剩下的边做边看。