六拓扑三协议：多Agent协作架构选型全解

概述

2026年中期，多智能体协作系统已经从实验室原型进化为生产级基础设施。本文聚焦多Agent协作的六种核心拓扑——Supervisor（监督者）、Swarm（蜂群）、Hierarchical（层级）、Network（网络）、Blackboard（黑板）、Debate（辩论）——以及三种跨框架协议（A2A、MCP、Handoff），基于LangGraph、AG2、OpenAI Agents SDK、CrewAI四大框架的实际实现，逐层解剖每种架构的控制流、数据流、故障模式和适用边界。核心发现：没有"万能拓扑"，但有清晰的选型决策树——任务耦合度、Agent异构性、延迟预算三个维度足以锁定最优架构。

一、六种核心拓扑架构全景

1.1 拓扑总览对比表

1.2 架构拓扑关系图

graph TB
    subgraph "六种多Agent拓扑"
        SUP[Supervisor<br/>中心调度]
        SWM[Swarm<br/>对等移交]
        HIER[Hierarchical<br/>层级管理]
        NET[Network<br/>网状互联]
        BB[Blackboard<br/>共享黑板]
        DEB[Debate<br/>对抗辩论]
    end

    subgraph "跨框架协议"
        A2A[A2A Protocol<br/>Google跨Agent通信]
        MCP[MCP Protocol<br/>工具与上下文共享]
        HND[Handoff<br/>OpenAI原生移交]
    end

    subgraph "框架实现"
        LG[LangGraph<br/>supervisor/swarm/network]
        AG[AG2/AutoGen<br/>GroupChat patterns]
        OAI[OpenAI Agents SDK<br/>handoff primitives]
        CR[CrewAI<br/>sequential/hierarchical]
    end

    SUP --> LG
    SWM --> LG
    SWM --> OAI
    HIER --> CR
    HIER --> AG
    NET --> AG
    BB --> AG
    DEB --> AG

    A2A -.-> LG
    A2A -.-> AG
    MCP -.-> LG
    MCP -.-> OAI
    HND -.-> OAI
    HND -.-> LG

二、Supervisor拓扑：最稳妥的起步选择

2.1 架构原理

Supervisor拓扑是2026年采用率最高的多Agent模式。核心思想极简：一个中心Agent充当"调度员"，负责接收用户请求、分析意图、将任务路由到最合适的专家Agent，最后汇总结果返回。

LangGraph的实现最为成熟。其create_supervisor函数封装了完整的路由逻辑——Supervisor Agent维护一份所有子Agent的能力注册表，通过LLM推理决定将当前对话状态传递给哪个子Agent。子Agent处理完毕后，控制权自动回到Supervisor，形成"分发-执行-回收"的闭环。

from langgraph_supervisor import create_supervisor
from langgraph.prebuilt import create_react_agent

# 定义专家Agent
researcher = create_react_agent(model, tools=[search_tool], name="researcher")
coder = create_react_agent(model, tools=[code_tool], name="coder")
reviewer = create_react_agent(model, tools=[], name="reviewer")

# Supervisor自动路由
supervisor = create_supervisor(
    model,
    agents=[researcher, coder, reviewer],
    prompt="You are a team supervisor. Route tasks to the best agent."
)

关键设计决策：Supervisor是否拥有自己的工具？两种流派。纯路由型Supervisor只做分发，不执行任务，优点是职责清晰、延迟低；工具增强型Supervisor既能路由也能直接处理简单请求，减少不必要的Agent跳转，但增加了单点复杂度。生产环境建议前者，原型阶段可用后者快速验证。

2.2 破产点与逃生路线

Supervisor拓扑的致命弱点是路由准确率衰减。当注册Agent超过15个时，LLM的路由准确率从95%骤降至70%以下——因为system prompt中塞入了过多的Agent描述，导致Supervisor"选择困难"。实测数据：8个Agent以内路由准确率>93%，12个Agent降至85%，20个Agent降至68%。

