Multi-Agent 架构模式
5.1 Multi-Agent 的核心价值
Multi-Agent 不是”更高级”，而是处理复杂性的工具：
Single-Agent 的局限:
- 上下文窗口有限
- 角色切换导致行为不一致
- 难以并行处理
- 难以独立扩展/测试各组件
Multi-Agent 解决:
- 专业化分工
- 独立上下文管理
- 并行执行
- 独立部署和迭代5.2 Multi-Agent 通信模式
白皮书总结了三种主要的 Multi-Agent 通信模式：
模式一: Orchestrator-Workers（编排者-执行者）
┌─────────────────┐
│ Orchestrator │
│ (编排者) │
│ - 理解任务 │
│ - 分配工作 │
│ - 汇总结果 │
└────────┬────────┘
│
┌─────────────┼─────────────┐
↓ ↓ ↓
┌────────┐ ┌────────┐ ┌────────┐
│Worker 1│ │Worker 2│ │Worker 3│
│(专家A) │ │(专家B) │ │(专家C) │
└────────┘ └────────┘ └────────┘特点: - Orchestrator 持有全局视图 - Workers 只关注自己的任务 - 适合流水线式工作流
挑战: - Orchestrator 成为瓶颈 - 单点失败风险 - Workers 间无法协作
最佳实践: - Orchestrator 只做路由，不做执行 - Workers 结果应该结构化返回 - 设置 Orchestrator 超时和 fallback
模式二: Hierarchical（分层架构）
┌─────────────────┐
│ Supervisor │
│ (监督者) │
└────────┬────────┘
│
┌──────────────┼──────────────┐
↓ ↓ ↓
┌───────────┐ ┌───────────┐ ┌───────────┐
│ Manager A │ │ Manager B │ │ Manager C │
│ (领域A) │ │ (领域B) │ │ (领域C) │
└─────┬─────┘ └─────┬─────┘ └─────┬─────┘
│ │ │
┌────┴────┐ ┌────┴────┐ ┌────┴────┐
↓ ↓ ↓ ↓ ↓ ↓
┌─────┐ ┌─────┐ ┌─────┐ ┌─────┐ ┌─────┐ ┌─────┐
│ A-1 │ │ A-2 │ │ B-1 │ │ B-2 │ │ C-1 │ │ C-2 │
└─────┘ └─────┘ └─────┘ └─────┘ └─────┘ └─────┘特点: - 每层只与直接上下级通信 - Manager 负责领域内协调 - Supervisor 负责跨领域协调
适用场景: - 组织结构复杂 - 需要权限隔离 - 不同团队负责不同层级
挑战: - 通信延迟累积 - 调试困难（跨多层） - 需要精心设计接口
模式三: Peer-to-Peer（对等协作）
┌──────────────────────────────────┐
│ Shared State │
│ (共享状态/消息总线) │
└──────────────────────────────────┘
↑ ↑ ↑
┌─────────┼───┼───┼─────────┐
│ │ │ │ │
┌────┴────┐ ┌──┴───┴──┐ ┌────┴────┐
│ Agent A │ │ Agent B │ │ Agent C │
│ (平等) │ │ (平等) │ │ (平等) │
└─────────┘ └─────────┘ └─────────┘特点: - 没有中心控制器 - Agent 通过共享状态或消息总线协作 - 更灵活、更去中心化
适用场景: - Agent 需要动态发现和协作 - 去中心化需求 - 容错性要求高
挑战: - 一致性保证困难 - 可能出现死锁或活锁 - 需要冲突解决机制
5.3 Multi-Agent 状态管理
核心原则: 永远不要用 LLM 上下文做状态存储
┌─────────────────────────────────────────────────────────────┐
│ Multi-Agent 状态管理架构 │
├─────────────────────────────────────────────────────────────┤
│ │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ External State Store (外部状态存储) │ │
│ │ - 数据库 (PostgreSQL, MongoDB) │ │
│ │ - KV Store (Redis) │ │
│ │ - 文件系统 │ │
│ │ - 消息队列 (Kafka, RabbitMQ) │ │
│ └─────────────────────────────────────────────────────┘ │
│ ↑↓ │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ State Schema (状态模式) │ │
│ │ { │ │
│ │ session_id: string, │ │
│ │ status: "planning" | "executing" | "done", │ │
│ │ plan: [...], │ │
│ │ current_step: number, │ │
│ │ results: [...], │ │
│ │ errors: [...] │ │
│ │ } │ │
│ └─────────────────────────────────────────────────────┘ │
│ ↑↓ │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ Agents (无状态) │ │
│ │ - 启动时读取状态 │ │
│ │ - 执行任务 │ │
│ │ - 写入更新 │ │
│ │ - 不持有任何持久状态 │ │
│ └─────────────────────────────────────────────────────┘ │
└─────────────────────────────────────────────────────────────┘5.4 Multi-Agent 的陷阱
白皮书警告了 Multi-Agent 的常见陷阱：
| 陷阱 | 表现 | 解决方案 |
|---|---|---|
| Agent Proliferation | Agent 数量失控 | 定期审查，合并相似职责 |
| Chat Protocol Chaos | Agent 间消息格式混乱 | 定义标准消息 Schema |
| State in Context | 在上下文中传递状态 | 使用外部状态存储 |
| Orchestrator Bottleneck | 所有决策都经过编排者 | 赋予 Worker 更多自主权 |
| Silent Failures | Agent 失败但系统不知情 | 强制结果校验和心跳 |