LoopArena：AI 编程 Agent 外层控制器的失败模式基准

Alibaba 的 DreamX 团队与 UNSW 的研究者昨日在 arXiv 上发布了 LoopArena（2608.28281）。该基准测试用于评估语言模型作为长期运行 coding agent 运行时控制器的表现。

Most multi-step agent frameworks have quietly moved away from single-prompt execution. 当你在一个 issue 上运行 Claude Code 或 Devin 这类工具时，实际上是在运行一个 outer loop。该 loop 负责解析任务、向 worker model 推送指令、捕获 diff 与测试日志、检查进度记录，并决定是继续、重定向还是终止。

标准基准测试如 SWE-bench 的问题在于，它们将整个运行过程视为一次不透明的单次尝试。如果一个 agent 未能解决某个 issue，最终的错误日志无法告诉你问题出在哪里：coding model 可能写出了无效语法，或者 loop supervisor 可能接受了一个幻觉出的测试通过、忽略了一个回归问题，或者提前三步就终止了执行。

将控制器与 worker 分离

LoopArena 通过将系统拆分为两个明确的角色来隔离这一失效面：

Worker 是一个固定的 coding agent，负责编辑文件、运行终端命令与执行测试套件。

Controller 是被测试的模型。每一步执行完成后，它接收一份结构化的运行摘要，并选择下一步动作：下发新的 contract、运行特定的验证检查、回滚，或提交。

+-------------------------------------------------------------+
|                      Controller                             |
|  - Reads structured run summary                             |
|  - Validates exit criteria                                  |
|  - Issues next contract / verification / abort              |
+------------------------------+------------------------------+
                               |
                        Loop Contract
                               |
                               v
+-------------------------------------------------------------+
|                        Worker                               |
|  - Executes shell commands and test runners                 |
|  - Generates code diffs                                     |
|  - Emits execution output and error logs                    |
+-------------------------------------------------------------+

该基准测试在三个执行成本层级上测试 controller：

Type I：静态问题，测试 controller 在历史执行轨迹上是否选择了正确的下一步。这不需要启动真实的运行环境。

Type II：交互式控制，针对开发任务的目标切片，衡量在特定子问题上的多步恢复能力。

Type III：从初始仓库状态到完成的完整长时程任务。

论文中的数据

实证结果表明，当任务运行时间拉长时，当前的 loop 监督有多么脆弱：

Low completion ceiling：在完整的 Type III 任务上，所有测试 controller 中的最高 Strict Success Rate 仅为 24.69%。即使底层有一个能力足够的代码生成模型，supervisor model 仍然难以将多文件变更引导至完成。

Token savings from active pruning：有效的 controller 将总推理成本平均降低了 64.4%。良好的 loop 路由剪掉了冗余的测试循环、阻止了循环编辑，并在消耗 token 预算之前终止了注定失败的轨迹。

Slice evaluation predicts full runs：Type II 切片评估与完整的 Type III 运行之间的 Spearman 等级相关系数达到 0.9747。团队可以在短执行片段上对 supervisor prompt 进行基准测试，而无需为每次完整仓库运行花费数百美元。

为什么 loop contract 对开发者至关重要

开发者在构建 agent 框架时，本能的做法是升级基础模型或在上下文窗口中塞入更多文档。LoopArena 指出，在上下文限制成为问题之前，运行时控制策略往往才是导致失败的根源。

生产环境 loop 中常见的一种失效模式是接受过时的进度记录。Worker 声称修复了 docstring 中的一个 bug，而 supervisor 在没有运行测试套件的情况下就终止了。另一种失效模式是 loop thrashing：worker 在两个冲突的编辑之间来回切换，而 supervisor 盲目地报告说正在取得进展。

修复这些失效模式需要在 loop supervisor 与 worker 之间执行严格的 contract 强制：

Enforce verification gates：在将任何子任务标记为完成之前，要求明确的、可执行的测试通过。绝不允许 supervisor 接受 worker 的自然语言保证。

Track diff budgets：如果一个 agent 在没有改变测试状态的情况下三次修改了同一五行代码，supervisor 应该强制回滚，而不是再次下发一个自由格式的重试。

Separate observation from decision-making：向 supervisor 推送一份经过清洗的执行摘要，而不是完整的原始终端滚动记录，以保持控制决策有据可依。

The repository and evaluation code are available on GitHub at AMAP-ML/LoopArena.