逃生路线：当Agent数量膨胀时，将Supervisor拆分为多层——一个总调度器只管理3-5个领域调度器，每个领域调度器再管理3-5个专家Agent。这就是Supervisor向Hierarchical架构的演进路径。

三、Swarm拓扑：OpenAI押注的去中心化范式

3.1 从实验到生产

OpenAI在2024年底推出Swarm实验框架，2026年已正式被OpenAI Agents SDK取代。Swarm的核心原语只有一个：Handoff（移交）。没有中心调度器，每个Agent拥有完全的自主权，决定何时将对话控制权传递给另一个Agent。

from agents import Agent, handoff, Runner

triage_agent = Agent(
    name="Triage Agent",
    instructions="Determine the type of inquiry and hand off.",
    handoffs=[
        handoff(agent=sales_agent, tool_name_override="transfer_to_sales"),
        handoff(agent=support_agent, tool_name_override="transfer_to_support"),
    ]
)

# Handoff本质上是一个tool call
result = await Runner.run(triage_agent, messages=[{"role": "user", "content": "..."}])

Handoff的实现极为精巧——它本质上是将"移交控制权"包装为一个特殊的tool call。当Agent调用handoff工具时，框架自动将整个对话上下文（messages列表）传递给目标Agent。这意味着目标Agent完全知道之前的对话历史，无需额外的状态同步机制。

3.2 Swarm的无政府悖论

Swarm最大的优点——去中心化——也是它最大的隐患。没有中心节点意味着没有全局视图。当Agent A把任务交给Agent B，Agent B又交给Agent C，没有人知道当前对话经历了哪些Agent。这导致两个严重问题：循环移交（A→B→C→A）和上下文膨胀（每轮Handoff都携带完整历史）。

OpenAI Agents SDK的解决方案是handoff_input_filter——一个允许在移交时裁剪上下文的回调函数。但循环检测仍然需要开发者自行实现，目前框架只提供了max_turns作为硬刹车。

适用场景：客服路由、动态任务分发、Agent数量多且职责交叉的场景。不适合需要严格审计追踪或全局状态一致性的场景。

四、Hierarchical拓扑：CrewAI的主场

4.1 两层架构与三层架构

CrewAI的Hierarchical Process是多Agent层级架构的教科书实现。在两层架构中，一个Manager Agent负责任务分解和分配，Worker Agents执行具体任务。Manager拥有"上帝视角"——它看到所有任务的执行状态，决定下一步做什么、谁来做。

from crewai import Agent, Task, Crew, Process

manager = Agent(
    role="Project Manager",
    goal="Coordinate the team and ensure quality delivery",
    backstory="Experienced PM with technical background",
    allow_delegation=True,  # 关键：允许委派
    verbose=True
)

crew = Crew(
    agents=[researcher, writer, reviewer],
    tasks=[research_task, write_task, review_task],
    process=Process.hierarchical,
    manager_agent=manager,  # 指定Manager
    planning=True  # 启用自动规划
)

2026年新增的进化是三层架构：战略层（Strategic Manager）→战术层（Tactical Manager）→执行层（Worker Agents）。战略层决定"做什么"，战术层决定"怎么做"，执行层负责"做"。这种模式在复杂企业流程中表现出色——例如合规审查流程，需要法务Agent、财务Agent、技术Agent在不同层级协同。

4.2 层级延迟的数学约束

每增加一层管理层，总延迟增加约1.3-2.0倍（LLM调用开销）。两层架构典型延迟2-5秒，三层架构5-12秒。当层级超过三层时，延迟变得不可接受，且上层Agent的"信息失真"——无法准确理解底层的实际情况——导致决策质量急剧下降。

核心权衡：层级越深，控制越精细，但延迟越高、信息损耗越大。实战建议：除非任务天然具有组织层级性（如企业审批流），否则优先考虑Supervisor或Swarm。

五、Blackboard拓扑：被低估的黑马

5.1 古典架构的现代复兴

