多智能体系统真正的成本不在模型，在连线。每一对智能体之间建立一条通信通道，就意味着一次状态同步义务：A 必须把上下文压缩后传给 B，B 必须回传结果让 A 更新自己的世界模型。这条"边"就是一笔账。2026 年多智能体编排框架（LangGraph、CrewAI、AutoGen、OpenAI Swarm 衍生生态）已收敛出四种主流拓扑——星型（Supervisor）、网状（Swarm）、树形（Hierarchical）、链式（Pipeline）——加上 A2A 协议带来的对等发现层（Network）。本文把这五种结构拆到图论层面，量它们的边数增长曲线、上下文冗余倍数、故障传播半径与路由决策成本，给出一套按"边数"而非按"故事"选型的硬规则。 ## 四式一网拓扑对比 | 拓扑 | 对应框架模式 | 边数增长 | 上下文冗余 | 故障半径 | 路由成本 | 最适场景 | |------|------------|---------|-----------|---------|---------|---------| | 星型 Supervisor | LangGraph Supervisor / CrewAI Crew | O(n) | 低（中心承载） | 全局（中心死全盘崩） | 中心单点 LLM 裁决 | 确定性流水线、中等复杂度 | | 网状 Swarm | OpenAI Swarm / LangGraph Swarm | O(n²) | 高（每对都要同步） | 局部（可绕行） | 每个节点各自路由 | 探索性、宽松、容错优先 | | 树形 Hierarchical | LangGraph 多层 Supervisor | O(n−1) | 中（按层级压缩） | 子树级 | 自顶向下委派 | 企业科层、任务可分解 | | 链式 Pipeline | 任意框架的串接 | O(n−1) | 极低（只传相邻） | 下游全停 | 零（静态） | ETL、审校、流水线 | | 全连接 Network | A2A / 自建对等 | O(n²) | 极高 | 局部 | 协商式广播 | 跨厂商异构协作 | 核心发现：**边数从 O(n−1) 跳到 O(n²) 时，上下文同步开销不是线性翻倍，而是平方级爆炸**。一个 10 节点的网状系统要维护 45 条同步关系，而同样 10 个节点的链式只维护 9 条——这就是"边数即税"。 ## 1. 星型 Supervisor：O(n) 的中心化瓶颈税 Supervisor 是 2026 年最被滥用的拓扑。一个中心智能体扮演路由器，所有工作智能体只与它对话，彼此隔离。QubitTool 的实测 TL;DR 给出的定位很准：Supervisor 适合"中等复杂度的确定性流水线"。它的好处是边数严格 O(n)，每个工作智能体只需把结果汇报给中心，上下文冗余最低。 代价全部压在中心节点。每一轮，Supervisor 都要读入所有子智能体的最近输出，做一个"下一步交给谁"的 LLM 裁决，再把任务派出去。这意味着中心节点的上下文是所有子智能体状态的并集，且每轮都要重新跑一次路由推理。当 n 超过 6–8 个工作智能体，中心上下文开始膨胀，路由准确率下降——它会开始把任务派给不相关的智能体，或在多个智能体间来回横跳。故障半径也是致命的：中心智能体一次幻觉，整个系统停摆或死循环。这正对应系列前文"控制流交接税"的根因——所有的交接都集中在一个节点上结算。 ```python # LangGraph Supervisor 的本质：所有边都经过中心 from langgraph.supervisor import create_supervisor supervisor = create_supervisor( agents=[researcher, coder, reviewer], # n=3，边=3，都指向中心 model="gpt-4o", prompt="Route to the right agent.", ) # 危险点：agents 列表越长，中心 prompt 越长，路由越糊 ``` 变现评估：Supervisor 是训练营最好讲的"入门样例"，三天课就能交付，但生产环境必须加中心节点的超时熔断与路由审计，否则就是一颗定时炸弹。 ## 2. 网状 Swarm：O(n²) 边数的上下文爆炸 Swarm 把控制权从中心下放到每个智能体：每个节点自己决定把"话筒"交给哪个同伴（handoff）。这让它看起来很"自由"、很"去中心化"，OpenAI Swarm 与 LangGraph 的 Swarm 模式都主推这套。问题藏在图论里——当任何两个节点都可能直接通信，边数是 n(n−1)/2。10 个智能体就有 45 条潜在同步通道，20 个就有 190 条。 每条边不是免费的。为了让 handoff 成立，发送方必须把自己当前的完整上下文（任务状态、已收集信息、未决问题）序列化成一段消息传给接收方，接收方要把这段消息并入自己的上下文再继续。在无中心约束下，多个智能体可能同时把任务甩向不同方向，产生"乒乓 handoff"——A 交给 B，B 觉得该 C 做，C 又退回 A，每跳都带一份越来越长的上下文。系列前文"归并黑洞：扇出税"描述的就是网状拓扑无约束扇出的结果。Swarm 的故障半径是局部优势（一条边断了可绕行），但这个优势被协调风暴完全抵消。 ```python # Swarm 的 handoff 本质：每个节点都能把球传给任意同伴 def researcher_agent(state): if "需要写代码" in state["messages"][-1]: return handoff_to(coder_agent, transfer_context=state) # 全量上下文传递 return handoff_to(reviewer_agent, transfer_context=state) # n 个节点 → 每个节点都持有对其他 n-1 个的 handoff 规则 ``` Swarm 适合的是"探索性、宽松、容错优先"的场景——比如创意头脑风暴、开放式调研，结论不唯一、错了也无所谓。把它套到需要精确交接的业务流上，就是在为 O(n²) 的同步开销买单。 ## 3. 树形 Hierarchical：层级委派的传递损耗 Hierarchical 是 Supervisor 的递归版：顶层 Supervisor 只管几个中层 Supervisor，每个中层再管几个一线智能体。边数回到漂亮的 O(n−1)，每条边只连接父子两层，上下文按层级压缩——底层干完活只把摘要汇报给中层，中层聚合后再摘要给顶层。这是企业科层结构在智能体世界的投影，也是大型任务分解（研究→设计→编码→测试，每层再拆）的自然选择。 代价是"传递损耗"。每一层汇报都是一次有损压缩，信息每上一层就丢一点。当树深超过 3 层，顶层 Supervisor 拿到的已是三手摘要，做出的战略决策可能与一线实际情况脱节——这正是系列前文"多智能体切片税：细即漂移"在层级结构里的变体：分层越细，漂移越远。同时，树形对"跨分支协作"极不友好：左子树的研究员想直接问右子树的测试员一个问题，必须层层上报到共同祖先再层层下传，往返延迟和上下文膨胀都很高。 适用边界明确：任务能干净地按"职能+层级"分解、分支间几乎不需要横向沟通时，Hierarchical 是性价比最高的结构。一旦出现频繁的跨分支需求，就该考虑给特定分支之间加一条"快捷边"，让树退化成带快捷路的层级图。 ## 4. 链式 Pipeline：串行延迟的累加税 Pipeline 是最简单也最被低估的拓扑：智能体排成一条直线，A 的输出是 B 的输入，B 的输出是 C 的输入。边数 O(n−1) 是所有拓扑里最低的，每个节点只与相邻两个节点交互，上下文冗余极低——只传交接产物，不传全局状态。这是 ETL、文档审校、代码 review 流水线的理想形态。 它的问题不是成本，是延迟。整条链的耗时是各节点耗时之和，没有并行空间（除非阶段内部并行）。链中任一节点卡住，下游全部停摆，故障表现为"整条线停滞"而非"局部绕行"。更深的问题是"误差累积"：链式结构没有纠错回路，A 的错误输出会被 B 当成事实继续加工，传到末端时错误已被层层放大且无法回溯——系列前文"假共识税"在单向链上最严重，因为没有第二意见来打破共识。 ```mermaid graph LR A[研究] -->|产物| B[设计] B -->|产物| C[编码] C -->|产物| D[测试] D -->|报告| E[发布] style A fill:#e1f5ff style E fill:#fff4e1 ``` Pipeline 适合流程确定、每步可独立验收、末端有人工把关的闭环。把它用在需要迭代修正的任务上（比如写代码→测→改→再测）就会退化成隐式回路，不如显式建一个反馈边。 ## 5. 全连接 Network 与 A2A：对等广播的协调风暴 第五种结构是 A2A（Agent2Agent）协议带来的"全连接网络"。Google 主导的 A2A 是一个开放协议，专门解决"不同厂商、不同框架的智能体如何相互发现并通信"——它定位为 MCP 的补充：MCP 管"智能体→工具"，A2A 管"智能体→智能体"。A2A 的核心机制是 Agent Card，一份 JSON 格式的"数字名片"，声明每个智能体能做什么、需要什么输入、提供什么端点。 Agent Card 解决了"边如何建立"——智能体通过 Agent Discovery 找到彼此的名片，再决定是否建立一条通信边。但这恰恰把网状的 O(n²) 问题推向极致：在一个完全对等、任何智能体都能与任何智能体协商的开放网络里，如果没有中心治理，协调开销会指数级膨胀。A2A 官方文档自己也承认，发现策略因环境而异（私有注册表、公共目录、点对点询问各有取舍），这正是治理复杂度的体现。 ```json // A2A Agent Card —— 每条潜在的"边"都由这张名片决定能否建立 { "name": "InvoiceAgent", "description": "处理发票校验与入账", "capabilities": ["validate_invoice", "post_to_erp"], "inputSchema": { "type": "object", "properties": { "invoice_id": {"type":"string"} } }, "endpoint": "https://finance.corp/a2a/invoice" } ``` A2A 的真正价值不在"让更多智能体互联"，而在"用标准名片降低建边成本、用发现层让边可治理"。把 A2A 当成"万物互联"的许可证去搭全连接网络，就是主动走进协调风暴；把它当成"边的中介层"，配合白名单与拓扑约束，才能在跨厂商协作里拿到对等的好处又不被 O(n²) 吞没。 ## 6. 拓扑选择决策：按边数与故障半径选型 把五种结构放在同一张决策图里，选型的硬规则浮现出来：先问"任务能不能拆成确定顺序"，能则用 Pipeline；再问"分支间要不要横向沟通"，不要则用 Hierarchical，要且容错优先则 Swarm；只有当确实需要跨厂商异构智能体协作时，才上 A2A Network 并强制拓扑治理。Supervisor 是"不确定时的默认值"，但要给中心节点设硬上限（工作智能体数 ≤ 8、路由超时熔断、路由决策可审计）。 ```mermaid flowchart TD Q1{任务有确定顺序?} Q1 -->|是| P[Pipeline 链式] Q1 -->|否| Q2{分支需横向沟通?} Q2 -->|否| H[Hierarchical 树形] Q2 -->|是| Q3{容错>精度?} Q3 -->|是| S[Swarm 网状] Q3 -->|否| Q4{跨厂商异构?} Q4 -->|是| N[A2A Network 带治理] Q4 -->|否| SV[Supervisor 星型 限n≤8] style P fill:#d4edda style SV fill:#fff3cd ``` 这条决策路径的底层逻辑始终是边数：每多一条边，就多一份上下文同步义务、多一个故障传播通道、多一次路由裁决。把拓扑选择简化成"边数预算管理"，多智能体系统的复杂度就从玄学变成可估算的工程量。 ## 推荐方案 **确定性流水线（数据处理、文档审校）**：直接上 Pipeline，别多想。它 O(n−1) 的边数和零路由成本是这类场景的绝配，加一个末端人工验收兜住误差累积即可。 **企业科层任务（研究→设计→开发，层级清晰）**：Hierarchical，但严格控树深 ≤ 3 层，并在已知高频跨分支处预留快捷边，避免层层上报的延迟与漂移。 **探索性、容错优先（开放式调研、创意生成）**：Swarm，接受 O(n²) 的同步开销作为探索广度的代价，但要给 handoff 设上限（最大跳数、上下文长度阈值），防止乒乓风暴。 **跨厂商异构协作（财务智能体找法务智能体）**：A2A Network，用 Agent Card 做发现，但必须配注册表白名单与拓扑约束——把它当"边的中介层"而非"万物互联开关"。 **默认/不确定**：Supervisor，但硬性限定工作智能体数 ≤ 8、中心路由超时熔断、每次路由决策落审计日志。超过这个规模就升级到 Hierarchical。 一条总纲：**先数边，再讲故事。** 多智能体架构的所有花活，最终都要在图的边数上结账。 ## 参考来源 1. [Multi-Agent Orchestration Patterns: Supervisor vs Swarm vs Hierarchical — QubitTool](https://qubittool.com/blog/multi-agent-orchestration-patterns) — 三种编排模式的定位与适用边界（Supervisor 适合确定性中等复杂度流水线、Swarm 对等去中心化） 2. [Multi-Agent AI Orchestration Patterns: Production Guide — Lushbinary](https://lushbinary.com/blog/multi-agent-orchestration-patterns-supervisor-swarm-pipeline-router-guide/) — 生产级四种模式指南，含 Gartner 关于 2026 年底 40% 企业应用嵌入智能体的预测 3. [Supervisor vs Swarm Architecture — DeepWiki langgraph-101](https://deepwiki.com/langchain-ai/langgraph-101/6.1-supervisor-vs-swarm-architecture) — LangGraph 官方仓库对两种基础拓扑的源码级对比 4. [Agent Discovery — A2A Protocol 官方文档](https://a2a-protocol.org/latest/topics/agent-discovery/) — Agent Card（JSON 数字名片）定义与发现策略，说明 A2A 与 MCP 的互补关系 5. [Announcing the Agent2Agent Protocol (A2A) — Google Developers Blog](https://developers.googleblog.com/en/a2a-a-new-era-of-agent-interoperability/) — A2A 作为开放协议的定位：解决跨平台智能体互操作，补足 MCP 的 agent-to-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 等场景全覆盖。