这项由美国伊利诺伊大学厄巴纳-香槟分校（UIUC）、微软研究院与卡内基梅隆大学（CMU）联合完成的研究，以预印本形式发布于2026年6月，论文编号为arXiv:2606.05597。研究的核心成果是一个名为AsyncWebRL的训练框架，专门用于教会AI在真实网页上自动完成任务——比如搜索信息、填写表单、对比商品价格等。

如果你曾经希望有个助手能帮你自动浏览网页、完成繁琐的在线操作，那这项研究正在解决的问题就和你密切相关。目前训练这类"网页自动化AI"需要消耗大量计算资源，而且训练过程中充满浪费——就像一条流水线上，有些工人在拼命干活，有些工人却在发呆等待。这篇论文同时解决了两个层面的浪费问题：一是让流水线不再空转，二是让每个工人养成更好的工作习惯。

一、先搞清楚这条"流水线"是怎么工作的

要理解这项研究，可以把训练AI完成网页任务的过程想象成培训一批新员工。这些员工（AI模型）要学会在真实的网页环境里完成各种任务，比如"去某个网站查一下某款商品的价格"或者"找到某所大学招生联系邮箱"。

训练的方式是让员工反复尝试——打开浏览器，截一张屏看看当前页面长什么样，决定下一步操作（点击、输入、滚动等），再截图，再决策，如此循环，直到完成任务或者达到最大步数上限。完成任务就得到奖励，失败则没有奖励。这种"尝试-反馈-改进"的过程，在AI领域叫做强化学习（Reinforcement Learning，简称RL）。

这个过程涉及三个关键环节：让员工实际去"跑网页"积累经验（称为rollout，即轨迹收集）、根据经验更新员工的知识（梯度更新，即让模型变聪明）、以及把最新的知识广播给所有员工（策略刷新）。

过去的训练方式是同步的——就像一个严格的班长，必须等所有员工都跑完这一轮网页任务，才允许更新知识，更新完了再统一出发跑下一轮。问题在于，不同任务难度差异很大，有的员工三步就完成了，有的员工要跑二十步才结束，跑完的人只能干等着，GPU（运算芯片）就这样白白闲置着。这正是论文所指的"GPU空转"问题。

与此同时，研究团队还发现另一个问题：失败的任务往往比成功的任务要长得多——数据显示，失败平均需要12.5步，而成功只需5.1步。这个长短差距会引发一种奇怪的"坏习惯"，下文会详细解释。

二、异步流水线：让三条传送带同时运转

AsyncWebRL的第一个核心贡献是把同步流水线改造成异步流水线。继续用工厂比喻：原来是"所有工人同时出发，全部回来才开会总结，总结完再全部出发"；现在改成"任何一个工人完成任务就立刻开始下一个，与此同时后台持续更新知识手册，更新好了就实时发给所有在岗工人"。

这个改造带来的直接效果是：轨迹收集、梯度更新和策略刷新这三件事同时在进行，互不等待。某个工人刚跑完一个任务，新任务立刻开始，不需要等其他工人。GPU几乎全程满负荷运转。

但这个改造带来了一个新麻烦：当某个工人在用"旧版本知识"跑任务时，后台已经用新经验更新了好几轮知识。这就像工人拿着上周的操作手册在工作，而公司已经发布了这周的新规程。这种"经验来自旧版本AI、更新却针对新版本AI"的错位，在技术上叫做"离策略"（off-policy）问题。

为了弥补这个错位，研究团队采用了一种叫做"解耦重要性采样"的技术。通俗来说，他们把"旧手册和新手册之间的差距"以及"本次更新前后的差距"这两件事分开处理，而不是混在一起打包考虑。这样做的好处是，系统能更准确地判断哪些经验值得重用、哪些经验已经太过时了。实验结果显示，这种方式让一个叫做"clip触发率"（可以理解为系统因为数据太过时而不得不踩刹车的频率）降低了大约一半，训练效率显著提升。

除了计算逻辑上的优化，研究团队还解决了一个工程层面的实际障碍：截图太占内存。每个网页任务可能涉及数十张高分辨率截图，数百个任务同时并行时，按照原来的方式把所有截图打包塞进共享数据通道，会导致通道堵塞、数据溢出到硬盘，速度瞬间暴跌。研究团队的解决方案是建立一个专门的"截图仓库"——截图只存一份，各个工人和训练器之间只传递"这张图在仓库的哪个位置"这样的轻量级标签，而不是把图片本身搬来搬去。这个改动让每步处理时间从约700秒压缩到约1秒。

