星网树链四式拓扑：边数即税

多智能体系统真正的成本不在模型，在连线。每一对智能体之间建立一条通信通道，就意味着一次状态同步义务：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 个工作智能体，中心上下文开始膨胀，路由准确率下降——它会开始把任务派给不相关的智能体，或在多个智能体间来回横跳。故障半径也是致命的：中心智能体一次幻觉，整个系统停摆或死循环。这正对应系列前文"控制流交接税"的根因——所有的交接都集中在一个节点上结算。

# 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 的故障半径是局部优势（一条边断了可绕行），但这个优势被协调风暴完全抵消。

# 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 当成事实继续加工，传到末端时错误已被层层放大且无法回溯——系列前文"假共识税"在单向链上最严重，因为没有第二意见来打破共识。

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 官方文档自己也承认，发现策略因环境而异（私有注册表、公共目录、点对点询问各有取舍），这正是治理复杂度的体现。

// 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、路由超时熔断、路由决策可审计）。

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。

一条总纲：先数边，再讲故事。 多智能体架构的所有花活，最终都要在图的边数上结账。