LoopArena：调度与写码拆开测的基准，最强也只跑通四分之一的长任务

不再写 prompt，改设计循环——这层新实践凭什么值得单独评测

2026 年 6 月，Anthropic Claude Code 团队负责人 Boris Cherny 在 X 上丢出一句话：我不再写 prompt 提示 Claude 了，跑着的是替我提示 Claude、替我决定该做什么的循环，我的工作变成了写循环。讲同一件事的还有 Peter Steinberger：你不该再给编码 agent 写提示了，你该设计循环去提示你的 agent。两个人说的不是同一个产品，指向的却是同一个转向：开发方式正在从"逐条喂指令"切换到"设计一个会自己喂自己的系统"。

6 月 7 日，前 Google Cloud AI 总监 Addy Osmani 把这条话语线整合成一套实践，以"Loop Engineering"为题发布在他的个人工程博客上。他给出三层递进：prompt 是你一次敲一句、agent 回一句；harness 是你给一个 agent 造好运行环境；loop 是在 harness 之上，让这个环境按计划自己驱动自己，定时醒来、派活、复检、续跑。Codex 的 /goal、Claude Code 的 /loop 和 /goal 已经把这些原语做进了产品里。Osmani 博客

在博客里，一个最小 loop 的日常是这样的：早晨一条 automation 把昨晚的 CI 失败、open issue 扫进 triage；值得做的 finding 开一个隔离的 worktree，第一个子代理在里面起草修复，第二个子代理拿着项目 skills 和现有测试复审；连接器自动开 PR、更新 ticket；一天结束时，所有"试过什么、过了什么、还卡在哪"写进状态文件，让明早的 run 从今晚的位置接着跑。整条 loop 的脊椎是那个状态文件，因为模型每次运行都会忘事，记忆必须落在磁盘上，不能放在上下文里。

但写循环不等于写对了循环。论文摘要把 loop 的失败方式列成四种：信任一份过期的进度记录、跳过该做的验证、把预算花错方向、在任务还不安全时就停机。一个手写的循环完全可能同时犯这四种错，而这四种错都发生在"调度"这一层，不在写代码那一层。LoopArena

于是问题来了。开发者从"写 prompt"转向"设计循环"之后，循环指挥得怎么样，成了一个值得被单独验收的对象。可怎么验收？先得看看传统 benchmark 给出的答案是什么。

一次运行的成败，该记在循环名下还是写码名下

假如你手上有一个编码 agent，一次长任务失败了。失败该记在谁的头上，是循环引导得不好，还是 Worker 写代码的能力不行？在绝大多数 benchmark 里，这个问题没有答案，因为分数把两边绑在一起。

SWE-bench 是这条范式的地标：2,294 个源自 12 个 Python 仓库的真实 issue，模型读 issue 描述和仓库快照，产出 patch，patch 应用成功且相关测试通过才算 resolved。这听起来干净，但一个 SWE-bench 分数是模型、检索器、上下文处理、patch 应用、测试执行共同的功劳。任何排行榜上的数字都同时背着 harness 和模型两边的成败，拆不出任何一环的独立贡献。SWE-bench

拆不开的后果是：分数再高，你也不知道该表扬谁、该训练谁。而且长程任务的难度是真实的，不是学术洁癖。SlopCodeBench 专门测"agent 在多轮迭代下写出的代码"，36 道题没有任何 agent 完整跑通，最强的 GPT-5.5 严格通过率也只有 14.8%，且代码质量随迭代退化，结构侵蚀在 77% 的轨迹里上升。写码这一侧，是会越写越烂的。SCBench

BeyondSWE 把任务难度再推一档：500 个实例、246 个真实仓库，覆盖跨仓库、跨领域、依赖迁移、从文档生成仓库四类任务，绝大多数前沿模型的平均分只落在 41 到 48 区间。任务本身难，agent 又会在迭代中退化，所以把"引导"从"写码"里剥出来测，就不是理论洁癖，而是现实需求。BeyondSWE

