AI终端助手在敲错一行命令后,为什么没能自己改过来

你有没有遇到过这种情况：让AI帮你在电脑终端里执行一个任务，它敲了一行命令,系统报错,接下来它死活不肯换个思路,反而在原地打转,甚至把环境越改越乱。

这不是你一个人遇到的问题。

NVIDIA和KAIST的一组研究者在2026年发的这篇论文里,专门研究了这件事。他们发现一个挺反直觉的现象:同一个AI模型,让它生成多条候选命令,然后挑一条最好的去执行,效果居然可以从50%的成功率跳到68%。但前提是,挑选这个动作的"裁判"必须足够强。如果裁判本身很弱,哪怕给它准备十条候选命令,成功率也只会从50%挪到51%,基本等于没用。

这篇论文的名字叫《Mid-Harness》,翻译过来大概是"中间层"的意思。它想解决的问题,其实特别朴素:**AI终端助手能不能在执行命令之前,先把几个候选方案比一比,挑个好的再动手**。

这个问题为什么重要

先说说终端助手是怎么工作的。

你让它完成一个任务,比如修复一个代码bug,它会像人一样,一步一步敲命令,看反馈,再敲下一条命令。这个过程叫做ReAct循环

**ReAct**：一种让AI交替进行"思考"和"行动"的工作模式,模型先生成一段推理,再决定下一步该执行什么命令,执行完看结果,再继续思考。

关键问题在于,每一条命令一旦执行,就会真实地改变环境。装错一个软件包,删错一个文件,这些动作造成的后果是不可逆的。模型可能在脑子里想得清清楚楚"应该装numpy而不是numpy2",但骰子只能掷一次,它随机采样出来的那个动作如果恰好是错的,环境就被污染了,后面的路会越走越偏。

论文里统计了一下,在TerminalBench-Lite这个评测基准上,基础版的TMAX-9B模型(一个90亿参数、专门为终端任务训练的模型)单次执行的成功率只有50%。这不是因为模型完全不懂该干什么,很多时候它其实有能力生成一个更好的命令,只是采样的随机性让它没选中那条路。

**TerminalBench-Lite**：一个专门测试AI在命令行环境里完成任务能力的评测集,包含100个经过筛选、覆盖软件工程、数据处理、安全等领域的任务,论文里实际用了98个(两个因为环境问题被剔除)。

这就好比你让一个实习生去银行办事,每次只准他排一次队,办错了就要重新跑一趟,而且上次办错留下的烂账还得他自己先去擦干净。如果允许他先想好三种办事方案,找个懂行的朋友看一眼哪个靴子最可能被柜员接受,再去排队,办对的概率显然会高很多。但如果那个"懂行的朋友"其实也是个半吊子,看不出三个方案的区别,那多想几种方案也是白费功夫,反而浪费了排队的时间。

这正是论文的核心发现:**采样再多候选动作,如果裁判辨别力不够,收益基本为零**。

Mid-Harness到底加了什么

论文给这套系统起的名字叫Mid-Harness,意思是"在模型和执行环境之间"插入一层验证机制。

**Harness**：在AI agent领域,指包裹着模型、负责调用工具、解析输出、把结果喂回去的那套工程脚手架,可以理解成"模型的操作系统"。

它的做法是:在模型要执行下一个命令之前,先让它基于同一段历史对话,采样出N个候选动作(比如8个),然后用一个验证器(verifier)从这N个里面选一个,只有被选中的那个才会真正送到终端去执行。其他候选全部作废。

这里有个设计上的巧妙之处值得单独说一下。它完全不需要改动原来的模型,也不需要改动执行环境的接口。论文里给出的伪代码特别简单,原来的模型调用函数是`llm.generate(messages)`,现在变成先采样N个,再调用一个`verify`函数选一个出来返回,其他地方一个字都不用动。

这就像给一辆已经组装好的汽车加一个倒车雷达,不需要拆发动机,不需要换变速箱,只是在倒车这个动作前面加一道"感应确认",但这个雷达得是真能测出距离的,不然装了也是摆设。

那么怎么验证哪个候选动作更好?论文对比了三种机制。

**Listwise verification(列表式验证)**：把所有候选一次性丢给裁判,让它从里面直接选一个。优点是只需要一次调用,缺点是候选越多,裁判要同时权衡的信息越复杂,容易判断失准。

**Pointwise verification(点式验证)**：给每个候选单独打分,互相独立,最后选分数最高的。可以并行跑,但问题是每个候选都是孤立评分的,不同候选之间没有直接比较,容易出现"单独看都还行,但放在一起比就输了"的情况。

