Claude Code 并行开发的三种方式

越是重度依赖 Claude Code，瓶颈就越不是"它能不能写这个"，而是"能同时写几个"。一个后端模块、一个前端 feature、一轮文档梳理，本来就彼此独立 —— 难点只是让它们的文件系统、分支、上下文不要互相踩。

Claude Code 给了三条路走，而且它们并不能互相替代。这篇把三种方式都过一遍，底层到底在做什么，以及我自己取舍时用的那几条规则。

1. claude --worktree —— 多个终端，同一个仓库

最简单、最可预期。每个终端启动一个独立的 Claude session，各自对应一个 git worktree。

# 终端 1
claude --worktree feat-dashboard
 
# 终端 2
claude -w feat-customers   # -w 是短写
 
# 终端 3
claude -w feat-assets

实际发生的事：Claude 在 .claude/worktrees/<name>/ 下创建 worktree，checkout 一个新分支，分支名是 worktree-<name>。Base 是本地 origin/HEAD 指向的那个分支 —— 不是你当前的分支。如果 GitHub 上默认分支变过而本地没同步，你会从一个旧 ref 开分叉。用这条命令重新对齐：

git remote set-head origin -a

把 .claude/worktrees/ 加进 .gitignore，免得主 checkout 里出现一堆 untracked 文件。

复制 gitignore 文件。 新建的 worktree 没有 .env、没有本地配置，因为那些本来就不跟踪。在仓库根目录加一个 .worktreeinclude，用 gitignore 语法列要复制的文件，Claude 每次建 worktree 都会自动拷过去：

.env
.env.local
config/secrets.json

只有"匹配 pattern 且被 gitignore"的文件会被复制，已跟踪的文件绝不会重复。

清理。 会话退出时若没改动，worktree 和分支会自动删除。有 commit 或脏文件时会提示是保留还是丢弃。在会话外手动创建的 worktree 用 git worktree list / git worktree remove 管。

我 80% 的情况都用这个。每个 session 完全隔离，像切换编辑器标签一样在终端间跳，没有任何协调成本。

2. Agent Teams —— 多个 Claude 之间互相对话

Agent Teams 是更新、更激进的模式。一个 session 做 lead，它会 spawn 出 teammate，每个 teammate 有自己独立的 context window，而且彼此之间可以直接发消息，不必都经过 lead。需要 Claude Code v2.1.32 或更高，属于实验性功能，要主动开启 —— 把这段加进 settings.json 或环境变量：

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

然后用自然语言描述这个团队就行：

Create an agent team to build the dealer portal. Spawn three teammates:
- 一个负责 dashboard 后端（apps/dashboard/）
- 一个负责 customers 模块（apps/customers/）
- 一个负责 assets 模块（apps/assets/）
Have them share findings on shared types before touching overlapping files.

显示模式。 两种：

• In-process —— 所有 teammate 都跑在 lead 的同一个终端里。Shift+Down 轮询 teammate；Enter 进入某个 teammate 的会话；Esc 打断它当前这一轮；Ctrl+T 切换共享任务列表。任何终端都能用。
• Split panes —— 每个 teammate 一个独立面板。需要 tmux，或者 iTerm2 + it2 CLI（并在 iTerm2 设置里打开 Python API）。macOS 上推荐组合是在 iTerm2 里 tmux -CC。

默认值是 "auto"：已经在 tmux session 里就用 split panes，否则走 in-process。全局覆写在 ~/.claude.json 里设 teammateMode，单次覆写就 claude --teammate-mode in-process。

共享了什么。 一个带依赖追踪的任务列表（被 block 的任务会在父任务完成后自动解锁），以及一个 mailbox，teammate 可以 message 点对点发给一个同伴，也可以 broadcast 发给所有人。Teammate 和普通 session 一样会加载 CLAUDE.md、MCP、skills 这些项目上下文，但 不会 继承 lead 的对话历史。任务相关的细节得写进 spawn prompt。

