最近用ChatGPT、Codex处理多个任务时，我越来越明显地感觉到一个变化：
Agent正在从“一个任务一个任务做”，变成“多个任务同时跑”。
以前我们让Codex处理一个Bug。
任务结束以后，再做下一个。
整个项目状态基本只有一个执行者在修改。
但以后很可能会变成：
Agent A在修登录Bug。
Agent B在升级依赖。
Agent C在补测试。
Agent D在重构支付模块。
甚至这些任务同时发生。
从吞吐上看，这当然很诱人。
一个开发者原本一次只能盯一个任务，现在可以同时推进多个Agent。
但问题也随之出现：
如果这些Agent都在同一个Workspace里工作，会发生什么？
一个Agent刚修改完依赖。
另一个Agent重新跑测试。
第三个Agent还在读取修改前的代码。
第四个Agent准备提交自己的Diff。
这时候真正的问题就不再只是：
Agent会不会写代码。
而是：
多个Agent会不会互相改变对方的工作环境。
所以随着并行Agent越来越多，一个新的基础能力会越来越重要：
Workspace Isolation——工作区隔离
一、单Agent时代，共享Workspace其实没什么问题
假设只有一个Agent。
它读取：
main branch
然后：
修改代码。
安装依赖。
运行测试。
提交结果。
整个过程中，Workspace虽然不断变化，但变化都来自同一个任务。
它知道：
哪些文件是自己改的。
依赖为什么变化。
测试环境为什么变了。
所以状态相对容易理解。
但一旦变成两个Agent同时工作，问题就完全不同。
例如：
Agent A正在修支付接口。
Agent B为了另一个任务升级了HTTP库。
Agent A重新跑测试时突然失败。
这时候它可能会认为：
自己的代码改错了。
但真正原因其实是：
另一个Agent刚刚改了依赖环境。
这就是共享Workspace最麻烦的一点：
状态变化和任务之间开始失去一一对应关系。
二、多个Agent最容易互相影响什么？
第一类当然是：
文件
Agent A正在修改：
payment_service.py
Agent B也因为另一个任务碰到了同一个文件。
两个Agent单独看自己的修改都合理。
但最后合在一起：
可能覆盖。
冲突。
或者改变彼此依赖的逻辑。
第二类是：
分支状态
比如Agent A开始任务时读取的是：
commit abc123
但Agent B中途切了分支、拉了新代码或者做了Merge。
Agent A继续执行时：
它面对的已经不是最开始理解的项目。
这其实就是一种：
Workspace State Drift。
第三类是：
依赖环境
比如一个Agent执行：
npm install
或者：
pip install …
依赖版本变化以后，其他Agent的Build和Test结果也可能一起变化。
这时候：
一个任务的环境操作，开始影响所有任务。
第四类是：
缓存和临时状态
例如：
Build Cache。
测试数据库。
Redis。
临时文件。
生成目录。
环境变量。
如果几个Agent共享这些状态：
即使代码文件完全没有冲突，结果也可能互相污染。
所以所谓Workspace Isolation，真正需要隔离的并不只是：
代码目录。
还包括：
任务运行时依赖的环境状态。
三、为什么Agent越多，共享Workspace的问题会越来越快放大？
假设只有两个Agent。
冲突关系只有一组：
A和B。
但如果有5个Agent并行：
每个Agent都有可能影响其他Agent。
这时候潜在交叉影响会迅速增加。
更麻烦的是：
问题未必马上出现。
比如Agent A改了一个共享配置。
Agent B没有立刻用到。
半小时以后跑测试时才失败。
于是Agent B开始排查：
为什么刚才还正常。
这时候真正的污染源已经离当前错误很远。
所以并行Agent越多：
状态来源越难追踪。
而当状态来源无法追踪以后，Agent就很容易把：
环境冲突
误判成：
业务Bug。
四、真正危险的不是Merge Conflict，而是“没有冲突提示的互相影响”
Git冲突其实反而比较好处理。
因为系统明确告诉你：
CONFLICT
真正难处理的是：
两个Agent修改的文件完全不同。
Git也能正常合并。
但逻辑上却互相影响。
比如：
Agent A修改数据库Schema。
Agent B基于旧Schema写代码。
两边都没有Git冲突。
最后组合以后才发现：
接口假设已经不一致。
所以工作区隔离不能只理解成：
避免两个Agent改同一个文件。
更深一层是：
保证每个Agent看到的项目状态，在任务期间尽量稳定。
五、Worktree为什么会越来越重要？
Git Worktree本质上解决的是：
让多个任务拥有独立代码工作区。
例如：
workspace-agent-a
workspace-agent-b
workspace-agent-c
每个Agent在自己的Worktree里：
读取代码。
修改文件。
跑测试。
查看Diff。
这样Agent A切分支，不会直接影响Agent B。
Agent B修改文件，也不会覆盖Agent C当前Workspace。
这种模式特别适合：
多个Agent同时处理不同任务。
因为：
每个任务开始拥有自己的代码状态。
以后一个很自然的Agent Workflow可能是：
任务创建
→ 自动创建Worktree
→ Agent进入独立Workspace
→ 完成修改和验证
→ 输出Diff
→ 最后统一Merge
相比所有Agent直接挤在同一个目录里：
稳定性会高很多。
六、但只有Worktree还不够
这是很容易忽略的一点。
代码隔离以后：
环境仍然可能共享。
例如多个Worktree还在使用：
同一个数据库。
同一个Redis。
同一个测试端口。
同一份全局依赖。
同一个临时目录。
这时候仍然可能出现：
Agent A清理测试数据。
Agent B正在使用这份数据。
Agent C覆盖了共享缓存。
Agent D启动服务时发现端口已经被占用。
所以更完整的工作区隔离应该继续包括：
Sandbox——沙箱
每个任务拥有相对独立的：
代码。
依赖。
环境变量。
临时文件。
测试数据。
服务端口。
必要时甚至独立容器。
这样Agent才能真正做到：
任务之间互不影响。
七、为什么“环境可复制”也会变得越来越重要？
如果每个Agent都需要独立环境：
那环境必须能够快速创建。
否则每开一个Agent，都要人工：
配置数据库。
安装依赖。
创建环境变量。
准备测试数据。
这样隔离成本会高到失去意义。
所以并行Agent继续增加以后，另一个能力会越来越重要：
Reproducible Environment——可复制环境
比如：
容器。
Dev Container。
固定依赖锁文件。
自动化Fixture。
环境模板。
目标是：
一个新Agent进来以后，可以快速获得：
一个和其他任务隔离、但又足够一致的执行环境。
这时候工作区隔离才能真正规模化。
八、还有一个关键问题：Agent需要知道“哪些状态属于自己”
假设一个Agent进入Workspace以后看到：
5个Modified Files。
它怎么知道：
哪些是自己改的？
哪些是其他任务留下的？
如果没有隔离，它甚至可能把：
别人未完成的修改
一起提交。
所以每个Agent任务最好天然拥有：
独立分支。
独立Worktree。
独立Diff范围。
这样任务边界就会清楚很多。
一个Agent的最终结果应该尽量能够回答：
这些改动属于哪个任务？
从哪个基线开始？
修改了什么？
验证结果是什么？
这也是为什么Workspace Isolation不只是环境问题。
它还直接影响：
任务可追踪性。
九、多个Agent之间什么时候才应该重新汇合？
隔离不是让Agent永远各干各的。
最终代码还是要合在一起。
所以比较合理的Workflow可能是：
任务A → 独立Workspace → 验证
任务B → 独立Workspace → 验证
任务C → 独立Workspace → 验证
↓
Integration
↓
再做统一验证
也就是说：
执行阶段尽量隔离，集成阶段再汇合。
这样问题就会更清楚。
如果单个Workspace里测试失败：
说明任务本身有问题。
如果各自都通过，但合并以后失败：
说明问题集中在：
跨任务集成。
排查范围会比所有Agent从一开始就共用环境小很多。
十、为什么隔离以后仍然必须做最终集成验证？
因为隔离只能解决：
“不要互相污染。”
不能保证：
“多个独立修改组合以后一定正确。”
Agent A升级了依赖。
Agent B修改了某个调用逻辑。
两边在各自Workspace里都通过。
合并以后仍然可能出现：
接口变化。
依赖冲突。
行为不一致。
所以真正成熟的并行Agent Workflow应该是：
Isolate → Validate → Integrate → Validate Again
每个任务先独立验证。
合并以后：
再验证一次整体系统。
这和今天第一篇讲的“独立验证”其实刚好能够接起来。
十一、给自己测一个指标：工作区冲突率
这篇我建议只看一个指标：
Workspace Conflict Rate——工作区冲突率
统计最近一段时间并行执行的Agent任务。
看有多少任务因为共享Workspace或者共享环境出现：
文件覆盖。
分支漂移。
依赖污染。
共享缓存冲突。
测试数据冲突。
端口或临时资源冲突。
最终导致返工。
例如最近50个并行Agent任务里：
有6个因为工作区相互影响而需要重新处理。
那么：
工作区冲突率 = 12%。
这个指标真正反映的是：
你增加的Agent并发，有多少被环境冲突抵消掉了。
十二、这个指标怎么判断？
如果工作区冲突率高于15%：
说明当前不适合继续增加并行Agent数量。
优先解决：
Worktree。
独立分支。
测试数据隔离。
缓存Namespace。
临时目录。
环境变量和端口冲突。
如果在5%—15%：
说明隔离已经有基础。
这时候重点找最常见的共享资源。
通常几个高频污染点解决以后，冲突率会明显下降。
如果长期低于5%：
说明多数Agent任务已经可以在相对独立环境里稳定执行。
这时候增加并发，才更容易真正提高吞吐。
十三、怎么降低工作区冲突率？
先做好四件事就很有效。
第一，每个Agent任务独立Worktree
不要让多个Agent长期共享同一个代码目录。
第二，环境尽量任务级隔离
测试数据库、缓存、临时目录和端口都尽量分开。
第三，任务开始时记录基线
明确：
当前Commit是什么。
分支是什么。
环境版本是什么。
第四，最终统一做Integration Validation
单任务通过不代表组合以后一定通过。
隔离和集成验证缺一不可。
十四、Plus和Pro怎么判断？
如果你的工作区冲突率还比较高：
多个Agent一并行就经常出现：
文件被覆盖。
环境突然变化。
测试互相污染。
Agent读到别人未完成的代码。
那当前真正限制效率的不是ChatGPT、Codex容量。
而是：
并行执行环境还不够稳定。
这个阶段Plus通常已经足够。
先把：
Worktree。
Sandbox。
依赖隔离。
测试数据隔离。
集成验证。
做好，收益往往更大。
否则增加更多AI容量，只会让更多Agent同时进入同一个共享状态里互相影响。
如果你的工作区冲突率已经长期很低：
Agent可以稳定使用独立Workspace。
环境之间基本互不污染。
多个任务完成以后也有统一集成验证。
同时又长期存在：
大量成熟任务排队。
AI并发能力开始真正限制吞吐。
这时候Pro才更容易放大效率。
因为增加的是：
真正能够独立工作的Agent并发。
而不是更多挤在同一个Workspace里的执行者。
最后
ChatGPT、Codex开始同时处理更多任务以后，我们很容易关注：
一次能开几个Agent。
能不能让更多任务并行。
但真正决定并发有没有价值的，不是Agent数量本身。
而是：
它们能不能在不互相改变对方环境的情况下工作。
一个Agent改依赖。
另一个Agent改配置。
第三个Agent跑测试。
如果所有任务共享同一个Workspace：
并发越高，状态越混乱。
所以未来多Agent开发真正需要的，可能不只是：
更多Agent。
而是：
更多彼此隔离、最后又能够安全汇合的Workspace。
当每个Agent都有自己的代码状态、环境和任务边界以后，
并行才真正意味着：
效率增加。
而不是：
冲突增加。
持续分享 Codex、大模型开发与 AI 编程实战内容。
长期深度使用各类代码大模型，也整理了稳定的Plus/Pro会员订阅渠道，有需要可自取。
