首页 › ai-agents › 多Agent六层编排拓扑:从调度到共识的实测

概述

2026年中期,多Agent系统已从实验原型全面进入生产环境,但编排架构的选择仍是决定项目成败的第一变量。本文实测六种主流编排拓扑——主管-工人(Supervisor-Worker)、层级委派(Hierarchical Delegation)、流水线(Pipeline)、黑板共享(Blackboard)、蜂群共识(Swarm Consensus)、DAG工作流(DAG Workflow)——在延迟、状态一致性、容错性和运维复杂度四个维度上的真实表现。同时覆盖A2A协议1.0发布后的跨框架互操作新格局、Microsoft Conductor开源带来的确定性编排范式,以及多Agent共享状态并发写入这一被严重低估的生产杀手。结论:没有一种拓扑万能,但2026年的生产系统正在收敛到"DAG骨架+黑板状态+事件驱动恢复"的三层混合架构。


一、六种编排拓扑全景对比

维度 Supervisor-Worker Hierarchical Pipeline Blackboard Swarm Consensus DAG Workflow
调度模型 中心路由器分发 多级主管递归委派 线性/分支顺序执行 共享空间+控制循环 去中心化投票/辩论 声明式依赖图
状态管理 主管持有全局状态 每层主管缓存子树 流水传递中间产物 黑板集中存储 各Agent独立+协议同步 图节点输出+检查点
瓶颈风险 主管过载单点 上层主管阻塞 慢节点拖累全链 控制循环竞争 共识轮次爆炸 编译验证开销
容错机制 主管重试/切换 层级降级回退 断点续传 回滚黑板版本 少数派容忍 节点级重试
适用规模 3-8 Agent 5-20 Agent 2-6 Agent 4-15 Agent 5-50+ Agent 3-30 Agent
上手难度 ★★☆ ★★★ ★☆☆ ★★★★ ★★★★ ★★★
生产就绪度 高 中高 高 中 低中 高

框架映射

拓扑 LangGraph CrewAI AutoGen OpenAI Agents Google ADK
Supervisor ✅ 原生支持 ✅ 原生支持 ✅ GroupChat ✅ Runner ✅ Agent.transfer()
Hierarchical ✅ 子图嵌套 ⚠️ 有限 ✅ NestedChat ❌ ⚠️ 有限
Pipeline ✅ 线性图 ✅ Sequential ✅ 顺序对话 ✅ Handoff链 ✅ 流式Agent
Blackboard ⚠️ 需自建 ⚠️ 需自建 ⚠️ 需自建 ❌ ❌
Swarm ⚠️ 需自建 ❌ ✅ Swarm模式 ✅ Swarm ✅ Loop Agent
DAG ✅ 原生核心 ⚠️ 流程编排 ⚠️ 需封装 ❌ ⚠️ 有限

二、深度分析六种拓扑

2.1 主管-工人(Supervisor-Worker):生产使用率最高

架构原理。 一个中心Agent充当路由器,接收用户请求后判断应该分发给哪个专业Agent处理。工人Agent执行完毕后将结果返回主管,由主管决定下一步——继续分发、合成输出、或终止。这是2026年使用率最高的模式,Presenc AI的调研显示超过55%的生产多Agent系统采用此拓扑。

核心代码(LangGraph实现)。

from langgraph.graph import StateGraph, MessagesState, START, END
from langgraph.types import Command

def supervisor(state: MessagesState) -> Command:
    """主管路由:分析最后一条消息,决定分发给谁"""
    last_msg = state["messages"][-1].content
    if "代码" in last_msg or "bug" in last_msg:
        return Command(goto="coder")
    elif "分析" in last_msg or "数据" in last_msg:
        return Command(goto="analyst")
    else:
        return Command(goto="responder")

builder = StateGraph(MessagesState)
builder.add_node("supervisor", supervisor)
builder.add_node("coder", coder_agent)
builder.add_node("analyst", analyst_agent)
builder.add_node("responder", responder_agent)
builder.add_edge(START, "supervisor")
builder.add_edge("coder", "supervisor")
builder.add_edge("analyst", "supervisor")
builder.add_edge("responder", END)
graph = builder.compile()

