ReTerm：AI程序员出错后怎么自己爬出坑

装一个 Python 包，报错提示找不到模块，接着反复敲同一条 pip install，一遍、两遍、三遍，报错内容一模一样，手却停不下来——这种场景你遇到过吗？

这种错误不只人会犯。能自己操作命令行、自己写代码、自己跑测试的 AI 程序员，同样会卡在这样的死循环里。更麻烦的是，人有时会突然反应过来“是不是该换个思路”，它不会——它会很自信地在同一个地方反复摔倒，直到任务彻底失败。

这篇论文瞄准的就是这个问题。研究者把这类 AI 命名为终端代理。

终端代理*：指能通过命令行界面与真实计算机环境交互、执行代码、调试程序的 AI 系统，Claude Code、Codex 这类工具背后的核心能力就属于这一类。

眼下这类系统已经能完成相当复杂的编程任务，能在终端里长时间敲命令、看报错、改代码。可它们有个共同的软肋：一遇到错误，就容易一条路走到黑。研究者把这种能力缺失概括为“缺乏从错误中恢复的能力”，并提出了一套叫

卡在哪了：当前方法的真实水平

要理解

论文里用了一个权威评测基准，叫

Terminal-Bench 2.0

论文作者选用的基础模型是

论文里有个很直观的例子。一个任务要求把 R 语言脚本转成 Python 脚本，用到 PyStan 这个库。代理把库装好了，import pystan 却还是报找不到模块。它检查后发现系统里确实装了对应文件，只是目录名叫 stan，不叫 pystan。这时候，一个用标准

这个对比戳中的核心矛盾是：模型知道怎么执行命令，却不知道该怎么诊断“这条命令为什么没用”。这不是智力问题，而是训练方式上的缺失——过去的训练几乎都盯着“怎么从零把任务做对”，没有人系统教过它“做错了之后怎么往回拉”。

一个值得对照的工作是

这正是 ReTerm 要补的两块短板：训练数据得来自模型自己真实踩过的坑，而非人工编出来的坑；训练方式也不能只靠监督微调，还要让模型通过试错不断进化。

第一块拼图：让 AI 教师给 AI 学生擦屁股

ReTerm 解决问题的第一步，是造一批高质量的“怎么从失败里爬出来”的示范数据，叫

这个数据集的构造方式挺有意思，分三步走。

第一步是收集失败现场。研究者让基础模型

这一步的设计很关键。为什么要在运行验收测试之前拍快照？因为验收测试本身可能在环境里留下副作用，比如生成临时文件、改动某些状态。不提前拍快照，恢复时这些测试带来的“噪音”就会混进去，干扰后面教师模型的判断。打个比方，你想研究一场交通事故的真实原因，肯定要在救护车和交警到场之前把现场封存起来，而不是等人清理完现场再分析——那时候线索早被破坏了。

接下来进入第二步：把失败的现场交给更强的教师模型接着处理，研究者选的是 DeepSeek-V4-Pro。教师模型掌握的信息其实不多，它只被告知“上一次尝试没成功”，至于哪个测试没过、错在哪里，一概不知。要弄清问题所在，它只能从操作历史和环境状态里自己往回推。为提升可靠性，研究者还配了一套“恢复工作流”：先查看遗留状态，再重新理解任务要求，随后诊断失败原因，最后修复并验证。

这种安排背后有一层更深的考虑。假如把测试失败的详细原因直接告诉教师模型，它很可能只是“头痛医头”地把那个具体 bug 改掉，真正的诊断能力却没学到。只给它“结果是失败”这一条信息，等于逼它把整套排查流程完整走一遍，这样产出的恢复轨迹才更贴近真实世界中“自己发现问题、自己解决”的情形。好比带新人修车，你直接说“火花塞坏了”，他只会换火花塞，却始终不会判断火花塞是否真坏了；只告诉他“车打不着火”，让他一步步自己查，他才能学会修车的门道。

第三步做的是严格的质量筛选。教师模型产出的恢复轨迹并非条条可用，需要过四道关：先由验证器过滤，只有真正通过任务验收测试的才保留；再是格式过滤，把操作指令格式不正确的轨迹剔掉；随后是合规过滤，违反任务明确约束的操作会被排除；最后是效率过滤，那些反复做无意义动作、陷入循环的轨迹不予保留。前两道关用规则直接判定，后两道关则先用规则筛出可疑案例，再交由 DeepSeek-V4.1-Flash 做二次判断。

