autumn-recruitment/06.AI/agent-design/多智能体协作模式.md

---
tags: [ai/agent, multi-agent, supervisor, critic-pattern, planner]
create time: 2026-08-08 18:43
update time: 2026-08-08 18:43
---

# 多智能体协作模式

## 概述

单个 Agent 的能力受限于上下文窗口和工具集。多智能体系统通过让多个专业化的 Agent 分工协作，实现复杂任务的可扩展解耦。核心挑战在于通信协议设计、任务分解质量和冲突消解机制。

## 详解

### Supervisor 模式 — 主从分发

Supervisor 作为中央调度器，接收用户请求后将任务拆解为子任务，分配给专业子 Agent，最后整合结果。

```mermaid
sequenceDiagram
    participant User as 用户
    participant S as Supervisor Agent
    participant A as Writer Agent
    participant B as Researcher Agent
    participant C as Editor Agent

    User->>S: 提交复合需求
    S->>S: 任务分解与规划
    S->>B: 子任务1: 调研背景资料
    B-->>S: 返回调研报告
    S->>A: 子任务2: 撰写初稿
    A-->>S: 返回初稿
    S->>C: 子任务3: 审校编辑
    C-->>S: 返回定稿
    S-->>User: 交付最终结果
```

**关键设计决策：**
- **任务粒度**：子任务拆得太细导致通信开销过大；太粗则失去并行价值。一般 3-7 个粒度最合适——匹配人类短期记忆容量（Miller 法则）。
- **状态一致性**：所有中间产物存储在共享 State 中，Supervisor 负责读取每个阶段的产出并构造下一轮输入。

```go
// Go 示例：Supervisor 路由到子 Agent
type Supervisor struct {
    agents map[string]*Agent // agentId → Agent实例
    router ModelRouter   // LLM 驱动的路由决策
}

func (s *Supervisor) Dispatch(task string) string {
    intent := s.router.Classify(task) // 调用 LLM 判断意图类型
    resultChan := make(chan Result)

    for _, subtask := range s.Decompose(intent, task) {
        go func(st SubTask) {
            agent := s.agents[st.AgentID]
            resultChan <- agent.Execute(st)
        }(subtask)
    }

    return s.Aggregate(resultChan, len(subtasks))
}
```

### Critic 模式 — 审查反馈循环

Critic Agent 不生产内容，只评估已有内容的质量，给出评分和改进建议。形成 Producer-Critic 的对抗循环。

```mermaid
graph TD
    A["Producer Agent\n生成候选方案"] --> B["Critic Agent\n质量评分"]
    B --> C{"分数 ≥ 阈值?"}
    C -->|"否"| D["Feedback\n具体改进意见"]
    D --> A
    C -->|"是"| E["接受输出"]
```

**适用场景：**代码审查、文章校对、Prompt 优化验证、安全策略校验。

> [!NOTE]
> Critic 的质量取决于它的评估标准是否量化。纯自然语言的评判主观性太强，应该定义结构化评分维度：准确性、完整性、安全性各占权重。

### Planner 模式 — 规划先行

Planner Agent 先输出一串有序的步骤序列，Executors 按步骤逐个执行。Plan 可静态制定，也可动态调整。

**静态 Planning：**
```
Step 1: 搜索「XX 技术栈的性能基准」
Step 2: 汇总三个数据源的对比表
Step 3: 针对劣势项提出优化建议
Step 4: 生成总结报告
```

**动态 Planning（Replan）：** 当某一步失败或结果不符合预期时，Planner 重新规划后续步骤。例如搜索结果为空时，自动调整为「扩大搜索范围 → 使用同义词 → 切换到备选信息源」。

#### Swarm 模式 — 蜂群协作

Swarm 没有中心调度器。所有 Agent 只看同一个共享环境（比如一张公共白板），各自根据局部线索自主行动，互不发消息。

