<!-- title: 多Agent六层编排拓扑：从调度到共识的实测 -->

## 概述

2026年中期，多Agent系统已从实验原型全面进入生产环境，但编排架构的选择仍是决定项目成败的第一变量。本文实测六种主流编排拓扑——主管-工人（Supervisor-Worker）、层级委派（Hierarchical Delegation）、流水线（Pipeline）、黑板共享（Blackboard）、蜂群共识（Swarm Consensus）、DAG工作流（DAG Workflow）——在延迟、状态一致性、容错性和运维复杂度四个维度上的真实表现。同时覆盖A2A协议1.0发布后的跨框架互操作新格局、Microsoft Conductor开源带来的确定性编排范式，以及多Agent共享状态并发写入这一被严重低估的生产杀手。结论：没有一种拓扑万能，但2026年的生产系统正在收敛到"DAG骨架+黑板状态+事件驱动恢复"的三层混合架构。

---

## 一、六种编排拓扑全景对比

| 维度 | Supervisor-Worker | Hierarchical | Pipeline | Blackboard | Swarm Consensus | DAG Workflow |
|------|-------------------|-------------|----------|------------|-----------------|-------------|
| **调度模型** | 中心路由器分发 | 多级主管递归委派 | 线性/分支顺序执行 | 共享空间+控制循环 | 去中心化投票/辩论 | 声明式依赖图 |
| **状态管理** | 主管持有全局状态 | 每层主管缓存子树 | 流水传递中间产物 | 黑板集中存储 | 各Agent独立+协议同步 | 图节点输出+检查点 |
| **瓶颈风险** | 主管过载单点 | 上层主管阻塞 | 慢节点拖累全链 | 控制循环竞争 | 共识轮次爆炸 | 编译验证开销 |
| **容错机制** | 主管重试/切换 | 层级降级回退 | 断点续传 | 回滚黑板版本 | 少数派容忍 | 节点级重试 |
| **适用规模** | 3-8 Agent | 5-20 Agent | 2-6 Agent | 4-15 Agent | 5-50+ Agent | 3-30 Agent |
| **上手难度** | ★★☆ | ★★★ | ★☆☆ | ★★★★ | ★★★★ | ★★★ |
| **生产就绪度** | 高 | 中高 | 高 | 中 | 低中 | 高 |

### 框架映射

| 拓扑 | LangGraph | CrewAI | AutoGen | OpenAI Agents | Google ADK |
|------|-----------|--------|---------|---------------|------------|
| Supervisor | ✅ 原生支持 | ✅ 原生支持 | ✅ GroupChat | ✅ Runner | ✅ Agent.transfer() |
| Hierarchical | ✅ 子图嵌套 | ⚠️ 有限 | ✅ NestedChat | ❌ | ⚠️ 有限 |
| Pipeline | ✅ 线性图 | ✅ Sequential | ✅ 顺序对话 | ✅ Handoff链 | ✅ 流式Agent |
| Blackboard | ⚠️ 需自建 | ⚠️ 需自建 | ⚠️ 需自建 | ❌ | ❌ |
| Swarm | ⚠️ 需自建 | ❌ | ✅ Swarm模式 | ✅ Swarm | ✅ Loop Agent |
| DAG | ✅ 原生核心 | ⚠️ 流程编排 | ⚠️ 需封装 | ❌ | ⚠️ 有限 |

---

## 二、深度分析六种拓扑

### 2.1 主管-工人（Supervisor-Worker）：生产使用率最高

**架构原理。** 一个中心Agent充当路由器，接收用户请求后判断应该分发给哪个专业Agent处理。工人Agent执行完毕后将结果返回主管，由主管决定下一步——继续分发、合成输出、或终止。这是2026年使用率最高的模式，Presenc AI的调研显示超过55%的生产多Agent系统采用此拓扑。

**核心代码（LangGraph实现）。**

```python
from langgraph.graph import StateGraph, MessagesState, START, END
from langgraph.types import Command

def supervisor(state: MessagesState) -> Command:
    """主管路由：分析最后一条消息，决定分发给谁"""
    last_msg = state["messages"][-1].content
    if "代码" in last_msg or "bug" in last_msg:
        return Command(goto="coder")
    elif "分析" in last_msg or "数据" in last_msg:
        return Command(goto="analyst")
    else:
        return Command(goto="responder")

builder = StateGraph(MessagesState)
builder.add_node("supervisor", supervisor)
builder.add_node("coder", coder_agent)
builder.add_node("analyst", analyst_agent)
builder.add_node("responder", responder_agent)
builder.add_edge(START, "supervisor")
builder.add_edge("coder", "supervisor")
builder.add_edge("analyst", "supervisor")
builder.add_edge("responder", END)
graph = builder.compile()
```

