其他 · 2026年2月8日

Claude Code 蜂群模式实战:Agent Teams 高级玩法

用过 Claude Code 的都知道,单个 Agent 已经够强了。但当项目复杂度上升,一个 Agent 的上下文窗口就成了瓶颈——调研、实现、测试全挤在一起,容易乱。

Agent Teams(官方叫法,国内常说”蜂群模式”)解决的就是这个问题:让多个 Claude 实例协同工作,各司其职。这篇不讲基础,直接上高级玩法。

先搞清楚:Agent Teams vs Subagents

很多人分不清这俩,一张表说明:

特性 Subagents Agent Teams
上下文 独立窗口,结果返回给主 Agent 完全独立,互不干扰
通信方式 只能向主 Agent 汇报 队友之间可以直接对话
协调机制 主 Agent 统一调度 共享任务列表,自协调
适用场景 只需要结果的简单任务 需要讨论和协作的复杂任务
Token 消耗 较低(结果摘要返回) 较高(每个队友独立实例)

选择建议:如果队友之间需要互相挑战、讨论、验证,用 Agent Teams;如果只是分发任务收结果,Subagents 更划算。

启用与配置

Agent Teams 默认关闭,需要手动开启。两种方式:

方式一:环境变量

export CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1

方式二:settings.json(推荐)

{
  "env": {
    "CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1"
  }
}

实战:竞争性假设调查

这是 Agent Teams 最能发挥价值的场景之一。单 Agent 调查 bug 时容易陷入”锚定效应”——找到一个看起来合理的解释就停了。多 Agent 互相质疑能避免这个问题。

Prompt 示例:

用户报告:应用只处理一条消息就断开了,应该保持连接。

创建 5 个 Agent 队友,分别调查不同假设。
让他们互相对话、尝试推翻对方的理论,像科学辩论一样。
把最终共识写入 findings.md。

为什么有效:5 个 Agent 同时探索 5 个方向,而且互相质疑。最后活下来的理论,可信度远高于单 Agent 的结论。

显示模式:in-process vs split panes

两种显示方式,各有适用场景:

模式 特点 适用场景
in-process 所有队友在主终端内,用 Shift+Up/Down 切换 任何终端都能用,无需额外配置
split panes 每个队友独立窗格,一眼看全局 需要 tmux 或 iTerm2,适合长时间监控

强制使用某个模式:

# 命令行参数
claude --teammate-mode in-process

# 或 settings.json
{
  "teammateMode": "in-process"
}

进阶:Delegate Mode

问题:有时候 Lead Agent 会忍不住自己动手实现,而不是等队友。

解决方案:Delegate Mode。开启后,Lead 只能使用协调类工具(spawn、消息、任务管理),不能碰代码。

启用方式:启动 Team 后,按 Shift+Tab 进入 Delegate Mode。

适合场景:希望 Lead 专注于拆分任务、分配工作、综合结果,不亲自写代码。

Plan Approval:给队友加审批环节

对于风险较高的任务,可以要求队友先出计划、等 Lead 批准后再动手:

创建一个 architect 队友来重构认证模块。
要求他先提交计划,批准后才能改代码。

工作流程:

  1. 队友在只读的 plan mode 下调研
  2. 提交计划给 Lead
  3. Lead 审批或打回(带反馈)
  4. 批准后队友退出 plan mode,开始实现

控制审批标准:在 prompt 里写清楚,比如”只批准包含测试覆盖的计划”或”拒绝任何修改数据库 schema 的计划”。

质量门禁:用 Hooks 自动检查

两个关键 Hook:

  • TeammateIdle:队友即将闲置时触发。Exit code 2 可以发送反馈、让队友继续干活
  • TaskCompleted:任务标记完成时触发。Exit code 2 阻止完成、发回修改意见

示例:强制要求测试通过才能完成任务

#!/bin/bash
# hooks/task-completed-check.sh
npm test
if [ $? -ne 0 ]; then
  echo "测试未通过,任务不能标记完成" >&2
  exit 2
fi
exit 0

踩坑指南

1. 文件冲突

两个队友编辑同一个文件 = 互相覆盖。解决方案:任务拆分时确保每个队友负责不同的文件集。

2. Lead 抢活干

Lead 有时会自己开始实现而不是等队友。直接告诉它:

等你的队友完成任务后再继续

3. 任务状态滞后

队友有时忘记标记任务完成,导致依赖任务被阻塞。手动更新状态或让 Lead 去催。

4. 孤儿 tmux session

Team 结束后 tmux 没清理干净:

tmux ls
tmux kill-session -t <session-name>

Token 成本控制

Agent Teams 的 token 消耗是线性增长的——每多一个队友就多一个完整的 Claude 实例。

建议:

  • 研究和 review 类任务:值得用 Teams,并行探索的价值大于成本
  • 日常编码:单 Session 或 Subagents 更划算
  • 模型选择:可以给队友指定用 Sonnet,Lead 用 Opus
创建 4 个队友并行重构这些模块。
每个队友用 Sonnet。

总结

Agent Teams 不是万能药,而是解决特定问题的工具:

  • ✅ 需要多视角并行探索时用它
  • ✅ 需要队友互相挑战验证时用它
  • ❌ 简单顺序任务别用——浪费 token
  • ❌ 同文件编辑别用——会冲突

用好了,是真正的生产力倍增器。

参考资料:
Claude Code 官方文档 – Agent Teams
Claude Code 官方文档 – Subagents