优缺点。 优势在于实现简单、状态集中、调试直观——你只需看主管的路由日志就能追踪完整链路。劣势是主管成为单点瓶颈:当Agent数量超过8个、并发请求超过20QPS时,主管的LLM推理延迟(通常500ms-2s)会堆积成显著的排队延迟。生产中的常见缓解策略是将路由决策从LLM调用降级为规则引擎或嵌入向量相似度匹配。

训练营评估。 这是入门多Agent的最低门槛,一个3小时的workshop足够覆盖从搭建到部署。变现潜力★★★☆。

2.2 层级委派(Hierarchical Delegation):复杂任务拆解

架构原理。 在Supervisor基础上引入多级委派:顶层主管只做战略分解,将子任务委派给中层主管;中层主管进一步分解给自己的工人。典型的三层结构是"产品经理→技术负责人→开发者/测试员"。AutoGen的NestedChat和LangGraph的子图嵌套是2026年实现此模式的主流方式。

关键挑战。 层级越深,上下文损失越严重。第3层Agent接收到的指令可能已经经过了两次自然语言转述,原始需求的精确度下降约15-25%(基于Paiteq的实测数据)。解决方案是在每层委派时附带结构化的任务描述(JSON Schema),而非纯文本指令。

适用场景。 代码审查流水线(架构审查→安全审查→风格审查)、多步骤研究任务(主题选择→文献检索→论文起草→同行评审)。当任务自然分解为3层以上时,Hierarchical比扁平Supervisor节省30-40%的Token消耗。

2.3 流水线(Pipeline):确定性最高

架构原理。 Agent按固定顺序排列,前一个的输出作为后一个的输入。最简单的拓扑,也是确定性最高的——每个步骤的输入输出可完全预测。2026年新增的变体是条件分支流水线:在特定节点根据中间结果选择不同的下游路径。

核心代码(CrewAI Sequential)。

from crewai import Agent, Task, Crew, Process

researcher = Agent(role="Researcher", goal="Gather information",
                   backstory="Expert researcher", llm="gpt-4.1")
writer = Agent(role="Writer", goal="Write article",
               backstory="Professional writer", llm="gpt-4.1")
editor = Agent(role="Editor", goal="Review and polish",
               backstory="Senior editor", llm="claude-sonnet-4-6")

research_task = Task(description="Research {topic}", agent=researcher,
                     expected_output="Research notes with sources")
write_task = Task(description="Write article from research",
                  agent=writer, expected_output="Draft article")
edit_task = Task(description="Edit and finalize", agent=editor,
                 expected_output="Final article")

crew = Crew(agents=[researcher, writer, editor],
            tasks=[research_task, write_task, edit_task],
            process=Process.sequential)
result = crew.kickoff(inputs={"topic": "Multi-Agent Architecture 2026"})

优缺点。 优势是零编排复杂度、完美的可观测性、最容易做断点续传。劣势是无法处理需要迭代/反馈的任务——如果Editor发现Researcher的信息不足,Pipeline无法回溯。生产中通常用"带反馈环的Pipeline"变体解决:设置最大重试次数,失败时回退到指定节点。

2.4 黑板共享(Blackboard):2026年复兴的经典模式

架构原理。 源自1980年代HEARSAY-II语音识别系统的经典架构,2026年在LLM多Agent领域强势回归。核心思想是:多个专家Agent围绕一块共享的"黑板"(结构化状态空间)工作,每个Agent独立读取黑板内容、贡献自己的专业知识、更新黑板状态。一个控制组件(Controller)决定下一个该激活哪个Agent。

为什么2026年复兴? 因为其他拓扑在处理"需要多Agent协同构建同一产物"的场景时都力不从心。Supervisor无法让Agent真正并行协作;Pipeline是串行的;Swarm缺乏结构化协调。黑板模式天然支持并行写入、增量构建、冲突检测。

三组件详解。

# 1. 黑板:结构化共享状态空间
class Blackboard:
    def __init__(self):
        self.state = {}           # 全局状态字典
        self.history = []         # 版本历史,支持回滚
        self.lock = asyncio.Lock() # 并发写入锁

    async def write(self, agent_id: str, key: str, value: Any):
        async with self.lock:
            version = len(self.history)
            self.history.append({
                "version": version, "agent": agent_id,
                "key": key, "old_value": self.state.get(key),
                "new_value": value, "timestamp": time.time()
            })
            self.state[key] = value