**优缺点。** 优势在于实现简单、状态集中、调试直观——你只需看主管的路由日志就能追踪完整链路。劣势是主管成为单点瓶颈：当Agent数量超过8个、并发请求超过20QPS时，主管的LLM推理延迟（通常500ms-2s）会堆积成显著的排队延迟。生产中的常见缓解策略是将路由决策从LLM调用降级为规则引擎或嵌入向量相似度匹配。

**训练营评估。** 这是入门多Agent的最低门槛，一个3小时的workshop足够覆盖从搭建到部署。变现潜力★★★☆。

### 2.2 层级委派（Hierarchical Delegation）：复杂任务拆解

**架构原理。** 在Supervisor基础上引入多级委派：顶层主管只做战略分解，将子任务委派给中层主管；中层主管进一步分解给自己的工人。典型的三层结构是"产品经理→技术负责人→开发者/测试员"。AutoGen的NestedChat和LangGraph的子图嵌套是2026年实现此模式的主流方式。

**关键挑战。** 层级越深，上下文损失越严重。第3层Agent接收到的指令可能已经经过了两次自然语言转述，原始需求的精确度下降约15-25%（基于Paiteq的实测数据）。解决方案是在每层委派时附带结构化的任务描述（JSON Schema），而非纯文本指令。

**适用场景。** 代码审查流水线（架构审查→安全审查→风格审查）、多步骤研究任务（主题选择→文献检索→论文起草→同行评审）。当任务自然分解为3层以上时，Hierarchical比扁平Supervisor节省30-40%的Token消耗。

### 2.3 流水线（Pipeline）：确定性最高

**架构原理。** Agent按固定顺序排列，前一个的输出作为后一个的输入。最简单的拓扑，也是确定性最高的——每个步骤的输入输出可完全预测。2026年新增的变体是条件分支流水线：在特定节点根据中间结果选择不同的下游路径。

**核心代码（CrewAI Sequential）。**

```python
from crewai import Agent, Task, Crew, Process

researcher = Agent(role="Researcher", goal="Gather information",
                   backstory="Expert researcher", llm="gpt-4.1")
writer = Agent(role="Writer", goal="Write article",
               backstory="Professional writer", llm="gpt-4.1")
editor = Agent(role="Editor", goal="Review and polish",
               backstory="Senior editor", llm="claude-sonnet-4-6")

research_task = Task(description="Research {topic}", agent=researcher,
                     expected_output="Research notes with sources")
write_task = Task(description="Write article from research",
                  agent=writer, expected_output="Draft article")
edit_task = Task(description="Edit and finalize", agent=editor,
                 expected_output="Final article")

crew = Crew(agents=[researcher, writer, editor],
            tasks=[research_task, write_task, edit_task],
            process=Process.sequential)
result = crew.kickoff(inputs={"topic": "Multi-Agent Architecture 2026"})
```

**优缺点。** 优势是零编排复杂度、完美的可观测性、最容易做断点续传。劣势是无法处理需要迭代/反馈的任务——如果Editor发现Researcher的信息不足，Pipeline无法回溯。生产中通常用"带反馈环的Pipeline"变体解决：设置最大重试次数，失败时回退到指定节点。

### 2.4 黑板共享（Blackboard）：2026年复兴的经典模式

**架构原理。** 源自1980年代HEARSAY-II语音识别系统的经典架构，2026年在LLM多Agent领域强势回归。核心思想是：多个专家Agent围绕一块共享的"黑板"（结构化状态空间）工作，每个Agent独立读取黑板内容、贡献自己的专业知识、更新黑板状态。一个控制组件（Controller）决定下一个该激活哪个Agent。

**为什么2026年复兴？** 因为其他拓扑在处理"需要多Agent协同构建同一产物"的场景时都力不从心。Supervisor无法让Agent真正并行协作；Pipeline是串行的；Swarm缺乏结构化协调。黑板模式天然支持并行写入、增量构建、冲突检测。

**三组件详解。**

