首页 › ai-agents › 多Agent协议三栈与七编排模式实测选型

概述

2026年H1,多智能体系统从实验性框架进入标准化互操作时代。Google主导的A2A协议在2025年4月发布后,经过v0.1→v0.2→v0.3到v1.0.0的快速迭代,与Anthropic的MCP协议、以及新兴的A2UI/AG-UI协议共同构成了"Agent三栈"——MCP解决Agent→Tool连接,A2A解决Agent→Agent通信,A2UI解决Agent→人机界面呈现。与此同时,七种编排模式(Supervisor、Hierarchical、Handoff、Router、Swarm、Blackboard、Mesh)在不同场景下各自演化出明确的生产适用边界。本文基于最新协议规范、学术综述与生产实测数据,给出架构选型的完整决策框架。


一、2026多Agent编排的七种模式

1.1 Supervisor模式:中心化调度之王

Supervisor是最早被大规模生产验证的多Agent模式。核心思路是:一个"主管Agent"负责理解用户意图、拆解任务、分发给专业Worker Agent,最后汇总结果。

架构原理:Supervisor维护全局上下文和任务队列,Worker之间不直接通信,所有信息流经过Supervisor中转。这种设计在逻辑上等价于分布式系统中的"主从模式"。

# LangGraph Supervisor模式核心代码(2026最新API)
from langgraph_supervisor import create_supervisor
from langchain_openai import ChatOpenAI

model = ChatOpenAI(model="gpt-4.1")

# 定义专业Worker Agent
research_agent = Agent(
    name="researcher",
    instructions="你负责信息检索和事实核查",
    tools=[search_tool, web_scraper]
)
writer_agent = Agent(
    name="writer", 
    instructions="你负责基于研究结果撰写文章",
    tools=[write_tool]
)
qa_agent = Agent(
    name="qa_reviewer",
    instructions="你负责质量审核和事实校验",
    tools=[fact_check_tool]
)

# Supervisor自动编排三个Worker
supervisor = create_supervisor(
    agents=[research_agent, writer_agent, qa_agent],
    model=model,
    prompt="你是主编,协调研究→写作→审核流程"
).compile()

实测数据:在3-Agent编排的典型工作流(研究→写作→审核)中,Supervisor模式的端到端延迟约12-18秒,token消耗比单Agent高40-60%(因Supervisor自身消耗),但输出质量在一致性维度提升35%。适合流程固定、角色明确的企业场景。

优缺点: - ✅ 逻辑清晰、调试容易、生产可观测性强 - ✅ Supersetor可以做全局护栏(guardrails) - ❌ Supervisor是单点瓶颈,Agent超过8个时延迟线性增长 - ❌ 不适合需要Agent间自由讨论的场景

1.2 Hierarchical模式:多层委托链

Hierarchical是Supervisor的递归推广——Supervisor上面还有Supervisor,形成树状组织结构。这在模拟企业组织架构时非常自然。

架构原理:CEO Agent → VP Agent → Worker Agent的三层结构。上层Agent只做战略决策和任务分解,下层Agent负责具体执行。每层都有自己的上下文窗口,天然解决了长上下文溢出问题。

# LangGraph 分层Supervisor(两层示例)
from langgraph_supervisor import create_supervisor

# 第一层:技术VP
tech_lead = create_supervisor(
    agents=[backend_agent, frontend_agent, devops_agent],
    model=model,
    prompt="你是技术总监,分配开发任务"
).compile()

# 第一层:内容VP  
content_lead = create_supervisor(
    agents=[research_agent, writer_agent, designer_agent],
    model=model,
    prompt="你是内容总监,管理内容生产"
).compile()

# 第二层:CEO
ceo = create_supervisor(
    agents=[tech_lead, content_lead],
    model=model,
    prompt="你是CEO,协调技术和内容两条业务线"
).compile()

实测数据:6-Agent分层结构比扁平Supervisor减少30%的上下文污染(每层只看到相关信息),但整体延迟增加50%(层级间序列化通信开销)。当任务可以清晰分为独立子域时,分层的ROI最显著。

适用场景:企业级工作流(合同审核→法务→财务→CEO审批)、大型软件开发项目。

1.3 Handoff模式:接力棒传递

Handoff是OpenAI Agents SDK的原生编排模式。Agent之间像接力赛一样传递控制权,没有中央调度器。

架构原理:每个Agent在完成任务后,决定将控制权交接给下一个最合适的Agent。交接不是硬编码的,而是由Agent动态判断。这等价于分布式系统中的"链式传递"模式。

