用Git工作树隔离多个编码代理，避免共享状态冲突

第一次尝试在同一个项目上同时运行两个编码代理时，结果和预想的一样糟。它们都在同一个目录里编辑文件，结果就像两个人同时在同一页纸上写字——一半未完成的编辑插进另一半的工作中间，构建结果毫无意义，也分不清哪处改动是谁的。

我的第一反应是让它们协调：加锁、轮流、排队。这个直觉是错的，想清楚错在哪，才是关键。问题不在于缺少协调，而在于共享状态。而对付共享状态最干净的办法，不是去协商访问权，是干脆别共享。

隔离，而不是当裁判

两个进程抢同一批文件，你可以试着当裁判——给共享的东西加把锁，让它们轮流来，定一套谁在什么时候改什么的协议。两个代理时这招管用，到十个就是噩梦。每多一个代理，就多一个谈判方，就多一条让协调本身死锁或饿死的路径。你把一个并行问题变成了分布式系统问题，而分布式系统问题，是周末报废的地方。

隔离把这件事翻了过来。如果每个代理都有自己的工作树副本，就没有什么需要裁判——它们可以全速往前冲，因为谁也看不见、更破坏不了别人正在进行的编辑。并行不再是抢同一页纸，而是一叠各自独立的纸，最后再归拢到一起。十个代理不是十倍的协调量，而是十个独立工作区加一次合并。

并行工作争抢共享状态时，别去造更好的裁判。把共享拿掉。隔离能扩展的地方，协调会崩塌。

Git里那个被低估的功能

Git自带一个正好干这件事的功能，而且被严重低估了。工作树是同一个仓库的第二份（或第三份、第十份）检出，住在自己的目录里，在自己的分支上，但共用同一个底层对象库。你不是把整个仓库克隆十遍、吃掉十倍的磁盘和历史，而是给同一段历史开十扇轻量窗口，每扇窗口可以在不同分支上、带着不同的未提交改动，谁也踩不到谁。

• 给一个代理开独立检出：git worktree add ../work-feature-a feat/thing-a
• 第二个代理，与第一个完全隔离：git worktree add ../work-feature-b feat/thing-b
• 每个目录都是真实工作树，一边的编辑在合并前对另一边不可见

共享对象库在这里悄悄干了两份活。它既是这套设置便宜的原因，也是最后重聚轻而易举的原因：因为每个分支都活在同一段历史里，git本来就能看见它们全部，工作一完成就能把任意两个调和到一起。经济性才是它在规模上可行的关键——立起一个工作树，花的是点磁盘和一点设置时间，恰恰因为昂贵的那部分，也就是仓库历史，是共享的。所以多加一个并行代理的成本接近于零，这正是你在决定把一个任务摊给五个工人、还是自己硬啃时想要的性质。

从origin/main切，别从本地状态切

还有一个更隐蔽的失败，工作树能修掉，而我是被烧过才学会的。同一仓库上同时跑着好几个代理时，主检出几乎从来不是干净状态——里面通常还堆着我一个小时前留下的未提交工作。新代理如果从那儿拉分支，就会继承一堆跟它任务毫无关系的烂摊子，这堆烂摊子还会跟着进它的提交。所以规则不只是"每个代理一个工作树"，而是每个工作树都从origin/main拉分支——一个干净、已知的基线，而不是从本地此刻恰好检出的东西。

哪怕只是改一个字符的文档，我也跑这一行，因为隔离保证的价值永远高于它花掉的那一秒。每个代理都从同一个确定起点出发，而不是从某个时间上的意外出发。这跟把世界安排成"危险的事根本发生不了"、而不是"信任自己会小心"是同一种直觉——安全不是靠警觉挣来的，是靠结构挣来的。从origin/main切出来的工作树，根本不可能继承兄弟代理的半成品编辑，因为它从没见过。

不让这套做法自己变成另一种乱子的纪律是：只在工作真的冲突时才动用隔离。代理并行编辑文件、否则就会冲突时，每个代理一个工作树是对的。代理只是读、或者在做真正互不相干、永不碰同一棵树的事时，这是错的——纯属开销。读密集的扇出不需要隔离，全都可以对着一个检出跑，因为没人在写。

所以我遵循的规则是：隔离写者，读者共享。一群代理审计代码库，可以同时看同一批文件，没什么需要保护的。一群代理各自转换不同文件，就需要人手一个工作树，因为这时有真实状态要防止缠在一起。让隔离程度匹配工作是否发生变更，才能让开销保持诚实，而不是变成仪式。

这对我来说不是假设的模式。这个项目一度同时有大约三十个工作树在跑，每个都是一个以任务命名的目录——og-cards、net-thumbs、home-stats、turnstile、oz-sources——每个都在自己的分支上：feat/per-page-og-ca