<!-- title: 拓扑定生死：多智能体五架构横评 -->

# 拓扑定生死：多智能体协作五架构横评

## 核心发现

2026 年的多智能体系统，真正的成本不在模型，而在拓扑。一份覆盖主流编排框架的基准测试揭示：同样是 10 个 Agent 的生产系统，因通信结构不同，月度运营成本可在 **3,200 到 13,000 美元**之间漂移 4 倍；而把链式流水线改成扇出/扇入（Fan-out/Fan-in）的 DAG 结构，端到端延迟能直接砍掉 **36%–50%**。本文以 Sequential Pipeline、Supervisor（星型）、Mesh/Swarm（网状）、Hierarchical（层次）、DAG（有向无环图）五种主流拓扑为坐标，实测它们在通信边数、协调令牌、单点风险、并行红利四个维度上的"税"，并给出按场景的选型结论。

---

## 一、为什么拓扑是 2026 年的头号决策

把 LLM 助手升级成多智能体系统后，团队的第一个错觉是"加 Agent 就能加能力"。真实情况恰恰相反：**决定系统能否上线的不是模型智商，而是拓扑选择**。架构蓝图定义了 Agent 如何协调、通信、排序工作，而这个选择直接锁死了四样东西——延迟分布、故障传播路径、成本曲线和系统复杂度的天花板。

业界把 Agent 自主度分成 L0–L4 五级，2026 年正处于从"单聊助手"向 L3/L4"编排式多智能体"跃迁的拐点。一旦越过 L3，单体 Agent 的推理质量不再是瓶颈，取而代之的是**编排层的通信与协调开销**。基准数据显示，这一年的首要延迟瓶颈已经从"模型推理速度"转移到了"链式工具调用（chained tool calls）"——也就是说，你被自己的拓扑结构卡住了，而不是被 GPU 卡住了。

下面这张表把五种拓扑放在同一坐标系下横评。

## 二、五拓扑多维横评

| 维度 | Sequential Pipeline 流水线 | Supervisor / Star 星型 | Mesh / Swarm 网状群智 | Hierarchical 层次 | DAG / Fan-out 扇出扇入 |
|------|---------------------------|------------------------|----------------------|-------------------|------------------------|
| 通信边数（n 个 Agent） | n−1（线性） | n−1（辐射） | n(n−1)/2（全互联） | O(n)，按层聚合 | O(n)，按依赖 |
| 协调开销 | 极低 | 中（中心重路由） | **高，O(n²) 爆炸** | 中，按层递归 | 低（调度器统一规划） |
| 端到端延迟 | **累加，最差** | 中心串行收发 | 收敛慢，需多轮 | 跨层叠加 | **并行，最优** |
| 单点故障 | 任一节点 | **中心节点** | 无（去中心） | 中间层节点 | 调度器（可冗余） |
| 并行红利 | 零 | 弱（worker 可并行） | 强但混乱 | 中 | **强且可控** |
| 扩展曲线 | 线性 | 线性，中心线性过载 | **平方爆炸** | 对数（分层摊薄） | 线性，受关键路径约束 |
| 上下文重复 | 中（流水线传递） | 高（中心聚合所有） | 极高（成对互通） | 中（逐层压缩） | 低（扇入聚合一次） |
| 典型框架 | CrewAI `process=sequential` | LangGraph `Supervisor` | AutoGen `GroupChat` | MetaGPT 角色树 | LangGraph `Send`/LLMCompiler |

## 三、深度拆解：每种拓扑的税在哪里

### 1. Sequential Pipeline——累加延迟税

流水线是最直觉也最危险的默认选择：Agent A 的输出喂给 B，B 给 C，像工厂流水线。它的诱惑在于"零协调成本"——没有中心、没有广播，代码写起来就是 `chain = a | b | c`。但代价是**延迟严格累加**：端到端时间等于每一步推理时间之和，且前一步的失败会让整条链回退。

