LoopArena：面向循环工程的模型运行时控制器能力基准 LoopArena: Benchmarking Models as Runtime Controllers for Loop Engineering
固定编码智能体，专测模型的循环调度指挥能力，全任务最佳成功率仅24.69%
前置知识
Loop Engineering（循环工程）
一种围绕编码智能体组织开发工作的实践：开发者不再逐条手写提示词，而是设计一个外层循环，由循环自动监控进展、分配任务、运行检查并决定智能体下一步做什么，代表机制如 Codex 的 /goal: 持久目标重申。循环质量决定了长任务能否在实现、验证、恢复、停止这些模式之间正确切换。
本文的研究对象正是循环中的运行时控制本身。LoopArena 把循环工程从工程实践变成可测量的基准，理解这一背景才能明白评测对象为何是 Controller 而非整个编码智能体系统。
Controller–Worker 双角色架构
本文把系统拆成两个模型角色：Worker 是固定的编码智能体，拥有读写仓库、跑测试等工具，按 ReAct 循环执行被分配的任务片段（内层循环）；Controller 是被评测的模型，没有任何编码工具，只能读取结构化摘要 Evidence Packet 并下达 Loop Contract 指令（外层循环），两者通过确定性 harness 交接。
整个基准的设计核心是固定 Worker、只变 Controller，只有理解角色边界与信息隔离，才能理解评分为何能干净地归因于控制能力而非编码能力。
ReAct 循环
编码智能体的原生执行模式：模型交替进行推理与行动——调用工具查看代码、修改文件、运行命令，观察结果再决定下一步，直到认为完成分配的任务。本文用 Worker ReAct 回合数衡量执行长度，并设置每段 600 回合或 7200 秒的硬上限，触限计为任务失败。
论文中 Worker turns、内层循环、执行预算等关键指标与运行限制都建立在 ReAct 概念之上，不熟悉它就无法读懂成本与执行长度数据。
可执行评估与 SCBench/BeyondSWE
通过真正运行测试或官方评估器来判定任务成败，而非人工判断。本文任务取自 SCBench（长程迭代编码任务，含多个原生 checkpoint，主准则要求所有 Core 检查通过）和 BeyondSWE（单仓库修 bug 之外更广的软件工程任务，官方 Harbor 评估器要求 reward 为 1）。
Strict Success Rate 的定义完全依赖这些可执行评估器，而且论文的敏感性分析显示评分准则的选择会显著改变结论，是理解实验结果的前提。
Spearman 等级相关
衡量两组排序一致性的非参数统计量，取值 -1 到 1，1 表示排序完全一致。本文用 $\rho_{\mathrm{II,III}}$ 检验低成本的 Type II 排序能否复现高成本的 Type III 排序，这是评测压缩（benchmark compression）方法论中验证便宜基准能否替代贵基准的标准手段。
Type II 设定的核心价值主张——平均省 64.4% 成本仍保持 Controller 排序——完全由这个统计量支撑，是论文最重要的方法学结论之一。
研究动机
现有编码基准（SWE-bench 及其后继）评测的是整个编码智能体系统的最终仓库状态，无法区分成败究竟来自外层循环的引导还是编码模型本身的能力。在真实循环工程实践中，即使 Worker 足够强，循环仍会犯四类典型错误：轻信过期的进度备忘录、跳过必要的验证、把预算花在错误方向上、或在任务尚未安全可提交时就提前停止。长任务中一个看似合理的局部结果极易被误判为完成——某个狭窄的检查通过了，但另一项需求根本没被动过。而且随着仓库和可用证据的演化，下一步有用的指令可能应从实现转向验证、恢复或停止，这种决策质量在端到端的一次性成败评分中完全不可见。
本文的目标是本文的目标是把运行时循环控制能力变成可直接评测的对象：固定 Worker、编码工具、执行预算与任务评估器，只改变充当 Controller 的模型，使被比较的唯一变量是控制能力本身。具体包括三件事：构建覆盖单步决策、任务切片、完整任务三个粒度的基准（90 道 Type I 控制选择题加 27 对配对的 Type II/III 任务）；定义严格的可执行指标（Contract Accuracy、Strict Success Rate、无缓存假设下的推理成本估计）；量化 Type II 相对 Type III 的成本节省并验证其排序一致性，为低成本控制器评测提供方法学依据。
与已有工作不同的是，与评测完整模型-脚手架系统的 Harness-Bench、LoopsBench，以及只给已录制轨迹的步骤打分的过程监督类工作不同，本文的独特切入是 model-as-manager：Controller 不写代码、不碰工具，只能通过结构化指令影响任务，因而控制质量可以被隔离归因。另一个独特点是把候选指令的真实执行前移到基准构建期——Type I 的四个候选 Loop Contract 在两个预登记的匹配重放计划下从同一恢复点重放，只有两计划下唯一赢家一致才保留为答案，使单步控制题具有执行结果背书而非人工标注。Type II/III 的成对设计也让成本与排序的权衡首次可被量化。
核心方法
直觉上，LoopArena 模拟了技术经理管理程序员的场景：经理不亲自写代码，每轮听取汇报、判断局势、下达有边界的下一项任务，或决定收工。技术上，确定性 harness 驱动一个控制循环：Worker 在持久会话中按 ReAct 循环执行被分配的片段；片段结束时，harness 用与 Worker 同款的模型创建临时 Reporter（只能只读检查工作区），从会话副本生成四部分报告——任务上下文、已完成工作与当前状态、可用的验证证据、遗留问题——报告中的关键论断引用对应的 Worker 回合；harness 确定性地把报告与被引用回合打包成 Evidence Packet $x_{i,k}$；Controller $\pi$ 结合自身历史 $h_{i,k}$ 输出 Loop Contract $c_{i,k} = \pi(x_{i,k}, h_{i,k})$，动作为 advance/verify/stop 三选一。继续执行则把合约渲染成 Worker 的下一条指令，停止则把当前工作区交给任务评估器。每个任务每个策略独立重复 $K=3$ 次。
核心创新是评测对象的重定义加上执行背书的单步题。其一，与 SWE-bench 类最终态基准和 Harness-Bench/LoopsBench 评测完整系统不同，本文冻结 Worker（Qwen3.7-Plus）与全部执行设置，被比较的唯一变量是 Controller 模型。其二，Evidence Packet 是只读结构化摘要而非原始对话，Reporter 运行在临时会话副本中、不污染 Worker 持久历史，保证所有 Controller 看到统一的信息接口。其三，Loop Contract 是强 schema 决策——advance/verify 需给出 goal、required_outcomes、prohibited_actions、completion_condition、protected_invariants 等字段，使下一轮做什么、何时交回控制权成为可验证对象。其四，Type I 用双计划重放的唯一赢家确定正确选项，答案由执行结果而非人工判断决定，且候选与展示顺序在任何重放之前冻结。
方法步骤详情
构建分三步。第一步，从 SCBench 取 11 个、BeyondSWE 取 16 个共 27 个官方任务构成 Type III 全任务集；Type II 为每任务选一个阶段切片，从准备好的中间工作区出发，保留条件是起点至少未满足一条该阶段需求、而官方完成态通过该阶段全部要求。第二步，Type I 在 Controller 引导轨迹的可恢复控制点上采样（先采父轨迹再采控制点，避免长轨迹被过度加权），记录的原始 Contract 连同 3 个新造备选共 4 个候选，展示顺序冻结后，用种子 $S{+}1{,}000{,}000$ 与 $S{+}2{,}000{,}000$ 两个匹配重放计划各执行全部候选，按成功、再下游控制轮少、再 Worker 回合少定唯一赢家，两计划一致才保留，最终得 90 题（SCBench 40、BeyondSWE 50）。第三步评测：每策略每任务跑 $K=3$ 次，Worker 每段限 600 回合或 7200 秒，控制循环限 128 周期/86400 秒，Controller 输出上限 20480 token，按冻结牌价逐调用累计无缓存成本。
技术新颖性
技术新颖性有四点。第一，把 Loop Engineering 中的运行时控制这一实践对象首次基准化，附录 Table 16 从模型输出、执行方式、评测对象三个维度与最终态基准、交互式基准、过程/批评基准、循环系统基准做了系统对比，凸显被测对象差异。第二，Type I 的执行验证式标注杜绝人工标注噪声——源轨迹中记录的 Contract 未必是正确选项，赢家完全由重放产出决定，且两计划不一致即弃题、事后不得修补候选。第三，Type II/III 成对设计把评测压缩文献中的排序相关性验证引入闭环执行场景，得到 $\rho_{\mathrm{II,III}}=0.9747$ 与平均 64.4% 的配对成本下降。第四，no-control 与 fixed-control 两个共享参照策略（后者仿 Codex /goal: 每个非终止交接点确定性重申原始目标）把有控制与只是反复念目标区分开，构成对循环价值的关键消融。
实验结果
全任务控制仍然很难：Type III Strict Success Rate 在 16.05%（GLM 5.2）到 24.69%（GPT-5.5）之间，最佳也仅约四分之一，其余为 Qwen 23.46%、Claude 20.99%、DeepSeek 19.75%，而无控制基线即有 18.52%。固定控制把 Type II 从 39.51% 提到 46.91%，但在 Type III 与无控制持平于 18.52%，说明长任务需要随实现、验证、恢复、停止阶段自适应的引导，而非持久重申目标。Type II 以平均 64.4% 成本下降复现了 Type III 的 Core 排序（$\rho=0.9747$，9 个严格有序对零翻转）。Type I 上 GPT-5.5 达 87.78%（79/90），其余 72.22%–77.78%，全部零无效输出；最强捷径仅 31.11%。成本上 Type III 每次运行 GPT-5.5 约 $18.84、Claude $16.82，GLM 仅 $4.86 但成功率最低，且其 20.39% 的 Controller 调用触顶 20480 token 输出上限。分来源看，Type III 的 SCBench 子集上 GLM 为 0/33、最佳 GPT-5.5 也仅 6/33，迭代式长任务尤其困难。
查看结构化数据
| 任务 | 指标 | 本文 | 基线 | 提升 |
|---|---|---|---|---|
| Type I 单步合约选择（90 题，无需执行 Worker） | Contract Accuracy (%) | GPT-5.5 87.78%（79/90）；其余模型 72.22–77.78% | 最强确定性捷径（多数位置）31.11%；均匀随机 25%；词面重叠 18.89% | 比最强捷径高 56.67 个百分点，表面线索无法替代控制决策 |
| Type II 任务切片（27 片段 × 3 次重复） | Strict Success Rate (%) | GPT-5.5 51.85%（成本 $5.00/次） | no-control 39.51%（$1.04）；fixed-control 46.91%（$1.08） | 较无控制 +12.34pp，且高于仅重申目标的固定控制 |
| Type III 全任务（27 任务 × 3 次重复） | Strict Success Rate (%) | GPT-5.5 24.69%（成本 $18.84/次）；Qwen3.7-Plus 23.46%（$6.89） | no-control 18.52%（$2.01）；fixed-control 18.52%（$5.58） | 较无控制 +6.17pp；固定控制在全任务上无增益 |
| Type II vs Type III 排序一致性 | Spearman ρ（Core 准则，5 个 Controller） | ρ = 0.9747，9 个严格有序对零翻转 | 换成 All checks / All non-error 准则后 ρ 降至 0.1481 / −0.2962 | 主准则下切片评测可低成本复现全任务排序 |
| 评测成本（Type II 相对 Type III） | 平均配对推理成本下降 (%) | 64.4%（如 DeepSeek $10.24→$2.10，GPT-5.5 $18.84→$5.00） | Type III 全任务端到端执行 | 切片执行平均节省约三分之二成本 |
局限与改进
作者承认的局限：目前只覆盖仓库级编码任务与单一 Controller–Worker 结构化交接组织，扩展到其他软件领域、Worker 家族、多 Worker 设置与其他循环形态需要重新构建任务与评估器；把三设定设计迁移到编码之外也需要领域特定的构建工作。我补充观察：其一，27 个任务 × 3 次重复样本极小，Type III 上 GPT-5.5（24.69%）与 Qwen（23.46%）仅差 1 次成功运行（20/81 对 19/81），排序对噪声敏感；其二，排序一致性对评分准则高度敏感——换成 All checks 或 All non-error 检查后 ρ 跌至 0.1481 甚至 −0.2962，说明切片可替代全任务的结论只在 Core 准则下成立；其三，GLM 等模型频繁触顶 20480 token 输出上限造成协议失败，把格式遵从能力混入了控制能力测量；其四，成本估计假设无缓存并采用公开牌价，与真实部署的差距可能很大；其五，结论绑定单一 Worker（Qwen3.7-Plus），Controller 排序对其他 Worker 的可迁移性未知。
独立分析的弱点
第一，统计功效不足：每设置 81 次运行下 1–2 个百分点的 SSR 差异未做显著性检验、未报告置信区间，头部两个 Controller（GPT-5.5 与 Qwen3.7-Plus 在 Type III 上仅差 1 次成功）实际不可分辨，改进方向是扩大任务面板或增加重复次数并给出区间估计。第二，Type I 题目全部采自这 5 个被测 Controller 自身轨迹的控制点，题目分布继承了这些模型的控制习惯（如偏 advance 少 verify），可能错估分布外决策，改进方向是从人类轨迹或随机策略等更多来源采样控制点。第三，Reporter 使用与 Worker 同款模型生成摘要，Packet 质量与 Worker 模型耦合，无法区分信息压缩损失与控制决策错误，应消融不同 Reporter 模型或直接给原始轨迹。第四，Type II 每任务只选一个阶段切片，切片代表性未验证，可多切片取平均。第五，固定控制在 Type II 有效、Type III 无效这一对比很有启发，但论文未分析其失败机制——是预算被拉长耗尽还是方向漂移，缺少过程层面的归因实验。
未来方向
作者提出的方向：把基准扩展到更多软件领域、更多 Worker 家族、多 Worker 协作与其他循环组织形态，并将三设定设计迁移到编码之外，这需要领域特定的任务构建与可执行评估器。基于本文成果可延伸的研究：一是把 Type I 的重放赢家作为奖励信号训练 Controller——replay 确定的正确选项天然构成 step-level 标注，可直接用于过程奖励或强化学习；二是研究成本感知的 Contract，让 Controller 在知晓剩余预算的情况下做推进/验证/停止的权衡（现协议只把预算作为只读信息）；三是让 Controller 能主动发起新的验证手段而非仅在 verify 语义下复述检查；四是扩大面板并做多准则联合评分，检验排序对评分政策的稳健性；五是评测缓存感知的真实成本与端到端延迟，弥补无缓存估计的偏差；六是做跨 Worker 泛化实验，检验循环控制能力是否为模型的一般属性而非与特定 Worker 的耦合。
复现评估
开源情况良好：基准数据、构建记录、harness 代码、运行配置、评估记录与分析代码已在 GitHub（AMAP-ML/LoopArena）发布，包括 90 道不含答案的 Type I 题、Type II 起始工作区与切片规格、27 个 Type III 任务规格、逐调用的输入输出 token 用量、冻结的公开牌价表与完整运行清单；无法再分发的评估器容器以不可变源标识引用并附准备说明。算力方面无需自有 GPU，完全依赖 API：Type III 每策略 81 次运行，最贵 Controller 单次约 18.84 美元，完整复现 5 模型双设定需数千美元预算；Type I 全套评估仅需 0.31–13.68 美元，几乎零门槛。复现难度中等偏高：只跑 Type I 或 Type II 很容易；完整复现需要各商用模型的特定冻结版本（如 gpt-5.5-0424-global、claude-opus-4-8）不发生漂移，且单次 Worker 上限 7200 秒意味着全任务评测的串行执行时间可观。
论文图表
