WHALE：当AI智能体的"大脑"和"手脚"学会互相配合

你有没有想过一件事：一个厨艺很好的厨师，如果被塞进一个连锅碗瓢盆都摆错位置的厨房里，能做出什么好菜？

这听起来是个奇怪的问题，但它恰好点出了当下AI智能体研究里一个被长期忽视的角落。我们花了大量精力去训练模型本身，让它变得更聪明、更会推理，却常常忘了另一件事：这个模型运行的那套"外壳"，决定了它能不能把聪明发挥出来。

**这套外壳,论文里管它叫"harness",翻译过来大概是"控制脚手架"。**

harness*：指管理AI智能体运行的可执行代码，包括系统提示词、工具怎么调用、观察结果怎么进入上下文、出错了怎么处理、什么时候该结束对话。它不是模型本身，但决定了模型能不能正常发挥。

想象一个问答智能体,配了一个搜索工具。模型脑子里可能什么都知道，但如果harness写得很粗糙,搜索回来的文档被截断到只剩一百字，或者查询词从来没被优化过，那模型再强也用不上那些证据。反过来，harness设计得再精巧，检索再准，模型如果读不懂、不会归纳信息，那些精心检索来的资料也是白费。

这就是这篇论文的出发点:模型参数和harness代码,谁强都不算完,真正决定系统表现的,是两者配合的程度。

问题出在哪儿

过去的研究其实也意识到了"光调模型不够"这件事,但他们往往把可调整的范围局限在文字提示词(prompt)上。也就是说,大家会去优化系统提示词怎么写、用户提示词怎么措辞,但很少有人碰更底层的代码:工具接口怎么设计、上下文怎么管理、错误怎么兜底、什么时候终止对话。

这不是因为大家不想碰,而是因为直接搜索代码这件事,在过去技术条件下不太现实。直到最近,借助大语言模型做优化器的技术(比如让一个"元优化"的LLM去读代码、改代码、评估效果)才让这种大范围搜索变得可行。

那问题来了:既然模型权重能调,harness代码也能调,那要不要同时调?怎么调?

这里遇到的第一个麻烦是节奏不匹配。

**模型训练是"边采样边更新"的快节奏循环,而harness搜索是"提出候选、跑一批评测、挑最好的"这种慢节奏循环。**

如果把两者硬凑在一起同时跑,会出现一个很棘手的问题:你在评估一次harness改动好不好的时候,模型权重可能正在悄悄变化,你根本分不清这次改进是harness带来的,还是模型自己训练的功劳。这就像你想知道到底是换了新食材让菜变好吃了,还是厨师本身手艺进步了,如果这两件事同时发生,你压根没法归因。

论文的解法是交替进行:先固定harness,专心训练一段模型;再固定模型,专心搜索一段harness;然后重复。每一步只改一个变量,这样才能干净地知道"是谁的功劳"。

这套方法论文起名叫WHALE,全称是Weight-Harness Alternating LEarning(权重-脚手架交替学习)。

WHALE具体怎么运作

WHALE的核心其实很朴素:一个循环,里面套两个阶段。

第一个阶段是模型更新。论文用的是一种叫在线拒绝采样微调的方法。

在线拒绝采样微调(RSFT)*：让模型自己生成多条尝试轨迹，只挑那些被验证器判定为"做对了"的轨迹，用监督学习的方式喂给模型，让它往对的方向学。这个过程是在线的，意味着一边收集数据一边更新参数，而不是先收集完再统一训练。

打个比方,这就像让一个学生做很多套题,然后只把做对的那些题的解题过程整理成"标准答案"给他反复背,做错的直接扔掉不看。这种做法比强化学习里那种"根据对错给分再调整策略梯度"的方式简单粗暴很多,但胜在稳定,不容易训练崩掉。

第二个阶段是harness搜索,用的是一个叫Meta-Harness的方法。

Meta-Harness(MH)*：一种迭代式的harness搜索算法。它维护一个"档案库",里面存着历史上尝试过的各版本harness和它们的表现分数。每一轮,一个"提案者"(通常是另一个强力LLM,论文里用的是Claude Opus 4.7)会读取档案库里的记录和源代码,写出几个新的候选harness,拿去跑一遍评测,分数最高的那个被记录下来,循环继续。

这个过程有点像一个产品团队不断迭代APP界面:每次改版都参考之前所有版本的用户反馈,可以推翻某次改版重新采用更早的设计,也可以在现有基础上小修小补。档案库的存在意味着搜索不是盲目试错,而是有记忆的。

两个阶段交替进行,就是WHALE的主体。