还有一个细节值得一提：原来每轮训练开始时都要重新启动数百个浏览器会话，光是这个"热身"就要花不少时间。现在改成"常青池"设计——浏览器会话永远保持开启状态，一个任务结束，下一个任务立刻接着跑，完全不需要重启。

这一系列系统层面的改进，最终让训练吞吐量达到每小时约3100条轨迹，而此前最快的开源同步方案（WebGym）在Instruct模型上约每小时1300条、在Thinking模型上约每小时1050条。换算下来，加速比在2.4到2.9倍之间。

三、发现一个"坏习惯"的根源：步数越多，学得越歪

解决完系统效率问题，研究团队在检查训练过程时发现了一个奇怪的现象：AI在学习过程中，轨迹越跑越长，每步的回复文字也越写越多，但任务完成率却没有相应提升。这是在浪费计算资源，也让训练变慢。

这个"坏习惯"的根源，藏在一个看起来非常无害的数学细节里。

训练AI时用的损失函数（可以理解为衡量"AI答得有多差"的评分方式）里，有一项叫做"每轨迹归一化因子"，写作1/|τi|，其中|τi|代表这条轨迹用了多少步。这个因子的本意是公平对待长短不一的轨迹——毕竟一条用了20步的轨迹，如果每步都按同等权重计算，总体影响力会是5步轨迹的4倍，看起来不公平。所以用步数来除，让每条轨迹的总影响力都归一化为1。

听起来很合理，但问题出在失败轨迹比成功轨迹长得多这个结构性事实上。失败平均12.5步，成功平均5.1步，这意味着失败轨迹里每一步收到的"惩罚梯度"被1/12.5稀释，而成功轨迹里每一步收到的"奖励梯度"被1/5.1稀释。两者比较下来，失败轨迹的惩罚信号被削弱了大约2.4倍。

这个信号失衡带来的后果是：AI没有足够强烈的动机去避免那些导致失败的行为，转而形成一种"拖延"倾向——继续跑更多步，希望最终能碰到成功。用更形象的说法：如果一个员工被批评时，批评的力度随着批评内容的长度而被平均稀释，那么他反而会倾向于把错误说得越来越冗长，因为每句话被惩罚的力度越来越小。

四、一行代码的修复：把"除以步数"换成"除以常数"

研究团队提出的解决方案极其简洁——把1/|τi|替换为1/k，其中k是一个固定常数（在实验中取10，对应最简单任务类型的步数上限）。

这一改动的含义是：不再按轨迹长度来稀释梯度，而是让所有轨迹按统一标准计算影响力。一条20步的失败轨迹，它每步的惩罚信号不再被20这个大数字稀释，而是和一条5步的成功轨迹一样，用同一个分母k来处理。等价地说，一条长轨迹的总影响力变成了|τi|/k，步数越多，影响越大——这正好是我们希望的：让AI更痛切地感受到"跑了这么多步还是失败了"意味着什么。

这个修复与此前学界对另一个相关问题的研究（Dr. GRPO，来自南洋理工大学的工作）相呼应，但作用层级不同。Dr. GRPO处理的是单步任务中"回复越长、每个词的梯度被稀释越多"的问题；而这篇论文处理的是多步任务中"轨迹越长、每步的梯度被稀释越多"的问题，是把同样的诊断逻辑向上抬了一个层级。

五、"冗长记忆综合症"：坏习惯是怎么一步步加剧的

为了让读者更直观地理解这个问题，研究团队深入分析了AI的具体行为变化。

在WebGym的训练设定中，AI每完成一步操作，都会维护一个叫做"Memory"（记忆）的JSON字段，用来存储跑任务过程中收集到的信息，比如"我访问过哪个网站""找到了什么信息"等。这个记忆字段是累加式的——每步可以新增条目，但不删除已有内容。

在使用1/|τi|归一化时，AI表现出明显的"记忆膨胀"：步数越多，Memory里的条目就越多，而且大量条目是无意义的通用占位符，比如"task_1""current_step""search_query"之类——这些词和具体任务毫无关联，只是在机械地填充字段。统计数据显示，34%的Memory条目属于这类通用占位符，只有7%的轨迹能在整个任务过程中保持相同的Memory键名，相邻两步之间Memory不变的情况只占36%。这意味着AI在不停地乱改记忆，没有形成稳定的任务理解框架。

