ChatGPT、Codex趋势：为什么AI同时改的任务越来越多以后，真正的瓶颈会变成“可合并性”？

前段时间我看到一个很典型的Codex使用场景。

一个开发者同时开了3个任务：

Agent A修登录Bug。

Agent B重构用户模块。

Agent C升级一组公共依赖。

三个任务分别在自己的Worktree里跑。

结果都很好。

A修完以后，相关测试通过。

B重构完成，自己的测试也正常。

C升级依赖以后，Build同样没有报错。

从单个任务看，三个Agent都可以算“成功”。

但真正准备合回主分支时，问题开始出现。

A的修改仍然依赖旧用户结构。

B已经把用户模块拆成了新的目录和接口。

C升级依赖以后，又让几个公共类型发生了变化。

最后真正花时间的，不再是AI写代码，而是：

Rebase。

重新适配。

重新测试。

重新Review。

甚至重新做一部分已经完成的工作。

这类情况以后很可能越来越常见。

因为当ChatGPT、Codex越来越能同时跑多个任务以后，开发者真正的瓶颈会慢慢从：

“AI能不能同时做更多？”

变成：

“这些任务做完以后，能不能低成本地重新合到一起？”

这就是Multi-Agent时代越来越重要的一个概念：

Mergeability——可合并性

一、表面看是Git冲突，真正的问题其实更深

很多人看到“多个Agent同时改代码”，第一反应会想到：

Git Conflict。

两个Agent改了同一个文件。

同一行代码冲突了。

最后人工解决一下。

但这只是最表面的一层。

真正麻烦的是：

Git没有冲突，系统行为却已经不一致。

比如Agent A修认证逻辑。

Agent B重构用户模块。

两个Agent可能完全没有改同一行代码。

Git可以直接Merge。

但A仍然基于旧的用户对象结构工作，而B已经改了这套结构。

这时候出现的不是文本冲突，而是：

结构冲突。

更深一层，还有语义冲突。

比如Agent A认为：

失败以后应该Retry。

Agent B正在调整错误处理，并认为：

同一场景应该Fail Fast。

两个Agent修改的文件可能完全不同。

Git照样能合。

但系统里已经同时出现两套互相矛盾的行为假设。

所以未来多Agent开发真正危险的，不一定是：

Git告诉你“这里冲突了”。

反而可能是：

Git告诉你“一切正常”，但Agent之间其实已经不在理解同一个系统。

二、表层原因：多个Agent同时工作的基础状态并不一致

为什么这个问题会越来越明显？

因为Agent并行不是简单的“多几个人一起干活”。

本质上是：

多个执行单元同时改变同一个Repository的未来状态。

假设Agent A上午10点从main开始。

10点20分，Agent B修改了公共接口。

10点40分，Agent C升级了依赖。

11点，Agent A才完成自己的任务。

A自己的测试可能全部通过。

问题是：

它验证的是10点时的项目。

而不是11点时的项目。

所以多Agent越多以后，真正需要管理的不只是：

任务数量。

还包括：

不同Agent看到的是不是同一个项目状态。

这也是为什么单个Agent“自己跑通”以后，并不能自动代表：

它可以直接进入主分支。

三、深层工程机制：Local Done不等于Integrated Done

这是这个问题最关键的一层。

过去我们很容易把：

测试通过

理解成：

任务完成。

但Multi-Agent以后，至少要区分两种“完成”。

第一种：

Local Done

Agent自己的Worktree里：

代码写完了。

测试通过了。

任务目标也完成了。

第二种：

Integrated Done

代码真正合回目标分支以后：

Build仍然正常。

Regression仍然通过。

公共接口没有冲突。

共享状态仍然一致。

其他Agent的修改也还能成立。

真正产生工程价值的，是第二种。

但现在很多AI工作流只统计第一种。

于是就会出现一种效率错觉：

一天开了10个Agent。

10个都显示Done。

看起来效率爆炸。

但最后真正能稳定进入主分支的，也许只有6个。

剩下4个需要：

重新修改。

重新验证。

重新适配。

甚至重新实现。

所以未来真正应该看的，不是：

Agent完成了多少任务。

而是：

多少任务最终完成了Integrated Done。

四、为什么AI越强，这个问题反而越严重？

如果AI能力比较弱，一个Agent一次可能只改：

一个函数。

一个文件。

一个局部Bug。

即使多个任务并行，它们之间碰撞的概率也有限。

但AI越强以后，单个Agent的修改范围正在扩大。

它可以一次完成：

跨文件修改。

跨模块修改。

接口调整。

测试调整。

配置变化。

依赖升级。

甚至大规模重构。

这意味着单个Agent的：

Change Surface正在变大。

同时，Agent数量也在增加。

过去可能是：

一个Agent × 小范围修改。

以后越来越可能变成：

多个Agent × 大范围修改。

这两个变量一起增长以后，真正的问题就不再只是执行速度。

而是：

Integration Capacity

系统到底能不能吸收这么多同时发生的变化。

所以AI越能并行，越容易出现一个新的瓶颈：

执行能力已经足够，但整合能力开始跟不上。

这也是为什么未来真正稀缺的能力，可能会从“生成代码”转向：

让多个修改稳定重新组成一个系统。

五、真正最容易出问题的，是公共Contract

很多人会用Worktree、Branch把任务隔离开。

这当然有价值。

它能解决：

不同Agent互相覆盖文件的问题。

但它解决不了：

公共契约变化。

例如：

Agent A修改用户对象结构。

Agent B虽然只改订单模块，但订单模块依赖这个用户对象。

它们甚至没有修改同一个文件。

但已经共享同一个Contract。

