微軟亞洲研究院發表 Agent Lightning v1.0：輕量級強化學習框架，訓練 AI 代理程式更高效

整合式代理強化學習：微軟亞洲研究院推出一種訓練範式，讓部署時使用的相同代理程式協調器直接參與強化學習，無需在訓練框架內重新實作代理程式。

輕量化設計：Agent Lightning v1.0 以約 3,500 行程式碼，提供一套完整的代理程式強化學習控制平面。

原生 Kubernetes 支援：代理程式可作為標準 Kubernetes 任務，在自管叢集、雲端 Kubernetes 或本地基礎設施上運行，不依賴付費商業沙盒服務。

資料高效訓練方法：一個端到端的程式碼代理程式管線，僅使用約 6,000 個基於開源資料集的訓練樣本，就將 Qwen3.5-9B 在 SWE-bench Verified 上的 Pass@1 從 41.8% 提升至 56.4%，增加了 14.6 個百分點。

AI 代理程式已從單一模型演變為由模型、工具和執行環境組成的複雜全端系統。它們的能力越來越依賴於從模型外部協調它們的代理程式協調器（agent harness）。強化學習（RL）是一種讓 AI 系統透過試錯學習的方法，由其行動的獎勵和懲罰來引導。

強化學習可以讓這些代理程式表現更好，但大多數代理程式強化學習系統要求開發人員在訓練框架內重新實作代理程式。這不僅成本高昂，也意味著受訓的代理程式與實際部署的代理程式不完全相同。

為了解決這個問題，微軟亞洲研究院的研究人員推出了「整合式代理強化學習」（Harnessed Agentic RL）訓練範式，並開源了全新重建的 Agent Lightning v1.0。相較於原始版本，Agent Lightning v1.0 更強調輕量化、與真實協調器整合，以及提供完整且可重現的代理程式強化學習訓練管線。

Agent Lightning v1.0 圍繞著整合式代理強化學習進行重建，並帶來了以下關鍵改進：

輕量化：整個框架約 3,500 行程式碼。Agent Lightning v1.0 以精簡且清晰的程式碼庫實作了完整的整合式代理強化學習系統，使其易於理解、修改和擴展。

在真實代理程式協調器上訓練：代理程式透過 Agent Lightning v1.0 中的大型語言模型（LLM）代理存取模型，無需更改現有的協調器程式碼。

原生 Kubernetes 支援：代理程式直接作為 Kubernetes 任務運行，無需外部商業沙盒服務。自管叢集和本地基礎設施都能支援大規模部署。

完整的程式碼代理程式訓練範例：一個基於 Qwen3.5-9B 的端到端管線，僅使用約 6,000 個訓練樣本，就將 SWE-bench Verified 上的 Pass@1 從 41.8% 提升至 56.4%，絕對增長了 14.6 個百分點。

傳統代理程式強化學習的局限

傳統代理程式強化學習假設訓練框架擁有與環境的互動迴圈。在 ReAct 風格的迴圈中，模型生成一個動作，環境返回一個觀察結果，該觀察結果被附加到上下文，然後模型生成下一個動作，因此整個部署過程映射到一個連續的 token 軌跡。

早期的強化學習系統，如 verl、AReaL 和 slime，都是以這種方式構建的，這意味著訓練一個代理程式需要在強化學習框架內重建其迴圈。真實的協調器已不再符合這個假設。

程式碼代理程式，例如 mini-SWE-agent、OpenHands、OpenCode、Claude Code 和 Codex，以及通用代理程式系統，都各自帶有自己的上下文管理、工具協定、執行邏輯和依賴項。為訓練而重建它們成本高昂，且重建後的代理程式可能不再與部署的代理程式行為一致。

Agent Lightning 採取了不同的路徑。它在代理程式和模型之間放置了一個 LLM 代理。代理程式繼續像以前一樣運行：只需將先前呼叫模型 API 的端點指向 Agent Lightning，訓練框架就能觀察並記錄其模型呼叫。

在 v1.0 中，研究人員更進一步，正式將此範式定義為「整合式代理強化學習」：無論部署時使用何種代理程式協調器，該協調器都將直接參與訓練期間的強化學習（圖 1）。

圖 1：傳統代理程式強化學習與整合式代理強化學習的比較。在傳統代理程式強化學習中，訓練框架管理環境和代理程式迴圈。在整合式代理強化學習中，協調器管理兩者。

使用真實協調器進行訓練的四大挑戰

整合式代理強化學習與傳統代理程式強化學習的核心區別在於，環境互動迴圈由代理程式協調器而非訓練框架處理。訓練系統只能觀察一系列 LLM 請求和回應對，因此單一的部署過程可能會被分割成數量不等的訓練樣本。這帶來了四個主要挑戰：