**Pairwise verification(两两式验证)**：每次只比较两个候选,给出谁更好的判断,再用某种打分规则把所有两两比较的结果汇总排名。好处是每次比较的焦点很集中,裁判只需要盯着两个选项的差异,不容易被信息量淹没。代价是调用次数更多,8个候选如果两两全比要28次。

实验结果很干脆地站在了两两式验证这边。在候选数N=8的设置下,列表式只能把成功率从50%拉到51%,点式拉到52.4%,而两两式能到54.8%。这不是一个小差距。

这里能看出一个挺有意思的现象:**同样一个"弱裁判"模型,换一种比较方式,成绩就能有明显差别**。这说明弱的不完全是模型本身的判断力,也包括"怎么把判断力正确地用出来"这件事。

这就好比考试的时候,让一个学生一次性给十篇作文排名次,他很容易乱,但如果每次只拿两篇出来比哪篇写得好,他大概率能给出靠谱的判断。不是他变聪明了,是任务的难度被拆小了。如果不拆小,裁判的真实水平就被题目的复杂度掩盖了,你根本看不出他到底行不行。

frontier verifier带来的巨大落差

但两两式验证带来的54.8%,离这篇论文真正想证明的事还差一大截。

研究者找了一个更强的"外援"裁判,叫GPT-5.6 Sol,让它来给同样的TMAX-9B生成的候选打分。结果是惊人的:成功率从50%一路冲到68.03%(N=8时)。

**frontier verifier(前沿裁判)**：论文里特指用更强大的模型(这里是GPT-5.6 Sol)来充当验证器,目的是测试"如果裁判足够聪明,生成器本身的潜力能被挖出多少"。

这个结果的意义比表面数字更值得琢磨。它说明TMAX-9B这个生成模型,其实并不是"能力不足",它生成的候选动作里,早就藏着能把成功率拉高18个百分点的好选项。问题从来不是"模型想不出好命令",而是"没人能可靠地把好命令从一堆候选里挑出来"。

这就像一个乐队里其实已经有能唱准每个音的歌手,只是现场调音师耳朵不够灵,每次都把跑调的那版放大了送进音箱。歌手的实力一直都在那儿,缺的是能听出差别的耳朵。如果调音师水平不提升,再让歌手唱十遍,听众听到的还是跑调的那版,因为调音师每次都选错。

这个发现直接把研究的焦点从"要不要多采样"转向了"裁判到底行不行"。这也是整篇论文最关键的一个转折点。

蒸馏:把强裁判的本事学到弱模型身上

既然GPT-5.6 Sol这么强,为什么不直接拿它当裁判用?

现实的考量很直接:成本和延迟。部署一个前沿大模型作为实时裁判,代价太高,不是每个场景都承受得起。

于是研究者做了一件很自然的事:蒸馏

**蒸馏(distillation)**：一种让小模型学习大模型行为的训练方式,通常是让大模型(教师)生成大量示范答案,再用这些示范去微调小模型(学生),让学生模仿教师的判断模式。

具体做法是,从244个困难任务里收集了732条轨迹,让GPT-5.6 Sol针对每一步的候选动作生成两两比较的推理过程、打分和偏好标签,一共攒了117,631条训练样本。然后用LoRA

**LoRA(低秩适配)**：一种高效微调大模型的方法,不需要改动模型里全部的参数,只往模型里插入少量新增的小矩阵进行训练,大大降低了训练成本和显存需求。

对TMAX-9B做微调,让它学会模仿GPT-5.6 Sol的判断方式。

效果是,蒸馏后的验证器把两两式验证的成功率从54.76%提到了57.14%,Pass@3(三次尝试里至少成功一次的比例)从71.43%提到75.51%。

这个提升幅度看起来不算惊人,但重要的是方向正确,而且验证了一件事:裁判这个角色,确实可以通过训练变强,而不需要换掉原本负责生成动作的那个模型

论文接着做了一个更细致的分析,去搞清楚蒸馏到底学会了什么,又还有哪里没学会。他们拿了21个没参与训练的任务做"离线对比",衡量蒸馏后的裁判和GPT-5.6 Sol的判断一致性。结果显示,打分的平均绝对误差从2.59降到1.05,两两比较的一致率从59.01%提升到74.58%,最终识别出同一个"最佳候选"的一致率从38.52%提升到57.79%。

但这里有个让人没法轻易满足的地方:**一致性是提升了,却远没有追平**。研究者进一步把裁判之间依然存在分歧的案例拿给另一个强模型GPT-5.6 Terra去审查,看看这些分歧里有多少是能明确判定为"裁判判断失误"的。结果是,蒸馏前有3328个这样的明显失误案例,蒸馏后降到1810个,降了不少,但依然有大量错误没被纠正。