更糟糕的是，Memory是回复的一部分，Memory越长，每步的总输出字符数就越多，计算量随之增加，训练变慢。在使用1/|τi|时，每步平均输出约240个token（token可以理解为词或词的片段）。

替换为1/k之后，情况完全不同。AI倾向于在第0步就确立一套与具体任务相关的关键词——比如针对一个查蛋白质信息的任务就写"insulin protein from Gallus gallus: not found yet"——然后在整个任务过程中保持这套框架不变，只更新值而不随意增删键名。统计数据印证了这一点：65%的轨迹能保持首尾相同的Memory键名，76%的相邻步骤Memory键名不变，通用占位符比例降到11%。每步平均输出也从约240 token降低了约33%。

研究团队为这种现象取了一个生动的名字：长度耦合记忆漂移（length-coupled memory drift）。用日常语言来说，就是"因为长轨迹的惩罚被稀释，AI学会了靠拖长篇幅来逃避责任，顺带把记忆系统搞得越来越乱"。

六、对症下药的三组验证实验

为了确认诊断正确、修复有效，研究团队设计了三组验证实验，每组都像是在排除一种可能的混淆因素。

第一组验证的问题是：这个"坏习惯"是GRPO（一种特定的训练算法）独有的，还是只要用了1/|τi|就会出现？研究团队检验了另一种算法RAFT++，它和GRPO在很多方面都不同，但也使用了1/|τi|归一化。结果发现，RAFT++同样出现了Memory膨胀现象，只是程度稍轻——因为RAFT++只从成功轨迹中学习，没有直接惩罚失败轨迹，所以这个效应通过成功轨迹传播，力度弱一些。这个结果表明，1/|τi|因子本身才是根源，而非某个特定算法的副作用。

第二组验证的问题是：能不能通过修改提示词来解决这个问题，而不需要改损失函数？研究团队测试了一个"压缩型"提示词——明确指示AI每步要压缩Memory，只保留关键信息。结果：在保留1/|τi|的情况下，这个提示词的确让Memory操作有所收敛，但仍然高于基础模型的水平，远未解决问题。这个结果确认了"病根在损失函数，打补丁在提示词上是治标不治本"。

第三组验证的问题是：如果把任务的步数上限调得更高（从10/20/30步调整到20/40/60步），失败轨迹会更长，问题会更严重吗？结果完全符合预测：更长的步数上限下，Memory的键数增长曲线更陡峭，几乎完美地沿着"每步新增一个键"的对角线走，比默认设置还要糟糕。这进一步验证了"步数越长，梯度稀释越严重，坏习惯越固化"的机制。

七、实战检验：在真实网页任务上打出新纪录

研究团队在WebGym提供的测评基准上验证了AsyncWebRL的综合效果。WebGym是目前规模最大的开源多步视觉网页智能体训练环境，包含约29万个训练任务，覆盖12.8万个真实网站，分为简单、中等、困难三个难度级别，测试集包含1167个AI从未见过的网站上的任务（称为OOD测试，即"域外"测试，考察泛化能力）。

使用Qwen3-VL-8B-Instruct模型（阿里发布的视觉语言模型的指令调优版本），启用完整AsyncWebRL方法（异步框架+解耦重要性采样+固定常数1/k替换）后，综合成功率从此前WebGym同步训练方案的42.9%提升到45.4%，相对提升5.8%。

数字本身看起来不算惊人，但拆开来看就很有说服力了。简单任务的提升只有2.9%（从50.9%到52.4%），因为简单任务原本成功率已经较高，提升空间有限。中等难度任务的相对提升高达42%（从24.1%到34.3%），困难任务的相对提升更达到48%（从4.8%到7.1%）。这说明AsyncWebRL的改进主要体现在原来模型最薄弱的地方——那些需要更多步骤、更复杂判断的任务类型，正是过去同步训练和1/|τi|归一化联合导致学习效果最差的地方。

使用Qwen3-VL-8B-Thinking（思维链版本）的结果同样令人满意：综合成功率44.4%，其中中等难度35.1%、困难难度11.3%，均优于同一框架下的RAFT++基准。

值得单独提一下RAFT++在异步框架下的表现：它的综合成功率（39.3%）低于同步WebGym方案（42.9%）约3.6个百分点。研究团队认为这个差距是"异步框架本身需要付出的离策略代价"，也说明单纯异步化并不自动带来性能提升，还需要算法层面的配合才能真正超越同步基线。