实测痛点是"步深即慢"。一个 6 步的研究流水线，即便每步只要 8 秒，端到端也是 48 秒起跳，叠加工具调用后轻松破分钟。更隐蔽的是**上下文衰减**：原始指令在链尾已经过 6 次转述，保真度急剧下降。CrewAI 默认就是这种模式，对线性、强依赖的任务（写作→审校→润色）尚可，但凡有一点可并行的子任务，流水线都在用串行的代价买单。

```python
# 流水线：延迟严格累加，无并行红利
result = agent_writer.invoke(topic)          # ~8s
result = agent_reviewer.invoke(result)       # ~6s
result = agent_editor.invoke(result)         # ~5s
# 端到端 ≥ 19s，三步串行
```

### 2. Supervisor / Star——中心瓶颈税

星型（Hub-and-Spoke）把一个"主管"Agent 放在中央，所有 Worker 只跟主管说话。这是 LangGraph `Supervisor`、OpenAI Swarm Hand-off 的主流形态，工程上最易控：权限清晰、可审计、好做人类在环（主管节点天然是干预点）。

它的税在**中心节点**。主管要接收每个 Worker 的输出、决策下一步、再把任务分发回去，这意味着：(1) 主管的上下文窗口是全系统的瓶颈，所有中间结果都往里塞，很快触发压缩即失忆；(2) 主管是**串行收发**，10 个 Worker 哪怕并行跑，结果也要排队回到主管做合并决策，吞吐被中心带宽卡死；(3) 中心节点是**单点故障**，挂了全网瘫痪。基准里 10 Agent 系统月烧上万刀，很大比例是主管 Agent 反复重读各 Worker 上下文产生的协调令牌。

```python
# LangGraph 星型：主管是瓶颈与单点
def supervisor(state):
    # 重读所有 worker 输出 → 上下文膨胀 → 决策 → 再分发
    next = route(state["messages"])        # 串行决策
    return {"next": next}                   # 中心带宽限吞吐
```

### 3. Mesh / Swarm——通信边数爆炸税

网状拓扑让 Agent 之间两两互通，理论上去中心化、容错最强、最像"群智"。AutoGen 的 `GroupChat`、多智能体辩论（debate）走的就是这条路。它的致命伤是**通信边数按 O(n²) 增长**：10 个 Agent 是 45 条边，20 个就是 190 条，每多一个 Agent，潜在的两两对话组合爆炸。

实践中 Mesh 有三重塌方：第一，**协调令牌暴涨**——每对 Agent 互通都要重建上下文，辩论几轮后总令牌量轻松破十万；第二，**收敛困难**——没有权威仲裁时，Agent 容易陷入"互相附和"或"循环争论"，群智收敛的四式（投票/加权/仲裁/分层）在这里都要额外开销；第三，**可观测性近乎为零**——190 条边谁在跟谁说话、谁影响了谁，调试时基本是黑盒。Mesh 只在任务真正需要"多元视角对撞"（如红队对抗、多方辩论）时才划算，否则就是用 O(n²) 的代价解决 O(n) 的问题。

```python
# AutoGen 网状群聊：边数 O(n²)，收敛需多轮
groupchat = GroupChat(
    agents=[analyst, coder, critic, pm],   # n 个 agent
    messages=[], max_round=12              # 辩论轮次驱动收敛
)  # 边数 = 4×3/2 = 6，n=20 时飙至 190
```

### 4. Hierarchical——跨层延迟税

层次拓扑把 Agent 组织成树：顶层主管分解任务给中层主管，中层再分给底层执行者，MetaGPT 的"产品经理→架构师→工程师→测试"角色树就是典型。它的优势是**指挥链清晰、模块化、可扩展**——新增分支不扰动其他子树，复杂度按深度而非规模增长。

