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 架构:

scss 复制代码

                    +------------------+
                    |    Team Lead     |
                    |  (规划/协调/综合) |
                    +--------+---------+
                             |
              +--------------+--------------+
              |              |              |
     +--------v---+  +------v-----+  +-----v------+
     | Worker A   |  | Worker B   |  | Worker C   |
     | (前端专家)  |  | (后端专家)  |  | (测试专家)  |
     +------------+  +------------+  +------------+

Team Lead: 不直接写代码, 负责任务拆解、分配、进度跟踪和结果综合
Worker: 每个 Worker 是一个独立的 Claude 会话, 拥有独立的上下文窗口, 专注于特定任务

2.2 七个核心原语

蜂群模式的协调层由七个工具调用(Tool Call)构成:

diff 复制代码

+-----------------------------------------------------------+
|                    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)的本质区别

子智能体是"发射后不管"的工作者, 蜂群成员是协作者。

css 复制代码

子智能体模式 (单向汇报)          蜂群模式 (全向通信)

  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 任务状态流转

yaml 复制代码

PENDING  ──>  IN_PROGRESS  ──>  COMPLETED
  |               |
  |  Worker 自行   |  Worker 完成
  |  认领或 Lead   |  任务后更新
  |  分配          |  状态

3.2 依赖感知的波次执行

蜂群模式支持任务间的依赖关系, 自动按波次调度:

yaml 复制代码

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 磁盘上的协调

所有协调状态都持久化在磁盘上:

ruby 复制代码

~/.claude/teams/{team-name}/config.json    # 团队配置
~/.claude/tasks/{team-name}/1.json         # 任务文件
~/.claude/tasks/{team-name}/2.json
...

任务文件示例:

json 复制代码

{
  "id": "1",
  "subject": "实现俄罗斯方块游戏核心逻辑",
  "description": "负责方块生成、旋转、碰撞检测、行消除等核心游戏机制...",
  "status": "in_progress",
  "owner": "game-developer"
}

四、实战案例: 蜂群开发俄罗斯方块

首先要开启claude的Agent team在用户的.caudle的settings.json 中设置

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 执行流程

sql 复制代码

用户: "帮我写一个俄罗斯方块..."
  |
  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 消耗显著高于单智能体:

java 复制代码

单智能体完成同样任务:  ~30k tokens
蜂群模式 (3 Workers):  ~86k tokens (约 2.8x)

但换来的是:

执行时间从约 3 分钟压缩到约 1 分钟
每个 Worker 的上下文利用率更高(约 40% vs 单智能体的 80-90%)
产出质量更高 -- 专业分工带来更深入的思考

五、Git Worktree 隔离

蜂群模式的一个精妙设计: 每个 Worker 在独立的 Git Worktree 中工作。

scss 复制代码

main branch (Lead)
  |
  +-- worktree/worker-a  (UI 设计师)
  +-- worktree/worker-b  (游戏策划)
  +-- worktree/worker-c  (开发工程师)

这意味着多个智能体可以同时修改不同文件, 不会产生冲突。只有当测试通过后, 代码才会合并回主分支。这种隔离机制让并行开发真正安全可靠。

六、最佳实践

6.1 启用蜂群模式

在 .claude/settings.json 中添加:

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 适用场景判断

lua 复制代码

小 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 辅助开发的未来, 不是一个更强大的模型, 而是一群各有所长的智能体。