Agent Lightning v1.0 開源約 3,500 行程式碼的輕量化框架，讓實際部署所用的智能體框架直接參與強化學習

System architecture diagram. On the left, agents with harnesses — mini-SWE-agent, OpenHands, and OpenClaw — run on a Kubernetes cluster. They connect to three components: an API Gateway containing a Rollout API and an LLM API Proxy, a Rollout Controller containing a local reconciler and a Kubernetes reconciler, and a Customized Trainer containing a sample adapter and monitoring. These connect in turn to an inference engine and a training engine holding the model.

重點一覽

Harnessed Agentic RL：Microsoft Research Asia 推出一種訓練範式，讓部署時使用的同一個 Agent harness 直接參與強化學習，無需在訓練框架內重新實作 Agent。
以輕量為設計理念：Agent Lightning v1.0 只需約 3,500 行程式碼，便提供完整的 Agent 強化學習控制平面。
原生支援 Kubernetes：Agent 可在自主管理的叢集、雲端 Kubernetes 或本地基礎架構上，以標準 Kubernetes 工作執行，無需依賴付費商業沙盒服務。
數據效率高的訓練方案：以開源數據集為基礎的端到端編碼 Agent 流程，僅使用約 6,000 個訓練樣本，便將 Qwen3.5-9B 在 SWE-bench Verified 上的 Pass@1 由 41.8% 提升至 56.4%，增加 14.6 個百分點。

AI Agent 已從單一模型演變為由模型、工具和執行環境構成的複雜全堆疊系統。其能力愈來愈取決於在模型外部協調這些元件的 Agent harness。強化學習（RL）是一種讓 AI 系統透過試錯學習的方法，並根據其行動所得到的獎勵和懲罰提供引導。RL 可以提升 Agent 的能力，但大多數 Agent 強化學習系統都要求開發人員在訓練框架內重新實作 Agent。這樣做成本高昂，也意味着受訓練的 Agent 並不完全等同於實際部署的 Agent。

為此，Microsoft Research Asia 的研究人員推出 Harnessed Agentic RL 訓練範式，並將全面重建的 Agent Lightning v1.0（在新分頁開啟）開源。與原版 Agent Lightning 相比，v1.0 更着重保持輕量、整合真實 Agent harness，以及提供完整、可重現的 Agent 強化學習訓練流程。

Agent Lightning v1.0 以 Harnessed Agentic RL 為基礎重新建構，主要改進包括：

輕量：整個框架約有 3,500 行程式碼。Agent Lightning v1.0 以精簡、清晰的程式碼實作完整的 Harnessed Agentic RL 系統，方便用戶理解、修改和擴展。
在真實 Agent harness 上訓練：Agent 透過 Agent Lightning v1.0 的大型語言模型（LLM）代理伺服器連接模型，無需更改現有的 harness 程式碼。
原生支援 Kubernetes：Agent 可直接以 Kubernetes 工作執行，無需外部商業沙盒服務。自主管理的叢集和本地基礎架構均可支援大規模 rollout。
完整的編碼 Agent 訓練範例：以 Qwen3.5-9B 建構的端到端流程，僅使用約 6,000 個訓練樣本，便將 SWE-bench Verified 上的 Pass@1 由 41.8% 提升至 56.4%，絕對增加 14.6 個百分點。

傳統 Agent 強化學習的限制

傳統 Agent 強化學習假設訓練框架掌控與環境互動的循環。在 ReAct 式循環中，模型生成一個動作，環境返回觀察結果，觀察結果會附加至上下文，模型再生成下一個動作，因此整個 rollout 對應至一段連續的 token 軌跡。早期的 RL 系統，例如 verl、AReaL 和 slime，都是按這種方式建構，因此訓練 Agent 時必須在 RL 框架內重新建構其循環。