# 2. 控制器:调度策略
class Controller:
    def __init__(self, agents, blackboard):
        self.agents = agents
        self.bb = blackboard

    async def run(self, max_iterations=20):
        for _ in range(max_iterations):
            # 评估每个Agent的贡献意愿
            contributions = []
            for agent in self.agents:
                score = await agent.evaluate(self.bb.state)
                contributions.append((score, agent))
            contributions.sort(reverse=True)

            if contributions[0][0] < THRESHOLD:
                break  # 没有Agent愿意贡献,结束

            best_agent = contributions[0][1]
            await best_agent.execute(self.bb)  # 执行并更新黑板

# 3. 专家Agent
class ExpertAgent:
    def __init__(self, specialty, llm):
        self.specialty = specialty
        self.llm = llm

    async def evaluate(self, state):
        """评估自己能否对当前状态做出有价值的贡献"""
        prompt = f"Given current state: {json.dumps(state)}, 
                  can you contribute as {self.specialty}? Score 0-1."
        return float(await self.llm.invoke(prompt))

生产挑战。 黑板模式的并发写入是最大的工程难题。AgentMarketCap的深度分析指出:"多Agent系统通常不是因为模型出错而失败,而是因为两个Agent同时读取同一文件、各自独立编辑、然后竞相写回——没有任何错误抛出,一个Agent的工作静默消失。"乐观锁(Optimistic Locking)是2026年主流解决方案:每个Agent在写入时携带读取时的版本号,如果黑板已被其他Agent更新,则触发合并或重试。

2.5 蜂群共识(Swarm Consensus):去中心化决策

架构原理。 没有中心调度器。Agent之间通过投票、辩论、或轮流发言达成共识。Zylos Research的分析指出,经典分布式共识协议(Paxos、Raft、PBFT)为确定性状态机设计,无法直接应用于LLM Agent——因为Agent是随机的、上下文敏感的、能够真正"讨论"的。2026年的共识模式已演化为三种变体:

代价。 Token消耗是Supervisor模式的3-7倍。5个Agent辩论3轮 = 至少15次LLM调用。生产中通常限制在3-5个Agent + 2-3轮辩论,并在共识已达成(>80%一致)时提前终止。

2.6 DAG工作流(DAG Workflow):2026年确定性编排新星

架构原理。 将多Agent任务建模为有向无环图(DAG)。每个节点是一个Agent调用,边表示依赖关系。无依赖的节点并行执行,有依赖的节点按拓扑排序执行。2026年5月Microsoft开源了Conductor——一个MIT许可的CLI工具,标志着DAG编排从LangGraph生态走向框架无关。

Microsoft Conductor核心设计。

# workflow.yaml - Conductor声明式DAG定义
name: code-review-pipeline
steps:
  - id: security-scan
    agent: security-reviewer
    prompt: "Review for security vulnerabilities: {code}"

  - id: style-check
    agent: style-reviewer
    prompt: "Check coding style: {code}"

  - id: perf-analysis
    agent: perf-reviewer
    prompt: "Analyze performance implications: {code}"

  - id: synthesize
    agent: lead-reviewer
    depends_on: [security-scan, style-check, perf-analysis]
    prompt: |
      Combine these reviews into actionable feedback:
      Security: {security-scan.output}
      Style: {style-check.output}
      Performance: {perf-analysis.output}

关键优势。 确定性执行:同样的DAG定义+同样的输入 = 同样的执行路径(Agent输出本身非确定性,但编排逻辑100%确定性)。这解决了"Agent编排不可复现"这一长期痛点——你可以精确复现任何一次执行的调度顺序、每步的输入输出、以及失败位置。

Temporal vs LangGraph vs Inngest。 CallSphere的对比评测指出三者各有所长:LangGraph与LangChain生态深度绑定,上手最快但锁定最深;Temporal提供最强的持久化保障(工作流状态持久化到数据库,进程崩溃后自动恢复),但学习曲线陡峭;Inngest介于两者之间,事件驱动模型适合实时场景。2026年推荐:新项目用Conductor(如果只需DAG调度),已有LangChain项目用LangGraph,需要跨天持久化的长任务用Temporal。


