mirror of
https://github.com/claude-code-best/claude-code.git
synced 2026-06-18 14:25:51 +00:00
271fd840e9
移除 TypeScript 代码、源码路径和 7 种任务类型枚举， 聚焦 Coordinator 先理解再分配的设计哲学、 Swarm 竞争认领的并发安全和模式选择指南。 Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
102 lines
5.2 KiB
Plaintext
102 lines
5.2 KiB
Plaintext
---
|
||
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 的文件系统隔离
|
||
- **任务管理** — 理解支撑协作的任务系统
|