关键的设计问题来了:每个阶段该跑多久才切换?

论文给出两种方案。一种是固定时长,比如每轮模型训练固定跑0.6个epoch,harness搜索固定跑6轮迭代,这个数字是通过实验调出来的。另一种更聪明,叫自适应WHALE,它不预设固定时长,而是盯着训练信号本身:如果模型训练的奖励值连续一段时间不再提升,就该切换到harness搜索了;如果harness搜索的最佳分数连续几轮没有刷新纪录,也该切换回模型训练了。这套机制有点像家里的恒温空调,不是你手动设定"开半小时关半小时",而是它自己感知温度变化,该开就开,该停就停。

如果没有这套判断机制会怎样?论文里做了对照实验,答案很戏剧性:如果一个阶段跑得太久,比如把模型训练的全部预算一次性用完,再一次性跑完全部的harness搜索预算(论文管这叫"stagewise"分阶段优化),效果反而比小步交替更差。

领域不同,瓶颈也不同

论文在三个完全不同的任务领域上做了实验:搜索问答(SearchQA,需要检索维基百科文档来回答多跳问题)、数学推理(用Python代码辅助解题的AIME竞赛题)、还有国际象棋残局解谜。

结果发现一个挺有意思的现象:不同领域里,到底是模型能力不够,还是harness设计不够,答案完全不一样。

在SearchQA任务里,论文发现harness搜索能用远远更少的计算量,达到模型训练很久才能达到的准确率,大约只需要5.79%的算力就能追平。这说明在这个任务上,瓶颈更多在harness怎么设计上,比如怎么处理检索到的文档、怎么控制回答格式,而不是模型本身的推理能力不够。

但在数学推理任务上,情况反过来了。单独搜索harness几乎不起作用,只提升了0.42%的效果,而模型训练能带来15.42%的提升。这背后的原因很具体:模型有个坏习惯,写数学解题过程写得又长又啰嗦,经常写到把回复长度上限用完还没写完,直接被截断,连答案都给不出来。这种"话太多说不完"的毛病,不是靠改harness的规则能解决的,得靠训练让模型学会写得更精炼。

**但有意思的转折是,一旦经过一小段模型训练,原本对harness搜索无动于衷的数学任务,突然就对harness优化敏感起来了。**

具体数据是这样的:在WHALE的第一轮循环里,harness搜索只花了4608次尝试,就把格式正确率从0.83%提到了4.38%,提升了3.54个百分点。而如果单独跑harness搜索(模型完全不训练),花了46080次尝试,格式正确率只提升了0.63个百分点。差了整整十倍效率。

这说明一件事:模型能力和harness设计不是相互独立的两条线,而是互相解锁对方的潜力。就像一把锁配一把钥匙,钥匙不对,锁再好也打不开,但换一把稍微修过的钥匙,同一把锁瞬间就能转动了。这也是论文反复强调的核心逻辑:两个组件轮流训练,能催化对方原本被压抑的潜力。

交替优化为什么比"一次做完"更好

论文专门做了个对照实验,把"分阶段"(stagewise)和"小步交替"两种做法放在一起比。

分阶段的做法是:先把模型训练的全部预算花完(比如SearchQA里跑满4个epoch的预算区间,实际选中2.7个epoch作为最佳点),再把harness搜索的全部预算跑满(选中32轮作为最佳点),两段各自挑自己训练过程里表现最好的那个点。

结果这种做法在SearchQA上只拿到43.02%的准确率,在数学推理上只有15.63%。而WHALE用小步交替的方式,分别拿到48.34%和24.79%,分别高出5.32和9.16个百分点,而且只用了29%和49%的计算资源就已经超过了分阶段方法最终能达到的水平。

为什么会这样?论文给出的解释是"条件性过度优化"。

这个术语听起来抽象,但道理很简单。因为模型表现这个函数不是可以拆开独立优化的,你把模型往一个方向死磕很久,它会越来越适应当前这套harness的脾气,但这套harness很快就要被换掉了。等你换了新harness,之前那种"过度适应旧环境"的模型反而变得不那么合适了。

**这就好比一个人为了适应某个特定老板的沟通风格,花了整整一年时间调整自己的说话方式,结果老板换人了,新老板完全是另一种风格,之前那一年的"适应训练"反而变成了负担,得重新调整。**

如果不做交替,直接死磕到底会怎样?数学任务里那个例子很直观:60轮的分阶段harness搜索,训练分数一直在涨,看起来很有希望,但拿到测试集上一看,只比模型单独训练的效果多了0.21个百分点。大量的搜索资源被浪费在了对训练集过拟合上,没有真正转化成泛化能力。

