Coding Agent动态并发：收益不稳，协作才是核心

Coding Agent正进入全新发展阶段。过去，这类智能体主要用于修复代码Bug、解决GitHub提交的问题或实现相对独立的功能，SWE-bench等评测基准已建立了成熟的评估范式；如今，它们开始承担从完整代码仓库生成、跨语言代码迁移，到需要持续探索与验证的长周期软件开发项目，任务规模和执行时间不断增长，单个智能体的上下文容量、推理能力和执行效率逐渐成为瓶颈。

一种自然的应对思路是让多个智能体协同工作。近年来，Codex、Claude Code和Kimi Code等前沿Coding Agent开始支持动态并发模式：主智能体在执行过程中可自主决定是否创建子智能体、何时创建，以及如何协调子智能体的工作。

理论上，这种模式能将复杂任务拆分，让不同智能体并行开展探索、实现和验证工作。但随之而来的问题也值得关注：多个智能体重复调查同一问题，是否只是增加了计算开销？不同智能体同时修改相同文件，最终实现是否仍能保证可靠性？子智能体完成的工作未被主智能体及时整合，并发模式是否真正创造了价值？

来自南京大学与UIUC的研究人员对三种前沿Coding Agent开展了大规模配对实验，覆盖354个软件工程任务、2124次执行，并结合主智能体与子智能体的完整执行轨迹进行分析。

研究发现，动态并发在部分长周期任务中能带来明显收益，但效果并不稳定，在部分短周期任务中甚至会显著降低任务成功率；通过轨迹分析，研究团队归纳出4大类、13个子类别、28种具体的并发失败模式，同时总结出三类能让并发真正发挥作用的典型协作机制。这项研究不仅要回答并发是否有效，更关注Coding Agent如何协作，才能将并行计算真正转化为软件开发的实际收益。

动态并发的收益：并非通用策略，任务依赖性强

第一个研究问题聚焦动态并发对智能体表现的影响。实验结果显示，动态并发并非能稳定提升任务成功率的通用策略，仅在部分长周期任务中展现出潜力。

在长周期任务LoopsBench上，动态并发带来了较为明显的收益：Claude Code的任务完成率从顺序模式的7.1%提升至21.4%，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%，不同智能体的并发机制面对相同任务会产生截然不同的结果。

而在短周期任务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 Code有4个任务仅在并发模式下成功。

除了任务成功率，动态并发还显著增加了计算资源消耗，且不一定缩短执行时间：并发模式的Token消耗是顺序模式的1.41至3.31倍；15组智能体与基准的组合中，14组启用并发后平均运行时间反而增加，比如SWE-bench上Claude Code的平均时间从17.5分钟增至27.8分钟，同时完成率下降。不过也有加速情况：366组两种模式都成功的配对中，102组并发模式更快，46组执行时间缩短至少20%。

智能体的并行组织：数量≠效率，时机与调度更关键

第二个研究问题关注不同智能体如何创建、调度和协调子智能体。研究分析了1062条并发执行轨迹，重点观察子智能体的创建数量、实际并发程度和活动时间。

首先要区分两个概念：累计创建的子智能体数量，与同时存在、执行时间重叠的子智能体数量。仅统计Agent数量无法反映真实并发行为，比如有的系统创建20个子智能体但基本顺序执行，有的创建5个却能同时推进不同任务。

三种智能体的调度方式差异明显：Codex通常维持规模较小的子智能体群组，Claude Code倾向通过多个工作流阶段持续创建子智能体，Kimi Code可一次性启动较大规模的子智能体批次。这种差异在高难度LoopsBench任务中尤为突出：Claude Code平均创建约134个子智能体，Kimi Code约67个，但Kimi Code的子智能体同时存在的平均峰值更高。任务越难，系统通常创建更多子智能体，但这一趋势不适用于所有智能体和基准。