已知的坑。 /resume 恢复不了 in-process teammate。任务状态偶尔会滞后（teammate 忘了 mark complete，下游任务就卡住）。一个 lead 一次只能带一个团队，不支持嵌套团队，lead 身份在整个团队生命周期内固定不变。Split-pane 模式在 VS Code 集成终端、Windows Terminal、Ghostty 下不支持。

它真正值回票价的场景是 研究和对抗性 review —— 多个并行的调查员互相证伪对方的假设，比单个 agent 锚定在第一个看起来合理的解释上更快收敛到根因。对那种 teammate 之间真的需要沟通的实现任务，它确实很强；但如果任务本质只是"做这三件事"，worktree 更便宜。

3. 对话内 Subagent

最轻量的一种。在同一个对话里让 Claude 并行 spawn 多个 subagent：

并行开发以下模块：

模块 A —— Dashboard：实现 KPI 统计 API……
模块 B —— Customer profile：GET/PUT /api/customers/profile/……
模块 C —— Assets：tag filtering 和 detail with items……

Claude 会给每个 subagent 分配独立的 context window，结果汇总回主对话。它们彼此之间不通信。想让它们也跑在隔离的 worktree 里？在 subagent 的 frontmatter 里加 isolation: worktree，每个 subagent 会拿到自己的 worktree，如果结束时没有任何改动就自动清理。

Subagent 便宜，因为回到主对话的只有摘要。代价是最脆弱的一种 —— subagent 一旦卡住或跑偏，你能介入的余地远不如 teammate，后者你可以 Shift+Down 直接进去改方向。

真正重要的对比

我自己遵守的规则

适合并行：

• 模块各在自己的目录下（apps/dashboard/、apps/customers/、apps/assets/）。
• 同时碰前后端，且前后端各自独立仓库或 package。
• 并行 code review，每个 reviewer 用不同 lens —— 安全、性能、测试覆盖。

不要并行：

• 多个 agent 会动同一个共享文件（shared/types/、顶层 urls.py、一个单体 schema）。
• 有真实依赖链 —— B 需要 A 的 API shape 先存在。
• 涉及数据库 migration。让一个 session 独占；worktree 共享同一个数据库，两个 agent 同时跑 migration 是你不需要的痛苦。

合并策略，并行分支跑完之后：

1. 先合基础分支（其他分支实际上依赖的那个）。
2. 逐个合并，每次合完跑一遍测试。
3. 冲突手动解，或者回到 Claude Code 里把两个分支都拉进上下文让它做一次 three-way 阅读。

一个具体例子

前段时间重写 dealer portal 的完整流程：

# 终端 1 —— Dashboard 后端
claude -w feat-dashboard
> 在 apps/dashboard/ 下实现 KPI 聚合：recent orders、total revenue、
> pending count。参考 apps/orders/ 里的 repository 模式。
 
# 终端 2 —— Customer 后端
claude -w feat-customers
> 在 apps/customers/ 下实现 sub-user CRUD：list、create、update、delete。
> 用现有的 JWT 中间件鉴权。
 
# 终端 3 —— Assets 后端
claude -w feat-assets
> 在 apps/assets/ 下完善 tag filtering 和 detail-with-items 接口。
> 序列化风格对齐 apps/orders/serializers.py。

三个终端、三个 worktree、三个分支。每个跑完我 review diff、跑测试、按顺序合并。原本要一周顺序做完的活，一个下午搞定。

到底该用哪个？

刚上手：直接用 --worktree。这是你之后也不会抛弃的那个。

当问题真的受益于 teammate 之间对话时 —— 多个假设 PK 的 debug、一次需要安全/性能/测试各过一遍的 PR review —— 再上 Agent Teams。Token 账单是真的，协调开销也是真的，单 session 更快能搞定的任务别拿来用。

对话内 Subagent 适合你想把结果汇总回当前在用的 session，而且能接受中途没法介入它们。

三种底层都是同一个把戏 —— 多个上下文，在同一个仓库上各自隔离工作。区别只在于它们之间需要多少沟通，以及你愿意为那些沟通付多少钱。