把六个最新的多智能体系统拆到底，会发现框架之争只是表层，真正决定成本与可靠性的，是三个协调原语（coordination primitive）的选择：智能体之间究竟通过什么"看见"彼此的状态——是一块谁都能写的黑板、一条按话题分发的消息总线，还是一个个点名投递的收件箱。2025—2026 年的三项关键研究给出了同样的结论：模型推理已经足够快、足够便宜，但协调延迟与协调税才是多智能体系统无法 scale 的真正瓶颈。Han 与 Zhang 在 arXiv:2507.01701 中把经典黑板架构引入 LLM 多智能体系统，在 AIMO 数学题与谋杀谜题上证明"共享黑板"可以击败"中心化经理"结构；SE-Blackboard（IEEE Access 2026）把同一思路搬进软件工程流水线；而 AgentMarketCap 的生产事故复盘则指出，共享状态最隐蔽的代价是两个智能体静默地互相覆盖。本文用一张耦合税账本，把三个原语的可见性成本、令牌成本、故障模式逐一拆开。
| 维度 | 黑板（Blackboard / 共享态） | 总线（Message Bus / Pub-Sub） | 收件箱（Inbox / 点对点） |
|---|---|---|---|
| 可见性模型 | 全员读全部状态 | 订阅者读自己关心的频道 | 只有被点名者收到 |
| 耦合度 | 最强（结构共享） | 中（话题共享） | 最弱（仅地址耦合） |
| 令牌税 | 高，每次快照重灌上下文 | 中，按频道过滤后注入 | 低，只传必要消息 |
| 典型故障 | 静默覆盖、读写竞争 | 乱序、丢订阅、重复消费 | 路由错配、死等回复 |
| 谁在控制流 | 控制壳（controller shell） | 总线本身（去中心化涌现） | 调用方（显式编排） |
| 适合阶段 | 渐进求精、求解空间开放 | 事件驱动、松耦合广播 | 任务清晰、责任分明 |
| 演化倾向 | 2025 复兴，回归经典 AI | 微服务范式迁移 | A2A 协议标准化 |
下面逐一拆解每一档的耦合税来源、代码形态与变现评估。
黑板架构并非新发明，它诞生于 1980 年代的 Hearsay-II 语音识别系统：一块中心化的结构化知识板，多个独立"知识源（knowledge source）"在条件满足时被触发，向板上写入、从板上读取，由一个控制壳决定下一个激活谁。Han 与 Zhang（arXiv:2507.01701）正是把这套经典范式移植到 LLM 时代：每个 LLM 智能体有专属角色，读写同一块共享黑板，控制壳负责调度。在 AIMO 数学竞赛题与谋杀谜题逻辑推理两类任务上，他们对照了中心化（manager-worker）、黑板、分布式三种通信结构，结论是黑板在需要"渐进求精、多视角拼图"的任务上明显占优。
黑板的耦合税来自可见性即复制：任何智能体要"看到"当前状态，就得把整块黑板（或一个快照）塞进自己的上下文。状态越大，每一步的令牌税越重，这与系列前文《压缩即失忆：自主体上下文税实测》观察到的现象同源——黑板越大，越容易触发压缩，越容易丢掉关键证据。更危险的是静默覆盖：AgentMarketCap 的生产复盘给出最典型的剧本——两个智能体读取同一文件、各自独立编辑、然后竞争写回，"没有任何报错抛出，一个智能体的工作悄无声息地消失了，代码库停留在双方都不想要的状态"。这是共享态最被低估的产线事故，解决办法是乐观锁（带版本号写回、冲突重试），而非依赖模型自觉。
# 黑板原语：结构化共享态 + 控制壳调度（伪代码）
class Blackboard:
def __init__(self):
self.state = {} # 结构化共享板
self.version = {} # 每个键的版本号，写回时乐观锁校验
def write(self, key, value, expected_version):
if self.version.get(key) != expected_version:
raise StaleWrite(key) # 静默覆盖的第一道闸
self.state[key] = value
self.version[key] += 1
self.controller.notify(key) # 唤醒关心该键的知识源
# 控制壳按"最被需要"的优先级激活智能体，而非按时间线
变现 / 训练营评估：黑板模式最适合包装成"开放式求解"训练营——数学证明、刑侦推理、方案共创这类没有固定 DAG 的任务，正是黑板的主场。卖点在于"多智能体拼图"，但教学难点在于讲清乐观锁与控制壳策略，否则学员只会做出互相覆盖的玩具。
总线原语直接迁移自微服务的事件驱动架构：智能体不直接喊话，而是把消息发到一个或多个频道（topic），订阅者各取所需，发布者与订阅者彼此不知道对方是谁。GeekyAnts 的技术深潜把它归为多智能体通信的"技术分层"之一，强调它解耦了发送方与接收方，使系统可水平扩展。Coupling 介于黑板与收件箱之间——大家共享的是话题语义而非完整状态结构。
总线的主要耦合税是消费侧的不可控。第一，乱序：同一频道的多条消息可能被不同订阅者乱序消费，若消息之间存在前置依赖（A 必须先于 B 被处理），系统会在无声中产出错乱状态，这正是系列前文《乱序即废：工具前置依赖六栈实测》在工具层观察到的问题在通信层的翻版。第二，重复消费与丢订阅：在多实例部署下，一条消息可能被消费两次（幂等性要求）或因订阅注册延迟而彻底丢失。第三，调试黑洞：消息流是"暗物质"，出问题时光看日志难以重建"谁在何时因为哪条消息做了什么决定"。
# 总线原语：发布者不知道有几个订阅者
class Bus:
def __init__(self):
self.subs = defaultdict(list)
def publish(self, topic, payload, seq):
# 至少一次投递 + 序列号，订阅者自行去重与排序
for handler in self.subs[topic]:
handler(payload, seq) # 投递顺序 ≠ 发布顺序
bus.subscribe("order.created", inventory_agent)
bus.subscribe("order.created", billing_agent) # 两者并行，互不知情
bus.subscribe("order.created", fraud_agent)
变现评估：总线最适合做"事件驱动业务编排"类产品——订单处理、风控流水、IoT 告警分发。卖点是与企业现有微服务栈无缝对接（Kafka/NATS/Redis Stream）。但训练营需重点教幂等设计与可观测性（消息追踪、重放），否则交付的只是能跑 demo 但上不了线的半成品。
收件箱原语最接近 Actor 模型：每个智能体拥有一个命名的信箱，消息按地址点对点投递，发送方必须明确知道接收方是谁。这是 2025—2026 年伴随 A2A（Agent-to-Agent）协议兴起而标准化的一档——智能体拥有稳定身份（agent card）、明确能力声明，调用方按需寻址。耦合度最低：双方只共享"消息格式"与"地址"，不共享任何运行态。
收件箱的耦合税藏在寻址正确性里。第一，能力失真：调用方依赖每个智能体自报的能力（系列前文《自报家门税：A2A 能力失真实测》已证自报经常夸大或过期），导致"该派给甲的活派给了声称能干其实干不了的乙"。第二，死等回复：点对点请求若不设超时，调用方会无限期挂起，等一个永远不会回来的回答——这是最长尾的"协调延迟"。bilwasiva 的论文《Coordination Latency as the Dominant Bottleneck》正是把这类串行等待列为主瓶颈：即便单次推理变快，多个组件（规划器、智能体、工具、记忆系统）串行握手后，端到端延迟仍被协调开销主导。第三，路由错配：当智能体数量上来后，"该找谁"本身成为一个组合问题，错配即返工。
# 收件箱原语：显式寻址 + 超时，不共享任何运行态
def ask(target_agent_id, message, timeout=10):
mbox = registry.locate(target_agent_id) # 依赖 agent card 的能力/地址
token = mbox.deliver(message)
return reply_wait(token, timeout=timeout) # 无超时 → 无限挂起
变现评估：收件箱最适合"跨组织智能体协作"产品——供应链多方对接、跨厂商客服流转。卖点是标准化（A2A、agent card）带来的可替换性，谁都能换。但教学难点是身份与信任：如何验能力、如何防冒名、如何设超时与熔断，这些是产品化壁垒。
把三档拉平看，bilwasiva 的 2026 立场文章与 Medium 上《多智能体蜂群与协调开销经济学》给出同一个判词：协调延迟与协调开销是规模化的真正瓶颈，而非模型本身。后者量化了蜂群规模——10、50、1000 个智能体——的协调开销如何被"冗余工作 + 过度消息传递"主导。这对三原语各自施加了不同的延迟形状：
flowchart LR
subgraph BB[黑板：控制壳串行]
B0[黑板快照] -->|重灌上下文| B1[Agent A]
B1 --> B0
B0 -->|重灌上下文| B2[Agent B]
end
subgraph MB[总线：去中心化扇出]
T1[Topic] -.->|订阅| M1[A]
T1 -.->|订阅| M2[B]
T1 -.->|订阅| M3[C]
end
subgraph IB[收件箱：点对点往返]
I1[A] -->|寻址+超时| I2[B]
I2 -->|回复| I1
end
style BB fill:#e8f0fe
style MB fill:#e6f4ea
style IB fill:#fef7e0
理解这张延迟形状图，比记住哪个框架更重要：选错原语，模型再强也会被协调延迟拖垮。
三原语最根本的差异是可见性模型，它直接决定令牌税。黑板是"全员读全部"——每个智能体激活时都要重新加载当前板面，状态越大令牌越贵，但好处是上下文最完整、决策依据最足。总线是"按需订阅"——智能体只收到自己关心的频道，天然做了上下文过滤，令牌税最低，但风险是"该订阅的没订阅"导致信息盲区。收件箱是"被点名才看见"——令牌最省，但调用方必须正确判断"这事归谁管"，判断错了就漏单。
这张可见性账本解释了一个反直觉现象：很多团队上了黑板之后，令牌成本不降反升，原因是"共享态"会持续膨胀，每个智能体都被迫吞下越来越大的快照。Moltbook 的批评文章《Multi-Agent Coordination Is Not About Shared State》正是戳破"先建一块共享状态板"的本能——共享态是协调的结果而非起点，过早共享会让所有参与者背上彼此的全部上下文。务实的做法是按任务阶段切换原语：开放探索阶段用黑板（要看得全），执行分发阶段用总线或收件箱（要看得精）。
生产级系统几乎从不用单一原语。SE-Blackboard（IEEE Access 2026，doi 10.1109/access.2026.3695435）给出了一个值得借鉴的混合范本：在软件工程流水线里用黑板做需求—设计—编码—测试的共享状态板，让各阶段智能体把中间产物写到板上彼此可见，而在阶段内部用点对点收件箱做精细分工。CallSphere 的三架构对比也建议把向量库作为"语义黑板"——当状态从结构化键值变成海量非结构化片段时，向量检索取代直接快照加载，按相关性只取最相关的几段，等于给黑板加了一道可见性过滤层。
把这一切落到工程的硬通货是版本号与乐观锁，它同时服务于黑板（防覆盖）和总线（去重与有序）。AgentMarketCap 推荐的最小可控集是：每条消息/每个状态键带单调递增的序列号，写回前校验、冲突时重试，配合幂等消费，就能把三原语共有的"静默错乱"风险压到最低。这套机制跨原语通用，是无论选哪一档都该先打好的地基。
flowchart TB
subgraph K1[黑板 Blackboard]
direction TB
BBctrl[控制壳 Controller]
BBboard[(共享黑板<br/>结构化状态 + 版本号)]
BBa[知识源 A] <-->|读写| BBboard
BBb[知识源 B] <-->|读写| BBboard
BBctrl -.激活.-> BBa
BBctrl -.激活.-> BBb
end
subgraph K2[总线 Bus]
direction TB
T1[(Topic: plan)]
T2[(Topic: review)]
Pa[Publish A] --> T1
T1 -.-> Sa[Sub A]
T1 -.-> Sb[Sub B]
end
subgraph K3[收件箱 Inbox]
direction TB
Reg[(Agent Registry<br/>agent card)]
Snd[Sender] -->|寻址| Reg
Reg --> MboxA[(mailbox A)]
Reg --> MboxB[(mailbox B)]
end
K1 ==>|阶段切换| K2
K2 ==>|阶段切换| K3
一句话收束：协调原语的选择，本质是在可见性成本（令牌税）、耦合强度（故障传染半径）与控制权归属（谁来编排）三者之间做权衡。2026 年的成熟做法不是迷信某一个框架，而是认清自己处在任务的哪个阶段，然后选对那块黑板、那条总线、或那个收件箱。
[!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 等场景全覆盖。