很多人第一次接触 Claude Code 的并行开发，都会先被几个词绕晕：subagents、agent teams、worktree、Claude for Teams，看起来都像“团队模式”，但其实不是一回事。
这也是为什么不少人明明已经会让 Claude 写代码了，一到多代理并行就开始翻车：有人抢同一个文件，有人改到一半停住，有人任务做完却没法合并，最后不是效率翻倍，而是把混乱翻倍。
所以这篇文章不准备把重点放在“怎么一键开很多代理”上，而是想先把一个更重要的判断说清楚：
稳定的多子代理并行开发，核心从来不是多开几个 Claude，而是把隔离、分工、验证和回收机制先搭好。
只要这四件事没弄明白，代理越多，现场越乱。
一、先把几个最容易混淆的概念拆开
1. Subagents：单会话里的“分身”
Claude Code 官方把 subagents 定义成一种专门化代理。它们运行在你的主会话体系里，各自有独立上下文窗口，但最终是把结果回传给主会话。官方还内置了 Explore、Plan 之类的子代理，你也可以通过 /agents 自定义。
它更适合这类场景：
- 让我先去搜代码、梳理结构、列计划
- 做一次安全审核&查验、测试补全、证据核查
- 把某个专门问题交给特定角色快速处理
一句话：subagents 更像是“助手团”，不是“独立小队”。
2. Agent teams：官方现在真正接近“团队模式”的东西
如果你听说 Claude Code 有 team 模式，你大概率听到的其实就是官方现在的 Agent teams。
它和 subagents 最大的区别，不是数量，而是结构。
官方文档写得很直白：agent team 由 lead、teammates、shared task list 和 mailbox 组成。也就是说，它不是主会话临时分派几个“打工人”回来汇报，而是多个独立 Claude Code 会话组成一支能互相通信、共享任务列表、自己协调的团队。
这就是为什么官方在对比页里会说：
- subagents 适合“只要结果回传给我”的任务
- agent teams 适合“彼此需要讨论、质疑、协作”的任务
这里非常值得注意：Agent teams 现在是实验性能力，而且默认关闭。 官方要求 Claude Code 版本至少到 v2.1.32，并通过环境变量 CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1 开启。也就是说，它不是“开箱即用的正式默认模式”，而是一个已经很有潜力、但仍处在实验阶段的并行协作机制。
3. Git worktree：真正解决“互相踩文件”的硬手段
很多人一提多代理，就先想着“怎么让它们多说话”。但在真实项目里，最先爆炸的往往不是沟通，而是文件冲突。
Claude Code 官方在 Common workflows 和 IDE Integrations 里都把 Git worktree 当成并行开发的重要基础设施。因为 worktree 的意义非常简单：
让每个 Claude 会话有自己独立的一份代码工作副本和分支。
这件事听起来普通，实际非常关键。没有 worktree，多代理并行开发很容易退化成“同仓库内多人抢同一块地盘”，最后越并行越互相污染。用了 worktree，至少从物理层面先把冲突面压下去了。
这也是我最想强调的一点：稳定并行的第一步，不是 TeamCreate，而是隔离工作副本。
4. Claude for Teams：是账号与管理方案，不是并行开发能力本身
这也是很多新手最容易搞混的地方。
Claude for Teams 是团队订阅和管理方案，解决的是计费、成员管理、组织配置这些问题。它确实更适合团队使用 Claude Code，但它本身不等于“Agent teams”这个并行代理能力。
换句话说：
- Claude for Teams 是组织层面的套餐和管理
- Agent teams 是 Claude Code 里的实验性多代理协作机制
别把这两个词混在一起，不然后面看教程会越看越乱。
二、想跑得稳，先学会选路线，而不是先追求最复杂
我很不建议一上来就把多子代理并行开发理解成“直接开 team 模式”。对新手来说，更稳妥的做法通常是分三档。
第一档：单会话 + subagents
这是最适合入门的一档。
主会话负责推进，遇到需要专门处理的事情，就交给 Explore、Plan 或自定义子代理。它的优点是便宜、可控、心智简单，不容易把现场搞得太散。
如果你的任务是：
- 先调研，再动手
- 先读代码，再改一处
- 先让它做安全审核&查验、测试建议、架构梳理
那这一档通常就够了。
第二档：多会话 + Git worktree
当你开始想同时推进两个以上相对独立的任务，比如一个人改登录流程，一个人补测试，一个人梳理文档，这时最稳的升级方式通常不是直接上 agent teams，而是先用 worktree 跑多会话。
官方明确支持用 claude --worktree 创建隔离工作树，而且子代理也可以配置 isolation: worktree。如果项目里还有 .env 这类 gitignored 文件，官方也给了 .worktreeinclude 机制，避免每次 worktree 一开就缺环境文件。
这套方式的优点是：结构简单，稳定性高，出问题也容易回收。
很多所谓“多代理协作”，其实做到这一步已经足够实用。
第三档：Agent teams
只有当你的任务真的需要“多个代理彼此交流、共享任务列表、互相挑战结论”时，agent teams 才开始体现价值。
官方给出的适用场景很典型：
- 并行代码审核&查验：安全、性能、测试覆盖分头看
- 复杂问题调研：多个假设互相辩论
- 跨层协作：前端、后端、测试各自推进一块
- 新模块开发：不同 teammate 分别拥有不同部分
如果你的任务本质上还是线性的、同文件密集改动的、依赖很多前置步骤的，那 agent teams 往往不是最优解。官方也明确提醒：对顺序任务、同文件修改、依赖关系很重的工作，单会话或 subagents 反而更有效。
三、怎样才能“稳定”地多子代理并行开发
这里我想把“稳定”拆成五件事。只要这五件事没做，所谓并行开发大概率只是看起来热闹。
1. 先做边界隔离，再谈分工
这是第一原则。
谁负责哪个模块、在哪个 worktree 里改、什么情况下才能动公共文件，这些边界一定要先讲清楚。官方文档推荐用 worktree 跑并行任务，本质就是为了先避免文件状态互相干扰。
我的经验是：一个 teammate 最好先有明确的“地盘”再开工。 例如：
- A 只负责
src/auth - B 只负责
tests/auth - C 只做 review 和验证，不直接改业务代码
没有边界的“自由协作”听起来高级，实际最容易把仓库弄成事故现场。
2. 团队别太大，三到四个通常最顺手
官方文档对这一点其实很诚实：没有硬上限，但团队越大，协调成本越高，token 成本也会线性上涨，而且收益会递减。官方甚至专门在成本页提醒，队伍要尽量小，teammate 的 prompt 要尽量聚焦。
这和真实团队管理没什么区别。三四个人的小组，通常比八九个人的松散大会战更容易出结果。
所以新手入门最推荐的，不是“五子登科”，而是：
- 1 个 lead
- 2 到 3 个 teammate
够用了。
3. 先批计划，再放执行
这是第二个特别关键的稳定器。
官方在 agent teams 文档里直接给了“Require plan approval for teammates”的做法：对复杂或高风险任务，可以要求 teammate 先在只读 plan mode 里给方案，lead 审过之后再放它改代码。
这是我认为最值得新手照抄的机制之一。
因为很多并行开发翻车，不是代理不会写，而是它们在没对齐方向前就都开始写。等三个人各自往前冲了一小时，才发现路根本不一样，这时回头成本就很高。
所以真正稳的方式不是：
开三个代理，直接干。
而是：
先让它们各自给计划，再由 lead 按标准放行。
尤其当任务涉及数据库、公共接口、共享 schema 或大范围重构时，这一步几乎必做。
4. 用 hooks 做“硬质量门”，不要只靠代理自觉
这也是稳定性的分水岭。
Claude Code 的 hooks 不是装饰品，而是让团队协作真正工程化的关键。官方文档里专门提到，agent teams 可以配合：
TeammateIdle：teammate 要空闲时做检查，不通过就继续干TaskCreated：创建任务时先过规则TaskCompleted：任务完成时做质量门验证
这意味着你完全可以把一些规则写死：
- 没跑测试，不准标记完成
- 改了公共接口，必须更新文档
- lint 没过，不准收工
- 没有给出风险说明，不准进入 review 阶段
只要规则能自动化，就别只指望 prompt 说服。
5. 结束时一定做回收，而不是放着不管
很多人会认真研究怎么启动，却不重视怎么收尾。其实多代理现场最容易烂掉的，就是回收。
官方文档里反复提到两件事：
- team 用完要 clean up
- worktree 用完要及时清理
而且官方还提醒：清理团队一定要让 lead 来做，不要让 teammate 自己跑 cleanup。因为团队上下文和资源状态都挂在 lead 那边，乱清理容易留下不一致状态。
一句话：并行开发不是只看“怎么开”，更看“怎么收”。
四、给新手的一套最稳起步方案
如果现在就想开始，而且想尽量少踩坑，我会建议按这个顺序来。
第一步：先不用 agent teams，先练 worktree + subagents
先把下面这几件事跑顺：
- 会用
claude --worktree开隔离会话 - 知道什么时候让子代理做调研、计划、审核&查验
- 把
CLAUDE.md写清楚，让所有会话遵守同一套项目规则 - 把团队共享配置放进
.claude/settings.json
这一步的意义，不是保守，而是先把最基本的并行卫生习惯建立起来。
第二步：把项目规则沉淀成共享配置
官方 settings 文档专门把 project scope 描述成“team-shared settings”，适合共享 permissions、hooks、MCP servers。也就是说，如果你真想做稳定的多代理协作，不要每次都在 prompt 里口头交代。
真正该沉淀的东西包括：
- 权限策略
- hooks
- MCP 服务器
- 技能和命令规范
- worktree 相关设置
靠配置共享，比靠记忆共享可靠得多。
第三步：再启用 agent teams
确认 Claude Code 版本满足要求后，再启用：
export CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1
claude --teammate-mode in-process新手第一轮我建议先用 in-process，别急着上 tmux 分屏。因为官方自己都提醒过，split-pane 模式依赖 tmux 或 iTerm2，而且在一些终端里并不支持。先把逻辑跑顺，再去追求“看起来很酷”的显示方式。
第四步：第一次就用最经典的三角分工
不要第一次就搞五六个奇怪角色。最稳的入门分工其实就是：
- Writer / Builder：负责实现
- Reviewer：负责代码审核&查验
- Tester / Verifier：负责测试、验证、边界检查
Claude Code 官方 best practices 里也专门提到 fresh context 对 review 有价值，因为 reviewer 不会天然偏袒自己刚写的代码。这一点很接近真实团队里“自己写自己审”为什么总不稳。
第五步：任务描述一定要写“边界 + 验收标准”
这是我最想额外补的一条。
很多人给代理下任务时，只有目标，没有边界；只有方向，没有验收标准。比如：
把认证模块重构一下。
这种话对单代理都不够，更别说多代理。
真正适合并行开发的任务描述，至少应该有：
- 负责范围
- 不能碰的东西
- 输出形式
- 验收标准
- 依赖关系
例如：
你负责 auth 模块里的 token 刷新逻辑，只修改
src/auth和对应测试，不要改数据库 schema。先给计划，计划必须包含回归测试方案；批准后再实现。完成前必须通过 lint 和 auth 相关测试。
这类描述，才是稳定并行开发真正需要的语言。
五、什么时候不该开 team
这点也必须说。
并不是所有任务都值得拉一个团队。官方文档已经提醒得很清楚：如果任务是顺序性的、同文件密集改动的、依赖关系很重的，单会话或 subagents 往往更有效。
我自己的判断标准更简单：
如果一个任务拆不开“相对独立、可并行、彼此少抢文件”的小块，那就先别开 team。
因为 team 模式真正擅长的是：
- 并行探索
- 并行审核&查验
- 跨角色协同
- 不同假设互相挑战
而不是在一段高度耦合、线性依赖很重的代码里同时硬挤三个人。
六、最后一句最重要
如果只想记住一句话，我希望是这句：
稳定的多子代理并行开发，本质上不是“把 AI 变成团队”，而是“把团队开发里那些本来就该有的约束，提前替 AI 搭好”。
Claude Code 现在确实已经有了更接近“团队模式”的官方能力——Agent teams。但真正让它跑得稳的，不是开关本身，而是你有没有把 worktree、权限、计划审批、hooks、共享规则、任务边界和回收流程配齐。
会开 team，只是入场券。
能让 team 跑得稳，才是真正开始理解多代理并行开发。
评论