当子智能体并行工作时：长时程编码任务中动态并发的机遇与陷阱

前沿编程智能体在执行中动态派生并协调子智能体，但其在长程编程任务上的效果、效率与失败特征仍不清楚。

• 场景：作者认为长程软件开发包含长时间的代码探索、实现、测试与验证，单个智能体在上下文、推理和执行上有实质限制。作者把多智能体分解视为扩大执行容量、并行探索和降低端到端延迟的一条路径。
• 静态并发的限制：TRAE、OpenHands等较早系统依赖预定义工作流，子智能体的数量、角色、分工和同步点事先指定。作者认为这种刚性难以适应执行展开后才显现的分解、依赖和并行机会。
• 评测缺口：作者称已有工作多研究单智能体，或研究预定义协议的多智能体，且评测多面向预期输出为较小补丁的有界任务，例如仅数十行。动态并发针对仓库级生成和软件发布；作者称参考实现或gold-change在不同难度组为0.8–54.4千行。
• 本文工作：作者比较Codex multiagent Version2、Claude Code Dynamic Workflow和Kimi Code AgentSwarm在并发开与关下的执行。作者称这是对原生动态并发的首次系统研究，覆盖354个任务、2124次执行，并分析失败模式与收益条件。

论文第2节把相关工作分成预定义协作和编程智能体实证；实验对照是同一智能体的顺序模式。

预定义协作

• 角色与工作流：ChatDev（Qian et al., 2024）和MetaGPT（Hong et al., 2024）用专门角色和开发流程组织协作。引言还把TRAE、OpenHands作为依赖预定义工作流的较早编程智能体。
• 任务图与讨论：CodeR（Chen et al., 2024）用预定义任务图协调issue解决。Multiagent Debate（Du et al., 2024）和SWE-Debate（Li et al., 2026）用重复讨论轮次，Mixture-of-Agents（Wang et al., 2025）用分层聚合。
• 作者的区分：作者认为静态范式按事先固定的工作流编排子智能体；动态并发则由主智能体在执行中决定是否派生、委派什么、如何汇合。论文对上述系统只作这类对照，没有给出与它们的数值比较。

失败与轨迹分析

• 交互与成本：论文引用的一组研究分析协调架构和辩论设置如何影响准确率、成本与延迟。正文未给出这些研究的具体数字。
• 失败模式：TRAJEVAL代表对编程智能体错误和成败轨迹的分析。MAST与AgentFail考察智能体间错位、信息丢失和失败传播。TrajAudit与CodeTracer代表轨迹自动诊断；论文还并列引用失败归因和基于反馈的恢复工作。
• 作者的定位：作者称既有评测多针对单智能体或预定义协作，且多测有界任务；这项研究改看前沿编程智能体的动态并发，并在长程任务上同时评估效果、效率和失败模式。

实验基线与基准

• 基线方法：同一骨干模型、提示词、环境和时间预算下，关闭动态并发的顺序模式。作者称该模式不会创建子智能体。
• 基准：RepoZero、ProgramBench、NL2Repo、LoopsBench，以及有界对照SWE-bench Verified。

作者在三款前沿编程智能体上开关原生动态并发，对照同一任务的并发与顺序轨迹，再从轨迹归纳失败模式和收益条件。

智能体与开关

• 配对：2026年7月的配置是Codex配GPT-5.4、Claude Code配Claude Opus 5、Kimi Code配Kimi K3。作者认为后训练强化学习可能使模型适应脚手架的工具接口，替换模型可能破坏兼容性，因此不换骨干模型。三者用原生脚手架，并请求最高推理力度。
• 三种机制：Claude Code由主智能体生成工作流脚本，安排并行阶段、显式依赖和汇合，用ultracode启动Dynamic Workflow；顺序模式关闭Workflow、Task和Agent工具。Kimi Code用AgentSwarm按共享模板一次发出一批子智能体，主智能体等待后收到有序报告，开关为swarm_mode=true或false。Codex支持直接和嵌套委派，主智能体可继续执行并交换消息；并发打开multi_agent和multi_agent_v2，顺序模式关闭这两项。
• 关闭的含义：作者称关闭动态并发后不会创建子智能体。两种模式共用骨干模型、提示词、环境和时间预算。方法节未给出适用于全部任务的统一时间上限。

任务与抽样