實際使用的代理執行框架已超出該假設的適用範圍。程式編寫代理，例如 mini-SWE-agent、OpenHands、OpenCode、Claude Code 和 Codex，各自具備不同的上下文管理方式、工具協定、執行邏輯和依賴項，通用代理系統亦然。為訓練而重新建構代理系統成本高昂，而且重建後的代理可能不再像已部署的代理般運作。

Agent Lightning 採取不同做法。它在代理與模型之間設置 LLM 代理伺服器。代理仍會照常運作：只需將原本用來呼叫模型 API 的端點改為指向 Agent Lightning，訓練框架便能觀察並記錄代理的模型呼叫。在 v1.0 中，研究人員進一步正式定義這種模式為 Harnessed Agentic RL：部署時使用哪個代理執行框架，訓練時就由同一個框架直接參與強化學習（圖 1）。

Figure 1: Side-by-side comparison of two training loops. In Agentic RL, the environment exchanges actions and observations with a tokenizer, which passes action and observation tokens to the policy model. In Harnessed Agentic RL, an agent harness handling context and orchestration sits between the environment and an OpenAI-like API, which exchanges input and output tokens with the policy model. — 圖 1. 傳統代理式 RL 與 Harnessed Agentic RL 的比較。傳統代理式 RL 由訓練框架管理環境和代理循環；Harnessed Agentic RL 則由代理執行框架同時管理兩者。

使用真實代理執行框架進行訓練的四項挑戰

Harnessed Agentic RL 與傳統代理式 RL 的一項核心分別，在於環境互動循環由代理執行框架而非訓練框架負責處理。訓練系統只能觀察一系列 LLM 請求和回應，因此一次 rollout 可能會被拆分為數量不定的訓練樣本。這帶來四項主要挑戰：

重新分詞與樣本合併：代理執行框架會以文字形式保留上下文，但 RL 訓練需要 rollout 期間採樣所得的 token ID。再次將文字套用聊天模板並交由 tokenizer 處理，可能會改變 token 邊界，因此相鄰的呼叫未必能合併為同一個樣本。
優勢計算：重新分詞、子代理和上下文摘要可能會將一次 rollout 拆分為多個樣本。在樣本層級直接計算基線和優勢，會令產生較多樣本的 rollout 被重複計入，從而改變 rollout 層級原有的統計關係。
損失正規化：按樣本數量平均損失，會令產生較多樣本的 rollout 獲得更高權重。由於樣本數往往只是代理執行框架運作方式所產生的結果，損失正規化亦必須避免因此失真。
訓練後端排程：只有在代理執行框架完成運作後，才能得知樣本數量和長度；GPU 數量以及數據／張量平行配置通常都是固定的。後端必須將可變的工作負載映射至固定資源。

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

在系統設計上，Agent Lightning v1.0 將簡潔視為首要原則。整個框架約有 3,500 行程式碼，包含三個核心元件：API Gateway、Rollout Controller 和 Customized Trainer（圖 2）。

API 閘道會儲存 rollout、模型及事件，並作為兼容 OpenAI 的 LLM 代理伺服器。它會將智能體執行框架發出的每次模型呼叫連結至相應的 rollout，並記錄訓練所需的提示詞、回應及對數機率。rollout 控制器會啟動和管理智能體執行作業，可將智能體作為本機程序或標準 Kubernetes 工作執行，並將智能體執行與訓練器分開。自訂訓練器以 verl 為基礎，負責產生 rollout、等待其完成、收集樣本，並透過樣本適配器整理出最終訓練樣本。因此，對於現有的智能體執行框架，通常只要將模型端點指向 Agent Lightning 代理伺服器，便足以快速接入 RL 訓練。

Figure 2: System architecture diagram. On the left, agents with harnesses — mini-SWE-agent, OpenHands, and OpenClaw — run on a Kubernetes cluster. They connect to three components: an API Gateway containing a Rollout API and an LLM API Proxy, a Rollout Controller containing a local reconciler and a Kubernetes reconciler, and a Customized Trainer containing a sample adapter and monitoring. These connect in turn to an inference engine and a training engine holding the model. — 圖 2. Agent Lightning v1.0 的系統架構，展示 API 閘道、rollout 控制器及自訂訓練器。

