一个人用智能体写代码，最省事的做法是让它一次只干一件事。可等你手上同时压着三四个任务，就会动念头：能不能让几个智能体同时开工？问题马上跟着来——它们挤在同一个工作目录里，改的又是同一批文件，A刚写完的代码被B覆盖掉，冲突排查起来比自己写还累。多智能体卡在第一步，往往不是模型不行，而是没地方站。多智能体卡在第一步，往往不是模型不行，而是没地方站——它们需要的是各自独立的地盘，而不是挤在一张桌子上抢同一支笔。
OpenAI的Codex在0.162版本里给这件事补了一块基础设施：托管的git工作树。你可以直接从受信任的本地项目里创建和列出工作树，每个工作树是一份独立的代码副本，自带自己的分支和状态。智能体各自进去干活，改的是各自的副本，互不踩脚。收工之后再由你来决定合并的顺序。收工之后再由你来决定合并的顺序，什么时候合、按什么顺序合，主动权始终留在人手里，而不是交给工具自己判断。
工作树不是什么新概念，git早就提供了git worktree这套机制。新鲜的地方在于它被做成了产品里的一等公民——不用你自己写脚本去创建、去清理、去挂载分支，工具本身接管了这套流程，还顺手把任务钉在了智能体的命令行面板上，谁在干什么一目了然。基础设施的价值，往往就体现在它不再需要你亲手维护。基础设施的价值，往往就体现在它不再需要你亲手维护。当一套机制从要写脚本变成默认可用，能用上它的人就多了十倍。
为什么这件事值得说？因为它把并行从脚本活儿变成了默认能力。以前你要自己维护一套目录结构，保证每个智能体有自己的地盘、自己的分支，收工还得一个个合并回去。现在这层复杂度被工具吃掉了，你只需要决定一件事：哪几个任务可以真的并行，哪几个必须排队。工具的进步，就是把过去要手工扛的杂活变成默认选项。工具越进步，把过去要手工扛的杂活变成默认选项，你能省下的注意力，就越能集中在真正需要判断的地方。
并行的前提，是各干各的
但并行的账要先算清楚。开源的多智能体编排项目在自己的说明里写得很直白：误差叠加、成本放大、调试变复杂、合并冲突，这些是常态而不是例外。三个智能体同时跑，出错的概率不是相加，而是相乘；到最后你要处理的冲突，可能比自己老老实实写一遍还多。并行是把双刃剑，不是免费的加速器。并行是把双刃剑，不是免费的加速器。加一个智能体，成本和复杂度都在涨，收益却要打过折扣才算数。
所以工作树解决的是物理隔离，不是决策问题。它让智能体不会互相覆盖文件，但不会替你判断哪两个任务本来就该串行。把互不相关的任务拆开并行，收益是实打实的；把有依赖关系的任务硬拆成并行，只是把矛盾推迟到合并那一刻。拆分这件事本身要动脑子，工具替不了。拆分这件事本身要动脑子，工具替不了。哪几个任务真的没有依赖，只有你最清楚，这份判断没法外包。
工作树隔离，解决的是什么
那工作树到底解决了什么？一句话，它解决的是同一份代码被多方同时改写的混乱。代码库是共享资源，两个进程同时改同一个文件，谁先写谁后写决定了最终结果，而这个顺序往往不可控。给每个智能体发一份独立的工作树，等于把共享资源变成各自私有，冲突从运行时挪到了合并时——而合并是可控、可审查、能回滚的。冲突从运行时挪到了合并时——而合并是可控、可审查、能回滚的，这正是隔离最实在的价值所在。
配套的还有一层看不见的收益：上下文。每个智能体在自己的工作树里，看到的是干净的分支状态，不会读到另一个智能体半途改了一半的文件。上下文越干净，模型犯的低级错误越少，这一条在长任务里尤其明显。很多人抱怨智能体越跑越糊涂，根子往往不在模型，而在它读到的文件本来就是乱的。很多人抱怨智能体越跑越糊涂，根子往往不在模型，而在它读到的文件本来就是乱的，喂进去的是一团麻，出来的自然也是。
拿它当默认还早。工具把并行做成了能力，但能力不等于应该。稳妥的顺序是：先把单个智能体的活干明白，再试两个互不相关的任务并行，确认合并这一步不会失控，再往上加。工作树给的是地基，盖几层楼还是你自己定。急着把并发拉到最高，多半会在合并那一步把省下的时间连本带利还回去。急着把并发拉到最高，多半会在合并那一步把省下的时间连本带利还回去，稳妥推进反而是更快的路。
A5创业网 版权所有