最近我在用Codex处理真实项目时，越来越明显地感觉到一个变化：

以前最怕AI干得慢，现在反而开始怕任务开得太多。

比如一个下午，我同时把几个任务交给Agent：

一个修改接口。

一个补测试。

一个排查Bug。

一个整理旧模块。

还有一个顺手做重构。

刚开始会觉得这种工作方式特别爽。

以前只能自己一个任务一个任务往下做，现在几个Agent可以同时跑，理论上同样一个小时，应该完成更多事情。

Codex本身也越来越适合这种多Agent、并行任务的工作方式。OpenAI现在对Codex的定位里，本身就强调了并行Agent和多任务协作。

但真正用一段时间以后，会出现一个很反常的情况：

Agent越开越多，自己的开发效率却不一定继续提高。

五个任务同时跑，并不代表效率就是一个任务的五倍。

有时候同时跑到第四个、第五个任务以后，你甚至会发现：

自己开始变忙了。

不是忙着写代码。

而是忙着：

看哪个Agent做到哪了。

回答不同任务的问题。

确认哪个可以继续。

处理任务之间的依赖。

切换不同项目上下文。

检查Agent有没有改到同一个模块。

判断哪个结果应该先Review。

最后五个Agent都在工作，但你自己却像一个项目调度员一样不停切窗口。

于是一个新的问题出现了：

Agent的并发能力提高以后，开发效率为什么反而可能开始下降？

真正的原因，并不是AI变慢了。

而是开发流程开始从“模型执行瓶颈”，进入另一个阶段：

协调瓶颈。

---

一、最容易出现的错觉：并发数量等于开发效率

传统开发里，一个开发者的并发能力其实非常有限。

你正在认真调一个数据库Bug时，很难同时认真设计另一个权限系统。

所以过去的开发基本是：

任务A
↓
任务B
↓
任务C

一个个处理。

Agent出现以后，这个结构开始变化。

你可以变成：

任务A → Agent 1

任务B → Agent 2

任务C → Agent 3

任务D → Agent 4

从表面看：

以前一次只能推进一个任务。

现在一次能推进四个。

因此很多人的第一反应自然是：

Agent开得越多，效率越高。

但这里隐藏了一个问题。

软件开发不是一个简单的“任务生产系统”。

它还是一个：

信息依赖 + 状态变化 + 人工判断 + 验证决策系统。

Agent可以并行执行任务。

但很多决定依然要回到人。

例如：

这个需求到底应该怎么理解？

两个方案选哪个？

这个依赖能不能升级？

这个测试失败是不是可以忽略？

这个Diff是不是改得太多？

这个权限变化有没有风险？

一个Agent遇到这些问题时，你处理起来不难。

但如果五个Agent几乎同时遇到这些问题，人的注意力就开始成为一个共享资源。

这时候：

Agent是并行的，人仍然是单线程的。

瓶颈就出现了。

---

二、真正的问题不是“同时跑几个”，而是有几个能真正独立推进

举个很简单的例子。

你同时启动5个Agent。

表面上看：

并发数 = 5。

但实际执行过程中：

Agent 1需要你确认接口设计。

Agent 2发现数据库版本不一致，需要你决定是否升级。

Agent 3可以完全独立完成。

Agent 4和Agent 1同时修改同一个公共模块。

Agent 5完成以后，需要你先Review才能继续下一阶段。

看起来五个任务都在运行。

真正能够完全不打扰你、持续独立推进的，可能只有一个。

所以：

名义并发是5，不代表有效并发也是5。

这也是多Agent工作流里很容易被忽视的地方。

真正重要的不是：

我同时开了多少Agent？

而是：

这些Agent里面，有多少能够真正独立向前跑？

---

三、为什么Agent越来越强以后，这个问题反而会更明显？

因为Agent能力增强以后，会同时发生三件事情。

第一，任务持续时间变长

以前给AI的任务可能只是：

“帮我写一个函数。”

几十秒以后结束。

这种情况下根本不存在复杂的调度问题。

但现在越来越多任务会变成：

读取项目。

分析结构。

修改多个文件。

运行测试。

根据失败重新修改。

继续验证。

甚至处理一个完整功能。

一个任务可能持续很久。

任务持续时间越长，就越容易和其他任务重叠。

于是多任务管理开始变成真实问题。

---

第二，任务范围变大

以前Agent主要改变一个局部。

现在可能一次涉及：

Backend。

Database。

Tests。

Config。

API。

Frontend。

当多个Agent同时进入这种范围以后，就更容易产生共享资源冲突。

比如：

Agent A正在改User Schema。

Agent B正在修改依赖User Schema的接口。

两个任务单独看都合理。

但它们实际上不是完全独立的。

这时候你如果仍然把它们当两个平行任务，后面就很容易付出额外的合并和验证成本。

---

第三，人会自然增加任务数量

这一点特别重要。

当Agent完成任务越来越快以后，人自然会想：

既然它可以做，那我再丢几个任务进去。

原来一天只会安排5个开发任务。

