ReTerm：当AI程序员卡壳时，怎么教它自己爬出坑

你有没有遇到过这样的场景：装一个Python包，报错说找不到模块，然后你反复执行同一个pip install命令，一遍，两遍，三遍，报错一模一样，你却停不下来重复同样的操作？

这不是人类才会犯的错。一个能自己操作命令行、自己写代码、自己跑测试的AI程序员，也会卡在这种死循环里。更要命的是，它不像人类那样会突然意识到"我是不是该换个思路了"，它会非常自信地在同一个坑里反复摔倒，直到任务彻底失败。

这就是这篇论文要解决的问题。研究者给这类AI起了个名字，叫终端代理

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

当前这类系统已经能完成相当复杂的编程任务，长时间地在终端里敲命令、看报错、改代码。但它们有个共同的软肋，一旦遇到错误，很容易一条路走到黑。研究者把这种能力的缺失概括为"缺乏从错误中恢复的能力"，并提出了一套叫ReTerm的训练方案来弥补这个短板。

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

要理解ReTerm有多重要，得先看看在它出现之前，这个领域的终端代理表现如何。

论文里有一个权威的评测基准，叫Terminal-Bench 2.0

Terminal-Bench 2.0*：一套专门用来衡量AI代理在真实命令行环境里完成复杂任务能力的标准化测试集，涵盖软件工程、系统管理、数据处理等多个领域。

论文作者选用的基础模型是Qwen3.5-9B，一个90亿参数的开源模型。它在Terminal-Bench 2.0上原始的通过率只有20.2%。这意味着每5个任务里，差不多有4个它完成不了。而业界顶尖的闭源模型比如GPT-5.5，能做到82.7%。这个差距不是因为小模型不会写代码，很大程度上是因为它一旦踩了坑，就爬不出来。

论文里有个很直观的例子。一个任务要求把R语言脚本转换成Python脚本，用到一个叫PyStan的库。代理装好了库，但发现import pystan还是报错找不到模块。它检查发现系统里确实装了对应文件，但目录名叫stan不叫pystan。这时候，一个用标准GRPO强化学习训练出来的模型会怎么做？它会反复执行pip install pystan，反复执行pip uninstall再重装，陷入死循环，始终没有意识到问题根源其实是导入路径不对。而经过ReTerm训练的模型，会主动去检查实际的文件路径，发现"模块文件在stan目录下不是pystan"，然后调整导入方式解决问题。

这个对比揭示的核心矛盾是，模型知道怎么执行命令，但不知道怎么诊断"为什么这个命令没用"。这不是智力问题，是训练方式的缺失，因为过去的训练几乎全部聚焦于"怎么把任务从零开始做对"，没人系统地教它"做错了之后怎么往回拉"。

一个值得提的对照工作是TermiGen，这是一个和ReTerm同期的研究，它的思路是人工往轨迹里注入错误，制造恢复训练样本。但这种做法有个硬伤：人工构造出来的错误和AI自己真实犯的错误，分布是不一样的。你教它怎么应对你编的坑，它遇到自己真实踩的坑，未必能对上号。而且TermiGen只用了监督微调（SFT），没有涉及强化学习这条路。

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

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

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

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

第一步是收集失败现场。研究者让基础模型Qwen3.5-9B去真实地做terminal任务，每个任务跑好多次。关键的操作是，在跑完一次尝试、还没有运行最终验收测试之前，先给整个虚拟机环境拍个快照，把当时的状态原封不动地存下来。然后再跑验收测试，如果失败了，这个失败现场的快照和完整的操作历史就被留下来，进入下一阶段；如果成功了，直接丢弃。

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

第二步是让一个更强的教师模型，接手这个失败现场继续干。研究者用的是DeepSeek-V4-Pro。这个教师模型拿到的信息很有限，只知道"之前这次尝试失败了"，但不知道具体哪个测试没通过、错在哪。它必须自己从操作历史和环境状态里倒推出问题出在哪儿。为了让它干得更靠谱，研究者给了它一套"恢复工作流"，引导它先检查遗留状态，再重新理解任务要求，诊断失败原因，最后动手修复并验证。

这个设计暗含一个很深的用意。如果直接把测试失败的详细原因告诉教师模型，它可能只是"对症下药"地改掉那个具体的bug，而学不到真正有用的诊断能力。只给它结果是失败这一个信息，逼着它自己完整走一遍排查流程，这样生成的恢复轨迹才更接近真实世界里"自己发现问题、自己解决"的样子。这就像带新人上手修车，如果你直接告诉他"是火花塞坏了"，他只会换火花塞，但永远学不会怎么判断是不是火花塞坏了。只告诉他"车打不着火"，让他自己一步步排查，他才真正学会修车的逻辑。

第三步是严格的质量筛选。教师模型生成的恢复轨迹不是全都能用，要经过四道关卡：首先是验证器过滤，必须真正通过了任务的验收测试才留下来；然后是格式过滤，剔除那些操作指令格式不对的轨迹；接着是合规过滤，排除违反任务明确约束的操作；最后是效率过滤，剔除那些陷入无意义重复动作循环的轨迹。前两道关卡用规则直接判断，后两道关卡先用规则初筛出可疑案例，再交给DeepSeek-V4.1-Flash这个模型做二次判断。

