黑板架构回归：多Agent共享状态实测

黑板架构（Blackboard Architecture）正在成为2026年多智能体系统的回潮范式。这块源自1980年Hearsay-II语音理解系统的"经典AI遗产"，在被消息总线、Supervisor编排、Mesh点对点压制了二十多年后，因为大模型上下文窗口的结构性缺陷而重新被点燃——多个LLM智能体不再通过消息互相喊话，而是围绕一块共享的、带类型与版本的状态空间读写，由一个控制器（Controller）决定谁先动。中科院团队2025年的LbMAS论文与多份2026年实践复盘都指向同一个判断：在需要部分结果可观察、协调关系不确定、参与方异构的复杂任务里，黑板模型把"协调税"从消息往返里转移到了状态收敛里，付出的代价是状态膨胀与冲突仲裁。本文拆解其三大组件、与五种主流协调模式的实测对比、控制器的调度红线、以及向生产迁移时必踩的四个坑。

一、为何是黑板：消息传递的结构性失血

先把坐标定准。多智能体协调的本质是"信息从哪来、到哪去、谁决定顺序"。当前的工业实践集中在两条路上：消息传递（AutoGen、A2A、Mesh）和编排器（LangGraph Supervisor、CrewAI Pipeline）。前者让智能体两两发消息，后者让一个中心节点调度子任务。

这两条路在LLM时代有一个共同的失血点：每次协调都要把对方的状态重新塞进上下文。两个智能体A和B要协作，A发消息给B，B要理解A在说什么，就必须在上下文里重建A的推理链；反过来同理。当智能体数量到5个以上、任务跨10轮以上时，协调本身消耗的token可能占到总支出的40%以上——这就是已被反复实测的"协调税"。

黑板架构换了一个根本性的思路：取消智能体之间的直接消息，所有部分结果都写到一块共享黑板上。智能体之间不"对话"，只对黑板读写。任何一个智能体想了解全局状态，去读黑板即可，而不必等待别人"告诉"它。这把"信息传递"变成了"状态共享"，把"点对点拓扑"变成了"星型+共享内存"拓扑。在协调关系不确定、谁该接手下一棒尚未明朗的探索性任务中，这种解耦能显著降低编排复杂度。

代价同样明确：黑板会膨胀，多个智能体并发写入会产生冲突，控制器要承担调度与仲裁的全部责任。黑板不是银弹，它是把协调成本从"通信"维度搬到了"状态管理"维度——这个置换在某些任务里净赚，在另一些任务里净亏。判断的关键在于任务的协调关系是否预先确定。

二、多智能体协调模式横向对比

协调模式	信息载体	调度方	协调关系要求	协调税来源	典型框架
消息传递/对话	点对点消息	各智能体自决	需预先知道对方	token往返重建上下文	AutoGen, A2A
Supervisor编排	子任务结果	中心编排器	流程可静态分解	编排器成为瓶颈	LangGraph, CrewAI
Pipeline流水线	顺序传递	固定链路	强线性、可串行	每段全量上下文	顺序Chain
Mesh/P2P	全连接消息	去中心化	共识/辩论	连接数平方爆炸	辩论网, AgentVerse
黑板架构	共享状态空间	控制器+触发	不确定、涌现式	状态膨胀+冲突仲裁	LbMAS, bMAS

这张表的关键在第四列"协调关系要求"。前四种模式都隐含一个假设：任务分解的方式、智能体之间的依赖关系，在系统启动时大体已知。Supervisor知道有哪些子任务，Pipeline知道链路顺序，Mesh知道参与者。黑板架构是唯一一种为"协调关系不确定"设计的模式——控制器不预设谁该接手，而是监听黑板状态变化，让知识源（Knowledge Source）根据自己预设的触发条件（precondition）主动认领。这是它和编排器的根本分野。

三、黑板三件套：黑板、知识源、控制器

黑板架构的经典定义是三件套，这套结构在LLM场景下被完整保留，只是每件套的内涵发生了迁移。

