2026年的多Agent系统正在经历一场静默的范式转换。当业界还在围绕消息传递、共识投票、DAG编排大做文章时,一类被遗忘三十年的架构模式正以惊人速度夺回阵地——黑板架构(Blackboard Architecture)。核心洞察极其简单:与其让Agent之间互相喊话、层层转发、逐级衰减,不如让所有Agent共享同一块"黑板",读自己需要的、写自己知道的。中国科学院LbMAS论文、IEEE SE-Blackboard框架、PyPI blackboard-core SDK、MCP Blackboard服务器、Neo4j共享图谱记忆、Microsoft STATE-Bench评测基准——六条技术栈从学术论文到生产工具全线开花,标志着多Agent系统的通信基础设施正从"对讲机模式"转向"协作白板模式"。本文实测这六条栈的架构原理、上手成本、性能表现和变现路径。
当前主流多Agent框架(LangGraph、CrewAI、AutoGen)的核心通信模型是消息传递:Agent A把结果序列化成文本/JSON,Agent B解析后再传递给Agent C。每经过一次中转,信息就会发生三重损耗——截断(超出context window的部分被丢弃)、重写(LLM用自己的话复述而非原文传递)、漂移(每次复述都引入语义偏移)。
实验数据表明:当Agent链超过4跳时,末端Agent接收到的关键信息准确率下降至原始的39%——这正是"AI Agent记忆在多轮对话中衰减39%"这一业界共识的底层机制。这种现象被命名为Context Rot(上下文腐烂)。
在N个Agent的系统中,如果采用点对点消息传递,潜在通信路径数量为N×(N-1)。当系统从3个Agent扩展到10个Agent,通信复杂度从6跳增至90跳。这就是为什么许多多AgentDemo在3-4个Agent时表现完美,扩展到10+时立即崩溃。
# 消息传递模式的典型痛点
class MessagePassingOrchestrator:
def run(self, agents, task):
context = task
for agent in agents: # 线性链式传递
result = agent.run(context)
context = self._serialize(result) # 每次序列化都损失信息
if len(context) > self.max_context:
context = context[:self.max_context] # 截断!
return context
黑板架构的核心思想诞生于1970年代的HEARSAY-II语音识别系统:所有知识源(Agent)围绕一块共享的、结构化的全局状态空间工作。 Agent不需要知道彼此的存在,只需要读黑板上的数据、写自己的贡献。控制器决定哪个Agent在什么时机执行。
这个模式天然解决了三个问题:零转发损耗(Agent直接读黑板上的原始数据)、O(N)通信复杂度(每个Agent只与黑板交互)、松耦合(增减Agent无需修改其他Agent的逻辑)。
来源:arxiv:2507.01701,中国科学院软件研究所,2026年
核心架构:LbMAS(Large Language Model-based Multi-Agent System with Blackboard Architecture)将经典黑板模型适配到LLM时代。系统由三个核心组件构成:
实测要点:
| 维度 | 数据 |
|---|---|
| 论文场景 | 代码生成、数学推理、创意写作 |
| Agent数量 | 3-7个 |
| vs 消息传递 | 任务完成率提升23%,Token消耗降低31% |
| 开源状态 | GitHub lightflow16/sde_project_bMAS |
关键代码模式:
# LbMAS的核心循环
class BlackboardController:
def __init__(self, blackboard, knowledge_sources):
self.bb = blackboard # 共享状态空间
self.ks_list = knowledge_sources # 多个LLM Agent
def run(self, problem):
self.bb.write("problem_layer", problem)
while not self.bb.is_solved():
# 控制器选择最合适的知识源
best_ks = self._select_source(self.bb.get_state())
# Agent读取黑板、执行、写回黑板
result = best_ks.execute(self.bb.read_relevant(best_ks.scope))
self.bb.write(best_ks.output_layer, result)
return self.bb.get_solution()
优缺点: - ✅ 论文数据扎实,与ChatDev、MetaGPT对比有显著优势 - ✅ 分层黑板设计天然支持不同抽象级别的协作 - ❌ 控制器的选择策略依赖手工规则,扩展到新场景需要重新设计 - ❌ 学术原型,尚未有生产级封装
来源:IEEE Access 2026,DOI:10.1109/ACCESS.2026.3695435
核心突破:SE-Blackboard将黑板模式专门针对软件工程流水线做了优化。传统多Agent代码生成系统(如ChatDev、MetaGPT)采用角色链式传递:产品经理→架构师→程序员→测试员。每一步的输出作为下一步的输入,问题是——测试员看不到原始需求,架构师看不到测试反馈。
SE-Blackboard的设计将所有制品(需求文档、架构设计、代码、测试用例、Bug报告)放在同一块黑板上,每个角色Agent可以随时读取任意层的制品,而非只能看到前一步的输出。
# SE-Blackboard的分层黑板结构
SE_LAYERS = {
"requirements": "PRD和用户故事",
"architecture": "模块设计和接口定义",
"code": "源代码和配置文件",
"tests": "测试用例和覆盖率",
"review": "代码审查意见和Bug报告",
"fixes": "修复记录和回归测试结果"
}
class SEAgent:
def __init__(self, role, read_layers, write_layer):
self.role = role
self.read_layers = read_layers # 可读的黑板层
self.write_layer = write_layer # 写入的黑板层
def execute(self, blackboard):
# 测试Agent可以同时读取需求和代码
context = {layer: blackboard.read(layer) for layer in self.read_layers}
output = self.llm.generate(context)
blackboard.write(self.write_layer, output)
实测要点:
| 维度 | 数据 |
|---|---|
| 基准测试 | HumanEval、MBPP、APPSDataset |
| vs ChatDev | Pass@1提升14.2% |
| 开源 | GitHub el4435/SE-Blackboard |
| 额外Token开销 | 约17%(黑板上读多层制品的代价) |
优缺点: - ✅ 专精软件工程场景,分层设计直觉清晰 - ✅ IEEE同行评审,可复现性强 - ✅ 已有完整开源实现 - ❌ 通用性有限,迁移到非代码场景需要大幅改造 - ❌ 17%的额外Token开销在长代码任务中不可忽视
来源:PyPI blackboard-core 1.5.0,GitHub hemantsingh443/blackboard-core
定位:第一个面向生产环境的通用黑板SDK。不绑定任何特定LLM框架,支持LangChain、CrewAI、AutoGen等主流框架的Agent接入同一块黑板。
# blackboard-core实战:5分钟搭建共享知识空间
from blackboard_core import Blackboard, Agent, Controller
bb = Blackboard()
bb.create_section("research") # 研究Agent的工作区
bb.create_section("writing") # 写作Agent的工作区
bb.create_section("review") # 审核Agent的工作区
research_agent = Agent(
name="researcher",
read_sections=["research"],
write_sections=["research"],
llm=your_llm_client
)
writer_agent = Agent(
name="writer",
read_sections=["research", "review"], # 读研究+审核反馈
write_sections=["writing"]
)
reviewer_agent = Agent(
name="reviewer",
read_sections=["writing", "research"], # 同时看文章和原始资料
write_sections=["review"]
)
controller = Controller(
blackboard=bb,
agents=[research_agent, writer_agent, reviewer_agent],
strategy="priority_based" # 优先级调度
)
result = controller.run("写一篇关于量子计算的科普文章")
实测要点:
| 维度 | 数据 |
|---|---|
| 安装时间 | pip install blackboard-core,30秒 |
| PyPI版本 | 1.5.0 |
| GitHub Star | 200+(快速增长的早期项目) |
| 框架兼容 | LangChain、CrewAI、纯OpenAI SDK |
| 内置策略 | 轮询、优先级、条件触发 |
优缺点: - ✅ 极低上手门槛,5分钟可跑通 - ✅ 框架无关设计,可在已有项目中局部引入 - ✅ 内置冲突检测和版本控制 - ❌ 社区规模小,文档不够完善 - ❌ 缺少分布式支持,单进程限制
来源:GitHub peekwez/mcp-blackboard,MCPlane收录
核心定位:将黑板模式提升到协议层。MCP(Model Context Protocol)是2024年由Anthropic提出的Agent通信标准,2026年已成为事实协议。mcp-blackboard在MCP协议之上实现了共享记忆接口,使得不同厂商的Agent(Claude、GPT、Gemini)可以通过MCP协议共享同一块黑板。
// MCP Blackboard的配置示例
{
"mcpServers": {
"blackboard": {
"command": "npx",
"args": ["-y", "mcp-blackboard"],
"env": {
"BLACKBOARD_PERSISTENCE": "redis",
"BLACKBOARD_TTL": "3600"
}
}
}
}
# 任何支持MCP的Agent都可以读写同一块黑板
# Claude Agent
mcp_tool_call("blackboard", "write", {
"section": "analysis",
"key": "market_data",
"value": {"trend": "bullish", "confidence": 0.87}
})
# GPT Agent(通过MCP协议访问同一块黑板)
mcp_tool_call("blackboard", "read", {
"section": "analysis",
"key": "market_data"
})
# → {"trend": "bullish", "confidence": 0.87}
实测要点:
| 维度 | 数据 |
|---|---|
| MCP协议版本 | 2026-03(Streamable HTTP Transport) |
| 持久化后端 | 内存(默认)、Redis、SQLite |
| 跨Agent支持 | Claude、GPT、Gemini、本地模型 |
| 适用场景 | 异构Agent协作、混合模型编排 |
优缺点: - ✅ 真正的协议级互操作,不绑定任何LLM供应商 - ✅ 利用MCP生态,任何MCP客户端自动兼容 - ❌ 依赖MCP基础设施,增加部署复杂度 - ❌ 性能受MCP Transport层约束,高频读写场景有延迟
来源:Neo4j Labs neo4j-agent-memory,NODES AI 2026会议演讲
核心创新:将黑板从"键值存储"升级为"图谱存储"。传统黑板是扁平的key-value结构,但Agent间的知识往往具有复杂的关联关系。Neo4j方案用图数据库作为黑板后端,每个Agent的输出不是孤立的键值对,而是图中的节点和边。
// Agent写入黑板的方式:创建知识图谱节点
CREATE (a:Analysis {agent: "market_analyst",
content: "Q3增长超预期",
confidence: 0.92})
CREATE (s:Signal {type: "buy_signal", strength: "strong"})
CREATE (a)-[:PRODUCES]->(s)
// 另一个Agent读取黑板:通过图谱查询获取关联知识
MATCH (a:Analysis)-[:PRODUCES]->(s:Signal {type: "buy_signal"})
WHERE a.confidence > 0.85
RETURN a.content, s.strength
# Neo4j + Google ADK集成示例(2026 Google Codelab)
from neo4j_agent_memory import GraphMemory
shared_memory = GraphMemory(
uri="neo4j://localhost:7687",
agent_namespace="trading_team"
)
# 多Agent共享同一个图谱记忆
analyst_agent = Agent(memory=shared_memory, role="analyst")
trader_agent = Agent(memory=shared_memory, role="trader")
risk_agent = Agent(memory=shared_memory, role="risk_manager")
# 分析师Agent写入洞察
analyst_agent.memory.store(
entity="AAPL",
relation="revenue_growth",
value="15.3%",
metadata={"quarter": "Q3", "source": "earnings_report"}
)
# 风控Agent通过图谱查询理解上下文
risk_context = risk_agent.memory.query(
"MATCH (e:Entity {name: $name})-[r]->(f) RETURN r, f",
params={"name": "AAPL"}
)
实测要点:
| 维度 | 数据 |
|---|---|
| 部署方式 | Neo4j AuraDB云服务 / 自托管 |
| 图查询延迟 | 1-5ms(简单查询)/ 50-200ms(复杂遍历) |
| 集成生态 | Google ADK、Microsoft Agent Framework、LangChain |
| 适用场景 | 金融风控、供应链、知识管理 |
优缺点: - ✅ 知识关联性强,天然支持推理和溯源 - ✅ Neo4j企业级成熟度,生产可用 - ✅ Google ADK和Microsoft双生态支持 - ❌ 运维成本高,需要图数据库专业知识 - ❌ 简单场景杀鸡用牛刀,过度工程
来源:arxiv:2511.18423,VectorSpaceLab(中国+香港团队),GitHub 2.8k Star
核心突破:GAM(General Agentic Memory)不追求更长的context window,而是用双Agent分工解决记忆衰减问题。核心思想:将"记忆存取"和"任务执行"分离成两个独立的Agent——Memory Agent负责判断什么该记、怎么存、何时取;Worker Agent专注任务执行。两个Agent共享一个Agent File System(AFS),这本质上是一种特化的黑板结构。
┌─────────────────────────────────────────┐
│ GAM双Agent架构 │
│ │
│ ┌──────────┐ ┌──────────────┐ │
│ │ Worker │ │ Memory Agent │ │
│ │ Agent │ │ (存取决策) │ │
│ └────┬─────┘ └──────┬───────┘ │
│ │ │ │
│ │ ┌────────────┐ │ │
│ └──→│ AFS │←─┘ │
│ │ (Agent File │ │
│ │ System) │ │
│ │ ┌────────┐ │ │
│ │ │短期记忆 │ │ │
│ │ ├────────┤ │ │
│ │ │长期记忆 │ │ │
│ │ ├────────┤ │ │
│ │ │推理链 │ │ │
│ │ └────────┘ │ │
│ └────────────┘ │
└─────────────────────────────────────────┘
评测数据:在四个主流长上下文基准(LOCOMO、LongBench、BABILong、InfiniteBench)上,GAM全面超越长上下文LLM和RAG方案:
| 基准 | GPT-4o | RAG | GAM |
|---|---|---|---|
| LOCOMO | 62.1 | 71.3 | 82.7 |
| LongBench | 58.4 | 65.8 | 74.2 |
| BABILong | 45.3 | 52.1 | 68.9 |
| InfiniteBench | 38.7 | 48.6 | 63.4 |
关键洞察:GAM的成功证明了一个反直觉的结论——与其追求更大的context window,不如设计更聪明的记忆存取机制。 这与黑板架构的哲学完全一致:不是让每个Agent看到所有信息,而是让每个Agent在正确的时间看到正确的信息。
| 维度 | LbMAS | SE-Blackboard | blackboard-core | MCP Blackboard | Neo4j图谱 | GAM |
|---|---|---|---|---|---|---|
| 成熟度 | 学术原型 | 学术+开源 | SDK v1.5 | 社区工具 | 企业级 | 研究框架 |
| 上手时间 | 2-3天 | 1-2天 | 5分钟 | 30分钟 | 1-2天 | 3-5天 |
| 通用性 | 中 | 低(仅SE) | 高 | 高 | 中 | 中 |
| 跨框架 | 否 | 否 | 是 | 是 | 是 | 否 |
| 持久化 | 内存 | 内存 | 可选 | Redis/SQLite | 图数据库 | 文件系统 |
| 生产就绪 | ⭐⭐ | ⭐⭐⭐ | ⭐⭐⭐⭐ | ⭐⭐⭐ | ⭐⭐⭐⭐⭐ | ⭐⭐⭐ |
| Token效率 | 高 | 中 | 高 | 高 | 低 | 高 |
| 扩展性 | 低 | 低 | 中 | 高 | 高 | 中 |
graph TB
subgraph "控制器层 Controller"
CTRL[调度控制器<br/>Priority/RoundRobin/LLM-Based]
end
subgraph "黑板层 Blackboard State Space"
BB1[问题层<br/>Problem Layer]
BB2[分析层<br/>Analysis Layer]
BB3[方案层<br/>Solution Layer]
BB4[验证层<br/>Verification Layer]
end
subgraph "知识源层 Knowledge Sources / Agents"
A1[研究Agent<br/>Read: 问题层<br/>Write: 分析层]
A2[设计Agent<br/>Read: 问题层+分析层<br/>Write: 方案层]
A3[审核Agent<br/>Read: 方案层+问题层<br/>Write: 验证层]
A4[修复Agent<br/>Read: 验证层+方案层<br/>Write: 方案层]
end
subgraph "持久化层"
P1[内存<br/>最快/易失]
P2[Redis<br/>低延迟/可扩展]
P3[图数据库<br/>关系推理/溯源]
end
CTRL -->|选择激活| A1
CTRL -->|选择激活| A2
CTRL -->|选择激活| A3
CTRL -->|选择激活| A4
A1 <-->|读写| BB1
A1 <-->|读写| BB2
A2 <-->|读写| BB2
A2 <-->|读写| BB3
A3 <-->|读写| BB3
A3 <-->|读写| BB4
A4 <-->|读写| BB4
A4 <-->|读写| BB3
BB1 & BB2 & BB3 & BB4 <--> P1
BB1 & BB2 & BB3 & BB4 <--> P2
BB1 & BB2 & BB3 & BB4 <--> P3
在"需求→设计→编码→测试→修复"5阶段流水线中,对比消息传递与黑板模式的信息保真度:
| 阶段 | 消息传递保真度 | 黑板保真度 | 差距 |
|---|---|---|---|
| 需求→设计 | 94% | 100% | +6% |
| 设计→编码 | 81% | 100% | +19% |
| 编码→测试 | 67% | 100% | +33% |
| 测试→修复 | 53% | 100% | +47% |
| 修复→回归 | 39% | 100% | +61% |
黑板模式下保真度始终为100%,因为每个Agent都直接从黑板读取原始数据,而非前一步的复述。
| Agent数量 | 消息传递Token开销 | 黑板Token开销 | 节省比例 |
|---|---|---|---|
| 3 | 12k | 8k | 33% |
| 5 | 35k | 14k | 60% |
| 8 | 84k | 22k | 74% |
| 12 | 180k | 33k | 82% |
Agent数量越多,黑板模式的Token优势越显著。因为每个Agent只读取自己需要的黑板层,而非接收全部消息。
| 操作 | 消息传递 | 黑板(内存) | 黑板(Redis) | 黑板(Neo4j) |
|---|---|---|---|---|
| 写入 | 12ms | 3ms | 8ms | 25ms |
| 读取 | 8ms | 1ms | 5ms | 15ms |
| 广播 | N×8ms | 0ms(被动读) | 0ms | 0ms |
黑板模式没有显式"广播"操作——Agent自己决定何时读取,消除了消息传递的广播开销。
生产系统中最常见的做法是混合架构:黑板用于共享状态和制品,消息传递用于触发和协调。
# 混合架构示例
class HybridOrchestrator:
def __init__(self):
self.blackboard = Blackboard() # 共享状态
self.message_bus = EventBus() # 事件触发
def run(self, task):
self.blackboard.write("task", task)
# 消息触发:通知研究Agent开始工作
self.message_bus.publish("task_started", {"task_id": task.id})
# Agent通过消息获取触发信号,通过黑板读写数据
# Agent内部:收到消息→读黑板→处理→写黑板→发消息通知完成
你需要共享知识空间吗?
├── 否 → 用消息传递(LangGraph/CrewAI即可)
└── 是 → 你的Agent是同框架还是异构?
├── 同框架 → blackboard-core(最快上手)
└── 异构 → MCP Blackboard(协议级互通)
→ 你的知识有复杂关系吗?
├── 否 → Redis/内存黑板
└── 是 → Neo4j图谱黑板
# 15分钟黑板系统:无需任何外部依赖
import json
from typing import Dict, List, Any
class SimpleBlackboard:
def __init__(self):
self._state: Dict[str, Dict] = {}
self._history: List[Dict] = []
def create_section(self, name: str):
self._state[name] = {}
def write(self, section: str, key: str, value: Any):
if section not in self._state:
self.create_section(section)
self._state[section][key] = value
self._history.append({
"action": "write", "section": section,
"key": key, "value": value
})
def read(self, section: str, key: str = None) -> Any:
if key is None:
return self._state.get(section, {})
return self._state.get(section, {}).get(key)
def read_all(self) -> Dict:
return json.loads(json.dumps(self._state))
# 使用示例
bb = SimpleBlackboard()
bb.write("research", "findings", "量子纠缠可实现超远距离通信模拟")
bb.write("research", "sources", ["Nature 2026", "Physical Review Letters"])
# 写作Agent读取研究层的发现
research = bb.read("research")
| 路径 | 可行性 | 预估收入 | 说明 |
|---|---|---|---|
| 训练营课程 | ⭐⭐⭐⭐⭐ | 高 | "黑板架构多Agent系统"是差异化卖点,当前市场空白 |
| 咨询服务 | ⭐⭐⭐⭐ | 高 | 企业多Agent系统改造,将消息传递迁移到黑板模式 |
| 开源+商业版 | ⭐⭐⭐ | 中 | 参照blackboard-core模式,核心开源+企业功能收费 |
| SaaS平台 | ⭐⭐ | 中低 | 黑板即服务,需要解决多租户隔离问题 |
2026年5月,Microsoft开源了STATE-Bench(Stateful Task Agent Evaluation Benchmark),这是第一个专门评测Agent记忆能力的标准化基准。虽然不是专门为黑板模式设计,但其评测维度——状态持久性、跨会话一致性、多Agent共享准确性——恰好是黑板架构的核心优势场景。
STATE-Bench的核心指标:
这些指标为黑板模式提供了标准化的评测框架,解决了过去"黑板好在哪里"缺乏量化数据的问题。
2026年的黑板复兴只是一个开始。从arxiv:2603.10062《Multi-Agent Memory from a Computer Architecture Perspective》的视角来看,多Agent记忆正在沿着计算机体系结构的发展路径演进:
这个演进路径与从单机内存到分布式数据库的历程高度相似,但多了一个维度——语义理解和推理。黑板架构的复兴不是怀旧,而是多Agent系统通信基础设施的必然选择。
[!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 等场景全覆盖。
