LoopArena：大模型当“项目经理”调度Agent，长程任务最高成功率仅24.69%

LoopArena: Benchmarking Models as Runtime Controllers for Loop Engineering

在软件工程智能体（Coding Agent）的演进过程中，从业者的交互模式正在发生一场深刻的范式转移。过去，开发者习惯于紧盯智能体的每一步输出，手工审查终端报错，并不断微调输入提示词。而随着长程规划与多轮工具调用的普及，“循环工程”（Loop Engineering）逐渐成为构建生产级编码系统的核心实践：工程师不再人工干预每个环节，而是设计一个外部控制循环，由它来监控任务进度、分配阶段性目标、调度验证工具，并决定当前回合究竟是继续编码、展开修复还是主动终止。

ArXiv URL：https://arxiv.org/abs/2608.28281v1

然而，一旦将复杂的代码仓库交由循环系统托管，全新的失效模式便接踵而至。一个底座代码能力极强的模型，很可能会轻易轻信一份过时的进度备忘录，忽略关键的回归测试，在完全错误的分支上耗尽上下文与计算预算，甚至在一个微小的局部测试通过后误以为大功告成而提前提交。更棘手的是，现有的软件工程基准测试（如 SWE-bench 及其演进版本）大多只根据最终的代码仓库状态进行黑盒评测。如果一次端到端运行失败了，开发者根本无法厘清这究竟是因为底层的编码模型写不出正确的算法，还是因为外层的循环控制逻辑发出了错误的调度指令。

来自阿里巴巴集团 DreamX 团队、北京邮电大学、澳大利亚数据61研究所（CSIRO’s Data61）与新南威尔士大学的研究团队在最新论文中提出了 LoopArena，这是首个专门针对“大模型作为运行时控制器”（Model as Runtime Controller）这一核心能力的基准测试。该研究将底层的编码执行者（Worker）与顶层的控制管理者（Controller）彻底解耦，在固定底层编码模型的前提下，系统评估不同大模型作为“项目经理”调度智能体攻克长程复杂工程任务的能力。评测结果揭示了一个冷酷的现实：在完整的真实长程工程任务中，即便是当前最前沿的模型担任控制器，最高严格成功率（Strict Success Rate）也仅有 24.69%；而业界常用的“机械重复原始任务目标”策略，在长程控制中几乎完全失效。

从“超级单兵”到“层级调度”：解耦控制与执行

要科学评估循环控制能力，首先必须解决评估对象混淆的问题。以往对智能体系统的评测往往把规划、探索、代码生成、工具调用与自我修正揉捏在一个黑盒智能体内部。当智能体表现不佳时，研究人员很难判断是代码生成模块的逻辑错误，还是调度逻辑的短视。

LoopArena 采用了一种双智能体测试架构（Harness），将整个软件开发过程拆分为“外环”（Outer Loop）与“内环”（Inner Loop）。在这一架构中，被评测的大模型扮演控制者的角色（Controller），而实际执行代码修改与测试执行的则是被固定的工作智能体（Worker，论文实验中统一固定为 Qwen3.7-Plus）。被评估的 Controller 本身没有任何编码工具或终端交互权限，它无法直接修改代码仓库，只能通过结构化的指令对 Worker 进行调度。

整个控制闭环的设计非常严密。每当 Worker 完成一个阶段的工作并将控制权交还给测试框架时，框架会启动一个临时的报告智能体（Reporter）。该 Reporter 挂载于 Worker 历史对话的临时副本上，负责提取当前工作区的真实状态与关键证据，并由测试框架将其严格格式化为一份只读的“证据数据包”（Evidence Packet）。Controller 审阅该数据包后，必须做出关键的策略判断，并输出一份符合规范的“循环契约”（Loop Contract）。这份契约可以是指派下一个具备明确边界的子任务，可以是要求针对某项边界条件展开定向验证，也可以是判定任务达成并正式终止运行。

