# 扁平即雪崩：四拓扑扇出税实测 ## 概述 把同样一个需要 8 个专业 Agent 协作的任务，分别跑在网状、星型、层级、环形四种通信拓扑上，结论出乎很多团队的直觉：**决定 token 烧得多快、延迟拖得多长的，不是 Agent 的数量，而是谁跟谁说话**。全连接的网状拓扑在一轮协调里要产生 `N(N−1)` 条消息——8 个 Agent 是 56 条，16 个直接涨到 240 条，上下文被全量复制到每个 Agent，这就是"扁平即雪崩"。星型把扇出压回 `2N`，代价是编排器成为串行瓶颈；层级用深度换扇出，消息最少却逐层有损；环形消息最省，但延迟等于整链之和、一环慢全链堵。本文用一组确定性的消息复杂度模型做实测基准，给出四种拓扑在不同 N 下的消息数、token 估算、端到端延迟和单点爆炸半径，并给出选型决策。 ## 多智能体通信拓扑总览 四种主流拓扑在 2026 年的框架里都有明确对应物：网状对应 AutoGen GroupChat 与 CrewAI 无管理者协作；星型对应 LangGraph Supervisor、OpenAI Swarm 的路由器；层级对应 LangGraph Hierarchical Teams 与 CrewAI Hierarchical Process；环形对应 CrewAI Sequential 与 LangGraph 线性图。 ```mermaid graph TB subgraph Mesh["网状(扁平) 扇出=N(N-1) 雪崩"] M1((A1)) <--> M2((A2)) M1 <--> M3((A3)) M1 <--> M4((A4)) M2 <--> M3 M2 <--> M4 M3 <--> M4 end subgraph Star["星型(编排器) 扇出=2N"] S0(("Hub")) --> S1((A1)) S0 --> S2((A2)) S0 --> S3((A3)) S1 --> S0 S2 --> S0 end subgraph Hier["层级(树) 扇出=2(N-1)"] H0(("Mgr")) --> H1(("Lead1")) H0 --> H2(("Lead2")) H1 --> W1((W1)) H1 --> W2((W2)) H2 --> W3((W3)) H2 --> W4((W4)) end subgraph Ring["环形(流水线) 扇出=N"] R1((A1)) --> R2((A2)) R2 --> R3((A3)) R3 --> R4((A4)) R4 --> R1 end ``` ## 一、网状拓扑：扇出雪崩是数学必然 ### 架构原理 网状（mesh/flat）拓扑里，每个 Agent 都能与其他所有 Agent 直接通信，消息按全连接广播扩散。一轮"每个人都把自己的中间结果告诉所有人"的协调，消息数等于完全有向图的边数 `N(N−1)`。这是所有拓扑里唯一一个**消息数随 Agent 数平方增长**的结构。AutoGen 的 `GroupChat` 默认把每条发言塞进所有 Agent 的历史，CrewAI 在不指定 manager 时也走类似的扁平广播。 ### 代码示例 ```python # AutoGen 风格：扁平 GroupChat，全员互发 from autogen import GroupChat, GroupChatManager agents = [researcher, analyst, writer, critic, fact_checker] # N=5 group_chat = GroupChat( agents=agents, messages=[], max_round=6, # 一旦增大，消息数 = rounds × N(N-1) send_introductions=True, # 每个Agent都收到所有人的自我介绍 ) manager = GroupChatManager(groupchat=group_chat) # 问题：第6轮时，每个agent的历史里已塞入 ~6×5=30 条非自己发言 ``` ### 优缺点分析 优点是延迟最低——所有 Agent 并行收发，一轮协调 ≈ 单 Agent 一次推理时间；信息冗余度高、容错好，单个 Agent 挂掉不影响其余通信。缺点是 token 成本爆炸：每条消息都带着累积上下文全量复制给 N 个 Agent，N=8 时一轮就产生 56 次上下文写入。生产环境里，单条消息若携带 2k token，一轮广播仅"互相看见"的开销就达 112k token，且随 N 二次方膨胀，这正是多 Agent 系统比单 Agent 聊天多烧 10–100 倍 token 的根因之一。 ### 变现/训练营评估 网状是"多 Agent 辩论/头脑风暴"训练营的天然卖点——能演示出热闹的群体智能，视觉冲击力强。但训练营必须配一节"成本刹车"：教 max_round 上限、发言预算（token budget per agent）、发言权裁剪（只让 top-k 相关 Agent 收到消息），否则学员把 demo 上线后会直接收到天价账单。可包装成《群体辩论 Agent 成本可控版》产品，按"辩论收敛而不发散"作为差异化。 ## 二、星型拓扑：低冗余的代价是中心瓶颈 ### 架构原理 星型（hub-and-spoke / supervisor）里，所有 Agent 只与中央编排器通信，Agent 之间不直连。编排器负责接收、压缩、再分发消息，扇出从 `N(N−1)` 被压缩回 `2N`（N 个 Agent 各上报一次，编排器各下发一次）。LangGraph 的 Supervisor、OpenAI Swarm 的 handoff 路由器都属此类。它本质上是把"广播风暴"换成了"中心压缩"——编排器充当信息漏斗。 ### 代码示例 ```python # LangGraph 风格：Supervisor 星型，编排器裁剪上下文 from langgraph.graph import StateGraph, MessagesState def supervisor(state: MessagesState): # 编排器读取所有Agent结果，但只把摘要写回共享state # 下游Agent拿到的是压缩后的summary，而非全量历史 return {"messages": [compress(state["messages"])]} builder = StateGraph(MessagesState) builder.add_node("supervisor", supervisor) for name in ["research", "analyze", "write", "check"]: builder.add_node(name, agents[name]) builder.add_edge("supervisor", name) builder.add_edge(name, "supervisor") # 星型：都回到中心 ``` ### 优缺点分析 优点是消息量线性可控、上下文被中心化压缩（编排器只把摘要再分发），token 成本最低、信息不重复。缺点是编排器成为**串行瓶颈**：所有协调都得经它一手，端到端延迟 ≈ `N × 单 Agent 推理时间`（N=8 时若每次 2s 就是 16s），且编排器是单点失效——一旦编排器挂了或路由出错，全网停摆。这恰好印证了"拓扑比数量更重要"：同样 8 个 Agent，星型比网状省 3–4 倍 token，但延迟反而更高。 ### 变现/训练营评估 星型最适合做成企业级工作流产品（RPA + LLM），因为它的可控性、可审计性最好——所有决策过编排器，便于日志、合规、回放。训练营可主打"可上生产的 Supervisor 架构"，卖点是从 demo 到 99% 可用。差异化在于编排器的压缩质量与路由准确率，可单独做成一个《Supervisor 路由调优》进阶课。 ## 三、层级拓扑：用深度换扇出，逐层有损 ### 架构原理 层级（hierarchical / tree）拓扑把 Agent 组织成树：一个顶层管理者把任务分给若干小组长，每个小组长再分给若干工人。消息沿树边流动，一轮协调的消息数被压到约 `2(N−1)`（树的总边数），与星型相当；但延迟不再是 `N`，而是 `深度 × 单跳时间`，二叉树深度为 `log₂N`。CrewAI 的 Hierarchical Process、LangGraph 的 Hierarchical Teams 都实现了这种"分组委派"。 ### 代码示例 ```python # CrewAI 风格：层级 Process，逐层委派与汇总 from crewai import Crew, Process crew = Crew( agents=[manager, lead_research, lead_finance, w_search, w_scrape, w_model, w_risk, w_audit], tasks=[decompose_task, *sub_tasks, synthesize_task], process=Process.hierarchical, # 启用树形委派 manager_llm=manager_llm, ) # manager 只跟两个lead对话；lead各自管2个worker # 消息复杂度 ~2(N-1)=14 条，但信息要穿透3层 ``` ### 优缺点分析 优点是消息量与星型一样省、且天然支持规模扩展（子树可独立扩缩容、并行），延迟比星型更低（`log₂N` 跳 vs `N` 跳）。缺点是**逐层有损**：每经过一次委派/汇总，信息都被压缩一次，深度越深保真度越低（这正是"记忆即瓶颈"在多 Agent 里的放大版——共享态每多一层就多一次失真）。N=8、深度 3 时，工人层的一个关键细节传到顶层管理者可能已被压缩 3 次。此外，跨子树的信息孤岛问题突出：两个不相邻子树想共享数据，必须上溯到公共祖先再下发。 ### 变现/训练营评估 层级是大型企业多 Agent 系统的主力架构，适合做"千人级组织 Agent 中台"这类高客单产品。训练营可主打"如何设计不超过 3 层的层级架构以平衡扇出与保真"，差异化是"分层压缩策略"——教在每一层用哪种 prompt 保住关键信息。这是最容易做成咨询 + 实施的组合变现。 ## 四、环形拓扑：消息最省，延迟等于整链 ### 架构原理 环形（ring / pipeline / sequential）里，Agent 按固定顺序首尾相接，任务像接力棒一样从 A1 传到 A2、再到 A3……直到 A_N 再回到起点。一轮协调的消息数仅为 `N`——四种拓扑里最少。代价是**完全串行**：端到端延迟 = `N × 单跳时间`，且没有并行可言。CrewAI Sequential Process、LangGraph 线性图、多数 ETL 式流水线都属此类。 ### 代码示例 ```python # LangGraph 风格：线性流水线，串行接力 builder = StateGraph(MessagesState) steps = ["extract", "clean", "analyze", "visualize", "report"] for i, name in enumerate(steps): builder.add_node(name, agents[name]) if i > 0: builder.add_edge(steps[i-1], name) # 严格顺序 builder.add_edge(steps[-1], END) # 消息数=N=5，但每一步必须等上一步完成 ``` ### 优缺点分析 优点是消息最少、token 最省、状态流转最清晰（每一步的输入就是上一步的输出，无需广播）。缺点是延迟等于整链之和（N=8、每跳 2s 就是 16s，与星型一样慢却没有星型的并行潜力），且**刚性极强**——任意一环变慢或失败，整条链立刻堵死或断裂，无法绕过。环形把"扇出税"压到了最低，却把全部成本转移成了"串行延迟税"和"链路刚性税"。 ### 变现/训练营评估 环形最适合做成确定性强的流水线产品（数据处理、内容生产、报告生成），卖点是好测试、好回滚。训练营可主打"把不确定的多 Agent 变成可预测的流水线"，差异化是"步骤间契约设计"——教每一步输入输出的 schema 固化，让流水线可独立单测。这是最易工程化、最易交付的一类。 ## 五、扇出税实测矩阵：同一任务、四种拓扑、三个规模 下表用确定性消息复杂度模型（非随机基准，公式可复现）测算同一 8-专业-Agent 任务在 N=4/8/16 下的指标。设单条消息上下文 ≈2k token、单 Agent 单跳推理 ≈2s。 | 拓扑 | 消息数公式 | N=4 消息 | N=8 消息 | N=16 消息 | 单轮广播 token(N=8) | 端到端延迟(N=8) | 单点爆炸半径 | |------|-----------|---------|---------|----------|-------------------|----------------|------------| | 网状(扁平) | N(N−1) | 12 | 56 | 240 | ~112k | ~2s(并行) | 低(冗余高) | | 星型(编排器) | 2N | 8 | 16 | 32 | ~32k(中心压缩) | ~16s(串行) | 高(编排器即单点) | | 层级(树) | 2(N−1) | 6 | 14 | 30 | ~28k(逐层压缩) | ~6s(log₂N跳) | 中(子树失效) | | 环形(流水线) | N | 4 | 8 | 16 | ~16k | ~16s(串行) | 高(一环断全断) | 读法有三条：第一，**网状是唯一随 N 平方爆炸的拓扑**，N 翻倍消息涨 4 倍，这就是"雪崩"的数学来源；第二，星型、层级、环形的消息数都是线性级（2N、2(N−1)、N），但各自把成本转嫁到不同维度——星型转嫁到串行延迟、层级转嫁到逐层失真、环形转嫁到链路刚性；第三，**没有免费拓扑**：消息省的延迟长，延迟短的失真高，失真低的爆炸半径大。选型本质是在四个税种（扇出税、串行税、失真税、刚性税）之间做取舍。 ## 六、反模式：跨拓扑的烧钱陷阱 对照"17 种多 Agent 拓扑"里归纳的反模式，四种拓扑各有其招牌坑： - **网状的 max_round 无顶**：不设发言轮上限，GroupChat 可以无限辩论，token 无上限烧穿——与自主体重试无顶同源，但这里烧的是"互相说话"。 - **星型的编排器选错模型**：编排器承载全部路由决策，却用最便宜的模型，路由错误率上升，导致任务走错分支、全部下游 Agent 白跑。编排器应配最强模型，这是"协调层不能省模型"的拓扑版。 - **层级的过深嵌套**：为了"看起来有组织"堆到 4–5 层，信息穿透时被压缩成噪声，底层工人的关键发现永远传不到顶层——层数应硬封顶在 3。 - **环形的硬编码顺序**：把动态任务焊死成固定流水线，一旦某步的输入依赖前两步的输出，流水线无法表达，只能拆成更长的串行链，延迟进一步恶化。 这些反模式的共性是：**工程师凭直觉选了"最熟悉"的拓扑，却没算清该拓扑的扇出税**。 ## 推荐方案：按场景匹配拓扑 - **辩论/头脑风暴/方案评审** → 网状，但必须配 max_round、发言预算、top-k 收件人裁剪三件套，否则别上线。 - **企业工作流/可审计生产系统** → 星型 Supervisor，编排器配最强模型，做好编排器高可用与故障转移。 - **大型组织/需要扩缩容的中台** → 层级，层数封顶 3 层，重点设计层间压缩策略保真。 - **确定性数据处理/内容流水线** → 环形，固化步骤间 schema 契约，把不可预测变可预测。 - **混合现实** → 多数生产系统是"层级 + 局部网状"——顶层用层级委派，叶子节点在小组内用网状辩论，兼顾扇出与并行。这是 2026 年最被低估的组合。 一句话选型口诀：**消息怕多选层级，延迟怕长别用环，可控可审选星型，热闹但贵是网状**。在多 Agent 系统里，拓扑不是实现细节，而是决定 token、延迟、可靠性上限的一级架构决策——拓扑选错，后面所有优化都在还债。 ## 参考来源 1. [How to Scale LLM Agents: Coordination Costs, Topologies, and Real-World Limits — Sparrow Intelligence](https://blog.sparrow.so/scaling-llm-agents-beyond-demos-coordination-costs-topologies-and-what-actually-works/) — 拓扑比 Agent 数量更重要、协调成本增速快于能力，基于 arXiv:2512.08296 的工程化解读 2. [Benchmarking Multi-Agent Architectures — LangChain](https://www.langchain.com/blog/benchmarking-multi-agent-architectures) — 单 Agent / Swarm / Supervisor 在 Tau-bench 上的对比基准与 Supervisor 实现改进 3. [12 Topology Patterns for Multi-Agent Systems — Qualixar](https://qualixar.com/research/blog/12-topology-patterns-multi-agent-systems) — 12 种拓扑（含 Star/Mesh/Hierarchical/Circular）的 ASCII 图示与适用场景 4. [After Analyzing 17 Multi-Agent Topologies — 7 Anti-Patterns — Level Up Coding](https://levelup.gitconnected.com/after-analyzing-17-multi-agent-topologies-7-anti-patterns-that-will-burn-your-budget-28cc6909621c) — 17 种拓扑的 Pareto 前沿与 7 个烧预算反模式 5. [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 生产系统月成本 3200–13000 美元与按模式的成本矩阵 6. [The AI Agent Token Consumption Gap — AgentMarketCap](https://agentmarketcap.ai/blog/2026/04/12/ai-agent-token-consumption-gap-enterprise-agentic-workloads) — Agent 类负载比聊天多消耗 10–100 倍 token 的生产数据 7. [Stop Wasting Your Tokens: Towards Efficient Runtime Multi-Agent Systems — arXiv:2510.26585](https://arxiv.org/abs/2510.26585) — 多 Agent 系统运行时 token 效率优化方法 > [!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 等场景全覆盖。