不知道大家有没有遇到过这样一种情况用大模型做自动化编程、线上排查、运维处置的时候单轮问答看起来什么都会但一旦把它放到真实任务里让它自己反复试错、修改命令、观察日志、再继续执行模型的表现往往会断崖式下降。它会绕圈子、重复同样的错误命令、把上下文窗口塞满、甚至在一半的时候“忘记”最初目标。这其实是当前大模型评测的一个盲区我们太习惯用“单轮输出对不对”来衡量模型却很少用“模型能否在一个循环里持续做运行时控制”来衡量它。LoopArena 这个名字所代表的基准方向就是为了弥补这个缺口而出现的它把大模型当作一个循环工程Loop Engineering里的运行时控制器来评测而不是当作一个“问你一句、答你一句”的聊天机器人。这篇文章会从概念拆解开始讲清楚什么叫“循环工程”什么叫“运行时控制器”以及 LoopArena 这类基准到底在测什么然后我会带大家设计一个最小可复现的评测框架用 Python 写一个简易 Runner让你也能在本地跑通“模型循环决策”的评测流程最后会补充常见坑点、指标设计思路和工程化建议。不管你是做 LLM Agent 应用开发、模型选型评测还是对 benchmark 设计感兴趣这篇内容都应该对你有帮助。1. 背景与核心概念1.1 从“单轮对话评测”到“循环工程评测”传统的大模型评测核心形式是“给一个问题模型输出一个答案然后对比标准答案”。这种评测方式非常适合问答、翻译、摘要、代码生成等场景因为任务边界清楚结果可以离线判定。但在真实工程环境里模型的使用方式早已变了。现在的典型用法是让模型扮演一个自主执行者在终端里执行命令、读取报错、修改文件、重新运行测试反复迭代直到任务完成。这种“观察环境 → 决策动作 → 执行动作 → 观察新状态”的过程不是单轮问答而是一个闭环控制过程。我习惯把这类场景统称为循环工程Loop Engineering。它的关键特征有四个多轮执行模型不是只输出一次结果而是连续输出多个动作。环境反馈每一步动作都会产生新的输出、报错、日志或状态变化。目标持久性模型需要在整个执行过程中保持对最终目标的记忆。错误恢复执行失败时模型要能根据反馈修正策略而不是反复撞墙。从控制论的角度看模型在这里不再是“知识问答器”而是整个执行循环的运行时控制器runtime controller。它的输入是目标、历史和观测状态输出是下一个动作。评测这种能力和评测“单轮答题”是完全不同的两套方法论。1.2 什么是“运行时控制器”“运行时控制器”这个词听起来有点抽象我们可以把它和传统软件架构做类比。在一个 Web 服务里控制器负责接收请求、调用业务逻辑、返回响应。它处于“用户意图”和“系统资源”之间是调度中枢。现在当我们说“大模型作为运行时控制器”意思是让大模型充当人、工具、代码执行环境之间的决策中枢上游输入是用户给的任务目标下行能力是它可以调用的工具比如 Shell、代码编辑器、文件读写、API 请求每一步模型都要根据当前观测到的状态决定下一步调用什么动作动作执行完环境产生新的观测模型继续决策直到满足终止条件。这种控制器的质量如何衡量传统基准评测很难回答。比如两个模型可能最后都完成了任务但一个用了 5 步且方向清晰另一个用了 30 步还反复执行了破坏性命令。单看终态都是“成功”但作为控制器的优劣一目了然。LoopArena 这类基准要做的就是把“控制器质量”拆解成可测量的多项指标。1.3 为什么需要新的基准现有 Agent 基准已经不少了比如一些工具调用类 benchmark、网页操作类 benchmark、代码修复类 benchmark。那为什么还需要 LoopArena 这样的基准我觉得最关键的一点是现有基准大多把“任务是否能完成”作为核心指标对执行过程本身的关注不足。而“运行时控制器”必须同时满足三个层面层面考察点传统基准覆盖情况任务层面最终是否解决任务覆盖较好过程层面是否高效、是否安全、是否少走弯路覆盖不足控制层面状态跟踪、反馈理解、恢复策略、长程记忆很少覆盖LoopArena 的核心价值就是把“过程质量”和“控制质量”放到和“任务成功率”同等重要的位置。它鼓励我们思考如果模型在一个循环里反复出现同样的错误那么再强的单轮生成能力也无法转化为可靠的自动化执行。另外一个值得强调的背景是现在很多 Agent 应用为了追求成功率会叠加复杂的提示词、外部规划器和人工兜底。但这样的系统很难复制和评判。LoopArena 的出现提醒我们模型本身的“循环控制能力”也需要被独立评测和持续优化。2. 评测对象与设计思路2.1 LoopArena 在测什么从基准设计者的角度出发一个模型要被当作“循环工程运行时控制器”来评测至少需要考察以下几项能力第一目标理解与保持能力。模型需要从任务描述中提取出可验证的完成条件。比如“修复测试套件中的失败用例”模型要能意识到结束标志是“pytest 全部通过”而不是“改了几个文件”。第二状态识别能力。真实环境是动态的。模型每一步看到的都是当前快照文件内容、git 状态、进程输出。它需要能从这些信息里判断“我现在离目标还有多远”。第三动作生成与工具调用能力。模型输出的动作必须是环境可以执行的合法动作。比如调用 Shell 命令时命令语法要正确改代码时代码要符合目标语言规范。第四反馈吸收与错误恢复能力。这是循环控制的核心。动作失败了模型能否从报错信息中定位根因重复出现同一错误时模型是否能意识到当前策略有问题并切换方案如果一个模型连续多次执行同一失败命令说明它并没有真正“读取”反馈。第五成本与风险管理能力。控制器运行在真实环境里每一次动作都有代价。可能有 token 成本、时间成本也可能有误删除文件、执行危险命令的安全风险。一个好的控制器应该能在低风险动作空间内完成目标。2.2 基准任务的一般形态按照这类基准的通用做法评测任务通常会被组织成一个“沙箱环境 目标描述 动作空间 终止条件”的元组。一个任务实例最少包含以下内容一个隔离的工作目录或环境一段任务目标描述一组允许调用的工具和命令白名单一个用于判断成功与否的可执行验证器一个步数预算和资源上限。在设计任务的时候任务难度通常会有梯度从“修改一行代码让测试通过”到“分析日志并定位一个隐蔽的 bug”再到“在允许范围内重构代码并保持全量测试通过”。这里需要特别注意的是所有任务都必须在隔离环境中运行避免模型执行过程中影响宿主机。这个安全约束不是可选项而是进行评测的前提条件。2.3 评价指标应该怎么设计对于这一类基准评价指标建议从四个维度展开。成功率是最基础的指标描述模型在预算内完成目标的比例。这个指标反映了控制器的“最终有效输出”。效率指标则描述模型达到成功所需的步数、Token 消耗或时间消耗。在同样的成功率下步数更少、Token 消耗更低的模型显然更适合做运行时控制器。过程质量指标关注模型是否出现重复动作、无效动作、破坏性动作。例如统计“重复错误次数”“被安全机制拦截的次数”等。鲁棒性指标关注相同任务在随机扰动下模型表现的稳定性。真实工程环境里报错信息可能有细微差别文件内容可能不完全一致一个脆弱控制器可能因为微小变化就失败。实际评测时通常不只看一个指标而是计算一个综合得分。比较常见的做法是把成功率作为门槛然后用效率指标和质量指标做加权排序。3. 一个最小可复现的 LoopArena 风格评测框架前面讲了很多概念接下来我们动手实现一个简化版评测框架。这个框架的目的不是完整复现论文而是帮助大家理解“模型循环决策”的评测过程。假设你的环境中已经有Python 3.9 以上asyncio 支持Python 3.7 默认支持一个可以调用的大模型接口比如 OpenAI 兼容 API 或本地部署模型需要测试的目标代码仓库。3.1 定义任务实例我们先定义任务的数据结构。一个任务实例应该包含任务 ID、目标描述、工作目录、验证命令、最大步数等。# 文件路径task_schema.py from dataclasses import dataclass, field from typing import Optional dataclass class EvalTask: task_id: str goal: str workspace: str verify_command: str max_steps: int 10 # 允许执行的动作前缀白名单例如 [cd , python , ls , cat , git ] action_prefixes: list field(default_factorylist) # 任务开始前的初始化命令 setup_command: Optional[str] None这里把action_prefixes作为白名单是为了减少评测风险。我们不允许模型随意执行任何命令只允许执行与任务相关的主流操作。在实际的 LoopArena 风格基准中动作空间会比这个更灵活但最小化实现时限制动作边界能让评估更容易控制。3.2 定义模型控制器接口为了支持不同模型的接入我们把“模型决策”抽象成一个接口。这样无论你接 OpenAI API、Claude API、Ollama 本地模型还是开源模型都只需要实现同一个方法。# 文件路径controller.py from abc import ABC, abstractmethod class RuntimeController(ABC): 循环工程运行时控制器接口 def __init__(self, model_name: str): self.model_name model_name abstractmethod async def decide(self, goal: str, history: list, state: dict) - str: 根据目标任务、历史轨迹和当前环境状态返回下一步要执行的动作命令。 history 格式为 [{role: assistant, content: ..., action: ..., output: ...}] state 中至少包含当前工作目录和最近输出。 raise NotImplementedError我们把它设计成异步方法是因为真实评测中模型推理、命令执行都可能耗时较长。异步结构能更自然地支持并发评测。下面给一个接入 OpenAI 兼容 API 的示例实现方便把评测框架跑通# 文件路径openai_controller.py import os from openai import AsyncOpenAI from controller import RuntimeController SYSTEM_PROMPT 你是一个运行在终端环境中的自动化工程师。 你会收到一个任务目标、历史命令记录和最近的输出。 请判断下一步应该执行什么命令。 约束 1. 每次只输出一条命令 2. 命令必须简洁且可执行 3. 如果任务已经完成输出 __FINISH__ 4. 不要重复执行已经失败且未修改策略的命令。 class OpenAIController(RuntimeController): def __init__(self, model_name: str gpt-4o-mini, base_url: str None): super().__init__(model_name) self.client AsyncOpenAI( api_keyos.getenv(OPENAI_API_KEY, EMPTY), base_urlbase_url or os.getenv(OPENAI_BASE_URL, https://api.openai.com/v1), ) async def decide(self, goal: str, history: list, state: dict) - str: messages [{role: system, content: SYSTEM_PROMPT}] # 角色信息说明 messages.append({ role: user, content: ( f任务目标: {goal}\n f当前工作目录: {state[cwd]}\n f最近一次输出: {state[latest_output][:2000]}\n f已完成步骤数: {state[step]}\n 请决定下一步动作。 ), }) # 把历史轨迹压缩后放入上下文 for item in history[-6:]: messages.append({ role: user, content: f上一动作: {item[action]}\n执行输出: {item[output][:1000]}, }) resp await self.client.chat.completions.create( modelself.model_name, messagesmessages, temperature0.2, ) action resp.choices[0].message.content.strip() return action这里有几个设计取舍值得说明历史轨迹只取最近 6 条是为了防止上下文被过长输出塞满设置temperature0.2是为了让控制器在评测时重复性更好最近输出截断到 2000 字符是为了控制 Token 成本也避免单次输出过长导致上下文溢出。如果你用的是 Ollama 本地模型只需要把客户端换成AsyncOpenAI(base_urlhttp://localhost:11434/v1)并将模型名改为本地的模型名称。比如本地拉取了qwen2.5:7b那就可以传入model_nameqwen2.5:7b。3.3 编写评测执行器 RunnerRunner 是整个框架的核心。它的逻辑很简单循环执行“模型决策 → 执行命令 → 收集输出 → 判断是否完成”。# 文件路径runner.py import asyncio import subprocess from controller import RuntimeController from task_schema import EvalTask class EvalRunner: def __init__(self, task: EvalTask, controller: RuntimeController): self.task task self.controller controller self.history [] self.success False async def run_once(self) - dict: if self.task.setup_command: self._exec(self.task.setup_command) for step in range(1, self.task.max_steps 1): cwd self.task.workspace latest_output if self.history: latest_output self.history[-1].get(output, ) state { cwd: cwd, latest_output: latest_output, step: step, } try: action await self.controller.decide( goalself.task.goal, historyself.history, statestate, ) except Exception as exc: self.history.append({ step: step, action: [MODEL_ERROR], output: f模型调用异常: {exc}, }) continue if not action or action __FINISH__: break if not self._is_action_allowed(action): self.history.append({ step: step, action: action, output: [BLOCKED] 命令不在白名单内, }) continue output self._exec(action) self.history.append({ step: step, action: action, output: output[-2000:], }) if self._check_success(): self.success True break return { task_id: self.task.task_id, success: self.success, steps: len(self.history), actions: [item[action] for item in self.history], } def _exec(self, command: str) - str: try: result subprocess.run( command, shellTrue, cwdself.task.workspace, capture_outputTrue, textTrue, timeout30, ) combined (result.stdout or ) \n (result.stderr or ) return combined.strip() or (no output) except subprocess.TimeoutExpired: return [TIMEOUT] 命令执行超时 except Exception as exc: return f[ERROR] {exc} def _is_action_allowed(self, action: str) - bool: if not self.task.action_prefixes: return True return any(action.startswith(prefix) for prefix in self.task.action_prefixes) def _check_success(self) - bool: if not self.task.verify_command: return False result subprocess.run( self.task.verify_command, shellTrue, cwdself.task.workspace, capture_outputTrue, textTrue, timeout60, ) return result.returncode 0这个实现有几个可以升级的点后面会提到。但作为最小化评测框架它已经能回答“模型能否在循环里完成任务”这个基本问题。3.4 准备一个任务示例我们可以设计一个非常简单但能体现控制能力的任务仓库里有一个脚本存在语法错误需要模型通过查看文件内容、修改代码、运行脚本最终让脚本输出预期内容。{ task_id: fix_timeout_script, goal: 修复当前目录下的 download.py使得 python download.py 能输出字符串 DOWNLOAD_OK且运行时间不超过 3 秒。, workspace: /tmp/looparena_tasks/fix_timeout_script, verify_command: cd /tmp/looparena_tasks/fix_timeout_script python download.py /tmp/verify_output.txt 21 grep DOWNLOAD_OK /tmp/verify_output.txt, max_steps: 8, action_prefixes: [ls , cat , python , sed -i , grep , cd ], setup_command: mkdir -p /tmp/looparena_tasks/fix_timeout_script }为了让任务有趣一些初始代码可以故意包含两个问题一个 import 错误一个循环结构问题。# 文件路径/tmp/looparena_tasks/fix_timeout_script/download.py # 目标任务修复该脚本最终输出 DOWNLOAD_OK import time def fetch_data(use_cache: bool): # 这里有一个 NameErrorUSE_CACHE 变量名错误 if USE_CACHE: return cache time.sleep(5) return remote def main(): data fetch_data(use_cacheTrue) print(data.upper() _OK) if __name__ __main__: main()模型在循环中需要用cat download.py查看文件发现NameError: name USE_CACHE is not defined用sed -i s/USE_CACHE/use_cache/ download.py修复再次运行脚本发现虽然不报错但运行时间是 5 秒超过 3 秒限制继续修改函数去掉time.sleep(5)或缩短睡眠最终运行验证成功。这样一个任务同时测了错误定位、代码修改、反复验证、时间约束感知等能力很适合用来对比不同模型的循环控制水平。3.5 批量运行与结果统计单个任务的输出还不能说明问题。我们需要跑多条任务、多个模型然后汇总统计。你可以先准备一个任务列表# 文件路径run_eval.py import asyncio import json from openai_controller import OpenAIController from runner import EvalRunner from task_schema import EvalTask def load_tasks(path: str) - list: with open(path, r, encodingutf-8) as f: items json.load(f) return [EvalTask(**item) for item in items] async def evaluate_model(model_name: str, task_path: str): controller OpenAIController(model_namemodel_name) tasks load_tasks(task_path) results [] for task in tasks: runner EvalRunner(tasktask, controllercontroller) result await runner.run_once() results.append(result) print(f[{model_name}] task{task.task_id} success{result[success]} steps{result[steps]}) success_count sum(1 for r in results if r[success]) avg_steps sum(r[steps] for r in results) / len(results) print(f\n模型 {model_name} 成功率: {success_count}/{len(results)}) print(f平均步数: {avg_steps:.2f}) if __name__ __main__: asyncio.run(evaluate_model(gpt-4o-mini, tasks.json))到这里你就有了一个能跑通的“模型循环控制能力”迷你评测系统。4. 评测过程中常见的坑与优化方向用这套框架评测模型时有很大概率会遇到下面这些问题我们逐个分析。4.1 模型陷入重复错误循环最常见的问题是模型在第一次命令失败之后不分析报错而是原封不动地再次执行同样的命令。在历史上表现为连续多条相同的action和基本相同的output。如果你发现自己的候选模型出现这种情况首先要看输出中是否真的包含最新报错信息。有些模型的 Prompt 设计里没有强调“结合最近一次输出调整策略”模型会把历史当成一种模板不断重复最近动作。解决方案通常有两个在 System Prompt 中加入显式约束例如“如果你要再次执行与上一次完全相同的命令必须先说明它为什么会在这次成功否则不能重复”。在评测代码里加入“重复动作检测”如果检测到连续相同动作可以记录一次repeat_penalty并且不把它计入正常步数。下面是在 Runner 中增加重复检测的示例片段def _detect_repeat(self, action: str) - bool: if len(self.history) 1: return False last_action self.history[-1].get(action) if last_action action: return True # 如果前两步动作完全一样也算重复 if len(self.history) 2: prev_actions [item[action] for item in self.history[-2:]] if prev_actions [action, action]: return True return False一旦检测到重复动作输出可以标记为[REPEAT_BLOCKED]避免模型继续用同样方式消耗步数和 Token。4.2 上下文输出过长导致 Token 截断在这个评测循环中最大的资源消耗点不是模型推理本身而是越来越长的命令输出。一个find /或cat 大型日志文件会瞬间把上下文塞满。我们已经在 Runner 中对输出做了截断到 2000 字符但这只是第一层防护。更完善的方案是对命令输出做摘要后再送入上下文记录文件路径与摘要而不是直接把全文交给模型在动作白名单中禁止可能产生超大输出的命令对单条命令输出设置预算比如超过 N 字符就停止继续读取。实际评测中经常出现“模型已经犯了错误但因为上下文里错误信息被截断模型根本不知道发生了什么”的情况。所以与其盲目截断不如设计一个专门的“信息压缩层”把输出整理成结构化片段文件修改了哪些行、测试失败用例名称、错误类型、错误位置等。这类压缩逻辑越完善模型循环决策的基础就越可靠。4.3 评测稳定性问题同一模型跑同一条任务两次结果可能完全不同。原因包括模型采样随机性、命令执行环境残留、时间因素等。提高评测稳定性的常规手段有设置temperature0或接近 0每条任务开始前使用干净容器或全新工作目录记录环境镜像的 SHA确保不同批次评测使用同一基线每条任务允许多个 Seeds 运行取多数结果固定大模型的版本避免供应商端无感升级导致波动。你可能觉得这些问题无关紧要但当你真的要用评测数据做模型选型时稳定性会直接影响决策质量。一次偶然的成功可能让一个实际很弱的模型进入候选名单这是需要警惕的。4.4 评测环境安全问题模型一旦获得 Shell 执行权限风险是真实存在的。即使我们设置了命令前缀白名单也不能保证所有命令都安全。比如sed -i可以修改任意文件rm可能删除文件python可以执行任意脚本。所以安全设计绝不能停留在“白名单”这一层。我建议至少做到以下安全底线容器隔离整个评测放在 Docker 容器中执行并禁止容器访问宿主机敏感目录网络隔离如果任务不需要联网可以使用docker run --network none文件系统备份任务开始前对工作目录做 snapshot结束后可以恢复超时熔断每条命令和整个任务都有硬性超时防止模型进入死循环命令黑名单即使不在白名单内也要额外禁止rm -rf /、mkfs、sudo等高风险命令最小授权不要在容器内使用 root 运行模型服务避免评测模型本身被当作攻击入口。安全机制的详细程度可以写一整篇文章。在评测框架这一层你只要记住一句话凡是模型能执行命令的地方都必须是可丢弃、可恢复、可审计的隔离环境。5. 从模型能力到工程落地运行时控制模型怎么选如果你不只是做测评而是想选一个模型作为真实自动化系统的“运行时控制器”那么除了跑通 LoopArena 风格评测之外还需要看以下几个方面。5.1 上下文窗口与长程记忆真实工程任务里历史轨迹往往很长。即使做了压缩控制器仍然需要在一定长度的上下文中保持连贯推理。上下文窗口更大的模型通常能容纳更多反馈信息但这不代表它一定更擅长利用这些信息。你可以设计一个“远程依赖任务”模型在第 5 步时读到一个关键线索第 15 步时需要回忆起这个线索才能完成任务。这种任务特别能区分模型的“上下文利用能力”。5.2 工具调用稳定性很多控制器通过 Function Calling 或 Tool Use 与外部环境交互而不同模型的工具调用格式稳定性差异很大。有些模型在普通对话里表现很好一到需要严格 JSON 输出动作时就会多出解释性文字导致解析失败。如果你要做工程项目优先选择在结构化输出评测中稳定的模型或者设计容错性更强的动作解析器。在代码里除了依赖模型输出严格命令外还可以提供“命令候选列表 用户确认”的折中方案但这种半自动模式已经偏离了“运行时控制器”的纯自动假设需要在实际业务中权衡。5.3 开源模型与本地部署最近很多开发者开始关注本地部署模型比如用 Ollama 部署 Qwen 系列、LLaMA 系列。对于“运行时控制器”这个角色本地模型的最大优势是隐私、延迟和成本可控。但小规模模型在复杂推理、代码修改、多步纠错上的能力仍需要谨慎评估。如果你打算在本地模型上做控制型任务建议先用第 3 节的最小框架跑一轮把成功率作为首要过滤条件。成功率太低时再多的工程优化都很难补救。我还建议在评测时对比“云端商用模型”和“本地开源模型”的差异重点观察失败模式本地模型失败往往是因为推理深度不够云端模型失败则可能是因为输出长度限制或内容安全策略。5.4 模型检查器与外部验证工具的联动在真实控制系统中你不应该让模型“裸奔”。模型即使能力很强也会在数字计算、状态统计、路径拼接等方面出错。因此运行时控制器之上通常还会叠加一层外部验证工具我们可以把它叫做带外检查器。带外检查器的作用是在模型执行之前校验语法是否正确在模型修改文件后自动运行编译或静态检查在执行删除等危险动作前做路径有效性检查在任务结束时调用独立验证脚本确认是否真正完成。在评测框架里我建议把验证逻辑设计成可插拔组件而不是让模型自己判断成功与否。比如在_check_success()中除了运行测试命令还可以检查文件 Git Status、关键日志、端口监听状态等。判断条件越独立评测结果越可信。6. 常见评测结果解读与参考阈值很多朋友跑完第一批评测数据后最常问的问题是成功率多少算好平均步数多少算优秀说实话这个问题没有固定答案因为不同任务难度差异太大。但我们可以建立一套相对理性的分析框架。6.1 结合任务难度看成功率假设你建了 20 个任务难度从“改一行配置”到“跨文件重构”。那么报告的汇总值会因为任务分布不同而失去可比性。更好的做法是分难度层级报告难度层级示例任务合理参考成功率L1单文件单错误修复90% 以上L2多文件联动修改60% - 80%L3日志排查 环境状态分析40% - 70%L4长周期多步重构20% - 50%这些范围纯粹基于个人经验不代表任何官方结论。但它们可以帮助你判断模型基线是否合理。6.2 分析失败原因分布比整体成功率更重要的是失败模式分布。我建议把所有失败轨迹都保存下来然后人工或半自动地分类目标漂移模型改完 A 后来改 B最后忘了原始目标环境理解失败模型不知道当前目录结构语法错误积累产生大量非语法错误导致项目基础状态损坏反馈忽略测试结果明确报错但模型不回看预算耗尽模型动作正确但步数预算太少来不及完成。如果你发现某个模型经常出现“反馈忽略”那么说明它在控制能力上有明显瓶颈。这种诊断价值对选型的意义甚至超过成功率本身。6.3 保存全量轨迹用于回归做评测系统最忌讳只看汇总指标。单条任务成功的背后模型可能做了大量危险动作单条任务失败的背后模型可能距离成功只有一步。所以在工程化评测系统时每一步的action、output、state、token 消耗、耗时都必须落盘保存。后续做模型新版本回归时可以直接回放这些轨迹确认哪些问题被修复了哪些性能出现退化。7. 写在最后的工程建议与学习路线写到这里LoopArena 的核心思想已经拆解得比较完整了。我们可以把它总结成一个可复用的心智模型评测一个大模型是否适合做自动化循环任务不能只看它单轮回答是否聪明而要看它在一个可观测、可执行、有反馈的真实循环里能否持续做出稳健的控制决策。如果你想在真实项目中落地这套思路我给几个具体的工程建议。第一先定义可验证目标。无论任务多简单都要有一个独立于模型判断的成功验证器。最好是一段可执行的脚本命令而不是模型自己说“完成了”。第二限制动作空间。给模型过大自由度看起来很美但在工程中往往不可控。从“只允许运行 pytest 和 git diff”开始逐步扩大范围比一开始就开放所有 Shell 命令要稳妥无数倍。第三把评测做成可持续的回归系统。不要只评测一次。模型版本会升级Prompt 会修改任务仓库会变化。只有持续回归才能及时发现能力回退。第四重视成本指标。在自动化系统里运行时控制器如果每完成一个任务要消耗 20 万 Token那它的商业价值会大打折扣即使成功率再高也很难规模化。接下来你可以按这个顺序继续学习先阅读几个主流 Agent 基准的论文了解任务构造和指标设计然后用本文的最小框架跑通两个模型的对比评测再逐步扩展加入容器隔离、轨迹存储、成本统计最后把评测结果用作你真实自动化业务的模型选型依据。如果你手头也在做自动化 Agent 或者模型评测系统欢迎把本文当作一个起点。真正把“循环控制”评估清楚离一个稳定可靠的自动化工程师 Agent 就不远了。
大模型评测新基准：循环工程中的运行时控制器能力
不知道大家有没有遇到过这样一种情况用大模型做自动化编程、线上排查、运维处置的时候单轮问答看起来什么都会但一旦把它放到真实任务里让它自己反复试错、修改命令、观察日志、再继续执行模型的表现往往会断崖式下降。它会绕圈子、重复同样的错误命令、把上下文窗口塞满、甚至在一半的时候“忘记”最初目标。这其实是当前大模型评测的一个盲区我们太习惯用“单轮输出对不对”来衡量模型却很少用“模型能否在一个循环里持续做运行时控制”来衡量它。LoopArena 这个名字所代表的基准方向就是为了弥补这个缺口而出现的它把大模型当作一个循环工程Loop Engineering里的运行时控制器来评测而不是当作一个“问你一句、答你一句”的聊天机器人。这篇文章会从概念拆解开始讲清楚什么叫“循环工程”什么叫“运行时控制器”以及 LoopArena 这类基准到底在测什么然后我会带大家设计一个最小可复现的评测框架用 Python 写一个简易 Runner让你也能在本地跑通“模型循环决策”的评测流程最后会补充常见坑点、指标设计思路和工程化建议。不管你是做 LLM Agent 应用开发、模型选型评测还是对 benchmark 设计感兴趣这篇内容都应该对你有帮助。1. 背景与核心概念1.1 从“单轮对话评测”到“循环工程评测”传统的大模型评测核心形式是“给一个问题模型输出一个答案然后对比标准答案”。这种评测方式非常适合问答、翻译、摘要、代码生成等场景因为任务边界清楚结果可以离线判定。但在真实工程环境里模型的使用方式早已变了。现在的典型用法是让模型扮演一个自主执行者在终端里执行命令、读取报错、修改文件、重新运行测试反复迭代直到任务完成。这种“观察环境 → 决策动作 → 执行动作 → 观察新状态”的过程不是单轮问答而是一个闭环控制过程。我习惯把这类场景统称为循环工程Loop Engineering。它的关键特征有四个多轮执行模型不是只输出一次结果而是连续输出多个动作。环境反馈每一步动作都会产生新的输出、报错、日志或状态变化。目标持久性模型需要在整个执行过程中保持对最终目标的记忆。错误恢复执行失败时模型要能根据反馈修正策略而不是反复撞墙。从控制论的角度看模型在这里不再是“知识问答器”而是整个执行循环的运行时控制器runtime controller。它的输入是目标、历史和观测状态输出是下一个动作。评测这种能力和评测“单轮答题”是完全不同的两套方法论。1.2 什么是“运行时控制器”“运行时控制器”这个词听起来有点抽象我们可以把它和传统软件架构做类比。在一个 Web 服务里控制器负责接收请求、调用业务逻辑、返回响应。它处于“用户意图”和“系统资源”之间是调度中枢。现在当我们说“大模型作为运行时控制器”意思是让大模型充当人、工具、代码执行环境之间的决策中枢上游输入是用户给的任务目标下行能力是它可以调用的工具比如 Shell、代码编辑器、文件读写、API 请求每一步模型都要根据当前观测到的状态决定下一步调用什么动作动作执行完环境产生新的观测模型继续决策直到满足终止条件。这种控制器的质量如何衡量传统基准评测很难回答。比如两个模型可能最后都完成了任务但一个用了 5 步且方向清晰另一个用了 30 步还反复执行了破坏性命令。单看终态都是“成功”但作为控制器的优劣一目了然。LoopArena 这类基准要做的就是把“控制器质量”拆解成可测量的多项指标。1.3 为什么需要新的基准现有 Agent 基准已经不少了比如一些工具调用类 benchmark、网页操作类 benchmark、代码修复类 benchmark。那为什么还需要 LoopArena 这样的基准我觉得最关键的一点是现有基准大多把“任务是否能完成”作为核心指标对执行过程本身的关注不足。而“运行时控制器”必须同时满足三个层面层面考察点传统基准覆盖情况任务层面最终是否解决任务覆盖较好过程层面是否高效、是否安全、是否少走弯路覆盖不足控制层面状态跟踪、反馈理解、恢复策略、长程记忆很少覆盖LoopArena 的核心价值就是把“过程质量”和“控制质量”放到和“任务成功率”同等重要的位置。它鼓励我们思考如果模型在一个循环里反复出现同样的错误那么再强的单轮生成能力也无法转化为可靠的自动化执行。另外一个值得强调的背景是现在很多 Agent 应用为了追求成功率会叠加复杂的提示词、外部规划器和人工兜底。但这样的系统很难复制和评判。LoopArena 的出现提醒我们模型本身的“循环控制能力”也需要被独立评测和持续优化。2. 评测对象与设计思路2.1 LoopArena 在测什么从基准设计者的角度出发一个模型要被当作“循环工程运行时控制器”来评测至少需要考察以下几项能力第一目标理解与保持能力。模型需要从任务描述中提取出可验证的完成条件。比如“修复测试套件中的失败用例”模型要能意识到结束标志是“pytest 全部通过”而不是“改了几个文件”。第二状态识别能力。真实环境是动态的。模型每一步看到的都是当前快照文件内容、git 状态、进程输出。它需要能从这些信息里判断“我现在离目标还有多远”。第三动作生成与工具调用能力。模型输出的动作必须是环境可以执行的合法动作。比如调用 Shell 命令时命令语法要正确改代码时代码要符合目标语言规范。第四反馈吸收与错误恢复能力。这是循环控制的核心。动作失败了模型能否从报错信息中定位根因重复出现同一错误时模型是否能意识到当前策略有问题并切换方案如果一个模型连续多次执行同一失败命令说明它并没有真正“读取”反馈。第五成本与风险管理能力。控制器运行在真实环境里每一次动作都有代价。可能有 token 成本、时间成本也可能有误删除文件、执行危险命令的安全风险。一个好的控制器应该能在低风险动作空间内完成目标。2.2 基准任务的一般形态按照这类基准的通用做法评测任务通常会被组织成一个“沙箱环境 目标描述 动作空间 终止条件”的元组。一个任务实例最少包含以下内容一个隔离的工作目录或环境一段任务目标描述一组允许调用的工具和命令白名单一个用于判断成功与否的可执行验证器一个步数预算和资源上限。在设计任务的时候任务难度通常会有梯度从“修改一行代码让测试通过”到“分析日志并定位一个隐蔽的 bug”再到“在允许范围内重构代码并保持全量测试通过”。这里需要特别注意的是所有任务都必须在隔离环境中运行避免模型执行过程中影响宿主机。这个安全约束不是可选项而是进行评测的前提条件。2.3 评价指标应该怎么设计对于这一类基准评价指标建议从四个维度展开。成功率是最基础的指标描述模型在预算内完成目标的比例。这个指标反映了控制器的“最终有效输出”。效率指标则描述模型达到成功所需的步数、Token 消耗或时间消耗。在同样的成功率下步数更少、Token 消耗更低的模型显然更适合做运行时控制器。过程质量指标关注模型是否出现重复动作、无效动作、破坏性动作。例如统计“重复错误次数”“被安全机制拦截的次数”等。鲁棒性指标关注相同任务在随机扰动下模型表现的稳定性。真实工程环境里报错信息可能有细微差别文件内容可能不完全一致一个脆弱控制器可能因为微小变化就失败。实际评测时通常不只看一个指标而是计算一个综合得分。比较常见的做法是把成功率作为门槛然后用效率指标和质量指标做加权排序。3. 一个最小可复现的 LoopArena 风格评测框架前面讲了很多概念接下来我们动手实现一个简化版评测框架。这个框架的目的不是完整复现论文而是帮助大家理解“模型循环决策”的评测过程。假设你的环境中已经有Python 3.9 以上asyncio 支持Python 3.7 默认支持一个可以调用的大模型接口比如 OpenAI 兼容 API 或本地部署模型需要测试的目标代码仓库。3.1 定义任务实例我们先定义任务的数据结构。一个任务实例应该包含任务 ID、目标描述、工作目录、验证命令、最大步数等。# 文件路径task_schema.py from dataclasses import dataclass, field from typing import Optional dataclass class EvalTask: task_id: str goal: str workspace: str verify_command: str max_steps: int 10 # 允许执行的动作前缀白名单例如 [cd , python , ls , cat , git ] action_prefixes: list field(default_factorylist) # 任务开始前的初始化命令 setup_command: Optional[str] None这里把action_prefixes作为白名单是为了减少评测风险。我们不允许模型随意执行任何命令只允许执行与任务相关的主流操作。在实际的 LoopArena 风格基准中动作空间会比这个更灵活但最小化实现时限制动作边界能让评估更容易控制。3.2 定义模型控制器接口为了支持不同模型的接入我们把“模型决策”抽象成一个接口。这样无论你接 OpenAI API、Claude API、Ollama 本地模型还是开源模型都只需要实现同一个方法。# 文件路径controller.py from abc import ABC, abstractmethod class RuntimeController(ABC): 循环工程运行时控制器接口 def __init__(self, model_name: str): self.model_name model_name abstractmethod async def decide(self, goal: str, history: list, state: dict) - str: 根据目标任务、历史轨迹和当前环境状态返回下一步要执行的动作命令。 history 格式为 [{role: assistant, content: ..., action: ..., output: ...}] state 中至少包含当前工作目录和最近输出。 raise NotImplementedError我们把它设计成异步方法是因为真实评测中模型推理、命令执行都可能耗时较长。异步结构能更自然地支持并发评测。下面给一个接入 OpenAI 兼容 API 的示例实现方便把评测框架跑通# 文件路径openai_controller.py import os from openai import AsyncOpenAI from controller import RuntimeController SYSTEM_PROMPT 你是一个运行在终端环境中的自动化工程师。 你会收到一个任务目标、历史命令记录和最近的输出。 请判断下一步应该执行什么命令。 约束 1. 每次只输出一条命令 2. 命令必须简洁且可执行 3. 如果任务已经完成输出 __FINISH__ 4. 不要重复执行已经失败且未修改策略的命令。 class OpenAIController(RuntimeController): def __init__(self, model_name: str gpt-4o-mini, base_url: str None): super().__init__(model_name) self.client AsyncOpenAI( api_keyos.getenv(OPENAI_API_KEY, EMPTY), base_urlbase_url or os.getenv(OPENAI_BASE_URL, https://api.openai.com/v1), ) async def decide(self, goal: str, history: list, state: dict) - str: messages [{role: system, content: SYSTEM_PROMPT}] # 角色信息说明 messages.append({ role: user, content: ( f任务目标: {goal}\n f当前工作目录: {state[cwd]}\n f最近一次输出: {state[latest_output][:2000]}\n f已完成步骤数: {state[step]}\n 请决定下一步动作。 ), }) # 把历史轨迹压缩后放入上下文 for item in history[-6:]: messages.append({ role: user, content: f上一动作: {item[action]}\n执行输出: {item[output][:1000]}, }) resp await self.client.chat.completions.create( modelself.model_name, messagesmessages, temperature0.2, ) action resp.choices[0].message.content.strip() return action这里有几个设计取舍值得说明历史轨迹只取最近 6 条是为了防止上下文被过长输出塞满设置temperature0.2是为了让控制器在评测时重复性更好最近输出截断到 2000 字符是为了控制 Token 成本也避免单次输出过长导致上下文溢出。如果你用的是 Ollama 本地模型只需要把客户端换成AsyncOpenAI(base_urlhttp://localhost:11434/v1)并将模型名改为本地的模型名称。比如本地拉取了qwen2.5:7b那就可以传入model_nameqwen2.5:7b。3.3 编写评测执行器 RunnerRunner 是整个框架的核心。它的逻辑很简单循环执行“模型决策 → 执行命令 → 收集输出 → 判断是否完成”。# 文件路径runner.py import asyncio import subprocess from controller import RuntimeController from task_schema import EvalTask class EvalRunner: def __init__(self, task: EvalTask, controller: RuntimeController): self.task task self.controller controller self.history [] self.success False async def run_once(self) - dict: if self.task.setup_command: self._exec(self.task.setup_command) for step in range(1, self.task.max_steps 1): cwd self.task.workspace latest_output if self.history: latest_output self.history[-1].get(output, ) state { cwd: cwd, latest_output: latest_output, step: step, } try: action await self.controller.decide( goalself.task.goal, historyself.history, statestate, ) except Exception as exc: self.history.append({ step: step, action: [MODEL_ERROR], output: f模型调用异常: {exc}, }) continue if not action or action __FINISH__: break if not self._is_action_allowed(action): self.history.append({ step: step, action: action, output: [BLOCKED] 命令不在白名单内, }) continue output self._exec(action) self.history.append({ step: step, action: action, output: output[-2000:], }) if self._check_success(): self.success True break return { task_id: self.task.task_id, success: self.success, steps: len(self.history), actions: [item[action] for item in self.history], } def _exec(self, command: str) - str: try: result subprocess.run( command, shellTrue, cwdself.task.workspace, capture_outputTrue, textTrue, timeout30, ) combined (result.stdout or ) \n (result.stderr or ) return combined.strip() or (no output) except subprocess.TimeoutExpired: return [TIMEOUT] 命令执行超时 except Exception as exc: return f[ERROR] {exc} def _is_action_allowed(self, action: str) - bool: if not self.task.action_prefixes: return True return any(action.startswith(prefix) for prefix in self.task.action_prefixes) def _check_success(self) - bool: if not self.task.verify_command: return False result subprocess.run( self.task.verify_command, shellTrue, cwdself.task.workspace, capture_outputTrue, textTrue, timeout60, ) return result.returncode 0这个实现有几个可以升级的点后面会提到。但作为最小化评测框架它已经能回答“模型能否在循环里完成任务”这个基本问题。3.4 准备一个任务示例我们可以设计一个非常简单但能体现控制能力的任务仓库里有一个脚本存在语法错误需要模型通过查看文件内容、修改代码、运行脚本最终让脚本输出预期内容。{ task_id: fix_timeout_script, goal: 修复当前目录下的 download.py使得 python download.py 能输出字符串 DOWNLOAD_OK且运行时间不超过 3 秒。, workspace: /tmp/looparena_tasks/fix_timeout_script, verify_command: cd /tmp/looparena_tasks/fix_timeout_script python download.py /tmp/verify_output.txt 21 grep DOWNLOAD_OK /tmp/verify_output.txt, max_steps: 8, action_prefixes: [ls , cat , python , sed -i , grep , cd ], setup_command: mkdir -p /tmp/looparena_tasks/fix_timeout_script }为了让任务有趣一些初始代码可以故意包含两个问题一个 import 错误一个循环结构问题。# 文件路径/tmp/looparena_tasks/fix_timeout_script/download.py # 目标任务修复该脚本最终输出 DOWNLOAD_OK import time def fetch_data(use_cache: bool): # 这里有一个 NameErrorUSE_CACHE 变量名错误 if USE_CACHE: return cache time.sleep(5) return remote def main(): data fetch_data(use_cacheTrue) print(data.upper() _OK) if __name__ __main__: main()模型在循环中需要用cat download.py查看文件发现NameError: name USE_CACHE is not defined用sed -i s/USE_CACHE/use_cache/ download.py修复再次运行脚本发现虽然不报错但运行时间是 5 秒超过 3 秒限制继续修改函数去掉time.sleep(5)或缩短睡眠最终运行验证成功。这样一个任务同时测了错误定位、代码修改、反复验证、时间约束感知等能力很适合用来对比不同模型的循环控制水平。3.5 批量运行与结果统计单个任务的输出还不能说明问题。我们需要跑多条任务、多个模型然后汇总统计。你可以先准备一个任务列表# 文件路径run_eval.py import asyncio import json from openai_controller import OpenAIController from runner import EvalRunner from task_schema import EvalTask def load_tasks(path: str) - list: with open(path, r, encodingutf-8) as f: items json.load(f) return [EvalTask(**item) for item in items] async def evaluate_model(model_name: str, task_path: str): controller OpenAIController(model_namemodel_name) tasks load_tasks(task_path) results [] for task in tasks: runner EvalRunner(tasktask, controllercontroller) result await runner.run_once() results.append(result) print(f[{model_name}] task{task.task_id} success{result[success]} steps{result[steps]}) success_count sum(1 for r in results if r[success]) avg_steps sum(r[steps] for r in results) / len(results) print(f\n模型 {model_name} 成功率: {success_count}/{len(results)}) print(f平均步数: {avg_steps:.2f}) if __name__ __main__: asyncio.run(evaluate_model(gpt-4o-mini, tasks.json))到这里你就有了一个能跑通的“模型循环控制能力”迷你评测系统。4. 评测过程中常见的坑与优化方向用这套框架评测模型时有很大概率会遇到下面这些问题我们逐个分析。4.1 模型陷入重复错误循环最常见的问题是模型在第一次命令失败之后不分析报错而是原封不动地再次执行同样的命令。在历史上表现为连续多条相同的action和基本相同的output。如果你发现自己的候选模型出现这种情况首先要看输出中是否真的包含最新报错信息。有些模型的 Prompt 设计里没有强调“结合最近一次输出调整策略”模型会把历史当成一种模板不断重复最近动作。解决方案通常有两个在 System Prompt 中加入显式约束例如“如果你要再次执行与上一次完全相同的命令必须先说明它为什么会在这次成功否则不能重复”。在评测代码里加入“重复动作检测”如果检测到连续相同动作可以记录一次repeat_penalty并且不把它计入正常步数。下面是在 Runner 中增加重复检测的示例片段def _detect_repeat(self, action: str) - bool: if len(self.history) 1: return False last_action self.history[-1].get(action) if last_action action: return True # 如果前两步动作完全一样也算重复 if len(self.history) 2: prev_actions [item[action] for item in self.history[-2:]] if prev_actions [action, action]: return True return False一旦检测到重复动作输出可以标记为[REPEAT_BLOCKED]避免模型继续用同样方式消耗步数和 Token。4.2 上下文输出过长导致 Token 截断在这个评测循环中最大的资源消耗点不是模型推理本身而是越来越长的命令输出。一个find /或cat 大型日志文件会瞬间把上下文塞满。我们已经在 Runner 中对输出做了截断到 2000 字符但这只是第一层防护。更完善的方案是对命令输出做摘要后再送入上下文记录文件路径与摘要而不是直接把全文交给模型在动作白名单中禁止可能产生超大输出的命令对单条命令输出设置预算比如超过 N 字符就停止继续读取。实际评测中经常出现“模型已经犯了错误但因为上下文里错误信息被截断模型根本不知道发生了什么”的情况。所以与其盲目截断不如设计一个专门的“信息压缩层”把输出整理成结构化片段文件修改了哪些行、测试失败用例名称、错误类型、错误位置等。这类压缩逻辑越完善模型循环决策的基础就越可靠。4.3 评测稳定性问题同一模型跑同一条任务两次结果可能完全不同。原因包括模型采样随机性、命令执行环境残留、时间因素等。提高评测稳定性的常规手段有设置temperature0或接近 0每条任务开始前使用干净容器或全新工作目录记录环境镜像的 SHA确保不同批次评测使用同一基线每条任务允许多个 Seeds 运行取多数结果固定大模型的版本避免供应商端无感升级导致波动。你可能觉得这些问题无关紧要但当你真的要用评测数据做模型选型时稳定性会直接影响决策质量。一次偶然的成功可能让一个实际很弱的模型进入候选名单这是需要警惕的。4.4 评测环境安全问题模型一旦获得 Shell 执行权限风险是真实存在的。即使我们设置了命令前缀白名单也不能保证所有命令都安全。比如sed -i可以修改任意文件rm可能删除文件python可以执行任意脚本。所以安全设计绝不能停留在“白名单”这一层。我建议至少做到以下安全底线容器隔离整个评测放在 Docker 容器中执行并禁止容器访问宿主机敏感目录网络隔离如果任务不需要联网可以使用docker run --network none文件系统备份任务开始前对工作目录做 snapshot结束后可以恢复超时熔断每条命令和整个任务都有硬性超时防止模型进入死循环命令黑名单即使不在白名单内也要额外禁止rm -rf /、mkfs、sudo等高风险命令最小授权不要在容器内使用 root 运行模型服务避免评测模型本身被当作攻击入口。安全机制的详细程度可以写一整篇文章。在评测框架这一层你只要记住一句话凡是模型能执行命令的地方都必须是可丢弃、可恢复、可审计的隔离环境。5. 从模型能力到工程落地运行时控制模型怎么选如果你不只是做测评而是想选一个模型作为真实自动化系统的“运行时控制器”那么除了跑通 LoopArena 风格评测之外还需要看以下几个方面。5.1 上下文窗口与长程记忆真实工程任务里历史轨迹往往很长。即使做了压缩控制器仍然需要在一定长度的上下文中保持连贯推理。上下文窗口更大的模型通常能容纳更多反馈信息但这不代表它一定更擅长利用这些信息。你可以设计一个“远程依赖任务”模型在第 5 步时读到一个关键线索第 15 步时需要回忆起这个线索才能完成任务。这种任务特别能区分模型的“上下文利用能力”。5.2 工具调用稳定性很多控制器通过 Function Calling 或 Tool Use 与外部环境交互而不同模型的工具调用格式稳定性差异很大。有些模型在普通对话里表现很好一到需要严格 JSON 输出动作时就会多出解释性文字导致解析失败。如果你要做工程项目优先选择在结构化输出评测中稳定的模型或者设计容错性更强的动作解析器。在代码里除了依赖模型输出严格命令外还可以提供“命令候选列表 用户确认”的折中方案但这种半自动模式已经偏离了“运行时控制器”的纯自动假设需要在实际业务中权衡。5.3 开源模型与本地部署最近很多开发者开始关注本地部署模型比如用 Ollama 部署 Qwen 系列、LLaMA 系列。对于“运行时控制器”这个角色本地模型的最大优势是隐私、延迟和成本可控。但小规模模型在复杂推理、代码修改、多步纠错上的能力仍需要谨慎评估。如果你打算在本地模型上做控制型任务建议先用第 3 节的最小框架跑一轮把成功率作为首要过滤条件。成功率太低时再多的工程优化都很难补救。我还建议在评测时对比“云端商用模型”和“本地开源模型”的差异重点观察失败模式本地模型失败往往是因为推理深度不够云端模型失败则可能是因为输出长度限制或内容安全策略。5.4 模型检查器与外部验证工具的联动在真实控制系统中你不应该让模型“裸奔”。模型即使能力很强也会在数字计算、状态统计、路径拼接等方面出错。因此运行时控制器之上通常还会叠加一层外部验证工具我们可以把它叫做带外检查器。带外检查器的作用是在模型执行之前校验语法是否正确在模型修改文件后自动运行编译或静态检查在执行删除等危险动作前做路径有效性检查在任务结束时调用独立验证脚本确认是否真正完成。在评测框架里我建议把验证逻辑设计成可插拔组件而不是让模型自己判断成功与否。比如在_check_success()中除了运行测试命令还可以检查文件 Git Status、关键日志、端口监听状态等。判断条件越独立评测结果越可信。6. 常见评测结果解读与参考阈值很多朋友跑完第一批评测数据后最常问的问题是成功率多少算好平均步数多少算优秀说实话这个问题没有固定答案因为不同任务难度差异太大。但我们可以建立一套相对理性的分析框架。6.1 结合任务难度看成功率假设你建了 20 个任务难度从“改一行配置”到“跨文件重构”。那么报告的汇总值会因为任务分布不同而失去可比性。更好的做法是分难度层级报告难度层级示例任务合理参考成功率L1单文件单错误修复90% 以上L2多文件联动修改60% - 80%L3日志排查 环境状态分析40% - 70%L4长周期多步重构20% - 50%这些范围纯粹基于个人经验不代表任何官方结论。但它们可以帮助你判断模型基线是否合理。6.2 分析失败原因分布比整体成功率更重要的是失败模式分布。我建议把所有失败轨迹都保存下来然后人工或半自动地分类目标漂移模型改完 A 后来改 B最后忘了原始目标环境理解失败模型不知道当前目录结构语法错误积累产生大量非语法错误导致项目基础状态损坏反馈忽略测试结果明确报错但模型不回看预算耗尽模型动作正确但步数预算太少来不及完成。如果你发现某个模型经常出现“反馈忽略”那么说明它在控制能力上有明显瓶颈。这种诊断价值对选型的意义甚至超过成功率本身。6.3 保存全量轨迹用于回归做评测系统最忌讳只看汇总指标。单条任务成功的背后模型可能做了大量危险动作单条任务失败的背后模型可能距离成功只有一步。所以在工程化评测系统时每一步的action、output、state、token 消耗、耗时都必须落盘保存。后续做模型新版本回归时可以直接回放这些轨迹确认哪些问题被修复了哪些性能出现退化。7. 写在最后的工程建议与学习路线写到这里LoopArena 的核心思想已经拆解得比较完整了。我们可以把它总结成一个可复用的心智模型评测一个大模型是否适合做自动化循环任务不能只看它单轮回答是否聪明而要看它在一个可观测、可执行、有反馈的真实循环里能否持续做出稳健的控制决策。如果你想在真实项目中落地这套思路我给几个具体的工程建议。第一先定义可验证目标。无论任务多简单都要有一个独立于模型判断的成功验证器。最好是一段可执行的脚本命令而不是模型自己说“完成了”。第二限制动作空间。给模型过大自由度看起来很美但在工程中往往不可控。从“只允许运行 pytest 和 git diff”开始逐步扩大范围比一开始就开放所有 Shell 命令要稳妥无数倍。第三把评测做成可持续的回归系统。不要只评测一次。模型版本会升级Prompt 会修改任务仓库会变化。只有持续回归才能及时发现能力回退。第四重视成本指标。在自动化系统里运行时控制器如果每完成一个任务要消耗 20 万 Token那它的商业价值会大打折扣即使成功率再高也很难规模化。接下来你可以按这个顺序继续学习先阅读几个主流 Agent 基准的论文了解任务构造和指标设计然后用本文的最小框架跑通两个模型的对比评测再逐步扩展加入容器隔离、轨迹存储、成本统计最后把评测结果用作你真实自动化业务的模型选型依据。如果你手头也在做自动化 Agent 或者模型评测系统欢迎把本文当作一个起点。真正把“循环控制”评估清楚离一个稳定可靠的自动化工程师 Agent 就不远了。
