Agent开发 3.2 - 通信与数据交互机制：消息传递与共享事实黑板的架构权衡

在多智能体系统（Multi-Agent Systems）中，当业务逻辑被拆解为多个独立专业角色的 Agent 后，开发者面临的第一个底层工程难题便是：智能体之间究竟该如何进行数据与状态交互？

很多开发者在刚接触多智能体时，最直观的实现方式往往是“传话筒模式”——每个智能体执行完毕后，将整段对话历史连同自身输出原封不动地打包，传递给下一个智能体。然而在真实业务中，这种直觉设计会迅速引发上下文爆炸与数据踩踏。

智能体间的通信机制绝不是简单的“发消息还是读变量”，它直接决定了整个系统的 Token 成本上限、决策精度与并发吞吐量。

本文将从三个正交维度建立多智能体通信的技术坐标系，全面解构工业界 10 种主流通信方案，深入剖析并发更新黑板的 6 级工程化防御阶梯，并给出生产环境下的最佳组合架构。

终结混乱：多智能体通信的三维正交坐标系#

市面上充斥着各种各样的名词：Handoff、Blackboard、Pub-Sub、MCP、A2A、Agent-as-Tool 等。若不理清本质，极易陷入概念混乱。

实际上，所有多智能体通信机制都可以抽象拆解为三个互相正交的独立维度：

flowchart TD
    subgraph Dimension1["维度一: 传什么 (Payload Form)"]
        D1_1["全量历史 (Raw History)"]
        D1_2["自然语言摘要 (Summary)"]
        D1_3["结构化结论 (Structured JSON)"]
        D1_4["轻量引用 / ID (Artifact Reference)"]
    end

    subgraph Dimension2["维度二: 谁和谁通信 (Topology)"]
        D2_1["链式顺序传递 (Chain)"]
        D2_2["星型中心调度 (Orchestrator)"]
        D2_3["网状对等通信 (Mesh / P2P)"]
        D2_4["广播订阅总线 (Pub-Sub)"]
    end

    subgraph Dimension3["维度三: 状态放哪 (State Location)"]
        D3_1["状态随消息流动 (Message Passing)"]
        D3_2["状态集中于外部共享存储 (Shared State / Blackboard)"]
        D3_3["状态下沉至对象存储与文件系统 (Artifact Store)"]
    end

传什么（Payload Form）：决定了单次交互的 Token 开销与信息保真度；
谁和谁通信（Topology）：决定了系统的控制流自由度、依赖复杂度与收敛稳定性；
状态放哪（State Location）：决定了数据的一致性模型、容灾能力与解耦程度。

后面所有工业级通信方案，本质上都是这三个维度的不同组合。

工业界 10 大通信与状态传递方案全景#

根据上述三维正交坐标系，我们将业界主流方案划分为三大阵营：

flowchart LR
    subgraph CatA["A. 消息传递型 (状态随消息走)"]
        A1["1. 全量传话筒 (反面基线)"]
        A2["2. 结构化 Handoff (精简交接)"]
        A3["3. 摘要压缩传递 (渐进有损)"]
    end

    subgraph CatB["B. 共享状态型 (状态在 Agent 外)"]
        B1["4. 共享 State / Blackboard (黑板模式)"]
        B2["5. 外部存储 + 引用传递 (Artifact 模式)"]
        B3["6. 共享长期记忆层 (Memory Store)"]
    end

    subgraph CatC["C. 拓扑与控制流型 (系统组织形态)"]
        C1["7. Orchestrator-Worker (中心调度)"]
        C2["8. Agent-as-Tool (函数级最小耦合)"]
        C3["9. 事件/消息总线 (Pub-Sub 异步)"]
        C4["10. 跨系统互联协议 (MCP / A2A)"]
    end

A. 消息传递型（状态跟着消息走）#

1. 全量传话筒（反面基线）#

机制：上游把所有原始对话消息、工具报错堆栈与中间推演打包追加，塞给下游。
致命缺陷：
- Token 二次方灾难：若链路有 $N$ 个 Agent，全链路输入总量呈 $\sum_{k=1}^N \sum_{i=1}^{k-1} M_i \approx O(N^2)$ 暴涨；
- 注意力被噪声稀释：大模型陷入“迷失在中间”（Lost in the Middle）困境，无法从上万字过程垃圾中提炼关键结论；
- 伪多智能体：本质只是在同一个超大单体上下文里反复切换角色 Prompt。
适用场景：仅限 2~3 步的单向原型验证，生产环境严禁使用。

