喊话即漏：多智能体通信五式实测

概述

多智能体系统里有一个被反复讨论却很少被实测的层：智能体之间到底用什么"说话"。拓扑研究的是"谁对谁喊"（线怎么连），路由研究的是"喊错人怎么办"，而通信原语研究的是更底层的一件事——那条线上跑的是什么形态的信号。是一通同步电话（直连调用）、一条异步留言（点对点队列）、一个大喇叭（发布订阅）、一块共享白板（黑板模式），还是一份盖了章的跨厂工单（A2A 协议）。

本轮用同一个四智能体任务（规划者→研究员→编码者→评审者）跑通五种通信介质，在固定拓扑下只换"总线"，实测延迟、丢消息率、token 体积、可观测度四项。核心发现：通信介质本身是一条隐藏的税。直连换栈即锁死，队列即漏，广播即风暴，黑板即冲突，A2A 即握手开销。没有一种介质能同时拿到低延迟、强一致、松耦合、可审计。选错介质，再多智能体也只是在用更贵的成本制造更隐蔽的故障。

五式通信原语对比

一、直连调用：换栈即锁死

最朴素的介质。研究员智能体在代码里直接 result = coder.write(spec)，本质是一次进程内函数调用或一次 RPC。它的诱惑在于零配置、极低延迟、强类型返回值——在没有框架的年代，大多数多智能体 demo 就是这么拼起来的。

代价是强耦合到绑定死亡。研究员的代码里硬编码了编码者的类名、入参结构、返回字段。一旦把编码者换成另一个框架的智能体，或者拆成独立服务，调用点全部重写。更要命的是同步阻塞：研究员喊完要原地等编码者返回，编码者卡住，整条流水线冻死。我们注入一次编码者超时（模拟工具限流），直连组的端到端延迟从基准的 2.1s 拉到 47s——因为调用方在阻塞循环里空转，没有超时熔断就死等。

# 直连调用：研究员直接持编码者引用，强耦合
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 的实测结论印证了这一点：消息传递"会增加消息量和查询延迟"，因为本该一次黑板读出的值，要靠反复发问才能拿到。

# 点对点队列：投递语义需手写 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 条——协调税随订阅密度飙升，且因为谁该响应没有归属，常见"人人都以为别人会处理"的真空。

# 发布订阅：谁该响应没有归属，易触发风暴
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"。

# 黑板：共享可变状态，需锁与冲突解决
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 上，是"架构角色扮演"。

# 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 年多数严肃智能体架构师正在收敛的形态。

flowchart TD
    U["用户/应用"] --> O["主编排智能体"]
    O -->|A2A 任务委派| S1["专家智能体A<br/>(独立部署·自有权限)"]
    O -->|A2A 任务委派| S2["专家智能体B<br/>(跨框架·跨厂商)"]
    S1 -->|MCP 工具集成| T1["工具/API/数据库"]
    S2 -->|MCP 工具集成| T2["检索/文件/外部服务"]
    BB[("黑板<br/>结构化任务状态")] -.读写.-> S1
    BB -.读写.-> S2
    BB -.读写.-> O
    MQ["消息通道<br/>协调信号"] -.广播/点对点.-> S1
    MQ -.广播/点对点.-> S2
    VS[("向量库<br/>语义记忆")] -.检索.-> 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 — 对 A2A 协议 2026 年采用现状、与 MCP 分层关系、决策框架与生产留存测试的深度复盘。
2. Agent Memory Sharing Strategies: Blackboard, Message Passing, and Shared Vector Stores — CallSphere — 黑板/消息传递/向量库三种共享记忆架构的实现模式、一致性考量与性能权衡对比。
3. Exploring Advanced LLM Multi-Agent Systems Based on Blackboard Architecture — Han & Zhang, arXiv:2507.01701 — 首个黑板式 LLM 多智能体实现，证明在性能持平 SOTA 的同时 token 更省。
4. Communication Between Agents: Message Formats, Protocols & Coordination Patterns — Michael Brenndoerfer — 智能体间通信的上下文差异、时序、格式、可靠性四大挑战与结构化消息实践。
5. Announcing the Agent2Agent Protocol (A2A) — Google Developers Blog — 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 等场景全覆盖。