协调面分野：多智能体五拓扑选型实测

多智能体系统真正的工程难点，从来不在"怎么让几个 Agent 一起说话"，而在协调面（control plane）的拓扑选型。选错了拓扑，要么协调器变成单点瓶颈、要么通信按 N² 爆炸、要么信用分配（credit assignment）根本无法回溯。本期基于 2026 年 1 月的编排综述（arXiv:2601.13671）与 Google A2A 协议官方规范，把五种主流编排拓扑——Orchestrator-Worker、Supervisor-Hierarchical、Pipeline、Mesh、Swarm——拆到协调面与数据面两个层面实测，并验证 A2A 协议如何用"不透明联邦"把进程内拓扑升级为跨框架的网络级拓扑。结论先行：拓扑不是装饰，而是决定系统协调税、容错半径、可审计性的头号架构变量，且 A2A 正在让"拓扑选型"从一次性设计决策，变成运行时可协商的能力。

一、五拓扑协调面横向对比

拓扑	协调面位置	通信复杂度	单点风险	可审计性	典型适用
Orchestrator-Worker	中心扇出	O(N)（线性）	高（中心宕即全瘫）	强（全经中心）	动态子任务拆分、研究类
Supervisor-Hierarchical	递归委托树	O(N·log N) 量级	中（子树可隔离）	强（逐层归因）	大规模、可分区任务
Pipeline	串联无中心	O(N)	低（可旁路）	强（线性因果链）	ETL、内容生产、审核流
Mesh	点对点全连接	O(N²)	低	弱（消息风暴）	稳定小团队、辩论/共识
Swarm	去中心化 handoff	O(N)～O(N²)	极低	弱（控制流涌现）	对话型、上下文移交

这张表背后的核心洞察是：协调面越集中，可审计性越强、容错越差；协调面越分散，弹性越高、因果链越难重建。 没有一种拓扑同时占满"高容错 + 强可审计 + 低协调税"，这正是编排层存在的全部意义——它就是在三者之间做工程取舍。

二、Orchestrator-Worker：协调器的扇出税与单点墙

这是 2024–2025 年最被滥用的拓扑，几乎所有"快速搭建多智能体"教程都在用它。结构上是一个 Orchestrator 把任务拆成若干子任务，扇出给 N 个 Worker，再回收结果。它的协调面就是 Orchestrator 本身——所有上下文、所有归并逻辑、所有重试决策都过这一个节点。

实测上，这套结构的协调税随 N 线性增长：每多一个 Worker，Orchestrator 的上下文窗口要塞进一份子任务规格 + 一份回执，归并时还要做一轮排序/去重/冲突裁决。这本身还好，真正的杀手是单点墙——Orchestrator 的 LLM 一旦出现规划漂移（把本该并行子任务误判成串行、或漏调度某个 Worker），整个系统静默丢失一片工作，且因为回执结构良好，外面完全看不出来。arXiv:2601.13671 把这类风险归因到"planning 层缺乏 policy enforcement"，即协调器既是规划者又是执行者，没有外部约束。

# Orchestrator-Worker 的协调面：一切经中心，归并即瓶颈
def orchestrator(task):
    subtasks = planner.decompose(task)          # 规划：中心决策
    results  = [worker.run(s) for s in subtasks] # 扇出：O(N)
    return reduce(merge, results)               # 归并：冲突裁决在中心

变现评估：作为训练营入门课极佳——5 分钟出一个能跑的 demo。但必须配套讲"协调器规划漂移"的复现实验，否则学员上线即踩雷。把它包装成"动态任务拆分"产品时，要强制加外部 Policy 层校验拆分的完备性。

三、Supervisor-Hierarchical：递归委托与信用归因

层级拓扑把 Orchestrator-Worker 递归化：顶层 Supervisor 委托给中层 Supervisor，中层再委托给底层 Worker，形成一棵委托树。它的协调面是分布式的——每一层只管自己那一段，子树故障可以被父节点捕获并重派，天然带分区容错。

这种结构的最大价值不在弹性，而在信用分配（credit assignment）。当最终结果出错，归因可以沿着委托树逐层回溯：哪一层分解失当、哪个子任务失败、谁重试了几次，全部有结构化记录。这对企业落地是刚需——审计、合规、成本分摊都依赖这条因果链。代价是协调面开销呈 O(N·log N)，因为每一层都要做一轮上下文压缩和状态汇报，深度每加一层，端到端延迟和 Token 成本都上一个台阶。

