LoopArena：让模型当"经理"指挥编程智能体，最强模型也只能管好四分之一的活

你有没有过这种体验：给 Claude Code 或者 Codex 派了个大活，中途离开了一会儿，回来看它信心满满地说"搞定了"，结果一跑测试——一半需求压根没动，它还顺手把一个早就过时的进度笔记当成了真理。

这其实是 2026 年 AI 编程圈最火的一个新话题：Loop Engineering。从今年 6 月 Peter Steinberger 那条八百万浏览的推文开始，行业里逐渐形成共识——人的角色不再是逐条写 prompt 的"传话员"，而是设计一个循环系统：让 Agent 自己执行、观察、评估、修正，直到目标达成。Addy Osmani 也公开描述过类似模式，PostHog 甚至用这套思路在生产环境里跑出了一个抓出三年陈年老 bug、性能提升 11% 的自动化循环。

但问题来了。大家都在搭 loop，这个 loop 里的"大脑"到底行不行，没人量过。一次端到端跑完，成了还是败了，你分不清是"指挥官"指导有方还是"干活的"本身能打。LoopArena 这篇论文（arXiv: 2608.28281）干的就是这件事：把"模型当经理"这件事从玄学变成可测量的对象。

核心摘要：Loop Engineering 正成为组织编程智能体的新范式，但单次运行的成败无法归因于循环的指导还是执行者的能力。LoopArena 把被评估的模型放在 Controller 的位置上——它不碰代码，只能在每轮结束后读一份结构化的证据摘要，然后指挥一个固定的 Worker 智能体下一步干什么、验证什么、或者收工。基准设计了三种互补的评估形态，成本从几乎为零到完整执行。结果相当扎心：最强的 Controller（GPT-5.5）在完整任务上的严格成功率只有 24.69 个点，而"每轮重述一遍原始目标"这种朴素策略在完整任务上跟完全不管一样烂。我的判断：这不是一篇刷榜论文，而是一次很扎实的测量学工作——它把一个行业正在押注的方向，第一次摆上了可以量化的手术台。

📖 论文信息

  • 标题：LoopArena: Benchmarking Models as Runtime Controllers for Loop Engineering
  • 作者：Yi Wang, Haopeng Zhang, Chengxiang Huang, Rui Dai, Kaikui Liu, Piotr Koniusz, Xiangxiang Chu
  • 机构：DreamX Team / Alibaba Group、北京邮电大学、UNSW Sydney / Data61, CSIRO
  • 发表：2026 年 8 月 28 日（arXiv: 2608.28281）
  • 代码与数据：https://github.com/AMAP-ML/LoopArena

🎯 为什么需要这篇论文：loop 的锅，到底谁来背

现在搭一个编程 Agent 的外层循环，工程师基本靠手感。信任哪份进度报告、什么时候该让 Agent 停下来跑验证、什么时候该收工提交——这些决策散落在各种 harness 脚本里，没人说得清好坏。

论文把失败模式列得很直白，我逐条翻译一下，做 Agent 的朋友大概率每条都中过枪：

  • 信任过时的进度笔记——状态早就变了，循环还在按昨天的记录决策；
  • 跳过必要的验证——一个狭窄的检查过了，另一个需求压根没人碰；
  • 预算花错方向——在不重要的分支上疯狂烧 token，主线没推进；
  • 提前收工——任务还远没安全到可提交的程度，loop 自作主张停了。

更麻烦的是归因问题。现有的编程基准，从 SWE-bench 到长周期的 SCBench，评估的都是"代理系统整体"。跑完一个任务，成功或失败，你没法拆开看：是外层的指导策略蠢，还是里面的编程 Agent 手潮？

LoopArena 的思路很直接：把 Worker 钉死，只换 Controller。Worker 固定为同一个模型（Qwen3.7-Plus）、同样的工具、同样的评估器，被评的模型只负责一件事——当经理。