训练侧的 SWE-Gym 也在这条脉络上，它把 2,438 个真实可执行任务变成训练环境，走的是"训权重"的路；LoopArena 走的是"评决策"的路。两条路共享同一个前提：真实任务才能当信号。SWE-Gym

所以结论是：高分不等于好引导，因为分数拆不开账。要把"引导"从"写码"里剥出来测，就得把一边固定住。那到底固定哪一边？答案是执行端。

把调度从写码里拆出来：只动嘴、不动手的 Controller 如何工作

LoopArena 的双角色拆分只有一句话：Worker 是唯一能改仓库的执行者，Controller 是没有任何 coding tools 的调度者，只负责看证据、下指令。Worker 的内部不是新发明，就是它自带的 native ReAct 循环，思考、行动、观察三拍交替，这是 ReAct 立下的范式。ReAct

要让"只看不动的 Controller"真的有信息可看，中间要过两道工序。每轮 Worker 改完代码后，一个临时的 Reporter agent 用只读工具检查工作区，汇总"改了什么、验证到什么状态、还卡在哪"，harness 把这个汇报确定性格式化成四段的结构化摘要，也就是 Evidence Packet（证据包）：任务上下文、已完成与当前状态、可用的验证证据、遗留问题，关键事实附上对应的 Worker 回合编号。Controller 读到的就是这份证据加历史记录，然后输出一个 Loop Contract（循环契约），下一步动作三选一：继续执行下一段、请求验证、停止。harness 再把这次选择渲染成下一段 Worker 的 prompt，Worker 接着跑它的内循环。每一步都是确定性格式化的，Controller 的输出没有自由发挥的空间，这让"调度决策"第一次成了一个干净、可评测的接口。LoopArena

这套结构最值得注意的是图里的右半边。同一次任务、同一个 Worker、同一套工具、同一个起点，跑两遍：一遍让 Controller 每轮接管引导，一遍让 Worker 从头自己跑到底。两边唯一的差别是有没有 Controller。正是这个同起点对照让归因成立：如果结果不一样，差异只能记在调度头上。

图注：论文 Figure 1 的 harness 结构。左半 guided 分支里，Worker 每轮结束由临时 Reporter 汇总，harness 确定性格式化成 Evidence Packet，Controller 读取后发出 Loop Contract，再回到 Worker 开启下一段；右半 no-control 分支让 Worker 自行跑到底。两侧共享同一任务起点、Worker、coding tools 与 task evaluator。LoopArena

Controller 无工具是刻意设计，工程上的直觉叫 maker-checker 分离，写码的人和判定的人不能是同一个人。论文参考策略 fixed-control 的灵感正是 Codex 的 /goal——让目标持久化、每个控制点确定性复述而不随证据调整。但"干净"只在单轮成立：证据包能不能让 Controller 跨过一百多个轮次持续做出对的判断，就要看评测怎么设计了。

怎么低成本地测一个"只做判断"的调度者：三档评测的广度与成本取舍

把"调度决策"评测出来，最大的对手是钱。一遍完整长任务要跑 140 到 289 个 Worker turn，烧的是真金白银。LoopArena 的解法是给执行广度做三档，让评测者在真实性和成本之间自己挑。

Type I 是单点决策：在一个冻结的控制点上给出 Evidence Packet 和四个候选 Loop Contract，让 Controller 四选一。评测时根本不跑 Worker，正确答案在 benchmark 构造期靠回放四个候选预先算好，新 Controller 进来只需要在 90 道题上各答一次。Type II 是任务切片：从准备好的中间工作区出发，让 Controller 和 Worker 配合跑完一段连贯阶段，单轮 51 到 80 个 Worker turn。Type III 是完整任务：从原始状态一路跑到验收，140 到 289 个 turn。一档比一档真实，也一档比一档贵，多花的钱买的是更真实的控制行为。LoopArena

