一句话总结

DreamX 团队、阿里巴巴集团、北京邮电大学、UNSW Sydney 等机构的研究人员提出了 LoopArena，一个基准，用于评估模型 Controller 在三种执行范围设定下引导独立的固定 Worker 完成长期编码任务的能力，报告的最佳 Strict Success Rate 为 24.69%，Spearman’s ρ = 0.9747，平均推理成本降低 64.4%。

核心贡献

• 本文提出了 LoopArena，该基准通过保持编码 Worker 和控制接口固定不变，依据结构化运行摘要对下一步指令、验证决策和停止决策进行评分，从而隔离 Controller 模型的长期循环引导能力。
• LoopArena 提供三种互补的评估设置：无需运行 Worker 的执行验证型下一步契约选择、对选定任务片的重复控制，以及从原始仓库状态出发的成对全任务执行。基准数据和评估代码已公开。
• 实验结果显示，观察到的最佳 Type III Strict Success Rate 为 24.69%，成对的 Type II 平均推理成本估计降低 64.4%，同时与全任务相比保持了相近的 Controller 排序（Spearman’s ρ = 0.9747）。固定目标策略并未优于无引导执行，这表明有效的循环控制必须适应不断变化的运行过程。

引言

Loop Engineering 反映了一种转变，即让模型管理一个独立的 coding agent 来完成长期任务，而不是要求开发者检查结果并手动编写每条后续提示。这一点很重要，因为经过许多步骤之后，看似合理的部分结果可能被误认为已经完成，而下一条有效指令可能需要从实现转向验证、恢复或停止。现有大多数编码基准评估最终仓库状态或完整 agent 系统，因此没有直接隔离模型在运行时引导另一个 coding agent 的能力。作者提出了 LoopArena，在该基准中，被评估模型作为 Controller，作用于固定的 Worker 和执行设置。它从三个互补层面评估运行时循环控制：低成本单次控制决策、任务片级运行时引导，以及端到端的长期仓库级任务。

数据集

作者构建了 LoopArena 基准，从 SlopCodeBench（SCBench）和 BeyondSWE 中选取任务，在三个不同范围评估 coding agent 的 Controller。SCBench 提供长期迭代编码任务，而 BeyondSWE 覆盖更广泛的软件工程挑战。

• Type I：契约选择。 每个实例是从 Controller 引导轨迹中的可恢复点提取的单项控制决策。输入是一个 Evidence Packet 和四个候选 Loop Contract。正确答案通过从同一恢复状态、按照两个预先声明的重放计划执行所有四个候选来确定，仅保留根据成功与成本规则在两种计划下同一候选都唯一胜出的项。经过验证后，评估新 Controller 只需进行四选一，且无需执行 Worker。
• Type II：压缩编码任务。 从完整任务的某个连贯开发阶段提取的任务片。它从准备好的中间工作区开始，要求 Controller-Worker 循环完成该阶段。只有当起始工作区未通过至少一项该阶段引入的需求，且来源提供的完成状态通过所有预期需求时，该任务片才会保留。每个 Type II 案例都与其对应的 Type III 任务配对，用于匹配比较。
• Type III：完整编码任务。 从初始状态执行的原始完整任务。Controller 管理从初步调查、实现、验证到最终停止决策的整个运行。

来源与筛选：

• 源任务来自 SCBench（原生检查点提供 Type II 任务片）和 BeyondSWE（使用官方修复和测试手动划分为连贯阶段）。
• Type I 项锚定在记录的 Controller 决策之前；备选项在任何重放结果被观察到之前冻结。没有唯一重放共识胜者的项被丢弃。
• Type II 任务片必须满足上述工作区需求差距，否则将被剔除。
• 所有子集都经过自动化一致性检查和 LLM 辅助审查，以验证任务、工作区和评估器的一致性，并确保模型输入不会暴露源轨迹中的求解代码、评分结果或未来事件。任务与任务片的选择在正式评估前固定。

数据使用方式： LoopArena 在三个层面评估 Controller 能力：单次契约决策（Type I）、任务片（Type II）和完整任务（Type III）。成对的 Type II 与 Type III 案例可在两个范围之间直接比较评估成本和 Controller 排序。基准规模及更多统计信息见论文。

方法

作者设计了 LoopArena，通过结构化控制循环评估和引导长期编码任务。该框架在每次运行中保持一个持久的 Worker 对话。Worker 是唯一配备编码工具的组件，遵循原生 ReAct 循环来检查与修改仓库、运行检查并执行所分配的工作。当 Worker 完成一个片段时，控制权返回给 harness，暂停持久对话并启动控制循环。

在每个控制循环开始时，harness 根据累积的 Worker 对话副本生成一个临时的 Reporter agent。该 Reporter 与 Worker 使用相同的模型配置，但仅限只读工具。它生成对运行的四部分说明，详细描述任务上下文、已完成工作与当前状态、可用的验证证据以及剩余问题。报告中的实质性声明引用相应的 Worker 轮次。Reporter 描述当前状态而不决定后续动作，且不能执行代码或修改仓库。