🏗️ 方法核心：Controller 没有手，只有嘴

图1：LoopArena harness 架构

图1：LoopArena 的双层循环架构。上半部分是 Controller 引导的条件：Worker 在内层跑原生 ReAct 循环（Observe → Reason → Act → 改仓库），每段结束后由一个临时的只读 Reporter 总结进度并引用证据，harness 确定性地打包成 Evidence Packet 交给 Controller，Controller 返回 Loop Contract 决定下一步。下半部分是无控制参照组：同一个 Worker 从同一个冻结的任务状态出发，不受打扰地一口气跑完。两边共享同一个任务评估器判 PASS/FAIL。

这个架构里有个设计我觉得挺漂亮的：Controller 没有任何编程工具。它影响任务的唯一途径是发给 Worker 的指令。这从机制上保证了评估对象足够纯粹——Controller 没法自己上手改代码作弊，只能靠"管理水平"赢。

每个控制循环长这样：

  1. Worker 干完一段活，交还控制权；
  2. Reporter 出场：从 Worker 对话的副本创建一个临时只读代理（同模型配置），产出四段式报告——任务上下文、已完成工作与当前状态、可用的验证证据、遗留问题。关键约束是"实质性论断必须引用对应的 Worker 轮次"，防止报告漂在空中；
  3. harness 打包成 Evidence Packet：确定性格式化，只读；
  4. Controller 决策：读证据包和自己的历史，产出 Loop Contract：
\[c_{i,k} = \pi(x_{i,k}, h_{i,k})\]

Loop Contract 是个结构化决策，action 三选一：advance（推进）、verify（验证）、stop（收工）。选 advance 或 verify 还得写清楚 worker_instruction——目标、上下文、要求的结果、禁止的操作、完成条件，外加保护性不变量和验收标准。说实话，这个 schema 本身就值得做 Agent 编排的人抄一抄，比随便写一句"继续搞"严谨太多了。

  1. 执行或终止：继续的话 Contract 被渲染成 Worker 持久对话里的下一条 user 指令；停止的话工作区直接交给任务评估器。

还有两个参照策略，用来回答一个朴素的问题：有指导是不是总比没指导强？

  • No control：Worker 拿到任务后自主跑到完，没人管；
  • Fixed control：受 Codex /goal 启发的持久目标基线——每个控制点确定性地重述一遍原始任务目标，不看证据、不做适配。

运行预算也给得很足：Worker 单 episode 上限 600 个 ReAct 轮次或 7200 秒；Controller 引导执行最多 128 个控制循环。触限直接判任务失败。

📐 三种评估形态：从一道选择题到跑完整个任务

图2：三种评估设置的构造

图2：三种设置的构造方式。左侧是素材来源：真实编程任务的仓库和 Controller 引导的轨迹。Type I 从一个可恢复的控制点出发，给 Controller 一份 Evidence Packet 和 A/B/C/D 四个候选 Loop Contract，问"下一步该发哪条"——正确答案在构建期通过重放执行预先验证，评估时完全不用跑代码。Type II 从准备好的中间工作区起步，让 Controller–Worker 循环完成任务的下一个切片。Type III 从原始状态跑完整任务，是最贵也最接近真实场景的形态。

这三种形态在执行范围和评估成本上互补，我整理成一张表：

设置 执行范围 评分方式 评估时跑 Worker 吗
Type I 契约选择 单个控制决策 四选一 Contract Accuracy 不跑（成本前移到构建期）
Type II 精简任务 任务的一个切片（从中间工作区起步） 严格成功率 + 估计成本 跑
Type III 完整任务 从原始状态跑全程 严格成功率 + 估计成本 跑