2. 结构化 Handoff（精简交接）#

概念解析：Handoff 即任务交接协议，本质是上游完成自身阶段任务后，将下游所需输入提炼为严格符合 Schema 规范的结构化数据直接转交。
典型实现：OpenAI Agents SDK 的 Handoff 机制。
优势：上下文用完即焚，输入极度聚焦，具备强类型校验保障。
代价：上游必须拥有完备的交付理解，一旦漏传某一关键参数，下游在隔离的上下文中无法自行补救。

3. 摘要/压缩传递（Summarized Message Passing）#

机制：上游推演完毕后，调用总结 Prompt 或专门的 Summarizer 模块将长文本压缩为要点再传递。
代价：自然语言摘要是“有损压缩”，在多跳传递中会引发“传话游戏效应”（Telephone Game Effect，指信息在层层口头转述中产生严重失真与语义漂移）。核心数字、硬性约束绝不能只靠摘要传递。

B. 共享状态型（状态放在 Agent 外面）#

4. 共享事实黑板（Shared State / Blackboard 模式）#

概念解析：黑板模式源自经典分布式系统架构。它在系统中央维护一个全局受控的状态容器（State），作为系统的 SSOT（Single Source of Truth，单一真实数据源，即全局状态只认一份权威数据，所有模块读写均基于该统一标准）。
典型实现：LangGraph 的 StateGraph。
核心收益：彻底终结“肉身路由器”。当下游 Agent D 既要依赖 Agent A 的原始需求，又要依赖 Agent B 和 C 的分析结论时，A、B、C 只需要把数据写在黑板上，D 自行摘取。彻底解耦通信拓扑，天然解决菱形依赖（DAG，有向无环图）。

5. 外部存储 + 引用传递（Artifact 模式，大产物终极解）#

概念解析：Artifact 模式是指将体积庞大的推演中间产物（如爬取的数十页网页原文、分析长表、编译日志、完整代码库）写入外部存储（本地文件系统、数据库或对象存储），在智能体通信链路中仅传递该产物的轻量引用（路径、ID、哈希值）与 100 字摘要。
典型实现：Anthropic 官方研究级多智能体系统、Claude Code 的上下文管理。
核心价值：
- Token 消耗从数十万降至几十：主干流程保持极致轻量；
- 全保真无损：下游如果需要核验原始细节，通过 ID 精准捞取，杜绝大模型总结带来的信息蒸发。

6. 共享记忆层（Shared Memory）#

机制：通过向量数据库、键值存储沉淀历史跨会话经验与用户画像。Agent 并非被动接收通知，而是基于语义相似度主动检索（RAG 模式）。

C. 拓扑与控制流型（系统组织形态）#

7. Orchestrator-Worker（中心编排 + 上下文隔离）#

机制：由中央主控 Agent 统一拆解任务并分发给专业 Worker，Worker 在完全独立的子上下文中执行，只将最终交付物回传主控。
典型实现：Claude Code 的 Subagent 架构。有效防止子任务内多轮工具调用的细碎噪声污染主干。

8. Agent-as-Tool（函数级最小耦合）#

机制：将一个子 Agent 彻底封装为一个普通的外部函数（Tool）。调用方在主循环中完全感知不到对方是一个智能体，仅遵循输入输出规范。适合翻译、SQL 生成、独立代码审查等边界高度明确的能力。

9. 事件/消息总线（Pub-Sub 异步总线）#

机制：基于主题（Topic）进行发布-订阅解耦。Agent 之间互不感知，适合大规模、长生命周期的异步网状系统，但系统因果追踪与调试排错复杂度极高。

10. 跨系统互联协议（MCP / A2A）#

MCP（Model Context Protocol）：解决智能体与外部工具、本地数据源的标准化安全连接；
A2A（Agent-to-Agent Protocol）：解决跨越组织边界、跨不同厂商框架的异构智能体间的任务委派与协议协商。

方案选型综合对照矩阵#