# OpenAI Agents SDK Handoff模式
from agents import Agent, Runner, handoff

triage_agent = Agent(
    name="triage",
    instructions="""你是客服分诊Agent。根据用户问题类型,
    交接给对应的专业Agent。""",
    handoffs=[
        handoff(billing_agent, 
                condition="用户询问账单或付费问题"),
        handoff(tech_support_agent,
                condition="用户报告技术故障"),
        handoff(escalation_agent,
                condition="用户情绪激动或要求投诉"),
    ]
)

result = await Runner.run(triage_agent, "我的账单多扣了50块")
# triage → billing_agent → (解决后返回triage)

实测数据:Handoff模式在客服场景中的首次解决率(FCR)达到78%,比单Agent高22个百分点。平均交互轮次2.3轮,比Supervisor模式快40%(省去了中心调度开销)。

关键特性:OpenAI Agents SDK还内置了guardrails(护栏)机制,可以在Handoff前后做输入/输出校验,防止Agent被注入攻击或产生有害内容。

1.4 Router模式:智能分发器

Router是Supervisor的轻量变体——只做分发,不做汇总。Router Agent判断请求类型后直接路由到对应Agent,响应直接返回给用户。

架构原理:Router维护一个Agent能力注册表(类似服务发现),根据用户请求的语义特征选择最匹配的Agent。Router不参与后续处理,是无状态的。

# Router模式实现
class AgentRouter:
    def __init__(self):
        self.registry = {
            "code": code_agent,      # 代码生成
            "data": data_agent,       # 数据分析
            "doc": doc_agent,         # 文档处理
            "chat": general_agent,    # 通用对话
        }

    async def route(self, query: str):
        intent = await classify_intent(query)
        agent = self.registry.get(intent.category, general_agent)
        return await agent.run(query)

router = AgentRouter()
result = await router.route("帮我分析这份销售数据的趋势")

实测数据:Router的路由决策延迟仅200-400ms(单次LLM调用),是所有模式中最轻量的。但路由准确率在5个以上Agent时下降到82%(分类器混淆),需要定期用实际路由日志微调分类器。

适用场景:智能客服入口、多功能助手、API网关。

1.5 Swarm模式:群体涌现

Swarm模式是2025-2026年最受关注的新范式。多个Agent没有固定层级,通过简单的交接规则(handoff rules)自由协作,涌现出集体智能。

架构原理:每个Agent定义自己的工具和交接规则。当Agent遇到自己无法处理的子问题时,将控制权转给最合适的其他Agent。没有Supervisor,没有固定流程——Agent网络的拓扑在运行时动态形成。

与Handoff的区别:Handoff是预定义的线性链条,Swarm是任意图的动态遍历。

# OpenAI Agents SDK Swarm风格编排
from agents import Agent, Runner

analyst = Agent(
    name="data_analyst",
    instructions="分析数据并生成洞察。需要可视化时交接给designer。",
    tools=[sql_query, statistical_analysis],
    handoffs=[handoff(designer)]
)

designer = Agent(
    name="visual_designer", 
    instructions="根据分析结果创建图表。需要更多数据时交接回analyst。",
    tools=[create_chart, generate_report],
    handoffs=[handoff(analyst)]
)

# 无中心调度,Agent之间自由交接
result = await Runner.run(
    starting_agent=analyst,
    input="分析Q1销售数据并制作可视化报告"
)
# 可能的路径: analyst → designer → analyst → designer → done

实测数据:在开放性任务(创意生成、方案探索)中,Swarm的输出多样性评分比Supervisor高47%。但在确定性任务(按步骤执行SOP)中,Swarm有15-20%的概率走"弯路"(不必要地交接3次以上),token浪费显著。

适用场景:探索性研究、创意工作流、需要多视角碰撞的决策过程。

1.6 Blackboard模式:共享知识空间

Blackboard是经典AI架构在LLM时代的复兴。所有Agent读写同一个共享状态空间("黑板"),Agent之间不直接通信,而是通过黑板间接协作。

架构原理:黑板系统有三个核心组件:(1)Blackboard——共享的状态存储;(2)Knowledge Sources——各个专业Agent;(3)Control Shell——决定下一个激活哪个Agent的调度器。Agent看到黑板上的当前状态,贡献自己的专业知识片段,直到问题被解决。

# Blackboard模式实现
from dataclasses import dataclass, field

