Git Worktrees实战：多AI Agent并行开发指南

当你在同一个代码仓库中同时运行多个 AI 编程智能体（Agents）时，大概率遇到过这种令人崩溃的场景：智能体 A 正在修改 src/auth.rs，智能体 B 也不偏不倚地锁定了同一文件。结果呢？一个覆盖了另一个，直到测试崩溃——或者更糟，线上直接宕机——才被人发现。

这个痛点很普遍，但解决方案其实异常简单。关键在于，早在 2015 年 Git 就已经内置了应对手段：那就是 worktrees（工作树）。

Git Worktrees 究竟是什么

一个 Git worktree，通俗讲，就是一个关联着同一代码仓库的独立工作目录。每个 worktree 拥有自己的分支、自己的暂存区，以及磁盘上独立的一套源文件——但所有 worktree 共享同一个 .git

你可以把它看作一种轻量级克隆，但它不会将整个仓库数据复制一遍。

# 主仓库~/project/# 为两个智能体创建两个工作树git worktree add ~/project/.agents/agent-1 -b agent-1/task-authgit worktree add ~/project/.agents/agent-2 -b agent-2/task-tests# 现在你拥有了三个工作目录：~/project/# main~/project/.agents/agent-1/# branch: agent-1/task-auth~/project/.agents/agent-2/# branch: agent-2/task-tests

每个智能体都在自己的工作目录和自己的分支上运作。它们可以同时编辑相同文件而互不干扰——唯一的冲突只会在合并时出现，也就是当某个智能体的分支被合并到主线时。

手动工作树工作流：分步拆解

1. 为每个智能体创建一个 worktree

mkdir -p .agentsgit worktree add .agents/agent-1 -b agent-1/task-refactor-authgit worktree add .agents/agent-2 -b agent-2/task-add-api-testsgit worktree add .agents/agent-3 -b agent-3/task-fix-css-bug

每条命令都会新建一个目录，并在基于当前 HEAD 的新分支上执行一次全新的检出。

2. 将每个智能体指向自己的工作树

在每个智能体自己的目录中启动它：

# Terminal 1cd .agents/agent-1claude-code # 或 codex, aider 等# 分配任务："将 auth 模块重构为 JWT 方式"# Terminal 2cd .agents/agent-2codex# 分配任务："为 REST API 添加集成测试"# Terminal 3cd .agents/agent-3aider# 分配任务："修复仪表盘的 CSS 布局问题"

每个智能体只能看到自己的工作目录。它可以读取任何文件、编辑任何内容、运行任何命令——但对其他智能体毫无影响。

3. 合并前先跑一遍测试

智能体报告任务完成之后，先做一次验证：

cd .agents/agent-1cargo test # 或 npm test, pytest 等echo $?# 0 = 测试通过，可以合并

这一步很多人会跳过，但它恰恰是关键环节。智能体经常在代码刚编译通过、测试还在报红的情况下，就信誓旦旦地说“搞定了”。在采纳它的工作成果之前，务必完整执行一遍测试套件。

4. 合并到主分支

cd ~/project# 回到主工作树git merge agent-1/task-refactor-auth

如果发生冲突（比如 Agent-2 也动了 Agent-1 改过的文件），Git 会清晰地报出冲突位置。一次性干净地解决，而不是让多个 Agent 在并行工作中悄悄地互相覆盖代码。

专业提示：一次只合并一个分支。如果你先合并了 Agent-1，再合并 Agent-2，那么第二次合并时，系统会将 Agent-1 的改动视为主线（main）的一部分。这种串行方式让你能逐步捕获冲突，而不是等到所有冲突堆积成山再处理。

5. 清理战场

git worktree remove .agents/agent-1git branch -d agent-1/task-refactor-auth

或者直接把 worktree 留给下一个任务使用：

cd .agents/agent-1git checkout maingit pullgit checkout -b agent-1/task-next-thing

复用显然更快——毕竟创建一个新的 worktree 需要检出整个工作区，在大仓库里通常要花好几秒。

为什么比单纯用分支强得多

你可能会想：“直接用分支不就行了？”——只说对了一半。分支确实能搞定版本控制，但如果没有独立的 worktrees，所有 Agent 都在共享同一个工作目录。这意味着：

• 不同 Agent 之间会出现 git stash 冲突
• 一个 Agent 未提交的改动，会出现在另一个 Agent 的环境里
• 构建产物和缓存也会陷入一片混乱

而 Worktrees 为每个 Agent 提供了一个物理上彼此隔离的目录。再也不用频繁切换 stash，再也不会被其他 Agent 做到一半的“脏工作区”干扰，共享构建缓存被污染的问题也不复存在。

实践的瓶颈在哪里

用这种方案，我同时并行跑过 3 到 5 个 Agent。超过 5 个以后，代码库本身就成了瓶颈——并发改动太多，干净的合并几乎不可能。最佳的平衡点取决于你的代码库结构：

• 松耦合模块（微服务、独立功能）：5 个以上 Agent 也能稳妥协作。
• 紧耦合代码库（共享状态、大量跨文件依赖）：最多 2 到 3 个 Agent。
• 边界清晰的 Monorepo（大型单体仓库）：取决于任务与模块边界的匹配程度。

自动化：从手动到省心

手动操作这套工作流当然可行，但规模一大就变得极其繁琐。每个 Agent、每个任务你都得重复：创建 Worktree、启动 Agent、检查测试结果、串行合并、清理环境。

Batty 正是为了把这个闭环自动化而生的。它为每个 Agent 创建持久化的 Worktree，从 Markdown 格式的看板中分发任务，在合并前自动跑测试，并通过文件锁来串行化并发合并。更有趣的是，Agent 会在 tmux 窗格中运行，方便你直观地观察它们的干活进度。

cargo install batty-clibatty init --template pair# 1 architect + 1 engineerbatty start --attach

不过话说回来，这种底层模式——即 worktree 隔离、测试把关以及串行合并——适用于任何工作流。即使只是写一个简单的 Shell 脚本来自动创建 Worktree 并在最后执行 git merge，也远比让多个 Agent 在同一个目录下互相死磕要强得多。

快速参考

# 创建 worktreegit worktree add -b # 列出 worktreesgit worktree list# 移除 worktreegit worktree remove # 清理过期的 worktree 引用git worktree prune

核心观点：文件系统层面的隔离，比单纯依赖分支层面的隔离更简单、也更可靠。而 Git worktrees 恰好能让你鱼与熊掌兼得。这个功能从 Git 2.5（2015 年）发布以来就一直很稳定，但大多数开发者却从未碰过它。

如果你正在跑多个 Agent，而且还没试过 worktrees，那么这恐怕是你当下能做出的、唯一一个最具影响力的改变了。