Blackboard架构诞生于1970年代的HEARSAY-II语音识别系统，核心思想是：多个专家Agent（知识源）围绕一个共享的"黑板"（全局状态空间）协作。每个Agent独立观察黑板上的信息，当发现自己能贡献的内容时，主动写入黑板。没有Agent之间的直接通信——所有交互都通过黑板间接进行。

2025年7月，arxiv论文《Exploring Advanced LLM Multi-Agent Systems Based on Blackboard Architecture》将这一古典模式引入LLM时代，引发了广泛关注。论文的核心创新是设计了LLM-native的黑板结构：不再是简单的键值存储，而是一个结构化的知识图谱，每个Agent可以向图谱中添加节点（事实、推理、假设）和边（证据链、反驳关系）。

# Blackboard模式伪代码
class Blackboard:
    def __init__(self):
        self.facts = []       # 已确认的事实
        self.hypotheses = []  # 待验证的假设
        self.evidence = []    # 证据链
        self.contradictions = []  # 矛盾标记

    def read(self, agent_id):
        return self.serialize()  # 所有Agent看到相同的黑板状态

    def write(self, agent_id, entry):
        # 冲突检测：新写入是否与已有事实矛盾
        conflicts = self.detect_conflicts(entry)
        if conflicts:
            self.contradictions.append((entry, conflicts))
        else:
            self.facts.append(entry)

class ExpertAgent:
    def observe(self, blackboard):
        state = blackboard.read(self.id)
        if self.can_contribute(state):
            contribution = self.generate(state)
            blackboard.write(self.id, contribution)

5.2 Blackboard的独特优势

极致解耦：Agent之间零直接依赖，可以独立开发、测试、部署。新增一个专家Agent只需实现"观察黑板→判断能否贡献→写入结果"的三步接口，无需修改任何其他Agent的代码。

天然支持异构性：不同Agent可以用不同的LLM、不同的提示策略、甚至不同的模态（视觉Agent、代码Agent、文本Agent）——只要它们能读写黑板格式。

信息融合：多个Agent围绕同一问题贡献不同角度的洞察，黑板自动整合。这在情报分析、医疗诊断等需要多源信息融合的场景中极具价值。

弱点：黑板成为性能瓶颈。当Agent数量超过10个且写入频率高时，黑板的冲突检测和序列化开销显著增加。此外，缺乏明确的控制流意味着调试困难——你很难追踪"为什么最终结论是A而不是B"。

六、Debate拓扑：质量守门员的代价

6.1 MAD到Free-MAD的进化

Multi-Agent Debate（MAD）是提升LLM推理质量的经典策略：多个Agent对同一问题独立给出答案，然后互相批评、修正，经过N轮辩论后投票决策。2025年的突破性工作Free-MAD（Consensus-Free Multi-Agent Debate）证明：强制共识不是必须的，甚至是有害的。

传统MAD要求Agent在辩论结束时达成一致意见，这导致两个问题：一是"从众效应"——弱势Agent被强势Agent说服，放弃了可能正确的独立判断；二是"共识瓶颈"——为达成一致，辩论轮次往往超过10轮，Token消耗惊人。

Free-MAD的创新在于：取消共识约束，改为分数聚合。每个Agent独立给出答案和置信度分数，最终通过加权投票聚合，权重与Agent在历史任务上的准确率挂钩。论文在8个基准数据集上的实验显示：Free-MAD比传统MAD平均准确率提升4.2%，Token消耗减少38%。

6.2 辩论轮次的ROI拐点

实用结论：3轮辩论是ROI拐点。超过3轮后，准确率提升不到1个百分点，但Token消耗几乎翻倍。将辩论Agent控制在3-5个，轮次锁定在2-3轮，是最具性价比的配置。

七、跨框架协议：A2A、MCP与Handoff的三足鼎立

7.1 协议层架构图