三、多Agent架构总图

graph TB
    subgraph "多Agent编排六拓扑"
        SW["Supervisor-Worker<br/>中心路由分发"]
        HI["Hierarchical<br/>多级层级委派"]
        PL["Pipeline<br/>线性/分支流水线"]
        BB["Blackboard<br/>共享状态空间"]
        SC["Swarm Consensus<br/>去中心化投票/辩论"]
        DA["DAG Workflow<br/>声明式依赖图"]
    end

    subgraph "跨Agent通信协议"
        A2A["A2A Protocol v1.0<br/>Agent间互操作"]
        MCP["MCP<br/>Agent到工具/数据"]
    end

    subgraph "持久化与执行引擎"
        LG["LangGraph<br/>图状态机"]
        TM["Temporal<br/>持久工作流"]
        IN["Inngest<br/>事件驱动"]
        CD["Conductor<br/>确定性DAG CLI"]
    end

    subgraph "状态管理"
        OPT["乐观锁<br/>版本号并发控制"]
        CHK["检查点<br/>DAG节点级快照"]
        EMB["嵌入向量<br/>语义状态检索"]
    end

    SW --> A2A
    HI --> A2A
    BB --> MCP
    SC --> A2A
    DA --> CD
    DA --> TM

    SW --> OPT
    BB --> OPT
    DA --> CHK

    A2A -.->|"互补"| MCP
    LG --> CHK
    TM --> CHK

四、A2A协议1.0:跨框架互操作新格局

2026年6月,Google主导的Agent2Agent(A2A)协议正式发布1.0版本,移交Linux基金会管理。这是多Agent领域2026年最重要的事件之一。

核心机制

A2A定义了三个原语:

  1. Agent Card(Agent名片): JSON-LD格式的Agent自我描述文件,包含能力列表、接受的输入格式、认证方式。Agent通过发布名片实现"可被发现"。
  2. Task(任务): 客户端Agent向远程Agent发起的异步任务请求。任务有唯一ID、生命周期(submitted→working→completed/failed),支持长时运行。
  3. Message & Artifact(消息与产物): 任务执行过程中的结构化通信。Message是中间状态更新,Artifact是最终交付物。

与MCP的关系。 A2A解决Agent-to-Agent通信,MCP解决Agent-to-Tool/Data通信。两者互补:一个Agent通过MCP访问数据库和API,通过A2A将子任务委派给另一个Agent。2026年的生产系统同时使用两者的比例已超过40%。

实测体验。 A2A的HTTP+JSON-RPC传输层实现简单,一个基本的A2A Server用Python写不到100行。但Agent Card的语义描述和任务协商机制在实际跨框架调用时仍有摩擦——不同框架对"能力"的粒度定义不一致,需要人工对齐。预计到2026年底随着生态成熟,这一问题将显著缓解。


五、共享状态并发写入:被低估的生产杀手

AgentMarketCap的分析直击要害:"当五个Agent共享一个代码库时,谁的状态是权威的?"这是多Agent系统在生产环境中面临的最棘手问题。

三种并发控制策略对比

策略 原理 适用场景 性能开销
悲观锁(Pessimistic Locking) 写入前获取排他锁 Agent数量少(2-3个)、写入冲突频繁 高——锁等待导致Agent空闲
乐观锁(Optimistic Locking) 写入时比对版本号,冲突则重试 Agent数量中等(4-10个)、冲突概率低 低——只在冲突时付出代价
事件溯源(Event Sourcing) 不直接修改状态,追加事件日志 需要完整审计轨迹的场景 中——重建状态需要回放日志

2026年推荐。 大多数多Agent系统使用乐观锁 + 最大重试次数。当冲突率超过30%时,说明Agent间的职责划分有问题——应该重新审视任务分解策略而非继续优化锁机制。


六、记忆架构:从孤岛到共享

