从问答到控制：AI模型在循环工程中作为运行时控制器的评测之道

这两年做 AI 应用有一个很普遍的体感：模型在“问答题”上越来越强，但一旦把模型接到真实系统里让它连续干活，问题就全出来了——比如让 Agent 修一个线上故障，它改了一次配置，服务恢复了几秒，随后又被自己改崩；或者让它写补丁，第一轮看起来合理，第二轮把它刚改过的那行代码又回滚了。

这类问题用传统评测很难暴露。静态问答只考核“最后一次输出对不对”，程序生成评测又往往只考核“离线生成的代码能不能过用例”。可真实的 AI 工程正在往前走一步：模型不再是“给一个答案就结束”的生成器，而是被放进一个循环里，成为观察系统状态、决定下一步动作、执行修改、再观察结果的运行时控制器。

LoopArena 这个基准主题要讨论的，正是“模型作为循环工程的运行时控制器”该如何评估。这篇文章会先讲清楚这几个概念到底指什么，再对比它和传统 AI 评测的差别，然后落到实际工程里：一个运行时控制器需要具备什么能力、评测任务怎么设计、有哪些容易被忽略的坑。

先说明一点：本文是根据现有公开主题信息写成的技术解读，而不是对 LoopArena 官方文档的逐字翻译。涉及具体数据集规模、官方排行榜数值这类无法从现有材料核实的内容，文章不会去编造；我们重点讨论的是这个方向背后的技术问题和工程判断。

1. 为什么“能回答”和“能控制”是两种能力

先看一个差异。

你问一个大模型：“P99 延迟突然升高，可能是什么原因？”它能列出数据库连接池耗尽、GC 停顿、慢查询、依赖服务变慢等一串原因。这是“能回答”。

但换一个场景：把这个模型接入一个自治运维系统，它需要自己去查指标、看日志、判断当前真实状态是连接池问题还是 GC 问题，然后执行一条命令去修改配置，再等几秒看指标是否恢复。如果没恢复，它还要继续尝试下一种方案，并且在多次失败之后不能把系统改得更糟。这是“能控制”。

两者差的不是一点半点。

“能回答”对应的是知识密度和语言表达能力，这些能力通过静态问答评测就能测出大概。但“能控制”意味着模型必须在真实或高仿真的闭环环境中做决策，而决策链条上任何一环出错，都会让整体表现崩掉。

循环工程（Loop Engineering）这个名字，指的就是这种多轮迭代的工作范式。不同于“用户发一次 prompt、模型返回一次结果”的对话形态，循环工程里的模型要反复处理状态变化，逐步逼近目标状态。模型写代码、跑测试、看报错、修 bug 再跑；模型观察指标、推断原因、调参数、看效果再调；这些都是循环。

“运行时控制器”则点明了模型的角色。它不再是一个坐在旁边给建议的顾问，而是系统循环里的控制核心。它输出的是要被真实运行的动作，动作会改变系统状态，系统状态又成为它下一轮的输入。这种角色非常接近控制论里的“控制器”概念：被控对象是系统，控制器依据反馈不断调整输出，目标是让系统收敛到某个期望状态。

如果沿用这个视角，你就能明白为什么传统评测不够用：我们一直在考“模型的知识储备”，但循环工程需要的是“模型在闭环中的调节能力和稳定性”。

2. LoopArena 的三个关键词：循环工程、运行时控制器、基准

LoopArena 从名字上看有两个部分：“Loop”对应循环，“Arena”对应竞技场或评测场。合起来的意思是，把模型放进一个需要循环迭代的工程场景里去比试。

2.1 什么是循环工程

循环工程可以理解为：用模型去执行那些本来需要人类工程师反复试错、验证、修正才能完成的任务。

举几个常见类型：

• Agent 编码闭环：模型写代码，执行单测，看失败信息，再修，再执行，直到测试通过。
• 运维诊断闭环：模型读取监控指标和应用日志，判断异常类型，修改配置或执行恢复操作，确认服务是否恢复。
• 数据修复闭环：模型分析数据质量问题，生成清洗脚本，运行后校验分布变化，不理想再迭代。
• 系统参数调优闭环：模型根据输入负载和性能反馈，调整线程池、缓存参数、批处理大小等运行参数。

这些任务有一个共性：完成路径不是一次输出，而是多次“行动—反馈—再行动”。评估这类能力，不能只看中间某一步是否聪明，要看整个循环走完是否达到目标状态。

2.2 什么是运行时控制器

控制器这个概念来自控制论。空调的温控器就是典型的运行时控制器：它读当前室温，对比目标温度，决定继续制冷还是停止，然后等下一轮温度采样。

模型作为运行时控制器，承担的是同一类职责，只不过被控对象更复杂：

• 状态空间不是“室温”一个数字，而是日志、指标、配置、进程状态、代码仓等多维信息。
• 动作空间不是“开/关”，而是执行命令、写文件、发请求、改配置、调代码等复杂操作。
• 反馈有延迟、有噪声，甚至有时你无法立刻知道某个动作是对是错。
• 控制目标可能不是单一数值，而是“服务恢复可用”这类需要多维度判断的目标。

把这种控制器角色交给大模型，意味着模型不仅要理解自然语言，还要能读懂结构化状态、选择安全动作、根据反馈调整策略，并在步数或时间约束内完成任务。

2.3 为什么需要新的 benchmark

Benchmark 的本质作用，是把某种能力量化出来，让不同模型之间可以横向比较。过去我们有很多 benchmark 分别测语言理解、代码生成、数学推理等能力，但它们测的大多是“一次性性能”。

循环工程时代的模型评测，至少要回答这几个问题：

• 这个模型在闭环环境里，能靠自己的反馈修正达到目标吗？
• 它需要多少轮才能收敛？还是会在某个状态附近来回震荡？
• 遇到执行失败时，它是能换一个方向，还是会反复重试同一个错误动作？
<