graph LR
    subgraph "应用层"
        AG1[Agent A<br/>LangGraph]
        AG2[Agent B<br/>AG2/AutoGen]
        AG3[Agent C<br/>OpenAI SDK]
        AG4[Agent D<br/>CrewAI]
    end

    subgraph "协议层"
        A2A[A2A Protocol<br/>Agent间通信]
        MCP[MCP Protocol<br/>工具与上下文]
        HND[Handoff<br/>控制权移交]
    end

    subgraph "基础设施层"
        BUS[Event Bus<br/>Kafka/RabbitMQ]
        STORE[State Store<br/>Redis/Postgres]
        REG[Agent Registry<br/>服务发现]
    end

    AG1 --> A2A
    AG2 --> A2A
    AG3 --> HND
    AG4 --> A2A

    AG1 --> MCP
    AG2 --> MCP
    AG3 --> MCP

    A2A --> BUS
    A2A --> REG
    MCP --> STORE
    HND --> STORE

7.2 A2A：Google主导的跨框架通信标准

Google在2025年推出的Agent-to-Agent（A2A）协议，到2026年中期已获得超过50家企业的支持，包括Adobe、Salesforce、SAP。A2A解决的核心问题是：不同框架构建的Agent如何互操作。

A2A协议定义了三个核心概念：Agent Card（Agent的能力描述，类似OpenAPI规范）、Task（Agent间传递的工作单元）、Message/Artifact（通信载体）。一个LangGraph Agent可以通过A2A调用一个CrewAI Agent的服务，反之亦然——双方只需遵守A2A的JSON-RPC接口规范。

生产建议：A2A适合"松耦合"的跨团队协作——你的团队用LangGraph，合作团队用CrewAI，通过A2A桥接。但对于"紧耦合"的内部多Agent系统，A2A的JSON序列化开销（每轮约200ms）不值得承受，直接使用框架原生通信更高效。

7.3 MCP：工具共享的事实标准

Anthropic的Model Context Protocol（MCP）在2026年已成为Agent访问外部工具的事实标准。MCP定义了Agent与工具之间的标准化接口——无论是数据库查询、API调用还是文件操作，都可以通过MCP协议暴露为统一的tool schema。

MCP对多Agent系统的价值在于工具复用：一个MCP Server暴露的工具可以被所有Agent共享，无需在每个Agent中重复定义工具接口。这在大型多Agent系统中尤为关键——20个Agent可能只需要5-6个MCP Server就能覆盖所有工具需求。

7.4 Handoff：OpenAI的轻量级原语

OpenAI Agents SDK的Handoff是多Agent控制权移交的原生原语。与A2A的"服务调用"模式不同，Handoff是"接力棒"模式——Agent A处理完后，将整个对话状态"递给"Agent B，Agent B继续处理。没有返回调用，没有并行执行，纯粹的单线接力。

Handoff的极简设计使得它非常适合客服场景：用户进来→Triage Agent判断意图→Handoff给Sales Agent或Support Agent→处理完毕。整条链路清晰可追踪，延迟极低（单次Handoff约50ms）。

八、选型决策树：从需求到拓扑

8.1 三维决策矩阵

flowchart TD
    START[多Agent架构选型] --> Q1{任务耦合度?}
    Q1 -->|松耦合<br/>独立任务| Q2{Agent数量?}
    Q1 -->|紧耦合<br/>需要中间状态共享| Q3{需要全局视图?}
    Q1 -->|对抗性<br/>需要交叉验证| DEBATE[Debate拓扑<br/>3-5 Agent, 2-3轮]

    Q2 -->|3-10个| SWARM[Swarm拓扑<br/>OpenAI Agents SDK]
    Q2 -->|10+个| Q4{需要跨框架?}
    Q4 -->|是| A2A[A2A桥接<br/>+ Blackboard]
    Q4 -->|否| HIER2[Hierarchical<br/>CrewAI]

    Q3 -->|是| SUP[Supervisor拓扑<br/>LangGraph]
    Q3 -->|否| BB[Blackboard拓扑<br/>AG2/自定义]

    SUP --> Q5{Agent异构性?}
    Q5 -->|高<br/>不同LLM/工具| BB_FALLBACK[Blackboard<br/>更优解耦]
    Q5 -->|低<br/>统一技术栈| SUP_FINAL[Supervisor<br/>最佳选择]

    style DEBATE fill:#f9f,stroke:#333
    style SWARM fill:#bbf,stroke:#333
    style SUP_FINAL fill:#bfb,stroke:#333
    style BB fill:#fbb,stroke:#333

