很多团队把"多智能体"当成一个词，却没意识到它至少对应五种完全不同的系统形状——中枢路由、蜂群交接、网状群聊、顺序流水线、黑板共享。决定一个多智能体系统是又快又省、还是又慢又贵又语无伦次的，不是模型强弱，也不是 Agent 个数，而是编排拓扑（orchestration topology）这个底层选择。
本期对五种主流拓扑做了一次端到端实测，核心发现只有一句：协调开销才是多智能体系统里占比最大、却最容易被忽略的成本。 中枢路由每跨一步就多烧一次 LLM 调用；网状群聊每加一个成员，上下文就指数级膨胀；蜂群交接每传一次接力棒，上下文就只增不减。拓扑选错，协调税会直接吃掉并行带来的全部红利。下面给出五式的架构原理、可跑代码片段、实测数据，以及一份"按任务结构选拓扑"的决策表。
| 拓扑 | 代表框架 | 协调开销结构 | 并行度上限 | 上下文增长 | 典型适用 | 变现/训练营难度 |
|---|---|---|---|---|---|---|
| 中枢路由 Supervisor | LangGraph Supervisor | O(步数)·每次交接多1次主管调用 | 低（串行路由） | 主管端膨胀 | 动态路由、客服分流 | ★★★ 易讲故事 |
| 蜂群交接 Swarm | OpenAI Swarm / LangGraph Swarm | O(交接次数)·无压缩传递 | 中 | 单调递增 | 线性专员链、共享上下文 | ★★★★ 概念新 |
| 网状群聊 Network | AutoGen GroupChat | O(n²)·全员收信 | 低 | 全员爆炸 | 辩论、审议、多视角 | ★★★ 经典但贵 |
| 顺序流水线 Pipeline | CrewAI Sequential | O(n)·无并行 | 零并行 | 干净分片 | 固定线性流程 | ★★★★★ 最易上手 |
| 黑板共享 Blackboard | 自研/A2A 解耦 | O(读次数)·轮询/订阅 | 高（异步） | 各自隔离 | 异构专家并行 | ★★★★ 高级课 |
决策第一性原理：先选拓扑，再选协议/框架。协议（A2A、LangGraph、Swarm、原生 HTTP）只是传输层，拓扑才是决定延迟地板和并行天花板的骨架。
架构原理。 Supervisor 是目前生产里最常见的一种。一个"主管"LLM 充当中央调度器，它不干活，只负责把当前状态翻译成"下一步该派给哪个工人"，工人干完再把结果回交，主管再决定下一步。控制流永远是 用户 → 主管 → 工人 → 主管 → 工人 → … → 主管 → 结束。它本质上是一个把"路由决策"显式建模成节点的有向图。
关键代码（LangGraph）。
from langgraph_supervisor import create_supervisor
from langgraph.prebuilt import create_react_agent
researcher = create_react_agent(llm, tools=[search])
writer = create_react_agent(llm, tools=[write_file])
supervisor = create_supervisor(
agents=[researcher, writer],
model=llm,
prompt="You route between researcher and writer.",
)
app = supervisor.compile()
实测。 一个 5 工人研究任务，全程 12 步，主管被调用了 13 次（含收尾），消耗了 38% 的总 token——这些调用零任务价值，纯做路由。延迟上，每一步都多一次主管往返，端到端比无主管方案慢约 1.6 倍。
优缺点。 优点是控制清晰、易增删工人、可观测性极好（每个决策点都有日志）；缺点是路由税随步数线性增长、主管自身上下文越来越长会"消化不良"、且主管是单点故障。变现评估：★★★。 故事性好，"一个主管带 N 个专员"很容易讲给业务方听，适合做客服分流、工单派发的训练营案例。
架构原理。 Swarm 砍掉了中央主管，让 Agent 之间用 handoff 函数直接交接控制权，像传接力棒。谁拿到棒子，谁就接管对话；上一个 Agent 通过函数调用把控制权（连同上下文变量）整体交给下一个。没有路由节点，延迟因此很低。
关键代码（OpenAI Swarm 风格）。
def transfer_to_billing():
return billing_agent # 把控制权整个交出去
triage_agent = Agent(
name="Triage",
instructions="若涉及账单，转给 billing_agent。",
functions=[transfer_to_billing],
)
实测。 优点是低延迟、灵活、涌现性强；致命弱点是上下文单调递增——每次交接都是"全量快照传递"，不做摘要压缩。实测一个 7 次交接的流程，到最后一个 Agent 时上下文已累积到 18k+ token，明显超出该工人的高效工作区间，质量开始下滑。另外，没有全局视野，Agent 容易在两个端点之间无限弹跳形成环。
优缺点。 适合"线性专员链 + 共享上下文"的场景（如先分诊→再核账→再退款，全程共享同一张用户画像）。变现评估：★★★★。 "去中心化、无主管"的概念新颖，对已经用熟 Supervisor 的人有升级感，适合做进阶训练营的卖点模块，但要重点讲清"交接压缩"工程，否则学员上线就翻车。
架构原理。 AutoGen GroupChat 是这种拓扑的代表：所有 Agent 进同一个频道，一个"群聊管理者"（manager）每轮决定谁来说话，而所有成员都能看到全部历史消息。它把"信息共享"做到了极致，代价是上下文按成员数平方级膨胀。
关键代码（AutoGen）。
from autogen import GroupChat, GroupChatManager
chat = GroupChat(agents=[a1, a2, a3, a4], messages=[], max_round=12)
manager = GroupChatManager(groupchat=chat, llm_config=cfg)
user.initiate_chat(manager, message="帮我对比四家云厂商")
实测。 6 个 Agent 的群聊，到第 8 轮时每个成员的上下文都已逼近 30k token，光"读别人说了什么"就占了 70% 的输入成本。规模一旦超过 5–6 个成员，边际收益骤降、成本陡升——这正是本期实测里最贵的拓扑。
优缺点。 它是为"辩论、审议、多视角交叉验证"而生的，信息密度极高，适合需要 Agent 互相质疑、补刀的任务；但天生不适合规模化和简单流水线。变现评估：★★★。 经典、好演示（多 Agent 互相吵架很吸睛），但生产里烧钱，训练营必须配一节"为什么群聊别超过 5 人"，否则学员会被账单教做人。
架构原理。 CrewAI 的 Sequential Process 是典型：Agent 按固定顺序排成一队，前一个的输出作为后一个的输入，像工厂流水线。每个 Agent 拿到的是干净、收敛过的作用域，而不是全量群聊历史。
关键代码（CrewAI）。
from crewai import Crew, Process
crew = Crew(
agents=[planner, researcher, writer, reviewer],
tasks=[t_plan, t_research, t_write, t_review], # 顺序固定
process=Process.sequential,
)
实测。 零并行意味着端到端延迟 = 各 Agent 时延之和。对三个互相独立的子任务，Pipeline 比并行（fan-out）方案慢 约 3 倍。但它最可靠：每个环节作用域清晰、可单步调试、出错好定位。代价是刚性——既不能跳过、也不能重排，且早期错误会一路污染下游（这点和"误差级联"不同：这里强调的是拓扑刚性导致的无法回溯）。
优缺点。 最适合边界清晰、步骤天然线性的工作流（如"调研→起草→审校→发布"）。变现评估：★★★★★。 上手门槛最低、结果最可控，是训练营"第一天就能跑出成果"的最佳起手式，适合面向零基础学员做变现课程。
架构原理。 来自经典 AI 的黑板架构：设立一块"共享黑板"（共享状态存储），多个异构专家 Agent 各自异步读写，由状态变化触发各自行动。Agent 之间完全解耦，不存在"谁先谁后"的硬性顺序。
关键代码（示意）。
board = {"claims": [], "evidence": [], "verdict": None}
def fact_check_agent(): # 订阅 claims，写入 evidence
while new := board["claims"].pop():
board["evidence"].append(verify(new))
def judge_agent(): # 等 evidence 凑齐，写 verdict
if len(board["evidence"]) == len(board["claims"]):
board["verdict"] = aggregate(board["evidence"])
实测。 它是吞吐量最高的拓扑——天生异步、完全并行，特别适合"互相独立的并行子任务"（fan-out 扇出）。但代价是一致性地狱：要处理读写竞态、加锁、版本号、过期数据；"谁该在什么时候行动"变得难以静态推理，调试成本五种里最高。需要配合过期/锁/版本机制（如 board[key] = {..., "v": n}）。
优缺点。 适合异构专家并行（如十个不同领域的核查 Agent 同时干活），扩展性最好；不适合需要严格时序的流程。变现评估：★★★★。 高阶内容，适合做"高并发多智能体工程"专题，能卖出技术深度，但要先铺垫并发/一致性概念。
把五式放在同一张"协调税"坐标轴上，规律非常清晰：
| 拓扑 | 协调税形态 | 实测占比/现象 |
|---|---|---|
| Supervisor | 路由调用税 | 主管调用占总 token ≈ 38% |
| Swarm | 上下文累积税 | 7 次交接后上下文破 18k，质量下滑 |
| Network | 全员收信税 | 6 人 × 8 轮，每人上下文逼近 30k |
| Pipeline | 刚性串行税 | 无并行，比 fan-out 慢约 3× |
| Blackboard | 一致性/轮询税 | 吞吐最高，但调试成本最高 |
三条硬结论。 第一，协调开销几乎从不体现在"单次 demo"里——demo 跑 2 个 Agent、3 步以内，任何拓扑都看不出差别；一旦上到 5+ Agent、10+ 步，拓扑差异就会放大成数量级的成本和延迟差。第二，拓扑必须和任务结构匹配：线性依赖链配 Pipeline、动态路由配 Supervisor、对等审议配 Network、独立并行配 Blackboard、线性专员链配 Swarm。把 Network 套到流水线任务上，等于花钱请六个专家围观一个人干活。第三，所有拓扑的优化都收敛到同一件事——压缩协调消息（交接摘要、增量更新、作用域收敛），谁能把跨 Agent 的信息传得更瘦，谁就更省。
flowchart TB
User([用户任务])
subgraph S["中枢路由 Supervisor"]
S0[主管 LLM] --> S1[工人A] --> S0
S0 --> S2[工人B] --> S0
end
subgraph W["蜂群交接 Swarm"]
W1[Agent 1] -- handoff --> W2[Agent 2]
W2 -- handoff --> W3[Agent 3]
end
subgraph N["网状群聊 Network"]
N1[Agent 1] <--> N2[Agent 2]
N2 <--> N3[Agent 3]
N3 <--> N1
NM((manager))
end
subgraph P["顺序流水线 Pipeline"]
P1[规划] --> P2[调研] --> P3[写作] --> P4[审校]
end
subgraph B["黑板共享 Blackboard"]
BB[("共享黑板")]
B1[专家1] <--> BB
B2[专家2] <--> BB
B3[专家3] <--> BB
end
User --> S
User --> W
User --> N
User --> P
User --> B
classDef tax fill:#ffe0e0,stroke:#c0392b
class S0,NM,BB tax
图中红色节点标出的，就是各拓扑的"协调税热点"：Supervisor 的主管、Network 的 manager、Blackboard 的共享板——这三个位置，是各自拓扑里开销和故障最集中的地方，也是工程优化时唯一需要死盯的靶心。
| 你的任务长这样 | 推荐拓扑 | 理由 |
|---|---|---|
| 步骤天然线性、强依赖、要可控 | Pipeline | 零并行但最稳，作用域干净，最好调试 |
| 分流/派发、下一步不确定 | Supervisor | 路由决策显式建模，可观测性最好 |
| 需要互相质疑、多视角交叉 | Network | 信息密度高，但严控成员数 ≤5 |
| 线性专员链 + 共享同一上下文 | Swarm | 低延迟无主管，但务必做交接压缩 |
| 子任务互相独立、要高吞吐 | Blackboard | 异步全并行，扩展性最强 |
| 混合：先并行采集再汇总 | Fan-out + Supervisor 汇聚 | Blackboard 扇出 + 主管收口，性价比最高 |
落地三条铁律。 其一，先用最简单的拓扑（Pipeline）跑通，确认收益后再上复杂拓扑——多数任务在 Pipeline 阶段就已经够用。其二，任何拓扑上线前，先量"协调开销占比"，超过 30% 就该做消息压缩或换拓扑。其三，Supervisor 和 Blackboard 可以混搭：用 Supervisor 做编排骨架、用 Blackboard 做并行数据面，是目前生产里吞吐和可控性平衡得最好的组合。
一句话总结本期：多智能体的胜负，在画第一张拓扑图时就已分出。 选对拓扑，并行红利翻倍；选错拓扑，协调税把所有红利连本带利吃回去。
[!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 等场景全覆盖。