## 概述 把 Gartner 的数字放在最前面：2024 年初到 2025 年中，关于多智能体系统的咨询量激增 **1,445%**。但真实工程里卡住团队的，从来不是"能不能编排五个 Agent"，而是**五个 Agent 之间靠什么共享上下文**。到 2026 年，多智能体协作的瓶颈已经从调度（谁先做、谁后做）彻底转移到了记忆（中间结果存哪、谁读得到、读到的是不是最新的）。本文拆解当前三种主流的多智能体记忆架构——消息传递、共享黑板、外部化产物——以及它们各自的协作效率与一致性代价，最后给出按任务形态选型的硬规则。 ## 多智能体记忆架构：四栈横评 | 架构 | 共享载体 | 一致性 | 写放大 | 隔离性 | 典型实现 | |------|---------|--------|--------|--------|---------| | 消息传递（会话派） | 对话历史 | 弱（最终一致） | 低 | 强 | AutoGen / CrewAI 对话 | | 共享黑板（Blackboard） | 全局可写状态 | 中（需锁/reducer） | 高 | 弱 | LangGraph State / 自建黑板 | | 外部化产物（Artifact） | 文件/对象存储 | 最终一致 | 低 | 强 | Claude Code 工作目录 / Agent 即微服务 | | 层级记忆 | 短期会话+长期向量+共享层 | 混合 | 中 | 中 | Letta / MemGPT 派系 | | 向量共享层 | 嵌入索引 | 最终一致 | 低 | 弱 | RAG 共享知识库 | 记住一个判断：**这张表里没有"最优"，只有"最匹配任务结构的那一行"**。把强一致的黑板塞进一对一会话任务，是过度工程；把消息传递硬扛十人协作的状态合并，是迟早崩盘。 ## 深度拆解 ### 一、Hub-Spoke 编排器的"记忆瓶颈" 2026 年绝大多数团队的第一套多智能体系统长这样：一个 lead agent 加 N 个 subagent，lead 既负责拆任务、又负责把每个 subagent 的结果读进自己的上下文再合并。这正是 Anthropic 工程团队在 *How we built our multi-agent research system* 里描述的形态——当任务是"广度优先的全面研究"时，并行 subagent 能把单线索串行研究的时间大幅压缩。 但这个架构的命门是 lead agent 的上下文窗口。每个 subagent 回来的结果都要塞进 lead 的 context，N 一旦超过 5–8 个，lead 就开始丢失早期 subagent 的结论，合并质量断崖式下滑。**这本质上是一个"记忆中枢单点过载"问题**：lead agent 既是编排器又是状态库，两个角色争抢同一份 context 预算。破局的关键不是换更大的模型，而是把"编排"和"状态"拆开——lead 只保留指针（"任务 A 的结果在产物文件 result_a.md"），不保留内容。这就是为什么 Anthropic 自己也强调 subagent 应该返回"简洁的结构化摘要"而非原始长文。 ### 二、共享黑板（Blackboard）的 2026 复兴 黑板模型是 1980 年代 Hearsay-II 语音理解系统的遗产：多个独立的"知识源"向一块公共黑板读写，由调度器决定谁何时激活。它在单体内核时代被冷落了三十年，却在 2026 年的多智能体场景里复活——因为 LLM agent 天然就是异构、异步、松耦合的"知识源"。 LangGraph 的 `StateGraph` 是当前最成熟的黑板实现：用一个 `TypedDict` 定义共享状态结构，每个节点（agent）只读写自己关心的字段，并发写冲突用 `add_messages` 这类 reducer 显式合并。 ```python from typing import TypedDict, Annotated from langgraph.graph import StateGraph class Board(TypedDict): facts: Annotated[list[str], lambda a, b: a + b] # reducer: 追加而非覆盖 claims: list[str] verdict: str | None g = StateGraph(Board) g.add_node("researcher", research_fn) # 只写 facts g.add_node("analyst", analyze_fn) # 读 facts，写 claims g.add_node("judge", judge_fn) # 读 claims，写 verdict ``` 黑板的威力在于**隐式协作**：analyst 不需要知道 researcher 是谁，它只盯黑板。代价同样明显——并发写需要 reducer 仲裁，字段一多，状态 schema 会膨胀成无人维护的怪兽；任何 agent 都能污染黑板，缺乏所有权边界。黑板适合"任务边界清晰、字段稳定、读多写少"的协作；一旦 agent 之间需要强时序耦合，黑板就退化成低效的全局锁。 ### 三、消息传递的"上下文重建税" 会话派（AutoGen 的 GroupChat、CrewAI 的任务交接）走的是另一条路：agent 之间不共享任何显式状态，所有信息靠对话历史传播。每次一个 agent 接力，它都得从完整的对话历史里**重建上下文**——重新理解前面发生过什么。 这在两个人类对话时是自然的，但在 agent 之间是一种隐性税。研究表明，传话链每多一级，关键信息的保真度衰减显著，到第十级常常只剩六成左右。原因正是上下文重建：每个中间 agent 都是"翻译官"，它先压缩再复述，压缩的依据是它自己当前 context 里的权重分配，而非原始信息的重要性。**消息传递的协作效率低，但隔离性和扩展性最好**——加一个新 agent 只需让它加入对话，不需要改任何全局 schema。对于"流水线式、每段责任清晰、不回头"的任务，会话派是最省事的；对于需要反复回看中间产物、多 agent 动态援引的任务，会话派会让你付一遍又一遍的重建税。 ### 四、外部化产物：Agent 即微服务 如果从分布式系统而非对话系统的视角看，多智能体协作的最稳形态是把每个 agent 当成一个**微服务**：它不直接和别人共享内存，只通过对外发布的产物（文件、对象、API 返回）来通信。Claude Code 的多 agent 协作、以及大量"agent 即 worker"的实战系统，本质都是这条路——agent 把结果写到工作目录里的某个文件，下一个 agent 读文件继续，文件名就是契约。 ```text # 工作目录即黑板，文件即契约 ./runs/2026-06-27/research.md ← researcher 产出 ./runs/2026-06-27/analysis.md ← analyst 读 research.md，产出 ./runs/2026-06-27/verdict.md ← judge 读 analysis.md，产出 ``` 这条路的一致性是"最终一致"——没有强锁，但天然可重放（每个产物都有时间戳和来源）、天然可审计（谁产出了什么一目了然）、天然可隔离（一个 agent 崩了不污染别人的内存）。代价是延迟：每次跨 agent 都要落盘再加载，串行链路下延迟叠加。它最适合**有副作用、要持久化、人要回看**的协作（编码、研究、报告生成），最不适合**纯推理、低延迟、不落盘**的实时对话。 ### 五、层级记忆：短期、长期、共享的三层切分 更工程化的做法是把记忆切成三层：每个 agent 自己的短期会话上下文（私房，谁也不给）、跨 session 的长期向量记忆（每个 agent 一份，回忆自己的历史）、以及专门的共享层（团队级知识，所有 agent 可读但通常只读）。Letta / MemGPT 这一派的核心洞察是：**别让所有东西都堆进一个 context**，而是用分页（core memory vs archival memory）把热数据留在 context、冷数据外置到向量库。 分层的好处是显著降低了单 agent 的 context 压力，坏处是引入了"什么该上提、什么该下沉"的检索决策——而这个决策本身又是一个易错的 LLM 调用。共享层的语义检索还会带来召回噪声：agent A 写入的事实，可能因为嵌入相近被 agent B 在不相关的语境下召回，造成"记忆串味"。这是 2026 年多智能体系统一个被低估的故障面。 ### 六、一致性 vs 隔离性：多智能体的 CAP 取舍 把多智能体记忆当作分布式数据库来看，问题立刻清晰：你不可能同时拿到强一致性、高可用、分区容忍。多 agent 是天然分区的（每个 agent 一个 context，等价于网络分区），所以真实的选择是 **CP 还是 AP**： - **CP 路线（强一致）**：用黑板 + 锁/reducer，保证所有 agent 读到同一份真相。代价是写放大、吞吐受限，一个慢 agent 拖累全局。 - **AP 路线（最终一致）**：用消息传递或外部产物，各 agent 先用自己的本地视图，事后合并。代价是临时不一致、合并冲突。 绝大多数 LLM 协作任务**容忍最终一致**——因为 agent 输出本就有概率性，强一致带来的复杂度远超收益。真正需要强一致的，是少数有真金白银副作用的环节（同一账户的并发扣款、同一文件的并发写），而这些恰恰应该被锁进确定性工具，而不是交给 LLM 协调。**一个反复被验证的经验法则：把一致性问题从"agent 之间"挪到"工具内部"**——让 agent 调用一个线程安全的服务，而不是让两个 agent 自己商量谁先写。 ```mermaid flowchart LR subgraph CP["强一致路线 · 黑板+锁"] A1[Agent A] --写--> B[(Blackboard\nreducer仲裁)] A2[Agent B] --写--> B B --读--> A3[Agent C] end subgraph AP["最终一致路线 · 产物+合并"] C1[Agent A] --产物--> P1[(a.md)] C2[Agent B] --产物--> P2[(b.md)] M[Merger] --读--> P1 M --读--> P2 end B -.慢节点拖全局.-> CP M -.事后合并/冲突.-> AP ``` ## 选型硬规则 **第一条：任务结构决定记忆架构，而非反过来。** 流水线（研究→分析→写作）用外部产物，最省心、可审计；发散式协作（头脑风暴、辩论）用共享黑板，隐式协作最高效；松耦合并行（同一问题多 agent 各做一份再投票）用消息传递或独立产物，隔离性最好。先画任务依赖图（链？树？环？），再选记忆栈。 **第二条：能外置就别内联。** 凡是有持久化价值、需要回看、可能被多个 agent 引用的中间结果，一律写成文件而非塞进对话历史。文件是天然的事务边界和审计日志，对话历史不是。 **第三条：把一致性问题锁进工具，不要交给 agent。** 涉及共享可变状态的并发，用线程安全的服务承载；让 agent 调用服务，而不是让 agent 之间互相谦让。这条能消掉一大半"两个 agent 写冲突"的诡异 bug。 **第四条：lead agent 只拿指针，不拿内容。** 编排器是路由器不是数据库，它的 context 预算要留给"下一步调度谁"，而不是装满每个 subagent 的返回。subagent 返回结构化摘要 + 产物路径，而非原文。 **第五条：监控的不是 token，而是"重建次数"。** 多智能体系统真正烧钱的是反复重建上下文。如果一个事实在一次任务里被三个 agent 各自重新推导了一遍，那是一个比 token 更值得修的浪费。 ## 归并判断 到 2026 年中，多智能体记忆架构正在收敛向一个稳定的二分：**需要强一致、字段稳定的，走黑板（LangGraph State 是事实标准）；需要隔离、可审计、可重放的，走外部产物（agent 即微服务）**。会话派仍是最易上手的入门形态，但一旦任务复杂度上来，几乎都会迁移到这两条路上之一。向量共享层则作为两者的通用"长期记忆后端"横切存在。选型的关键不是哪个框架 Star 多，而是你画出来的任务依赖图，更像一条链、一棵树，还是一个环。 ## 参考来源 1. [AI Agent Memory Architectures for Multi-Agent Systems — Zylos Research](https://zylos.ai/research/2026-03-09-multi-agent-memory-architectures-shared-isolated-hierarchical/) — 提出"记忆是多智能体核心未解问题"，给出 shared/isolated/hierarchical 三类架构与 Gartner 1,445% 增长数据 2. [Multi-Agent AI Architecture in Production: Patterns, Frameworks & Observability (2026) — MACGPU](https://macgpu.com/en/blog/2026-0622-multi-agent-ai-architecture-production-guide.html) — 六种编排拓扑、MCP+A2A 集成与可观测性，含并行 vs 串行耗时对比 3. [Multi-Agent Memory from a Computer Architecture Perspective — ACM SIGARCH / arXiv](https://www.sigarch.org/multi-agent-memory-from-a-computer-architecture-perspective-visions-and-challenges-ahead/) — 将多智能体记忆映射为计算机体系结构问题，提出一致性/隔离性框架 4. [Agent Memory Sharing Strategies: Blackboard, Message Passing, and Vector Stores — CallSphere](https://callsphere.ai/blog/agent-memory-sharing-strategies-blackboard-message-passing-vector-stores) — 三种基础记忆共享架构的工程权衡对比 5. [CrewAI vs LangGraph vs AutoGen: Choosing the Right Multi-Agent AI Architecture — DataCamp](https://www.datacamp.com/tutorial/crewai-vs-langgraph-vs-autogen) — 三大框架如何承载共享状态与工作流，附代码与选型指引 > [!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 等场景全覆盖。