腾讯混元实验:一个270亿参数模型配三套外壳,多解出194道题
你有没有遇到过这种情况:同一道数学题,换个思路突然就做出来了。不是你变聪明了,是思路对了。AI模型其实也是这样。腾讯混元团队最近做了一个挺有意思的实验,他们拿同一个270亿参数的模型(Qwen-3.8-27B),分别套上三种不同的"做题方式",去解将近3000道终端任务题。结果发现,三种方式加起来解出来的题,比任何一种
一道数学题换个思路忽然就通了,这种事不少人都碰到过。变聪明谈不上,是路子找对了。AI模型身上其实也发生着类似的事。
腾讯混元团队前不久做了个实验。同一个270亿参数的模型(Qwen-3.8-27B),他们给它套上三种不同的“做题方式”,拿去解将近3000道终端任务题。三种方式合起来解出的题,比任何单独一种都多出三分之一还多。
这个结果本身倒不稀奇。真正有意思的是后面那个问题:既然换套做法就能多解题,那这些“多解出来的经验”能不能反过来喂给模型,让它只靠最普通的做法也能多解出一些?
论文讲的就是他们怎么把这件事做成的。
问题根子在哪
有件事得先摆明:看模型解题,只盯着模型本身远远不够。
AI执行任务并非赤膊上阵,它外面还包着一层“壳”,论文里称作harness,可以理解为执行框架或者脚手架。任务反馈怎么送到模型眼前、工具怎么调、做到什么程度算完、出了错怎么返工,全由这层壳说了算。同一个大脑,换不同的壳,表现能差出一大截。
这观点并不新。此前已有研究显示,给弱模型配一套足够聪明的壳,弱模型甚至能赢过没有壳加持的强模型。论文里提到的StateM框架,就曾把终端任务基准上的成绩直接拉到95.3%的准确率。另一项叫Self-Harness的工作更干脆,只换壳,MiniMax M2.5的分数就从40.5%升到61.9%,模型参数一个没动。
一句话,壳不是装饰,它实打实地算战斗力。
研究团队顺着这个思路往下想:不同壳能解不同的题,那多备几套壳,分头去啃那3000道难题,看看各自的本事落在哪一段,行不行?
他们实际用了三套框架。
头一套是Terminus 2,最朴素的版本。模型发命令、看结果、自己定下一步,没有多余的脚手架,相当于“裸装上阵”的基准。
第二套StateM,特点在于给执行过程加了状态管理。任务流程像被画成一张流程图,每走一步都核对有没有走偏,走错了就退回去修。
第三套由团队自己改造,名叫RSRT(Recursive Self-Reflect Terminus,循环自我反思终端)。它的玩法是:模型做完一次任务,系统拿验证器暗中核对对错,却只丢给模型一句“你错了”,错在哪、正确答案是什么,一概不透。模型只能自己翻回先前做过的步骤,自己挑毛病、自己改,改完再交,一直到做对或者时间耗尽(最多180分钟)。
打个比方,交卷之后老师不标出错题,也不给答案,只说“这张卷子不及格,回去再看看”。你只好把卷子从头到尾捋一遍,每一步都怀疑一下,直到揪出问题。这种逼自己复盘的练法,记住的东西往往比直接看答案更牢。反过来,老师要是把错题圈出来告诉你改哪儿,下回碰上同类题,多半还是不会独立去想,因为“找茬”这个过程你压根没经历过。
三套框架各自跑完,团队开始统计。
三套打法,解题范围几乎不重叠
数字摆出来,冲击力不小。
将近3000道题的池子里,Terminus 2单独解出565道(19.3%),RSRT解出512道(17.5%),StateM解出461道(15.7%)。单看数字Terminus 2最强,可三者并起来一共解出759道,比最强的单一框架多194道,相对提升34.3%。
更关键的是,这多出来的194道并非随便换个框架就能撞上。759道至少被一个框架解出的题里,288道只有唯一一个框架解得开:Terminus 2独占129道,RSRT独占91道,StateM独占68道。另有163道要靠两个框架凑齐,剩下308道三个框架都能解。
这说明三套框架之间不是强弱排序,而是各占各的山头。RSRT在脚本自动化类任务上覆盖率达35.7%,StateM在软件开发调试类任务上领先,覆盖率26.2%,Terminus 2则在版本控制和部分科学计算任务上更占便宜。
团队还专门排除了“跑得多自然解得多”这个干扰项。把尝试次数控制成一样再统计,复杂性依旧在:三框架并集的解题量仍比单一最强框架多23.5%,每个框架照样贡献自己独有的解法。
开头那个疑惑到这里也就有了答案:三套框架并不是在抢同一批题的解法,它们是用完全不同的策略,摸任务空间里不同的角落。
可要是把这些解法直接喂给模型,问题就来了
三套框架并用能多解出194道题,那把这些成功的解题记录直接交给模型去学,模型是不是就能掌握这些本事?
结论是:远没有这么容易。
研究人员尝试了直接拿轨迹做监督微调(Direct SFT,也就是把成功案例直接喂给模型训练),结果有好有坏。自建的高难度基准(TBH)上提升了17个百分点,可另一个基准TB2上却下滑3.6个百分点,平均通过率从51.7%掉到43.8%。
症结在哪里?
一条成功轨迹并不全是模型自己的本事,里面掺杂了外壳干预的痕迹。以RSRT框架为例,系统会不停提醒模型"你错了,回头看看",这种反复试错的轨迹往往上百步。模型照单全收地学,除了解题思路,还把"反正能无限重试"这种离不开外部支持的习惯一并学了进去。研究人员查看训练后的模型输出时,确实发现了死循环:没有外部验证器反复提醒,模型就在同一个动作模式里绕圈,出不来,任务最后失败。
打个比方,一个学生刷题时总有老师在旁边随时纠错,他的思路就严重依赖"老师马上会告诉我错在哪"。真到了独立考试、没人提醒的场合,他反倒比没刷过这些题的同学考得差——他已经习惯了那种拐杖式的反馈节奏,拐杖一撤就站不稳。
直接训练这条路走不通,那换什么办法?研究团队给出的方案是:不要直接抄答案,而是把解题过程重写一遍,放进模型最终要用的那套"裸装"框架里重新做,做对了才算数。
论文真正的核心创新就在这里:Recursive Self-Rewrite(递归自我重写,论文简称RSR)。
递归自我重写:撤掉拐杖,让模型独立再走一遍
RSR分三步走,每一步都由同一个模型扮演不同角色来完成,全程不依赖任何外部更强的模型。
第一步是规划。模型扮演规划者(planner),面对之前某个框架留下的成功轨迹,把关键步骤、检查点、常见的坑提炼出来,写成一份"操作手册"(runbook)。手册只讲方法和路径,不写最终答案。比如任务是重建某种文件格式,手册会写"先找一个兼容的解析器,再对照输出摘要做校验,再探测关键参数",而不会直接给出最终文件内容。
规划者*:模型扮演的第一个角色,负责把原始解题过程压缩提炼成一份不含答案的操作指南。
第二步是审查。模型切换为评审者(critic),专门检查上一步的操作手册有没有泄密。泄密分两种:直接漏了答案本身,或者漏了验证器内部的检查逻辑——相当于把评分标准偷偷告诉了考生。审查分两层,先过规则检查(格式对不对、有没有引用根本不存在的工具),再让模型自己当裁判,只给它看公开的任务描述和这份手册,判断有没有越界。一旦查出泄密,手册被打回重写,最多重写若干次。
评审者*:模型扮演的第二个角色,专门挑出操作手册里是否藏了不该出现的答案或验证逻辑,发现问题就打回重写。
第三步是重新执行。模型换上执行者(executor)的角色,拿着审查通过的手册,在一个全新的干净沙盒环境里,用最普通的Terminus 2框架把这道题再解一遍。手册只是私下给模型参考,不会写进最终训练数据,模型必须照着手册的指引,自己一步步敲命令、看反馈、调整策略,把整道题重新做出来。
这个环节最妙的地方在于,它逼着模型"脱离拐杖重新学走路"。原来那条成功轨迹里混着外壳给的各种提示和干预,现在被抽象成一份纯方法论的指南,模型得靠自己的能力把它转化成真实操作。手册里没有答案,只有路标。
这就像去一座没去过的城市旅游:一种方式是朋友把逐字逐句的导航发给你,你照着念就能走到目的地,可下次换个地方你还是不会自己认路;另一种方式是朋友只告诉你"这片区域地铁比公交快,换乘站记得看指示牌颜色,出站口附近常有小吃摊可以问路",你得自己根据这些提示实地判断方向、处理突发状况。后者走起来慢一点,但你是真的学会了在陌生城市找路,下次换个城市也能照这个思路摸索。一直给你逐字路线,你永远是个"没有导航就寸步难行"的游客。
重写完成后还得再过一关:假如重放出来的轨迹里冒出了某个数值或结论,而模型既没法从任务描述里推出来,也得不到环境反馈的支持,那基本可以判定是答案泄露,这样的轨迹会被直接丢弃。能保留下来的训练数据,必须同时满足两点——真正通过了任务验证器的检查,且没有泄密痕迹。训练时也只留公开的任务指令、环境反馈和模型回答,原先的操作手册和评审对话统统删掉。
一道题,能重写出好几种新练习
重写过程并非只做一次。
研究团队对每条成功的原始轨迹生成了K=4份不同的操作手册候选,每份手册又各自跑M=4次独立执行,等于一条原始成功经验最多能衍生出16次重新练习的机会。
最终跑出12893条重写轨迹,覆盖975道不同的题目,其中86%通过验证,留下11094条高质量轨迹,比原始的2001条成功轨迹膨胀了超过5倍。
论文里举了两个具体案例,挺能说明问题。
Markdown格式解析是第一个案例。RSRT框架给出的原始轨迹足足用了64轮对话才完成,期间在兼容性问题上反复纠缠,还不断调用同一个工具试错。重写以后,12次独立尝试中有7次成功,占58.3%;这些成功轨迹的中位数只需32轮,比原来少了一半。不过重写并非次次奏效,有些轨迹拿着同一份操作手册,走到中途照样翻车。可见手册的作用是让模型绕开早期的摸索阶段,而真正难啃的解题部分,仍然得模型自己解决。
第二个案例是OpenFOAM流体仿真重建,出自StateM框架。原始轨迹跑了38轮,重写之后8次尝试成功7次(87.5%),中位数29轮。重写轨迹把原解法里“分析输出、修改实现、反复检验”这套管用的思维习惯保留了下来,只把具体执行方式换成了通用框架能读懂的命令。
团队还比较了同一份操作手册生成的多条轨迹在命令层面的相似度。结果,同手册轨迹的命令重合度和执行顺序相似度都明显高于不同手册的轨迹。以Markdown案例为例,同手册轨迹的精确命令重合度为19.1%,不同手册只有12.1%。手册确实在实实在在地塑造执行路径,并非走个形式。
训练结果:换了套重写方式,模型真的变聪明了
设计细节说了这么多,最终还得看训练出来的模型表现如何。
研究团队用同一个Qwen-3.8-27B底座模型对比了三个版本:没训练过的原版(Base)、直接用原始成功轨迹微调的版本(Direct SFT),以及用RSR重写轨迹微调的版本(RSR)。
评测覆盖多个基准:Terminal-Bench系列(TB2、TB3、TB4)、自建的高难度基准Terminal-Bench Hard(TBH)、自建的软件类基准(SWR100),以及专门考察长程任务推理过程质量的Long-Horizon Terminal Bench(LHTB)。
| 基准 | 指标 | 原版Base | 直接微调 | RSR重写微调 |
|---|---|---|---|---|
| TB2 | pass@3 | 57.0% | 53.4% | **74.2%** |
| TB3 | pass@3 | 0.0% | 5.4% | **9.5%** |
| TB4 | pass@3 | 1.5% | 4.5% | **9.1%** |
| TBH(自建) | pass@3 | 39.0% | 56.0% | **63.0%** |
| SWR100(自建) | pass@3 | 3.0% | 3.0% | **6.0%** |
| LHTB(自建) | 过程奖励分 | 0.21 | 0.25 | **0.29** |
pass@3*:模型尝试三次,只要有一次做对就算通过,衡量的是模型在多次尝试里的最高水平。
过程奖励分*:不只看任务最后有没有完全做对,还会给执行过程中的局部进展打分,用来衡量模型在超长任务里有没有真正朝正确方向推进。
RSR在所有基准上都压过了直接微调的版本。TB2高出20.8个百分点,TBH涨了7个百分点,连一向最难啃的TB4(原版只有1.5%)也从1.5%翻到9.1%,是原来的六倍。前面提到Direct SFT在TB2上反而不如原版,这个问题在RSR这里被彻底扭转:不但没掉分,还涨了17个百分点。
这组数据说明一件事:经验本身有价值,但得经过“消毒”才能安全地喂给模型。直接吃生肉可能会拉肚子,煮熟了再吃才真正能长肉。
写在后面
论文读下来,最抓人的倒不是RSR这条流水线设计得多巧,而是那组“消毒前后判若两人”的实验数据。原版模型在TB2上能到57%,拿成功经验直接微调,分数反倒跌到53.4%。这个反常识的掉分,比后面所有涨分的数字都更说明问题。它点出一件常被忽略的事:训练数据好,不等于把正确答案攒齐了;一条标成“成功”的轨迹里,很可能藏着不少让模型学坏的隐性依赖,比如对路径的依赖——依赖外部反馈,也依赖无限次重试的机会。这些东西在原始框架里是隐形的安全网,训练时没拆掉,等模型部署出去,安全网没了,它反倒比没学过的时候更脆弱。
还有个细节挺耐人寻味:同一个270亿参数的模型,只换一套外壳,同一道题就能从不会变成会。研究团队发现了这一点,也等于在追问“模型能力到底指什么”。平时说某个模型“能不能解决某类问题”,默认讲的是模型加上它惯用那套工具链之后的综合表现,而非参数本身的孤立本事。这篇论文某种程度上是在说,脚手架和模型权重之间的界线,比我们直觉里以为的要模糊得多。
论文也没回避没解决的问题:在LHTB这个长程任务基准上,三个版本的模型完全解决率都是0;RSR带来的0.21到0.29的提升,不过是“过程更朝着正确方向走了一点”,离真正啃下这类超长任务还差得远。这就引出一个更本质的问题:任务长到一定程度,经验重写这条路还够不够用?还是说得另找一种全新的训练范式,专门对付超长周期的任务?
Q&A
Q1:Recursive Self-Rewrite是什么?
A:这是腾讯团队提出的一种训练方法:先让模型在不同执行框架下解出更多难题,再把其中的成功经验提炼成不含答案的操作指南,然后让模型在通用框架下重新独立解一遍,只把真正验证通过的新轨迹留下来,用于训练模型本身。
Q2:为什么不能直接把不同框架解出的成功案例拿去训练模型?
那为什么不把这些框架跑出来的成功轨迹直接喂给模型训练?问题在于轨迹里夹着框架自己给的外部支持,像反复提醒重试这类机制就是。模型照着学,容易依赖上这些外部拐杖,放到普通框架下反倒更差。实验里在TB2基准上直接微调,得分没升,反而降了。
那三套不同的执行框架,凭什么能解出更多题?
关键在于Terminus 2、StateM和RSRT各管一摊:StateM长于软件开发调试,RSRT长于脚本自动化,各自能解的题目范围并不重叠。三套合起来,比单用任何一个框架多解出34.3%的题目。