你有没有想过这样一件事：现在市面上那些能帮你写代码、订机票、整理文档的AI助手，比如Claude Code、OpenClaw，它们背后驱动的大语言模型，到底是怎么"学会"熟练使用这些工具的？
大部分人可能觉得答案很简单：模型本身够聪明就行了。但事实并非如此。
一个反直觉的现象是：即便你换上了目前最强的大模型,如果它没有针对某个具体的工具执行系统专门训练过，它在这个系统里的表现可能远不如一个经过针对性强化学习训练的、参数量小得多的模型。这就好比给一个从没开过手动挡的老司机一辆赛车,再厉害的驾驶直觉,也得先磨合几百公里才能跑出好成绩。
这篇来自中国人民大学高瓴人工智能学院和IQuest Research联合团队的论文,研究的正是这个问题：怎么让大模型在这些复杂的"驾驶舱"里，通过强化学习真正学会开好车。
先搞懂"外壳"是个什么东西
要理解这篇论文在解决什么问题,得先弄明白一个概念。
**智能体外壳**：英文叫Agent Harness,你可以把它理解成大模型和真实世界之间的一层"操作系统"。模型本身只会生成文字,但它没法直接打开文件、执行代码、访问网络。外壳负责把模型的想法翻译成实际动作,管理上下文、调度工具、处理失败重试,是连接"脑子"和"手脚"的中间层。
像Claude Code、OpenAI的Codex、OpenClaw这些产品,本质上都是精心设计的外壳系统。它们把系统提示词、工具接口、上下文管理、失败恢复机制全部打包成一个统一的运行环境,让模型能应对更复杂、更长链条的任务,比如修复一整个代码仓库,或者从头到尾配置一套系统。
这些外壳做得越来越复杂、越来越智能,这本来是件好事。但问题也随之而来：这些外壳的内部逻辑,往往是不透明的。
想象你要教一个新员工用公司的CRM系统。这个系统里有各种自动化脚本、审批流程、隐藏的业务规则,你作为培训师根本看不到系统内部是怎么处理每一次点击的,你只能看到员工点了什么按钮,系统弹出了什么结果。如果你想通过"观察员工操作,给出反馈"这种方式训练他更好地使用这个系统,你面对的信息本身就是不完整的、被系统层层加工过的。
这正是论文要解决的核心矛盾。传统的强化学习训练,通常假设你能完整看到"模型说了什么、环境返回了什么"这样一条清晰的因果链条。但当外壳变得像Claude Code这么复杂之后,模型的一次调用可能被外壳拆分、重试、转发给子代理去处理,甚至同一个任务被系统内部悄悄执行了两次,你拿到的只是一堆零散的、甚至相互矛盾的记录碎片。
在这种情况下做强化学习,业内把这种思路叫做**黑箱强化学习**：把外壳的内部控制逻辑当作一个完全不透明的黑盒子,不去试图理解或修改它内部是怎么工作的,只在模型和外壳的交界处收集数据、进行优化。这已经成为让大模型真正用好这些复杂外壳系统的关键技术路径,但此前这个方向的探索还相对空白。
这篇论文要回答的问题就是：怎么才能在这样一个黑箱系统里,稳定、可扩展地训练出更强的智能体。
三座大山
作者团队把这个问题拆成了三个具体的技术挑战,咱们一个个看。
第一座山是基础设施问题。真实的智能体任务,不是那种"问一句答一句"的简单对话,而是需要一个持续存在、带状态的运行环境。模型可能要连续操作几十步,过程中不断修改文件、启动进程、调用外部服务。要做强化学习,你得同时跑成百上千个这样的环境副本,而且长时间运行的任务里,任何一步卡顿或者报错,都可能让前面几十步的努力全部作废。
第二座山是训练效率和一致性问题。前面提到,黑箱外壳吐出来的调用记录是碎片化的、分叉的、还经常有重复。这些原始记录没法直接拿来训练,得先想办法把它们拼回一条条完整的对话链路。更麻烦的是,外壳内部的各种转换处理,还可能悄悄改变模型输出的表示形式,导致你训练时用的数据和模型实际生成时的数据对不上,这种"训练和推理不一致"的问题一旦出现,整个训练过程可能直接崩掉。
第三座山是扩展性问题。市面上的外壳系统五花八门,协议不同、工具接口不同、上下文管理策略也不同。如果每换一个外壳就要重新设计一套训练流程,这套方法就没有推广价值了。
针对这三个问题,研究团队搭建了一整套统一的黑箱强化学习框架。接下来就是这篇论文真正有意思的部分。
沙盒:给每次尝试一个隔离的房间
先看基础设施怎么解决。
**沙盒**：Sandbox,一种临时的、隔离的运行环境。每次执行任务前现场搭建,任务结束后立刻销毁,专门用来防止不同任务之间互相干扰。
具体做法是,针对每一个任务,系统会从初始工作区出发,现场搭建一个专属的运行环境,把外壳装进这个临时沙盒里跑。沙盒用完就扔,资源可以按需伸缩。除此之外,沙盒里还内置了一些标准化的工具接口,叫**模型上下文协议**（Model Context Protocol,简称MCP,一种让外部工具能被模型统一调用的标准接口）,方便接入网络搜索之类的通用能力,而不需要改动外壳原本的工作流程。
这个设计的价值,你可以类比成医院里的一次性手术器械。如果每次手术都用同一套没消毒的器械,一旦某个环节出了感染,后续所有病人都会受影响,而且你根本查不出来是哪次手术留下的问题。用完即弃的隔离环境,恰恰是为了保证每一次"手术",也就是每一次任务执行,都是从干净状态开始的,出了问题也只影响这一次,不会污染整个训练批次。如果不这么做,几千个并发跑的任务互相踩踏,训练数据里混进的噪声可能比有效信号还多。
代理服务器：在黑箱边界上偷听
基础设施问题解决了,接下来是更核心的问题：既然外壳内部看不见,那到底该在哪里"偷听"模型的行为?
答案是模型和外壳交互的那个边界点。不管外壳内部逻辑多复杂,模型每一次生成动作,本质上都必须通过一次"模型请求"发出去,这个请求必然要跨越外壳和模型服务之间的那条边界线。
论文的做法是,在这条边界线上架设一个**代理服务器**：Serving Proxy,一个伪装成模型接口、实际上会记录每次请求和响应细节的中间层。
这个代理服务器假扮成模型本身,接收外壳发来的每一个请求,调用当前正在训练的策略模型生成回应,再把结果按外壳期待的格式传回去。与此同时,它偷偷把这次调用的输入token、输出token、生成概率等所有训练需要的信息记录下来。外壳完全不知道自己在被"偷听",它按自己的逻辑正常运转,系统对它是完全无感的。
这就好比你想研究一个黑箱工厂的生产效率,又不能进厂拆开设备看内部构造。这时候最聪明的做法不是硬闯进去,而是在原料入口和成品出口各装一个记录仪,只要进出的东西被完整记下来,你依然能做出很多有价值的分析,而且完全不影响工厂原本的运转。如果非要闯进去改造设备内部逻辑,一来风险极高,二来换个工厂又得重新改造一遍,根本没法规模化。
前缀树：把碎片拼回完整的故事
代理服务器记下来的原始数据,还只是一堆零散的调用记录。真正棘手的问题来了：怎么把这些碎片重新组织成完整的、可训练的多轮对话。
这里论文提出了一个很巧妙的数据结构,叫**前缀树**：Prefix Tree,一种树形结构,共享的历史内容只存一份,不同分支各自延伸出去,常用来高效表示大量有公共前缀的序列数据。
具体逻辑是这样的：一次任务执行过程中,后面的模型调用通常是在延续前面调用建立起来的对话历史。但有些时候,外壳会做上下文压缩,或者派生出一个子代理去处理某个子任务,这时候相当于从某个中间状态另起一段新的对话分支。系统会把所有调用挂到一棵以初始任务指令为根节点的树上,通过比对每次调用的输入内容和前一次调用积累的历史,把它们准确地接到树上对应的位置,同时还能倒推出外壳在中间悄悄插入的工具执行结果之类的非模型内容。
树上那些没有再被延伸的调用,叫做叶子节点。每一条从根到叶子的路径,就构成了一条候选的完整训练轨迹。
这个结构的妙处在于,它天然避免了重复存储。想象你在写一篇有很多分支剧情的小说,前面80%的情节是共享的,只是结局根据不同选择分成了三个版本。你肯定不会把前面80%的内容抄三遍,而是共享同一段主体,只在分叉点之后各写各的结局。前缀树做的正是这件事,共享的历史只存一次,不同的后续走向各自作为独立分支保留。如果不这么处理,直接把每条完整轨迹当独立数据存储和训练,不仅浪费大量存储和计算资源,还会导致训练时对共享历史的内容被反复计算权重,让分叉多的任务在梯度更新里占据不成比例的话语权。
三重过滤：把噪声筛出去
树建好了,不代表所有叶子节点都值得拿去训练。论文里详细描述了三类需要过滤掉的情况。
第一类是死叶子。有时候推理服务重试了一次请求,或者外壳发现某次工具调用格式不对,让模型重新生成,这些被放弃的旧版本依然会挂在树上,变成没有下文的死路。系统会在每个交互段落里,只保留延续最长、最有效的那条路径,把这些半途而废的分支剪掉。
第二类是过度分叉的任务。如果某次任务执行过程中,树莫名其妙分出了一大堆叶子节点,这通常意味着系统陷入了某种重复失败的循环,而不是正常的任务分支。一旦叶子数量超过设定的阈值,这整次执行的数据就会被直接丢弃,宁可牺牲一点数据量,也不能让这种坏信号混进训练里。
第三类是辅助轨迹的排除。子代理执行的过程,或者上下文压缩产生的分支,它们在整个任务里扮演的角色和主线任务本身不一样,如果把最终的任务奖励原封不动地分配给这些辅助分支,会造成一种模糊不清的责任归属问题。论文选择只训练主线智能体的轨迹,辅助交互暂时不参与优化,这是留给未来工作的一个方向。
这三重过滤,某种程度上像是一个编辑在审阅一堆采访录音转写稿。有些是重复录制的失败版本,直接删掉;有些是采访对象跑题跑得太离谱,整段作废;还有一些是助理帮忙补充的背景资料,虽然有用,但不能算作被采访者本人说的话,得单独标注处理。经过这样的编辑,剩下的才是真正能拿去发表的、干净的核心内容。
PPO和GRPO怎么套进树结构里
过滤完毕的树,接下来要拿去做强化学习优化。论文对两种主流算法都做了适配。
**近端策略优化**：Proximal Policy Optimization,简称PPO,一种依赖额外价值模型来估计每一步价值的强化学习算法,是critic-based方法的代表。
**组相对策略优化**：Group Relative Policy Optimization,简称GRPO,一种不需要单独价值模型、而是通过同一任务下多次采样结果互相比较来估计优势的算法,是critic-free方法的代表。
对GRPO来说,适配相对自然。它本来就是靠同一任务下多次采样的结果互相比较来算优势值,所以论文直接把某个任务的所有执行结果作为一个组,组内奖励做归一化,得到的优势值分配给这次执行里所有保留下来的轨迹节点,共享前缀部分的token只计算一次损失,避免分叉多的执行拿到过多的优化权重。
PPO则复杂一些,因为它依赖价值模型来估计每一步的优势,如果真要完整建模分叉轨迹之间的依赖关系,计算会变得极其复杂。论文选择了一个简化方案：把同一次执行里分出来的多条轨迹当作相互独立处理,每条轨迹在自己的终点拿到那次执行的最终奖励,单独往回做优势估计,分支点之间不传递信号。这个简化的代价是,价值模型得学会从中间状态直接估计长程回报,而且因为没有做时间上的折扣衰减,估计的方差可能会更大一些。论文也坦诚地说,对分叉轨迹更严谨的处理方式,留给了未来的研究。
训练和推理必须"说同一种语言"
这里涉及一个容易被忽视但极其关键的技术细节。
强化学习的一个基本要求是,你训练时用的token序列,必须和模型实际采样生成的token序列完全一致。但在黑箱环境里,外壳经常会对模型输出做各种转换处理,比如把工具调用格式标准化、重新序列化助手消息。如果你简单地把重建出来的对话轨迹重新分词,编码的其实是外壳加工过的内容,和模型当初真实采样出来的token可能已经不是一回事了。
论文采用的方案叫**黑箱token进token出**机制：一种保留两套并行视图的做法,一套是模型采样时生成的原始token,直接进树用于训练,另一套是解码出来给外壳使用的结构化文本,只负责驱动外壳运转,永远不会被反向编码进训练数据。
这个设计逻辑其实挺直白的：不管外壳怎么加工、怎么美化显示的内容,那些改动都只发生在外壳自己看到的那个版本上,永远碰不到真正拿去训练的token记录。两条线各走各的,谁也不干扰谁。
光是token序列一致还不够,还有一个更隐蔽的问题：同一个token,在生成它的那个推理引擎里算出来的概率,和训练引擎重新算一遍算出来的概率,可能因为数值精度、计算内核、并行方式的差异而对不上。论文引入了**token级别的重要性采样修正**：一种通过计算训练时重算概率和推理时记录概率之间的比值,来修正这种系统性偏差的技巧,同时设定一个上限阈值,防止个别异常比值把方差搞得太大。
这套精细的一致性保障,类比起来有点像跨国视频会议里的同声传译。如果翻译员翻译的内容,和发言人实际说的话有细微出入,一两次可能没什么大碍,但如果这种偏差在每一句话里持续累积,几十分钟下来,会议记录和实际发言内容可能已经差出十万八千里,最后基于这份记录做出的决策就会建立在错误的基础之上。强化学习训练也是同样的道理,哪怕每一步的偏差都很小,几百步优化下来,这种偏差累积起来足以让整个训练过程失去稳定性。
混合外壳训练：一个模型伺候多个"老板"
前面解决的都是单一外壳内部的问题,论文还往前走了一步,提出了**混合外壳训练**：Mix-Harness Training,让同一个模型在同一次训练里,同时接受来自多个不同外壳系统的数据来联合优化。
这个想法背后的顾虑是这样的：如果一个模型只在OpenClaw里训练,它很可能会过度适应OpenClaw特有的工具调用习惯和上下文管理方式,换到Claude Code这种协议完全不同的系统里,表现可能会打折扣。
具体实现上,论文把同一个任务,分别配上不同的外壳,形成不同的"任务-外壳"训练实例。这些来自不同外壳的实例会被随机打乱,混在同一个训练批次里一起处理。唯一需要特别注意的是分组统计,GRPO计算优势值时要按组内统计量归一化,如果把不同外壳产生的奖励混在一起统计,会因为不同外壳本身难度和奖励分布不一样而扭曲相对优势的计算,所以论文选择按"任务-外壳"这个更细的粒度来分组,保证组内数据具有可比性,同时让所有组的梯度共同更新同一个策略模型。
这套设计,可以类比成培养一名能同时胜任中餐和西餐烹饪的厨师。如果只在中餐后厨训练,厨师可能会把"用中式炒锅颠勺"这个动作当成理所当然的固定套路,一旦换到西式厨房用平底锅,反而手足无措。而如果从一开始就交替在两种厨房里练习,同时确保每种菜系内部的评分标准是独立公正的,厨师最终掌握的会是更底层的、可迁移的烹饪判断力,而不是某一种厨房设备的使用习惯。
实验结果说话
理论说了这么多,最终还是要看数据。论文用Qwen3-30A3B作为基座模型,分别在OpenClaw和Claude Code两个外壳下做了完整实验。
| 训练方式 | 评测基准 | 起始分数 | 训练后分数 | 提升幅度 |
| OpenClaw黑箱RL | ClawGym-Bench | 52.64 | **62.62** | +9.98 |
| OpenClaw黑箱RL | PinchBench | 75.61 | **87.32** | +11.71 |
| Claude Code黑箱RL | ClawGym-Bench | 37.06 | **51.87** | +14.81 |
| Claude Code黑箱RL | PinchBench | 54.14 | **71.42** | +17.28 |
从数字上看,不管是从冷启动模型出发,还是直接从原始基座模型出发训练,黑箱强化学习都带来了实打实的提升。更值得一提的是,在OpenClaw这条线上,经过训练的30A3B模型,居然反超了参数量大得多的Qwen3-235A23B模型8.14个百分点,这说明针对性的强化学习训练,有时候比单纯堆参数量更有性价比。
论文还专门测试了训练过程的稳定性,PPO和GRPO两种算法在200到400步的优化过程中,训练奖励和评测分数都呈现稳步上升的趋势。PPO的策略熵变化相对平稳,GRPO则波动更大一些,尤其在OpenClaw设置下出现了训练后期熵值下降的现象。作者也观察到,Claude Code这条线因为没有经过冷启动预训练,整体熵值起点更高,这提示冷启动阶段确实能提供更好的初始行为先验,让后续优化更平稳。
混合外壳训练的实验结果也很有意思。混合训练出来的模型,在两种外壳下的评测表现,都能追平甚至略微超过分别单独训练的模型,说明来自异构外壳的学习信号,确实可以被一个共享策略同时消化吸收,没有出现互相拖累的情况。
论文进一步把这套框架推广到了两个更具挑战性的任务场景。一个是**JobBench**：一个模拟真实职场工作流的评测基准,任务环境里混杂着图片、数据库、办公文档等多种异构文件格式,另一个是**OfficeQA**：一个侧重从大规模文档语料中检索证据、做多步推理并给出可验证答案的评测基准。在这两个全新的任务分布上,黑箱强化学习依然带来了明显提升,JobBench-Easy上的评测分数从20.46提升到27.20,OfficeQA-Full上则从8.53提升到21.54。这说明这套框架不是只能在ClawGym这一个特定任务集上生效的定制方案,而是具有相当的通用性。
论文还专门做了一组对照实验,比较黑箱强化学习和白箱的AgentLoop强化学习。所谓白箱,就是研究者自己从零搭建一套完全透明可控的智能体交互循环,包括系统提示词、工具接口全部自己设计。实验发现,在同样的白箱环境里评测,白箱训练出来的模型表现明显更好,达到59.90分,超过黑箱训练的模型8.53分。但反过来,把白箱训练出来的模型拿到外部的OpenClaw环境里测试,它虽然相比原始基座模型有提升,却依然明显落后于直接在OpenClaw里训练出来的模型,差了12个百分点以上。这组对比说明一件挺现实的事情：不同外壳系统之间确实存在一些可以迁移的通用能力,但真正针对某个具体外壳的、细致入微的交互习惯,还是得在那个外壳里亲自训练才能学到位。
写在后面
读完这篇论文,一个挺触动我的细节是白箱和黑箱训练那组对照实验的结果。很多人可能会本能地觉得,既然白箱训练出来的模型在自己的环境里表现更强,那干脆所有训练都改成白箱得了,何必费劲去解决黑箱里的种种技术难题。
但现实是反过来的。市面上真正被大规模使用的智能体产品,像Claude Code、Codex,它们的外壳设计本身就是产品的核心竞争力,包含了大量经过实战打磨的细节,失败重试逻辑、上下文压缩策略、子代理调度机制,这些东西你没法简单地在自己的白箱环境里复刻出来。所以黑箱强化学习不是一个"退而求其次"的妥协方案,而恰恰是唯一能让模型真正吃透这些成熟产品级外壳的路径。
另一个值得琢磨的地方是,论文里提到的辅助轨迹排除,子代理和上下文压缩产生的分支目前被完全排除在训练之外。这些分支其实包含着系统在真实运行中处理复杂情况的宝贵信息,只是奖励分配的问题还没解决好。这块留白,或许才是这个方向接下来最有想象空间的部分。
Q&A
Q1：黑箱强化学习和普通强化学习有什么区别？
A：普通强化学习通常能完整观察模型和环境的交互过程,而黑箱强化学习面对的是像Claude Code这样内部逻辑不透明的复杂外壳系统,只能在模型和外壳的交界处收集数据,无法看到外壳内部具体是怎么处理每一次调用的。
Q2：这篇论文用的实验模型和外壳分别是什么？
A：论文以Qwen3-30A3B为基座模型,在OpenClaw和Claude Code两个结构完全不同的外壳系统上做了验证,同时还扩展测试了JobBench和OfficeQA这两个更具挑战性的任务场景。
Q3：混合外壳训练效果怎么样，会不会互相拖累？
A：不会。实验显示同时用OpenClaw和Claude Code两种外壳的数据联合训练一个模型,最终在两种外壳下的评测表现都能追平甚至略微超过单独用一种外壳训练的模型,说明来自不同外壳的学习信号可以被同一个策略模型有效吸收。
热门跟贴