# 层级委托：信用沿树回溯，深度受成本约束
class Supervisor:
    def __init__(self, children, depth):
        self.children, self.depth = children, depth
    def run(self, task):
        for child in self.children:
            try:
                return child.run(task)          # 委托向下
            except SubTaskError as e:
                self.escalate(e)                # 归因沿树向上

变现评估：这是最该做成"企业级多智能体"卖点的拓扑，因为信用归因直接对应可审计、可合规、可计费三大企业诉求。训练营层级里它属于进阶课，可以专门讲"如何用层级树做成本分摊和故障隔离"，比泛泛讲架构有溢价。

四、Pipeline：有界协调面的因果链

流水线拓扑把 Agent 串成一条链，前一个的输出是后一个的输入，没有中心协调器——协调面被"溶解"进了数据流本身。这是五种拓扑里协调面最干净的一种：因果链是严格线性的，A→B→C→D，任何一步出错都能精确定位，不需要额外的归并逻辑。

代价是延迟累积与背压。每一段 Agent 都是一次 LLM 往返，链上 6 段就是 6 次串行延迟，端到端延迟等于各段之和而非最大值；且如果某一段变慢，前一段的中间结果会堆积，形成背压。另一个隐性风险是语义漂移——每经过一个 Agent，上下文会被重新表述一次，链路越长，最初意图被稀释得越厉害，末端 Agent 可能完全脱离原始任务。

# Pipeline：协调面溶解进数据流，延迟线性累积
def pipeline(task, stages):
    state = task
    for stage in stages:
        state = stage.run(state)   # 前段输出=后段输入
    return state

变现评估：最适合做成"内容生产线""审核流水线""报告生成链"这类产品——边界清晰、可计价、容错简单。作为训练营案例，它特别适合讲"背压与语义漂移"两个工程细节，能让学员真正理解链式拓扑不是把 prompt 串起来那么简单。

五、Mesh：N² 通信爆炸与小团队天花板

网状拓扑里每个 Agent 都能直接和任何其他 Agent 对话，没有中心、没有固定方向。它的协调面是完全分散的，弹性极高——任意节点离线，其余节点仍能协作。问题在于通信复杂度是 O(N²)：N 个 Agent 两两之间都可能有消息往来，上下文同步、一致性维护、重复消息过滤全都指数级膨胀。

这给了 Mesh 一道硬天花板：它只适合"稳定的小团队"。N≤5 时辩论、共识、多视角交叉验证非常有效；N 一旦上到两位数，消息风暴会让每个 Agent 的上下文被噪声淹没，且因果链彻底无法重建——你再也说不清一个结论是被谁、经过哪条路径推导出来的。这也是为什么很多 Mesh 框架在规模化时被迫退化回 Orchestrator-Worker。

变现评估：Mesh 适合做"多视角验证""辩论式决策""红蓝对抗"这类特定产品，强调的是多样性而非规模。训练营里它要和"共识幻觉"风险绑讲——Mesh 的 N² 通信也意味着错误观点的 N² 传播，盲从税会放大。

六、Swarm：去中心化 handoff 的涌现协调

Swarm 拓扑（OpenAI Swarm 范式）用 handoff 机制做协调：每个 Agent 完成自己那一段后，把上下文"移交"给下一个最合适的 Agent，没有中央调度器，控制流是涌现出来的。它的协调面是完全去中心的，弹性接近 Mesh，但通信是 O(N) 量级——因为同一时刻只有持球的那一个 Agent 在活动。

Swarm 的工程魅力在于上下文随控制流流动：状态不需要存到共享黑板（避开了黑板的并发税），谁拿球谁就拥有完整上下文。代价是可审计性最弱——控制流是运行时涌现的，事前无法画出确定的路由图，事后要靠 trace 重建。当一个任务在多个 Agent 之间来回 handoff 多次，"为什么走到了这个 Agent"会成为一笔糊涂账。

变现评估：Swarm 最适合"对话型助手""客服多技能路由"这类产品，强在自然、低协调税。它的训练营卖点应该聚焦"handoff 的契约设计"——移交时传什么、不传什么、如何避免上下文污染，这是 Swarm 落地的真功夫。

七、A2A 联邦拓扑：不透明协调的范式跃迁