现在可能一天启动15个。

结果AI能力提高以后，并没有减少工作负载。

反而扩大了工作负载。

以前很多：

“小问题以后再说。”

现在变成：

“顺便让Agent也处理一下。”

所以AI提速以后，真正变化的不只是任务速度。

而是：

整个开发系统里的任务密度提高了。

任务密度提高以后，并发管理的问题自然越来越明显。

---

四、更深一层：多Agent并不是简单的“多核CPU”

有时候我们很容易把多个Agent想象成：

电脑增加了几个CPU核心。

以前一个核心。

现在五个核心。

所以性能应该提高五倍。

但真实Agent系统并不是这样。

因为软件任务之间不是完全独立的数据块。

它们可能共享：

代码库。

接口。

测试环境。

数据库。

依赖。

分支。

业务状态。

人的判断。

也就是说：

多个Agent之间存在大量共享资源。

这和并行计算里的问题很像。

当所有任务都完全独立时，并行收益最大。

但只要开始出现共享资源，就会产生：

等待。

协调。

锁。

冲突。

同步。

在开发Workflow里，对应的就是：

等人工确认。

等前一个任务完成。

等测试环境。

等依赖更新。

等Review。

解决代码冲突。

同步需求变化。

所以随着并发增加，效率曲线并不是一直直线上升。

更可能是：

开始阶段迅速提高 → 到某个点以后增长变慢 → 再继续增加甚至开始下降。

---

五、最容易被忽略的成本：上下文切换

假设你只有一个任务。

Codex突然问：

“这个接口是继续保持兼容，还是直接改成新格式？”

你脑子里还保持着整个任务上下文。

很快就能回答。

但如果你同时管理6个Agent：

第一个在做登录。

第二个在做数据库。

第三个在修CI。

第四个在改前端。

第五个在写测试。

第六个在做重构。

这时候第六个突然问你一个问题。

你的第一反应可能已经不是回答。

而是：

“这个任务刚才做到哪了？”

你需要重新读取：

需求。

Agent做过的修改。

当前状态。

它为什么问这个问题。

这个过程就是上下文恢复成本。

一次可能只有两三分钟。

但一天发生几十次以后，会非常明显。

更麻烦的是：

上下文切换不仅消耗时间，还会降低判断质量。

当一个人在多个复杂任务之间快速跳转时，更容易出现：

漏看风险。

误判需求。

忘记前一个决定。

Approve不应该Approve的修改。

所以Agent并发超过一定程度以后，增加的不只是时间成本。

还有：

决策错误成本。

---

六、另一个隐藏问题：任务之间会开始互相制造工作

假设两个Agent完全独立。

A修改登录页面。

B优化日志系统。

并行没有问题。

但如果：

A修改API返回结构。

B修改依赖这个API的前端。

这两个任务其实存在依赖关系。

如果同时启动：

A可能先完成一种结构。

B按照旧结构继续修改。

等A完成以后，B的部分工作就要重做。

于是出现一个非常典型的现象：

两个Agent都非常努力，但其中一部分工作实际上是在制造返工。

这时候增加并发没有提高吞吐量。

反而增加了：

返工。

冲突。

重新测试。

重新Review。

所以多Agent最大的误区之一就是：

把“可以同时启动”，理解成“适合同时执行”。

这两个完全不是一回事。

---

七、为什么这个趋势以后还会越来越明显？

因为Agent未来很可能不是少量辅助工具。

而会逐渐成为一种持续存在的开发劳动力。

OpenAI公开介绍的内部使用情况里，重度Codex用户已经会在一天里运行大量并行Agent工作；这说明多Agent调度正在从一种实验性玩法，逐渐变成真实工作模式。

当这个变化继续发展以后，一个开发者未来可能不再只是：

自己写代码。

而更像：

定义任务。

分配任务。

观察状态。

处理异常。

确认结果。

管理优先级。

决定什么时候应该继续，什么时候应该停止。

这时候开发者真正稀缺的资源，可能不再只是：

编码时间。

而是：

注意力和决策带宽。

Agent数量可以快速增加。

但人的注意力并不能同步扩容。

这就是为什么以后真正高效的AI开发Workflow，不一定是：

“同时开最多Agent。”

而更可能是：

“只保持自己能够稳定消化的有效并发。”

---

八、可以自己测一个指标：有效并发率

这篇我只建议观察一个指标。

有效并发率

计算方式非常简单：

能够独立推进、基本不需要你频繁协调的Agent任务数 ÷ 同时启动的Agent任务总数。

例如你同时启动5个任务。

其中：

3个可以自己持续执行。

1个频繁需要人工确认。

1个因为依赖另一个任务而经常等待。

那么：

有效并发率 = 3 ÷ 5 = 60%。

这个指标比单纯看：

“我一天开了多少Agent”

有意义得多。

---

有效并发率低于40%

如果你同时开很多任务，但大量任务都需要：

频繁回答问题。

处理冲突。

重新说明需求。

等待其他任务。

说明你的Workflow实际上还不适合高并发。

