Claude CLI 蜂群模式: 当 AI 学会"带团队"
从单兵作战到多智能体协作, Claude Code 的蜂群模式正在重新定义 AI 辅助开发的边界。
引言
你有没有想过, 让 AI 不只是一个"写代码的助手", 而是一个能拆解任务、分配角色、协调团队的"技术负责人"?
2026 年 2 月, Anthropic 正式发布了 Claude Code 的蜂群模式(Swarm Mode)。这个功能将 Claude Code 从单一 AI 助手升级为多智能体编排系统 -- 你不再是在和一个 AI 对话, 而是在和一个 AI 团队协作。
本文将从技术架构、工作原理、实战案例三个维度, 深入剖析这一特性。
一、从单智能体到蜂群: 演进之路
AI 辅助编程经历了四个阶段:
| 阶段 | 代表产品 | 能力边界 |
|---|---|---|
| 代码补全 | GitHub Copilot | 预测下一行代码 |
| 对话式编程 | ChatGPT | 响应单次请求 |
| 自主智能体 | Claude Code / Cursor | 执行多步骤任务 |
| 蜂群协作 | Claude Code Swarm | 多智能体并行协调 |
单智能体的核心瓶颈在于上下文窗口。当一个 Claude 实例面对大型代码库时, 光是加载足够的上下文来理解架构, 就已经消耗了大部分工作记忆。蜂群模式的解决思路很直接: 分而治之, 各司其职。
二、蜂群模式的核心架构
2.1 角色模型
蜂群模式采用经典的 Leader-Worker 架构:
+------------------+
| Team Lead |
| (规划/协调/综合) |
+--------+---------+
|
+--------------+--------------+
| | |
+--------v---+ +------v-----+ +-----v------+
| Worker A | | Worker B | | Worker C |
| (前端专家) | | (后端专家) | | (测试专家) |
+------------+ +------------+ +------------+
- Team Lead: 不直接写代码, 负责任务拆解、分配、进度跟踪和结果综合
- Worker: 每个 Worker 是一个独立的 Claude 会话, 拥有独立的上下文窗口, 专注于特定任务
2.2 七个核心原语
蜂群模式的协调层由七个工具调用(Tool Call)构成:
+-----------------------------------------------------------+
| TEAM PRIMITIVES |
+-----------------------------------------------------------+
| SETUP | WORK | COMMUNICATE |
| TeamCreate | TaskCreate | SendMessage |
| TeamDelete | TaskUpdate | (agent-to-agent) |
| | TaskList | |
+-----------------------------------------------------------+
| 原语 | 职责 | 说明 |
|---|---|---|
TeamCreate | 创建团队 | 生成团队配置和任务目录 |
TaskCreate | 定义任务 | 每个任务是磁盘上的一个 JSON 文件 |
TaskUpdate | 认领/完成任务 | 通过 status 字段防止重复认领 |
TaskList | 查询任务状态 | 去中心化调度, 每个 Worker 自行轮询 |
Task | 生成 Worker | 通过 team_name 参数将子智能体升级为团队成员 |
SendMessage | 智能体间通信 | 支持直接消息、广播、关闭请求等类型 |
TeamDelete | 清理团队 | 移除所有配置和任务文件 |
2.3 与子智能体(Subagent)的本质区别
子智能体是"发射后不管"的工作者, 蜂群成员是协作者。
子智能体模式 (单向汇报) 蜂群模式 (全向通信)
Main Agent Team Lead
/ | \ / | \
S1 S2 S3 T1 T2 T3
\ | /
S1 看不到 S2 的发现 T1 可以读取 T2 的发现
S2 无法向 S3 求助 T2 可以向 T3 请求协助
Main 负责所有综合工作 Lead 可以委托综合工作
这意味着: 当 API Worker 完成了类型定义, 它可以直接通知 UI Worker, 无需经过 Lead 中转。测试 Worker 可以主动询问 API Worker 是否启动了开发服务器。这种点对点通信大幅减少了协调开销。
三、任务生命周期与调度机制
3.1 任务状态流转
PENDING ──> IN_PROGRESS ──> COMPLETED
| |
| Worker 自行 | Worker 完成
| 认领或 Lead | 任务后更新
| 分配 | 状态
3.2 依赖感知的波次执行
蜂群模式支持任务间的依赖关系, 自动按波次调度:
Wave 1 (无依赖): T1 T2 T3 ── 并行执行
| | |
v v v
Wave 2 (依赖 W1): T4 T5 ── T1/T2/T3 完成后启动
| |
v v
Wave 3 (依赖 W2): T6 ── T4/T5 完成后启动
文件锁机制确保不会有两个 Worker 同时认领同一个任务。
3.3 磁盘上的协调
所有协调状态都持久化在磁盘上:
~/.claude/teams/{team-name}/config.json # 团队配置
~/.claude/tasks/{team-name}/1.json # 任务文件
~/.claude/tasks/{team-name}/2.json
...
任务文件示例:
{
"id": "1",
"subject": "实现俄罗斯方块游戏核心逻辑",
"description": "负责方块生成、旋转、碰撞检测、行消除等核心游戏机制...",
"status": "in_progress",
"owner": "game-developer"
}
四、实战案例: 蜂群开发俄罗斯方块
首先要开启claude的Agent team在用户的.caudle的settings.json 中设置
"env": {
"CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "true"
}
下面是一个真实的蜂群模式运行截图:
用户输入了一条简单的指令:
"帮我写一个俄罗斯方块, 一个设计 UI, 一个策划怎么留住玩家, 一个写代码"
Claude 立即理解了意图, 创建了一个蜂群团队, 分配了三个专业角色:
4.1 团队组成
| 角色 | 职责 | 工具调用 | Token 消耗 |
|---|---|---|---|
| UI 设计师 | 负责设计俄罗斯方块游戏的视觉界面 | 3 tool uses | 18.6k tokens |
| 游戏策划 | 负责设计留存机制和游戏玩法 | 1 tool use | 18.4k tokens |
| 开发工程师 | 负责实现俄罗斯方块游戏代码 | 32 tool uses | 19.0k tokens |
4.2 执行流程
用户: "帮我写一个俄罗斯方块..."
|
v
Lead Agent:
1. TeamCreate("tetris-dev")
2. TaskCreate x 3 (UI/策划/开发)
3. Task(spawn) x 3 (生成三个 Worker)
|
+---> UI 设计师
| - Searching for 1 pattern, reading 2 files
| - 输出视觉设计方案
|
+---> 游戏策划
| - Bash: 确认当前工作目录
| - 输出留存机制设计文档
|
+---> 开发工程师
| - 32 次工具调用
| - Write: tetris.html
| - 实现完整游戏代码
|
v
Lead: 综合三方产出, 交付最终结果
总耗时: 1m 6s | 总 Token: 86,258
三个智能体并行运行, 各自在独立的上下文窗口中工作。UI 设计师参考了现有文件来确定设计风格, 游戏策划独立思考留存策略, 开发工程师则大量调用工具来编写和测试代码。
4.3 成本分析
蜂群模式的 Token 消耗显著高于单智能体:
单智能体完成同样任务: ~30k tokens
蜂群模式 (3 Workers): ~86k tokens (约 2.8x)
但换来的是:
- 执行时间从约 3 分钟压缩到约 1 分钟
- 每个 Worker 的上下文利用率更高(约 40% vs 单智能体的 80-90%)
- 产出质量更高 -- 专业分工带来更深入的思考
五、Git Worktree 隔离
蜂群模式的一个精妙设计: 每个 Worker 在独立的 Git Worktree 中工作。
main branch (Lead)
|
+-- worktree/worker-a (UI 设计师)
+-- worktree/worker-b (游戏策划)
+-- worktree/worker-c (开发工程师)
这意味着多个智能体可以同时修改不同文件, 不会产生冲突。只有当测试通过后, 代码才会合并回主分支。这种隔离机制让并行开发真正安全可靠。
六、最佳实践
6.1 启用蜂群模式
在 .claude/settings.json 中添加:
{
"env": {
"CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1"
}
}
6.2 推荐工作流: 先规划, 再并行
最高效的模式不是直接启动蜂群, 而是两步走:
- Plan 阶段: 使用
/plan模式让 Claude 分析代码库, 产出实施计划。这一步成本低, 只读取文件。 - Execute 阶段: 审核计划后, 让 Claude 以蜂群模式并行执行。计划已经包含了任务拆解, 蜂群只需按图施工。
6.3 成本优化
- Lead 使用 Opus 模型(强推理), Worker 使用 Sonnet 模型(高性价比)
- 简单任务用单智能体, 复杂任务才启用蜂群
- 任务描述越详细, Worker 的执行效率越高, 减少无效 Token 消耗
6.4 适用场景判断
小 Bug 修复? --> 单智能体
需要调研/探索? --> 子智能体
多文件并行开发? --> 子智能体 + Task 系统
Worker 之间需要通信? --> 蜂群模式
七、蜂群模式的局限性
任何技术都有边界, 蜂群模式也不例外:
| 局限 | 说明 |
|---|---|
| Token 成本高 | 每个 Worker 是完整会话, 3 个 Worker 约 2-3x 成本 |
| 实验性质 | 目前仍为 Research Preview, 不建议用于生产流程 |
| 协调开销 | Worker 数量过多时, 通信和调度本身会消耗大量 Token |
| 简单任务不适用 | 对于小型修改, 蜂群模式是"杀鸡用牛刀" |
八、展望
蜂群模式代表了 AI 辅助开发的一个重要方向: 从 AI 助手到 AI 团队。
Gartner 报告显示, 从 2024 Q1 到 2025 Q2, 多智能体系统的咨询量增长了 1445%。预计到 2026 年底, 40% 的企业应用将包含特定任务的 AI 智能体。
当前的蜂群模式还只是起点。未来可以期待的方向包括:
- 跨团队协作: 多个蜂群之间的协调
- 持久化记忆: Worker 在多次会话间保留学习成果
- 自适应专业化: 智能体根据历史表现自动优化角色分配
AI 辅助开发的未来, 不是一个更强大的模型, 而是一群各有所长的智能体。