这种设计的精妙之处在于对控制变量的极致控制。无论更换哪个模型担任 Controller，底层的 Worker 模型、代码编辑工具、终端沙箱、执行预算、中间报告机制以及最终的测试评估套件都完全保持一致。这就彻底排除了 Worker 个人能力的偶发波动对实验结论的干扰，使评估指标纯粹且精确地收敛在大模型对长程复杂过程的“战局判断力”与“任务指派力”上。

兼顾效能与成本：三层互补的评测空间

长程代码任务的在线评测极其昂贵。一个典型的复杂软件修复或功能迭代任务，往往需要 Worker 连续执行数十轮甚至上百轮 ReAct 交互，频繁调用 Docker 容器编译与回归测试，若每测试一个新控制器模型都从零运行全套基准，推演成本将令人望而却步。为此，LoopArena 巧妙地构建了三层在执行粒度与成本消耗上互补的评测形态：

Type I（契约选择单选）：这一评测完全消除了评测阶段的 Worker 执行成本。研究团队在真实轨迹的关键控制节点上采集环境切片，固定当前的证据数据包，并提供 4 个候选循环契约。正确答案并非人工主观标注，而是在基准构建阶段通过双调度计划真实重放执行，只有在不同重放路径下均能带来最优下游执行结果的选项才会被选为标准答案。在实际评测时，待测模型只需在单步决策中完成 4 选 1，即可极其低成本地探测模型在细粒度决策分水岭上的敏锐度。
Type II（精简切片控制）：针对全任务执行代价高的问题，Type II 选取了完整任务中的某个连贯阶段。测试从一个预先构建好的中间代码仓库工作区开始（此时前期工作已完成，但当前阶段的核心需求尚未满足），要求 Controller 带领 Worker 协同推进并完成该特定阶段的开发与验证。
Type III（端到端完整控制）：这是最严格的宏观测试。任务从最初的 GitHub Issue 描述与原始未修改的代码仓库启动，Controller 必须在漫长的交互周期中全程把握方向，自主引导 Worker 完成从初始探索、功能实现、错误修复到最终决定提交退出的全生命周期。

这一三层架构不仅覆盖了微观单步决断与宏观全局把控，还带来了一个极具工程价值的发现：实验表明，Type II 切片评测相比 Type III 完整评测，其推演成本平均大幅缩减了 64.4%；但在衡量控制器优劣的核心指标上，二者对不同模型给出的排名相关性高达 Spearman’s $\rho = \mathbf{0.9747}$。这意味着开发团队在后续迭代控制逻辑或微调专用调度模型时，完全可以依靠 Type II 进行高保真、低成本的快速算法筛选，而无需每次都耗尽算力去跑昂贵的全量任务。

实验发现一：长程循环控制是一道未解难题

在数据来源上，LoopArena 严格筛选了来自 SlopCodeBench（针对长程迭代编码）和 BeyondSWE（覆盖跨仓库复杂工程）的高难度真实任务，确保评测场景不局限于简单的单文件函数填空，而是真正面对大型工程代码库的复杂演进。

实验结果给当前过分乐观的智能体产业泼了一盆冷水。在 Type III 完整任务的严格成功率（Strict Success Rate）测试中，即便是综合表现最佳的模型，其最终成功率也仅仅定格在 24.69%。这一数字不仅远低于人类软件架构师在相同约束下的表现，也显著低于人们对当前前沿大模型“逻辑推理能力”的预期。

深入分析执行轨迹可以发现，控制器模型最常掉入两类认知陷阱：第一类是“轻信幻觉”。当 Worker 汇报称“某模块的代码已经编写完成，且基础单元测试通过”时，缺乏深层工程审视能力的 Controller 往往会直接予以认可，并下达终止指令，完全没有意识到原本 Issue 中明确规定的向后兼容性、边界用例或关联模块集成测试根本尚未运行。第二类是“发散失控”。在面对复杂的异常报错时，Worker 容易在代码库的不相关角落里反复打补丁，而 Controller 此时往往缺乏拉回主线的全局视野，不仅没有制止 Worker 的盲目探索，反而在后续契约中顺着 Worker 汇报的偏门错误继续指派任务，最终在极高的上下文消耗下耗尽预算而崩溃。