那小步交替是不是越小越好?论文也测试了这个问题,答案是否定的。

论文对比了五种固定的调度方案,发现如果每轮切换得太频繁,比如harness搜索只跑2轮迭代就切换,反而会因为证据不足而选中一个"运气好"但实际不靠谱的候选harness,模型随后就跟着适应了这个错误的选择,整个训练过程会变得不稳定,论文里这个实验直接因为训练崩溃而提前终止了。

这说明理想的节奏介于两个极端之间:既不能死磕太久导致过拟合,也不能切换太快导致噪音误判。论文形象地把这个过程比作在山谷里找路:两头都是悬崖(过度优化和噪音干扰),真正的联合最优点藏在中间那条蜿蜒的谷底路径上,只有走得不快不慢,才能顺着谷底一步步走到底。

那这条路径的具体形状是什么样?论文给出的自适应WHALE其实就是在自动寻找这条路径,不需要人为预设"该走多快"。实验显示,自适应版本在SearchQA任务上取得了整个对比实验里最好的成绩,52.82%的准确率,比固定调度方案还要高出2.73个百分点,而且用的计算资源反而更少。在数学任务上,自适应版本比默认的固定调度(0.6,6)要好,但没能超过经过人工细致调参后找到的那个最佳固定调度。这也说明自适应机制不是万能的,但确实省去了大量人工调参的工作。

具体看几个真实案例

论文附录里给出了几个具体的对比案例,读起来还挺有意思。

有个搜索问答的例子,问题是"Octavie Coudreau的丈夫出生在哪里"。原始harness下,模型检索一次,发现文档提到了丈夫的名字叫Henri Coudreau,但没提到出生地,然后模型又搜了一次,结果这一轮的回复超出了限制的两轮对话预算,连答案标签都没来得及输出,直接判错。

而经过WHALE优化后的harness,允许模型最多三次搜索、四轮对话,还在提示词里加了一条硬性检查清单:每次检索之后,必须确认检索到的段落里是否明确写出了答案,如果没有就必须换一个角度再搜一次。同时,系统还会在每轮对话之间插入一句提示,列出目前已经检索过的文档标题,提醒模型别重复搜索同样的内容。最终模型成功找到了"Sonnac"这个正确答案。

另一个数学题的例子更能说明模型训练本身的作用。同一道题,原始模型在原始harness下,从头到尾都在用大段文字手动推演,写了两万多字,最后被截断,连一个boxed格式的最终答案都没写出来。而经过WHALE训练后的模型,面对完全相同的提示词(这道题的harness提示词其实没有任何改动),直接选择写一段Python代码去暴力枚举所有排列,算出结果后干脆利落地给出了答案,总共只用了三千多字。这个对比清楚地说明,这道题卡住模型的根本不是harness的问题,而是模型本身"该不该用代码"这个习惯没有被训练出来。

还有一个国际象棋的例子也很典型。原始harness把合法着法平铺列成一个长列表,模型在推理过程里引用了列表里的着法记号,却因为格式问题让解析器读出了21个候选着法,系统判定为"歧义,无法解析",直接判错。而优化后的harness把着法按棋子分组显示,还标注了哪些着法是将军、吃子或将死,并且明确规定"思考过程里出现的方括号着法只是草稿,真正生效的是最后一个着法标签"。同样的模型,面对这套更清晰的规则,顺利完成了一次将军加将死的组合,总共只用了800多个字符就解决了问题。

这几个例子放在一起看,其实印证了论文最核心的结论:同一个模型,配上不同的harness,表现能天差地别;同一个harness,配上训练前后的模型,表现也能天差地别。谁是瓶颈,取决于具体任务,没有放之四海而皆准的答案。

Q&A

Q1：WHALE是什么？

A：WHALE是一种交替优化AI智能体模型权重和执行代码框架(harness)的训练方法，通过先训练模型再搜索更优harness、再训练模型的循环，让两者协同提升，在搜索问答、数学推理、国际象棋三个任务上都超过了只优化单一部分的方法。

Q2：为什么不能同时训练模型和优化harness？

A：因为两者更新节奏不同，模型训练是快速的边采样边更新循环，harness搜索是慢速的提案评估循环，同时进行会导致评估对象一直在变化，无法分清改进究竟来自哪一方，容易产生错误归因。

Q3：一次性训练完模型再优化harness，效果为什么不如小步交替？

A：因为长时间只训练模型会导致模型过度适应当前的harness，后续harness一变模型反而不适应；长时间只搜索harness也会对训练集过拟合，论文实验显示小步交替能用更少计算量达到更高准确率。