方案名称	Token 成本	并发友好度	状态可追溯性	实现复杂度	典型适用场景
全量传话筒	极高 ($O(N^2)$)	极差 (互相覆盖)	弱 (杂乱无章)	极低	2~3 步原型验证
结构化 Handoff	低	一般	中	低	线性流程、客服分流转接
摘要压缩传递	中 (有损)	一般	弱 (传话走样)	低	长程会话历史折叠
共享 State (黑板)	低	好 (需配并发防线)	强	中	复杂业务工作流、DAG 聚合编排
外部存储 + 引用 (Artifact)	最低	极好	极强 (无损原件)	中高	自动化研报、大规模代码生成、网页爬虫
共享长期记忆	低	良好	中	中高	跨会话偏好记忆、企业知识沉淀
Orchestrator-Worker	低	良好	中	中	主任务分解、上下文物理隔离
Agent-as-Tool	低	良好	弱 (工具粒度)	低	专有计算、翻译、结构化提取
Pub-Sub 事件总线	低	最好	需额外链路追踪	高	大规模分布式异构协同
跨系统协议 (A2A/MCP)	受底层决定	良好	强 (规范化)	高	跨厂商、跨组织智能体互操作

共享黑板的并发一致性六级阶梯#

当系统选择以“共享黑板（Shared State）”作为核心数据底座时，在并发分支下必须直面整体读改写（Read-Modify-Write）导致丢失更新的工程风险。

业界沉淀了 6 级由易到难、可叠加的工程化防护阶梯：

flowchart TD
    L1["1. 分区所有权 (Field Ownership)"] -->|"消除 80% 伪冲突"| L2["2. Reducer 增量合并 + Superstep 屏障"]
    L2 -->|"保障因果确定性"| L3["3. 事件溯源 + 单写者串行化 (Event Sourcing)"]
    L3 -->|"提供全链路审计回放"| L4["4. 乐观并发控制 (细粒度 CAS / 字段版本号)"]
    L4 -->|"低频修改防御"| L5["5. 悲观锁 / 分布式临界区 (不可逆扣款/库存)"]
    L5 -->|"极端资源控制"| L6["6. CRDT 无冲突复制 (多端实时富文本协同)"]

1. 分区所有权（Field Ownership / 命名空间隔离，首选底座）#

核心逻辑：将黑板划分为严格独立的命名空间，保证每个 key 有且仅有一个合法的写入者（Single Writer）。
工程效果：机票 Agent 专写 flight/，酒店 Agent 专写 hotel/，账务 Agent 专写 budget/。从 Schema 层直接根除并发写冲突，0 锁开销。

2. 增量 Reducer + Superstep 屏障（BSP 模型，现代框架标准解）#

概念解析：BSP（Bulk Synchronous Parallel，大体同步并行模型）是一种并行计算架构范式，它将执行划分为若干轮次（Superstep）。在同一轮次中，各计算单元独立推演；推演结束后在同步屏障（Barrier）处集中合并状态。
核心机制：
- 严禁在持锁期间调用大语言模型：大模型调用耗时数秒至数十秒，期间黑板保持只读快照；
- 只产出增量（Delta）：Agent 不覆写整体，只返回增量声明；
- 屏障合并：调度器在屏障处调用满足交换律的纯函数 Reducer（归约合并函数）完成毫秒级原子打补丁。结果与 Agent 执行耗时波动完全解耦。

3. 事件溯源 + 单写者串行化（Event Sourcing）#

核心机制：Agent 永远不直接修改黑板状态，而是向追加日志（Append-only Event Log）提交不可变事件。由单线程状态管理器（State Manager）顺序消费事件并应用校验规则。
工程价值：为具备随机性的大模型系统提供千金难买的全链路可观测、责任审计与断点回滚重试能力。

4. 乐观并发控制（细粒度 CAS / 字段级版本号）#

设计关键：版本号必须细化至具体字段（Field-level Versioning）。严禁在整块黑板上设置全局单一版本号，否则 Agent A 修改字段 1 推进全局版本后，会无辜击中 Agent B 并发修改字段 2 的请求，引发大量假冲突。

5. 悲观锁 / 分布式临界区#

红线约束：绝不能在持锁期间调用 LLM。仅限用于微秒级涉及真金白银转账、稀缺考位抢占等不可逆操作。