前面五种拓扑都是进程内拓扑——所有 Agent 跑在同一个框架、同一份内存里，互相能看见对方的内部状态。2025 年 4 月 Google 联合 50+ 合作伙伴推出的 A2A（Agent2Agent）协议，把拓扑提升到了网络级：不同框架（LangGraph、ADK、CrewAI）、不同厂商、不同服务器上的 Agent，第一次能像 Web 服务一样互相发现、协商、协作。

A2A 的革命性在于不透明性（opacity）这一设计原则：协作的 Agent 之间不暴露彼此的内部状态、记忆、工具实现。一个 Agent 对另一个 Agent 而言就是一个黑盒服务，只通过协议规定的接口交互。这彻底改变了拓扑选型——过去 Mesh/Orchestrator 之所以需要进程内通信，是因为要共享上下文；现在 A2A 让"联邦"成为第一公民，跨组织的 Agent 可以组成一个逻辑上的 Swarm 或 Hierarchical，而物理上完全隔离。

A2A 用四个机制支撑联邦拓扑：（1）Agent Card——一个 JSON 能力清单，托管在 /.well-known/agent.json，让 Agent 互相发现彼此能干什么；（2）Task 生命周期——把一次协作建模为有状态的 Task，从 submitted 走到 completed/failed/canceled；（3）Capability Discovery + UX Negotiation——协商用文本、表单还是富媒体交互；（4）基于现有标准——HTTP + JSON-RPC + SSE，零成本接入企业 IT 栈。

// Agent Card：联邦拓扑的"名片 + 能力清单"
{
  "name": "travel-booking-agent",
  "description": "Books flights, hotels, and activities",
  "url": "https://booking.example.com/a2a",
  "skills": [
    { "id": "book_flight", "name": "Book Flight",
      "description": "Search and reserve flights" }
  ],
  "defaultInputModes":  ["text"],
  "defaultOutputModes": ["text", "data"]
}

变现评估：这是 2026 年最有溢价的方向。把"如何用 A2A 把内部 Agent 接入外部生态"做成企业咨询/训练营，正好踩在协议从草案走向生产就绪（Google 承诺"later this year"生产版）的时间窗。对企业客户而言，"不暴露内部模型和工具就能加入联邦"是直击安全与 IP 保护的卖点。

八、Task 不可变性 + 并行 follow-up：可审计性的工程基石

A2A 的 Task 模型里有两个被低估的工程细节，恰恰是多智能体可重放性的关键。

第一是 Task 不可变性：一旦 Task 进入终态（completed/canceled/rejected/failed），它永远不会重启。任何后续的细化、追问、修正，都必须在同一个 contextId 下发起新的 Task，并可以用 referenceTaskIds 指回原 Task。这看似死板，实则是可审计性的基石——每个 Task 是一个不可变的、可独立引用的工作单元，输入到输出的映射永远清晰。回顾此前"回放失真"的痛点，正是缺乏这种不可变单元导致的：可变状态会让回放无法对齐。A2A 用终态冻结 + contextId 分组，把这条因果链焊死。

第二是 并行 follow-up：同一个 contextId 下可以并发多个 Task，且允许声明依赖。官方文档给的例子是订机票→订酒店→订雪地摩托，酒店和雪地摩托都依赖机票结果，但二者彼此独立可并行。这让多智能体联邦天然支持任务图（task DAG）调度，而不需要额外的编排框架。

// 并行 follow-up：同 contextId 下的任务 DAG
[
  { "task": "book_flight_to_Helsinki", "status": "completed" },
  { "task": "book_hotel",  "ref": ["book_flight_to_Helsinki"], "parallel": true },
  { "task": "book_snowmobile", "ref": ["book_flight_to_Helsinki"], "parallel": true },
  { "task": "add_spa",     "ref": ["book_hotel"], "parallel": true }
]

这背后的三种 Agent 形态也值得记住：Message-only（总是直接回消息，适合简单工具封装）、Task-generating（总是产出 Task，把简单交互也建模成已完成 Task）、Hybrid（先用 Message 协商范围，再发 Task 跟踪执行）。Hybrid 是最贴近真实协作的——先"聊清楚要做什么"再"立项跟踪"，和人工作业的方式一致。

九、MCP × A2A：控制面与数据面的解耦

