Claude CLI 蜂群模式: 当 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---+
|WorkerA| |WorkerB| |WorkerC|
| 前端 | | 后端 | | 测试 |
+-------+ +-------+ +-------+
- 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 依赖感知的波次执行
蜂群模式支持任务间的依赖关系，会自动按波次调度：
Wa ve 1 (无依赖): T1 T2 T3
| | |
+---并行执行--+
|
Wa ve 2 (依赖 W1): T4 T5
| |
+--并行--+
|
Wa ve 3 (依赖 W2): T6
还有个关键细节：文件锁机制确保不会有两个 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，需要在 .claude/settings.json 中设置：
"env": {
"CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "true"
}
下面是一个真实的蜂群模式运行截图。用户只输入了一条简单指令，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 辅助开发的未来，或许不是一个更强大的模型，而是一群各有所长的智能体。