```python
# 1. 黑板：结构化共享状态空间
class Blackboard:
    def __init__(self):
        self.state = {}           # 全局状态字典
        self.history = []         # 版本历史，支持回滚
        self.lock = asyncio.Lock() # 并发写入锁
    
    async def write(self, agent_id: str, key: str, value: Any):
        async with self.lock:
            version = len(self.history)
            self.history.append({
                "version": version, "agent": agent_id,
                "key": key, "old_value": self.state.get(key),
                "new_value": value, "timestamp": time.time()
            })
            self.state[key] = value

# 2. 控制器：调度策略
class Controller:
    def __init__(self, agents, blackboard):
        self.agents = agents
        self.bb = blackboard
    
    async def run(self, max_iterations=20):
        for _ in range(max_iterations):
            # 评估每个Agent的贡献意愿
            contributions = []
            for agent in self.agents:
                score = await agent.evaluate(self.bb.state)
                contributions.append((score, agent))
            contributions.sort(reverse=True)
            
            if contributions[0][0] < THRESHOLD:
                break  # 没有Agent愿意贡献，结束
            
            best_agent = contributions[0][1]
            await best_agent.execute(self.bb)  # 执行并更新黑板

# 3. 专家Agent
class ExpertAgent:
    def __init__(self, specialty, llm):
        self.specialty = specialty
        self.llm = llm
    
    async def evaluate(self, state):
        """评估自己能否对当前状态做出有价值的贡献"""
        prompt = f"Given current state: {json.dumps(state)}, 
                  can you contribute as {self.specialty}? Score 0-1."
        return float(await self.llm.invoke(prompt))
```

**生产挑战。** 黑板模式的并发写入是最大的工程难题。AgentMarketCap的深度分析指出："多Agent系统通常不是因为模型出错而失败，而是因为两个Agent同时读取同一文件、各自独立编辑、然后竞相写回——没有任何错误抛出，一个Agent的工作静默消失。"乐观锁（Optimistic Locking）是2026年主流解决方案：每个Agent在写入时携带读取时的版本号，如果黑板已被其他Agent更新，则触发合并或重试。

### 2.5 蜂群共识（Swarm Consensus）：去中心化决策

**架构原理。** 没有中心调度器。Agent之间通过投票、辩论、或轮流发言达成共识。Zylos Research的分析指出，经典分布式共识协议（Paxos、Raft、PBFT）为确定性状态机设计，无法直接应用于LLM Agent——因为Agent是随机的、上下文敏感的、能够真正"讨论"的。2026年的共识模式已演化为三种变体：

- **多数投票（Majority Voting）：** 每个Agent独立给出答案，取多数。适合事实判断（"这段代码有bug吗？"）。
- **辩论制（Debate）：** Agent轮流发言反驳前一个Agent的观点，多轮后由裁判Agent综合。PolySwarm的研究部署了50个LLM角色并行评估，发现辩论制比单Agent准确率提升12-18%。
- **逐步共识（Stepwise Consensus）：** 每个决策步骤都要求所有Agent同意后才进入下一步。最慢但最可靠。

**代价。** Token消耗是Supervisor模式的3-7倍。5个Agent辩论3轮 = 至少15次LLM调用。生产中通常限制在3-5个Agent + 2-3轮辩论，并在共识已达成（>80%一致）时提前终止。

### 2.6 DAG工作流（DAG Workflow）：2026年确定性编排新星

**架构原理。** 将多Agent任务建模为有向无环图（DAG）。每个节点是一个Agent调用，边表示依赖关系。无依赖的节点并行执行，有依赖的节点按拓扑排序执行。2026年5月Microsoft开源了Conductor——一个MIT许可的CLI工具，标志着DAG编排从LangGraph生态走向框架无关。

**Microsoft Conductor核心设计。**

```yaml
# workflow.yaml - Conductor声明式DAG定义
name: code-review-pipeline
steps:
  - id: security-scan
    agent: security-reviewer
    prompt: "Review for security vulnerabilities: {code}"
    
  - id: style-check
    agent: style-reviewer
    prompt: "Check coding style: {code}"
    
  - id: perf-analysis
    agent: perf-reviewer
    prompt: "Analyze performance implications: {code}"
    
  - id: synthesize
    agent: lead-reviewer
    depends_on: [security-scan, style-check, perf-analysis]
    prompt: |
      Combine these reviews into actionable feedback:
      Security: {security-scan.output}
      Style: {style-check.output}
      Performance: {perf-analysis.output}
```

**关键优势。** 确定性执行：同样的DAG定义+同样的输入 = 同样的执行路径（Agent输出本身非确定性，但编排逻辑100%确定性）。这解决了"Agent编排不可复现"这一长期痛点——你可以精确复现任何一次执行的调度顺序、每步的输入输出、以及失败位置。

**Temporal vs LangGraph vs Inngest。** CallSphere的对比评测指出三者各有所长：LangGraph与LangChain生态深度绑定，上手最快但锁定最深；Temporal提供最强的持久化保障（工作流状态持久化到数据库，进程崩溃后自动恢复），但学习曲线陡峭；Inngest介于两者之间，事件驱动模型适合实时场景。2026年推荐：新项目用Conductor（如果只需DAG调度），已有LangChain项目用LangGraph，需要跨天持久化的长任务用Temporal。