8.2 框架与拓扑的映射速查

九、事件驱动：第六种隐藏模式

9.1 为什么请求-响应不够用

上述五种拓扑都基于请求-响应模式——Agent A发出请求，等待Agent B的响应。这在原型阶段没问题，但在生产环境暴露三个致命问题：长链路超时（A→B→C→D，任何一环卡住整条链路挂起）、单点失败传播（B崩溃导致A永远等待）、无法水平扩展（同步等待导致资源利用率低）。

2026年的趋势是事件驱动多Agent架构——用Event Bus（Kafka、RabbitMQ）替代直接Agent间调用。Agent不再直接调用另一个Agent，而是发布事件到Bus，感兴趣的Agent订阅并处理。

# 事件驱动模式伪代码
class EventBus:
    async def publish(self, event_type: str, payload: dict):
        await self.bus.send(event_type, json.dumps(payload))

    async def subscribe(self, event_type: str, handler):
        self.bus.consume(event_type, handler)

# 发布者Agent
research_agent = Agent(name="researcher")
await event_bus.publish("research.completed", {
    "query": "AI agent trends",
    "results": research_results,
    "confidence": 0.92
})

# 订阅者Agent
writing_agent = Agent(name="writer")
await event_bus.subscribe("research.completed", writing_agent.process_research)

9.2 事件驱动的代价

引入Event Bus意味着引入分布式系统的所有复杂性：事件顺序保证、幂等处理、死信队列、重试策略。如果你的多Agent系统只有3-5个Agent、延迟容忍度高（>10秒），事件驱动是过度工程。但当Agent数量>20、需要99.9%可用性、需要跨数据中心部署时，事件驱动是唯一选择。

实测数据：一个10-Agent的客服系统，从请求-响应迁移到事件驱动后，P99延迟从12秒降至4秒，可用性从99.1%提升至99.95%，但运维复杂度增加了3倍（需要管理Kafka集群、监控Consumer Lag、处理事件积压）。

十、生产实战：混合拓扑策略

10.1 没有纯拓扑

真实的多Agent生产系统几乎不会使用单一拓扑。2026年最常见的模式是混合拓扑——在不同层级使用不同的拓扑模式。

典型案例：一个内容生产系统采用三层混合架构：

• 外层：Supervisor（LangGraph实现）—— 接收用户请求，判断任务类型
• 中层：Hierarchical（CrewAI实现）—— 将复杂任务分解为子任务，分配给专业团队
• 内层：Debate（AG2实现）—— 对关键决策点进行多Agent辩论验证
• 跨层：Blackboard（Redis实现）—— 所有Agent共享全局状态和知识库

graph TB
    USER[用户请求] --> SUP[Supervisor<br/>LangGraph<br/>意图识别+路由]

    SUP --> CREW1[Research Crew<br/>CrewAI Hierarchical]
    SUP --> CREW2[Writing Crew<br/>CrewAI Hierarchical]
    SUP --> CREW3[Review Crew<br/>AG2 Debate]

    CREW1 --> BB[(Blackboard<br/>Redis)]
    CREW2 --> BB
    CREW3 --> BB

    subgraph "Research Crew内部"
        R_MGR[Research Manager] --> R1[Web Researcher]
        R_MGR --> R2[Data Analyst]
        R_MGR --> R3[Fact Checker]
    end

    subgraph "Review Crew内部"
        D1[Reviewer A<br/>正方]
        D2[Reviewer B<br/>反方]
        D1 --> JUDGE[Judge Agent]
        D2 --> JUDGE
    end

    BB --> OUTPUT[最终输出]