• 基准：RepoZero含Py2JS（用JavaScript重建Python包）和C2Rust（用Rust重建C接口）；ProgramBench按参考可执行文件和文档重建命令行程序；NL2Repo从自然语言规格和空工作区建仓库；LoopsBench是相互依赖的持续开发；SWE-bench Verified在已有仓库中解决单个issue，用作有界对照。
• 抽样：长程基准按原难度组分层随机抽25%，SWE-bench Verified抽20%。作者给出的费用例子是整份LoopsBench跑一次可花11,354美元。
• 规模：Table 1样本为Py2JS 100、C2Rust 50、NL2Repo 26、ProgramBench 50、LoopsBench 28、SWE-bench Verified 100，合计354个任务、2124个执行单元。记录token对应20,780.02美元；正文另写11.2 billion recorded tokens。作者称长程基准不同难度组的参考实现或gold-change为0.8–54.4千行，并把Figure 3的26.8K行对应到LoopsBench。

过程度量

• 委派：每个子智能体上下文在一次执行中计一次。时间窗相交算重叠。创建数可因多轮委派高于同时存在的峰值。
• 重叠比例：轨迹按主智能体或任一子智能体的首末时间戳归一化。该比例是至少两个子智能体同时活跃的时间占比，不含主智能体；没有这种重叠则记0。
• 判定：官方Task pass是完全解决的任务比例，Test pass是每任务通过测试比例的均值，由官方测试器给出。Figure 4另把ProgramBench的成功定义为test pass大于0，因为两种模式都没有完全解决的样本任务；其他基准仍用完全解决。

标注与收益筛选

• 码本：两名标注者先开放编码50条轨迹，形成主类、子类、具体模式三级。功能失败指所有权、信息交换、隔离、可观测性或验收被违反；性能失败指在既有预算下协调无效。
• 正式标注：三名标注者中，每条由两人独立标注，可多选。不一致先讨论，未决由资深作者裁定。对象是全部1062条并发轨迹，并对照同智能体、同任务的顺序轨迹、产物和官方测试。
• 收益对：纳入条件是并发Test pass更高，或并发完全解决了顺序模式未解决的任务，或在不降低Test pass时完成时间至少减少60秒且至少减少20%。

实验设置

• 被测配置：Codex配GPT-5.4，Claude Code配Claude Opus 5，Kimi Code配Kimi K3。配置选自2026年7月，原生脚手架，最高推理力度。结果按智能体报告，每个智能体只配一个骨干模型。
• 任务：354个。SWE-bench Verified 100（易39、中52、难9，总体500）；Py2JS 100（33/32/35，总体400）；C2Rust 50（15/18/17，总体200）；NL2Repo 26（6/12/8，总体104）；ProgramBench 50（7/36/7，总体200）；LoopsBench 28（4/11/13，总体112）。Table 1。
• 模式：每任务、每智能体各跑并发与顺序一次，共2124个执行单元。两种模式共用模型、提示词、环境和时间预算；顺序模式不创建子智能体。
• 指标：Task pass、Test pass、Shell calls（主智能体与全部子智能体合计）、Time（分钟）、Tokens（百万）。
• 判定：各基准官方测试器。论文未使用LLM裁判，也未报告主对比的重复次数。记录token对应20,780.02美元，正文写11.2 billion recorded tokens。
• 检验：合并短程与长程后，对三款智能体做exact McNemar检验并Holm校正，与α=0.05比较。委派与难度用双侧Spearman置换检验，30次比较做Holm校正。

主结果

据Table 2，Task pass（%），格内为并发/顺序。

表格较宽，可左右滑动

基准	Codex	Claude Code	Kimi Code
SWE-bench Verified	71.0/71.0	59.0/83.0	59.0/77.0
RepoZero	40.7/40.0	26.7/42.7	38.7/37.3
NL2Repo	57.7/34.6	65.4/57.7	46.2/57.7
ProgramBench	0.0/0.0	0.0/0.0	0.0/0.0
LoopsBench	25.0/21.4	21.4/7.1	25.0/25.0

• 作者的解读：作者称动态并发并不稳定提高端到端成功率；引言中的解决率效应为下降11.9个百分点到上升2.3个百分点。LoopsBench上Codex与Claude Code的Task pass升幅最高14.3个百分点，Kimi Code不变；该基准Test pass三款都上升，升幅最高6.0个百分点。SWE-bench Verified无提升，Claude Code下降24.0个百分点。其他长程基准并不一致，见表中Claude Code的RepoZero和Kimi Code的NL2Repo。
• 统计检验：合并两类任务后，作者报告Claude Code与Kimi Code的总体下降在α=0.05下统计显著，调整后p分别为5.08348×10−7和0.0132176；Codex的上升不显著，p=0.229481。
• 与规模及内部抵消：三智能体等权平均后，并发减顺序的Test pass差值按实现规模排序，为RepoZero −8.29、NL2Repo −0.04、ProgramBench +1.24、LoopsBench +4.31个百分点。作者认为更大的预期实现规模与更大的平均Test pass优势相关。Codex在RepoZero内部，Py2JS的Task/Test pass降2.0/1.7个百分点，C2Rust升6.0/2.4个百分点，少解决2个Py2JS、多解决3个C2Rust，150个任务净增1个。

