swarm-coordination

Swarm Coordination 技能

Swarm Coordination 技能 - 编排并行 Agent 执行、管理 Agent 间通信、处理任务分配，并协调复杂多 Agent 工作流的结果汇总。 - 并行启动 Agent - 任务分配策略 - 结果汇总 - Agent 间通信 - 故障处理与恢复

步骤 1：分析任务的并行化可能

识别可并行的工作：

模式	示例	策略
独立任务	审查多个文件	并行启动
依赖任务	设计 → 实现	顺序启动
扇出/扇入	多项审查 → 汇总	并行 + 汇总
流水线	解析 → 转换 → 验证	顺序交接

步骤 2：并行启动 Agent

在单条消息中使用 Task 工具启动多个 Agent：

// Spawn multiple agents in ONE message for parallel execution
Task({
  task_id: 'task-1',
  subagent_type: 'general-purpose',
  description: 'Architect reviewing design',
  prompt: 'Review architecture...',
});

Task({
  task_id: 'task-2',
  subagent_type: 'general-purpose',
  description: 'Security reviewing design',
  prompt: 'Review security...',
});

要点：两个 Task 调用必须位于同一条消息中，才能实现真正的并行。

步骤 3：定义交接格式

使用结构化格式进行 Agent 间通信：

## Agent Handoff: [Source] → [Target]

### Context

- Task: [What was done]
- Files: [Files touched]

### Findings

- [Key finding 1]
- [Key finding 2]

### Recommendations

- [Action item 1]
- [Action item 2]

### Artifacts

- [Path to artifact 1]
- [Path to artifact 2]

步骤 4：汇总结果

合并并行 Agent 的输出：

## Swarm Results Aggregation

### Participating Agents

- Architect: Completed ✅
- Security: Completed ✅
- DevOps: Completed ✅

### Consensus Points

- [Point all agents agree on]

### Conflicts

- [Point agents disagree on]
- Resolution: [How to resolve]

### Combined Recommendations

1. [Prioritized recommendation]
2. [Prioritized recommendation]

步骤 5：处理故障

应对部分故障的策略：

场景	策略
Agent 超时	使用更简单的提示词重试
Agent 出错	使用可用结果继续
结果冲突	使用 consensus-voting 技能
缺少关键结果	阻止后续操作并重试

</execution_process>

<best_practices>

1. 积极并行化：独立工作应并行执行
2. 结构化交接：使用一致的通信格式
3. 平稳降级：在安全的情况下，使用部分结果继续
4. 清晰汇总：系统地合并结果
5. 跟踪来源：了解每项结果由哪个 Agent 生成

</best_practices>

**并行审查请求**：

Get architecture, security, and performance reviews for the new API design

Swarm 协调：

// Spawn 3 reviewers in parallel (single message)
Task({ task_id: 'task-3', description: 'Architect reviewing API', prompt: '...' });
Task({ task_id: 'task-4', description: 'Security reviewing API', prompt: '...' });
Task({ task_id: 'task-5', description: 'Performance reviewing API', prompt: '...' });

汇总结果：

## API Design Review (3 agents)

### Consensus

- RESTful design is appropriate
- Need authentication on all endpoints

### Recommendations by Priority

1. [HIGH] Add rate limiting (Security)
2. [HIGH] Use connection pooling (Performance)
3. [MED] Add versioning to URLs (Architect)

</usage_example>

规则

• 始终并行启动相互独立的 Agent
• 使用结构化交接格式
• 妥善处理部分故障

相关工作流

此技能针对复杂多 Agent 场景提供了相应的工作流：

• 工作流：.claude/workflows/enterprise/swarm-coordination-skill-workflow.md
• 何时使用工作流：适用于具有 Queen/Worker 拓扑、容错能力和分布式协调的大规模并行任务执行（大规模重构、并行代码审查、多文件实现）
• 何时直接使用技能：适用于简单的并行 Agent 启动，或将 swarm 模式集成到其他工作流中

工作流集成

此技能为整个框架中的多 Agent 编排模式提供支持：

路由器决策： .claude/workflows/core/router-decision.md

• 路由器使用 swarm 模式并行启动 Agent
• 规划编排矩阵定义了何时使用 swarm 协调

工件生命周期： .claude/workflows/core/skill-lifecycle.md

• swarm 模式适用于大规模创建工件
• 并行验证多个工件

相关工作流：

• 用于解决 Agent 输出冲突的 consensus-voting 技能
• 用于汇总并行结果的 context-compressor 技能
• .claude/workflows/enterprise/ 中的企业工作流使用 swarm 模式

---

铁律

1. 绝不按顺序派发工作者——所有相互独立的 Agent 必须在同一条消息中派发
2. 始终实现故障检测；绝不让挂起的工作者无限期阻塞蜂群
3. 绝不允许工作者之间互相通信——所有协调都必须通过 Queen 进行
4. 始终使用结构化交接格式编写工作者报告，以便以编程方式汇总
5. 绝不在一次扇出中派发超过 7 个工作者——超过此数量后，协调开销将占主导

反模式

反模式	失败原因	正确做法
按顺序派发	没有并行性；蜂群像队列一样运行	在同一条消息中派发所有相互独立的工作者
工作者之间互相通信	O(N²) 的协调混乱	所有工作者之间的通信都通过 Queen 进行
不处理故障	一个工作者崩溃就会阻塞整个蜂群	检测挂起或失败的工作者，并使用全新状态重新派发
不受限的并行处理	超过 7 个工作者后，协调开销将超过速度提升	每次扇出限制为 5-7 个工作者，以获得最佳吞吐量
自由格式的工作者报告	无法以编程方式汇总结果	要求所有工作者使用结构化交接模板

内存协议（强制）

开始前：

cat .claude/context/memory/learnings.md

完成后：

• 新模式 -> .claude/context/memory/learnings.md
• 发现问题 -> .claude/context/memory/issues.md
• 做出决策 -> .claude/context/memory/decisions.md

假设任务会被中断：你的上下文可能会重置。如果没有记录在内存中，就等于从未发生。