图注：论文 Figure 2 展示三种任务形态的构造。Type III 从原始状态跑完整任务，Type II 从准备好的中间工作区出发跑同一任务的切片，Type I 在可回放控制点上构造四选一；从左到右执行广度与评测成本递增，Type II 与 Type III 一一配对。LoopArena

三档在题量上是 90 / 27 / 27。Type I 的 90 题来自 SlopCodeBench 的 40 题加 BeyondSWE 的 50 题；Type II 和 Type III 各 27 题，都从同一批 27 个来源任务构造，Type II 与 Type III 一一配对、共用同一个 source task。这道配对工序是后面的成本对比和排序对比能成立的前提，没有配对，切片档和完整档就是两套不相干的题。LoopArena

选这两家素材不是随手的。SlopCodeBench 把每道题切成多个原生 checkpoint，天然适合当任务切片的起点，它的 Core check 也被直接用作主评分准则；BeyondSWE 提供超出单仓 bug fix 的跨仓库、跨领域任务，而且官方 Harbor evaluator 自带独立容器，验收标准现成可用。SCBench BeyondSWE

但便宜档真的能给出和完整档同样的结论吗？这要看了数字才知道。

最强的调度者也只跑通四分之一的长任务：三档各自测出了什么

先看评分口径。Strict Success Rate 的定义要先说清楚：SSR=成功 run 数÷（任务数×K=3 次重复），每次 run 单独判定成败、跑通的 run 都计入；SlopCodeBench 侧要求 Core check 全过，BeyondSWE 侧要求官方 Harbor evaluator 给出 reward=1，是单次 run 的成败标准。

主结果在下面这张从论文 Table 2 重建的简表里。五个 Controller 共享同一个 Worker（Qwen3.7-Plus，所有 Type II / III run 统一使用），成本是估算推理成本，不是用户账单。

*每 run 估算推理成本，口径为 provider 公布的 list-price，不应用 prompt caching / batch / 折扣，价格冻结于 2026-08-16。LoopArena

这张表里藏着三个反差。

第一，Type I 不是 trivial 多选。五个 Controller 的决策准确率从 72.22% 到 87.78%，所有回答都解析成单一候选，Invalid Rate 为 0；而最强的确定性 shortcut（Majority position，只按答案位置多数选）也只有 31.11%，比最弱的 Controller 还低一大截。只看证据做一次四选一，本身是有信息量的能力。

第二，也是最扎心的：单点强不等于长程稳。GPT-5.5 在 Type I 上拿到 87.78%，到 Type III 只剩 24.69%，也就是四次里跑通一次多。五个 Controller 的完整任务 SSR 全部落在 16.05% 到 24.69% 之间，最强的也只跑通四分之一。长程控制不是缺一点，是缺一大块。这组数字证明，单点选择题再强，也预测不了跨一百多个轮次的持续引导能力。LoopArena

第三，重复目标能救切片，救不了完整任务。对照组的玩法是：no-control 让 Worker 一次性拿任务自己跑，fixed-control 每轮确定性复述原任务目标、不看证据。在 Type II 上，fixed-control 把 39.51% 提到 46.91%，提升 7.4 个百分点；到 Type III，两条线都停在 18.52%，一动不动。翻译成工程语言：周期性重申目标，约等于顺手给 agent 重发一遍 /goal，在短程切片上有效，完整任务上则和没有控制一模一样。

再看成本和排序。五个 Controller 的 Type II 相对配对的 Type III，估算推理成本平均下降 64.4%。更重要的是序：在 Core 准则下，Type II 的 Controller 排序与 Type III 高度一致，Spearman ρ=0.9747，9 对严格排序无一处反转。低成本档排出的序可以信，绝对分数仍以完整档为准。评测这件事本身，便宜下来了。LoopArena

同期有个旁证：LoopsBench 用完整 loop 配置测出最强组合 25.00% 的 Resolve Rate，和 24.69% 落在同一量级。两个 25% 的含义并不一样，这个留到最后一章说。

两种评测范式撞出同一个 25%：这套方法能搬到哪里、卡在哪里