Mem0的《2026 AI Agent记忆状态》报告指出,LoCoMo、LongMemEval、BEAM三大基准测试已成为记忆架构的标准评估工具。多Agent系统的记忆架构在2026年收敛为三种模式:

  1. 完全隔离(Isolated): 每个Agent独立维护自己的记忆。最简单但Agent间无法共享学到的知识。
  2. 完全共享(Shared): 所有Agent读写同一个记忆库。效率最高但隐私和干扰问题严重。
  3. 层级混合(Hierarchical Hybrid): Agent拥有私有工作记忆 + 可选的共享长期记忆。Greennode的分析认为这是2026年最有效的模式。

Zylos Research的深度分析将多Agent记忆映射到计算机架构概念:隔离记忆类似分布式系统的本地缓存,共享记忆类似共享内存多处理器,层级混合类似L1/L2/L3缓存层次结构。这种映射有助于借用成熟的计算机架构理论来解决多Agent记忆挑战。


七、选型决策树

graph TD
    START[多Agent编排选型] --> Q1{任务是否需要<br/>迭代/反馈?}
    Q1 -->|否| Q2{步骤间是否有<br/>明确依赖关系?}
    Q1 -->|是| Q3{反馈需要几个<br/>Agent参与?}

    Q2 -->|线性顺序| PL[Pipeline<br/>CrewAI Sequential<br/>确定性最高]
    Q2 -->|有依赖图| DA[DAG Workflow<br/>LangGraph / Conductor<br/>并行执行无依赖节点]
    Q2 -->|需要路由| SW[Supervisor-Worker<br/>LangGraph / OpenAI Agents<br/>最成熟的生产模式]

    Q3 -->|1对1反馈| PL2[Pipeline+反馈环<br/>最大重试3次]
    Q3 -->|多Agent协作<br/>构建同一产物| BB[Blackboard<br/>自建 / agent-blackboard<br/>并行写入+版本控制]
    Q3 -->|需要达成<br/>共识决策| SC[Swarm Consensus<br/>AutoGen / 自建<br/>Token消耗最高]

    Q3 -->|需要多级<br/>任务分解| HI[Hierarchical<br/>AutoGen NestedChat<br/>3层以上适用]

八、2026年下半年趋势判断

趋势一:Conductor引发DAG编排标准化。 Microsoft Conductor的MIT许可+CLI优先设计降低了DAG编排的门槛。预计到2026年底,DAG将成为多Agent编排的"默认骨架",类似于Kubernetes成为容器编排的默认选择。

趋势二:A2A生态爆发但碎片化风险。 A2A 1.0发布后,预计将有大量Agent服务提供商发布A2A兼容的Agent Card。但如果没有统一的注册中心(类似DNS),Agent发现将退化为点对点配置。

趋势三:黑板模式从学术界走向生产。 arXiv论文2507.01701将黑板架构引入LLM多Agent系统的提案已获得广泛关注。结合MCP的工具访问能力,黑板模式有望成为"多Agent协同编辑"场景的标准解法。

趋势四:混合拓扑成为主流。 单一拓扑无法满足复杂生产需求。2026年的生产系统正在收敛到"DAG骨架(定义执行依赖)+ 黑板状态(共享中间产物)+ 事件驱动恢复(处理失败)"的三层混合架构。


参考来源

  1. Agent Workflow Orchestration Patterns: DAG, Event-Driven, and Actor Models — Zylos Research — DAG/事件驱动/Actor三种编排模式的深度对比
  2. Conductor: Deterministic orchestration for multi-agent AI workflows — Microsoft Open Source Blog — Microsoft开源确定性DAG编排工具
  3. A2A Protocol Specification v1.0 — Google主导的Agent间互操作协议正式规范
  4. Concurrent Multi-Agent State Management — AgentMarketCap — 多Agent共享状态并发写入问题与乐观锁方案
  5. Blackboard Architecture: The Multi-Agent AI Pattern Making a Comeback — TopicTrick — 黑板架构在LLM时代的复兴与实践
  6. Multi-Agent Orchestration Frameworks 2026 — Presenc AI — LangGraph/CrewAI/AutoGen/Swarm/ADK五大框架生产就绪度对比
  7. Consensus Protocols for Multi-Agent Decision Making — Zylos Research — 多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学通信知识星球海报-扫码加入