越是重度依赖 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-<name> origin/HEAD 不是你当前的分支 。如果 GitHub 上默认分支变过而本地没同步，你会从一个旧 ref 开分叉。用这条命令重新对齐：
git remote set-head origin -a 把 .claude/worktrees/ .gitignore
复制 gitignore 文件。 新建的 worktree 没有 .env .worktreeinclude
.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 Enter Esc Ctrl+T Split panes —— 每个 teammate 一个独立面板。需要 tmux ，或者 iTerm2 + it2 （并在 iTerm2 设置里打开 Python API）。macOS 上推荐组合是在 iTerm2 里 tmux -CC
默认值是 "auto" ~/.claude.json teammateMode claude --teammate-mode in-process
共享了什么。 一个带依赖追踪的任务列表（被 block 的任务会在父任务完成后自动解锁），以及一个 mailbox，teammate 可以 message broadcast CLAUDE.md 不会 继承 lead 的对话历史。任务相关的细节得写进 spawn prompt。
已知的坑。 /resume
它真正值回票价的场景是 研究和对抗性 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 便宜，因为回到主对话的只有摘要。代价是最脆弱的一种 —— subagent 一旦卡住或跑偏，你能介入的余地远不如 teammate，后者你可以 Shift+Down
真正重要的对比
--worktree Agent Teams 对话内 Subagent 通信 无 —— 完全独立 Teammate 之间 + lead 互发消息 只向主对话汇报 协调 手动（切终端） 共享任务列表、自动依赖解锁 Lead 手动委派 Token 成本 中（独立 session） 高 （每个 teammate 都是完整实例）低（只回摘要） 配置 无 CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1 无 最适合 独立模块、长任务 对抗 review、跨层 feature、假设式 debug 轻量并行小任务 最大风险 忘了哪个终端是哪个 Teammate 悄悄 idle、任务状态滞后 Subagent 卡住没救
我自己遵守的规则
适合并行：
模块各在自己的目录下（apps/dashboard/ apps/customers/ apps/assets/
同时碰前后端，且前后端各自独立仓库或 package。
并行 code review，每个 reviewer 用不同 lens —— 安全、性能、测试覆盖。
不要并行：
多个 agent 会动同一个共享文件（shared/types/ urls.py
有真实依赖链 —— B 需要 A 的 API shape 先存在。
涉及数据库 migration。让一个 session 独占；worktree 共享同一个数据库，两个 agent 同时跑 migration 是你不需要的痛苦。
合并策略 ，并行分支跑完之后：
先合基础分支（其他分支实际上依赖的那个）。
逐个合并，每次合完跑一遍测试。
冲突手动解，或者回到 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，而且能接受中途没法介入它们。
三种底层都是同一个把戏 —— 多个上下文，在同一个仓库上各自隔离工作。区别只在于它们之间需要多少沟通，以及你愿意为那些沟通付多少钱。
