多Agent五范式×三协议：协作架构选型实战

2026年，多Agent系统从实验室走向生产的关键转折已经发生。单个Agent能力天花板的逼近，使得业界共识加速收敛：协作即规模（Coordination is the new scale）。然而，"多个Agent一起干活"远比想象中复杂——架构选错，三个月后必推倒重来。本文聚焦多Agent协作系统的五大架构范式、三大通信协议以及涌现行为的工程治理，给出可落地的选型决策框架。

一、五大协作架构范式深度拆解

多Agent协作不是"把几个Agent拼在一起"那么简单。微软、Google、LangChain、学术界各自提出了分类体系，经过2025-2026年的生产验证，五大范式已形成业界共识：

1.1 Supervisor-Worker：生产首选的"经理-员工"模式

这是2026年采用率最高的多Agent模式。一个Supervisor Agent负责理解用户意图、拆分子任务、分发给专业Worker Agent、收集结果并综合回答。

范式	核心思想	拓扑结构	最适场景	生产成熟度
Supervisor-Worker	中心调度器分配任务，Worker汇报结果	星形	流水线式任务分解	★★★★★
Pipeline/Sequential	Agent按固定顺序串联，上游输出即下游输入	链式	内容生成、数据处理	★★★★☆
Council/Voting	多Agent独立推理，投票/加权汇总决策	全互联	决策评审、风险评估	★★★★☆
Blackboard	共享状态空间，Agent异步读写	总线型	复杂问题求解、情报分析	★★★☆☆
Mesh/Swarm	去中心化对等协作，涌现行为驱动	网状	探索性任务、群体智能	★★☆☆☆

架构原理： Supervisor维护全局状态和任务队列，通过工具调用（function calling）或消息传递将子任务分配给Worker。Worker之间不直接通信，所有协调经由Supervisor中转。这种中心化设计带来的最大优势是可观测性——每一步决策都有明确的责任归属。

# LangGraph Supervisor-Worker 核心实现
from langgraph.graph import StateGraph, MessagesState, START, END
from langgraph.types import Command

def supervisor_node(state: MessagesState) -> Command:
    """Supervisor决定下一步路由到哪个Worker"""
    messages = state["messages"]
    response = llm.invoke([
        {"role": "system", "content": "你是调度器，决定将任务分配给：researcher、coder、reviewer"},
        *messages
    ])
    # 解析路由决策
    goto = parse_route(response.content)
    return Command(goto=goto, update={"messages": [response]})

def researcher_node(state: MessagesState):
    """研究Agent执行调研任务"""
    result = research_tool.invoke(state["messages"][-1].content)
    return {"messages": [{"role": "assistant", "content": result}]}

builder = StateGraph(MessagesState)
builder.add_node("supervisor", supervisor_node)
builder.add_node("researcher", researcher_node)
builder.add_node("coder", coder_node)
builder.add_node("reviewer", reviewer_node)
builder.add_edge(START, "supervisor")
builder.add_edge("researcher", "supervisor")
builder.add_edge("coder", "supervisor")
builder.add_edge("reviewer", "supervisor")
builder.add_conditional_edges("supervisor", route_fn, ["researcher", "coder", "reviewer", END])

优缺点分析： 优势在于实现简单、调试友好、天然支持checkpoint和恢复。劣势是Supervisor成为单点瓶颈——当Worker超过8个时，Supervisor的上下文窗口和推理延迟会成为系统天花板。

变现评估： 这是最适合包装为训练营的范式。"用LangGraph搭建你的第一个Supervisor-Worker系统"是目前市场上最畅销的AI Agent课程方向之一，客单价500-2000元区间接受度最高。

1.2 Pipeline/Sequential：链式流水线的确定性之选

当任务天然具备阶段性时（如：调研→大纲→初稿→审校→终稿），Pipeline模式提供最强的执行确定性。每个Agent只关心自己的输入输出，无需理解全局。

架构原理： 类似Unix管道，Agent A的stdout成为Agent B的stdin。状态以结构化schema（通常为JSON Schema或Pydantic Model）在节点间传递。LangGraph的StateGraph和CrewAI的Process.sequential都原生支持此模式。

关键工程细节： Pipeline的核心挑战不在编排，而在数据契约——上下游Agent之间的接口定义。2026年的最佳实践是用TypedDict或Pydantic严格约束每个节点的输入输出类型，避免"Agent A输出了Agent B无法解析的格式"这类运行时故障。

1.3 Council/Voting：群体智慧的工程化

Council模式让多个Agent独立对同一问题给出答案，然后通过投票、加权平均或辩论机制汇聚最终决策。这是对抗单Agent幻觉和偏见的最有效手段之一。