LoopsBench 是 2026 年 7 月微软主导发布的同期基准，112 道题，每道题是一张依赖 DAG，合计超过 5,300 个开发单元。它评测时把完整 loop 配置，也就是 harness 加模型加 loop 实现，当作一个不可分的整体端到端地测，最强的 Opus-4.7 加上 Claude Code 和 outer continuation 也只有 25.00%，去掉 outer continuation 立刻掉到 16.96%。LoopsBench

两种范式怎么切评测对象，从这张流水线图里能看出一半：LoopsBench 把任务构造成依赖图接进 flow-aware runtime，让整条流水线自己跑，评测对象是"整套配置"。

图注：LoopsBench 的构造与评测流水线。左侧 Task Collection 汇集课程作业、PR 序列、研究演化三类真实来源，中段是预处理与筛选，右侧汇聚成统一的评测入口，并注明已完成的节点会成为下游的回归义务。LoopsBench

LoopArena 做的则是把 loop 拆开，固定 Worker、只换 Controller，单独定位调度者的决策质量。所以两个 25% 不是同一件事的两次测量：25.00% 与 24.69% 分别是这两项实验中所测配置和 Controller 的最佳结果，两者评测对象不同，不可直接比较，也没有谁赢谁输。但两条独立路径撞出同一个量级，本身也提示长程 loop 控制仍可能是重要瓶颈。

这套做法本身是可迁移的：固定 Worker、只换 Controller、用切片档迭代、完整档验收。手里预算有限的话，Type II 这种切片档可以先用起来做排序，完整档留给关键版本验收。而实验也顺手戳破了一个流行的偷懒姿势，以为周期性给 agent 重申目标就是 loop engineering。fixed-control 在完整任务上纹丝不动的 18.52% 就是答案，调度必须随证据调整，不能靠复读。

论文自己划了三条边界：只覆盖仓库级编码任务；只评测单一 Controller–Worker 结构，多 Worker 配置没有做；三档设计推广到非编码域，需要领域专属的任务构造和可执行 evaluator。成本数字依赖 list-price / no-cache 口径，结果限定在 arXiv v1 和 release v0.1.0。LoopArena

把这条线往回看，LoopArena 真正做的是一件事：把"调度能力"从黑盒式的系统分数里解放了出来，让开发者和研究者终于能指着一次失败的运行说，这笔账记在循环头上。"最强也只跑通四分之一"不是这次评测的终点，而是下一轮要填的起点：Controller 的训练、多 Worker 的协作，都得从这个 25% 量级的缺口开始补。

想深入可以读原文：LoopArena: Benchmarking Models as Runtime Controllers for Loop Engineering，arXiv:2608.28281。

参考文献

• LoopArena: Benchmarking Models as Runtime Controllers for Loop Engineering（arXiv:2608.28281）: https://arxiv.org/abs/2608.28281
• SlopCodeBench: Benchmarking How Coding Agents Degrade Over Long-Horizon Iterative Tasks（arXiv:2603.24755）: https://arxiv.org/abs/2603.24755
• BeyondSWE: Can Current Code Agent Survive Beyond Single-Repo Bug Fixing?（arXiv:2603.03194）: https://arxiv.org/abs/2603.03194
• LoopsBench: From Harness Engineering to Loop Engineering in Coding Agent Evaluation（arXiv:2608.00267）: https://arxiv.org/abs/2608.00267
• Loop Engineering（Addy Osmani 工程博客）: https://addyosmani.com/blog/loop-engineering/
• SWE-bench: Can Language Models Resolve Real-World GitHub Issues?（arXiv:2310.06770）: https://arxiv.org/abs/2310.06770
• Training Software Engineering Agents and Verifiers with SWE-Gym（arXiv:2412.21139）: https://arxiv.org/abs/2412.21139
• ReAct: Synergizing Reasoning and Acting in Language Models（arXiv:2210.03629）: https://arxiv.org/abs/2210.03629