6. CRDT（无冲突复制数据类型）#

适用场景：仅用于多 Agent 与人类实时共同编辑同一份在线文档等长文本协同场景，常规业务状态不建议引入。

内容层防御：大模型特有的语义冲突治理#

数据层即使做到了完全没有写冲突，大模型在内容层依然可能产出严重互斥的事实冲突。

治理语义冲突必须构筑三道防线：

窄接口工具封装（Narrow Actions）：绝不暴露通用覆写接口，仅暴露 record_flight_booking(...) 等具体语义工具；

凭据链元数据（Provenance Metadata）：写入黑板的关键结论必须强制封装元数据：

interface FactWithProvenance<T> {
  value: T;
  sourceRef: string;       // 官网原始链接或外部文件路径
  evidenceQuote: string;   // 原始网页引用片段
  confidence: number;      // 模型置信度
  timestamp: number;       // 写入时间戳
}

提案-仲裁机制（Proposal & Reviewer）：当出现事实矛盾时，状态打上待仲裁标签，交由专门的 Reviewer Agent 或触发人工协同（HITL，Human-In-The-Loop，指在程序执行遇到高风险分支时停下来等人类输入或审批）裁决。

生产级代码复现：支持 Artifact 引用与 Superstep 的黑板内核#

以下采用纯 TypeScript 实现一个集成了命名空间隔离、Artifact 外部存储引用与 Superstep 屏障合并的工业级黑板运行内核：

// 1. 定义黑板状态：结构化数据与外部 Artifact 引用解耦
export interface TravelPlanningState {
  destination: string;
  totalBudget: number;
  // 仅存放轻量结构化索引与外部大产物引用路径 (Artifact Ref)
  attractions: Array<{ name: string; cost: number; artifactPath: string }>;
  hotels: Array<{ name: string; cost: number; artifactPath: string }>;
  spentBudget: number;
}

// 2. 增量补丁接口：Agent 仅产出本阶段增量
export interface PlanDelta {
  newAttractions?: Array<{ name: string; cost: number; artifactPath: string }>;
  newHotels?: Array<{ name: string; cost: number; artifactPath: string }>;
  addedCost?: number;
}

// 3. 纯函数 Reducer：处理增量合并，天然具备交换律
export function travelPlanReducer(
  prevState: TravelPlanningState,
  deltas: PlanDelta[]
): TravelPlanningState {
  const nextState: TravelPlanningState = structuredClone(prevState);

  for (const delta of deltas) {
    if (delta.newAttractions) nextState.attractions.push(...delta.newAttractions);
    if (delta.newHotels) nextState.hotels.push(...delta.newHotels);
    if (delta.addedCost) nextState.spentBudget += delta.addedCost;
  }

  return nextState;
}

// 4. 并发 Superstep 调度器：彻底消除并发写踩踏
export class SuperstepBlackboardEngine {
  private state: TravelPlanningState;

  constructor(initial: TravelPlanningState) {
    this.state = structuredClone(initial);
  }

  public getSnapshot(): Readonly<TravelPlanningState> {
    return structuredClone(this.state);
  }

  /**
   * 并发执行一组子 Agent 并在同步屏障处原子合并
   */
  public async executeSuperstep(
    agents: Array<(snapshot: Readonly<TravelPlanningState>) => Promise<PlanDelta>>
  ): Promise<Readonly<TravelPlanningState>> {
    const snapshot = this.getSnapshot();

    // 并发推演：各自在沙箱推演，大产物写磁盘，仅向内存回传 Delta
    const deltas: PlanDelta[] = await Promise.all(
      agents.map(async (agentFn) => {
        try {
          return await agentFn(snapshot);
        } catch (error) {
          console.error("Agent 执行异常，增量降级置空:", error);
          return {};
        }
      })
    );

    // 屏障汇聚：原子执行纯函数打补丁
    this.state = travelPlanReducer(this.state, deltas);
    return this.getSnapshot();
  }
}

场景走一遍：生产级黄金组合拳#

在实际工程中，最优方案往往不是单一流派，而是组合装：Orchestrator（控制流程）+ 共享 State（存储结构化结论）+ Artifact 引用传递（承载大体积素材）。

