单 Agent 的天花板
单 Agent 模式在简单任务上表现良好,但遇到复杂场景时会暴露致命缺陷:
- 上下文窗口爆炸:一个 Agent 要理解所有领域知识,Prompt 越来越长,质量越来越差
- 单一视角偏见:LLM 有自己的思维定势,规划、校验、润色全由一人包办等于没有审查
- 无法并行:查天气、查机票、查酒店互不依赖,但单 Agent 只能串行等待
- 调试地狱:输出不满意?你不知道是规划错了、检索错了还是生成错了
多 Agent 架构的本质是分而治之——把复杂系统的不同职责拆分给专门的 Agent,让它们协作完成整体任务。
四种经典架构模式
模式一:Orchestrator(编排器模式)
┌─────────────┐
│ Orchestrator │ ← 中央调度者
└──┬───┬───┬──┘
│ │ │
┌──────┘ │ └──────┐
▼ ▼ ▼
┌────────┐ ┌────────┐ ┌────────┐
│Agent A │ │Agent B │ │Agent C │
└────────┘ └────────┘ └────────┘
一个主 Agent(Orchestrator)负责任务分解和分发,多个 Worker Agent 各司其职。
class OrchestratorAgent:
def run(self, task: str) -> str:
# 1. 分解任务
subtasks = self.decompose(task)
# ["查天气", "查机票", "查酒店"]
# 2. 并行分发
results = await asyncio.gather(*[
self.dispatch(sub) for sub in subtasks
])
# 3. 汇总整合
return self.synthesize(results)
def decompose(self, task) -> list:
return self.llm.plan(
f"将以下任务分解为可并行的子任务: {task}"
)
优点:结构简单,容易理解和调试;Orchestrator 有全局视角。 缺点:Orchestrator 成为单点瓶颈;无法处理 Agent 间的动态交互。 适用:任务可预先分解、子任务间无复杂依赖的场景。
模式二:Hierarchical(层级模式)
┌──────────┐
│ CEO Agent│
└────┬─────┘
│
┌──────────┼──────────┐
▼ ▼ ▼
┌────────┐ ┌────────┐ ┌────────┐
│Manager │ │Manager │ │Manager │
│ A │ │ B │ │ C │
└───┬────┘ └───┬────┘ └───┬────┘
│ │ │
┌────┼────┐ ... ...
▼ ▼ ▼
Worker Worker Worker
层级模式在 Orchestrator 基础上增加了管理层。CEO Agent 定方向,Manager Agent 管执行,Worker Agent 干活。
class HierarchicalSystem:
def __init__(self):
self.ceo = CEOAgent()
self.managers = {
"research": ManagerAgent("research"),
"writing": ManagerAgent("writing"),
"review": ManagerAgent("review"),
}
async def run(self, task: str):
# CEO 定策略
strategy = self.ceo.plan(task)
# {research: "查最新AI新闻",
# writing: "写一篇评论",
# review: "事实核查+润色"}
# 各 Manager 并行执行自己的子任务
results = {}
for dept, subtask in strategy.items():
results[dept] = await self.managers[dept].execute(subtask)
# CEO 最终审核
return self.ceo.review(results)
优点:适合超复杂任务(如代码仓库分析 → 模块分析 → 文件修改);管理者可以独立优化自己的团队。 缺点:层级越深,通信延迟越大;顶层 Agent 可能做出错误的战略决策。 适用:企业级复杂工作流,需要多层次决策的场景。
模式三:Swarm(蜂群模式)
┌──────┐ ┌──────┐ ┌──────┐
│Agent1│◄───►│Agent2│◄───►│Agent3│
└──┬───┘ └──┬───┘ └──┬───┘
│ │ │
└────────────┼────────────┘
▼
┌────────┐
│ 环境/ │
│ 黑板 │
└────────┘
没有中央调度者,Agent 之间直接通信协商。灵感来自蚁群和蜂群的去中心化协作。
class SwarmAgent:
def __init__(self, name: str, role: str):
self.name = name
self.role = role
self.memory = []
self.peers = []
async def broadcast(self, message: str):
"""向所有同伴广播消息"""
responses = []
for peer in self.peers:
if peer.name != self.name:
resp = await peer.receive(self.name, message)
responses.append(resp)
return responses
async def receive(self, sender: str, message: str) -> str:
"""接收同伴消息并决定是否响应"""
if self._is_relevant(message):
return self.act(message)
return "not relevant"
def _is_relevant(self, message: str) -> bool:
return any(kw in message for kw in self.keywords)
优点:高度鲁棒,单个 Agent 挂掉不影响整体;天然适合探索性任务。 缺点:收敛困难,可能出现"死循环讨论";调试几乎不可能。 适用:头脑风暴、开放式研究、需要多视角碰撞的场景。
模式四:Blackboard(黑板模式)
┌─────────────────┐
│ Blackboard │
│ (共享状态) │
└──┬──┬──┬──┬─────┘
│ │ │ │
┌──────┘ │ │ └──────┐
▼ ▼ ▼ ▼
┌───────┐ ┌───────┐ ┌───────┐
│Agent 1│ │Agent 2│ │Agent 3│
└───────┘ └───────┘ └───────┘
所有 Agent 共享一块"黑板"——一个公共状态空间。每个 Agent 从黑板读取当前状态,做出贡献,写回黑板。
class Blackboard:
def __init__(self):
self.state = {}
self.contributions = []
def write(self, agent: str, key: str, value):
self.state[key] = value
self.contributions.append({
"agent": agent,
"key": key,
"value": value,
"timestamp": time.time()
})
def read(self) -> dict:
return self.state.copy()
def is_stable(self, threshold: int = 3) -> bool:
"""如果连续 N 轮没有新贡献,认为收敛"""
recent = self.contributions[-threshold:]
return len(set(c["key"] for c in recent)) == 0
class BlackboardAgent:
def __init__(self, name: str, expertise: list[str]):
self.name = name
self.expertise = expertise
async def act(self, blackboard: Blackboard):
state = blackboard.read()
# 只在专业领域做贡献
for area in self.expertise:
if area not in state or self._can_improve(state[area]):
improvement = await self.analyze(state, area)
blackboard.write(self.name, area, improvement)
优点:Agent 间松耦合,可以随时加入或退出;状态对所有 Agent 透明。 缺点:黑板成为单点瓶颈;并发写入需要处理冲突。 适用:需要多专业协作的复杂分析(如金融分析:基本面 + 技术面 + 估值 + 舆情)。
四大模式对比
| 模式 | 调度方式 | Agent 间通信 | 复杂度 | 容错 | 适用场景 |
|---|---|---|---|---|---|
| Orchestrator | 中央调度 | 间接(通过编排器) | ⭐ | ⭐⭐ | 任务可预分解 |
| Hierarchical | 层级调度 | 层级内直接 | ⭐⭐⭐ | ⭐⭐⭐ | 复杂工作流 |
| Swarm | 无调度 | 直接广播 | ⭐⭐⭐⭐ | ⭐⭐⭐⭐ | 头脑风暴 |
| Blackboard | 无调度 | 间接(通过黑板) | ⭐⭐ | ⭐⭐⭐ | 多专业协作 |
主流框架怎么实现
CrewAI(Orchestrator 模式)
from crewai import Agent, Task, Crew
researcher = Agent(
role="研究员",
goal="查找最新 AI 趋势",
backstory="资深技术研究员",
allow_delegation=False
)
writer = Agent(
role="撰稿人",
goal="根据研究结果写报告",
backstory="科技专栏作者",
allow_delegation=False
)
task1 = Task(description="研究2024年AI Agent的发展趋势", agent=researcher)
task2 = Task(description="基于研究结果写一篇2000字的综述", agent=writer)
crew = Crew(agents=[researcher, writer], tasks=[task1, task2])
result = crew.kickoff()
CrewAI 的核心是 顺序任务链——上一个任务的输出自动成为下一个任务的输入。
AutoGen(对话式)
from autogen import AssistantAgent, UserProxyAgent
assistant = AssistantAgent("assistant", llm_config={"model": "gpt-4"})
user_proxy = UserProxyAgent("user_proxy", code_execution_config={"work_dir": "workspace"})
# 两个 Agent 通过对话协作,Assistant 写代码,UserProxy 执行
user_proxy.initiate_chat(
assistant,
message="帮我写一个爬取 Hacker News 前10条新闻的脚本"
)
AutoGen 的精髓在于 Agent 之间的自然语言对话——不需要预定义流程,Agent 在对话中自主协商。
LangGraph(图编排)
from langgraph.graph import StateGraph
graph = StateGraph(AgentState)
graph.add_node("researcher", researcher_node)
graph.add_node("writer", writer_node)
graph.add_node("reviewer", reviewer_node)
graph.add_edge("researcher", "writer")
graph.add_edge("writer", "reviewer")
graph.add_conditional_edges(
"reviewer",
lambda s: "writer" if s.needs_revision else "end",
{"writer": "writer", "end": END}
)
LangGraph 的哲学是 显式定义流程——每一步的去向由状态和图结构决定,不是 LLM 自由发挥。
框架选型决策树
你的任务特征是什么?
├── 有明确的顺序步骤?
│ └── CrewAI(顺序任务链最简单)
├── 需要 Agent 之间自由协商?
│ └── AutoGen(对话驱动,灵活)
├── 需要复杂的分支和循环逻辑?
│ └── LangGraph(图结构,可视化流程)
├── 去中心化、无领导者?
│ └── 自建 Swarm(轻量,但调试难)
└── 多专业协作、共享状态?
└── Blackboard + LangGraph(共享状态 + 图编排)
实践中的 5 条避坑指南
1. 不要过度拆分
3 个能完成的事不要用 10 个 Agent。每增加一个 Agent,就增加一个 LLM 调用的延迟和失败概率。
2. Agent 必须"知道自己不知道什么"
每个 Agent 应该有明确的专业边界。当收到超出能力范围的任务时,应该明确说"这不是我的领域",而不是强行编造。
3. 共享上下文,但不共享 Prompt
Agent 之间传递结构化数据(JSON),而不是自然语言描述。自然语言每传递一次信息就损失 10%。
4. 收敛条件是刚需
Swarm 和 Blackboard 模式必须有明确的收敛条件——最大轮数、状态稳定性阈值、人工终止信号。没有收敛条件的多 Agent 系统等于死循环。
5. 先单 Agent,再多 Agent
如果你的单 Agent 还没跑通,不要幻想多 Agent 能解决。多 Agent 只会放大单 Agent 的问题。
总结
多 Agent 不是银弹,但在以下场景确实有效:
- 任务可分拆:子任务间无强依赖,可并行
- 需要多视角:同一个问题需要不同专业知识协同
- 需要校验:一个生成,一个检查,天然分工
- 容错需求:某个 Agent 挂了不影响整体
选型口诀:线性的用 CrewAI,对话的用 AutoGen,图的用 LangGraph,去中心的自己写。