本文是AI编程高效开发指南专栏的续篇，预计会更新100多期，每篇不到5毛钱。
这一期我们讲Worktree。
现在用 Claude Code、Codex 这类 Coding Agent 多Agent已经成为常态。
以前是一个需求做完，再做下一个。
现在都是同时开几个任务：
Agent A：修改登录
Agent B：开发支付
Agent C：修复 Bug
Agent D：补测试
Agent E：重构 API
代码生成速度已经足够快，不过新的问题来了。
这几个 Agent 到底在哪里工作？
如果全部放在同一个目录里，很快就会乱。
A 修改了一半，B 切了分支。
C 跑测试改了数据库。
D 执行格式化，又碰了 A 正在改的文件。
于是 Git Worktree 开始变得非常适合 AI Coding。
一个 Repository，可以同时拥有多个独立工作目录。
最直观的用法就是：
project-main
project-login
project-payment
project-bugfix
project-test
一个 Agent 一个目录。
到这里看起来已经解决问题了。
但真正连续使用几天以后，会发现 Worktree 解决的其实只是最表面的一层。
第一个问题：代码隔离以后，环境没有隔离
Worktree 可以保证每个 Agent 拿到自己的代码目录。
但开发一个真实项目，需要的东西远远不止代码。
还有：
.env
node_modules
数据库
Redis
开发端口
Docker
临时目录
测试数据
浏览器 Profile
日志
比如同时启动两个前端项目：
Agent A → localhost:3000
Agent B → localhost:3000
马上端口冲突。
两个 Agent 都操作：
dev.db一样会互相污染。
再比如每创建一个新的 Worktree，都重新：
pnpm install
项目稍微大一点，同时开 5 个目录，安装依赖本身就变成了负担。
所以这里很快会发现一个关键问题：
Git Worktree 解决的是 Workspace，AI Agent 真正需要的是完整的 Runtime。
这两个概念差别很大。
第二个问题：临时创建 Worktree 本身也开始变成成本
很多人的 Worktree 使用方式是：
来一个任务
↓
创建 Worktree
↓
安装环境
↓
开发
↓
提交
↓
删除 Worktree
任务少的时候没问题。
一天启动十几个 Agent 后，创建和销毁环境就开始变成机械劳动。
所以更适合 Agent 的方式，其实是另一种模型：
Worker 1
Worker 2
Worker 3
Worker 4
Worker 5
Worker 6
这些 Worktree 长期存在。
任务来的时候，只负责找到一个空闲 Worker。
例如：
支付需求 → Worker 2
登录 Bug → Worker 4
数据库重构 → Worker 6
任务结束以后，把 Worker 恢复干净。
下一项任务直接继续使用。
这时候 Worktree 已经不太像临时分支目录，它更像一个 Worker Pool。
第三个问题：Agent 数量越多，Merge 越容易失控
假设三个 Agent 同时从 main 开始工作。
A ───────────── 完成
B ─────────────────── 完成
C ───────────────────────── 完成
A 第一个完成，直接合入 main。
B 完成的时候，main 已经变化，需要同步一次。
C 最后完成，此时 main 已经包含 A 和 B 的修改。
于是出现一个非常典型的情况：
第一个完成的人几乎不用处理冲突。
最后完成的人承担所有并行开发产生的冲突。
Agent 越多，这种情况越明显，如果每个 Agent 都拥有如下操作
pull
rebase
merge
push
完整权限，很快会出现多个 Agent 同时修改 Git 历史的情况。
这个时候，真正需要设计的已经不是简单的Worktree的概念和操作了。
而是任务怎么分配、环境怎么隔离、结果怎么回收、谁有权修改主干。
只有掌握这些，Git Worktree 才真正进入 AI Coding 的核心问题。
下面进入我的个人实践和具体实现，可以作为参考。
从这一部分开始，回答五个问题：
1. Worker Pool 到底应该怎么设计
2. .env 和依赖应该怎么共享
