這項由美國伊利諾伊大學厄巴納-香檳分校（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%。