```mermaid
graph LR
    SA["Agent A\n看线索 → 行动"] --> WB["公共环境 / 共享状态"]
    SB["Agent B\n看线索 → 行动"] --> WB
    SC["Agent C\n看线索 → 行动"] --> WB
    SD["Agent D\n看线索 → 行动"] --> WB
    WB --> Out["最终聚合"]
```

**跟 Supervisor 的根本区别：**

| 维度 | Supervisor | Swarm（蜂群） |
|------|-----------|--------------|
| 通信方式 | Agent ↔ Supervisor ↔ Agent（中心化） | Agent ↔ 共享环境（去中心化） |
| 协调者 | 有 | 无 |
| 每个 Agent 知道全局吗 | 不知道，只知道自己的子任务 | 也不知道，只看局部线索 |
| 结果如何汇总 | Supervisor 聚合 | 各自产出叠加即可 |

**类比理解：**

- **Supervisor** = 指挥官发号施令，士兵执行并汇报
- **Swarm** = 一群蜜蜂围着蜂巢转，每只各自找花蜜，最后蜂蜜自然 accumulate

**适用场景：**头脑风暴、概念发散、大量独立验证——即"**不需要商量、答案 = 所有人想法的总和**"的场景。比如让 10 个 Agent 各出 20 个点子，再挑最好的几条。

> [!WARNING]
> Swarm 的坑：① 多个 Agent 可能重复试同一个方向（浪费算力）；② 缺少全局约束时，产出容易过于发散难整理；③ 某个 Agent 发现走不通也无法通知别人及时止损。

## 消息传递协议

多 Agent 之间通过结构化消息通信，推荐基于 JSON Schema 定义契约：

```json
{
  "type": "task_assignment",
  "id": "task_001",
  "from": "supervisor",
  "to": "researcher",
  "payload": {
    "instruction": "检索 Golang gc 在 1.21 中的改动",
    "timeout_ms": 30000,
    "format": "structured_summary"
  }
}
```

**消息类型体系：**

| 类型 | 方向 | 用途 |
|------|------|------|
| `task_assignment` | S→Agent | 分配子任务 |
| `result_report` | Agent→S | 汇报完成结果 |
| `feedback_request` | C→Agent | 要求重新生成 |
| `escalation` | Agent→S | 上报异常求决策 |
| `cancellation` | S→All | 全局取消信号 |

### 各模式对比

| 模式 | 优点 | 缺点 | 最佳适用场景 |
|------|------|------|-------------|
| Supervisor | 架构清晰、便于监控 | 单点瓶颈、上下文窗口压力大 | 复杂长链路任务，如研究报告生成 |
| Critic | 显著提升输出质量 | 增加延迟和 token 消耗 | 对准确性要求高的场景 |
| Planner | 解耦规划与执行、支持重试 | Plan 可能不合理需 Replan | 步骤依赖明确的流水任务 |
| Swarm | 简洁灵活、天然并行 | 缺乏全局协调、易产生不一致 | 探索性、发散性头脑风暴 |

> [!TIP]
> 面试高频题：为什么不做一个超级大的 Agent？答案：① 上下文窗口有限，塞入太多能力会稀释注意力；② 工具冲突概率随数量增加而上升；③ 调试困难——出问题时无法定位是哪个模块的问题；④ 迭代成本高，改一个能力可能需要重新微调整个模型。

## 实践场景

**项目复盘：Gen2D 项目中的多 Agent 设计**

Gen2D 项目中采用了 Supervisor + Planner 混合模式：
1. 入口 Agent 将用户需求分解为前端/后端/测试三条线
2. 每条线内由 Planner 制定步骤序列
3. Executor Agent 按步骤执行，每次执行后写入共享日志
4. Reviewer Agent 做最终交叉检查

这种分层设计避免了单层 DAG 节点过多导致的管理复杂度。

## 扩展阅读

- [[Eino DAG 工作流设计]]
- [[上下文工程与记忆管理]]