让三个 AI Agent 同时开发一个项目：前端改页面、后端写接口、测试补用例。听起来效率翻三倍，实际跑起来第一周就会撞上同一个问题——两个 Agent 同时改 package.json，先写入的修改被后写入的直接覆盖。通信协商能缓解，但文件依赖一复杂就守不住。真正干脆的解法，是给每个 Agent 分一间独立的屋子。
Worktree 是什么来头
先说清楚：Git Worktree 不是 AI 技术，是 Git 多年前就内置的原生功能。普通仓库一个分支对应一个工作目录，切分支前得先收拾未提交的修改。Worktree 打破了这个限制——同一个仓库下开出多个相互独立的工作目录，文件各自独立、版本历史共享、分支各自领先，等于同一份项目开了多个工作台。
对人类开发者这是锦上添花，对 AI Agent 这是刚需。共享目录下的三类事故在多 Agent 场景里天天上演：同时写一个文件互相覆盖、读到对方改到一半的半成品、一个 Agent 动了配置文件导致另一个 Agent 的测试集体变红。隔离目录之后，这些运行期冲突直接消失。
三条命令上手
git worktree add ../frontend-wt feature-frontend
git worktree add ../backend-wt feature-backend
git worktree list
每条 add 命令生成一个新目录，检出指定分支，与主目录共享同一个 .git 仓库。干完活切回主目录正常 git merge 即可。收尾时 git worktree remove <path> 拆目录，如果手动删过目录，用 git worktree prune 清理失效登记。
工具侧的配套已经跟上：Claude Code 启动时加 --worktree 参数就能在独立目录里开会话，目录默认落在项目的 .claude/worktrees/ 下；自定义 SubAgent 的配置里写上 isolation: worktree，子 Agent 执行任务时自动获得独立文件空间，特别适合大规模重构这类动文件很多的活。
那些教程不写的实操坑
第一条坑最经典：fatal: 'xxx' is already checked out at ...。同一个分支不允许在两个 worktree 里同时检出，想并开就先从它切一个新分支。报错信息里那个"already checked out"的位置，就是正在占用该分支的目录路径。
第二条坑是依赖不共享。Worktree 共享的只有版本历史，node_modules 这类依赖目录各归各——每个新 worktree 都得重装一遍依赖。前端项目装一次三五分钟，十个 Agent 并行就是五十分钟的隐性成本。磁盘占用同理，仓库本体共享，工作文件按目录翻倍。
第三条坑是清理时机。Agent 会话结束后，工具的自动清理机制可能连同未提交的修改一起处理掉，拆目录前先确认里面没有来不及提交的成果。
隔离了过程，不等于消除了冲突
Worktree 解决的是工作目录层面的干扰，有三类问题它管不着，提前认清能省很多排查时间。
合并冲突照旧存在：两个 Agent 改了同一段代码，合并时一样要人工裁决。但相比运行过程中的静默覆盖，合并阶段的冲突至少是显式的、可定位的。
语义冲突完全不可见：Agent A 把某函数返回值从字符串改成了整数，Agent B 按字符串接着用——两个改动落在不同文件，Git 合并毫无冲突，程序一跑就报错。这类问题只能靠集成测试兜底。
运行环境不隔离：多个 Agent 起服务抢同一个端口、连同一个数据库，Worktree 管不了，那是 Docker 这类环境隔离的活。
把三层机制摆在一起看更清楚：SubAgent 管上下文隔离，Agent Teams 管协作分工，Worktree 管工作目录隔离。只读的调研任务不需要 Worktree；能划清文件归属的并行开发靠通信协调；文件边界重叠、又要真并行改代码的场景，才是 Worktree 的主场。哪怕只有一个 Agent，让它做高风险重构时套一层 Worktree，搞砸了一弃了之，主分支毫发无伤。
评论0