实验发现二：“机械复述目标”无法代替动态上下文感知

在工程实践中，许多初期的智能体框架倾向于采用一种简化的控制策略：类似于部分系统实现的 /goal 逻辑，在每次交互切换时，程序自动将最初的用户 Prompt 机械地重新喂给模型，提醒其“不要忘记最终目标”。

为了验证这种策略的有效性，LoopArena 引入了两个极具说服力的基线策略：

无控制基线（No-control）：将任务一次性交代给 Worker，让其凭借自身内部的 ReAct 循环自由跑到底，直至其自主认输或耗尽轮次。
固定控制基线（Fixed-control）：不调用任何高阶模型担任 Controller，而是在每个交接点，由框架确定性地重复原本的顶级任务目标，强行要求 Worker 继续执行。

在 Type III 的长程完整任务中，Fixed-control 的表现令人大跌眼镜——它相较于完全不加干预的 No-control 几乎没有带来任何统计学意义上的显著增益，某些指标甚至出现了倒退。

这一反差深刻地揭示了长程循环控制的技术本质：有效的控制绝不是静态目标的简单机械回响，而是高度依赖运行态证据的动态博弈。当代码库随着执行推进而发生状态演化时，系统最需要的信息输入不是“最初的目标是什么”，而是“刚才那一步修改到底改动了什么”、“这个通过的测试是否具有代表性”、“当前是否存在隐蔽的代码破坏”。一个合格的控制器必须根据当前的运行证据，在“深入推进开发”、“退回检查前置条件”、“转换排查策略”与“适时止损退出”之间做出权衡。简单的提示词重复，在面对真实的代码分支发散时毫无防御力。

而在微观的 Type I 决策评测中，各大前沿模型的选择准确率分布在 72.22% 至 87.78% 之间，且所有受测模型在格式规范性上均做到了 0% 的解析失效。这证明目前的主流模型完全具备理解结构化报告、并从预置选项中辨识出“更优路径”的局部鉴别力。但从单步的 87.78% 识别率，骤降到宏观全任务的 24.69% 执行成功率，直观呈现了单步逻辑与多轮状态累积之间的巨大鸿沟。

软件工程 Agent 的范式演进：从代码生成到组织控制

LoopArena 的提出，在编码智能体评测体系中切出了一个极具价值的全新纵深。它向社区清晰地传递了一个信号：构建高可靠性的自动化软件工程师，代码生成模型的单点参数量与编码质量只是基础底座，而环绕在模型周边的循环控制架构与调度模型质量，正在成为制约端到端能力的更大瓶颈。

这项研究对未来 Agent 架构设计具有多重启发意义。在系统架构层面，它明确了“双层解耦”的必要性。将写代码的执行者与审视全局的管理者分离，不仅让代码生成的 Token 消耗与宏观逻辑规划的开销各司其职，还能有效避免单智能体身兼数职时普遍存在的“既当运动员又当裁判员”的自我校验幻觉。

在基准评测方法论上，Type II 展现出的极高相关性（$\rho = 0.9747$）为产业界指出了一条兼顾经济性与保真度的测试路径。在未来的持续集成与模型迭代中，开发者不必在每次微小优化后都去跑耗资数千美元的全量端到端评估，而可以通过高质量的任务切片实现敏捷反馈。

当代码大模型在 HumanEval、SWE-bench 等传统榜单上的单点指标逐渐趋于饱和，真正的技术战场已经转移到了复杂工程体系的长程把控上。LoopArena 为这场向深水区迈进的探索树立了一面清晰的镜子：代码智能体要想真正接管企业级生产环境中的复杂迭代，大模型不仅要学会如何“敲键盘写代码”，更要学会如何在风云变幻的执行现场，当好一个头脑清醒、进退有度的“项目经理”。