重新分詞與樣本合併：協調器以文字形式保留上下文，但強化學習訓練需要部署過程中採樣的 token ID。再次將文字通過聊天模板和分詞器可能會改變 token 邊界，因此相鄰的呼叫不總能合併為一個樣本。

優勢值計算：重新分詞、子代理程式和上下文摘要可能將一個部署過程分割成多個樣本。直接在樣本層級計算基準線和優勢值會導致產生更多樣本的部署過程被重複計算，從而改變部署層級的原始統計關係。

損失正規化：按樣本數量平均損失會給產生更多樣本的部署過程更大的權重。由於樣本數量通常只是協調器行為的產物，損失正規化也必須避免受其扭曲。

訓練後端排程：樣本數量和長度只有在協調器完成後才可知曉，而 GPU 數量和資料/張量平行配置通常是固定的。後端必須將可變的工作負載映射到固定的資源上。

以 3,500 行程式碼構建完整的代理程式強化學習控制平面

在系統設計上，Agent Lightning v1.0 將簡潔性視為首要原則。整個框架約 3,500 行程式碼，包含三個核心元件：API 閘道、部署控制器和客製化訓練器（圖 2）。

API 閘道儲存部署過程、模型和事件，並作為與 OpenAI 相容的 LLM 代理。它將協調器發出的每個模型呼叫連結到其部署過程，並記錄訓練所需的提示詞、回應和對數機率。部署控制器啟動並管理代理程式執行，無論是作為本地程序還是標準 Kubernetes 任務，將代理程式執行與訓練器分離。

客製化訓練器基於 verl 構建，負責建立部署過程、等待其完成、收集樣本，並透過樣本轉接器組裝最終的訓練樣本。因此，對於現有的代理程式協調器，只需將模型端點指向 Agent Lightning 代理，通常就能快速連接到強化學習訓練。

圖 2：Agent Lightning v1.0 系統架構，顯示 API 閘道、部署控制器和客製化訓練器。

共置非同步強化學習

不同代理程式的部署時間差異很大。同步強化學習會等待批次中最慢的代理程式，導致 GPU 閒置；而完全非同步強化學習雖然提高了利用率，但需要為部署和訓練分別設置 GPU 池。為此，Agent Lightning v1.0 引入了「共置非同步強化學習」（Collocated Async RL），讓部署和模型更新共享同一組 GPU。

一旦系統收集到足夠的部署過程，更新便會開始：API 閘道暫停接收新請求，並等待正在進行的請求完成，更新完成後部署過程恢復。整個狀態轉換對外部代理程式協調器是透明的。

實驗證明，這種方法比同步強化學習實現了約 2 倍的端到端加速，同時比傳統非同步強化學習使用了更少的 GPU（圖 3）。

圖 3：同步強化學習、非同步強化學習和共置非同步強化學習的比較。共置非同步強化學習提高了利用率，同時佔用更少的 GPU。

在 Kubernetes 上運行代理程式

收集足夠的部署過程意味著同時運行許多代理程式，這會消耗大量的 CPU、記憶體和運算資源。其他整合式代理強化學習框架通常將這些代理程式託管在 Modal Sandbox 或 E2B 等商業沙盒服務上，但其成本會隨著規模迅速增加。

相反地，Agent Lightning v1.0 將它們作為標準 Kubernetes 任務運行，重複利用現有的自管叢集、雲端 Kubernetes 或本地基礎設施（圖 4）。這使得現有運算資源得到更有效率的利用，大規模部署成本更低，且整個管線保持開源和可重現。

圖 4：Agent Lightning v1.0 中的部署控制器提供原生 Kubernetes 支援，直接將代理程式作為標準 Kubernetes 任務運行。

6,000 個訓練樣本，效能提升 14.6 個百分點

為了測試這種方法，研究人員在 SWE-smith、mini-SWE-agent 和 Qwen3.5-9B 上構建了一個完整的管線，涵蓋資料清理、環境建構、獎勵駭客防護和強化學習訓練。該訓練集約有 6,000 個樣本，不需要大規模運算。

僅強化學習訓練就將 Qwen3.5-9B 在 SWE-bench Verified 上的分數從 41.8% 提升到 56.4%，增加了 14.6 個百分點。程式碼代理程式實驗進一步證實了先前對兩個挑戰的分析：優勢值計算和損失正規化。

與樣本層級處理相比，部署層級的優勢值結合部署層級的正規化，能實現更高的驗證獎勵，並在訓練期間保持策略熵更穩定（圖 5）。

圖 5：Qwen3.5-9B 在 SWE-smith 驗證集上的通過率和策略熵。