LoopArena: Benchmarking Models as Runtime Controllers for Loop Engineering

TL;DR LoopArena 是首个评估模型作为运行时控制器引导独立编码 agent 完成长程任务的基准，通过三种执行范围与成本层级检验循环工程决策能力，当前最优严格成功率仅 24.69%，显式暴露了长时程控制中的关键短板。

问题

问题背景

随着 coding agents 在长周期软件任务中的应用，Loop Engineering 成为组织开发工作的新实践：设计循环来监控进度、分配任务、运行检查并决定代理的下一步动作。评价对象从“单次 prompt 质量”转向“运行时控制器的决策质量”。

现有方法局限

• 端到端运行只看最终是否通过测试，无法归因：失败可能来自 Controller 指令错误，也可能来自 Worker 执行能力不足。
• Controller 可能信任过期的进度报告、跳过必要验证、把 token 预算花在错误方向，或过早停止；这些中间决策在现有基准中缺少独立量化。
• 缺少对 成功率 与 推理成本 的联合度量，难以比较“多轮保守验证”与“激进提前停止”两种策略的实际工业价值。

为什么这个问题难/重要

长时任务的状态观察天然滞后且不完整，Controller 必须在部分可观测环境下做序列决策，一个早期误判会沿循环不断放大。业界正从一次性 prompt 转向可复用、可审计的 agent 循环，稳定、成本可控的运行时控制成为规模化采用的关键瓶颈；而现有评估无法提供可比较的控制器信号。

行业类比

类似自动驾驶中把规划器与执行器分离评测：LoopArena 希望独立衡量“驾驶决策”的质量，而非只看整车最终是否到达终点。

核心洞察

• - Control-Executor 解耦是核心贡献。LoopArena 将 Controller 与固定 Worker 分离，单独评估前者在长程任务中的循环控制与验证决策，而非代码生成能力。这解决了传统端到端 agent 基准中最终成败无法归因到控制策略还是执行能力的问题。 - Type II 可作为高性价比代理。在压缩任务切片上重复执行控制，其主指标排序与完整任务高度一致（Spearman's ρ=0.9747），且全任务估计推理成本平均降低 64.4%。这为工业界提供了可扩展的评估途径，能低成本筛选弱 Controller，同时对完整任务排序保持高保真。

方法

输入与角色

LoopArena 将评测对象定义为 Controller，与被评测模型分离：模型作为 Controller，在每一轮编码结束后接收结构化运行摘要（包括进度记录、验证状态、历史动作等）。实际执行任务的是固定且独立的 Worker，负责执行 Controller 所指定的下一步操作。

关键模块：三类评估设置

1. Type I: Contract selection — 不运行 Worker，基于执行验证问题要求 Controller 从预定义 Loop Contract 集合中选择下一步指令，以低成本度量决策质量。
2. Type II: Condensed coding task — 从完整任务中截取关键切片，执行多轮控制循环，用于降低评估成本，同时复现主要排序。
3. Type III: Full coding task — 从原始状态端到端运行完整任务，评估长程控制能力与最终的成功提交。

控制循环与输出

每个控制回合中，Controller 接收 Evidence Packet 或报告模板，输出一个动作：要么选择某个 Loop Contract（例如继续验证、分配子任务、运行检查），要么决定停止并提交结果。Worker 按指令执行后更新状态，循环继续。主要指标包括 Strict Success Rate、推理成本变化等；实验表明不同 Controller 的平均推理成本降幅约 64.4%，而完整任务严格成功率仅 24.69%。

与同类方法的差异点

LoopArena 将运行控制能力与代码执行能力解耦：固定 Worker 隔离了下游执行变量，专门度量 Controller 的指导质量，这与把模型作为单一端到端执行者的主流 agent 基准（如 SWE-bench）形成明确对照。

实验

实验设计

