一个编码能力再强的模型，如果没人知道什么时候该让它掉头、什么时候该验证结果、什么时候该叫停，它也可能在复杂的开发任务里越走越偏。这是新基准 LoopArena 提出的核心观点：管理编码循环的“控制器”模型，和写代码的“工人”模型，是两码事，得分开评测。

把“管理”单独拎出来考

打开网易新闻 查看精彩图片

LoopArena 的做法很直接：固定住写代码的 Worker 模型，只换负责调度和决策的 Controller 模型。在这个基准里，Worker 被固定为 Qwen3.7-Plus，而 Controller 负责决定 Worker 下一步该干什么——是继续实现功能、验证代码、修复问题，还是干脆停下来。

这样一来，评测的焦点就从“谁会写代码”转移到了“谁会指挥写代码”。一个模型哪怕代码写得再好，如果 Controller 不懂审时度势，整个系统的表现依然会崩。

结果：最强控制器也只有24.69%成功率

在完整的 27 个任务跑分中，表现最好的 Controller 是 GPT-5.5，但它的严格成功率也只有 24.69%。这个数字说明，即便是目前最强的控制器，在管理多轮编码循环这件事上，依然有巨大的提升空间。

更值得玩味的是对照组：如果每一轮都只是简单地把最初的目标重新陈述一遍，这个“复读机”策略也能拿到 18.52% 的成功率——和完全不给任何控制、让 Worker 自己撒欢跑的结果一模一样。换句话说，瞎指挥和不管，效果差不多。

有效的控制必须“看菜下饭”

LoopArena 的结论很明确：有用的控制必须根据任务进行中不断变化的证据做出反应。Controller 需要在实现、验证、恢复和停止这几个状态之间灵活切换，而不是机械地重复“继续干”。

这个发现对评估 AI 智能体系统有直接启示：在评测一个智能体系统时，应该把负责管理循环的模型和负责写代码的模型分开来单独打分。否则，一个平庸的 Controller 可能会拖垮一个顶尖的编码模型，而问题出在管理层，却让执行层背了锅。

为什么这对你很重要

如果你正在用 AI 编码助手处理复杂项目，这个基准提醒你：别只看写代码那个模型有多强，更要看驱动它的“大脑”会不会在关键时刻喊停、纠偏。毕竟，一个只会埋头写代码的 Worker，配上不懂管理的 Controller，结果可能还不如让它自己跑。

这项研究来自 arXiv 论文《LoopArena: Benchmarking Models as Runtime Controllers for Loop Engineering》，目前已在 arXiv 上公开。