当Coding Agent开始动态并行，软件开发变得更好了吗？

新智元报道 Coding Agent正在进入新的发展阶段。过去，它们主要修复Bug、解决GitHub Issue或实现相对独立的功能，SWE-bench等Benchmark已为此建立了成熟评测范式；如今它们开始承担从完整代码仓库生成、跨语言迁移，到需要持续探索与验证的长周期软件工程项目，任务规模和执行时间不断增长，单个Agent的上下文容量、推理能力和执行效率逐渐成为限制。 一种自然的解决思路是让多个Agent同时工作。近年来，Codex、Claude Code和Kimi Code等前沿Coding Agent开始支持动态并发（Dynamic Concurrency）：主Agent在执行过程中自主决定是否创建子智能体、何时创建，以及如何协调它们的工作。 理论上，这种方式能将复杂任务拆分，让不同Agent并行探索、实现和验证。 但问题也随之而来——多个Agent重复调查同一问题，是否只是增加计算开销？不同Agent同时修改相同文件，最终实现是否仍然可靠？子智能体已完成工作而主Agent没有及时整合，并发又是否真正产生了价值？ 南京大学和UIUC的研究人员对三种前沿Coding Agent进行了大规模配对实验，覆盖354个软件工程任务、2124次执行，并结合完整的主智能体与子智能体执行轨迹进行分析。 研究发现：动态并发在部分长周期任务中能带来明显收益，但并不稳定，在部分短周期任务中甚至会显著降低成功率；轨迹分析进一步归纳出4大类、13个子类别、28种具体并发失败模式，以及并发真正发挥作用的三类典型机制。 研究想回答的不仅是并发是否有效，更关注Coding Agent究竟应该如何协作，才能真正将并行计算转化为软件开发收益。 论文：https://arxiv.org/abs/2610.10263 研究数据与代码：https://github.com/schwerli/Concurrency-Failures-Trajectory-Artifact 从静态工作流到动态并发 多智能体协作并非全新概念。 此前，ChatDev、MetaGPT等系统已探索让多个Agent承担不同角色共同完成软件开发，但通常采用固定协作流程——预先规定由一个Agent规划、另一个实现、还有一个测试，并提前确定信息传递与同步方式。 这种方式被称为静态并发（Static Concurrency），它在任务结构清晰时能提供稳定的执行流程，却要求系统在任务开始前就确定如何拆分和组织工作。 然而，真实的软件工程任务往往具有较强的不确定性：大型代码仓库存在大量隐藏依赖，某些功能看似独立，只有实际探索后才会发现它们需要共享接口、修改相同文件或依赖其他模块的执行结果。 因此，越来越多的Coding Agent从预定义工作流转向动态并发——主Agent根据不断变化的任务状态，自主决定如何委派工作、组织执行和整合结果。 论文研究了三种代表性机制：Codex Multiagent V2在主Agent继续执行的同时动态创建子智能体，并通过消息交换协调；Claude Code Dynamic Workflow动态生成工作流脚本，组织多个具有依赖关系的执行阶段；Kimi Code AgentSwarm批量委派一批不同任务目标的子智能体并行执行，批次完成后返回结果。 图1｜三种Coding Agent的动态并发机制（原论文Fig.1） 三种机制都希望利用多个独立的模型上下文扩大执行能力，但也引入了新的系统性挑战：主Agent不仅需要理解软件开发任务，还需要判断哪些工作可以并行、哪些存在依赖，以及不同子智能体的结果能否正确集成。 因此，评价动态并发不能只看系统创建了多少个Agent，更重要的是这些Agent是否真正推进了关键任务，以及它们的工作结果能否有效汇合。 实验设计 为了系统评估动态并发，研究团队选择了Codex、Claude Code和Kimi Code三种前沿编程智能体，分别比较启用和关闭动态并发时的表现，采用各系统原生支持的并发机制而非统一的外部多智能体框架；对于同一个任务，尽可能保持基础模型、任务要求、执行环境和时间预算一致。 研究主要关注四个长周期软件工程Benchmark：RepoZero涉及代码仓库的跨语言重建，ProgramBench要求根据参考程序和文档重新实现完整程序，NL2Repo关注根据自然语言描述生成代码仓库，LoopsBench则考察需要持续推进、维护任务依赖的软件工程过程。 为了观察任务规模对并发收益的影响，研究还引入SWE-bench Verified作为相对短周期、目标明确的软件修复任务，并按任务难度分层采样，最终选取354个任务。 图2｜不同软件工程Benchmark的参考实现规模（原论文Fig.3） 每个任务由三种Coding Agent分别在并发和顺序模式下执行，共形成2124次执行，整个实验记录了约112亿Token，按标准API价格计算对应约20,780美元的成本。 除最终任务完成率外，研究还记录测试通过率、执行时间、Shell调用次数与Token消耗，并保存主Agent和所有子智能体的完整执行轨迹。 论文围绕四个研究问题展开：动态并发是否带来收益？Agent如何组织并行工作？并发为什么会失败？什么样的协作能够真正发挥并发的价值？ RQ1 动态并发究竟能带来多大的收益？ 第一个研究问题关注动态并发对Coding Agent整体表现的影响。实验结果显示：动态并发并不是一种能够稳定提高任务成功率的通用策略，但在部分长周期任务中展现出了明显潜力。 表1｜ 并发 与顺序执行下的任务效果和资源消耗（原论文Table 2；Conc.为并发，Seq.为顺序） 长周期任务：并发开始展现优势 在LoopsBench上，动态并发带来了较为明显的收益：Claude Code的任务完成率从顺序模式下的7.1%提升至21.4%（提高14.3个百分点），Codex从21.4%提高至25.0%，Kimi Code的完成率保持在25.0%，但平均测试通过率从62.5%提高至66.6%；在NL2Repo上，Codex同样从34.6%提升至57.7%。 然而，这种优势并不稳定：同样在NL2Repo中，Kimi Code的任务完成率反而从57.7%下降至46.2%，不同Coding Agent的并发机制面对相同任务也可能产生截然不同的结果。 短周期任务：更多Agent可能适得其反 与长周期任务不同，在SWE-bench Verified上动态并发没有带来整体优势：Codex启用并发前后的任务完成率均为71.0%，Claude Code从83.0%下降至59.0%，Kimi Code从77.0%下降至59.0%。对于目标相对明确、修改范围较小的软件修复任务，额外的任务拆分、通信和协调成本可能抵消并行带来的潜在收益。 从全部354个任务的整体结果看，Codex在并发模式下多完成了8个任务，但提升未达到统计显著水平；Claude Code和Kimi Code的任务完成数分别减少42个和19个，下降具有显著性。 不过，研究也发现即使整体任务完成率没有提升，并发仍可能帮助系统完成某些顺序模式无法解决的任务——例如在LoopsBench上，Claude