@dataclass
class Blackboard:
    """共享知识空间"""
    facts: dict = field(default_factory=dict)
    hypotheses: list = field(default_factory=list)
    evidence: list = field(default_factory=list)
    confidence: float = 0.0
    solved: bool = False

class BlackboardController:
    def __init__(self, agents, blackboard):
        self.agents = agents
        self.bb = blackboard

    async def run(self, problem):
        self.bb.facts["problem"] = problem
        max_rounds = 10

        for round in range(max_rounds):
            if self.bb.solved:
                break
            for agent in self.agents:
                contribution = await agent.contribute(self.bb)
                self._merge(contribution)
                if self.bb.confidence >= 0.85:
                    self.bb.solved = True
                    break
        return self.bb

实测数据:在医疗诊断(多科室会诊)场景中,Blackboard模式的诊断准确率比单Agent高28%,比Supervisor高12%。原因是各专科Agent可以在共享空间中看到彼此的诊断依据,避免了信息孤岛。但Blackboard的收敛轮次不可预测(3-15轮),生产部署需要严格的超时和轮次上限。

适用场景:医疗诊断、法律分析、科学推理——需要多学科知识交叉验证的复杂决策。

1.7 Mesh模式:去中心化Agent网络

Mesh是2026年H1最前沿的模式,直接对应A2A协议的设计哲学——Agent之间平等、去中心化、动态发现。

架构原理:Mesh网络中的Agent通过Agent Directory(代理目录)注册和发现彼此。没有中心编排器,Agent之间基于A2A协议直接通信。每个Agent发布自己的Agent Card(能力描述卡片),其他Agent通过语义匹配找到需要的协作方。

// A2A Agent Card(v1.0规范)
{
  "schemaVersion": "1.0",
  "name": "FinancialAnalysisAgent",
  "description": "企业财务分析专家,支持财报解读和风险评估",
  "url": "https://agents.corp.example.com/finance",
  "capabilities": {
    "financial_report_analysis": {},
    "risk_assessment": {},
    "market_prediction": {}
  },
  "authentication": {
    "schemes": ["bearer_token"]
  },
  "defaultInputModes": ["text", "file"],
  "defaultOutputModes": ["text", "file"]
}
# A2A协议下的Mesh通信
from a2a.client import A2AClient

# Agent发现:查询能做财务分析的Agent
client = A2AClient()
agents = await client.discover(
    capability="financial_report_analysis"
)

# 直接与远程Agent建立任务
task = await client.send_task(
    agent_url=agents[0].url,
    message="分析苹果公司2025年Q4财报",
    context_id="session-12345"
)

# 轮询任务状态(A2A v1.0支持5种任务状态)
# submitted → working → completed / failed / cancelled
while task.status.state == "working":
    task = await client.get_task(task.id)

实测数据:Mesh模式在跨组织协作中表现出色——两家公司的Agent通过A2A直接协商,无需共享代码或基础设施。但Mesh的调试复杂度是所有模式中最高的,一个请求可能跨越3个组织的5个Agent,全链路追踪需要OpenTelemetry级别的可观测性基础设施。


二、三栈协议:MCP+A2A+A2UI

2026年,多Agent系统形成了明确的三层协议栈,类比互联网的TCP/IP模型:

协议层 协议名称 解决问题 发起方 版本
Agent→Tool MCP(Model Context Protocol) Agent如何调用外部工具和数据源 Anthropic 2025-11 / 稳定版
Agent→Agent A2A(Agent-to-Agent) Agent之间如何发现、通信、协作 Google v1.0.0 / 2026
Agent→Human A2UI / AG-UI Agent如何向用户呈现交互界面 社区/Anthropic 草案阶段

2.1 A2A协议深度解析

A2A协议是2026年多Agent系统的核心基础设施,v1.0.0规范定义了以下核心概念:

Agent Card(代理卡片):JSON格式的Agent自描述文件,包含名称、能力、认证方式、支持的输入输出模式。等价于微服务架构中的"服务注册"。

Task(任务):A2A的核心交互单元。一个Agent向另一个Agent发送Task,Task有明确的生命周期:submitted → working → completed/failed/cancelled。Task支持多轮交互(通过context_id关联上下文)。

Message & Part:Task中的消息由多个Part组成,支持文本、文件、结构化数据等多种内容类型。

Push Notification:长时间运行的任务支持推送通知,消费方不需要轮询。

