# 拓扑>模型：多智能体五范式编排税实测 ## 核心发现 2026 年多智能体（Multi-Agent）领域出现一个反直觉的结论：**编排拓扑（orchestration topology）对生产效果的影响，已经压过了模型本身的选择**。AdaptOrch（2026）在 SWE-bench 等基准上证明，仅优化拓扑（而非换更强的模型）就能带来 **12%–23% 的增益**；Google 内部"Agent Bake-Off"用分布式多智能体把同一任务的处理时间从 **1 小时压到 10 分钟（6×）**。与此同时，MAST 团队对 **1,642 条执行轨迹**的解剖显示，失败里 **78% 以上是设计税**——重复步骤、交接失真、提前终止，全部属于"拓扑与流程"问题，而非模型能力问题。 这意味着 2025 年"换更大模型就能解决"的直觉，在多智能体场景里被彻底推翻。本文以 2026 年生产环境实际跑通的 **五范式**——扇出（Fan-out）、流水线（Pipeline）、辩论（Debate）、主管（Supervisor）、群体（Swarm）——为主线，逐一拆解它们的控制流拓扑、"编排税"账单、失败模式与精确反模式，并给出按场景的选型决策树。 ## 五范式多维度对比 | 范式 | 控制流拓扑 | 编排开销 | 成本倍数（vs 单模型） | 主失败模式 | 适用场景 | 2026 原生框架 | |------|-----------|---------|----------------------|-----------|---------|--------------| | Fan-out 扇出 | 并行发散→聚合 | 低 | ~N× | 部分失败聚合（静默残缺） | 多源检索、多文件并行评审 | LangGraph、Claude Agent SDK | | Pipeline 流水线 | 线性链式 | 低 | ~N× | 级联污染（坏中段毒化下游） | 研究→起草→评审→事实核查 | LangChain 1.0、CrewAI | | Supervisor 主管 | 层级委派 | 中 | ~(N+1)× | 过度委派死循环 | 跨域 agent（编码+检索+评审） | 三大框架均原生收敛 | | Debate 辩论 | 多视角+判官 | 高 | Critique ~1.2× / Council ~2.5× | 判官偏置、不收敛循环 | 高风险对外决策 | AutoGen GroupChat | | Swarm 群体 | 动态对等涌现 | 高 | 可变（随种群膨胀） | 抖动、非确定性失控 | 超大规模并行编码 | Kimi K2.5/K2.6（唯一原生） | ## 深度分析 ### 一、AdaptOrch 的颠覆性结论：拓扑才是第一杠杆 AdaptOrch（2026）的核心命题是"**自适应编排（adaptive orchestration）> 模型选择**"。它不换底座模型，而是让系统在运行时根据任务特征自动切换拓扑形态，在 SWE-bench 等基准上稳定拿到 12%–23% 的增益。这个结论之所以重要，是因为它直接命中了多智能体系统最贵的那个错觉：团队遇到效果不达标，第一反应往往是"加更大模型"，而 AdaptOrch 证明，在很多情况下，**正确的做法是换一种连接方式**。 这与 Google Bake-Off 的 6× 提速相互印证——提速主要来自把串行单 agent 拆成分布式多 agent 并发，而非模型代际跃迁。对工程团队的直接含义是：在多智能体架构里，**拓扑是收益弹性最大的变量**，模型反而接近边际。因此 2026 年的架构评审，应当把"用了哪种范式、为什么用它"作为第一性问题，而不是"用了哪个模型"。 ### 二、五范式的"编排税"账单：成本不是线性的 每种范式都自带一笔可预测的"编排税"。以单模型调用为 1.0× 基线：Pipeline 与 Fan-out 大致是 ~N×（N 为分支/阶段数），开销可控；Supervisor 因为多了一个协调者，落到 ~(N+1)×；真正昂贵的是 Debate——微软 Copilot Council 跑 GPT-5.4 与 Claude Sonnet 4.6 并行、再加判官模型，**成本约 2.5×**；轻量的两阶段 Critique 变体也要 **~1.2×（+20%）**；Swarm 则是"可变"——随动态 agent 种群膨胀，**默认上不封顶**。 关键认知：Debate 的 2.5× 是**常量级**的固定税，不是"按需付费"。把它当默认的质量增强器，是对成本结构的误判。Digital Applied 的判断很直白——Debate 只应留给"高风险、对外可见、且多视角真正有价值"的决策，常规问答与内部摘要根本不配这个溢价。每超过单模型的范式，都应在 harness 里焊死成本上限（Claude Agent SDK 默认每子 agent ~25 轮、LangGraph 的 step 预算、Swarm 的种群规模上限），而不是事后看账单报警。 ### 三、Fan-out vs Pipeline：开销相同，失败模式完全相反 这是被混淆得最狠的一对。两者编排开销都标注为"低"，但失败模式是镜像的。**Pipeline 的失败是级联式**——一个坏的中段输出会污染它之后的所有阶段；一个没有逐阶段校验的 Pipeline，会"愉快地"产出一个建立在第一阶段幻觉之上的、非常漂亮的最终答案。**Fan-out 的失败是部分式**——某个分支报错，你必须预先决定：整体失败、返回部分结果、还是只重试失败分支。大多数实现根本没在设计期声明这个策略，于是出现"看起来完整、其实是残缺"的静默结果。 这正是"五范式而不是三范式"的工程理由。把 Fan-out 折进 Pipeline（所谓"并行 pipeline"）、把 Debate 折进 Supervisor（所谓"多 supervisor"），会抹掉那些在生产里真正要命的差异：**级联污染要靠逐阶段 schema 校验治，部分失败要靠聚合器的显式处理逻辑治，二者不是一回事**。LangGraph 还有一个隐蔽陷阱：并行 fan-in 节点若漏标 `defer=True`，合成器会在所有 Send 分支结束前就触发，产出空聚合。 ### 四、Supervisor 成为 2026 默认：收敛与硬约束 三大框架在 2026 不约而同收敛到 Supervisor 拓扑：Claude Code 的 subagent（`.claude/agents/.md`）、LangGraph 的 Supervisor 一等公民模式、OpenAI Agents SDK 的 handoffs，本质都是"主管委派、子 agent 执行、主管合成"。对绝大多数跨域 agent 任务（编码+检索+评审），Supervisor 是**正确的起手式**——它的失败模式（过度委派循环）最被理解，框架支持最厚。 但 Supervisor 有一条容易被忽视的硬约束：**Claude Agent SDK 的 subagent 只有一层深，不能再生 subagent**。这是一个当前实现的硬架构边界。任何假设"递归委派"的 supervisor 拓扑（supervisor-of-supervisor）在这套环境里会直接塌掉。OpenAI Agents SDK 的 handoffs 同理——它是 supervisor 原语而非对等 swarm。所以"层级嵌套"在 2026 主流 SDK 里其实是个**纸面能力**，真正能跑递归层级的，只有 LangGraph 的 sub-graph 与 Kimi 的原生 PARL。 ### 五、Debate 的真实价格：2.5× 不是免费质量升级 Debate 把同一个问题发给多个 agent，等它们分歧，再由判官裁决。它的成本结构天生 ≥2×——还没算判官。微软 Copilot Council 是 2026 的标杆实现：GPT-5.4 + Claude Sonnet 4.6 并行，再用判官模型汇总共识、标出分歧、提炼各自独到见解，整体 **~2.5× 单模型成本**。判官成本本身不可省。 Debate 有两个杀手级失败模式。第一是**判官偏置**：判官若稳定偏好某模型的风格或自信度（而非准确度），辩论会产出"更高置信度的错误答案"——这比单模型错得更危险。第二是**不收敛仲裁循环**：两 agent 持续分歧、判官无法裁决，一些实现就会无限循环。Digital Applied 的纪律是：**在 harness 里设死最大轮数**，且只在赌注配得上 2.5× 溢价时启用。一个经验阈值——同题是否真的需要"不同模型的不同视角"，如果答案不是肯定的，就退回单模型或 Pipeline。 ### 六、Swarm 的门槛线：不到 50 个并行任务别用 Swarm 是 2026 的前沿范式，也是门槛最高的一种。它的种群大小在设计期不固定——agent 随负载动态生灭，通过共享内存或消息总线协调，而不是固定 supervisor。**真正以一等公民原生支持 swarm 的，只有 Kimi**：K2.5 用 Parallel-Agent Reinforcement Learning（PARL）协调最多 **100 个**专用子 agent、并行 1,500 次工具调用；K2.6（2026-04-20 发布）推进到 **300 agent**、支持 12 小时自治编码会话。传统框架里，AutoGen v0.4+ 的事件驱动 actor 模型是最成熟的"swarm 近似"。 Swarm 的反模式极其明确：**并行任务少于 50 个时不要用 swarm**。动态生灭、共享内存管理、种群生命周期、竞态防护，这些工程开销只有在真正规模化时才摊得薄。3–10 个并发 agent，用 Supervisor + Fan-out 分支，更简单、更便宜、更可调试。OpenAI 早年那个叫 Swarm 的实验库已在 2024 年归档，Agents SDK 的 handoffs 继承的是 supervisor 而非 swarm——别被名字误导。 ### 七、MAST 失败解剖：78% 是"设计税"，交接污染最致命 MAST 团队解剖 1,642 条执行轨迹得出的失败分布，是理解多智能体为何"难"的最硬数据。**系统设计问题占 41.77%**（重复步骤、选错工具、上下文溢出、缺终止条件）；**agent 间失准占 36.94%**（交接时丢失上下文，幻觉变成下一个 agent 的"事实"）；**任务验证失败占 21.30%**（提前终止、验证不全）。三者相加 **接近 80% 的失败，根因都在拓扑与流程设计，而非模型**。 最致命的是那 36.94% 的交接失真：Agent A 幻觉出错误数据，原样传给 B 和 C，整个系统就在错误前提上继续构建。治法是**每次 handoff 都做 schema 校验 + 置信度门控（低于 0.7 拒绝）**，把污染掐在交接边界。配合 macgpu 给出的工程硬约束——`MAX_ITERATIONS=10`、`MAX_TOOL_CALLS=20`、`MAX_TOTAL_TOKENS=50,000`、LangGraph 的 `interrupt_before=["high_cost_tool"]`——这套护栏能把失控循环和级联污染压住。另一个反差数字：**57% 的组织已在生产跑 agent，但只有 8% 装了 LLM 可观测**；错误返回 HTTP 200，仪表盘一片绿，输出却是错的。 ### 八、MCP + A2A 双协议层：拓扑能跨进程的前提 五范式能从"单进程演示"走向"跨组织生产"，前提是通信协议标准化。2026 年这套协议收敛为两层，均归入 Linux Foundation 的 Agentic AI Foundation：**MCP（纵向）** 由 Anthropic 主导，统一 agent 访问工具/数据库/API 的方式，"写一次，到处用"；**A2A（横向）** 由 Google 2025-04 开源、2026 发布 v1.0，已有 Atlassian、Salesforce、SAP 等 50+ 合作伙伴，标准化任务委派、能力发现与状态同步——每个 agent 发布 `/.well-known/agent.json` 的 Agent Card，编排者通过 JSON-RPC 2.0 的 `message/send` 委派。 这套双协议层的意义在于：它让"拓扑"这个抽象第一次能脱离单一框架的进程边界。Supervisor 可以在本地 Mac 跑编排，把 5 个 worker + MCP 工具簇推到远端节点，靠 A2A over HTTP 委派——这是把"跑得起 demo"变成"跑得起生产"的物理前提。一个实测案例：5 worker 在 32GB Mac 上并发 fan-out，统一内存撞到 28GB、节流、P95 从 8s 飙到 45s；迁移到远端 64GB 节点后 P95 回到 12s、token 成本降 35%（无节流重试）。 ## 架构与决策可视化 **五范式控制流拓扑对比：** ```mermaid graph LR subgraph Fan-out["Fan-out 扇出 并行低开销"] F0[协调者] --> F1[分支A] F0 --> F2[分支B] F0 --> F3[分支C] F1 --> FA[聚合器] F2 --> FA F3 --> FA end subgraph Pipeline["Pipeline 流水线 线性低开销"] P1[检索] --> P2[分析] --> P3[起草] --> P4[评审] end subgraph Supervisor["Supervisor 主管 层级中开销"] S0[主管] --> S1[检索子agent] S0 --> S2[编码子agent] S0 --> S3[评审子agent] S1 --> S0 S2 --> S0 S3 --> S0 end subgraph Debate["Debate 辩论 多视角高开销~2.5x"] Q[同一问题] --> D1[模型A] Q --> D2[模型B] D1 --> JG[判官] D2 --> JG end subgraph Swarm["Swarm 群体 动态高开销"] MB[(共享内存/消息总线)] <-.-> SW1[agent] MB <-.-> SW2[agent] MB <-.-> SWN[...N agent] end ``` **选型决策树（macgpu 2026 生产版）：** ```mermaid flowchart TD START([任务进入]) --> Q1{有严格线性依赖?} Q1 -->|是| Q2{子任务能并发?} Q2 -->|否| R1[Sequential Pipeline] Q2 -->|是| R2[Parallel Fan-out + Pipeline] Q1 -->|否| Q3{有决策权威 agent?} Q3 -->|是| Q4{需要大规模子团队?} Q4 -->|否| R3[Supervisor-Worker] Q4 -->|是| R4[层级 Supervisors-of-Supervisors] Q3 -->|否| Q5{长时异步工作?} Q5 -->|是| R5[Blackboard 黑板架构] Q5 -->|否| Q6{agent ≤ 5 ?} Q6 -->|是| R6[Swarm + 终止条件] Q6 -->|否| R7[重构为层级] R3 -.默认起手.-> R3 classDef rec fill:#e8f5e9,stroke:#2e7d32,stroke-width:2px; class R3,R1,R2 rec; ``` ## 推荐方案（按场景） **1. 不确定时先 Supervisor。** 它是 2026 原生支持最厚、失败模式最被理解的范式，对跨域任务（编码+检索+评审）是正确的默认。记住 Claude Agent SDK subagent 一层深、默认 ~25 轮，别设计递归委派。 **2. 生产甜点区是 3–8 个 agent。** 把两步 LLM 链拆成八个 agent 是典型的过度工程。先从 Sequential Pipeline 起步，验证核心价值，再按决策树上调复杂度。 **3. 高风险对外决策才上 Debate。** 把它当 2.5× 常量税对待，设死最大轮数防不收敛，并在 harness 里监测判官偏置。常规内容与内部摘要用单模型或 Pipeline。 **4. Swarm 留给真规模。** 并行任务低于 50 不要碰；只有 Kimi K2.5（100 agent）/K2.6（300 agent）这种原生 PARL 才让 swarm 摊得薄。传统框架用 AutoGen v0.4+ 的 actor 模型近似。 **5. 每次交接焊护栏。** handoff 处 schema 校验 + 置信度门控（<0.7 拒绝），全局 `MAX_ITERATIONS`/`MAX_TOOL_CALLS`/`MAX_TOTAL_TOKENS` 上限，并行 fan-in 节点标 `defer=True`——这四样能把 MAST 那 78% 的设计税压掉一大半。 **6. 双协议层打底。** MCP（纵向工具）+ A2A（横向 agent）让拓扑能跨进程、跨组织。编排留本地、worker 推远端，是规模化后的标准拓扑部署形态。 一句话收口：2026 年多智能体的胜负手不在模型清单，而在**你画的拓扑图对不对**——选错范式，比选错模型亏得多。 ## 参考来源 1. [Multi-Agent Orchestration: 5 Patterns That Work in 2026 — Digital Applied](https://www.digitalapplied.com/blog/multi-agent-orchestration-5-patterns-that-work) — 五范式（fan-out/pipeline/debate/supervisor/swarm）的成本倍数、反模式与 9 框架兼容矩阵，含 Copilot Council ~2.5× 成本数据。 2. [Multi-Agent AI Architecture in Production: 2026 Guide — MACGPU](https://macgpu.com/en/blog/2026-0622-multi-agent-ai-architecture-production-guide.html) — 六编排范式、LangGraph/CrewAI/AutoGen 对比、MCP+A2A 双协议层、MAST 1,642 轨迹失败分布（设计 41.77%/失准 36.94%/验证 21.30%）、AdaptOrch 12–23% 增益与 Google 6× 提速。 3. [Multi-Agent Orchestration Patterns: Supervisor vs Swarm vs Hierarchical — QubitTool](https://qubittool.com/blog/multi-agent-orchestration-patterns) — Supervisor/Swarm/Hierarchical 三种控制模式（集中/分散/层级）的权衡与生产适配性深度对比。 4. [Multi-Agent Orchestration Pattern Decision Guide (2026) — M2ML](https://m2ml.ai/agent/ClaudeResearcher/knowledge/multi-agent-orchestration-pattern-decision-guide.md) — 按用例特征（可并行性/同题多视角/种群固定与否）选型的决策框架。 5. [Multi-Agent AI Systems Explained: 2026 Patterns — DecodeTheFuture](https://decodethefuture.org/en/multi-agent-systems-explained/) — supervisor/swarm/orchestrator-worker 拓扑与 LangGraph vs CrewAI 选型补充，含 Kimi K2.6 swarm 规模数据。 > [!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 等场景全覆盖。