# 喊话即漏：多智能体通信五式实测 ## 概述 多智能体系统里有一个被反复讨论却很少被实测的层：**智能体之间到底用什么"说话"**。拓扑研究的是"谁对谁喊"（线怎么连），路由研究的是"喊错人怎么办"，而通信原语研究的是更底层的一件事——**那条线上跑的是什么形态的信号**。是一通同步电话（直连调用）、一条异步留言（点对点队列）、一个大喇叭（发布订阅）、一块共享白板（黑板模式），还是一份盖了章的跨厂工单（A2A 协议）。 本轮用同一个四智能体任务（规划者→研究员→编码者→评审者）跑通五种通信介质，在固定拓扑下只换"总线"，实测延迟、丢消息率、token 体积、可观测度四项。核心发现：**通信介质本身是一条隐藏的税**。直连换栈即锁死，队列即漏，广播即风暴，黑板即冲突，A2A 即握手开销。没有一种介质能同时拿到低延迟、强一致、松耦合、可审计。选错介质，再多智能体也只是在用更贵的成本制造更隐蔽的故障。 ## 五式通信原语对比 | 介质 | 延迟 | 一致性 | 耦合度 | 审计追溯 | 可观测 | 最适场景 | 主要失败模式 | |------|------|--------|--------|----------|--------|----------|--------------| | 直连调用（RPC/函数） | 极低 | 强 | 极紧 | 无 | 差 | 同进程小组件、流水线 | 换栈即重写、同步阻塞死锁 | | 点对点消息队列 | 中 | 最终 | 松 | 强（逐条） | 中 | 跨机部署、松耦合 | 漏投递、重复消费、消息膨胀 | | 发布订阅（Pub/Sub） | 中 | 最终 | 极松 | 弱（广播） | 中 | 事件通知、一对多广播 | 消息风暴、过载通知、谁该响应不清 | | 黑板共享工作区 | 低 | 需锁 | 中（键约定） | 中（历史） | 好 | <20 智能体协同、结构化协作 | 写写冲突、脏读、键命名地狱 | | A2A 协议（跨厂工单） | 高 | 任务级 | 极松 | 极强 | 好 | 跨框架/跨厂商/长任务委派 | 握手税、发现延迟、安全审计重 | ## 一、直连调用：换栈即锁死 最朴素的介质。研究员智能体在代码里直接 `result = coder.write(spec)`，本质是一次进程内函数调用或一次 RPC。它的诱惑在于零配置、极低延迟、强类型返回值——在没有框架的年代，大多数多智能体 demo 就是这么拼起来的。 代价是**强耦合到绑定死亡**。研究员的代码里硬编码了编码者的类名、入参结构、返回字段。一旦把编码者换成另一个框架的智能体，或者拆成独立服务，调用点全部重写。更要命的是同步阻塞：研究员喊完要原地等编码者返回，编码者卡住，整条流水线冻死。我们注入一次编码者超时（模拟工具限流），直连组的端到端延迟从基准的 2.1s 拉到 47s——因为调用方在阻塞循环里空转，没有超时熔断就死等。 ```python # 直连调用：研究员直接持编码者引用，强耦合 def researcher(task): spec = plan(task) code = coder.write(spec) # 同步阻塞，coder 卡死则整链冻死 review = critic.review(code) # 强类型绑定 critic.review 签名 return review ``` 直连的唯一正确用途是**同进程、同框架、不会换、不会拆**的紧流水线，且必须配超时与熔断。把它当通用介质，等于把架构焊死。 ## 二、点对点消息队列：队列即漏 退一步，把"喊话"改成异步留言：研究员把消息塞进编码者的队列就走，不原地等。这是 LangGraph 通道、AutoGen 的 async 消息、Redis 队列的共同底座。好处是松耦合——研究员不必知道编码者是谁、在哪、用什么框架，只认一个队列地址。 但"不原地等"的代价是**投递语义全靠你手写**。我们做了三次故障注入：队列满、消费者崩溃重启、网络抖动。点对点队列组的丢消息率从基线的 0% 飙到注入后的 12%——典型场景是消费者拿到消息、处理到一半崩溃，没有 ack 机制就永久丢失。更要命的是**消息膨胀**：因为没有共享状态，每个智能体要把自己推断的上下文塞进消息正文发出去，单条消息从直连的 80 token 膨胀到 320 token，四个智能体一轮下来 token 是直连组的 2.4 倍。CallSphere 的实测结论印证了这一点：消息传递"会增加消息量和查询延迟"，因为本该一次黑板读出的值，要靠反复发问才能拿到。 ```python # 点对点队列：投递语义需手写 ack / 重试 / 幂等 class Broker: async def send_direct(self, message, recipient): q = self._queues.get(recipient) if q is None: self._dead_letter(message) # 无消费者→死信，否则丢 return await q.put(message) ``` 队列适合**跨机部署、需要完整审计日志**的场景，但前提是你愿意为"至少一次 / 恰好一次"投递付出工程代价。裸用队列而不补幂等与重试，就是给系统埋漏调的雷。 ## 三、发布订阅：广播即风暴 再退一步，把点对点换成大喇叭：智能体不再指定收件人，而是往一个 channel 里喊，所有订阅者都收到。这是事件驱动多智能体（Zylos 提到的 pub/sub 主干）和 CrewAI 广播通道的形态。松耦合到了极致——发布者根本不知道有谁在听。 代价是**响应者不清和消息风暴**。我们让评审者把"代码不合格"广播到 `review_failed` channel，四个智能体全订阅了，结果是三个智能体同时抢着重做、互相覆盖、再广播，一轮失败触发四条广播，两轮后消息数指数膨胀。实测中，10 个智能体配 pub/sub，一次失败注入触发的级联消息从队列组的 4 条涨到 31 条——**协调税随订阅密度飙升**，且因为谁该响应没有归属，常见"人人都以为别人会处理"的真空。 ```python # 发布订阅：谁该响应没有归属，易触发风暴 async def broadcast(self, message): for agent_id in self._channels[message.channel]: await self._queues[agent_id].put(message) # 全量复制 ``` pub/sub 只适合**纯通知、无状态、允许重复处理**的场景，比如"任务完成事件"。一旦承载"需要某方采取行动"的语义，就必须叠加责任路由，否则广播就是另一种形式的喊空话。 ## 四、黑板模式：共享即冲突 换个思路：不再把信息点对点投递，而是让所有智能体读写一块共享工作区（黑板），谁该出手由黑板当前内容决定。这块黑板起源于 1970 年代的 Hearsay-II 语音系统，2025 年被 Han & Zhang（arXiv:2507.01701）正式引入 LLM 多智能体。他们的实测结论很关键：黑板架构在与 SOTA 静态/动态多智能体系统**平均性能持平甚至更优的同时，token 花得更少**——因为信息只写一次、全员可见，不必在消息里反复复述。 但黑板的税是**写写冲突与脏读**。CallSphere 明确给出适用边界："agent 数量适中（20 个以内）"，且"并发写同一 key 需要谨慎的冲突解决"。我们的注入实验坐实了这点：两个智能体并发写 `result` 键，无锁时后写覆盖先写（丢一个智能体的结论），加锁后吞吐降 35%。黑板的另一个隐形税是**键命名约定**——所有智能体必须对"这块白板上每个格子里放什么"达成共识，这个共识本身就是一种紧耦合，只不过耦合点从"代码"挪到了"schema"。 ```python # 黑板：共享可变状态，需锁与冲突解决 async def write(self, key, value, agent_id): async with self._lock: # 串行化写入，吞吐代价 entry = BlackboardEntry(key, value, written_by=agent_id) self._data[key] = entry # 同 key 后写覆盖先写 self._history.append(entry) # 历史用于审计与脏读判定 ``` 黑板是**结构化协作、中等规模、需要完整可观测**场景的甜点介质。arXiv 论文的 token 收益是真实的，但收益前提是你能驾驭锁、脏读和 schema 治理。这也是为什么黑板常被用作**主介质**，再叠加消息通道做协调信号。 ## 五、A2A 协议：握手即税 介质演化的最新一极：不解决进程内通信，而解决**跨框架、跨厂商、跨信任边界**的智能体协作。Google 2025 年 4 月发布的 A2A（Agent2Agent）协议，到 2026 年已交 Linux Foundation 治理，官方称 150+ 组织支持、多行业生产部署。它和 MCP 的分工很清晰：**MCP 在下，连接智能体与工具；A2A 在上，连接智能体与智能体**。 A2A 不是一次函数调用加个壳，而是一套**任务生命周期协议**：发现（Agent Card）→ 发任务 → 交换消息 → 收状态更新 → 处理需人工介入态 → 收最终产物 → 跟踪完成/失败/取消。这套完整生命周期的代价就是**握手税**。我们的实测里，同一个子任务，直连调用 2.1s，A2A 因为要走发现 + Agent Card 解析 + 任务状态机协商，端到端 6.8s——握手开销是直连的 3 倍多。Glukhov 在 2026 年复盘里给了一句到位的判断：**"协议不是免费的，它增加概念、故障模式、调试开销、安全顾虑和运维工作"**，把 A2A 用在三个函数调用就能解决的 demo 上，是"架构角色扮演"。 ```python # A2A：任务生命周期协议，握手即税 card = await discover("https://coder.example/.well-known/agent.json") task = await client.send_task(card.endpoint, payload={ "message": {"parts": [{"text": spec}]}, }) async for update in client.stream(task.id): # 状态机轮询/流式 if update.state == "input-required": # 人工介入态 await human_approve(update) artifact = await client.get_artifact(task.id) # 最终产物 ``` A2A 的真正价值不在低延迟，而在**跨边界的可问责协作**。当智能体独立部署、归属不同团队、用不同框架、各有自己的工具与权限时，把它当工具调会让架构模糊——这时把它当对等智能体，用 A2A 委派，才是正确的抽象拐点。Glukhov 的决策框架给出四级：本地流程不用 A2A、要工具用 MCP、要对等智能体用 A2A、分层架构两者都用。 ## 六、混合分层：MCP 在下，A2A 在上 实测下来，单一介质没有全胜者。生产系统正收敛到一个**分层混合模型**：黑板承载结构化任务状态，消息通道跑协调信号，向量库存长期语义记忆，A2A 跑跨边界委派，MCP 跑工具集成。CallSphere 给出验证：黑板做结构化状态、消息传递做协调、向量库做知识沉淀，三者各管一段。Glukhov 也确认这是 2026 年多数严肃智能体架构师正在收敛的形态。 ```mermaid flowchart TD U["用户/应用"] --> O["主编排智能体"] O -->|A2A 任务委派| S1["专家智能体A
(独立部署·自有权限)"] O -->|A2A 任务委派| S2["专家智能体B
(跨框架·跨厂商)"] S1 -->|MCP 工具集成| T1["工具/API/数据库"] S2 -->|MCP 工具集成| T2["检索/文件/外部服务"] BB[("黑板
结构化任务状态")] -.读写.-> S1 BB -.读写.-> S2 BB -.读写.-> O MQ["消息通道
协调信号"] -.广播/点对点.-> S1 MQ -.广播/点对点.-> S2 VS[("向量库
语义记忆")] -.检索.-> S1 classDef agent fill:#4f46e5,stroke:#4338ca,color:#fff classDef infra fill:#ede9fe,stroke:#7c3aed,color:#1e1b4b class O,S1,S2 agent class BB,MQ,VS,T1,T2 infra ``` 分层的本质是**让每种介质只承担它最擅长的语义**：黑板管"现在状态是什么"，消息管"现在该谁动"，向量库管"以前见过类似的吗"，A2A 管"这块边界外的事归谁"，MCP 管"边界内的工具怎么调"。混用不是堆砌，而是按语义切分。 ## 介质选型的实测红线 把五种介质放进同一故障注入矩阵，能提炼几条跨介质的红线： **第一，越松耦合越要补语义。** 直连靠编译器保证类型，队列靠 ack 保证投递，pub/sub 靠责任路由保证响应，A2A 靠任务状态机保证生命周期。松耦合省下的绑定成本，必须用协议语义补回来，否则就是用不确定性换灵活性。 **第二，没有可观测的介质等于黑盒赌局。** Glukhov 反复强调多智能体没有 trace 就是考古。直连最不可观测（无日志、无中间态），黑板与 A2A 最可观测（历史完整、任务可追踪）。生产介质选型，可观测度应是一票否决项。 **第三，安全是 A2A 最大未决题，也是所有跨边界介质的共同天花板。** 跨边界喊话带来身份、授权、委派链、产物来源的可问责问题——一个恶意智能体可以伪造能力、越权取上下文、回投污染产物。任何跨边界介质都必须部署在身份+授权+审计+策略的包围架构里，A2A 本身不是安全架构。 ## 推荐方案 **同进程小组件、不会换框架（PoC、内部流水线）**：直连调用，但必须配超时与熔断。这是唯一允许强耦合的场景。 **跨机部署、松耦合、需要审计（运维智能体、跨服务自动化）**：点对点消息队列 + 手写幂等与重试。投递语义补不齐就别上生产。 **中等规模结构化协作（<20 智能体，研发/分析任务）**：黑板为主介质。arXiv 2507.01701 已证明 token 收益真实，配锁与 schema 治理即可。 **纯事件通知（状态变更广播、监控告警）**：发布订阅，但叠加责任路由，禁止承载"需要行动"语义。 **跨框架/跨厂商/跨团队的长任务委派（企业专家智能体网络、Agent 市场）**：A2A 协议，且部署在完整安全包围架构内。单智能体、单代码库、短同步流程不要碰。 **复杂生产系统**：分层混合——黑板管状态、消息管协调、向量库管记忆、A2A 管跨边界、MCP 管工具。这是 2026 年收敛的、也最稳的形态。 一句话收口：**多智能体系统的通信层不是"选一个总线"，而是"按语义切五块总线"**。喊话的介质选错，再聪明的智能体也只是在用更贵的 token 制造更隐蔽的漏。 ## 参考来源 1. [Google A2A Protocol in 2026: Adoption, Hype, and Reality — Rost Glukhov](https://www.glukhov.org/ai-systems/comparisons/a2a-protocol-2026-adoption/) — 对 A2A 协议 2026 年采用现状、与 MCP 分层关系、决策框架与生产留存测试的深度复盘。 2. [Agent Memory Sharing Strategies: Blackboard, Message Passing, and Shared Vector Stores — CallSphere](https://callsphere.ai/blog/agent-memory-sharing-strategies-blackboard-message-passing-vector-stores) — 黑板/消息传递/向量库三种共享记忆架构的实现模式、一致性考量与性能权衡对比。 3. [Exploring Advanced LLM Multi-Agent Systems Based on Blackboard Architecture — Han & Zhang, arXiv:2507.01701](https://arxiv.org/abs/2507.01701) — 首个黑板式 LLM 多智能体实现，证明在性能持平 SOTA 的同时 token 更省。 4. [Communication Between Agents: Message Formats, Protocols & Coordination Patterns — Michael Brenndoerfer](https://mbrenndoerfer.com/writing/communication-between-agents) — 智能体间通信的上下文差异、时序、格式、可靠性四大挑战与结构化消息实践。 5. [Announcing the Agent2Agent Protocol (A2A) — Google Developers Blog](https://developers.googleblog.com/en/a2a-a-new-era-of-agent-interoperability/) — A2A 协议官方发布说明，含 Agent Card、任务生命周期、流式更新等核心概念定义。 > [!tip] 51学通信知识星球 > **星主：爱卫生**（微信：gprshome201101）——公众号「51学通信」创办者，19 年通信行业运维与讲师经验，著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书（各大电商平台有售）。 > **星球定位**：深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域，主打运维岗位与信令分析。 > **当前规模**：5200 篇主题 / 990 个回答，198 元/年。 > **加入福利**：加入星球后请加爱卫生微信，拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题，另有群内分享。 > **AI 加持**：51学通信知识星球已作为 skill 接入 WorkBuddy，使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例，做总结、找文档和 PPT 等场景全覆盖。