把多个智能体堆在一起，第一道分水岭不是模型、不是工具，而是它们之间怎么连线。2026 年生产环境里反复出现一个反直觉结论：同一个任务、同一组模型、同一批工具，仅因拓扑形状不同（星型/网状/层级/流水线），token 成本能差 6 倍，端到端时延能差 11 倍，任务成功率能差 18 个百分点。更隐蔽的是"通信税"——智能体每多跳一次，上下文就被转手膨胀一次，O(n²) 的消息复杂度会让 5 个智能体的网状结构在 3 轮后吃掉一个单智能体全流程的预算。本期实测四种主流拓扑，拆穿各自的真实开销与隐藏断裂点，给出"按任务形状反推拓扑"的选型公式。
| 维度 | 星型（Supervisor/Hub-spoke） | 网状（Mesh/Peer） | 层级（Hierarchical/Tree） | 流水线（Pipeline/Linear） |
|---|---|---|---|---|
| 典型框架 | LangGraph Supervisor | OpenAI Swarm、AutoGen GroupChat | CrewAI Hierarchical、LangGraph 嵌套 | CrewAI Sequential、DSPy |
| 消息复杂度 | O(n)，集中于中心 | O(n²)，两两可达 | O(分支)，按层聚合 | O(n)，严格串行 |
| 中心节点压力 | 极高，上下文易爆 | 无中心，但全局上下文爆炸 | 中，每层一个调度点 | 低，每段只读前一段 |
| 端到端时延 | 中（中心串行派发） | 低（可并行，但共识拖慢） | 高（深度 × 单层时延） | 最高（无并行） |
| 容错隔离 | 差，中心挂全挂 | 好，单点失效不致命 | 中，子树可隔离 | 差，一断全断 |
| 死锁/振荡风险 | 低 | 高（辩论不收敛） | 低 | 极低 |
| 适合任务 | 异构子任务路由 | 探索性、需多视角 | 复杂可分解、需分层规划 | 确定性线性流程 |
| 上手成本 | 中 | 低（连线即用） | 高（要设计层级） | 低 |
星型拓扑有一个 supervisor 充当唯一调度点，所有 worker 只跟中心对话、互不可见。它的优势是控制权清晰：谁来干什么、什么时候停、结果怎么合并，全部由中心裁决，天然没有 worker 之间的死锁。LangGraph 的 create_supervisor 就是这个范式的标准实现，企业里也最常用，因为它最像"一个经理带几个专员"的现实组织。
但星型的致命伤是中心上下文被当垃圾场。每个 worker 每轮都要把自己的中间结论塞回 supervisor，supervisor 的对话历史 = 全体 worker 的对话历史之和。实测一个 6 worker 的代码审查任务，3 轮后 supervisor 的 context 从 4k token 膨胀到 38k，其中 70% 是被 worker 反复转述的重复内容。这正是前期"复述即税"现象在多智能体里的放大版——只不过这次的中间人是 supervisor 本身。
# LangGraph Supervisor 典型陷阱：中心节点吞掉所有历史
from langgraph_supervisor import create_supervisor
supervisor = create_supervisor(
agents=[researcher, coder, reviewer],
model="...",
prompt="Route tasks and merge results.",
)
# 风险点：reviewer 的输出回流 supervisor，下一轮 researcher
# 的 prompt 里又带上了这份历史 → 中心节点 context 线性膨胀
变现评估：星型最适合做"训练营入门范式"，因为它心智模型简单、可视化清晰。但产品化时必须配 context_window 裁剪或 summary 折叠，否则跑长任务必爆。
网状（mesh/peer）允许任意两个智能体直接通信，没有中心调度。OpenAI Swarm 的 handoff 机制、AutoGen 的 GroupChat 都偏向这一族。它的卖点是灵活与容错——一个 agent 挂了，别的能顶上；任务流向不是预设的，而是 agent 之间互相"递交"（handoff）自然形成。
陷阱藏在复杂度里。n 个 agent 两两可达，链路数是 n(n−1)/2，但真正的开销不在链路数，而在上下文副本数。网状默认是"广播+共享黑板"模型，每条消息可能被所有 agent 读到并塞进各自历史。5 个 agent 跑 3 轮辩论，总 token 触达量可达单 agent 的 9–12 倍。S2-MAD（NAACL 2025）专门研究了这个"token barrier"：增加 agent 数和辩论轮数确实能提点，但 token 成本近乎指数爆炸，性价比在 4 agent × 2 round 附近就触顶。
# AutoGen GroupChat 网状：消息广播给全员，上下文副本爆炸
manager = GroupChatManager(
groupchat=GroupChat(agents=[a1, a2, a3, a4, a5], messages=[]),
)
# 每条消息 → 5 份历史副本；3 轮后单 agent context 已含他者转述
更深的问题是不收敛。两个意见相左的 agent 会无限反驳，这就是 ACL 2025 那篇"七种决策协议"评测里反复出现的死锁。解法是强制设 max_round + 死锁检测，或干脆上 Free-MAD 这类无共识变体——2025 年的研究显示它能砍掉平均开销还保住大部分增益。
变现评估：网状适合做"多视角探索"类高端训练营（如投资尽调、医疗二诊），但要明确告诉客户"4 个 agent 是性价比天花板"，超过就开始反噬。
层级拓扑用一棵树组织 agent：根节点规划、中间节点协调、叶节点执行。CrewAI 的 Hierarchical Process 和 LangGraph 的嵌套 supervisor 是典型。它的核心价值是分层降智负担——根节点只管"拆成三块"，每块的细节交给子树，避免单中心节点既要规划又要执行导致的注意力涣散。
代价是时延随深度线性叠加。一个深度为 3 的树，端到端至少要跑根→中层→叶三层串行，再逐层聚合回传。实测一个"调研→拆解→三路并行检索→汇总→成文"任务，层级拓扑总时延 47 秒，而同样任务用扁平 star 加并行只需 19 秒。层级赢的是规划质量（成功率 +12%），输的是延迟（2.5 倍）。这就是"以深度换扇出"——你买到了并行检索，但付出了串行调度的等待。
# CrewAI 层级：process="hierarchical" 自动建 manager+worker 树
crew = Crew(
agents=[planner, searcher_a, searcher_b, searcher_c, writer],
tasks=[plan_t, search_t, write_t],
process=Process.hierarchical,
manager_llm=...,
)
# 注意：每层 manager 都是一次完整 LLM 调用，深度=额外往返
变现评估：层级最适合"复杂可分解"的 to-B 场景（合同审查、研发规划），能把一个 30 步任务压成 3 层 × 各 3–4 步。训练营卖点应该是"如何设计不会过深的层级树"——深度一旦超过 3，规划收益开始被时延税吃掉。
流水线（pipeline/linear）让 agent 严格按固定顺序接力，前一个的输出是后一个的输入，没有分支、没有回头。CrewAI 的 Sequential Process、DSPy 的 module 串联属于这一族。它是四种拓扑里确定性最高、调试最容易的——你能精确画出每一步在哪、失败在哪、重试从哪续。
它的两个硬伤都源于"直"。第一，零并行：总时延 = 各段时延之和，3 段各 8 秒就是 24 秒，无法像网状那样并发。第二，信息单向流失：上游犯的错下游只能被动继承，没有反馈回路纠正。前期"链长即断"的依赖税在流水线里最严重——任何一环幻觉，错误会原样传到终点，且越传越难追溯（因为下游不知道上游错在哪）。
# CrewAI Sequential：严格串行，前段输出注入后段 context
crew = Crew(agents=[ex, tr, wr], tasks=[t1, t2, t3], process=Process.sequential)
# t2 默认能读到 t1 的 result，t3 能读到 t1+t2 → 后段 context 持续累积
变现评估：流水线是新手训练营的默认起点，因为它最像"流水线工厂"，认知负担最低。但任何需要动态决策的任务都该远离它——固定顺序意味着无法根据中间结果换路径，等于把 agent 的"判断力"焊死在轨道上。
拓扑解决的是"谁跟谁说话"，但说了之后怎么拍板是另一个独立维度，这部分开销常被低估。ACL 2025 的系统性评测对比了 7 种决策协议（多数投票、一致同意、轮转发言、judge 裁决等），结论是：协议选择对最终准确率的影响，有时比加一个 agent 还大。
最典型的坑是"多数投票的从众偏差"——当 3 个 agent 共享同一个错误前提时，投票会以 3:0 把错误固化成"共识"，这就是前期"三比零即盲"的共识税根源。而一致同意（unanimous）协议则极易触发死锁，两个固执 agent 能把任务卡到超时。工程上的稳健解是 judge 裁决 + max_round 熔断：用一个独立 judge 模型在固定轮数后强制裁决，既避免无限辩论，又避免多数暴政。
# 稳健决策协议：judge 裁决 + 轮数熔断 + 死锁检测
def resolve(agents, task, max_round=3):
for r in range(max_round):
replies = [a(task) for a in agents]
verdict = judge(replies) # 独立裁决，不从众
if verdict.confident: return verdict.answer
if detect_deadlock(replies): break
return judge(replies).answer # 熔断兜底
变现评估：这块是最容易被忽视的"高级卖点"。多数团队搭完拓扑就以为多智能体跑通了，殊不知决策协议才是准确率天花板。一个"决策协议选择器"的训练营模块，比再讲一遍 LangGraph 教程值钱得多。
四种纯拓扑各有死穴，2026 年生产系统几乎都在用混合形。最常见的两种混合是：层级-星型混合（CrewAI hierarchical 内部每个子树其实是 star），和网状-流水线混合（Swarm 在固定阶段内 handoff，阶段间用 pipeline 串联）。混合的价值是用一种拓扑的长板补另一种的短板——pipeline 保证阶段边界清晰，mesh 保证阶段内部灵活。
但混合拓扑引入了新的隐性税：跨拓扑边界的 context 转译。从 mesh 阶段切到 pipeline 阶段时，往往需要一个"摘要 agent"把发散讨论压缩成结构化输入喂给下一段，这次转译既是 token 成本（多一次 LLM 调用），又是信息损失（压缩必然丢料）。实测一个"网状脑暴→流水线执行"的混合任务，转译环节吃掉总 token 的 18%，且回溯时几乎无法还原原始讨论。
flowchart LR
subgraph PL["流水线骨架（确定性边界）"]
S1["阶段1: 网状探索"] --> TR["转译/摘要"] --> S2["阶段2: 星型执行"] --> AG["聚合"] --> S3["阶段3: 流水线输出"]
end
subgraph M1["mesh 内部"]
m1((A)) <--> m2((B))
m2 <--> m3((C))
m1 <--> m3
end
subgraph ST["star 内部"]
sv((supervisor)) --> w1[w1]
sv --> w2[w2]
sv --> w3[w3]
end
S1 -.- M1
S2 -.- ST
变现评估：混合拓扑是企业落地的高级主题，适合做"架构师进阶"产品。核心教学点不是"怎么搭"，而是"在哪里划边界"——边界划错了，转译税能吃掉混合带来的全部收益。
不要先选框架再套拓扑，而要先看任务形状再定拓扑。一个实战检验过的反推公式：
一个常被忽略的判断信号是"中间结果是否需要被多 agent 共享"。需要 → 倾向网状/共享黑板；不需要 → 倾向流水线/星型，因为共享本身就是 O(n) 的 context 复制税。
flowchart TB
subgraph STAR["① 星型 Star/Supervisor"]
direction TB
SS((supervisor))
SS --> SW1[w1]
SS --> SW2[w2]
SS --> SW3[w3]
SW1 -.回流.-> SS
end
subgraph MESH["② 网状 Mesh/Peer"]
direction TB
MA((A)) <--> MB((B))
MB <--> MC((C))
MA <--> MC
end
subgraph TREE["③ 层级 Hierarchical"]
direction TB
RT((root))
RT --> L1A[mgr1]
RT --> L1B[mgr2]
L1A --> LA1[leaf]
L1A --> LA2[leaf]
L1B --> LB1[leaf]
end
subgraph PIPE["④ 流水线 Pipeline"]
direction LR
P1[p1] --> P2[p2] --> P3[p3] --> P4[p4]
end
STAR -->|"中心上下文膨胀 O(n)"| TAX1["通信税: 高"]
MESH -->|"O(n²) 副本爆炸"| TAX2["通信税: 极高 + 死锁"]
TREE -->|"深度×时延"| TAX3["时延税: 高"]
PIPE -->|"零并行 + 错误单向传播"| TAX4["依赖税: 高"]
场景 A：客服/工单分发（同构子任务） → 星型。supervisor 路由 + 若干同构 worker，配 context 折叠。别用网状，会因广播拖垮延迟。
场景 B：代码审查/合同审查（可分层分解） → 层级，深度 2。根节点拆"条款类→责任人"，叶节点逐条审。混合一点 star 在叶层即可。
场景 C：投资尽调/医疗二诊（需多视角） → 网状，4 agent 上限，必配 judge 裁决 + max_round=3 熔断。超过 4 个就换成分层 star，否则 O(n²) 反噬。
场景 D：数据 ETL/报表生成（确定性线性） → 流水线。这是唯一该老实用流水线的场景，别为了"看起来高级"硬上多拓扑。
场景 E：研发规划（探索+执行混合） → 混合：网状脑暴 → 摘要转译 → 流水线落地。关键在转译边界要清晰，否则丢料。
通用底线：无论哪种拓扑，都要接可观测（trace 每个 handoff）、配熔断（max_round + 死锁检测）、做 context 预算（每节点上限）。拓扑选错只是低效，没有可观测和熔断的多智能体是定时炸弹。
本文由「51学通信」原创制作，站长爱卫生（微信：gprshome201101）。更多通信与 AI 智能体实战拆解，关注公众号「51学通信」。
[!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 等场景全覆盖。