除了创建规模，子智能体的启动时间和重叠时长也很重要。Codex的首次委派通常更早，首次子智能体启动时间中位数在整个执行的4.0%，而Claude Code和Kimi Code分别为22.1%和26.0%——因为Codex可在主智能体执行时直接启动子智能体，后两者需先组织工作流或任务批次。但更早启动不代表更充分的并发：至少两个子智能体同时存在的时间占比，Codex中位数为23.9%，Claude Code为52.7%，Kimi Code为15.6%。

并发失败的原因：协作环节的问题比能力更突出

第三个研究问题聚焦并发失败的根源。研究团队深入分析1062条并发轨迹，结合顺序执行轨迹对照，最终形成4大类、13个子类别、28种具体的失败模式，出现在650条轨迹中，共804次实例。部分任务虽成功完成，但仍存在重复工作、文件冲突等协作问题。

第一类是任务编排问题，涉及工作拆分和分配阶段，包括任务缺少负责人、伪并发（多智能体看似并行但核心工作仍串行）、负载不均衡，占全部失败模式的28.5%。比如Kimi Code执行某程序重建任务时，创建17个子智能体并行调查但未分配实现任务，主智能体等待调查结果后才规划实现，最终任务失败。

第二类是执行治理问题，涉及主智能体对子智能体的管理时机，占比29.0%。当多个子智能体开始工作后，主智能体需监控进度、决定结果接收时机。比如Kimi Code重建某命令行工具时，主智能体将22项功能分配给20个子智能体并行实现，随后等待两小时（任务预算仅40分钟），部分子智能体完成后未及时整合，最终仅通过92项测试。

第三类是全局上下文管理问题，子智能体独立执行导致信息共享不足，占比9.3%，包括任务要求缺失、接口约定不明确、信息交接负担重等。比如Claude Code执行某迁移任务时，子智能体未利用汇总的调查结果，重新开始环境检查和错误调查，最终中断。

第四类是共享状态与代码集成问题，占比33.2%，是占比最大的类别，包括并发写入冲突和共享环境污染。比如Codex执行某迁移任务时，子智能体替换共享目录的文件，导致主智能体的代码状态失效，产生额外集成工作；还有子智能体使用相同临时目录，导致测试数据污染。

有效协作的机制：三类模式让并发创造价值

研究筛选出131组有并发收益的配对轨迹，总结出三类典型有效协作机制。

第一类是互补工作：将任务拆分为多个相对独立且可正确集成的部分，缩短执行时间。比如Kimi Code执行某文本提取任务时，主智能体实现核心算法，8个子智能体负责不同交付文件和检查，并发模式将时间从734秒缩至468秒，保持质量同时提升效率。

第二类是并行探索：多个智能体同时尝试不同方案，整合有效部分。比如Codex执行某程序重建任务时，主智能体和子智能体分别实现不同部分，主智能体结合两者优势，最终通过292项测试，而顺序模式失败。

第三类是独立验证：子智能体提供主智能体缺少的关键信息，修正错误。比如Codex执行某安全实验任务时，密码学子智能体识别出椭圆曲线阶数要求，主智能体修正算法，最终通过全部检查，顺序模式失败。

这三类机制的核心是主智能体能有效整合多个执行结果，将并行工作转化为更好的最终产物。

未来方向：从单智能体到有效协作

随着Coding Agent承担更复杂的任务，多智能体协作成为重要方向，但研究表明，支持创建子智能体不代表具备可靠协作能力。系统可能因任务拆分不合理、关键工作无负责人、结果回收不及时或代码冲突，无法获得预期收益。

动态并发并非没有价值：当任务可拆分、能提供不同方案或可独立验证时，并发可改善质量和效率。因此，核心问题不是“多少智能体并行”，而是“智能体如何有效协作”。

未来的Coding Agent不仅要判断如何实现功能，还要理解任务依赖，识别适合并行的工作，管理资源、信息和共享状态。从评测角度，不仅要观察任务是否完成，还要分析任务分配、子智能体贡献、结果整合等环节。当Coding Agent走向多智能体协作，真正值得追求的是更有效的协作，而非更多智能体。