---

## 三、多Agent架构总图

```mermaid
graph TB
    subgraph "多Agent编排六拓扑"
        SW["Supervisor-Worker<br/>中心路由分发"]
        HI["Hierarchical<br/>多级层级委派"]
        PL["Pipeline<br/>线性/分支流水线"]
        BB["Blackboard<br/>共享状态空间"]
        SC["Swarm Consensus<br/>去中心化投票/辩论"]
        DA["DAG Workflow<br/>声明式依赖图"]
    end

    subgraph "跨Agent通信协议"
        A2A["A2A Protocol v1.0<br/>Agent间互操作"]
        MCP["MCP<br/>Agent到工具/数据"]
    end

    subgraph "持久化与执行引擎"
        LG["LangGraph<br/>图状态机"]
        TM["Temporal<br/>持久工作流"]
        IN["Inngest<br/>事件驱动"]
        CD["Conductor<br/>确定性DAG CLI"]
    end

    subgraph "状态管理"
        OPT["乐观锁<br/>版本号并发控制"]
        CHK["检查点<br/>DAG节点级快照"]
        EMB["嵌入向量<br/>语义状态检索"]
    end

    SW --> A2A
    HI --> A2A
    BB --> MCP
    SC --> A2A
    DA --> CD
    DA --> TM

    SW --> OPT
    BB --> OPT
    DA --> CHK

    A2A -.->|"互补"| MCP
    LG --> CHK
    TM --> CHK
```

---

## 四、A2A协议1.0：跨框架互操作新格局

2026年6月，Google主导的Agent2Agent（A2A）协议正式发布1.0版本，移交Linux基金会管理。这是多Agent领域2026年最重要的事件之一。

### 核心机制

A2A定义了三个原语：

1. **Agent Card（Agent名片）：** JSON-LD格式的Agent自我描述文件，包含能力列表、接受的输入格式、认证方式。Agent通过发布名片实现"可被发现"。
2. **Task（任务）：** 客户端Agent向远程Agent发起的异步任务请求。任务有唯一ID、生命周期（submitted→working→completed/failed），支持长时运行。
3. **Message & Artifact（消息与产物）：** 任务执行过程中的结构化通信。Message是中间状态更新，Artifact是最终交付物。

**与MCP的关系。** A2A解决Agent-to-Agent通信，MCP解决Agent-to-Tool/Data通信。两者互补：一个Agent通过MCP访问数据库和API，通过A2A将子任务委派给另一个Agent。2026年的生产系统同时使用两者的比例已超过40%。

**实测体验。** A2A的HTTP+JSON-RPC传输层实现简单，一个基本的A2A Server用Python写不到100行。但Agent Card的语义描述和任务协商机制在实际跨框架调用时仍有摩擦——不同框架对"能力"的粒度定义不一致，需要人工对齐。预计到2026年底随着生态成熟，这一问题将显著缓解。

---

## 五、共享状态并发写入：被低估的生产杀手

AgentMarketCap的分析直击要害："当五个Agent共享一个代码库时，谁的状态是权威的？"这是多Agent系统在生产环境中面临的最棘手问题。

### 三种并发控制策略对比

| 策略 | 原理 | 适用场景 | 性能开销 |
|------|------|----------|----------|
| **悲观锁（Pessimistic Locking）** | 写入前获取排他锁 | Agent数量少（2-3个）、写入冲突频繁 | 高——锁等待导致Agent空闲 |
| **乐观锁（Optimistic Locking）** | 写入时比对版本号，冲突则重试 | Agent数量中等（4-10个）、冲突概率低 | 低——只在冲突时付出代价 |
| **事件溯源（Event Sourcing）** | 不直接修改状态，追加事件日志 | 需要完整审计轨迹的场景 | 中——重建状态需要回放日志 |

**2026年推荐。** 大多数多Agent系统使用乐观锁 + 最大重试次数。当冲突率超过30%时，说明Agent间的职责划分有问题——应该重新审视任务分解策略而非继续优化锁机制。

---

## 六、记忆架构：从孤岛到共享

Mem0的《2026 AI Agent记忆状态》报告指出，LoCoMo、LongMemEval、BEAM三大基准测试已成为记忆架构的标准评估工具。多Agent系统的记忆架构在2026年收敛为三种模式：

1. **完全隔离（Isolated）：** 每个Agent独立维护自己的记忆。最简单但Agent间无法共享学到的知识。
2. **完全共享（Shared）：** 所有Agent读写同一个记忆库。效率最高但隐私和干扰问题严重。
3. **层级混合（Hierarchical Hybrid）：** Agent拥有私有工作记忆 + 可选的共享长期记忆。Greennode的分析认为这是2026年最有效的模式。