八、离策略偏差究竟有多大：一个重要的安全性检验

在完全异步运行时，一个自然的担忧是：如果工人手里的"操作手册"版本太旧，会不会导致训练方向跑偏？

研究团队对此进行了量化追踪，定义了一个"离策略偏差"指标（即当前被训练的策略和产生数据时的策略之间的差距）。他们将最大允许的"版本滞后"设为η=2，即允许最多用比当前策略旧2个版本的数据训练。实验全程监控显示，平均偏差稳定在1.5左右，最大偏差在2.0左右，始终没有超出设定上限，训练全程GPU保持满负荷运转。

这个数字比做文字推理任务的类似异步框架（AReaL，针对数学和编程任务，允许η=4到8）更小，原因也很直观：网页操作任务的每步回复比数学推理短很多，模型产生轨迹的速度和训练速度之间的比例更接近，因此训练批次里很少出现"严重过时"的数据。

九、细节里的严谨：不惩罚超时轨迹的设计哲学

论文还有一个小设计值得一提，体现了研究团队在算法选择上的思考方式。

有些研究会对"用完所有步数还没完成任务"的轨迹给予特殊处理，比如额外惩罚。AsyncWebRL没有这样做，而是把所有超时轨迹一律视为普通失败。

研究团队的理由是：一条耗尽步数上限的轨迹，意味着它的某些动作并不够好——毕竟同一批任务里有其他轨迹在步数限制内完成了。那些在长轨迹中频繁出现的"回退"操作，其实是应该尽量少做的行为；如果AI发现"超时轨迹里有很多回退"，正确的学习方向是减少不必要的回退，而不是把超时和回退当成两件不相关的事情分别处理。当整批轨迹都失败了（即无论如何都完不成这个任务），那可能是任务本身太难或步数限制太紧，按失败处理也是合理的默认选项。

说到底，这项研究做了两件事，一件是工程层面的、一件是数学层面的，但两者都指向同一个目标：在有限的计算预算下，让AI学得更好、更快。

工程上，把同步流水线改成异步流水线，再配合截图轻量化处理和常青浏览器池，把训练吞吐量提升了2.4到2.9倍——这意味着同样的服务器，同样的时间，可以让AI多看70%到190%的真实网页经验。

数学上，一个隐藏在损失函数里的归一化因子被替换为常数，解决了"失败轨迹的惩罚信号被长度稀释"的问题，让AI不再养成用冗长输出逃避惩罚的坏习惯，训练速度和任务成功率双双改善。

这项研究的影响不局限于网页浏览这一个场景。任何需要AI在多步骤环境中自主行动的应用——在线购物助手、自动化办公工具、复杂信息检索代理——都面临类似的训练效率问题，而AsyncWebRL提出的这两个解决方向具有相当的通用性。

有兴趣深入了解技术细节的读者，可以在arXiv上通过编号2606.05597查阅完整论文，作者来自UIUC、微软研究院和CMU的联合团队，论文于2026年6月4日挂出。

Q&A

Q1：AsyncWebRL和普通的强化学习训练框架有什么区别？

A：普通框架要等所有任务同时跑完再统一更新模型，GPU经常空闲等待；AsyncWebRL让轨迹收集、模型更新、参数广播三件事同时进行，任何一个任务结束就立刻开始下一个，GPU几乎全程满负荷。加上截图不再通过公共通道传输而是存在专用仓库，整体训练速度达到原来最快同步方案的2.4到2.9倍。

Q2：把1/|τi|换成1/k这么简单的修改为什么能提升效果？

A：原来的1/|τi|会让长轨迹里每一步的惩罚信号被步数稀释，而失败轨迹平均比成功轨迹长2.4倍，所以AI学不到"长时间失败很糟糕"这件事，转而形成冗长输出的坏习惯。换成固定常数1/k后，长轨迹的惩罚不再被稀释，AI开始认真避免导致失败的行为，轨迹变短，每步输出减少，任务成功率在中等和困难任务上分别提升了42%和48%。

Q3：AsyncWebRL在网页任务上的实际表现怎么样？

A：在WebGym的域外测试集（AI从未见过的1167个网站任务）上，使用Qwen3-VL-8B-Instruct模型，综合成功率从此前最好的42.9%提升到45.4%。提升主要集中在难任务上：中等难度从24.1%提升到34.3%，困难难度从4.8%提升到7.1%，相对提升分别为42%和48%。