第一件：黑板（Blackboard）。它不是一块无结构的白板，而是一个分层的、带类型的、可版本化的状态空间。Hearsay-II当年把黑板分成词汇、音素、音节、词、短语多个抽象层级，LLM黑板通常分成"事实层""假设层""决策层""待办层"。每个条目（entry）带元数据：写入者、时间戳、置信度、依赖指针。分层是关键——它让知识源可以订阅自己关心的层级，而不是被迫扫描全部状态。生产环境里，这块黑板几乎总是落在一个外部存储（Redis、Postgres JSONB、向量库）而非模型上下文里，否则它会迅速吃满窗口。

第二件：知识源（Knowledge Source, KS）。每个KS是一个自治的、对黑板特定变化敏感的智能体。KS的核心特征是它带一个触发条件：当黑板出现某种模式（例如"事实层新增了三条法律条文"），KS才被激活。KS之间互不知道彼此存在，只对黑板状态反应。这种"无知"恰恰是解耦的来源——新增一个专家智能体不需要改任何已有智能体的代码，只要注册它的触发条件即可。这是黑板模型相对消息总线的扩展性优势所在。

第三件：控制器（Controller）/调度器。它是整个系统的大脑，负责一件事：根据当前黑板状态，决定下一步激活哪个KS。控制器的策略从简单到复杂分三档：轮询（round-robin，所有可激活KS轮流）、优先级（按KS声明的优先级）、以及基于黑板状态的策略式调度（agenda-driven，维护一个候选KS队列，每轮选期望信息增益最大者）。控制器的质量直接决定系统是否会塌方——一个糟糕的控制器会让黑板在低价值条目上反复打转，token烧光而无收敛。

四、控制器调度：从轮询到议程驱动

控制器是黑板架构里工程含量最高、也最容易出问题的地方。实测中，控制器的调度策略直接决定了系统是"优雅收敛"还是"原地空转"。

最朴素的轮询调度几乎不可用于生产。原因在于LLM的KS执行成本不对称：一次法律分析KS可能消耗2000 token，一次格式校验KS只消耗200 token。轮询会让它们获得相同的执行机会，导致高成本KS被低价值KS稀释，预算耗尽前根本到不了深层推理。这一点在多份2026复盘中被反复提及——"不要用公平调度调度成本不对称的智能体"。

工业级控制器普遍采用议程驱动（agenda-driven）调度，本质是维护一个"可执行KS候选队列"。每轮调度做三件事：扫描黑板状态，找出所有触发条件满足的KS，把它们连同当前黑板快照一起放入议程；对议程中的每个KS评估一个期望价值（信息增益、与目标的距离、置信度提升）；选最高者执行，执行后黑板更新，重新扫描。这个循环对应Hearsay-II当年的"假设-检验"（hypothesize-and-test）周期。

class BlackboardController:
    def __init__(self, blackboard, knowledge_sources, budget):
        self.bb = blackboard
        self.ks_list = knowledge_sources  # 每个KS声明 trigger + priority + cost
        self.budget = budget

    def run(self, goal):
        while not self.goal_met(goal) and self.budget.remaining():
            agenda = []  # 议程：本轮所有可激活的KS
            for ks in self.ks_list:
                if ks.trigger.matches(self.bb.snapshot()):
                    agenda.append(ks)
            if not agenda:
                break  # 无人可动 = 黑板停滞，需注入新信息或终止
            # 按期望价值选KS：优先级 * (1 - 当前置信度) / 成本
            best = max(agenda, key=lambda ks: self.expected_value(ks))
            entry = best.execute(self.bb.read(ks.scope))
            self.bb.write(entry, author=best.id)  # 带版本号与依赖指针
            self.bb.notify()  # 通知其他KS重新评估触发条件

