---
title: "协调者与蜂群"
description: "两种多 Agent 协作模式：Coordinator 的星型编排和 Swarm 的竞争认领。理解各自的设计权衡和适用场景。"
keywords: ["协调者模式", "蜂群模式", "Agent Swarm", "多 Agent 协作", "任务编排"]
---

## 核心问题

单个 AI Agent 的上下文窗口有限。当任务复杂到需要同时理解多个模块、执行多个并行操作时，单个 Agent 会力不从心。

多 Agent 协作的目标：让多个 AI Agent 分工合作，各自拥有独立的上下文窗口，协同完成复杂任务。

## 两种协作模式

| 维度 | Coordinator Mode | Agent Swarms |
|------|-----------------|--------------|
| **拓扑** | 星型：Coordinator 居中编排 | 星型 + P2P：Teammate 间可直接通信 |
| **角色** | Coordinator 理解决策，Worker 执行 | Team Lead 协调，Teammate 自主认领 |
| **适用** | 需要集中决策的复杂任务 | 并行度高、任务独立的场景 |

两者不是互斥的——可以组合使用，但那属于高级用法。

## Coordinator Mode：先理解，再分配

### 设计哲学

Coordinator Mode 最核心的约束：**Coordinator 必须先理解问题，再分配任务。**

反模式（禁止）：
> "Based on your findings, fix the auth bug" — 把理解的责任推给了 Worker

正确做法：
> "Fix the null pointer in src/auth/validate.ts:42. The user field is undefined when sessions expire but the token remains cached." — Coordinator 自己理解了问题，给出精确指令

**设计考量**：如果 Coordinator 不理解问题就分配任务，Worker 会因为缺乏上下文而做出错误的决策。Coordinator 的理解质量直接决定了 Worker 的执行质量。

### Coordinator 的工具限制

Coordinator 被剥夺了所有"动手"工具——不写代码、不读文件、不执行命令。只保留编排能力：启动 Worker、发送指令、停止走错方向的 Worker。

**设计洞察**：限制工具不是能力的削弱，而是职责的清晰化。Coordinator 专注于"想"，Worker 专注于"做"。如果 Coordinator 也能动手，它很容易跳过编排直接自己干，失去了多 Agent 的意义。

### Scratchpad：跨 Worker 共享知识

Workers 共享一个 Scratchpad 目录，可以自由读写。Worker A 的研究结果可以写入 Scratchpad，Worker B 直接读取，无需通过 Coordinator 中转。

**设计考量**：不是所有知识都需要通过 Coordinator 中转。中间结果（如搜索结果、分析报告）适合 Worker 间直接共享，只有最终结论和决策才需要 Coordinator 参与。

### 通信协议

Worker 完成后，Coordinator 收到结构化通知，包含状态、结果摘要和 token 使用统计。Coordinator 可以向任何 Worker 发送后续指令，实现"分配 → 执行 → 反馈 → 追加"的循环。

## Agent Teams (Swarm)：竞争认领

### 设计哲学

Swarm 基于一个简单的假设：**如果任务列表是共享的、可见的，多个 Agent 会自然地分工合作。**

不需要一个中央调度器——每个 Teammate 看到任务列表，自己决定认领哪个任务。这和人类团队的工作方式一致：站会上大家看到看板，自己选择下一步做什么。

### 核心机制

| 机制 | 说明 |
|------|------|
| **共享任务列表** | 所有 Teammate 看到同一个任务池 |
| **竞争认领** | 第一个锁定任务的 Teammate 获得执行权 |
| **Mailbox 消息** | Teammate 间可直接通信，无需经过 Lead |
| **异常恢复** | Teammate 崩溃后，其未完成任务被自动重置 |

### 竞争认领的并发安全

两个 Teammate 可能同时想认领同一个任务。文件锁保证原子性——第一个写入者获得锁定，第二个收到 `already_claimed` 错误后选择下一个任务。

**设计考量**：竞争是特性而非缺陷。它确保任务自然地分配给最先空闲的 Agent，不需要中央调度。但需要防止"饿死"——如果某个 Agent 总是慢半拍，它可能永远抢不到任务。实践中这个问题不严重，因为 AI Agent 的执行速度差异不大。

### Teammate 的生命周期

Teammate 异常退出时，其未完成任务被自动重置为无主状态。Team Lead 通过共享任务列表或空闲通知感知到变化，可以重新分配或创建新 Teammate。

**设计哲学**：单个 Agent 的崩溃不应该阻塞整个团队。任务系统保证工作不会因为个别 Agent 的失败而丢失。

### 当前限制

- 不支持嵌套团队（Teammate 不能创建子团队）
- 每会话一个团队
- Lead 固定不可更换

## 模式选择指南

| 场景 | 推荐模式 | 原因 |
|------|---------|------|
| "重构认证系统，需要多模块协调" | Coordinator | 需要集中决策，Worker 间有依赖 |
| "修复 10 个独立的 lint 警告" | Swarm | 任务独立，Teammate 可完全并行 |
| "研究方案 A 和方案 B，然后选一个实现" | Coordinator | 先并行研究，再集中决策 |
| "在大仓库中搜索所有 TODO 并分类" | Swarm | 无依赖，各自领任务即可 |

## 接下来

- **子 Agent** — 理解单个子 Agent 的创建和生命周期
- **Worktree 隔离** — 理解多 Agent 的文件系统隔离
- **任务管理** — 理解支撑协作的任务系统