经过这四道关卡，大约 10000 条高质量的恢复轨迹被保留下来，构成了

有了这批数据，研究者用它做了一次监督微调（

第二块拼图：让 AI 在自己挖的坑里反复练习

监督微调能解决冷启动，可它撞得到天花板。训练数据是死的，全是基础模型最初那版犯下的错。强化学习一路推进，模型自己也在变，新冒出来的错误种类，固定数据集里压根没有。数据不更新，就跟不上模型进化的节奏。

于是有了ReTerm的第二项核心工作——

GRPO*，全称群组相对策略优化。DeepSeek-R1这类推理模型最早用了它。做法是让模型对同一道题给出多个答案，再比这些答案孰优孰劣，靠相对好坏去调参数，单独的打分模型就省了。

这套东西被改造成了ReTerm-GRPO。

跑起来是这样的：每轮训练，模型对一批原始任务分别生成若干条独立尝试，彼此不干扰，相当于一道题答16遍。某个任务的尝试里只要有失败的，系统就挑出一条，把失败时的环境状态连同完整操作历史存下来，打包成一个恢复任务。接着模型从这个翻车现场出发，针对恢复任务再生成多条恢复尝试，看哪条能把活干完。

工程上有个绕不开的麻烦：一批数据里不一定每次都攒得出足够的失败样本。研究者为此加了一个恢复任务队列，跨训练步骤攒下来的恢复任务都放里面。新任务插到队首，优先被取用；队列一满，最老的被挤出去。

用意很直白。恢复训练要盯着模型最近犯的错，而不是很久以前那版模型犯的、现在多半不会再犯的老毛病。好比篮球教练看录像，他想看的是这周训练赛刚暴露的问题，三个月前的旧带子翻出来没多大意思，球员动作早变了。反过来说，队列完全不存，每轮都得额外跑一批任务去凑失败样本，训练成本直接翻倍。

到最后，原始任务组和恢复任务组的学习信号会合到一起做联合优化。模型干活的本事和从错误里爬出来的本事，就这么同步长起来，不用先学一样再补另一样。

训练曲线给出一个让人踏实的结果：恢复任务组的奖励起点比原始任务组低一大截，训练后的涨幅也更大；原始任务那边的表现没受任何干扰，没变差。两边是互相成就，不是互相拖累。

实打实的数据：9B模型打出34.8%

设计讲了这么多，效果到底如何？

基于Qwen3.5-9B训出来的ReTerm-9B，在Terminal-Bench 2.0上通过率34.8%。基础模型是20.2%，算下来整整多了14.6个百分点。

这个涨幅，放到同体量模型里比才更有感觉。同样是9B参数规模的——

有个对比对象值得单拎出来：TermiGen-32B，前面提过，靠人工注入错误来练恢复能力。Terminal-Bench 2.0上它只有19.3%，而体量不到它四分之一的ReTerm-9B拿到34.8%，差不多是它的近两倍。这个结果从侧面印证了前面的判断：用真实踩出来的坑训练，确实比人工编的坑管用。

研究者还做了消融实验，把每个训练阶段的贡献单独拆开看。原始基础模型20.2%，只做监督微调到25.8%，加上标准GRPO强化学习到28.0%，换成ReTerm-GRPO则到34.8%。每一步都有实质贡献。把标准GRPO换成ReTerm-GRPO带来的提升，比标准GRPO自身带来的还大。可见光靠常规强化学习，模型自己摸索“怎么从错误里恢复”效率很低，专门设计恢复任务来教，才是真正起作用的环节。

更细的分析来自错误类型拆解。终端任务里的错误被分成五类：规划错误，理解需求或选策略时方向想歪了；工具使用错误，命令敲错、参数用错；实现错误，代码或配置本身有毛病；验证错误，没能通过测试把问题揪出来；资源管理错误，时间、轮次浪费太多，或者进程没管好。