Zylos Research的深度分析将多Agent记忆映射到计算机架构概念：隔离记忆类似分布式系统的本地缓存，共享记忆类似共享内存多处理器，层级混合类似L1/L2/L3缓存层次结构。这种映射有助于借用成熟的计算机架构理论来解决多Agent记忆挑战。

---

## 七、选型决策树

```mermaid
graph TD
    START[多Agent编排选型] --> Q1{任务是否需要<br/>迭代/反馈？}
    Q1 -->|否| Q2{步骤间是否有<br/>明确依赖关系？}
    Q1 -->|是| Q3{反馈需要几个<br/>Agent参与？}

    Q2 -->|线性顺序| PL[Pipeline<br/>CrewAI Sequential<br/>确定性最高]
    Q2 -->|有依赖图| DA[DAG Workflow<br/>LangGraph / Conductor<br/>并行执行无依赖节点]
    Q2 -->|需要路由| SW[Supervisor-Worker<br/>LangGraph / OpenAI Agents<br/>最成熟的生产模式]

    Q3 -->|1对1反馈| PL2[Pipeline+反馈环<br/>最大重试3次]
    Q3 -->|多Agent协作<br/>构建同一产物| BB[Blackboard<br/>自建 / agent-blackboard<br/>并行写入+版本控制]
    Q3 -->|需要达成<br/>共识决策| SC[Swarm Consensus<br/>AutoGen / 自建<br/>Token消耗最高]

    Q3 -->|需要多级<br/>任务分解| HI[Hierarchical<br/>AutoGen NestedChat<br/>3层以上适用]
```

---

## 八、2026年下半年趋势判断

**趋势一：Conductor引发DAG编排标准化。** Microsoft Conductor的MIT许可+CLI优先设计降低了DAG编排的门槛。预计到2026年底，DAG将成为多Agent编排的"默认骨架"，类似于Kubernetes成为容器编排的默认选择。

**趋势二：A2A生态爆发但碎片化风险。** A2A 1.0发布后，预计将有大量Agent服务提供商发布A2A兼容的Agent Card。但如果没有统一的注册中心（类似DNS），Agent发现将退化为点对点配置。

**趋势三：黑板模式从学术界走向生产。** arXiv论文2507.01701将黑板架构引入LLM多Agent系统的提案已获得广泛关注。结合MCP的工具访问能力，黑板模式有望成为"多Agent协同编辑"场景的标准解法。

**趋势四：混合拓扑成为主流。** 单一拓扑无法满足复杂生产需求。2026年的生产系统正在收敛到"DAG骨架（定义执行依赖）+ 黑板状态（共享中间产物）+ 事件驱动恢复（处理失败）"的三层混合架构。

---

## 参考来源

1. [Agent Workflow Orchestration Patterns: DAG, Event-Driven, and Actor Models — Zylos Research](https://zylos.ai/research/2026-04-14-agent-workflow-orchestration-patterns/) — DAG/事件驱动/Actor三种编排模式的深度对比
2. [Conductor: Deterministic orchestration for multi-agent AI workflows — Microsoft Open Source Blog](https://opensource.microsoft.com/blog/2026/05/14/conductor-deterministic-orchestration-for-multi-agent-ai-workflows/) — Microsoft开源确定性DAG编排工具
3. [A2A Protocol Specification v1.0](https://a2a-protocol.org/latest/specification/) — Google主导的Agent间互操作协议正式规范
4. [Concurrent Multi-Agent State Management — AgentMarketCap](https://agentmarketcap.ai/blog/2026/04/10/concurrent-multi-agent-state-management) — 多Agent共享状态并发写入问题与乐观锁方案
5. [Blackboard Architecture: The Multi-Agent AI Pattern Making a Comeback — TopicTrick](https://topictrick.com/blog/blackboard-architecture-pattern) — 黑板架构在LLM时代的复兴与实践
6. [Multi-Agent Orchestration Frameworks 2026 — Presenc AI](https://presenc.ai/research/multi-agent-orchestration-frameworks-2026) — LangGraph/CrewAI/AutoGen/Swarm/ADK五大框架生产就绪度对比
7. [Consensus Protocols for Multi-Agent Decision Making — Zylos Research](https://zylos.ai/research/2026-03-19-consensus-protocols-multi-agent-decision-making) — 多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 等场景全覆盖。

![51学通信知识星球海报-扫码加入](https://wiki.500nian.com/images/zhixingqiu_qrcode.png)