架构原理： 通常由一个Chair Agent发起议题，N个Expert Agent并行推理，Chair收集所有回复后执行聚合策略。聚合策略包括：简单多数投票、加权投票（按Expert在特定领域的置信度加权）、辩论式（Expert之间可见彼此回答并修正）、级联式（低置信度时升级到更强的Expert）。

# CrewAI Council模式示例
from crewai import Agent, Crew, Task, Process

researcher = Agent(role="市场研究员", goal="收集竞品数据", backstory="资深市场分析师")
analyst = Agent(role="数据分析师", goal="量化市场趋势", backstory="数据科学背景")
strategist = Agent(role="战略顾问", goal="制定进入策略", backstory="MBA+10年战略咨询")

# 三人独立完成同一任务，然后投票决策
task = Task(
    description="评估东南亚市场进入可行性",
    agent=[researcher, analyst, strategist],  # 多Agent并行
    output_format="decision_matrix"
)

crew = Crew(
    agents=[researcher, analyst, strategist],
    tasks=[task],
    process=Process.consensus  # 共识决策流程
)

生产实践： Google DeepMind的内部研究表明，3-Agent Council在安全评估中比单Agent减少42%的错误输出。但成本是单Agent的3倍，延迟也增加约2.5倍。变现方向：将Council模式包装为"AI决策委员会"产品，面向金融风控、法律审查等高风险场景。

1.4 Blackboard：共享记忆的异步协作

源自经典AI的Blackboard架构在2026年焕发新生。多个Agent通过一个共享的状态空间（"黑板"）异步读写信息，无需直接通信。

架构原理： 核心是一个持久化的共享存储，Agent可以随时写入自己的推理结果、读取其他Agent的输出。一个Controller Agent监控黑板状态，决定何时触发哪些Agent参与。这种模式特别适合信息不完整、需要多轮渐进求解的复杂问题。

与Supervisor的关键区别： Supervisor模式下Worker之间完全隔离；Blackboard模式下Worker可以间接受到其他Worker输出的影响（通过读取黑板），但不需要直接通信。这种"松耦合"在情报分析、故障诊断等场景中表现优异。

1.5 Mesh/Swarm：涌现行为的双刃剑

去中心化的Mesh网络是学术界最关注、也是生产中最难驾驭的模式。Agent之间对等通信，没有中心调度器，系统行为从局部交互中涌现。

架构原理： 每个Agent维护自己的状态和邻居列表，通过gossip协议或stigmergy（蚂蚁信息素机制）进行间接协调。AutoGen的GroupChat模式是这一范式的代表——Agent在一个共享聊天室中自由发言，下一个发言者由LLM自动决定。

2026年的新认知： Zylos Research的研究指出，涌现行为在大规模多Agent系统中是真实存在且不可消除的，只能管理。Nature发表的"Unraveling the emergence of collective behavior in networks of cognitive agents"论文证实：LLM Agent网络会在没有显式指令的情况下自发形成社会规范、市场策略和道德偏好。这既是创新的源泉，也是风险的来源。

二、三大通信协议：Agent互联互通的基础设施

如果说架构范式定义了Agent"怎么协作"，那么通信协议定义了Agent"怎么说话"。2026年，三大协议形成了清晰的分层：

graph TB
    subgraph "应用层：协作范式"
        S[Supervisor-Worker]
        P[Pipeline]
        C[Council/Voting]
        B[Blackboard]
        M[Mesh/Swarm]
    end

    subgraph "协议层：通信标准"
        A2A["A2A Protocol<br/>Agent↔Agent<br/>Google主导"]
        MCP["MCP<br/>Agent↔Tool<br/>Anthropic主导"]
        ACP["ACP<br/>Agent↔Context<br/>IBM主导"]
    end

    subgraph "传输层"
        HTTP["HTTP/2 + SSE"]
        GRPC["gRPC"]
        WS["WebSocket"]
    end

    S --> A2A
    P --> MCP
    C --> A2A
    B --> ACP
    M --> A2A

    A2A --> HTTP
    MCP --> HTTP
    ACP --> GRPC

2.1 A2A（Agent-to-Agent）：Google推动的Agent互联标准

A2A是2026年最值得关注的协议。它解决的核心问题是：不同框架、不同厂商构建的Agent如何互相发现和通信。

协议架构： A2A基于HTTP/2 + SSE，定义了Agent Card（能力描述）、Task（任务委托）、Message（通信消息）、Part（多模态内容片段）四个核心概念。每个Agent通过.well-known/agent.json发布自己的能力描述，其他Agent可以据此发现和调用。