这五类错误上，ReTerm-GRPO训出的模型恢复率都高过基础模型和标准GRPO模型。可除了工具使用错误能恢复到68.9%，其余四类的恢复率都在32%以下。错误越牵扯深层的理解和判断，比如规划错误、验证错误，恢复就越难。这块天花板眼下还在，没被彻底捅破。

论文里有个很直观的例子，讲规划错误的恢复。任务是要构造一个满足特定数学约束的概率分布，相对均匀分布两个方向的KL散度都得恰好等于10。标准GRPO训出的模型围着“两段式幂律分布”反复调参，两个方向的误差始终压不进容许范围，最后只能交一个不完全达标的结果。ReTerm-GRPO训出的模型中途想明白了一件事——“两组模型和幂律模型无法独立控制两个方向的KL散度，因为熵和期望对数概率之间存在数学关系”。这个洞察更深一层，让它掉头去试“两段式幂律族”这个新方向，最终真找到了同时满足两个约束的解。

这个例子说明的事挺有意思：恢复能力有时候不是“换个写法再试一遍”，而是能不能从当前框架里跳出来，重新看问题本身的数学结构。这种差别，正是ReTerm训练想培养的东西。

跨场景的检验：换个马甲还认得出来吗

一个很自然的疑问：ReTerm练出来的能力，是不是只在训练时那套交互方式下才管用？换一套操作界面，提升会不会就没了？

研究者专门测了跨agent框架。Terminal-Bench 2.0的任务不变，执行环境换成三种不同的交互框架：

跨任务领域的泛化能力也测了，挑的是跟终端操作毫无关系的数学推理测试。

这个结果有点出人意料。ReTerm整套训练设计都围绕“命令行环境里的恢复”来做，数学题、表格操作这些方向并没有专门设计过。它却能在完全无关的领域也出现提升，说明训练出来的不只是“怎么处理终端报错”这一项窄技能，更像是一种更底层的通用能力：察觉自己走偏了，然后调头。这种能力不挑场合。

写在后面

再看ReTerm-GRPO那条训练曲线，有个细节值得多想一会儿：恢复任务组的初始奖励比原始任务组低不少，可提升的斜率反而更陡。起点更低，学习效率却更高。换句话说，恢复能力本身就是一块更容易被训练撬动的洼地——不是因为它简单，而是因为之前几乎没人专门去填它。

那个QEMU启动失败的案例也让人反复琢磨。标准GRPO训练出的模型一遍遍换命令行参数组合，想绕过“端口转发规则设置失败”这个报错，始终没意识到真正的原因是上一次失败的尝试留下了一个僵尸进程，正占着同一个端口。ReTerm-GRPO训练出的模型第一步做的，是去查这个端口到底被谁占用。差别很微妙：前者在“解决报错本身”，后者在“理解环境此刻处于什么状态”。真正的恢复，或许就藏在这个区别里——不是换个姿势再撞一次墙，而是先搞清楚自己现在到底站在哪儿。

论文测的五类错误里，工具使用错误的恢复率能冲到近七成，规划错误和验证错误却始终卡在三成以下。这个落差论文没有刻意回避，而是老老实实摆了出来。它暗示着一件事：命令敲错了容易改，但判断错了方向、或者没能真正验证清楚自己到底对不对，这类更接近“认知”而非“操作”层面的失误，才是AI代理下一步真正难啃的骨头。

Q&A

Q1：ReTerm是什么？

A：ReTerm是一种训练终端AI代理的方法，核心思路是让AI从自己真实执行任务时产生的失败状态中学习如何恢复，而不是依赖人工编造的错误场景。基于Qwen3.5-9B训练出的ReTerm-9B在Terminal-Bench 2.0上达到34.8%通过率，比基础模型提升14.6个百分点。

Q2：ReTerm-GRPO和普通的GRPO强化学习有什么区别？

A：GRPO 通常只围绕原始任务多采样几条路径来做优化。ReTerm-GRPO 则另建了一个恢复任务队列，把模型自己踩出来的失败状态专门留存下来，再让它一遍遍在这些真实失败场景中练习恢复。这样一来，恢复本领和完成任务的能力就能一起长进。

Q3：ReTerm训练出来的能力能不能用在别的场景？

A：可以。实验显示ReTerm-9B换到完全不同的交互框架（如