以经典场景“帮我做一份 3 天东京亲子游规划，预算 2 万”为例，对比两种设计的高下：

sequenceDiagram
    autonumber
    actor User as 用户
    participant Orch as 调度器 (Orchestrator)
    participant State as 共享事实黑板 (State)
    participant Disk as 外部存储 (Artifacts)
    participant A1 as 景点 Agent
    participant A2 as 酒店 Agent
    participant Final as 整合 Agent

    User->>Orch: 提出规划需求
    Orch->>State: 初始化写入学生与预算画像 (100 Tokens)
    
    par 并发执行 Superstep 阶段
        Orch->>A1: 下发画像快照
        A1->>Disk: 网页检索 30k 原始图文，存入 /artifacts/spots.json
        A1-->>Orch: 回传增量 (仅含简述与文件引用, 500 Tokens)
    and
        Orch->>A2: 下发画像快照
        A2->>Disk: 检索 20k 酒店比价数据，存入 /artifacts/hotels.json
        A2-->>Orch: 回传增量 (仅含房型与文件引用, 500 Tokens)
    end

    Note over Orch,State: 屏障处 Reducer 原子合并状态
    Orch->>State: 写入 attractions 与 hotels 列表

    Orch->>Final: 下发汇聚后的轻量 State (约 2k Tokens)
    Final->>Disk: 按需读取 /artifacts/ 验证儿童友好细节
    Final-->>User: 产出精确行程总报告

传话筒模式的崩溃链路#

需求 Agent 产出画像（2k Tokens），塞给景点 Agent；
景点 Agent 调 8 次搜索，抓了 30k 网页原文，打包带着塞给酒店 Agent；
酒店 Agent 叠加 20k 报价，整段 52k 的巨大文本塞给整合 Agent；
整合 Agent 面对 52k 上下文，发生严重的注意力稀释，把最初“必须适合儿童”的约束遗漏，且单次调用成本高昂。

黄金组合方案的优雅收敛#

需求 Agent 将结构化画像 { days: 3, budget: 20000, traveler: "亲子" } 写入黑板；
调度器并发拉起景点 Agent 与酒店 Agent，各自基于轻量快照推演；
景点 Agent 查到 30k 网页原文，**原件直接写入磁盘 /artifacts/spots.json**，仅向黑板写入结构化要点与路径引用 { name, cost, artifactPath }；
酒店 Agent 同理操作。两者写入不同字段，互不干扰；
调度器在屏障处一次性合并；整合 Agent 接收到的黑板上下文仅仅 2k Tokens，注意力高度聚焦；如需查验特定景点的推车通道政策，按 artifactPath 针对性查阅原件。

全链路上下文从 50k+ 骤降至 3k 左右，成本降低 90% 以上，且所有关键结论具备完备的凭据链追溯能力。

工程实践规范#

传结论，不传过程：默认只传递结构化结果，排错思考过程留在 Agent 沙箱内部；
严格定义 Schema：每个字段必须有明确的写入者权限（Owner）和类型校验，严禁让 Agent 自由倾倒非结构化大文本；
并发写入必须配套合并策略：在架构设计初期就明确使用 Reducer、分区还是版本号，杜绝后写覆盖先写；
大对象强制走引用（Artifact）：超过 2k Tokens 的原文抓取、数据表与代码库，统一落盘或进对象存储，上下文中仅流转引用 ID；
核心事实禁止裸存在自然语言摘要中：预算、硬性门槛、日期这类硬指标，必须单独抽成结构化字段，防止摘要有损失真；
强制保留溯源信息（Provenance）：每条核心事实附带 sourceRef、产出角色与时间戳，确保错误可排查；
最小上下文可见原则：Agent 只能查阅完成自身任务所必需的最简切片数据，既降低 Token 开销，又防止注意力分散；
建立通信可观测性：在调试与生产环境中监控每次交互的 Token 体积与时延，及时定位恶性膨胀的通信链路。

多智能体通信机制绝非简单的技术堆砌，而是对数据流向、状态边界与大模型注意力分配的深思熟虑。掌握三维正交坐标系，以“分区所有权 + Reducer 屏障”治理并发，用“Artifact 引用”解耦大产物，就能打造出可控、经济且工程化高的工业级多智能体系统。