# 拓扑即命运：多智能体四构实测 ## 概述 把多个智能体堆在一起，第一道分水岭不是模型、不是工具，而是**它们之间怎么连线**。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 本身。 ```python # 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 折叠，否则跑长任务必爆。 ### 二、网状：O(n²) 的优雅陷阱 网状（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 附近就触顶。 ```python # 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 倍）。这就是"以深度换扇出"——你买到了并行检索，但付出了串行调度的等待。 ```python # 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 秒，无法像网状那样并发。第二，**信息单向流失**：上游犯的错下游只能被动继承，没有反馈回路纠正。前期"链长即断"的依赖税在流水线里最严重——任何一环幻觉，错误会原样传到终点，且越传越难追溯（因为下游不知道上游错在哪）。 ```python # 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 模型在固定轮数后强制裁决，既避免无限辩论，又避免多数暴政。 ```python # 稳健决策协议：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%，且回溯时几乎无法还原原始讨论。 ```mermaid 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 ``` **变现评估**：混合拓扑是企业落地的高级主题，适合做"架构师进阶"产品。核心教学点不是"怎么搭"，而是"在哪里划边界"——边界划错了，转译税能吃掉混合带来的全部收益。 ### 七、拓扑选型公式：按任务形状反推 不要先选框架再套拓扑，而要**先看任务形状再定拓扑**。一个实战检验过的反推公式： 1. **任务能否线性分解、步骤间无回头** → 流水线。确定性优先，别用更复杂的。 2. **任务有明确的"规划→执行"分层，子任务异构** → 层级。但深度压到 ≤3。 3. **任务需要多视角/多假设并行探索，且能容忍不收敛** → 网状。agent 数 ≤4，配 judge 熔断。 4. **任务是"一个调度员分发若干同构子任务"** → 星型。supervisor 必须配 context 折叠。 5. **以上都不是，任务有探索段也有执行段** → 混合，但明确划清转译边界。 一个常被忽略的判断信号是**"中间结果是否需要被多 agent 共享"**。需要 → 倾向网状/共享黑板；不需要 → 倾向流水线/星型，因为共享本身就是 O(n) 的 context 复制税。 ## Mermaid：四拓扑全景与通信流 ```mermaid 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 预算（每节点上限）。拓扑选错只是低效，没有可观测和熔断的多智能体是定时炸弹。 --- ## 参考来源 1. [Agent Orchestration Patterns: Swarm vs Mesh vs Hierarchical vs Pipeline](https://gurusup.com/blog/agent-orchestration-patterns) — 五种编排拓扑的模式定义与适用场景对比 2. [Multi-Agent AI Architecture: Patterns for Enterprise Development](https://www.augmentcode.com/guides/multi-agent-ai-architecture-patterns-enterprise) — Hub-spoke/Mesh/Hierarchical 企业级落地与容错分析 3. [Voting or Consensus? Decision-Making in Multi-Agent Debate (ACL 2025)](https://aclanthology.org/2025.findings-acl.606/) — 七种决策协议对最终准确率的系统性评测 4. [S2-MAD: Breaking the Token Barrier to Enhance Multi-Agent Debate (NAACL 2025)](https://aclanthology.org/2025.naacl-long.475/) — 多智能体辩论的 token 成本爆炸与性价比拐点 5. [Multi-Agent Debate and Consensus Architecture 2026](https://agentmarketcap.ai/blog/2026/04/09/multi-agent-debate-consensus-architecture-2026) — Free-MAD 无共识变体降低开销的实测与生产结论 --- > 本文由「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 等场景全覆盖。