arXiv:2601.13671 的核心论断是：多智能体编排层需要两个互补的协议——MCP（Model Context Protocol）标准化 Agent 如何访问外部工具和数据，A2A 标准化 Agent 之间如何对等协调、协商、委派。这个二分法可以直接映射到经典系统设计里的数据面 vs 控制面：

这个解耦的工程意义在于：拓扑（A2A）和工具（MCP）可以独立演进。你可以用 A2A 组一个 Hierarchical 联邦，而每个节点的工具集用 MCP 接入，互不耦合。过去多智能体框架把这两者焊死在一起（协调和工具调用共用一套内存和循环），导致换拓扑就得重写工具层。A2A/MCP 分离后，编排层真正成为独立的、可审计的、可治理的一层——这也是综述强调"policy enforcement、state management、quality operations"统一进编排层的设计意图。

flowchart TB
    subgraph CP[控制面 · A2A · 协调]
        direction TB
        ORC[Orchestrator/Supervisor]
        ORC -->|delegate Task| A1[Agent A]
        ORC -->|delegate Task| A2[Agent B]
        A1 <-.handoff / negotiate.-> A2
    end
    subgraph DP[数据面 · MCP · 工具/数据]
        T1[Tool: SQL]
        T2[Tool: Search]
        T3[Tool: API]
    end
    A1 -->|call tool| T1
    A1 -->|call tool| T2
    A2 -->|call tool| T3
    classDef cp fill:#e8f0fe,stroke:#1a73e8,stroke-width:2px;
    classDef dp fill:#fef7e0,stroke:#f9ab00,stroke-width:2px;
    class ORC,A1,A2 cp;
    class T1,T2,T3 dp;

十、五种拓扑的协调面/数据面状态机对比

不同拓扑本质上是控制流形态的差异，可以用状态机视角统一刻画。下面这张图把五种拓扑的控制流压缩成一张对比：哪条路径是确定的、哪条是涌现的、哪里有协调器。

flowchart LR
    IN((输入)) --> OW{Orchestrator}
    OW -->|并行扇出| W1[Worker1]
    OW -->|并行扇出| W2[Worker2]
    OW -->|并行扇出| W3[Worker3]
    W1 --> OW
    W2 --> OW
    W3 --> OW
    OW --> OUT((输出))

    subgraph Hierarchical
      H1[Sup-L1] --> H2[Sup-L2]
      H2 --> H3[Worker]
    end

    subgraph Pipeline
      P1[Stage1] --> P2[Stage2] --> P3[Stage3]
    end

    subgraph Mesh
      M1[Agent] <-.-> M2[Agent]
      M1 <-.-> M3[Agent]
      M2 <-.-> M3[Agent]
    end

    subgraph Swarm
      S1[Agent A] -->|handoff| S2[Agent B]
      S2 -->|handoff| S3[Agent C]
    end

十一、推荐方案：按场景选拓扑

一个贯穿性的建议：别把拓扑当一次性设计。成熟的编排层应该让拓扑在运行时可切换——简单子任务用 Pipeline，复杂拆解切 Orchestrator-Worker，跨域协调走 A2A 联邦。A2A 的 Task 模型恰恰提供了这种"运行时拓扑协商"的接口，这也是它区别于早期进程内框架的根本之处。

十二、协调面才是多智能体的真考点

五拓扑实测后的一条主线结论：多智能体的成败，七成在协调面、三成在数据面。Orchestrator-Worker 赢在可审计、输在单点；Hierarchical 赢在归因、输在延迟；Pipeline 赢在因果链、输在漂移；Mesh 赢在弹性、输在 N²；Swarm 赢在自然、输在涌现控制流。没有任何一种拓扑能同时占满容错、可审计、低协调税，编排层的全部价值就是在三者间做可量化的工程取舍。

而 A2A + MCP 的分离，第一次把"协调"从"工具调用"里解耦出来，让拓扑成为真正独立、可治理的一层。对企业而言，这意味着多智能体不再是框架选型题，而是控制面架构题——选谁做 Orchestrator、Agent Card 如何暴露、Task 状态机如何设计、不透明性边界划在哪。这些决策的复利，远大于纠结用 LangGraph 还是 CrewAI。下一步值得深挖的，是 A2A Task 状态机在长时间任务下的检查点与恢复语义，以及多 Orchestrator 联邦下的死锁检测——那是控制面架构的第二道墙。

参考来源

本文由「51学通信」原创，站长爱卫生（微信：gprshome201101）持续输出 AI 智能体与通信技术实战拆解。