一个编程智能体接下一个长任务。
写代码，跑测试，回头修错。
干到一半，上下文就满了。
推理也开始原地绕圈。
这半年，前沿的编程智能体换了打法。
主智能体不再一个人干到底。
它在执行的中途临时拉一批子智能体。
谁去查资料，谁去改文件，谁去跑验证。
由它自己决定。
这种机制叫动态并发。
Codex，Claude，Kimi 三家的新版本都已经上了。
听上去是件好事。
麻烦也跟着来。
几个子智能体可能重复调查同一件事。
也可能同时改同一个文件。
还有一种是活干完了没人收，结果堆在一边。
算力花出去了。
任务却没变快。
这笔账怎么算，得有人拿数据说话。
南京大学和 UIUC 的团队做了这件事。
354 个软件工程任务，2124 次执行。
并发和顺序两种模式一对一配对。
主智能体和每个子智能体的轨迹都留了全档。
结论比宣传复杂。
长周期任务里，并发确实有收益。
短周期任务里，它反而把成功率压下去了。
有的组合掉了二十多个百分点。
研究还把失败拆得很细。
4 个大类，13 个子类，28 种具体模式。
另外总结出三种真正管用的协作方式。
图面是一篇论文的首页，标题写着并行子智能体的承诺与坑
论文和实验数据都公开了。
它想回答的不是并发能不能用。
而是这些智能体到底该怎么配合。
早年的多智能体协作不算新鲜。
ChatDev 和 MetaGPT 都试过。
一个负责规划，一个负责实现，另一个负责测试。
流程提前写死，信息怎么传也提前定好。
这套做法叫静态并发。
静态并发在任务结构清楚的时候很稳。
可它要求开工前就想明白怎么拆活。
真实的工程任务往往拆不明白。
大仓库里到处是隐藏依赖。
两个功能看着独立，动手才发现要共用接口。
这套东西已经不是单纯的 AI工具。
而是整套调度逻辑都得跟着改。
所以前沿系统转向了动态并发。
主智能体看着任务状态，临场决定怎么分活。
三家的做法并不一样。
Codex 让主智能体一边干活一边拉子智能体，中间靠消息对齐。
Claude 是现场生成一份工作流脚本，再按阶段往下派。
Kimi 走批处理，一次开一批目标不同的子智能体，整批回来了再收。
图1｜三种编程智能体的并发机制示意，原文论文图 1
三条路都想用多个独立上下文扩大产能。
新麻烦也就跟着来了。
主智能体得判断哪些活能并行，哪些有依赖。
还得判断子智能体的结果拼不拼得回去。
所以评价并发不能数它拉了多少个智能体。
要看这些智能体有没有推进关键任务。
还要看它们的结果能不能汇合。
实验设计得很克制。
三个系统各用自己原生的并发机制。
不套统一的外部框架。
同一个任务里，基础模型和任务要求尽量对齐。
环境和时间预算也保持一致。
长周期基准有四个。
一个考跨语言重建仓库。
一个考照着参考程序重写整套程序。
一个考按自然语言描述生成仓库。
还有一个考需要持续推进、维护依赖的工程过程。
图2｜四个基准的参考实现规模，代码量从两万行到五万行
再加一个短周期的修错任务做对照。
按难度分层抽样，最后取 354 个任务。
每个任务跑并发和顺序两种模式。
2124 次执行，合计约 112 亿 Token。
按标准接口价格折合约两万零七百八十美元。
除了完成率，还记了测试通过率。
耗时和命令行调用次数也一并记下。
四个问题依次回答。
并发到底有没有收益。
智能体怎么组织并行。
为什么会失败。
什么样的协作才有用。
表1｜并发与顺序两种模式的成绩和资源消耗对比
问题一的答案是，有条件。
Claude 在长周期那个基准上，完成率从 7.1% 升到 21.4%。
Codex 从 21.4% 升到 25.0%。
Kimi 的完成率没动，还是 25.0%，但平均测试通过率从 62.5% 升到 66.6%。
另一个仓库生成基准上，Codex 从 34.6% 升到 57.7%。
同一个基准上，Kimi 反而从 57.7% 掉到 46.2%。
同样的任务，不同的并发机制，结果能差这么远。
短周期任务更直接。
Codex 开不开并发都是 71.0%。
Claude 从 83.0% 掉到 59.0%。
Kimi 从 77.0% 掉到 59.0%。
目标明确，改动范围小。
额外的拆分成本和通信开销，把并行的好处吃干净了。
354 个任务合起来看，Codex 多完成 8 个，没到统计显著。
Claude 和 Kimi 分别少完成 42 个和 19 个，下降是显著的。
也有反例。
有一个基准上，Claude 有 4 个任务只在并发模式下做成了。
顺序模式怎么试都过不去。
成本这一项更扎眼。
并发模式的 Token 消耗，是顺序模式的 1.41 到 3.31 倍。
15 组智能体与基准的组合里，14 组开了并发之后平均更慢。
短周期那个基准上，Claude 的平均耗时从 17.5 分钟涨到 27.8 分钟。
完成率还降了。
并发也确实有跑得快的时候。
366 组两边都成功的配对里，102 组并发更快。
其中 46 组至少快了 20%。
所以真正的问题不是并发能不能提速。
是这套系统能不能稳定地把并行换成端到端的收益。
问题二换了个角度。
光看结果不够，得看它们是怎么干的。
团队分析了 1062 条并发轨迹。
图3｜不同难度下子智能体的创建数量与并发峰值
先要分清两件事。
一共创建了多少个子智能体。
和同时活着、时间真正重叠的有多少个。
一个系统可能先后拉了 20 个子智能体。
但它们基本排队执行，那就没形成并行。
另一个系统只拉 5 个，却让它们同时推进不同任务。
三家的调度习惯差别明显。
Codex 维持小群组。
Claude 靠多个阶段持续往外派。
Kimi 一次开一大批。
高难度任务上，这个差别被放大。
Claude 平均创建约 134 个子智能体。
Kimi 平均约 67 个。
但同时存在的峰值，Kimi 反而更高。
图4｜子智能体在归一化执行时间里的活跃情况
啥时候开始派活，也很关键。
Codex 的第一次委派来得早。
首次启动时间的中位数，落在整个执行过程的 4.0%。
Claude 和 Kimi 分别是 22.1% 和 26.0%。
因为 Codex 能让主智能体边干边派。
后两家往往要先组织工作流，或者先凑一批任务。
但派得早不等于并行得充分。
看至少两个子智能体同时在线的时长占比，Codex 的中位数是 23.9%。
Claude 是 52.7%，Kimi 只有 15.6%。
Claude 派得晚，重叠时间却最长。
表2｜并发失败模式的三个层级，4 大类 13 子类 28 种
问题三问的是，失败到底出在哪一环。
团队把 1062 条并发轨迹全部人工标注。
再拿同一任务的顺序轨迹做对照。
经独立标注和分歧复核，最后得出这套三级分类。
这些模式出现在 650 条轨迹里，一共记录了 804 次。
有一点要说清。
出现失败模式，不等于任务最终失败。
有些任务做成了。
过程中照样有重复劳动和文件冲突，还多出额外的集成成本。
第一类是任务编排。
毛病出在拆活和分活这一步。
它包括缺负责人，也包括伪并发和负载不均。
合起来占 28.5%。
伪并发最有代表性。
系统确实开了好几个同时干活的子智能体。
但真正决定成败的那部分工作，还是沿着串行路径在走。
有个例子。
Kimi 在一个程序重建任务里开了 17 个子智能体。
它们分头去查程序的不同行为。
可没人被安排写实现。
主智能体等全部调查回来才开始规划实现。
最后卡在规划阶段，官方测试 0/785。
第二类是执行治理。
子智能体已经在干活，主智能体没管住。
它包括时机错和结果汇合错。
失败后的工作丢失、缺主动监控也算在内。
占 29.0%。
最典型的是一个序列处理工具的重建。
主智能体先写好了基础代码。
把 22 项命令功能分给 20 个子智能体，11 秒内全部启动。
然后它开始等整批完成。
等待时限设成两小时。
而整个任务的执行预算只有 40 分钟。
已有结果没被及时集成，最终只通过 440 项测试里的 92 项。
图5｜一次重建任务里的并发执行与结果回收问题
分工本身没问题，并行也真的发生了。
坏在回收时机。
系统不光要会分活，还得会在对的时间把活收回来。
第三类是全局上下文管理。
信息传过去了，却没被用上。
这部分占 9.3%。
它包含五种情形。
任务要求缺失，接口约定不清，交接负担过重，缺全局验证，重试时也不继承已有进展。
有一个例子很说明问题。
Claude 在一个字符串编码迁移任务里，把大量调查结果汇成一份约 8 万字符的说明。
接到说明的子智能体并没有直接写代码。
它重新做了一遍环境检查和源码分析，还排查了一遍错误。
最后在生成输出文件之前就被打断了。
传得多，不等于用得上。
交接内容里没有清楚的任务状态，也没交代已完成的工作和下一步目标。
新来的智能体还会再走一遍老路。
如果几个子智能体各自实现互相依赖的模块，又没提前约定接口名和数据格式，返回值也没说清。
最后集成一样会崩。
第四类是共享状态与代码集成。
局部都对，合起来打架。
这是占比最大的一类，804 次里占 33.2%。
主要是并发写入冲突和共享环境污染。
主智能体和多个子智能体同时改一个仓库。
它们可能基于不同版本的文件在开发。
每个都在完成自己的任务，改动之间照样冲突。
在一个迁移任务里，主智能体已经写好并构建了部分源文件。
随后一个子智能体在共享输出目录里替换了源码和项目配置。
主智能体只能重新检查当前代码，再协调两边实现的差异。
这个案例最后通过了官方测试。
但它先前掌握的代码状态已经失效，多出一堆集成工作。
共享执行环境也会出同类问题。
两个子智能体各自给测试建临时目录，用了同一个路径。
其中一个重建目录后，另一个的测试数据悄悄变了。
它还在不知情的情况下继续跑。
这些问题和传统并发程序里的数据竞争有点像。
不同的是，冲突不只发生在程序线程之间。
还可能发生在几个自己会写代码的智能体之间。
所以 AI编程 走到并发协作这一步，文件归属和环境隔离都会变成可靠性的一部分。
结果集成也一样。
问题四没有否定并发。
团队挑出 131 组确实有收益的配对轨迹。
条件是至少满足一条。
测试通过率更高。
完成了顺序模式做不到的任务。
或者在不掉通过率的前提下明显更快。
对着两边的完整轨迹，总结出三类有效机制。
第一类是互补工作。
任务能拆成几个相对独立、又能正确拼回去的部分。
一个文本提取任务里，主智能体写核心算法，8 个子智能体分头做交付文件和检查。
两种模式都过了全部测试。
并发把耗时从约 734 秒压到 468 秒。
第二类是并行探索。
让几个智能体同时试同一问题的不同解法，再挑更好的那个。
一个程序重建任务里，主智能体和子智能体各写一版替代实现。
主智能体发现对方在地图行为上更强，自己那版在协议处理上更稳。
它把两边有效的部分合起来，最终过了 391 项测试里的 292 项。
顺序版本压根没构建成功，通过数为 0。
真正值钱的不是多生成几份代码。
是主智能体能不能比出来，选出来，再合回去。
第三类是独立验证。
让另一个智能体专门检查，把错挑出来。
一个安全实验任务里，主智能体负责整体功能，一个密码学方向的子智能体独立复核实现。
它查出椭圆曲线阶数上的一个关键要求。
主智能体据此修正了恢复算法。
并发版本过了全部检查，顺序版本没做完。
这里的子智能体不是在分担写代码。
它提供的是主智能体本来缺的那份证据。
这三类机制来自有收益的案例。
它们不代表在所有任务上都能稳定提升成功率。
但共同点很清楚。
只有多个智能体的工作能被有效利用，并发才会变成系统层面的收益。
回到那个最初的问题。
支持创建子智能体，不等于系统已经会协作。
一个系统哪怕能同时跑很多智能体，也可能拿不到该有的收益。
拆活不合理，关键环节没人负责，结果回收不及时，共享代码还在打架。
想省下这笔算力，别一上来就开并发。
先看任务拆不拆得开。
反过来，任务结构清楚的时候，或者能提供不同候选方案、独立验证能纠错的时候，并发确实有机会改善质量。
所以动态并发的真问题，不是能同时跑多少个。
而是它们怎么才能真正配合起来。
就像你平时用的 AI对话，问一句答一句是最浅的一层。
真让它去干一件长活，难的是调度。
从系统设计看，编程智能体的能力正在从单个模型的推理和生成，扩到多个执行上下文之间的任务组织与协调。
往后它不光要判断一个功能怎么实现。
还要看懂任务之间的依赖，认出哪些活适合并行。
执行途中还得管资源，管信息，管共享状态。
从评测看，只看任务最后成没成，也不够。
还得看主智能体怎么分活，子智能体有没有推进关键工作，几段执行有没有真正重叠，结果能不能及时拼上。
Codex，Claude，Kimi 这一轮把并发做出来了。
离稳定还差得远。
Claude Code会员中转站 微信:douhanq
