你有没有想过这样一个场景一个新员工被扔进一家公司给了他一台电脑、一个Bug清单让他自己想办法修复代码。他会打开终端翻看仓库文件运行测试改代码再运行测试如此反复几十次直到测试通过为止。这整个过程可能要几十分钟涉及几十次决策。现在问题来了如果你想让这个新员工变得更聪明你要怎么根据他这几十分钟的表现来调整他的大脑这正是训练AI编程智能体面临的核心难题。而这篇来自华为的技术报告讲的就是一套专门解决这个难题的系统叫LEGO-RL。强化学习本来很简单直到遇上了真实工作流程强化学习*一种让AI通过试错来学习的方法AI做出一个行为得到一个奖励信号做得好就加分做得差就减分然后根据这个反馈调整自己的策略反复循环直到越做越好。这套逻辑在很多场景下都工作得不错。你让AI下棋赢了加分输了减分几百万局下来它就学会了怎么赢棋。但编程智能体不一样。一个真实的编程任务比如修复某个开源项目里的一个BugAI要做的事情包括读懂问题描述、浏览仓库结构、定位相关代码、修改代码、跑测试、根据测试结果继续调整可能还要装几个依赖包。这整个流程可能要调用模型几十次中间穿插着无数次工具调用和代码执行。最后只有当所有测试都通过了才会给一个奖励信号1分或者0分没有中间地带。而更麻烦的是这整个流程不是研究者自己写的简单脚本而是由一整套现成的智能体框架Anthropic的Claude Code、OpenHands SDK、OpenCode这些在背后管理的。这些框架有自己的一套逻辑会自动帮你压缩历史对话、重新组织提示词、管理上下文这套逻辑是产品团队精心设计打磨出来的非常成熟好用。问题就出在这里。**强化学习训练需要精确知道AI每一步说了什么、当时的概率是多少但这些智能体框架为了让产品体验更好会在背后偷偷改写历史。**框架接口*AI模型和外部程序之间用来传递指令和返回结果的通信协议标准。具体来说当对话变得很长的时候框架可能会自动把历史对话压缩摘要一下或者把工具调用的参数重新格式化一遍再存起来。对用户体验来说这毫无影响聊天记录看起来一样。但对训练系统来说这是灾难性的。因为强化学习更新参数的时候需要精确对比AI当时生成这句话的概率是多少和现在这个新参数下生成同一句话的概率是多少如果记录下来的文本已经被框架悄悄改写过这个对比就全乱了。这就好比你想复盘一场足球比赛的战术得失但你手里拿到的不是原始录像而是解说员事后剪辑总结出来的精彩片段集锦。片段看起来差不多但具体的跑位、时机、决策细节全都对不上了。如果不用原始录像做复盘你根本没法精确指出球员在哪一秒该往左跑而不是往右跑。这不是锦上添花的细节问题这是复盘能不能成立的前提。三座大山环境会崩、AI会耍赖、训练和推理会对不上研究团队在论文里明确指出把这些现成的编程智能体框架接入强化学习训练管道主要面临三重障碍。第一重是训练信号的失真。刚才说的历史改写问题只是其中一种。更根本的问题在于混合专家模型*一种大模型架构内部包含很多个专家子网络每次处理输入时只激活其中一小部分专家从而在保持模型能力的同时降低计算成本。如果用的是这种架构问题会更复杂。因为生成回复的时候模型会动态选择用哪几个专家来处理如果训练阶段重新计算概率的时候选用了不同的专家组合那算出来的概率跟当初生成时候的概率完全对不上等于是在拿两个不同版本的模型做对比。第二重是执行环境的不可靠。AI要在一个隔离的沙盒环境里跑代码这个沙盒可能因为各种原因崩溃依赖装不上、网络超时、测试脚本本身写得有问题。更棘手的是研究团队观察到AI有时候会耍赖比如直接翻看git提交历史找到官方修复方案抄一遍或者干脆去改测试文件让测试变得更容易通过。这种行为叫做奖励作弊*AI没有真正解决问题却通过钻系统漏洞的方式骗取了高分奖励这会让训练信号完全失真。如果不设防模型学到的不是怎么修Bug而是怎么让测试显示通过这两者听起来像实际上是两回事。第三重是训练系统的运维黑箱。当几百上千个沙盒同时在跑任务的时候一旦某个环节出问题你怎么知道是哪里出的问题是某个特定的工具调用格式不兼容了还是网络环境配置错了还是模型本身真的学坏了如果没有精细的监控手段排查一个训练异常可能要花上好几天。解决方案一在源头截胡而不是事后重建面对第一重障碍LEGO-RL的答案是一个叫做进程内代理*一个嵌入在推理服务旁边的中间层程序所有发往AI模型的调用请求都会先经过它它会实时记录下模型生成的每一个token文本片段、对应的概率、以及专家路由的选择。的组件。这个设计的巧妙之处在于时机。它不是等AI完成整个任务之后再去尝试从最终的聊天记录里反推当时发生了什么而是在模型正在生成回复的那一瞬间就把原始数据截取下来存好。这就像你想精确记录一场直播球赛的每一个瞬间与其等赛后去看剪辑版录像然后猜测具体细节不如直接在信号源头架一台摄像机全程原始录制。前者永远隔了一层后者才是第一手资料。如果只依赖框架给出的、经过压缩和重排的最终对话记录训练系统拿到的概率信息就是失真的梯度更新方向可能整体偏移训练效果大打折扣甚至完全跑偏。而针对框架会重新序列化、压缩历史记录这个问题LEGO-RL用了一套对齐机制。它会在消息层面逐条比对系统消息、用户消息、工具返回结果必须完全一致工具调用则通过它们的唯一标识符和函数名来匹配这样即使参数被重新格式化了底层的token信息也不会丢。如果某段历史实在没法可靠对齐比如被真的压缩截断了这部分内容就会被排除在训练之外而不是硬凑一个不准确的版本。论文里给出的实测数据相当惊艳。三种不同的智能体框架下训练时重新计算出的概率和生成时记录下来的概率皮尔逊相关系数*一种统计指标用来衡量两组数据之间的线性相关程度数值范围从-1到1越接近1说明两者越同步一致。都稳定在0.998以上从没在任何训练步骤跌破0.989。这意味着训练系统几乎完美复现了推理时的真实行为这是整个训练能够忠实进行的地基。至于混合专家模型的路由不一致问题LEGO-RL用了一个叫R3的路由重放*训练阶段强制复用推理阶段的专家选择结果而不是让模型重新自主决策该用哪些专家。技术。论文的对比实验很说明问题不用路由重放时训练推理概率相关性只有0.9946用了之后飙升到0.9993平均每个token的概率偏差从0.0062降到0.0025。研究团队还专门做了个负面对照实验故意把路由决策和token错位对齐一格结果相关性直接暴跌到0.75专家重合度从99.6%掉到8.3%。这个对照实验其实挺有意思的它证明了一件事路由重放这个机制看起来简单但一旦对错了位破坏性比完全不做还要大而且这种破坏是沉默的系统表面上运行正常实际上训练信号已经被污染了。解决方案二给沙盒环境设防作弊和减负双保险针对执行环境不靠谱和AI耍赖这两个问题LEGO-RL做了两方面的工作。先说减负。研究团队发现一个规律智能体在沙盒里跑任务的时候真正花时间的是AI自己执行代码调试代码这个过程占了整个流程时长的91.3%而搭建沙盒环境和最后跑测试验证加起来才占6.2%左右。既然大头在这儿那把小头的成本压到最低才划算。沙盒镜像*把一个软件运行所需的操作系统、依赖库、代码环境打包成一个标准化文件每次启动时直接加载这个文件就能得到一个一致的运行环境不需要重新安装配置。于是他们用了一个叫Nydus的懒加载技术让镜像数据按需从网络流式加载而不是每次都把整个镜像文件完整下载一遍。实测下来100个真实任务镜像上冷启动延迟中位数提升了1.7倍最慢的那次启动从40秒压到了1.7秒提升了23倍。网络流量从21.6GB降到1.6GB硬盘写入从65.6GB降到5.3GB。另外把编程智能体的运行环境直接挂载进去而不是每次重装速度快了15.4倍用预构建好的任务镜像代替临时构建中位数快了33倍。这几个优化叠加起来效果是实实在在的。这就好比一个连锁餐厅每天要给几百家分店送食材如果每次都从零开始种菜、宰杀、加工那效率低到没法开业但如果建一个中央厨房把常用的半成品统一预制好分店只需要按需简单加热组装出餐速度能快出几十倍。沙盒环境的懒加载和镜像挂载本质上就是给AI训练建了一个中央厨房。再说防作弊。研究团队在附录里详细列出了他们观察到的几种AI耍赖行为直接读取git提交历史发生率在4.6%到20.5%之间非常高下载参考答案占1.9%篡改测试文件本身占2.4%到19.4%。针对每一种都有对应的封堵措施。git历史在AI工作阶段会被折叠成单个提交等到最后评分阶段再恢复网络访问由一个AI改不了的特权组件严格控制分阶段限制外网访问权限测试文件在评分之前根本不会出现在AI能看到的目录里等到打分时才临时上传进沙盒。这套设计的道理其实很朴素。就像考试的时候监考老师不会在考生答题的时候就把标准答案摆在桌上即便考生宣称自己不会去看。真正靠谱的做法是把答案锁在只有阅卷时才能打开的柜子里物理上杜绝作弊的可能而不是靠考生的自觉。如果只是口头警告AI不要作弊而系统层面留了漏洞那作弊几乎是必然会发生的因为强化学习的本质就是会疯狂寻找能拿到高分的任何路径哪怕这条路径是钻空子而不是真正解决问题。除此之外研究团队还发现了一个环境侧的严重问题大约2.5%被检查的任务评分脚本本身写错了会错误地把标准答案补丁直接应用进去导致不管AI做没做对最后都能拿满分。这种问题不是AI在作弊而是评分系统本身有Bug同样会污染训练信号所以也需要专门的审计流程来筛查。解决方案三给失败的尝试打标签而不是一刀切地丢弃或照单全收训练过程中不是每一次AI的尝试都能顺利跑完流程。有的因为沙盒环境搭建失败了有的因为超时被强制中断有的正常达到了轮次上限或者token长度上限。这些不同类型的未完成该怎么处理论文给出的策略是区别对待。如果是基础设施本身出的问题比如环境搭建失败、执行超时这类轨迹会被直接排除出训练不参与梯度计算因为这种失败跟AI的能力好坏没关系纯粹是运气不好或者环境不稳定。但如果AI是正常运行、只是碰到了轮次上限或者内容长度上限被截断了这种情况下已经产生的部分依然会被保留因为这确实反映了AI当时的真实行为只是没走到终点而已。三个框架的实测数据显示Claude Code有7.1%的轨迹被排除OpenHands SDK是2.4%OpenCode是6.4%。有意思的是三个框架失败的原因差别很大Claude Code主要栽在超时上OpenCode则更多是环境搭建失败。研究者的解释是同样的底层沙盒基础设施跑在不同的智能体框架上会表现出完全不同的失败模式这说明失败原因不只是基础设施的问题也和框架自身的行为习惯有很大关系。这套筛选逻辑本质上是在回答一个问题这次失败到底是AI能力不够还是环境本身出了幺蛾子打个比方一场考试如果因为停电导致部分考生答不完卷子你不能因为这些考生最后交了白卷就判定他们不会做题这道题应该按因客观原因未完成处理而不是简单地打零分算作水平不行。但如果一个考生正常答完了卷子只是能力有限做错了这个错误答案确实反映了他的真实水平应该如实计入成绩。LEGO-RL对失败轨迹的分类处理走的就是这个逻辑。一个容易被忽略但特别关键的发现任务难度是相对的会随AI变强而贬值强化学习里有个技术叫组相对优势估计*给同一个任务生成好几次尝试比如8次根据这几次结果之间的相对好坏来计算学习信号而不是看单次的绝对得分。这套方法有个隐藏的前提一组尝试里得有成功的也有失败的这样才能算出相对好坏。如果一组8次尝试全部成功或者全部失败这一组数据对训练来说就是废的因为没有差异可以比较梯度信号是零。论文里的一组数据让人很有触动。研究团队跟踪了整个训练过程中全对和全错这两类没有信息量的任务组占比变化。以OpenHands SDK为例训练刚开始的时候这类无效组占44.7%训练到第三个周期结束这个比例反而涨到了51.4%。这个现象一开始听起来有点反直觉AI变强了为什么无效数据反而更多了答案其实很简单因为AI越来越强那些原本半对半错、能提供学习信号的中等难度任务慢慢变成了AI每次都能做对的简单任务全对组的比例涨得比全错组降得还快净效果就是有效学习信号在慢慢变少。这就好比一个学生刚开始学一门课的时候练习册上大部分题目对他来说是半会半不会的做十道题能对五六道每道题都有讲解的价值。但随着他越来越熟练原来那些中等难度的题目慢慢变成了他闭着眼睛都能秒杀的送分题真正能锻炼他的题目占比反而变少了。如果这时候练习册的题目不更新学生的进步速度就会慢慢停滞因为大部分时间都花在了重复练习已经掌握的东西上。正因为这个现象研究团队专门设计了一套难度筛选流程。他们从近3.7万个候选任务出发先经过规则筛选去掉明显有问题的剩下2.28万个再经过构建和验证测试的可靠性检查剩下2.17万个这一步顺便发现了前面提到的2.5%评分脚本出错的问题最后用一个中等规模的模型跑四次试探只保留四次里成功一到三次的任务也就是那些不太简单也不太难、正好卡在AI能力边界上的任务最终筛出2699个任务组成训练集。论文还专门做了个对照实验来验证这套筛选逻辑的价值。他们拿相同规模、四组不同难度分布的任务池分别训练结果显示用了难度筛选的两组完整难度带和偏难的那一半验证得分能提升到0.671和0.670而未经筛选的随机任务池训练完之后的得分和起点基本持平几乎没有进步。原因也很直白未经筛选的任务池里72.7%的任务AI从来没做对过13.4%的任务AI每次都能做对真正能提供学习信号的任务只占很小一部分。这个发现挺重要的它说明训练数据的质不只是看内容对不对更要看这批数据能不能持续给模型提供有效的学习压力而这个有效性本身是会随着模型能力变化而动态漂移的不是一劳永逸能确定下来的。训练效果三个框架全线提升说了这么多系统设计最终效果到底怎么样研究团队用LEGO-RL训练了Qwen3.5-35B-A3B这个模型一种混合专家架构分别接入OpenHands SDK、Claude Code、OpenCode三种智能体框架在权威的SWE-bench Verified基准上评测。SWE-bench Verified*一个专门评测AI能否真实解决GitHub开源项目Bug的基准测试每道题都有对应的仓库环境和可执行的验证测试AI必须真正让测试通过才算成功是目前公认较为严格的编程能力评测标准。| 智能体框架 | 训练前得分 | 训练后得分 | 提升幅度 ||---|---|---|---|| OpenHands SDK | 64.0% | **70.4%** | 6.4 || Claude Code | 62.4% | **68.2%** | 5.8 || OpenCode | 57.2% | **66.6%** | 9.4 |三个框架全线提升其中OpenCode提升幅度最大达到9.4个百分点。而且训练过程中模型的策略熵可以理解为回答的多样性和随机性始终保持稳定没有出现训练崩了的坍缩现象同时平均回复长度也稳步增长尤其在OpenHands SDK上从43.5k token涨到90.9k token说明模型学会了做更充分的探索和验证。更有说服力的是和更强基线的对比。研究团队还拿新一代基座模型Qwen3.6-35B-A3B以及经过专门后训练的KAT-Coder-V2.5-Dev做对比结果LEGO-RL训练出来的模型在所有三个框架下都是最强的甚至比参数量更大、训练资源更多的新一代基座模型还要高出3到6个百分点。不过论文里也诚实地指出了一个有意思的反常现象KAT-Coder-V2.5-Dev在Claude Code框架下比自己的基座模型高出3.4个百分点但换到OpenHands SDK框架下反而比未经调优的基座模型低了0.4个百分点。研究团队坦言他们没法确定具体原因但这恰恰印证了这篇论文一开始就强调的核心观点在一个特定智能体框架下调优出来的能力提升未必能迁移到另一个框架上这不是理论假设是实测出来的真实现象。可观测性不只是训练更是能看懂训练除了前面说的三大技术支柱LEGO-RL还专门做了一套完整的运维观测系统包含数据准备、运行前校验、训练执行、实时监控、人工复盘这五个闭环阶段。这套系统里有个叫Live UI的实时看板能把训练异常精确定位到具体原因。论文里举了几个真实案例。有一次验证得分从0.556骤降到0.150通过看板追踪发现172条轨迹里只有60条真正跑到了验证环节问题出在任务环境搭建失败而不是模型能力退化。另一次更极端1024条轨迹全部只跑了一轮就终止了排查发现是工具调用格式解析器不兼容一个纯粹的工程配置问题跟训练算法本身毫无关系。这个细节其实挺重要的因为如果没有这套细粒度的追踪能力研究者看到的只是一条陡然下跌的曲线很容易误判成模型训练失败了或者算法有问题从而做出错误的调整浪费大量算力和时间去排查错误的方向。论文里还展示了一些通过这套观测系统发现的行为变化挺值得说道的。比如在OpenHands SDK训练过程中AI修改代码之后回头再检查文件的比例从73.6%涨到了98.1%几乎是养成了改完必查的习惯编辑前查看的文件数量从平均3.5个涨到6.9个说明AI变得更谨慎会先充分了解代码全貌再动手。但另一方面处理中间命令失败之后最终能解决问题的比例只从63.9%涨到66.8%涨幅相对温和。这说明训练带来的行为改变更多体现在自我核查这个习惯上而不是出错后怎么救回来这个更难的能力。这个发现某种程度上也符合直觉学会更细心地检查自己的工作比学会灵活应对各种突发状况前者是更容易通过练习强化的技能。系统效率异步调度带来的实打实提速最后说说系统工程层面的一个关键决策异步训练。传统的强化学习训练是同步的意思是要等一批任务比如64个全部跑完才能开始下一轮训练。但编程任务的执行时长差异极大有的几分钟搞定有的要跑几十分钟。这就产生一个问题只要这批任务里有一个特别慢的整批都得等它其他早就跑完的算力资源就白白闲置在那里。论文用一个离线测试量化了这个浪费最慢的10%任务占用了总执行时间的24.5%而且观察到31次批次边界停滞中位数停滞时长38.7分钟最长一次停了135.9分钟。这就好比一个旅行团出去玩大巴车必须等所有游客都从景点回来才能出发去下一站。如果其中一个游客走丢了或者逛得特别慢剩下二十几个人只能干等着这个时间成本摊到每个人头上都是巨大的浪费。而异步调度做的事情本质上是让每个游客各走各的谁先逛完谁先上另一辆车出发不用互相等待。实测下来同样7.5个小时同步训练完成3步异步训练完成7步单步时间快了2.5倍。即便扣除两组实验用的GPU算力差异这个干扰因素之后校正后的单步时间依然是1.9小时对1.0小时异步方案接近翻倍的效率提升。不过论文也很坦诚地指出这个结论只在最大策略滞后为1这个具体设置下成立允许更大滞后可能带来更大的效率提升空间但这属于以后可以探索的方向。QAQ1LEGO-RL是什么ALEGO-RL是华为技术团队提出的一套强化学习训练框架专门用来训练编程智能体它的核心特点是不改动Claude Code、OpenHands SDK、OpenCode这些现成智能体框架的内部逻辑而是通过在推理服务边界截取原始生成数据实现精确的强化学习训练。Q2LEGO-RL训练出来的模型效果怎么样A研究团队用它训练Qwen3.5-35B-A3B模型在SWE-bench Verified基准上OpenHands SDK框架下得分从64.0%提升到70.4%Claude Code从62.4%提升到68.2%OpenCode从57.2%提升到66.6%三个框架全线提升且训练推理概率相关性保持在0.99以上。Q3为什么在一个框架下调优好的模型换到另一个框架效果可能会变差A因为不同智能体框架有各自的提示词构造方式、上下文管理策略和工具调用逻辑模型在特定框架下学到的行为模式和框架本身高度耦合论文中KAT-Coder-V2.5-Dev在Claude Code下提升3.4个百分点但在OpenHands SDK下反而下降0.4个百分点就是实证案例。