与MCP的关系： A2A不是MCP的替代，而是互补。MCP解决Agent如何使用外部工具（Agent→Tool），A2A解决Agent之间如何对话（Agent→Agent）。一个完整的系统通常同时使用两者：MCP让Agent获取工具能力，A2A让多个Agent组成协作网络。

生产状态： Google Cloud已在其Vertex AI Agent Engine中集成A2A，Adobe、Salesforce等企业已宣布支持。但截至2026年6月，A2A仍在快速迭代中，API稳定性不足，不建议在关键路径上深度依赖。

2.2 MCP（Model Context Protocol）：工具调用的USB-C

MCP在2025年底由Anthropic提出后，已成为Agent与外部工具/数据源连接的事实标准。它的定位是"Agent世界的USB-C接口"——统一替换之前每个Agent框架各自实现的工具调用协议。

关键能力： Resources（静态数据暴露）、Tools（可执行操作）、Prompts（模板化提示词）、Sampling（服务端请求LLM推理）。MCP Server可以暴露任何能力——数据库查询、API调用、文件系统访问——而Agent通过统一的MCP Client消费这些能力。

在多Agent系统中的角色： MCP主要解决Agent的"手和眼"问题——让单个Agent具备足够的能力。在Supervisor-Worker模式下，每个Worker通常配置不同的MCP Server集合（如Researcher连接搜索MCP，Coder连接GitHub MCP）。

2.3 ACP（Agent Communication Protocol）：IBM的企业级选择

ACP是IBM提出的另一种Agent间通信协议，侧重企业级场景的可靠性、安全性和审计能力。与A2A的"开放互联"理念不同，ACP更强调"管控下的协作"——内置RBAC、消息签名、不可篡改日志。

三、涌现行为的工程治理：从恐惧到驾驭

多Agent系统最令人兴奋也最令人不安的特性是涌现行为（Emergent Behavior）——系统整体展现出任何单个Agent都不具备的行为模式。

3.1 涌现的类型学

3.2 MAEBE框架：涌现行为的系统评估

类型	表现	风险等级	示例
功能涌现	Agent自发分工、协作策略优化	低	三个Agent自发形成"探索-验证-整合"分工
社会涌现	Agent形成社会规范、影响力层级	中	Agent自发产生"权威服从"倾向
对抗涌现	Agent共谋、策略操纵	高	定价Agent串通形成垄断价格

2026年6月发表的MAEBE（Multi-Agent Emergent Behavior Evaluation）框架是首个系统评估涌现行为的工具。核心发现：孤立LLM的安全评估结果不能直接推广到多Agent场景。单个Agent在安全测试中表现良好，不代表多个Agent组成的系统同样安全——因为Agent间交互会产生新的攻击面。

工程启示： 任何多Agent系统上线前，除了常规的单Agent安全测试，还必须进行： 1. 交互审计：监控Agent间通信是否偏离预期 2. 涌现测试：在受控环境中观察系统级行为 3. 边界探测：刻意制造冲突输入，观察系统是否稳定收敛

3.3 Nature论文的关键发现

Nature于2026年发表的"Unraveling the emergence of collective behavior"论文提供了实验证据：LLM Agent网络中，共识形成速度与网络拓扑强相关。小规模网络（<5个Agent）中共识形成极快但可能过早收敛到错误结论；大规模网络（>20个Agent）中共识形成较慢但最终结论更可靠。最优Agent数量在5-9个之间。

四、框架选型决策矩阵

基于架构范式和通信协议的分析，以下是2026年主流框架在不同协作模式下的适配度：

框架	Supervisor-Worker	Pipeline	Council	Blackboard	Mesh/Swarm	学习曲线	生产就绪度
LangGraph	★★★★★	★★★★★	★★★★☆	★★★☆☆	★★★☆☆	陡峭	★★★★★
CrewAI	★★★★☆	★★★★★	★★★★★	★★☆☆☆	★★☆☆☆	平缓	★★★★☆
AutoGen	★★★☆☆	★★★☆☆	★★★★☆	★★★★☆	★★★★★	中等	★★★☆☆
OpenAI Agents SDK	★★★★★	★★★★☆	★★★☆☆	★★☆☆☆	★★☆☆☆	最平缓	★★★★☆
DSPy	★★☆☆☆	★★★★★	★★☆☆☆	★☆☆☆☆	★☆☆☆☆	陡峭	★★★☆☆