资源消耗与耗时

据Table 2，Tokens（百万），格内为并发/顺序。

表格较宽，可左右滑动

基准	Codex	Claude Code	Kimi Code
SWE-bench Verified	3.37/1.34	2.14/1.02	1.01/0.98
RepoZero	2.47/0.89	4.03/2.42	1.33/0.82
NL2Repo	8.00/2.87	8.55/6.53	2.70/2.21
ProgramBench	27.05/9.19	6.02/6.18	11.64/6.05
LoopsBench	51.65/11.45	21.73/15.52	41.49/11.29

• 调用与token：作者称每个智能体、每个基准的平均shell calls都上升，token达顺序模式的1.41–3.31倍。上表里Claude Code在ProgramBench一格并发并不更高。例如Claude Code在LoopsBench的Shell calls为791.6对107.4。按已解决任务摊销后三款都上升；论文给出的Codex数字是并发24.12 million、顺序7.69 million。
• 耗时：作者称平均端到端时间总体上升，15个智能体–基准组合中有14个上升。Table 2中Kimi Code在ProgramBench为39.9分钟对40.1分钟；作者未点名哪一格是例外。Claude Code在SWE-bench Verified为27.8分钟对17.5分钟，同时解决的任务更少。
• 少数加速：两种模式都解决的366例中，并发更快的有102例（27.9%），其中46例（12.6%）至少快20%。作者认为协调得当时并发仍可能加速。

委派规模与时间重叠

• 随难度变化：全部并发执行等权后，平均创建数从易6.69、中7.53到难15.84，平均峰值从3.66、4.61到6.70。LoopsBench上三智能体平均的创建数从易16.25到难68.18，峰值从6.00到21.77。难任务中LoopsBench占14.6%，但占难任务上所创建子智能体的62.9%。作者称Claude Code在RepoZero上并不必然对更难任务创建或维持更多子智能体。
• 智能体差别：Codex各任务组平均峰值在1.21到3.00。难LoopsBench上，Claude Code平均创建133.69、峰值25.46；Kimi Code平均创建67.00、峰值37.46。作者检查实现后称，Codex可把部分实现留在主智能体，Claude Code可在后续阶段新建组别，Kimi Code可一次发出大批次。
• 时间结构：创建了子智能体的执行中，首次派生的轨迹位置中位数为Codex 4.0%、Claude Code 22.1%、Kimi Code 26.0%；首次重叠中位数为4.7%、22.5%、26.9%。全部任务的重叠比例中位数为23.9%、52.7%、15.6%。末次子智能体结束点中位数为83.3%、100.0%、93.6%。354次执行中，创建了子智能体但彼此无重叠的比例为Codex 24.3%、Claude Code 1.7%、Kimi Code 2.8%。作者称Codex早派生但重叠较短，Claude Code较晚派生但重叠更持久，Kimi Code的重叠比例中位数最低。

失败分类与收益情形

• 分类规模：1062条并发轨迹全部人工标注，Cohen's κ=0.77。四类、13个子类、28个具体模式出现在650条轨迹中，共804个实例；一条轨迹可含多个模式。Table 3：任务编排229（28.5%），执行治理233（29.0%），全局上下文75（9.3%），共享状态与合并267（33.2%）。
• 高频模式：负载不均衡166（20.6%），其中Fan-out Budget Exhaustion 154（19.2%），并占Claude Code模式实例的39.8%。启动、汇合或结果时机错误166（20.6%），其中过早终止128（15.9%）。并发写213（26.5%），占Codex模式实例的62.9%；交付物覆盖120（14.9%）。Figure 2的seqtk例子中，Kimi Code一批发出20个子智能体，任务预算40分钟，通过92/440个测试；作者用它说明整批等待会挤掉集成。
• 收益条件：131对轨迹满足更高Test pass、独有完全解决，或在不降低Test pass时至少快60秒且快20%。作者归纳三种情形：互补工作，如Kimi Code的NL2Repo justext，两种模式都通过全部测试，墙钟时间从734.116秒到467.997秒；替代方案选择，如Codex的ProgramBench Halite，并发292/391、顺序0/391；独立校验，如Codex的LoopsBench安全实验任务和NL2Repo trimming，并发通过全部检查或全部测试，顺序模式未通过。作者称收益出现在主智能体把并行结果用于集成、选择或纠正时。