这些剩下的分歧主要集中在两类问题上:判断一条命令具体会产生什么效果(candidate semantics),以及判断这条命令在当前环境里到底能不能跑通(execution feasibility)。两者加起来占了蒸馏后裁判失误案例的67.4%。

换句话说,蒸馏能学会"大致怎么打分、怎么表达偏好",但对"这条命令真正会发生什么"这种需要对系统状态有深刻理解的判断,学得还不够到位。

论文里举了两个具体的例子,很有意思。一个是关于C语言里字符运算的写法,蒸馏后的裁判认为`’a’ + s1`这种写法"有缺陷",偏好另一种写法`s1 + ’a’`,但实际上这两种写法在C语言里是完全等价的整数加法,裁判在这里犯了一个纯粹的语义错误。另一个例子更危险:一个候选命令里包含了一段用来清理旧进程的Python脚本,但这段脚本的扫描逻辑本身就包含了它要匹配的关键词,很可能会把自己或者父进程也误杀掉。蒸馏后的裁判反而更偏好这个有自毁风险的方案,只因为它"看起来更持久地启动了服务"。

这说明蒸馏学到的更多是"怎么表达一个像样的判断",而不是"真正理解命令执行后会发生什么"。这也呼应了论文标题里那个核心命题:在命令被执行之前,判断它会产生的效果,是一件远比想象中难的事。

如果你让一个刚入行的审计新人去模仿老会计做账,新人很快能学会怎么写批注、怎么打分、怎么表达"这笔账有问题",但他未必真的理解某个科目背后牵扯的复杂业务逻辑。表面的流程学会了,底层的判断力还得靠真实踩坑才能补齐。

不需要推理的裁判:省钱的另一条路

论文里还藏着一个挺实用的发现。

两两式验证虽然效果最好,但代价也最大。因为每次比较,裁判都要先生成一段推理文字,再给出打分和偏好,这个过程非常耗token。论文测算过,在N=8的设置下,零样本两两式验证会让裁判额外产生26,600个token的解码开销,而列表式和点式最多只要1,300个token。

研究者于是尝试了一个"decision-only"(只给结论不给理由)的版本,让裁判直接吐出一个A或B的token,不写任何推理过程。

结果出乎意料:在TMAX-9B上,这个不写理由的版本反而比写理由的版本成绩更好,同时降低了20.9%(零样本)和24.1%(蒸馏版)的参考定价token成本。

但这个结论并不是放之四海而皆准的。在4B和27B规模的模型上,不写理由的版本反而成绩更差。这说明"要不要推理"这件事,和模型本身的规模、能力有关,没有一个统一答案。

这有点像写作文,有的学生写提纲就能直接把答案想清楚,多写一段"分析过程"反而是画蛇添足,拖慢了思路;但也有学生需要一步步把逻辑摆出来才能想明白,跳过推理直接给结论反而容易出错。到底该不该让裁判多说两句,取决于这个裁判本身的思维习惯和能力水平。

和"多跑几次"组合起来会怎样

前面说的都是"单次轨迹内部"怎么优化动作选择。但业界还有另一条路:多跑几整条完整轨迹,然后挑一条最好的,或者让模型看完上一次失败的经历再重跑一次。论文把这两种思路也纳入了对比。

Best-of-T:跑T条完整轨迹,用一个"轨迹裁判"挑出一条最好的输出。

Sequential Refine(SR,序贯改进)**：跑完一条轨迹后,总结这次的经验教训,再基于这个总结重新跑一次,相当于"吃一次亏,学一次乖"。

论文发现一个很漂亮的组合效应。单独用Best-of-T(T=3)跑三条轨迹,成功率是55.10%。但如果每条轨迹在生成过程中都用上了蒸馏版的Mid-Harness做动作验证,再跑Best-of-T,成功率直接飙到66.33%。这是11个百分点的提升,而且用的环境执行次数完全一样,都是三次。

单独用SR(改进一轮)跑,成功率是55.10%,结合蒸馏版Mid-Harness后提升到60.20%。

这说明**动作层面的优化和轨迹层面的优化,不是互相替代的关系,而是互相增益的关系**。一个在负责"每一步走得稳不稳",另一个在负责"整条路线对不对"。前者管细节,后者管方向,两者叠加,效果比单独用任何一个都强。

研究者还算了一笔经济账。用蒸馏版Mid-Harness(N=8)跑,能达到和Best-of-T跑五次差不多的成功率(57%左右),但花费的token成本大概只有后者的三分之一。如果把两者结合起来,用更少的总成本超过单独跑七次Best-of-T的效果。

