05.1 — 多智能体架构
定位: 多 Agent 系统的骨架——理解不同架构模式的设计思路、取舍和适用场景 面试高频度: ⭐⭐⭐⭐ 考查方式: 架构设计题（设计多 Agent 协作系统）、对比题（架构模式的选择和权衡）
一、这是什么？为什么需要它？
是什么
多智能体架构 定义了多个 Agent 之间如何进行组织、协调和交互的结构模式。它决定了系统的控制流、信息流和决策权分配。
为什么需要多 Agent 架构？
❌ 单 Agent 的局限：
一个 Agent 的知识和能力有限
任务太复杂时单 Agent 难以处理
单点故障（Agent 一错全错）
无法并行工作
✅ 多 Agent 的优势：
专业化（每个 Agent 擅长一个领域）
并行化（多个 Agent 同时工作）
鲁棒性（个别 Agent 失败不影响整体）
辩论与验证（多个 Agent 互相审查）核心洞察：多 Agent 不是"多个单 Agent 的简单聚合"，而是需要精心设计的协作系统。
二、原理拆解
2.1 三种经典架构
① 集中式架构（Centralized）
┌────────────────────────────────────────────┐
│ 集中式架构 │
│ │
│ ┌────────────────────────────────────┐ │
│ │ 中央控制器 (Orchestrator) │ │
│ │ • 接收任务 │ │
│ │ • 分解任务 │ │
│ │ • 分配任务 │ │
│ │ • 监控进度 │ │
│ │ • 汇总结果 │ │
│ └────┬────┬────┬────┬────┬──────────┘ │
│ │ │ │ │ │ │
│ ▼ ▼ ▼ ▼ ▼ │
│ ┌──┐ ┌──┐ ┌──┐ ┌──┐ ┌──┐ │
│ │A1│ │A2│ │A3│ │A4│ │A5│ ← 工作者 │
│ └──┘ └──┘ └──┘ └──┘ └──┘ │
└────────────────────────────────────────────┘
优点：控制简单，全局可见
缺点：单点故障，中心成为瓶颈python
class Orchestrator:
"""集中式架构的中央控制器"""
def __init__(self):
self.workers = {} # name -> Agent
def register_worker(self, name: str, agent, specialty: str):
self.workers[name] = {
"agent": agent,
"specialty": specialty,
"status": "idle"
}
def execute_task(self, task: str):
# 1. 任务分解
subtasks = self.decompose(task)
# 2. 分配任务
results = {}
for subtask in subtasks:
worker = self.select_worker(subtask)
self.workers[worker]["status"] = "busy"
result = self.workers[worker]["agent"].run(subtask)
self.workers[worker]["status"] = "idle"
results[worker] = result
# 3. 汇总
return self.synthesize(results)
def select_worker(self, subtask: str) -> str:
decision = llm.call(f"子任务：{subtask}\n可用工作者：{list(self.workers.keys())}\n选择最适合的：")
return decision.strip()② 分布式架构（Decentralized）
┌────────────────────────────────────────────┐
│ 分布式架构 │
│ │
│ ┌─────┐ ┌─────┐ ┌─────┐ │
│ │ A1 │◄──►│ A2 │◄──►│ A3 │ │
│ │ │ │ │ │ │ │
│ │ 专家 │ │ 专家 │ │ 专家 │ │
│ └──┬──┘ └──┬──┘ └──┬──┘ │
│ │ │ │ │
│ └──────────┼──────────┘ │
│ │ │
│ ┌─────┴─────┐ │
│ │ 共享黑板 │ │
│ │ (Blackboard) │
│ └───────────┘ │
└────────────────────────────────────────────┘
优点：无单点故障，可自由扩展
缺点：协调复杂，可能死锁python
class DecentralizedAgent:
"""分布式架构中的单个 Agent"""
def __init__(self, name: str, specialty: str, blackboard):
self.name = name
self.specialty = specialty
self.blackboard = blackboard # 共享黑板
def run(self, task: str):
# 先查看黑板上是否已有相关信息
existing = self.blackboard.read(task)
# 基于已有信息 + 自己的专业知识处理
result = llm.call(f"你是一个{self.specialty}专家。\n"
f"任务：{task}\n"
f"已有信息：{existing}")
# 把结果写回黑板
self.blackboard.write(self.name, task, result)
return result③ 分层式架构（Hierarchical）
┌────────────────────────────────────────────┐
│ 分层式架构 │
│ │
│ 战略层 │
│ ┌────────────────────────────────────┐ │
│ │ 经理 Agent │ │
│ │ 设定目标、制定策略、分配资源 │ │
│ └────────────────┬───────────────────┘ │
│ │ │
│ ┌────────────────┼───────────────────┐ │
│ │ │ │ │
│ │ ┌─────────────▼─────────────┐ │ │
│ │ │ 协调层 │ │ │
│ │ │ Project Manager Agent │ │ │
│ │ │ 任务分解、进度管理 │ │ │
│ │ └─────────────┬─────────────┘ │ │
│ │ │ │ │
│ │ ┌─────────────┼─────────────┐ │ │
│ │ │ │ │ │ │
│ │ ▼ ▼ ▼ │ │
│ │ ┌───┐ ┌───┐ ┌───┐ │ │
│ │ │ A │ │ B │ │ C │ │ │
│ │ │执行│ │执行│ │执行│ │ │
│ │ └───┘ └───┘ └───┘ │ │
│ │ 执行层 │ │
│ └────────────────────────────────────┘ │
└────────────────────────────────────────────┘2.2 架构选择矩阵
| 场景 | 推荐架构 | 原因 |
|---|---|---|
| 任务流程固定（如文档处理流水线） | 集中式 | 中央控制容易编排固定流程 |
| Agent 需要深度协作（如辩论式代码审查） | 分布式 | Agent 自主交互更灵活 |
| 大规模系统（如企业自动化平台） | 分层式 | 各层专注不同抽象级别 |
| 快速原型 | 集中式 | 实现最简单 |
| 高可用要求 | 分布式 | 无单点故障 |
2.3 多 Agent 系统的挑战
| 挑战 | 描述 | 缓解策略 |
|---|---|---|
| 通信开销 | Agent 之间消息过多 | 使用共享黑板减少一对一通信 |
| 协调成本 | 决策需要共识时很慢 | 使用分层减少协调面 |
| 幻觉传播 | 一个 Agent 的错误通过通信扩散 | 加入审查/验证 Agent |
| 目标不一致 | Agent 之间的目标冲突 | 统一奖励/评价标准 |
| 死锁/活锁 | Agent 互相等待或无限循环 | 超时机制 + 仲裁者 |
三、图解全景
┌─────────────────────────────────────────────────────────┐
│ 架构选择决策树 │
│ │
│ 需要多 Agent 吗？ │
│ ├── 否 → 用单 Agent 更简单 │
│ └── 是 │
│ │ │
│ ▼ │
│ 任务流程固定吗？ │
│ ├── 是 → 集中式架构 │
│ │ ↓ │
│ │ 需要高可用吗？ │
│ │ ├── 是 → 加入冗余工作者 │
│ │ └── 否 → 基本集中式即可 │
│ │ │
│ └── 否 → Agent 需要自主协商吗？ │
│ ├── 是 → 分布式架构 │
│ │ ↓ │
│ │ 规模大吗？ → 加入分层管理 │
│ │ │
│ └── 否 → 分层式架构 │
│ │
└─────────────────────────────────────────────────────────┘四、实战验证
python
# 三种架构的快速实现对比
# === 集中式：代码审查系统 ===
orchestrator = Orchestrator()
orchestrator.register_worker("code_analyzer", CodeAnalysisAgent(), "静态分析")
orchestrator.register_worker("security_checker", SecurityAgent(), "安全审查")
orchestrator.register_worker("reviewer", ReviewAgent(), "代码审查")
result = orchestrator.execute_task("审查 PR #123 的代码变更")
print(f"集中式审查结果: {result}")
# === 分布式：头脑风暴系统 ===
blackboard = Blackboard()
agents = [
DecentralizedAgent("设计师", "UI/UX", blackboard),
DecentralizedAgent("工程师", "技术实现", blackboard),
DecentralizedAgent("产品经理", "用户需求", blackboard)
]
for agent in agents:
agent.run("为在线教育平台设计一个新功能")
print(f"黑板上的最终方案: {blackboard.read('最终方案')}")
# === 分层式：项目管理 ===
manager = ManagerAgent("项目总监")
coordinator = ProjectCoordinator()
workers = [DevAgent("前端"), DevAgent("后端"), DevAgent("测试")]
plan = manager.make_plan("开发用户登录功能")
coordinator.execute_plan(plan, workers)五、面试视角
| 追问 | 答案要点 |
|---|---|
| 三种多 Agent 架构的优缺点？ | 集中式（简单但单点故障）、分布式（鲁棒但协调复杂）、分层式（平衡但结构复杂）。选型看任务特性 |
| 什么时候不应该用多 Agent？ | 单 Agent 能解决的问题、任务太简单、通信成本 > 协作收益、延迟敏感的场景。多 Agent 不是银弹 |
| 多 Agent 系统最大的挑战？ | 协调成本（Agent 间通信和决策）、一致性（多个 Agent 对同一任务的理解可能不同）、错误传播（一个 Agent 的错误会影响其他 Agent） |
| 如何设计多 Agent 的容错？ | 超时机制（Agent 无响应时重试或换人）、冗余（关键角色有备选）、断路器（连续失败的 Agent 隔离）、手动降级（退化为单 Agent 模式） |
📚 相关链接
- **通信与协调** — Agent 间如何通信
- **角色分配与编排** — 如何设计角色
- **AutoGen** — AutoGen 的分布式架构
- **CrewAI** — CrewAI 的角色化架构
- ← 返回 **多智能体系统索引**