多智能体协作架构深度解析：从 Supervisor 到 Swarm 的生产级设计模式
引言：为什么需要多智能体协作？
当 AI Agent 从"执行单一任务"演进到"完成复杂工作流"时，单体架构的局限性迅速暴露：上下文窗口爆炸、决策能力过载、错误隔离困难。2024 年 Anthropic 在《Building Effective Agents》中明确提出核心理念——"保持简洁，仅在需要时引入复杂度"。多智能体协作的核心价值在于：通过专业化分工降低每个 Agent 的认知负担，通过结构化通信提升系统整体的可控性。
本文将从架构模式的视角，系统拆解五种主流多智能体协作拓扑，对比主流框架的实现差异，并给出生产级落地的选型建议。
一、协作模式分类图谱
多智能体协作可以从控制拓扑和通信模式两个维度理解：
| 维度 | 类型 | 特征 |
|---|---|---|
| 控制拓扑 | 中心化 | 由中央协调器分发任务、汇总结果 |
| 控制拓扑 | 去中心化 | Agent 之间直接通信，无全局控制器 |
| 通信模式 | 同步阻塞 | 请求-响应式，调用方等待返回 |
| 通信模式 | 异步事件 | 消息队列或事件驱动，解耦执行 |
基于这两个维度，业界已经沉淀出五种核心协作模式。
二、五种核心协作模式详解
2.1 Supervisor 模式（监督者模式）
架构概览： 一个中央 Supervisor Agent 负责任务分解、路由分发和结果汇总，Worker Agent 专注于特定领域的执行。
┌──────────────────┐
User Request ──→ │ Supervisor Agent │
└────────┬─────────┘
│ dispatch
┌──────────────┼──────────────┐
▼ ▼ ▼
┌──────────┐ ┌──────────┐ ┌──────────┐
│ Research │ │ Coder │ │ Reviewer │
│ Worker │ │ Worker │ │ Worker │
└──────────┘ └──────────┘ └──────────┘
│
▼
Aggregated Result
优势与局限：
- ✅ 全局视角，易于实现任务依赖和执行顺序控制
- ✅ 状态集中管理，便于检查点和恢复
- ⚠️ Supervisor 成为性能瓶颈和单点故障
- ⚠️ Worker 之间无法直接通信，信息共享效率低
LangGraph 实现示例：
from langgraph.graph import StateGraph, START, END
from typing import TypedDict, Annotated
import operator
class WorkflowState(TypedDict):
task: str
messages: Annotated[list, operator.add]
research_result: str
code_result: str
review_feedback: str
final_output: str
def supervisor(state: WorkflowState) -> WorkflowState:
"""中央调度器：分析任务并决定执行路径"""
# 根据 task 内容决定调用哪些 Worker
return {"messages": [f"Supervisor analyzing: {state['task']}"]}
def researcher(state: WorkflowState) -> WorkflowState:
"""研究 Worker：信息检索和分析"""
return {"research_result": "调研结果..."}
def coder(state: WorkflowState) -> WorkflowState:
"""编码 Worker：代码生成"""
return {"code_result": "生成的代码..."}
def reviewer(state: WorkflowState) -> WorkflowState:
"""审查 Worker：质量评估"""
return {"review_feedback": "审查意见..."}
# 构建有向图
graph = StateGraph(WorkflowState)
graph.add_node("supervisor", supervisor)
graph.add_node("researcher", researcher)
graph.add_node("coder", coder)
graph.add_node("reviewer", reviewer)
graph.add_edge(START, "supervisor")
graph.add_edge("supervisor", "researcher")
graph.add_edge("researcher", "coder")
graph.add_edge("coder", "reviewer")
graph.add_edge("reviewer", END)
app = graph.compile()
2.2 Orchestrator-Workers 模式（编排器-工作者模式）
与 Supervisor 的关键区别： Anthropic 将 Orchestrator-Workers 定义为——子任务不是预定义的，而是由编排器根据输入动态决定。
┌──────────────────────┐
Complex Task ──→ │ Orchestrator LLM │ ───→ 动态分解
└────────┬─────────────┘
│
┌──────────────┼──────────────┐
▼ ▼ ▼
┌──────────┐ ┌──────────┐ ┌──────────┐
│ Worker A │ │ Worker B │ │ Worker C │
│ (动态创建) │ │ (动态创建) │ │ (动态创建) │
└──────────┘ └──────────┘ └──────────┘
│
┌────────▼─────────────┐
│ Result Synthesis │
└──────────────────────┘
典型场景： 涉及多个文件的代码修改、跨文档的信息聚合分析。编排器需要先理解整体任务，再动态生成子任务描述并分派。
生产级设计要点：
import asyncio
from dataclasses import dataclass
from typing import Optional
@dataclass
class SubTask:
id: str
description: str
dependencies: list[str] = None
result: Optional[str] = None
status: str = "pending"
class Orchestrator:
def __init__(self, llm, worker_pool_size: int = 5):
self.llm = llm
self.semaphore = asyncio.Semaphore(worker_pool_size)
async def decompose(self, task: str) -> list[SubTask]:
"""动态分解任务为子任务列表"""
prompt = f"将以下任务分解为可并行执行的子任务：\n{task}"
# 解析 LLM 返回的结构化子任务
subtasks = await self._parse_subtasks(prompt)
return subtasks
async def execute(self, subtasks: list[SubTask]) -> str:
"""带依赖管理的并行执行"""
completed = set()
while len(completed) < len(subtasks):
ready = [
st for st in subtasks
if st.status == "pending"
and all(d in completed for d in (st.dependencies or []))
]
async with self.semaphore:
results = await asyncio.gather(
*[self._run_worker(st) for st in ready]
)
for st, result in zip(ready, results):
st.result = result
st.status = "completed"
completed.add(st.id)
return self._synthesize(subtasks)
2.3 Evaluator-Optimizer 模式（评估器-优化器模式）
架构核心： 生成器与评估器形成闭环迭代，类似软件工程中的 Code Review 循环。
┌──────────────┐ ┌──────────────┐
│ Generator │ ──────→ │ Evaluator │
│ (生成/执行) │ │ (评估/反馈) │
└──────────────┘ └──────┬───────┘
▲ │
│ Feedback Loop │
└─────────────────────────┘
关键设计决策：
- 终止条件：最大迭代次数、评估分数阈值、人工介入检查点
- 评估维度：准确性、完整性、代码质量、安全性
- 迭代策略：增量修复 vs 全量重生成
class EvaluatorOptimizer:
def __init__(self, generator_llm, evaluator_llm, max_rounds=3, threshold=0.85):
self.generator = generator_llm
self.evaluator = evaluator_llm
self.max_rounds = max_rounds
self.threshold = threshold
async def run(self, task: str) -> dict:
history = []
current_output = await self.generator.generate(task)
for round_num in range(self.max_rounds):
score, feedback = await self.evaluator.evaluate(task, current_output)
history.append({
"round": round_num + 1,
"score": score,
"feedback": feedback
})
if score >= self.threshold:
return {
"output": current_output,
"score": score,
"rounds": round_num + 1,
"history": history
}
# 增量修复模式
current_output = await self.generator.refine(
original_task=task,
previous_output=current_output,
feedback=feedback
)
return {"output": current_output, "final_round": self.max_rounds}
2.4 Swarm 模式（蜂群/去中心化模式）
架构核心理念： OpenAI 在 Swarm 实验框架中提出的范式——Agent 之间通过Handoff（交接） 机制实现扁平化的任务流转，无需中央控制器。
┌──────────┐ handoff ┌──────────┐ handoff ┌──────────┐
│ Agent A │ ─────────────→ │ Agent B │ ─────────────→ │ Agent C │
│ (Sales) │ │ (Support)│ │ (Tech) │
└──────────┘ └──────────┘ └──────────┘
↑ │
└──────────────────────────────────────────────────────┘
(可回传 handoff)
核心设计要素：
- Handoff 协议：Agent 在无法处理时将上下文传递给另一个 Agent
- 上下文连续性：交接时携带完整对话历史和任务状态
- 无全局状态：每个 Agent 只维护局部状态，降低系统复杂度
# Swarm 模式的核心：Handoff 定义
from typing import Optional
from dataclasses import dataclass
@dataclass
class Handoff:
target_agent: "Agent"
description: str # 何时应该交接
condition: Optional[str] = None # 可选的交接条件
class Agent:
def __init__(self, name: str, instructions: str, handoffs: list[Handoff] = None):
self.name = name
self.instructions = instructions
self.handoffs = handoffs or []
def should_handoff(self, message: str) -> Optional["Agent"]:
"""判断是否需要交接给其他 Agent"""
for handoff in self.handoffs:
if self._matches_condition(message, handoff):
return handoff.target_agent
return None
# 实际应用：客服系统
sales_agent = Agent(
name="Sales",
instructions="处理产品咨询和报价",
handoffs=[
Handoff(support_agent, "当用户反馈技术问题时"),
Handoff(tech_agent, "当用户需要技术支持时")
]
)
2.5 Blackboard 模式（黑板模式）
架构原理： 源自经典 AI 领域的黑板系统——所有 Agent 共享一个结构化的"黑板"（共享状态空间），Agent 独立读取/写入黑板上的信息，通过数据驱动实现隐式协作。
┌─────────────────────────────────────┐
│ Shared Blackboard │
│ ┌───────────┬──────────┬─────────┐ │
│ │ User Query│ Research │ Analysis│ │
│ │ Profile │ Data │ Result │ │
│ └───────────┴──────────┴─────────┘ │
└──────┬──────────┬──────────┬────────┘
│ │ │
┌────▼───┐ ┌───▼────┐ ┌──▼─────┐
│Agent A │ │Agent B │ │Agent C │
│(订阅) │ │(写入) │ │(读写) │
└────────┘ └────────┘ └────────┘
适用场景特点：
- 异构专业 Agent（如法律、技术、财务），各自关注黑板的不同区域
- Agent 之间不需要显式通信，通过共享数据间接协作
- 需要控制 Agent 的触发条件（如当研究数据更新时，分析 Agent 才启动）
from enum import Enum
from typing import Any
from datetime import datetime
class BlackboardSection(Enum):
USER_PROFILE = "user_profile"
RESEARCH_DATA = "research_data"
ANALYSIS_RESULT = "analysis_result"
RECOMMENDATION = "recommendation"
class Blackboard:
"""共享状态空间，支持事件通知"""
def __init__(self):
self._data: dict[BlackboardSection, Any] = {}
self._subscribers: dict[BlackboardSection, list] = {}
def write(self, section: BlackboardSection, value: Any, author: str):
self._data[section] = {
"value": value,
"author": author,
"timestamp": datetime.now().isoformat()
}
self._notify(section)
def read(self, section: BlackboardSection) -> Any:
return self._data.get(section)
def subscribe(self, section: BlackboardSection, callback):
if section not in self._subscribers:
self._subscribers[section] = []
self._subscribers[section].append(callback)
def _notify(self, section: BlackboardSection):
for callback in self._subscribers.get(section, []):
callback(self._data[section])
三、框架对比与选型指南
3.1 主流框架协作模式支持
| 框架 | Supervisor | Orchestrator-Workers | Evaluator-Optimizer | Swarm | Blackboard |
|---|---|---|---|---|---|
| LangGraph | ✅ 原生支持 | ✅ 原生支持 | ✅ 通过图循环实现 | ⚠️ 需自定义 | ⚠️ 需自定义 |
| CrewAI | ✅ Process.sequential | ✅ Process.hierarchical | ✅ 内置 human_input | ⚠️ 有限支持 | ❌ |
| OpenAI Swarm | ❌ | ❌ | ❌ | ✅ 核心范式 | ❌ |
| AutoGen | ✅ GroupChat | ✅ 两阶段聊天 | ✅ 内置反馈 | ⚠️ 需配置 | ⚠️ 可模拟 |
3.2 选型决策矩阵
任务类型 ──→ 选择依据
─────────────────────────────────────────
固定流程 ───→ Sequential Pipeline（无需多智能体框架）
动态路由 ───→ Supervisor + LangGraph
开放探索 ───→ Swarm / Autonomous Agent
质量控制 ───→ Evaluator-Optimizer 循环
异构专业 ───→ Blackboard + 事件驱动
四、生产级落地的关键技术挑战
4.1 上下文传递与状态爆炸
问题： 多智能体系统中，上下文在 Agent 之间传递时会指数级膨胀。
解决方案：
# 上下文压缩策略
class ContextCompressor:
def compress(self, messages: list, max_tokens: int) -> list:
if self._count_tokens(messages) <= max_tokens:
return messages
# 策略 1：保留最近 N 轮完整对话
recent = messages[-6:]
# 策略 2：历史对话摘要化
old_summary = self._summarize(messages[:-6])
return [{"role": "system", "content": f"历史摘要: {old_summary}"}] + recent
4.2 错误传播与容错设计
核心原则： 单个 Agent 的失败不应导致整个工作流崩溃。
# Circuit Breaker 模式保护 Agent 调用
from dataclasses import dataclass
from enum import Enum
class CircuitState(Enum):
CLOSED = "closed" # 正常
OPEN = "open" # 熔断
HALF_OPEN = "half_open" # 探测恢复
@dataclass
class AgentCircuitBreaker:
failure_threshold: int = 3
recovery_timeout: int = 60 # seconds
state: CircuitState = CircuitState.CLOSED
failure_count: int = 0
async def call(self, agent, task: str) -> dict:
if self.state == CircuitState.OPEN:
return {"status": "fallback", "message": "Agent 不可用，使用降级策略"}
try:
result = await agent.execute(task)
self.failure_count = 0
self.state = CircuitState.CLOSED
return result
except Exception as e:
self.failure_count += 1
if self.failure_count >= self.failure_threshold:
self.state = CircuitState.OPEN
return {"status": "error", "error": str(e)}
4.3 Token 成本控制
| 策略 | 预期节省 | 实现复杂度 |
|---|---|---|
| 模型分级路由（简单任务用小模型） | 40-60% | 低 |
| 语义去重（避免重复查询） | 20-30% | 中 |
| 上下文窗口裁剪 | 30-50% | 低 |
| Agent 输出结构化（JSON Schema） | 10-20% | 中 |
| 结果缓存（相似任务复用） | 20-40% | 中 |
4.4 可观测性设计
生产级多智能体系统必须实现完整的调用链追踪：
import uuid
import time
from contextlib import contextmanager
@contextmanager
def trace_agent(agent_name: str, trace_id: str = None):
"""Agent 调用追踪上下文管理器"""
trace_id = trace_id or str(uuid.uuid4())
span_id = str(uuid.uuid4())[:8]
start = time.time()
print(f"[TRACE] {trace_id} | {agent_name} | START | span={span_id}")
try:
yield {"trace_id": trace_id, "span_id": span_id}
duration = (time.time() - start) * 1000
print(f"[TRACE] {trace_id} | {agent_name} | END | span={span_id} | duration={duration:.0f}ms")
except Exception as e:
duration = (time.time() - start) * 1000
print(f"[TRACE] {trace_id} | {agent_name} | ERROR | span={span_id} | duration={duration:.0f}ms | error={e}")
raise
五、设计原则总结
Anthropic 在《Building Effective Agents》中提出了三个核心设计原则，结合我们的工程实践补充为五条：
-
最小复杂度原则 —— 如果一个 Prompt Chain 能解决问题，就不要引入多智能体框架。复杂度的每一层都应该换来明确的价值。
-
透明可控原则 —— Agent 的规划和执行过程应该是可观测的。调试一个黑箱式 Agent 比调试三个透明 Agent 困难得多。
-
工具接口优先原则 —— Agent-Computer Interface (ACI) 的设计质量直接决定系统上限。工具描述、参数 Schema、错误信息的清晰度，比模型选择更重要。
-
降级兜底原则 —— 每个智能体调用都应该有 Fallback 策略。Swarm 中一个 Agent 的 Handoff 失败不应阻塞用户请求。
-
成本意识原则 —— 区分必须用强模型的决策路径和可以用小模型处理的执行路径，模型分级路由是成本优化的第一要务。
结语
多智能体协作架构不是银弹，而是解决特定复杂度问题的工具箱。Supervisor 模式适合可控的业务流程，Swarm 模式适合开放性探索，Evaluator-Optimizer 适合质量敏感场景，Blackboard 适合异构专业协作。选择的关键不是"哪个最先进"，而是"哪个最适合你的问题复杂度"。
正如 Anthropic 所强调的：最好的 Agent 系统，是那些能优雅退化为更简单架构的系统。
