用 Git 工作树隔离并行编程 Agent

两个 AI 编程 Agent 同时改一个项目，最直接的冲突往往发生在提交之前：它们共用同一份工作目录，一个刚写完，另一个就覆盖了。作者做了一个小实验，让两个「Agent」分别在独立目录和分支里修改同名文件 app.txt，主工作目录保持原样。

解决办法是 Git 自带的 git worktree。它让一个仓库同时拥有多个工作目录，每个 Agent 各用一份。值得掌握的不是多开几个文件夹，而是把并行编辑、分支审查和最终合并分开处理。

分支不同，为什么还要把目录分开

只创建两个分支，并不能让同一个工作目录容纳两套正在修改的文件。Agent 如果仍然指向同一个目录，就会读写同一批未提交内容。

git worktree 提供的是多个工作树（working tree）：同一个仓库可以同时检出多个分支，每个分支拥有自己的目录和文件状态。你可以把它理解成，同一份 Git 仓库历史，配上几张独立的工作台。

作者的实验里，两个「Agent」同时编辑各自目录下的 app.txt，彼此没有覆盖，主工作目录也没有变化。原文没有说明具体使用了哪些 Agent 产品，因此它验证的是 Git 的目录隔离行为，不能据此判断某个 AI 工具的并行能力。

每个 Agent 都需要独立的工作目录和分支，才能隔离未提交的文件修改。

四条命令搭好工作区，隔离也有边界

下面这组命令覆盖了创建、查看和清理工作树的基本流程：

git worktree add -b agent-a ../wt-a      # folder + branch for agent A
git worktree add -b agent-b ../wt-b      # folder + branch for agent B
git worktree list                        # see all of them
git worktree remove ../wt-a              # clean up when A's branch is merged

重点看前两行：-b 创建新分支，后面的路径指定独立目录。创建完成后，还要分别把两个 Agent 指向 ../wt-a 和 ../wt-b。最后一行用于分支合并后的工作树清理。

Git 还有一道默认保护：一个分支已经被某个工作树检出时，再尝试为它创建另一个工作树会被拒绝。作者遇到的报错是：

fatal: 'agent-a' is already used by worktree

要注意报错里的 agent-a：这道保护针对的是同一分支被重复检出，并非禁止不同分支修改同一个文件。原文也指出，--force 可以绕过这道默认限制。

多个工作树仍然共用一个仓库。在其中一个目录创建的提交，其他工作树无需推送就能访问，但文件不会因此自动同步。作者建议分别查看每个分支的 diff 或 pull request，逐个审查。

共享仓库还带来另一面：在一个目录误用 git branch -D，影响的是共享的分支记录，不能把各个工作树当成完全独立的仓库。

我的判断

这个办法适合解决一个明确的问题：多个 Agent 并行工作时，不要互相踩到尚未提交的文件。相比完整克隆多份仓库，工作树共享仓库数据，作者据此指出它能节省磁盘空间，但没有给出具体节省量，也没有提供效率对照数据。

它没有解决任务之间的逻辑冲突。

两个 Agent 可以分别改好同一个文件，最终合并时依然可能冲突；即使 Git 能自动合并，组合后的行为也仍需验证。目录隔离负责保护编辑现场，不能替代任务划分、代码审查和测试。

对于只让一个 Agent 顺序工作的场景，普通分支流程就可能够用。需要多个 Agent 真正同时编辑时，工作树的价值才更直接。

能拿来做什么

• 下次并行运行 AI 编程任务前，先为每个 Agent 创建独立分支和工作树，并核对它实际使用的目录。
• 审查时按分支逐个查看 diff 或 pull request，再检查合并后的结果，不把「没有覆盖文件」当成「没有代码冲突」。
• 任务合并后清理对应工作树；执行 git branch -D 等分支操作前，先确认自己正在修改共享仓库的记录。