其他消融与分析

• ProgramBench委派：Claude Code平均创建数由易到难为10.71、22.08、31.29，峰值8.00、11.56、13.86（第5.1节）。
• 难度关联：30次Spearman比较中，作者报告显著的是Claude Code在ProgramBench的创建数（ρ=0.470，调整后p=0.015）和Codex在SWE-bench Verified的创建数（ρ=0.316，调整后p=0.042）。作者称任务结构和协调机制也会塑造委派。
• 独有成功（Figure 4）：Claude Code在LoopsBench有4个仅并发解决的任务（样本28），顺序模式无独有成功；在SWE-bench Verified有5个仅并发解决（样本100）。Codex在该基准两种模式各独有9个，汇总值相同。该图对ProgramBench以test pass大于0计成功。
• Test pass（Table 2，并发/顺序）：ProgramBench为Codex 58.3/53.5、Claude Code 0.5/1.8、Kimi Code 1.7/1.5；LoopsBench为Codex 58.1/52.1、Claude Code 48.7/45.8、Kimi Code 66.6/62.5。

作者指出的局限与后续方向

• 外部效度（第8.2节）：作者写明发现限于所测智能体与基准。文中的应对是选用前沿编程智能体及其原生模型，并做费用超过20K美元的评测。
• 随机性与重复（第8.2节）：作者写明执行是随机的，长程评测成本限制了大规模重复运行。作者认为逐次随机不太可能实质改变总体趋势，依据是本实验中Codex在LoopsBench的顺序Task pass和Test pass接近该基准原文对Codex配GPT-5.4的报告，且原文称重复尝试下总体趋势稳定。
• 人工标注（第8.2节）：作者写明人工分析可能引入主观判断。文中的做法是50条试点码本、三人中的两人独立标注、记录理由、讨论分歧，并由资深作者裁定未决分歧。
• 开放问题（第8.1节）：作者列出四类后续问题：任务分解、所有权分配与负载均衡；检测停滞或失败的子智能体、回收未完成工作，并决定何时收集结果或终止；在隔离上下文之间传递需求、接口契约和可复用进度；共享文件与环境的隔离、同步和冲突检测。

实验覆盖范围

• 被测为Codex、Claude Code、Kimi Code，分别配GPT-5.4、Claude Opus 5、Kimi K3，配置选自2026年7月，并使用最高推理力度（第3.2节）。
• 基准为RepoZero、ProgramBench、NL2Repo、LoopsBench和SWE-bench Verified；分层样本354个任务、2124次执行（Table 1、第3.3节）。
• 效果由各基准官方测试器判定。论文未报告LLM裁判，也未报告主对比每个执行单元的重复次数（第3.4节、第8.2节）。
• 失败分析覆盖全部1062条并发轨迹，每条两人标注，Cohen's κ=0.77；收益分析使用131对轨迹（第6.1节、第7节）。
• 实验对照是关闭动态并发的顺序模式。论文在第2节讨论了ChatDev、MetaGPT、CodeR等静态系统，未报告与这些系统的实验对比。

三款前沿编程智能体被用来检验一种执行中才决定的并行：主智能体自行判断要不要派生子智能体、委派什么、怎样汇合。要回答的是长程编程任务上成功率是否提高、资源增加多少，以及失败和收益各在什么协调条件下出现。

• 协议：Codex配GPT-5.4，Claude Code配Claude Opus 5，Kimi Code配Kimi K3。354个任务来自RepoZero、ProgramBench、NL2Repo、LoopsBench和SWE-bench Verified，每任务两种模式各一次，共2124次执行；顺序模式不创建子智能体。
• 成功率：作者称解决率效应为下降11.9个百分点到上升2.3个百分点。LoopsBench上Task pass升幅最高14.3个百分点；SWE-bench Verified上Claude Code下降24.0个百分点。合并短程与长程后，作者报告Claude Code和Kimi Code的下降在α=0.05下统计显著，Codex的上升不显著。
• 资源：作者称平均token达顺序模式的1.41–3.31倍。Codex每解决一个任务记录24.12 million token，顺序模式为7.69 million。15个智能体–基准组合里14个平均耗时更高；两种模式都解决的366例中，12.6%至少快20%。
• 失败：更难的长程任务创建更多子智能体，但三款的派生时机和重叠时长不同。804个失败实例中，共享状态与合并占33.2%，执行治理占29.0%，任务编排占28.5%，全局上下文占9.3%。
• 作者的结论：收益出现在互补分工、替代实现的选择，或子智能体独立校验并纠正主智能体时。作者建议按任务决定是否打开并发，并在执行预算内优先做可核对的汇合与交付。