• LoopArena 将评估分为 Type I 契约选择、Type II 压缩任务、Type III 完整任务，覆盖不同执行范围与成本粒度。
• 被评估模型作为 Controller，每轮编码后接收结构化运行摘要，指示固定的 Worker 下一步验证或停止。
• 多模型作为 Controller 进行横向对比，Worker 固定以隔离控制能力。

关键发现

• 在完整任务上，目前最佳 Strict Success Rate 仅为 24.69%，表明长周期控制仍存在显著提升空间。
• Controller 带来的推理成本降低平均为 64.4%，说明良好控制能明显节省 token 消耗。
• Type II 与 Type III 在 Core 准则下的排序一致性高（Spearman's ρ=0.9747），压缩任务可作为低成本代理评估。

深度解读

与固定无控制策略相比，引入 Controller 在成本上优势明显，但成功率依然偏低，核心瓶颈在于停止决策与验证策略。 对实际工程而言，该基准强调将控制策略与 worker 能力解耦，有助于定位失败原因，并指导设计更稳健的验证与预算管理机制。

行业影响

落地场景

LoopArena 面向 loop engineering 场景，适用于 AI coding agent 平台、自动化软件工程流水线 与 长周期研发任务管理系统。例如：

• 电商后端服务迭代：Controller 根据 CI 失败日志与测试覆盖率，决定下一轮 Worker 是补测试、修 bug 还是停止提交。
• 企业服务 SaaS 的多模块代码改造：Controller 在预算内分配审查资源，避免在错误方向耗尽 token。

商业价值

核心收益在 降本 与 提效：论文实测配对 Controller 平均降低 推理成本 64.4%，同时保持相近任务完成度。对于按 token 计费的 Agent 产品，这意味着同等任务量的毛利提升；对于内部研发平台，则是更可预测的算力预算与更短的交付周期。严格成功率仍有较大提升空间（最佳 24.69%），因此早期采用可作为差异化能力而非全面替代人工。

与现有产品/工作流的接口

LoopArena 可作为 Controller 选型与回归评测 的离线组件，集成到现有 Agent harness（如 SWE-bench 类评估、GitHub Actions、内部 CI）中。具体方式：

1. 将生产里的 Worker 与 Reporter 接口按论文协议封装。
2. 用 Type I 题目做快速、低成本的控制器初筛。
3. 用 Type II/III 做上线前全链路回归，监控 Strict Success Rate 与推理成本。

这样可以在不改变已有 coding agent 实现的前提下，引入一个可评测、可替换的 Controller 策略层。

局限

• **任务覆盖范围有限**：LoopArena 的评估任务主要源自 SWE-bench 等现有编码基准，偏向 Python 与相对短周期的改动；这未必能代表真实生产环境中 loop engineering 的长周期、多服务协作、非理想初始状态等复杂场景。论文自身也承认，任务来源和切片方式可能限制结论的外部效度，尤其对于需要持续集成、跨仓库协调或长期维护的项目，当前基准的覆盖面仍然较窄。
• **评估成本与指标的代理性**：Type III 完整任务执行开销高，导致样本量受限，统计效力可能不足；Type I 和 Type II 虽然与 Type III 有较高相关性（Spearman's ρ=0.9747），但毕竟是对完整控制循环的缩写或静态替代，无法完全捕捉实际运行中的错误累积、状态漂移等动态因素。此外，成本核算仅计推理 token 数，未涵盖延迟、内存占用、工具调用费用或重试开销，实际部署中的资源节省可能被高估。
• **与同类 agent benchmark 的对比短板**：现有工作如 SWE-bench、AgentBench 已对 agent 执行能力有较成熟的多维评测，而 LoopArena 侧重控制层，却未系统研究循环设计参数（如报告频率、检查点策略、停止条件阈值）对控制器表现的影响；这些参数在实际工程中常由人类设计者调优，基准中将其固定，可能低估了循环工程整体可优化空间。同时，固定 Worker 模型使得控制器评估结果可能不适用于能力差异较大的编码代理，结论的泛化性有待进一步验证。