对于控制循环 $k$k 中的可执行任务 $i$i，harness 将报告和引用的 Worker 轮次打包为 Evidence Packet $x_{i,k}$xi,k​，作为 Controller 的结构化只读摘要。令 $\pi$π 表示 Controller 模型，$h_{i,k}$hi,k​ 表示其决策前的对话历史，包含之前的 Packet 和 Contract。在每个控制点，Controller 收到最新 Packet 以及该历史，但不能直接访问工作区或编码工具。然后，它产生一个 Loop Contract $c_{i,k}$ci,k​：

$$c_{i,k} = \pi(x_{i,k}, h_{i,k})$$ci,k​=π(xi,k​,hi,k​)

Contract 记录了推进工作、请求重点验证或停止的决定。如果 Controller 选择继续，Contract 会为 Worker 提供一个有边界的下一项任务，并指定控制权何时返回 harness。如果 Controller 选择停止，harness 将当前工作区发送给任务评估器。

为了系统评估该框架，作者使用来自 SlopCodeBench 和 BeyondSWE 的完整编码任务构建基准，并将其组织为三种不同设置。

Type III 从原始状态评估完整编码任务，保留原始规范、起始状态、开发过程和评估器。Type II 将一个完整任务与从准备好的中间工作区开始的一个任务片配对。对于 Type II，案例描述该特定阶段所需的工作，其评估器检查完成时应满足的需求。只有当起始工作区未通过至少一项该阶段引入的需求，且来源提供的完成状态通过所有预期需求时，任务片才会保留。Type I 在 Controller 引导轨迹中的可恢复点构造执行验证的控制问题。每个问题锚定在记录的 Controller 决策之前，以 Evidence Packet 作为上下文。记录的 Loop Contract 作为四个候选项之一保留，另外还有三个完整备选项。只有当一个候选项根据成功与成本规则，在两个预先声明的匹配重放计划下唯一胜出时，它才会成为正确选项。

实验

LoopArena 在三个层面评估 Controller 能力：Type I 通过在四个预先执行的 Loop Contract 中进行选择来测试单次控制决策，而 Type II 和 Type III 则对压缩任务片及其成对完整编码任务上的重复 Controller-Worker 控制进行评分。共享的 Worker 和参考策略允许在这些设置之间进行匹配比较。结果表明，全任务控制仍然困难；固定目标重述在有界任务片上有帮助，但在完整任务上没有帮助；成本较低的 Type II 设置保持了所评估 Controller 的全任务排序。Type I 显示了单次控制决策中的有意义差异，简单捷径远未达到 Controller 级准确率。

该基准比较了三种设置：Type I 隔离单次控制决策且无需 Worker 执行，而 Type II 和 Type III 共享相同的源任务和可执行的 Controller-Worker 循环。Type II 相对于 Type III 减少了 Worker 轮次、控制循环和平均推理成本，同时保持相近的 Controller 排序。完整任务 Type III 成功率仍然有限，固定控制在有界的 Type II 设置中有帮助，但在完整任务中没有帮助。Type II 相对于 Type III 降低了平均估计推理成本，并且每次运行使用的 Worker 轮次和控制循环大幅减少。Type II 中的 Controller 排序与完整任务 Type III 排序非常接近，没有严格有序的 Controller 对出现排序反转。Type I 的响应都解析为单个候选项，确定性捷径的得分明显低于 Controller 准确率。

被评估的 Controller 仅取得了有限的完整任务成功，最强的 Type III 结果低于四分之一。Type II 任务片评估保持了与 Type III 非常接近的 Controller 排序，同时平均将估计推理成本降低约三分之二。固定控制在较短的任务片上有帮助，但在完整任务上没有帮助；Type I 契约决策远高于确定性捷径。完整任务控制仍然困难：Controller 的 Type III 严格成功率峰值低于四分之一。Type II 相对于 Type III 大幅降低了推理成本，同时在主要标准下保持相似的 Controller 排名。固定控制相对于无控制提高了 Type II 成功率，但在 Type III 上没有增益。Type I 契约准确率显著高于所有测试的确定性捷径，后者峰值接近三分之一。

该基准比较了三种设置：Type I 隔离单次控制决策，而 Type II 和 Type III 共享源任务和可执行 Controller-Worker 循环，其中 Type II 使用较短的任务片。Type II 相对于 Type III 显著降低了推理成本、Worker 轮次和控制循环，同时保持相近的 Controller 排序。固定控制在有界的 Type II 设置中提高了成功率，但在完整任务中没有提高，完整任务 Type III 成功率仍然有限。Type I 契约决策解析可靠，并且表现远高于确定性捷径。