税在**跨层延迟与中间节点风险**。一次决策要逐层下传再逐层上报，深度 d 的树端到端延迟约为 d × 单跳延迟，层数越多越慢。更危险的是**中间层节点故障会隔离整个子树**——架构师这个中层主管挂了，下面所有工程师的产出都上不来。此外层次拓扑常常**过度切分**：把一个本来 2 步能做完的任务切成 4 层 8 个节点，制造大量"管理 Agent"，这些节点不产生价值却持续消耗令牌（一种"协调层去模型化"问题）。层次适合组织结构天然分层、子任务边界清晰的大型工程（软件工厂、多部门协同），小团队用就是杀鸡用牛刀。

### 5. DAG / Fan-out——幂等性税

DAG（有向无环图）用 Fan-out/Fan-in 把无依赖的子任务并行化，是 2026 年公认的延迟最优解。基准显示，把链式工作流重写为 DAG，生产内容和研究流的端到端时间下降 **36%–50%**；LLMCompiler 配合 PASTE（投机式工具执行）能达到 **1.8x–3.7x 加速、最高 6x 成本降低**。原因在于并行红利：原本串行的 6 步，若 4 步无依赖，理论上 3 层即可收敛。

DAG 不是免费午餐，它的税叫**幂等性**。并行节点可能因竞争、超时、重试被触发多次，只有幂等（同样输入永远同样输出、无副作用积累）的节点才能安全重跑。一旦某个并行分支修改了共享状态，就会出现"并发写共享态丢更新"的经典故障。此外 DAG 的**关键路径**决定上限——并行加速比被最长依赖链锁死，阿姆达尔定律在这里无情生效：即便 90% 可并行，剩余 10% 串行也把加速比压在 10x 以内。

```python
# DAG 扇出/扇入：并行红利 + 幂等性要求
import asyncio
async def dag_run(query):
    # Fan-out：无依赖的子任务并行
    a, b, c = await asyncio.gather(
        research(query),          # 必须幂等
        retrieve(query),          # 必须幂等
        compute(query),           # 必须幂等
    )
    # Fan-in：一次聚合，上下文只重复一次
    return synthesize([a, b, c])
```

### 6. 拓扑混合——生产实战的折中艺术

没有任何一个真实生产系统是"纯拓扑"。2026 年的高成熟团队几乎都在做**混合编排**：外层用 Supervisor 做权限与人类在环（拿星型的可控性），中层用 DAG 做并行（拿并行红利），局部用 Mesh 做辩论（拿多元视角），骨架用 Hierarchical 做组织（拿可扩展性）。这种折中的核心原则是**把拓扑与任务结构对齐**——任务依赖图长什么样，拓扑就长什么样。一条有用的工程经验：默认从 DAG 起步（并行红利最大、上下文税最低），只在确实需要权威裁决时引入 Supervisor，需要视角碰撞时局部引入 Mesh。把 Mesh 当默认选项，是用 4 倍成本换一个"看起来很聪明"的系统。

## 四、五拓扑协作架构图

```mermaid
flowchart LR
    subgraph Pipeline["①流水线 Pipeline"]
        P1[A] --> P2[B] --> P3[C]
    end
    subgraph Star["②星型 Supervisor"]
        S0((主管)) --> S1[W1]
        S0 --> S2[W2]
        S0 --> S3[W3]
    end
    subgraph Mesh["③网状 Swarm"]
        M1[A] --- M2[B]
        M2 --- M3[C]
        M3 --- M1
    end
    subgraph Hier["④层次 Hierarchical"]
        H0((顶层)) --> Hm((中层))
        Hm --> H1[执行1]
        Hm --> H2[执行2]
    end
    subgraph DAG["⑤DAG 扇出扇入"]
        D0((调度)) --> D1[研究]
        D0 --> D2[检索]
        D0 --> D3[计算]
        D1 --> Df((聚合))
        D2 --> Df
        D3 --> Df
    end
```