Type I 的构建流程值得一说，因为它解决了一个选择题基准的通病——答案不能是作者拍脑袋定的。做法是：从真实轨迹里采样控制点，记录的 Contract 只是候选之一（不预设为正确答案），再由人写三个完整且合理的干扰项，四个候选冻结之后，从同一个恢复状态用两套预先声明的重放计划全部执行一遍，种子分别为 \(S+1{,}000{,}000\) 和 \(S+2{,}000{,}000\)。只有两套计划都认定同一个唯一赢家的题目才被保留。执行重放定答案，这个做法把"哪个决策更好"从主观判断变成了可执行的实验。

评分上，Type I 用 Contract Accuracy：

\[\operatorname{Acc}_{\mathrm{I}}(\pi)=\frac{1}{N_{\mathrm{I}}}\sum_{q=1}^{N_{\mathrm{I}}}\mathbf{1}\!\left[\widehat{j}_{\pi,q}=j_{q}^{\star}\right]\]

Type II/III 每个任务跑 \(K=3\) 次，严格成功率 SSR 要求既通过任务评估器、又遵守控制协议。成本按冻结的公开价格表逐次调用累计（无缓存假设）。

数据集方面：90 道 Type I 问题、27 个 Type II–III 配对任务，来自两个互补的来源——SCBench（长周期迭代编程）和 BeyondSWE（超越单仓库 bug 修复的软件工程任务）。规模不算大，说实话这是我看到 Table 1 时的第一反应。但想想每个 Type III 任务要跑 3 次、每次 140 到 289 个 Worker 轮次，这个规模对应的算力消耗已经不小了。

📊 实验结果：经理不好当

主实验测了 5 个 Controller 模型，全量结果如下（Type I 为准确率，Type II/III 为严格成功率和每次运行的估计成本）：

方法 Type I Acc. ↑ Type II SSR ↑ Type II 成本 ($/run) ↓ Type III SSR ↑ Type III 成本 ($/run) ↓
No control（参照） — 39.51 1.04 18.52 2.01
Fixed control（参照） — 46.91 1.08 18.52 5.58
Qwen3.7-Plus 72.22 48.15 4.30 23.46 6.89
DeepSeek-V4-Flash-0731 77.78 45.68 2.10 19.75 10.24
GLM 5.2 74.44 37.04 1.63 16.05 4.86
GPT-5.5 87.78 51.85 5.00 24.69 的最高值 18.84
Claude Opus 4.8 76.67 48.15 5.87 20.99 16.82

几个发现值得展开聊。

长周期循环控制，离"能用"还很远。 Type III 上所有模型都落在 16.05% 到 24.69% 之间。最强的 GPT-5.5 也只有 24.69 个点——换句话说，当前最好的模型当经理指挥一个固定 Worker 跑完整编程任务，四次里败三次。这个数字对正在押注"全自动 loop"的团队应该是个冷水澡。

Fixed control 的结果是我觉得全文最有信息量的一行。 每轮重述原始目标，在 Type II 切片上把成功率从 39.51% 拉到 46.91%，涨了 7.4 个点；但在 Type III 完整任务上，跟完全不管一模一样——都是 18.52%。更要命的是，fixed control 在 Type III 的成本从 2.01 美元涨到 5.58 美元。花了将近三倍的钱，买了零收益。

这就是关键。坚持目标不等于管理。短切片上，反复提醒目标确实有用，因为状态空间小，Worker 不太会跑偏；任务一长，运行状态在实现、验证、恢复、停止之间反复切换，不看证据的"复读机式管理"就彻底失效了。论文的结论是：有用的循环控制必须适应不断演化的运行状态，而不仅仅是坚持一个目标。我之前项目里也踩过类似的坑——给 Agent 加了个每轮重述 system prompt 的机制，短任务上立竿见影，长任务上纯烧 token。看到这篇论文把这个现象量化出来，还是挺爽的。

Type II 是个合格的低成本平替。 两个数字支撑这个结论：Type II 相对配对的 Type III，估计推理成本平均降 64.4%；而两种设置给出的 Controller 排序 Spearman 相关系数 \(\rho = 0.9747\)——10 个模型对里 9 个严格定序的无一反转。对日常迭代来说，用 Type II 筛模型、关键节点再跑 Type III 确认，是个性价比很高的评估策略。