再比如：

Agent A修改API返回结构。

Agent B仍然基于旧结构写调用方。

Agent A升级Schema。

Agent B还在使用旧字段。

所以以后判断两个Agent能不能并行，不能只看：

会不会改同一个文件。

还要看：

它们是不是依赖同一个公共Contract。

只要共享：

API。

Schema。

公共类型。

基础依赖。

共享配置。

并行风险就会明显上升。

六、只看一个核心指标：Mergeability Score

以后判断自己适不适合继续增加并行Agent，不需要搞很多复杂指标。

看一个就够：

Mergeability Score——可合并性评分

不用真的打出0到100分。

只要看四件事。

1. 共享区域多不多？

多个Agent是否同时涉及：

公共模块。

共享类型。

数据库。

配置。

核心依赖。

共享越多，Mergeability越低。

2. 公共Contract稳不稳定？

任务执行期间：

API。

Schema。

数据结构。

公共接口。

是否频繁变化？

变化越多，Agent越容易基于旧状态继续工作。

3. 任务能不能独立验证？

一个Agent完成以后，能不能单独证明：

它自己是对的？

如果必须依赖另外两个任务一起完成才能测试，Mergeability就偏低。

4. 合并以后重新验证贵不贵？

Merge回main以后：

只需要跑少量Regression，

还是需要大量重新适配、重新测试？

成本越高，Mergeability越低。

如果这四项大部分表现都不错，就说明：

你适合提高并行度。

如果大部分都很差，继续增加Agent数量通常不会带来等比例收益。

七、真正的解决办法：不是少开Agent，而是先提高Mergeability

第一，公共Contract先稳定，再并行

如果多个任务都依赖：

API。

Schema。

共享类型。

公共接口。

先把这些东西定下来。

最容易出问题的情况，就是：

Agent A正在改接口，

Agent B和C还基于旧接口继续开发。

真正适合并行的时间点，往往是：

公共Contract已经稳定以后。

第二，高耦合任务串行，低耦合任务并行

比如：

独立文档。

不同模块的Bug。

互不相关的测试任务。

这些通常很适合并行。

但：

认证重构 + 登录Feature。

Schema调整 + 数据访问层修改。

公共依赖升级 + 大范围Feature开发。

这种任务共享状态很多，串行反而更容易更快完成。

Multi-Agent真正成熟的用法，不是：

能开几个就开几个。

而是：

只并行那些Mergeability本身就比较高的任务。

第三，任务开始前就明确修改边界

每个Agent最好提前知道：

允许改什么。

不能改什么。

哪些公共模块不要顺手重构。

如果确实必须突破边界，先暂停并说明原因。

这样可以避免一个原本独立的小任务，执行到一半突然开始影响其他Agent。

第四，Merge以后必须重新验证

Agent自己测试通过，只能证明：

它在自己的Worktree里成立。

真正完成还应该再经过：

合回目标Branch。

Build。

Regression。

必要的Integration。

也就是说：

以后Done最好从：

Local Done

升级成：

Integrated Done。

这一步看起来多了一层，但它会明显减少“每个Agent都成功，最后却合不起来”的假效率。

八、Mergeability Score低时，Plus往往已经够用

如果你现在的情况是：

同时跑几个Agent没有问题。

但多个任务经常：

共享模块。

公共接口还在变化。

Merge以后需要大量修改。

经常Rebase。

Review和重新测试占很多时间。

这时候真正的问题并不是：

AI任务跑得不够多。

而是：

Mergeability Score偏低。

这种情况下，更合理的做法通常是：

继续用Plus。

先把：

任务边界。

公共Contract。

并行顺序。

Post-Merge Verification。

这些东西做好。

因为如果三个Agent完成以后，只有一个能顺利合并，那把Agent数量从3个提高到6个，未必能提高真实交付。

可能只是把待整合任务从：

2个

增加到：

5个。

九、Mergeability Score高时，Pro才真正开始有意义

真正更接近Pro的情况是：

公共Contract比较稳定。

高耦合任务不会盲目并行。

Agent之间的Modification Boundary很清楚。

合并前会同步最新Base。

大部分任务Merge以后不需要大规模返工。

也就是说：

Mergeability Score已经比较高。

这时候如果每天仍然存在大量：

低耦合。

高价值。

能独立验证。

能够稳定合并。

的Agent任务持续排队，

那说明真正的瓶颈开始从：

Integration Problem

变成：

Capacity Problem。

这时候更高的执行容量和更高并行度，才更容易直接变成：

更多Integrated Done。

也就是更多真实交付。

最后：不要再只看“Agent完成了多少任务”

AI进入多Agent阶段以后，一个很容易产生的效率错觉是：

今天同时跑了5个任务。

5个都显示Done。

所以效率提高了5倍。

但真实软件工程最后需要的不是：

5个独立成功的Agent。

而是：

一个Repository。

一套统一行为。

一组能通过的测试。

一个真正可以继续部署的系统。

所以未来真正值得看的，不再只是：

Task Count。

而是：

这些Agent做出来的结果，有多少能够低成本地重新合回整个系统？

如果Mergeability低：

更多Agent只会制造更多待整合结果。

如果Mergeability高：

更高并行才真正能够转化成吞吐量。

所以Multi-Agent时代真正的分水岭，很可能不是：

谁能同时开更多Agent。

而是：

谁能让更多Agent的结果稳定进入Integrated Done。

这才是“可合并性”真正成为新瓶颈的原因。

持续更新Codex、大模型开发相关技术内容。
长期使用各类代码大模型，整理了稳定的Plus/Pro会员订阅渠道，有需要可自取！