```text
graph TD
    A[任务到达] --> B{有并行子任务?}
    B -- 否 --> C[Sequential Pipeline<br/>延迟累加 但零协调]
    B -- 是 --> D{需要权威裁决/人环?}
    D -- 是 --> E[Supervisor 星型<br/>可控 但中心瓶颈]
    D -- 否 --> F{需要多元视角对撞?}
    F -- 是 --> G[Mesh 网状<br/>群智 但 O(n²) 边数]
    F -- 否 --> H[DAG 扇出扇入<br/>并行最优 需幂等]
    style C fill:#ffe0e0
    style E fill:#fff4d6
    style G fill:#ffe0e0
    style H fill:#d6ffd6
```

## 五、按场景的推荐方案

**个人/小团队、线性任务**（写作流水线、数据处理 ETL）：选 **Sequential Pipeline**。零协调、易调试，但要硬性控制步数在 4 步内，否则累积延迟和上下文衰减会吞掉收益。

**企业内部 Agent、需要审计与人环**（客服、合规、流程审批）：选 **Supervisor 星型**。它的可控性、可观测性、人类在环天然契合，但务必给主管做上下文压缩和降级备份，避免中心瓶颈和单点故障。

**红队对抗、深度研究、多方辩论**：局部使用 **Mesh**，但**严格限定 Agent 数 ≤ 5、辩论轮数 ≤ 4**，并强制引入仲裁收敛。否则 O(n²) 边数会让协调令牌失控。

**软件工程工厂、多部门协同、组织天然分层**：选 **Hierarchical**。把每一层的接口契约定义清楚，警惕中层"管理 Agent"虚胖，定期审计哪些中间节点可以合并。

**内容生成、研究汇总、任何"一个任务可拆多个独立子任务"的场景**（这是大多数）：**默认选 DAG 扇出扇入**。这是 2026 年的性价比最优解——并行红利砍掉近半延迟，扇入聚合让上下文只重复一次，是四种税里最轻的。

**变现/训练营评估**：DAG + Supervisor 混合模式是最具产品化潜力的组合，因为它同时满足"延迟可控、成本可控、可向客户解释"三个商用约束，可包装成"多智能体并行生产力"训练营。流水线和纯 Mesh 因为各自有硬伤（一个太慢、一个太贵），教学价值高但商用需谨慎。

## 参考来源

1. [AI Agent Orchestration Patterns (2026 Guide) — thinking.inc](https://thinking.inc/en/blue-ocean/agentic/agent-orchestration-patterns/) — 六种编排模式蓝皮书，论证拓扑决定延迟/故障/成本/复杂度上限
2. [DAG Orchestration: Cut AI Agent Latency 50% Fan-Out — Particula](https://particula.tech/blog/dag-agent-orchestration-fan-out-fan-in-latency-parallel-execution) — DAG 扇出/扇入降延迟 36–50%，LLMCompiler+PASTE 1.8x–3.7x 加速、6x 成本降低
3. [The Real Cost of Multi-Agent Orchestration in 2026 — Koenig AI Academy](https://academy.kspl.tech/blog/2026-05-31-multi-agent-orchestration-real-cost-2026) — 10 Agent 生产系统月成本 $3,200–$13,000，按模式的成本矩阵
4. [Multi-Agent Orchestration 2026: A Benchmark of Latency and Cost — Refactor](https://www.refactor.website/artificial-intelligence/multi-agent-orchestration-2026-latency-cost-benchmarks) — 2026 编排框架延迟/吞吐/成本基准，L3/L4 拐点与链式工具调用瓶颈
5. [AI Agent Orchestration — 6 Patterns for Production 2026 — AnhTu.dev](https://anhtu.dev/ai-agent-orchestration-6-patterns-for-production-2026-1121) — Pipeline/Supervisor/Swarm/Hierarchical/Router 六模式生产实践与不可变状态模式

> [!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)