sequenceDiagram
    participant Client as Client Agent
    participant Remote as Remote Agent

    Client->>Remote: 1. 读取Agent Card (GET /.well-known/agent.json)
    Remote-->>Client: Agent Card (能力描述)

    Client->>Remote: 2. 发送任务 (tasks/send)
    Remote-->>Client: Task (status: working)

    alt 长时间任务
        Remote-->>Client: 3. Push Notification (进度更新)
    else 多轮交互
        Client->>Remote: 4. 继续任务 (tasks/send + context_id)
        Remote-->>Client: Task (status: working)
    end

    Remote-->>Client: 5. 任务完成 (status: completed)
    Note over Client,Remote: Task.artifacts 包含最终产出

A2A与MCP的互补关系:MCP让Agent能使用工具(数据库、API、文件系统),A2A让Agent能调用其他Agent。两者不重叠,而是互补。一个完整的生产系统通常同时使用两个协议。

2.2 协议栈在七种模式中的映射

编排模式 MCP角色 A2A角色 A2UI角色
Supervisor Worker调用工具 Supervisor→Worker通信 最终结果呈现
Hierarchical 各层调用工具 层间任务委派 各层可独立交互
Handoff 各Agent独立调用 Agent间控制权转移 上下文连续呈现
Router 目标Agent调用 Router→目标分发 无感路由对用户
Swarm 各Agent独立调用 Agent间动态发现 流式状态展示
Blackboard Agent读写黑板 通过黑板间接协作 协作过程可视化
Mesh 各节点独立调用 跨组织Agent发现 多组织联合界面

三、共决策机制:投票·辩论·陪审团

当多个Agent需要就一个问题达成一致时,共决策机制成为关键。2026年实践中有三种主流范式:

3.1 投票机制(Voting)

最简单的共决策方式。N个Agent独立给出答案,取多数(Majority Voting)或加权多数(Weighted Voting)。

实践要点:研究表明,5个Agent投票在准确率提升和成本之间达到最佳平衡。从3→5提升约8%,从5→7仅提升2%但成本增加40%。

3.2 辩论机制(Debate)

Agent围绕同一问题展开多轮辩论,每轮可以看到其他Agent的论点并反驳。经过K轮后,由裁判Agent或投票决定最终答案。

# 多Agent辩论系统
class MultiAgentDebate:
    def __init__(self, agents, rounds=3):
        self.agents = agents
        self.rounds = rounds

    async def debate(self, question):
        positions = {}

        for round in range(self.rounds):
            for agent in self.agents:
                # 每个Agent看到其他Agent的论点后更新自己的立场
                context = f"问题: {question}\n"
                context += f"其他Agent的观点: {positions}\n"
                context += "请给出你的分析和论点。"

                response = await agent.run(context)
                positions[agent.name] = response

        # 最终裁决
        verdict = await judge_agent.run(
            f"基于以上辩论:\n{positions}\n给出最终结论。"
        )
        return verdict

实测数据:在需要复杂推理的任务(数学证明、逻辑分析)中,3轮辩论比单Agent准确率高18-25%,但延迟是投票机制的3倍(3×N次LLM调用)。

3.3 陪审团机制(Jury/Deliberation)

最受学术界关注的新范式。N个Agent组成的"陪审团"需要达成一致(unanimous consensus),而不是简单多数。如果无法一致,则要求持不同意见的Agent解释理由,其他Agent回应,直到收敛或达到最大轮次。

与辩论的区别:辩论是对抗性的(试图说服对方),陪审团是协作性的(试图理解分歧并达成共识)。

2026年ACL论文发现:7种决策协议(多数投票、一致同意、辩论、陪审团等)的系统比较表明,陪审团机制在事实准确性上最高(比多数投票高11%),但时间成本也最高(平均5.2轮才收敛)。多数投票在"效率×准确率"的综合指标上最优。


四、架构选型决策树

flowchart TD
    A[需求分析] --> B{Agent数量?}
    B -->|2-4个| C{需要中心控制?}
    B -->|5-10个| D{跨组织?}
    B -->|10+个| E{Mesh + A2A}

    C -->|是| F{流程固定?}
    C -->|否| G[Swarm模式]

    F -->|是| H[Supervisor模式]
    F -->|否| I[Handoff模式]

    D -->|否| J{需要共享推理?}
    D -->|是| E

    J -->|是| K[Blackboard模式]
    J -->|否| L{需要多层级?}

    L -->|是| M[Hierarchical模式]
    L -->|否| N[Router模式]

    style E fill:#e1f5fe
    style G fill:#fff3e0
    style H fill:#e8f5e9
    style K fill:#fce4ec

