Agent 异步通信解决方案深度调研
一、问题从哪里来
多 Agent 系统正在成为 AI 应用的标准架构。一个用户请求背后，可能有 Orchestrator、若干 Worker Agent、数据检索 Agent、工具调用 Agent 并行协作。这不是未来，这是今天 Claude Code、AutoGen、CrewAI、LangGraph 用户每天在构建的东西。
这些系统里，Agent 之间需要通信。任务分发、结果回传、状态同步、异常告警——全部是通信问题。
但 Agent 有一个跟服务完全不同的特性：Agent 是临时的，上下线不可预测。 一个 Worker Agent 完成任务就消亡，边缘设备的 Agent 随网络状态起伏，人工审批节点的"人类 Agent"可能几小时后才上线。
这个特性，让所有基于"对方在线"假设的通信方案，在多 Agent 场景下都变成了有漏洞的方案。
问题是真实的。现在看看业界在怎么解决。
二、业界现状：三个层次的努力
第一层：协议标准层
这是目前声量最大的方向。Google、IBM、Linux Foundation 在 2025 年密集布局。
A2A（Agent2Agent，Google）
2025 年 4 月 Google 发布，同年 6 月进入 Linux Foundation，100+ 科技公司支持。定位是 Agent 之间的通信标准，解决不同框架、不同厂商的 Agent 互操作问题。
技术上，A2A 基于 HTTP/JSON-RPC 2.0，支持 SSE 流式推送和 webhook 回调。对于长时间运行的任务，A2A 的方案是：客户端断连后，任务继续执行，恢复连接后通过 webhook 推送结果。
这套方案解决了语义层问题——Agent 之间怎么描述能力、怎么交接任务、怎么表达任务状态。但传输层的本质没有变：还是 HTTP 短连接，异步靠的是 webhook 注册 + 服务端轮询推送。如果接收方不在线，webhook 推不过去，消息就丢了或堆在发送方。这不是 store-and-forward，是 best-effort delivery。
ACP（Agent Communication Protocol，IBM BeeAI）
IBM 的定位是"Agent 之间的 Slack + Email + Jira"。基于 REST，以异步为默认，同步为可选，支持 Agent 注册中心和跨平台互操作。已进入 Linux Foundation。
ACP 的 REST-first 设计让接入更简单，但也继承了 REST 的根本限制：调用方发出请求时，如果对方不在线，请求失败。ACP 在协议层定义了异步消息的语义，但没有在传输层解决离线投递的问题——这还是靠上层业务自己处理。
ANP（Agent Network Protocol）
面向开放互联网的 Agent 发现和通信，用 DID 身份验证和 JSON-LD 图结构做去中心化 Agent 寻址。场景更宏观，聚焦跨组织跨平台的 Agent 互联。传输层同样没有离线投递的原生支持。
这一层的共同局限： 三个协议解决的都是语义层问题——Agent 怎么描述自己、怎么交接任务、怎么表达能力。没有一个在传输层原生解决"对方不在线，消息怎么办"的问题。
第二层：基础设施层
有人意识到传输层的问题，开始把已有的 MQ 基础设施拿来用。
NATS JetStream
目前最接近 Agent 异步通信需求的底层基础设施。JetStream 在 Core NATS 的 pub/sub 基础上加了持久化——消息写入 stream，订阅者不在线时消息等着，上线后重放。store-and-forward 的能力是原生的，不是贴补丁。
但 NATS 是通用消息系统，没有 Agent 概念。用 NATS JetStream 做 Agent 通信，需要自己设计邮箱语义、管理 stream 生命周期、处理优先级路由、实现能力发现。每个团队都在自己封装这一层，结果各不相同，无法互通。
AWS SQS / Azure Service Bus
企业级方案，Bedrock 文档里明确推荐用 SQS 做 Agent 异步解耦的架构：Bedrock Agent → SQS → Lambda → 目标 Agent。消息持久化，按目标 Agent 的处理能力控制消费速率。
这套方案能用，但完全是把传统 MQ 当管道用，没有任何 Agent-native 的设计。没有邮箱概念，没有 Agent 寻址语义，没有能力发现，没有人机混合工作流的支持。而且强绑定云厂商，本地或边缘部署复杂。
Kafka
有团队尝试用 Kafka 做 Agent 异步通信。Kafka 的持久化能力强，但从设计假设上就跟 Agent 场景不匹配：topic 需要管理员预先创建，partition 需要规划，consumer group 语义面向批量数据消费而非点对点邮箱。Agent 是日抛型的，Kafka 假设资源长期存在精心维护。两者的设计哲学根本相反。
这一层的共同局限： 基础设施能力够用，但 Agent 层的语义需要每个团队自己封装。没有标准，没有互通，重复造轮子。
第三层：工具层
这一层是离"Agent 邮箱"概念最近的实践，但都是局部工具，不是系统性方案。
mcp_agent_mail（GitHub，2025）
基于 Git + SQLite 的 Agent 邮件协调系统。每个 Agent 有独立 inbox，支持 urgent-only 过滤、时间戳筛选、持久化存档、文件锁冲突避免。专门为多 Agent 并行编程场景设计（Claude Code + Codex CLI 协作）。
邮箱语义完整，但架构是本地工具：SQLite 存储，Git 做版本控制，通过 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 地址和电话号码。Agent 之间通过 SMTP/IMAP 通信，支持异步模式（call_agent 完成后 email 结果回来）。62 个 MCP tools，覆盖邮件收发、SMS、任务协调。
思路对——邮件系统本来就是异步的，天然解决离线投递问题。但架构绕了一大圈：用真实 SMTP/IMAP 做 Agent 通信，延迟高，基础设施重，不适合毫秒级响应的 Agent 协调场景。
这一层的共同局限： 邮箱语义做出来了，但都是局部工具——本地文件系统，或者借用真实邮件基础设施。没有一个是专门为 Agent 设计的网络级 broker，也没有实时推送 + 持久化兜底的双轨机制。
三、现有方案的根本缺陷
把三个层次放在一起看，有一个共同的盲点浮现出来：
所有方案都在解决局部问题，没有人把"Agent 异步通信"作为一个完整的基础设施问题来设计。
具体来说，当前没有任何方案同时满足以下四点：
1. 原生离线投递（store-and-forward） 不是靠 webhook 轮询，不是靠业务层重试，而是传输层原生保证：消息发出去，不管对方在不在线，投递就完成了，对方上线必然收到。
2. Agent-native 寻址语义 不是 topic，不是 queue，不是 exchange。是对 Agent 来说自然的概念：邮箱、inbox、广播频道。开发者写 Agent 时不需要思考底层 MQ 的资源管理。
3. 轻量，开箱即用 不需要预先创建 topic，不需要规划 partition，不需要运维经验。Agent 需要通信时，一行申请邮箱，拿到地址，发消息。
4. 实时推送 + 持久化双轨 在线时实时推送，不在线时持久化等待。两种状态对发送方透明，发出去就不用管了。
现在的状态：A2A/ACP 做到了第 2 点的部分（语义），做不到第 1 点；NATS JetStream 做到了第 1 点，做不到第 2、3 点；工具层的方案做到了第 2、3 点，做不到第 1 点。
没有一个方案四点全覆盖。
四、这是真实需求还是伪需求
一个关键问题：Agent 异步通信的需求，是真实存在的，还是被过度夸大的？
从使用规模看： Gartner 预测 2026 年 40% 企业应用将集成 AI Agent，McKinsey 的报告显示多 Agent 系统的 ROI 是单 Agent 的 3 倍。Google 发布 A2A 时有 50+ 企业合作伙伴，包括 Salesforce、ServiceNow、SAP。这些公司在生产环境跑多 Agent 系统，Agent 通信是他们的真实问题。
从工程实践看： GitHub 上出现了多个独立的 Agent mailbox 实现（mcp_agent_mail、agent-message-queue、agenticmail），都是开发者为解决自己遇到的真实问题而构建的。这些项目出现在 2025-2026 年，正好是多 Agent 系统从实验走向生产的时间窗口。有人造轮子，说明有真实痛点。
从架构演进看： AWS、Google、Microsoft 都在 2025 年发布了"如何用消息队列做 Agent 异步通信"的官方文档和架构指南。云厂商不会为伪需求写文档。
需求的真实性没有疑问。 但有一个需要正视的问题：现有工具"够用但不好用"，这种状态不一定驱动开发者主动寻找新方案——除非新方案的好用程度有量级差异，或者现有拼凑方案的维护成本高到了临界点。
Agent 系统的规模增长会加速这个临界点的到来。当一个系统里跑几十个 Agent，自制的 Redis 邮箱开始出 bug；当边缘设备 Agent 开始离线，polling 方案开始漏消息——对专用方案的需求会真实爆发。
五、结论
这是真实需求，不是伪需求。
从三个维度可以验证：
其一，使用规模。Gartner 预测 2026 年 40% 企业应用将集成 AI Agent，Google 发布 A2A 时有 50+ 企业合作伙伴背书，AWS/Google/Microsoft 都在 2025 年发布了专门针对 Agent 异步通信的官方架构指南。云厂商不为伪需求写文档，大公司不为伪需求背书。
其二，工程实践。GitHub 上出现了多个独立的 Agent mailbox 实现（mcp_agent_mail、agent-message-queue、agenticmail），都诞生于 2025-2026 年，开发者为解决自己的真实问题独立造轮子。独立造轮子是痛点真实存在最直接的证据。
其三，方案局限。当前没有任何方案同时满足：原生离线投递（store-and-forward）、Agent-native 寻址语义、轻量开箱即用、实时推送与持久化双轨。A2A/ACP 在语义层有建树，传输层靠 webhook 拼凑；NATS JetStream 传输层能力足够，Agent 语义需要每个团队自己封装；工具层方案有邮箱语义，但没有网络级 broker。三个层次各解决了一部分，中间那层是真实的工程空白。
需要正视的一个问题："够用但不好用"不一定驱动开发者主动换方案。当前大多数团队用 Redis/SQS/NATS 拼凑，短期内能撑住。随着 Agent 系统规模增长，拼凑方案的维护成本会上升到临界点——那个时候对专用方案的需求才会真实爆发。这个窗口在打开，但还没有完全打开。
另一个需要持续关注的动向是 A2A 的传输层演进。目前 A2A 靠 webhook + polling 做异步，这是它明显的弱点。如果 A2A 社区在协议层补入原生的 store-and-forward 能力，这个空白会被填掉。目前没有迹象表明这在发生，但 12-24 个月内值得观察。
总结： 问题存在，空白真实，需求不是伪造的。这是一个目前被大家用临时方案绕过去、尚未被正面系统性解决的工程问题。