Type I 的成绩单揭示了个体决策差距。 Contract Accuracy 从 Qwen3.7-Plus 的 72.22% 到 GPT-5.5 的 87.78%，所有模型 0% 的 Invalid Rate。更重要的是捷径检验：最强的确定性浅层捷径（uniform choice、只看 action、候选长度、词汇重叠这些）只到 31.11%，离最弱的 Controller 还差得远。说明这些题真需要理解证据，没法靠表面特征蒙。

也有让我皱眉的地方。成本这列有点反直觉：GPT-5.5 和 Claude Opus 4.8 的成功率是上去了，但 Type III 每次运行成本分别是 18.84 和 16.82 美元，是 GLM 5.2 的近四倍。如果你按"每美元买到的成功"算，故事就没那么一边倒了。论文没直接给这个效率指标的排名，有点可惜。

另外说句坦率的：Worker 固定为 Qwen3.7-Plus 这个设计保证了可比性，但也留下一个没回答的问题——换一个更强或更弱的 Worker，Controller 的排序还稳不稳？manager 和下属的能力搭配效应，论文明确说留给未来了。

🔬 质量控制：这份基准下了不少笨功夫

基准论文最怕的是"题出得烂"。LoopArena 在这方面做的几件事值得点名：

  • 防泄漏检查：模型可见的输入排除了官方解代码、私有评分输出、后续轨迹事件；
  • 答案稳定性：Type I 题目要求两套重放计划认定同一赢家才保留，被拒的题不允许事后修补候选；
  • 运行稳定性：Table 14 统计了三次重复中成功次数为 0/1/2/3 的任务分布，直面 LLM 运行的方差问题；
  • 冻结审计：冻结后做 LLM 辅助与专家审计，但审计不能改变重放定义的答案——这个"审计不许改答案"的纪律挺少见的。

💡 我的判断

这篇论文最值钱的地方，不是某个模型又刷了什么分，而是它定义了一个此前不存在测量对象的评估轴。

Loop Engineering 今年被炒得很热，但热度基本停留在工程经验和推文层面。LoopArena 把"模型当经理"拆成了可测量的能力：读证据、发指令、知进退。而且三档成本的设计很务实——不是所有团队都烧得起每次 18 美元的全量评估，Type I 几乎免费、Type II 便宜六成多、排序还基本保真，这套梯度设计让基准真的能被日常用起来。

批判两句。一是 27 个 Type II/III 任务的规模偏小，单任务方差对排名的影响需要警惕，论文自己也用稳定性分析间接承认了这点。二是评估对象目前局限在仓库级编程任务、单一 Controller–Worker 结构，多 Worker 编排、其他软件领域都还没覆盖——不过作者在第 7 节老老实实地承认了这些，没有过度包装。

对工程实践的启发，我给三条：

  1. 别指望"重述目标"救长任务。Fixed control 在完整任务上的失效说明，loop 的决策必须基于当前证据做状态自适应。你 harness 里如果只有 goal restatement，趁早升级。
  2. Controller 输出要有 schema。Loop Contract 那套字段（goal / required_outcomes / prohibited_actions / completion_condition / protected_invariants）直接抄进你的编排系统，比自由文本指令稳得多。
  3. 评估分层做。日常迭代用便宜的设置，里程碑再跑全量——这既是这篇论文验证过的方法论，也是控制 token 预算的现实需要。

长周期 Agent 的"管理水平"第一次有了标尺，而这个标尺现在指向的读数是：刚够到四分之一。这既是坏消息，也是好消息——坏消息是全自动编程 loop 离可靠还远，好消息是这个方向有了可量化、可比较的进步通道。

觉得有启发的话，欢迎点赞、在看、转发。跟进最新AI前沿，关注我