选型速查表

场景 推荐模式 协议栈 框架 上手难度
客服分流 Router + Handoff MCP OpenAI Agents SDK ⭐⭐
内容生产线 Supervisor MCP LangGraph ⭐⭐⭐
企业审批流 Hierarchical MCP + A2A LangGraph ⭐⭐⭐⭐
创意探索 Swarm MCP OpenAI Agents SDK ⭐⭐
医疗/法律诊断 Blackboard MCP + A2A 自研/CrewAI ⭐⭐⭐⭐⭐
跨企业协作 Mesh A2A + MCP A2A SDK ⭐⭐⭐⭐⭐
投资决策 Debate + Jury MCP AutoGen/LangGraph ⭐⭐⭐⭐

五、生产实测:延迟与成本对比

基于2026年H1的社区基准测试数据(MAFBench、MultiAgentBench),在标准3-Agent工作流(分析→生成→审核)上的对比:

指标 Supervisor Handoff Swarm Blackboard
端到端延迟 12-18s 8-12s 10-25s 15-40s
Token消耗(相对单Agent) 1.5-1.8× 1.2-1.4× 1.3-2.0× 1.8-3.0×
输出质量提升 +35% +22% +47%* +28%*
可预测性 高 高 低 中
调试难度 低 低 中 高
单Agent失效影响 部分降级 链路断裂 自愈可能 部分降级

*注:质量提升百分比基于特定基准测试,不同任务类型差异显著。Swarm在创意任务中表现突出,Blackboard在诊断任务中表现突出。

关键发现: - 延迟不是线性增长:5个以上Agent时,并行化可以抵消部分开销,Supervisor模式的延迟增长从线性退化为亚线性 - Token成本是最大变量:Blackboard在不可预测收敛的场景中可能消耗3-5倍token,需要严格的budget上限 - Swarm的自愈能力被低估:实测中Swarm在一个Agent出错时有60%概率自动交接给替代Agent完成


六、变现与训练营评估

6.1 企业培训/训练营方向

方向 热度 单价区间 竞争度
多Agent客服系统(Router+Handoff) 🔥🔥🔥🔥🔥 ¥3,000-8,000 中
Agent协议栈实战(MCP+A2A+A2UI) 🔥🔥🔥🔥 ¥5,000-15,000 低
多Agent内容工厂(Supervisor) 🔥🔥🔥🔥 ¥2,000-5,000 高
跨企业Agent Mesh部署 🔥🔥🔥 ¥10,000-30,000 极低

6.2 产品化方向


七、趋势判断

  1. A2A v1.0是分水岭:v1.0.0的发布意味着A2A从"实验协议"变为"生产标准"。2026年下半年将出现大量A2A兼容的Agent市场/目录。

  2. Swarm → Mesh收敛:Swarm模式(单组织内)和Mesh模式(跨组织)正在技术层面收敛。OpenAI Agents SDK的Swarm概念和Google A2A的Mesh概念正在互相借鉴。

  3. Blackboard复兴加速:2026年已有3篇顶会论文(AAAI、ACL、NeurIPS)重新审视Blackboard架构在LLM时代的设计空间。共享状态+多Agent协作的模式特别适合RAG增强的诊断类任务。

  4. 共决策标准化:投票→辩论→陪审团的梯度正在被内建到框架中。LangGraph 0.3+已原生支持投票和辩论模式,OpenAI Agents SDK预计Q3 2026加入类似功能。

  5. Agent Card成为"名片":A2A的Agent Card正在成为Agent生态的通用描述格式,类比OpenAPI/Swagger对REST API的作用。


参考来源

  1. The Orchestration of Multi-Agent Systems: Architectures, Protocols, and Enterprise Adoption — arXiv综述论文,系统梳理多Agent编排的架构分类与企业采纳路径
  2. A2A Protocol Specification v1.0.0 — Google主导的Agent-to-Agent协议官方规范,定义Agent Card、Task生命周期等核心概念
  3. MultiAgentBench: Evaluating the Collaboration and Competition of LLM Agents — ACL 2025论文,7种共决策协议的系统性评测
  4. MCP, A2A, and A2UI: The Complete Protocol Stack for Multi-Agent Systems — 三层协议栈的实战指南,含完整代码示例
  5. 多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 等场景全覆盖。

51学通信知识星球海报-扫码加入