这段伪代码暴露了三个红线。第一，expected_value的估计本身可能需要一次LLM调用，控制器因此不是零成本——生产里常用轻量规则或小模型打分，避免控制器自己吃掉预算。第二，notify机制必须异步且去重，否则一次写入会触发KS雪崩。第三，if not agenda: break这一行是最容易被忽略的——黑板停滞时，系统要么死等要么空转，必须有注入新外部信息或显式终止的逃生通道。多个公开复盘都把"黑板卡死在无人可激活状态"列为头号生产故障。

五、共享状态带来的冲突与一致性

把协调从消息维度搬到状态维度，最直接的工程后果是并发写冲突。多个KS可能同时被同一黑板变化触发，同时尝试写入相互矛盾的条目。消息传递模型里，两个智能体的分歧是一次对话里的事；黑板模型里，两个条目直接共存于状态空间，必须有一套机制决定哪个算数。

生产实践里普遍采用三层防御。第一层是版本号与依赖指针：每个条目记录它基于黑板的哪个版本生成，写入时若发现依赖的版本已被覆盖，则该KS的结果作废、重新触发。这是乐观并发控制，开销小，但在高并发下重试风暴严重。第二层是置信度仲裁：当两个条目落在同一抽象层级、针对同一对象，控制器比较它们的置信度，保留高的、降级低的（而非删除，保留作为替代假设）。第三层是结构化分层：把矛盾条目放在不同层级（如"假设层"vs"已验证层"），让它们逻辑上不冲突，由后续KS负责升迁或否决。

这里的隐性成本是状态膨胀。因为黑板不删除（至少不立即删除）矛盾假设，状态空间会持续增长。一个跑了20轮的黑板，条目数可能膨胀到初始的10倍，每次KS执行前要扫描的黑板快照越来越大。控制台层面的实测显示，若不做主动压缩，黑板的token占用会在第15-20轮左右突破单个KS的上下文窗口上限，导致KS无法完整读取自己关心的层级。解决办法是层级投影：KS只读取它声明scope的层级，控制器负责把全黑板投影成该KS的视图，丢弃无关层。这把"全状态扫描"变成了"局部视图查询"，是黑板模型能scale到中大型任务的命门。

六、黑板 vs Supervisor-Blackboard 混合：实测分水岭

值得单独拎出来的是2026年实践中浮出水面的Supervisor-Blackboard混合模式。纯粹的Supervisor模式（LangGraph默认）让编排器直接调用子智能体、收集返回值；纯黑板模式让智能体只读写黑板、控制器调度。混合模式把两者焊接：Supervisor负责高层任务分解与流程推进，黑板负责智能体之间的状态共享。

# 混合模式：Supervisor 分解任务，黑板承载中间状态
def supervisor_loop(goal, blackboard):
    subtasks = decompose(goal)          # Supervisor：静态分解
    for task in subtasks:
        agent = route(task, blackboard) # 路由到专家智能体
        result = agent.run(task, blackboard.read_for(task))
        blackboard.write(result, task=task)  # 写回黑板而非直接传递
    # Supervisor 不直接持有中间结果，所有跨子任务共享走黑板
    return blackboard.synthesize()

这种混合在"任务前半段结构清晰、后半段涌现"的场景里净赚。例如法律文书起草：大纲分解是确定的（Supervisor擅长），但每个章节的论据补充、引用核验、逻辑自洽检查之间关系错综复杂、谁先完成不定（黑板擅长）。纯Supervisor会强行给这些后续步骤排一个未必正确的顺序，纯黑板则在已经确定的部分浪费调度开销。

分水岭很清晰：协调关系可静态分解的部分交给Supervisor，协调关系涌现的部分交给黑板。强行用一种模式覆盖全任务，要么牺牲确定性（全黑板），要么牺牲灵活性（全Supervisor）。多份生产复盘的共识是——超过70%的真实复杂任务都是"半结构化"的，混合模式的实际采用率正在快速超过纯黑板或纯Supervisor。

七、状态序列化与崩溃恢复