flowchart TD
    Start[多Agent系统选型] --> Q1{任务是否可分解为<br/>独立子任务?}
    Q1 -->|是| Q2{需要中心化控制<br/>还是去中心化?}
    Q1 -->|否| Q3{是否需要多视角<br/>独立评估?}

    Q2 -->|中心化| Q4{子任务间是否<br/>有严格顺序?}
    Q2 -->|去中心化| A1[AutoGen GroupChat<br/>Mesh模式]

    Q4 -->|是| A2[LangGraph Pipeline<br/>或 CrewAI Sequential]
    Q4 -->|否| A3[LangGraph Supervisor<br/>或 OpenAI Agents SDK]

    Q3 -->|是| A4[CrewAI Consensus<br/>或 自建Council]
    Q3 -->|否| Q5{问题是否需要<br/>渐进式求解?}

    Q5 -->|是| A6[AutoGen Blackboard<br/>+ 共享状态]
    Q5 -->|否| A7[重新审视是否<br/>需要多Agent]

    style A1 fill:#ff9800,stroke:#333,color:#000
    style A2 fill:#4caf50,stroke:#333,color:#000
    style A3 fill:#2196f3,stroke:#333,color:#000
    style A4 fill:#9c27b0,stroke:#333,color:#000
    style A6 fill:#f44336,stroke:#333,color:#000

五、六大实战陷阱与解法

陷阱1：Agent数量崇拜

症状： 认为Agent越多能力越强，动辄部署20+Agent。真相： 5-9个Agent是大多数任务的最优区间。超过10个Agent后，协调成本（Supervisor的上下文消耗、通信延迟、Token消耗）急剧上升，收益递减。Google DeepMind的实验表明，从3个Agent增加到7个能提升约35%的任务完成率，但从7个增加到15个仅提升8%。

解法： 先从2-3个Agent起步，只在明确的性能瓶颈处增加Agent。用"每个Agent必须有不可替代的职责"作为增减标准。

陷阱2：忽略数据契约

症状： Agent之间传递自由文本，下游Agent经常无法理解上游输出。真相： 这是最常见的生产故障模式。解决方案是强制每个Agent节点的输入输出都经过Pydantic Model校验。

from pydantic import BaseModel
from typing import Literal

class ResearchOutput(BaseModel):
    """Researcher Agent的输出契约"""
    findings: list[str]
    confidence: float  # 0.0-1.0
    sources: list[str]
    gaps: list[str]  # 信息缺口

class AnalysisInput(BaseModel):
    """Analyst Agent的输入契约"""
    findings: list[str]
    context: str
    depth: Literal["surface", "medium", "deep"]

陷阱3：通信协议混用

症状： 同一系统内同时用A2A、MCP、自定义WebSocket，调试时无法追踪消息流。解法： 2026年的最佳实践是"协议分层"——MCP只用于Agent→Tool，A2A只用于Agent→Agent，不在同一层混用多种协议。

陷阱4：涌现行为未监控

症状： Agent自发形成了预期外的协作模式或决策倾向，直到产生错误输出才被发现。解法： 部署"观察者Agent"——一个不参与任务执行、只监控其他Agent通信内容的Agent，负责检测异常模式（如两个Agent过度一致、价格Agent趋向相同报价等）。

陷阱5：状态管理灾难

症状： 多Agent共享可变状态，产生竞态条件和不一致。解法： 采用事件溯源（Event Sourcing）模式——Agent不直接修改共享状态，而是发布事件，由一个专门的State Reducer按顺序处理。LangGraph的checkpoint机制本质上是这一模式的实现。

陷阱6：成本失控

症状： 多Agent系统的Token消耗是单Agent的5-15倍，且难以预测。解法： 在Supervisor节点实施"预算卡"——为每个任务设定Token上限，Worker超过预算时强制截断。同时，对Supervisor→Worker的通信进行压缩（只传递必要上下文而非完整对话历史）。

六、推荐方案

场景	推荐架构	推荐框架	预计Agent数	Token成本倍率
内容生产流水线	Pipeline	CrewAI	3-5	3-5×
企业知识问答	Supervisor-Worker	LangGraph	4-7	4-6×
代码审查与生成	Supervisor-Worker	OpenAI Agents SDK	3-4	3-4×
金融风控决策	Council/Voting	LangGraph + 自建投票	5-7	5-7×
情报分析	Blackboard	AutoGen	6-10	6-10×
探索性研究	Mesh/Swarm	AutoGen GroupChat	3-5	5-8×
客服工单处理	Pipeline + Supervisor	LangGraph	4-6	4-5×

终极建议： 2026年构建多Agent系统，优先选择Supervisor-Worker或Pipeline作为初始架构，使用LangGraph（需要精细控制）或CrewAI（需要快速原型）作为框架，用MCP连接工具、用A2A连接Agent。从小规模（3个Agent）开始，在明确的性能瓶颈处才增加复杂度。记住：协作即规模，但规模不等于Agent数量——等于协调效率。