如何让 AI Coding Agent 使用 Git worktree

把两个 AI Coding Agent 指向同一个检出目录，它们迟早会毁掉一个下午。一个改写另一个正在编辑的文件。一个把另一个脚下的分支切走。两个都对同一份 node_modules 执行 npm install，留下谁也没写过的 lockfile。失败一开始很安静，然后你要在两个 Agent 都解释不了的混乱里二分排查。

Git worktree 是标准修法。worktree 让每个 Agent 在同一个仓库上拥有自己的工作目录和自己检出的分支，并行工作不再互相碰撞。这篇指南说明真实会用到的命令、实际会咬人的问题，以及很少有人提到的清理纪律。然后说明手工 worktree 在哪里停止扩展，以及 HiFox 怎样让每条任务自动使用自己的 worktree，把结果回到同一条共享记录，而不是散落在各个终端里。

如果只跑一个 Agent，现在还不需要这些。一旦跑两个，隔离就不再可选。

先看结论

Git worktree 是挂在同一个仓库上的第二个工作目录，有自己的分支和索引。给每个 AI Coding Agent 自己的 worktree，它们就可以并行编辑、构建和测试，而不会互相覆盖或争夺当前分支。命令很简单。增长的是操作成本：每个 worktree 的安装、清理、磁盘和协调。HiFox 把这个成本接过来，为每条任务自动准备隔离的 worktree，并把每个结果交回任务供人审查。

为什么一个检出目录装不下两个 Agent

普通的 git checkout 正好有一个工作目录、一个索引和一个 HEAD。一个人做一件事时没问题。两个 Agent 同时工作时它会失效，因为这三样都是共享状态。

想象同一个仓库上的两个 Agent。Agent A 正在名为 auth-refactor 的分支上重构认证模块。Agent B 被要求修复日志问题，并执行 git checkout -b fix-logging。这一条命令会移动整个检出目录的 HEAD。Agent A 未提交的改动现在位于错误的分支上，下一次提交会落到错误的地方，构建也会因为要花二十分钟「调试」的原因失败。没有崩溃。状态只是悄悄错了。

文件上更糟。两个 Agent 共享一个工作目录。Agent B 重新生成配置文件或重新运行格式化工具时，会改掉 Agent A 正在使用的文件。

Git worktree 到底是什么

值得记住的定义是：

Git worktree 是连接到同一个仓库的额外工作目录。它有自己检出的分支、索引和 HEAD，并共享一个对象数据库。

最后一句是关键。worktree 不是克隆。克隆会复制整个对象库：每个提交、每个 blob、每个 tag 都复制到第二个 .git。worktree 共享一个对象库，只增加一个轻量的第二个工作目录。提交一旦落下来，每个 worktree 都能看见，因为下面只有一份历史。每个 worktree 不同的是检出：哪个分支被检出、暂存了什么、磁盘上哪些文件是脏的。

对 Agent，这正好对应问题。每个 Agent 得到一个 worktree。每个 worktree 有自己的分支和自己的文件。它们不能互相覆盖，因为它们不写同一个目录。

实际会用到的命令

从一个普通仓库开始。下面的命令都在仓库里面执行。

用新分支创建 worktree。这是最常用的一条：

git worktree add -b fix-logging ../myproject-fix-logging main

它会在 ../myproject-fix-logging 创建目录，从 main 建立新分支 fix-logging，并在那里检出。把 Agent 指向这个目录，它就有一个干净、隔离的工作位置。

为已有分支创建 worktree：

git worktree add ../myproject-auth auth-refactor

列出当前打开的 worktree：

git worktree list

/Users/you/myproject              9f3c1a2 [main]
/Users/you/myproject-fix-logging  9f3c1a2 [fix-logging]
/Users/you/myproject-auth         3b7e0d4 [auth-refactor]

每个 worktree 一行，包含路径、检出的提交和分支。Agent 一多，这张列表就是你的地图。

实际会咬人的问题

每个 worktree 都要自己的依赖安装和环境文件。对象库是共享的，node_modules 和构建缓存不是。

worktree 应该放在主检出目录旁边，不要嵌套在里面。嵌套会干扰遍历目录的工具，也会把忽略规则搞复杂。

删除前先提交或暂存。--force 是你确定时才用的，不是默认动作。定期执行 git worktree prune，并查看 git worktree list，避免留下失效条目。

不要用自己的脚本删除 Runtime 自己的嵌套缓存，例如 ~/.claude/worktrees。让 Runtime 管理它。

脚本在哪里停止扩展

命令可以写进脚本。每个 worktree 的安装、环境、清理、磁盘、谁在哪个目录，以及结果怎样回到同一个人手里，会随着 Agent 数量增长。脚本能创建目录，却不会自然变成一块看得见状态的看板。并行运行多个 Claude Code、用看板代替手工脚本、派发第一条任务，以及 Agent 编排，都是隔离做完之后才出现的问题。

HiFox 怎样让每条任务使用自己的 worktree

HiFox 是 Agent 的指挥和管理平台。它不替代 Claude Code、Codex 或其他 Agent 已经在使用的执行工具。它在周围加上共享的任务、电脑、上下文和审查。worktree 隔离就做在这一层里，所以不用再手工维护。

机制很直接。每条任务得到一个隔离目录。对有仓库的工作，HiFox 根据缓存的仓库数据为每次运行准备新的 worktree，因此多条任务可以针对同一份源代码工作，却从不写入同一个检出目录。你不用执行 git worktree add，也不用自己设计命名、清理任务或映射文件。指派一条任务时，隔离已经在那里。

手工 worktree 和管理层

问题	手工 git worktree	HiFox 管理的 worktree
每个 Agent 的隔离	每次运行自己执行 git worktree add	每条任务自动得到新的 worktree
每个 worktree 的准备	自己写安装和环境脚本	作为任务准备的一部分处理
清理	自己负责，容易忘记	由系统管理，安全清理不会碰受保护的缓存
哪个 Agent 在哪里	自己维护映射文件	显示在任务上，没有旁路文件
结果和 diff	留在各个终端里	回到任务供审查
任务占用和锁	自己写锁	任务从共享计划中认领
磁盘协调	手工	在已连接的电脑之间管理

一个人跑一两个 Agent、希望完全控制时，用手工 worktree。数量和风险上升后，管理层才值得使用。

人与 Agent 的边界仍然成立

隔离改变的是工作发生在哪里，不是谁做决定。worktree 让 Agent 可以并行研究、执行、测试和汇报，而不会碰撞。人仍然定方向、授予权限并接受结果。需要团队判断的地方，自动化就停下来。每个 Agent 一个新的 worktree，让这条边界可以执行：每个 Agent 的工作以自己分支上可审查的变更到来，而不是混进共享检出目录、无法追踪的编辑。你审查的是分支，不是混乱。Agent 编程讲的是日常工作方式，HiFox 是什么讲的是这层管理平台，两者都不是再做一个写代码的工具。