黑板是共享状态，这带来一个被低估的红利：天然的可恢复性。消息传递模型里，系统崩溃后要重建非常痛苦，因为协调状态分散在每条消息里、分散在每个智能体的内部上下文里，没有单一可信快照。黑板模型里，整个系统的进度就是黑板的状态——把黑板序列化到外部存储，就完成了快照；恢复时重建黑板、重放未完成的KS即可。

这个特性让黑板架构在长程任务（跨小时、跨天）里具备结构性优势。一个跑了两小时的多智能体研究任务，中间任何一刻崩溃，都能从最近一次黑板快照恢复，而不是从头来过。工程上这要求KS设计成幂等的（基于黑板状态的触发条件自然满足），且黑板快照是原子写（用事务型存储）。代价是快照本身的存储成本——一个深层黑板可能携带数千条目，单次快照几十KB到几MB，高频快照的存储与序列化开销需要权衡。

但红利也有边界：当KS内部维护了大量与黑板无关的状态时（如某个专家智能体的长内部推理链），那部分状态仍然在黑板的可见范围之外，崩溃就会丢失。所以黑板架构对KS的设计有一条隐性约束——"重要的中间结论必须落板"。不落板的状态就是恢复时的盲区。这条约束在团队协作开发多智能体系统时尤其需要约定，否则不同开发者写的KS对"什么算中间结论"理解不一致，恢复后行为不可重现。

八、选型红线：什么任务该上黑板

把前述拆解收敛成可执行的选型判断。黑板架构净赚的场景有三个特征：协调关系不确定（谁接手下一棒依赖中间结果）、参与方异构且会增减（专家智能体动态加入）、需要部分结果可观察（外部系统或人类要中途查看进度）。典型代表是开放式研究、综合诊断、复杂文书生成、多源情报融合——这些任务里，任务分解的"形状"在执行过程中才浮现，硬套Supervisor的静态DAG会扭曲流程，硬套Mesh会让协调税爆炸。

黑板净亏的场景同样清晰：流程强线性（顺序管线，黑板是过度设计）、参与方固定且少（2-3个智能体，直接消息更简单）、对延迟极敏感（黑板的调度-触发循环比直接调用慢）。一个简单的"搜索-总结-翻译"三段式管线，上黑板纯属增加复杂度，Pipeline模式几行代码就能搞定。

flowchart TD
    START([复杂任务接入]) --> Q1{协调关系<br/>是否预先确定?}
    Q1 -->|是, 可静态分解| SUP[Supervisor/编排模式]
    Q1 -->|否, 涌现式| Q2{参与智能体<br/>是否异构且会增减?}
    Q2 -->|否, 固定少量| MSG[消息传递/对话模式]
    Q2 -->|是, 动态异构| Q3{是否需要部分<br/>结果可观察+崩溃恢复?}
    Q3 -->|否| MESH[Mesh/P2P共识]
    Q3 -->|是| BB[黑板架构]
    Q4{任务是否<br/>半结构化?} -. 推荐 .-> HYBRID[Supervisor-Blackboard混合]
    BB --> Q4
    SUP --> Q4

最后是变现与落地角度。黑板架构的训练营价值集中在两个抓手：一是"经典AI模式与现代LLM的嫁接"这个稀缺选题，市面上讲Supervisor和Mesh的多，讲黑板原理与Hearsay-II渊源的极少，有明确的差异化空间；二是它强制学习者理解"状态协调"这个抽象层次——控制器的议程调度、并发写冲突、状态投影，都是能迁移到任何分布式系统设计的硬技能。产品化方向上，"黑板即服务"（把黑板+控制器+KS注册做成托管中间件）是一个空白位，目前LbMAS等实现都还是研究原型，工业级托管产品缺位，留给独立开发者空间。

一句话结论：黑板架构不是要取代Supervisor或Mesh，它补的是"协调关系涌现且需要共享状态收敛"这一格空缺。上不上黑板，看的不是任务复杂度，而是任务的协调关系能否提前画清楚——画得清楚就别上，画不清楚它才值得那份状态管理的代价。