如果你在同一个代码仓库里同时运行多个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/# 分支：agent-1/task-auth~/project/.agents/agent-2/# 分支：agent-2/task-tests每个智能体都在自己的工作目录和自己的分支上干活。它们可以同时编辑相同的文件而互不干扰——唯一的冲突只会在合并时发生，也就是当某个智能体的分支被合并到主线的时候。
手动工作树工作流：分步拆解
为每个智能体创建一个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的新分支上执行一次全新的检出。
把每个智能体指到自己的工作树
在每个智能体自己的目录里启动它：
# 终端1cd .agents/agent-1claude-code # 或者 codex、aider 等# 给它分配任务：“将 auth 模块重构为 JWT 方式”# 终端2cd .agents/agent-2codex# 给它分配任务：“为 REST API 添加集成测试”# 终端3cd .agents/agent-3aider# 给它分配任务：“修复仪表盘的 CSS 布局问题”每个智能体只能看到自己的工作目录。它能读取任何文件、编辑任何内容、运行任何命令——但对其他智能体完全没有影响。
合并前先跑一遍测试
智能体报告任务完成之后，先验证一下：
cd .agents/agent-1cargo test # 或者 npm test、pytest 等echo $?# 0 = 测试通过，可以合并这一步很多人会跳过去，但恰恰是关键所在。智能体经常在代码刚编译通过、测试还跑着红灯的时候，就信誓旦旦地说“搞定了”。接受它的工作成果之前，务必完整跑一遍测试套件。
合并到主分支
cd ~/project# 回到主工作树git merge agent-1/task-refactor-auth如果发生冲突（比如Agent-2也动了Agent-1改过的文件），Git会明明白白地告诉你。干净利落地一次性解决，而不是让多个Agent在并行工作中悄悄地互相覆盖代码。
专业提示：一次只合并一个分支。如果你先合并了Agent-1，再合并Agent-2，那么第二次合并时，系统会把Agent-1的改动视为主线（main）的一部分。这种串行的方法让你能逐步捕获冲突，而不是等到所有冲突堆成一团时再处理。
清理战场
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个架构师 + 1个工程师batty start --attach不过话说回来，这种底层模式——即worktree隔离、测试把关以及串行合并——适用于任何工作流。即使只是写一个简单的Shell脚本来自动创建Worktree并在最后执行 git merge，也远比让多个Agent在同一个目录下互相死磕要强得多。
快速参考
# 创建worktreegit worktree add -b # 列出所有worktreegit worktree list# 移除worktreegit worktree remove # 清理过期的worktree引用git worktree prune 核心观点：文件系统层面的隔离，比单纯依赖分支层面的隔离更简单、也更可靠。而Git worktrees恰好能让你鱼与熊掌兼得。这个功能从Git 2.5（2015年）发布以来就一直很稳定，但大多数开发者却从未碰过它。
如果你正在跑多个Agent，而且还没试过worktrees，那么这恐怕是你当下能做出的、唯一一个最具影响力的改变了。