这时候继续增加Agent，很可能只是增加调度工作。

---

有效并发率40%—70%

说明已经有一部分任务能够比较稳定地委托出去。

但仍然存在较明显的人工协调。

这个阶段最值得优化的是：

任务边界。

依赖关系。

验收标准。

并发任务选择。

---

有效并发率长期超过70%

如果大量任务都已经能够：

需求明确。

边界清楚。

互不依赖。

自动验证。

完成以后直接进入Review。

那么说明你的多Agent Workflow已经比较成熟。

这个时候增加AI容量，才更容易真正转化成开发吞吐量。

---

九、怎么提高有效并发率？

不是简单少开几个Agent。

而是要改变任务怎么分。

1. 并发之前先检查依赖

启动两个任务以前先问：

它们是不是会改同一个模块？

有没有共同Schema？

有没有共同数据库？

一个任务是不是依赖另一个任务的结果？

如果答案是肯定的，就不要强行并行。

---

2. 优先并行“天然独立”的任务

最适合同时跑的是：

不同模块。

不同项目。

互不影响的Bug。

独立测试补充。

文档。

代码调查。

静态分析。

这种任务之间几乎不需要同步。

并行收益最大。

---

3. 提前写清人工确认点

如果一个任务做到一半一定要问你：

方案A还是方案B？

那最好在启动以前就决定。

否则每个Agent跑到一半都回来找人，会形成大量中断。

---

4. 把验证标准一起交出去

不要只给：

“把这个Bug修掉。”

最好同时写：

修改范围。

不能改变什么。

需要跑哪些测试。

成功标准是什么。

这样Agent能够更长时间独立推进。

---

5. 给并发任务设置优先级

不是所有任务完成后都必须马上看。

可以分成：

需要立即Review。

可以稍后Review。

只需要最终结果。

这样才能避免五个Agent同时完成以后，人瞬间进入新的排队状态。

---

十、Plus和Pro应该怎么判断？

这个主题特别适合用“有效并发率”来判断，而不是单纯看每天用了多少额度。

如果你的有效并发率还比较低：

比如同时开5个任务，真正可以独立跑的只有2个。

其他几个不断需要：

人工确认。

重新解释。

处理冲突。

等待依赖。

那当前真正限制效率的并不是AI容量。

而是：

Workflow还无法稳定消化高并发。

这种阶段，Plus通常已经足够用来继续优化自己的任务拆分和Agent使用方式。

即使直接增加更多AI容量，也很容易出现：

Agent开得更多。

结果自己更忙。

---

如果你的有效并发率已经长期比较高：

大量任务可以独立运行。

项目规则比较清楚。

测试自动化程度高。

任务之间很少互相冲突。

人工只在关键节点介入。

但你仍然持续遇到：

大量任务等待启动。

长任务数量明显增加。

多个稳定Agent都需要连续运行。

AI侧容量开始真正影响任务吞吐。

这时候Pro的价值才会更明显。

因为此时增加AI容量，不再只是增加任务数量。

而是真的能够增加：

有效完成的任务数量。

---

十一、真正值得追求的不是最高并发，而是最高有效吞吐

以后AI编程很可能会进入一个很有意思的阶段。

大家不再比较：

“谁写代码最快？”

而开始比较：

“谁能够稳定管理更多AI工作？”

但这里仍然有一个误区。

真正厉害的并不是：

一个人同时开20个Agent。

而是：

这些Agent产生的工作，最终有多少真正转化成了可以合并、可以发布、可以使用的成果。

如果开20个Agent：

10个互相冲突。

5个需要返工。

3个等你确认。

真正完成2个。

那这个20并没有意义。

反过来，如果只同时运行4个：

任务边界清楚。

互不依赖。

自动验证。

稳定完成。

那4个Agent产生的真实吞吐量，可能反而更高。

所以以后衡量AI开发效率，一个重要变化可能就是：

从：

Agent数量

转向：

有效吞吐量。

---

最后

Agent越来越能自己完成任务以后，人确实获得了一种以前没有的能力：

同时推进多个开发任务。

但这种能力并不是没有上限。

因为Agent可以并行。

项目里的依赖不会消失。

验证不会消失。

上下文不会消失。

人的判断带宽也不会无限增加。

所以未来真正成熟的AI开发Workflow，可能不会追求：

“能开多少Agent就开多少。”

而是会找到一个更合理的平衡：

哪些任务应该并行。

哪些必须串行。

哪些需要人工介入。

哪些可以完全委托。

以及：

自己究竟能够稳定管理多少个真正独立运行的Agent。

当你下一次发现：

同时开的Agent越来越多，

自己却越来越忙，

不要急着认为是AI还不够强。

真正的问题很可能已经变成：

名义并发增加了，但有效并发正在下降。

而这，可能才是Agent时代真正值得管理的新开发瓶颈。

持续分享 Codex、大模型开发与 AI 编程实战内容。
长期深度使用各类代码大模型，也整理了稳定的Plus/Pro会员订阅渠道，有需要可自取。