这就像盖房子,如果地基(每一步命令)本身就打得不牢,那即便你多盖几栋房子挑最好的那栋(Best-of-T),最好的那栋也好不到哪里去,因为每栋房子的地基问题是共性的。但如果先把地基打牢了,再多盖几栋挑最好的,这时候"多盖几栋"这件事才真正开始发挥价值,因为每一栋本身的质量都提高了一个台阶。不先解决地基问题,盖再多房子也只是在同一个低水位上重复。

这套方法能不能用在别的模型和场景上

论文最后做了一轮扩展实验,想看看Mid-Harness是不是只对TMAX-9B这一个模型管用。

答案是不只。他们测试了参数量更小的TMAX-4B和更大的TMAX-27B,结果都有提升:4B从38.78%提升到43.88%,27B从71.09%提升到76.19%。

他们还换了别的模型家族,比如Qwen3.5-9B、Nemotron3.5 Lightning(300亿参数)和体量巨大的Nemotron3 Ultra(5500亿参数),用的还是不同的执行框架(从Vanillux2换成Terminus-2)。结果显示,零样本版本的Mid-Harness在全部七种组合里都提升了Pass@3指标,Pass@1也至少保持不变或提升。

更值得一提的是在一个叫FeatureBench-Mini的高难度基准上的表现。这个基准测的是端到端的功能开发,难度很大,基础版TMAX-9B的成功率只有1.45%,几乎等于"几乎干不成"。但加上Mid-Harness之后,零样本版提升到5.80%,蒸馏版提升到7.25%。虽然绝对数字还是低,但相对提升是实打实的几倍。

这说明,哪怕是那种"连基础模型都几乎不会做对"的超难任务,给它一个能在执行前多想一步、多挑一个的机制,也能把生还率拉上去一些。这有点像在极端恶劣的考场环境里,哪怕一个学生平时只能及格,给他一次"先打草稿再抄到答题卡"的机会,他至少能避免一些原本会犯的低级失误。

写在后面

读完这篇论文,最让我意外的不是那个68%的数字,而是那个50%和51%的对比。多给模型几个候选命令,结果几乎没有变化,这件事本身在直觉上是很反常的。按理说"选项更多总比选项更少好",但这篇论文用实打实的数据告诉你,选项多了没用,如果没人能分辨哪个选项更好。

这让我想起一个更普遍的现象:很多团队在做AI产品的时候,第一反应是"让模型多想几个方案",却忽略了挑选方案这件事本身需要的能力,和生成方案的能力,根本是两种不同的能力,需要分别投入资源去打磨。论文里那个两两比较优于列表比较的发现尤其值得记住,不是裁判变聪明了,而是任务被拆小了之后,裁判原有的判断力才真正被释放出来。这对做任何需要"评审"环节的系统设计都有启发,不只是AI终端助手。

论文里关于蒸馏之后依然存在的两类顽固分歧,也让我多想了一层。命令语义和执行可行性,这两样恰恰是最需要"理解系统真实状态"的判断,而不是"模仿一种打分风格"就能学会的。这似乎暗示了一个更根本的问题:对AI来说,学会说出一个像样的判断容易,真正理解一个系统会怎么运转,难得多。

这篇论文留了一个明显的口子没有堵上:全文都没有"黄金标准"的动作标签,也就是没有人真正标注过"在这一步,哪个候选命令才是客观正确的"。所有的评估都建立在"用一个更强的裁判去推测哪个更好"这个代理指标上。这意味着整套方法论的上限,目前还被这个评估手段本身限制着。如果有一天能有真正的动作级标注数据,现在这个68%的"前沿裁判上限",会不会也只是一个被低估的数字?

Q&A

Q1：Mid-Harness是什么?

A：Mid-Harness是NVIDIA和KAIST研究者提出的一种方法,在AI终端助手执行命令之前,先让模型生成多个候选动作,再用一个验证器挑出最优的一个去执行,整个过程不需要改动原有的模型和执行环境。

Q2：为什么增加候选命令数量有时候不起作用?

A：因为候选命令的质量收益完全取决于裁判能不能分辨出哪个更好。如果裁判判断力弱,哪怕给它8个候选命令,成功率也只从50%提升到51%,几乎没有变化;但换成更强的裁判,同样的候选数量能把成功率拉到68%。

Q3：两两比较式验证为什么比列表式验证效果好?

A：列表式验证要让裁判同时权衡一堆候选,容易判断失准;两两比较每次只聚焦两个候选的差异,判断难度被拆小了,裁判的真实水平更容易发挥出来。实验显示两两式验证成功率54.76%,明显高于列表式的51.02%。