共置非同步 RL

不同智能體的 rollout 時間差異很大。同步 RL 需要等待一批智能體中最慢的一個完成，令 GPU 閒置；完全非同步 RL 雖可提高利用率，卻需要為 rollout 和訓練分設 GPU 資源池。為此，Agent Lightning v1.0 推出共置非同步 RL（Collocated Async RL），讓 rollout 與模型更新共用同一組 GPU。

系統收集到足夠的 rollout 後便會開始更新：API 閘道會暫停接收新請求，並等待正在處理的請求完成；更新完成後，rollout 便會恢復。對外部智能體執行框架而言，整個狀態轉換都是透明的。實驗顯示，與同步 RL 相比，這種方法的端到端加速效果約為 2 倍，而且使用的 GPU 比傳統非同步 RL 少（圖 3）。

Figure 3: Three GPU scheduling timelines. Synchronous RL uses four GPUs at low efficiency, with long idle gaps before a single update block. Collocated Async RL uses the same four GPUs at high efficiency, interleaving full and partial rollouts with update blocks. Asynchronous RL reaches high efficiency but requires eight GPUs. Bars are colored for full rollout, partial rollout, and update. — 圖 3. 同步 RL、非同步 RL 與共置非同步 RL 的比較。共置非同步 RL 在使用較少 GPU 的同時提高了利用率。

在 Kubernetes 上執行智能體

收集足夠的 rollout 意味着要同時執行大量智能體，會消耗大量 CPU、記憶體及運算資源。其他 Harnessed Agentic RL 框架通常會在 Modal Sandbox 或 E2B 等商業沙盒服務上託管這些智能體，規模擴大時成本便會迅速上升。Agent Lightning v1.0 則將智能體作為標準 Kubernetes 工作執行，重用現有的自主管理叢集、雲端 Kubernetes 或本機基礎架構（圖 4）。這樣能更有效運用現有運算資源，降低大規模 rollout 的成本，並讓整條管線保持開源且可重現。

Figure 4: Flow diagram. An API Gateway holds three rollouts, two queueing and one running. The Rollout Controller polls the gateway and uses a Kubernetes reconciler to create jobs on a Kubernetes cluster, and a local reconciler to watch and list local processes. Status updates flow back to the gateway. — 圖 4. Agent Lightning v1.0 的 rollout 控制器原生支援 Kubernetes，可直接以標準 Kubernetes 工作執行智能體。

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

為測試這種方法，研究人員以 SWE-smith、mini-SWE-agent 和 Qwen3.5-9B 建構了完整管線，涵蓋資料清理、環境建置、防範獎勵駭取的措施，以及 RL 訓練。訓練集約有 6,000 個樣本，無需大規模運算資源。單靠 RL 訓練，Qwen3.5-9B 在 SWE-bench Verified 上的分數便由 41.8% 升至 56.4%，提升 14.6 個百分點。

程式編寫智能體實驗進一步印證了先前對兩項挑戰的分析：優勢值計算和損失正規化。相較於樣本層級的處理方式，按 rollout 層級計算優勢值並進行正規化，可取得較高的驗證獎勵，並令訓練期間的策略熵保持更穩定（圖 5）。

Figure 5: Two line charts plotting 200 training steps. On the left, validation reward: rollout-level advantage combined with rollout-level normalization reaches the highest reward at about 0.37, above rollout-level advantage alone and sample-level advantage. On the right, policy entropy: rollout-level advantage alone climbs steeply to about 0.65, while the combined method stays lower and steadier. — 圖 5. Qwen3.5-9B 在 SWE-smith 驗證集上的通過率和策略熵。

技術報告

GitHub 專案

在新分頁開啟

文章 Agent Lightning v1.0：一個用於透過真實 Harness 訓練 Agent 的 3,500 行輕量級 Agentic RL 框架最初刊登於 Microsoft Research。