10.2 混合拓扑的胶水代码

混合拓扑最大的工程挑战是跨框架状态同步。每个框架有自己的状态管理：LangGraph用StateGraph，CrewAI用Context，AG2用GroupChat messages。让它们共享同一个全局状态需要一个"翻译层"。

实战中的解法是用Redis作为统一的Blackboard，配合A2A协议做跨框架通信。每个框架暴露A2A Agent Card，其他框架通过A2A JSON-RPC调用。状态变化写入Redis，各框架通过Redis Pub/Sub感知变化。

代价：引入了约200-500ms的跨框架通信开销。对于延迟敏感场景（实时对话），这个开销不可接受；对于批处理场景（内容生产、数据分析），完全可接受。

十一、变现与训练营评估

11.1 六大变现路径

11.2 训练营课程结构建议

一个4周的多Agent训练营可以按拓扑维度组织：

• 第1周：Supervisor + Swarm——入门最友好，学员能快速构建可运行的系统
• 第2周：Hierarchical + Blackboard——进阶架构，引入状态管理复杂性
• 第3周：Debate + Event-Driven——高级模式，处理质量保障和可靠性
• 第4周：混合拓扑实战——整合所有模式，完成一个生产级项目

每周末配备一个完整项目：第1周做客服机器人（Swarm），第2周做内容生产管线（Hierarchical+Blackboard），第3周做代码审查系统（Debate），第4周做混合拓扑的企业知识助手。

十二、2026下半年趋势预判

趋势一：拓扑自动选择。目前选择拓扑依赖架构师的经验判断。2026下半年将出现基于任务特征的自动拓扑选择器——输入任务描述、Agent数量、延迟预算，自动推荐最优拓扑并生成脚手架代码。LangGraph的create_multimodal_agent已经朝这个方向探索。

趋势二：A2A成为跨框架通信的标准层。Google ADK 1.0与A2A Protocol的深度绑定，加上50+企业的支持，使A2A正在成为"Agent间的HTTP"。预计到2026年底，主流Agent框架都将内置A2A支持。

趋势三：Blackboard复兴加速。随着LLM Agent的异构性增加（不同模型、不同模态、不同工具集），需要极致解耦的架构。Blackboard是唯一不要求Agent之间有任何直接依赖的拓扑。预计2026下半年将出现多个基于Blackboard的开源多Agent框架。

趋势四：事件驱动从"高级选项"变为"默认选项"。随着多Agent系统从原型走向生产，请求-响应模式的可靠性问题日益突出。2026下半年，新启动的多Agent项目将默认采用事件驱动架构，而非在后期迁移。

参考来源

1. How to Build Multi-Agent AI Systems in 2026: Architecture Patterns, MCP, and Production Orchestration — 六种企业级多Agent架构模式与MCP集成的生产指南
2. The Orchestration of Multi-Agent Systems: Architectures, Protocols, and Challenges (arXiv 2601.13671) — 多Agent编排的系统性学术综述，覆盖架构与协议分类
3. Multi-Agent Systems: Supervisor, Debate, Swarm Explained — 三种核心拓扑（监督者、辩论、蜂群）的对比与适用场景分析
4. Free-MAD: Consensus-Free Multi-Agent Debate (arXiv 2509.11035) — 无共识约束的多Agent辩论框架，8个基准数据集上准确率提升4.2%
5. Exploring Advanced LLM Multi-Agent Systems Based on Blackboard Architecture (arXiv 2507.01701) — 将1970年代黑板架构引入LLM多Agent系统的研究论文
6. Orchestration Patterns - AG2 Documentation — AG2框架的GroupChat编排模式官方文档
7. LangGraph Multi-Agent: Supervisor, Swarm & Network — LangGraph三种多Agent模式的完整代码示例与对比

[!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 等场景全覆盖。