经过这四道关卡，大约10000条高质量的恢复轨迹被保留下来，构成了ReTerm-10K。从统计上看，这些轨迹覆盖了文件操作、软件工程、数据处理、调试等九大领域，分布相对均匀，没有哪个领域特别偏多，输出长度大多集中在4000到8000个token，操作轮次大多在9到16轮之间完成。

有了这批数据，研究者用它做了一次监督微调（SFT），让模型先打一个底子，学会"接手一个烂摊子该怎么下手"的基本套路。

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

监督微调解决的是冷启动问题，但它有个天花板。因为训练数据是固定的，都来自训练之初那个版本的基础模型犯的错误。而随着强化学习训练的推进，模型本身会不断变化，它会开始犯一些全新种类的、训练数据里压根没见过的错误。固定数据集跟不上模型进化的脚步。

这就引出了ReTerm的第二个核心贡献，叫ReTerm-GRPO，一种在线强化学习算法。

GRPO*：一种群组相对策略优化算法，最早被DeepSeek-R1这类推理模型采用。它的基本思路是让模型针对同一个问题生成多个不同的回答，然后比较这些回答谁好谁差，用相对的好坏关系来指导模型调整参数，而不需要一个单独的打分模型。

ReTerm-GRPO的巧妙之处在于，它不只是用GRPO训练模型怎么把原始任务做对，还专门构造了一类"恢复任务"，让模型在训练过程中持续地从自己刚刚制造出来的失败里学习怎么爬出来。

具体的运作方式是这样的。每一轮训练，模型会针对一批原始任务各自生成多条独立的尝试，这些尝试互相之间互不影响，就像同一道题让模型答16遍。如果某个任务的这些尝试里出现了失败的，系统就从中挑一条，把它失败后的环境状态和完整操作历史保留下来，打包成一个新的恢复任务。然后，模型要针对这个恢复任务，从那个失败现场出发，再独立生成多条恢复尝试，看看哪些能最终把任务做成。

这里有个很现实的工程问题：一批训练数据里，未必每次都能攒够足够多的失败样本用来做恢复训练。于是研究者引入了一个恢复任务队列，专门存放跨训练步骤积累下来的恢复任务。新造出来的任务插在队列最前面，优先被抽取使用；队列满了，最老的任务被挤出去。

这个队列设计的意图很直接。你希望恢复训练聚焦在模型最近犯的那些错误上，而不是很久以前那个版本的模型犯的、现在的模型可能早已经不会再犯的旧错误。这就好比一个篮球教练在复盘录像，他肯定更想看球员这周训练赛里刚暴露出来的毛病，而不是翻出三个月前的旧录像，那时候球员的技术动作早就不一样了，复盘意义不大。而如果完全不保留队列，每一轮都要专门跑一批额外的任务才能收集到失败样本，训练成本会直接翻倍。

最终，模型会把原始任务组和恢复任务组的学习信号放在一起，联合优化。这样一来，模型做任务的能力和模型从错误中恢复的能力，是同步进化的，而不是先学会一个再去补另一个。

训练曲线显示出一个挺让人安心的现象：恢复任务组的奖励分数从一开始就比原始任务组低很多，经过训练后提升幅度也更大，而原始任务的表现没有因为加入恢复训练而受到任何干扰或变差，两者是互相成就的关系，不是互相拖累。

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

说了这么多设计，最终效果怎么样？

基于Qwen3.5-9B训练出的ReTerm-9B，在Terminal-Bench 2.0上拿到34.8%的通过率，相比基础模型的20.2%，提升了整整14.6个百分点。在OpenThoughts-TBLite这个基准上，从44.2%提升到60.6%，涨了16.4个点。在面向真实软件工程问题的SWE-bench Verified上，从45.2%涨到58.4%，提升13.2个点。

这个提升幅度放在同体量模型里对比会更有感觉。同样是9B参数规模的TMax-9B，在Terminal-Bench 2.0上是27.2%，ReTerm-9B比它还高出7.6个点。更夸张的是，ReTerm-9B这个9B的小模型，在Terminal-Bench 2.0上甚至超过了参数量大几倍的32B模型Terminal-World-32B（31.5%），在SWE-bench Verified上超过了同样是32B的OpenThinkerAgent-32B（54.0%）。

一个值得特别提的对比对象是TermiGen-32B，前面提到的那个用人工注入错误来训练恢复能力的工作。在Terminal-Bench 2.0上，TermiGen-32B只有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的任务不变，但是把执行环境换成三种不同的交互框架：Terminus-2、mini-SWE-agent和OpenHands。结果显示，ReTerm-9B在训练用的框架下提升14.6个点，换到另外三种框架下，提升幅度分别是10.1、6.7和12.4个点，虽然没有训练框架下那么高，但依然保持着实质性的优势。

研究者还测试了跨任务领域的泛化能力，挑的是和终端操作完全没关系的数学推理测试AIME，以及涉及表格操作的SpreadsheetBench。结果同样是全面上涨，AIME 2025从73.3%涨到93.3%，涨了20个点，SpreadsheetBench Verified从37.8%涨到48.8%，涨了11个点。

这个发现挺出乎意料的。因为ReTerm的整套训练设计都是围绕"命令行环境里的恢复"展开的，没有专门针对数学题或者表格操作做任何设计。它能在这些完全无关的领域也表现出提升，说明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换到完全不同的交互框架（如Terminus-2、OpenHands）下依然保持6到12个百分点的提升，在数学推理、表格操作等和终端完全无关的任务上也有10到20个百分点的提升，说明训练出的是一种通用的纠错能力。