RLVR來做Agent任務能力增強訓練

和上一篇其實有點承接

上一篇的爭論其實是因為要優化agent的任務規劃和實現能力的

所以有了self-learning之爭

當我們說Self-learning，其實是在說什么？

其實上一篇最后時候提了一點拿RLVR來做agent的任務提升

正好今天看到了一篇應景的論文，就拿來直接用它來解釋了

https://github.com/cmriat/l0/blob/main/papers/l0.pdf

git上也有對應的項目

這個其實寫得挺清楚的介紹了一個名為?L-Zero (L0)?的新系統，旨在將大型語言模型（LLMs）訓練成能夠自主完成復雜、多步驟任務的通用智能體（General Agents）。

核心思想是解決現有方法在訓練智能體時面臨的可擴展性和效率低下的問題?。

為了實現這一目標，該研究主要提出了三個點：

1. NB-Agent：像Jupyter Notebook一樣工作的智能體?

工作模式：研究者設計了一種名為 "NB-Agent" 的智能體結構?。它的工作方式模仿了人類使用 Jupyter Notebook 的過程，即在一個 "思考-編碼-觀察" 的循環中解決任務?。
- 思考 (<think>)：首先，模型會生成一段思考過程，分析問題并規劃下一步行動?。
- 編碼 (<code>)：然后，它會生成一段 Python 代碼來執行具體的任務，如網絡搜索、數據計算等?。
- 觀察 (<output>)：代碼在一個安全的 Python 環境中執行后，其輸出結果會作為下一步行動的依據，反饋給模型?。

長期記憶：為了克服大模型有限的上下文窗口（Context Window）問題，NB-Agent 配備了一個 "記事本"（NotePad）工具?。智能體可以通過代碼將關鍵信息（如中間結論、數據）存入這個記事本，從而實現持久化記憶，便于在后續步驟中隨時調用?。

2. 端到端的強化學習（RL）訓練框架?

研究團隊為 NB-Agent 量身打造了一套完整的、可擴展的強化學習訓練流程?。

智能體策略梯度 (Agentic Policy Gradient)：與傳統強化學習不同，L0 將智能體的一個完整 "思考+編碼" 的輸出序列視為一個 "動作"?，并在此基礎上計算策略梯度，從而更高效地進行學習?。
可驗證的獎勵模型 (Verifiable Reward Model)：為了給智能體提供清晰的學習信號，研究者設計了一套自動化的獎勵機制。獎勵分數綜合了以下幾個方面：
- 最終答案質量：根據答案的準確率（EM）和內容重合度（F1）等指標來評分?。
- 格式規范性：獎勵那些嚴格遵守?<think>?和?<code>?輸出格式的行為?。
- 代碼執行效果：如果生成的代碼能成功運行，則給予正面獎勵?。
動態采樣 (Dynamic Sampling)：在訓練過程中，系統會生成多個解決同一問題的軌跡，并智能地舍棄那些獎勵過低或過高的極端案例，以增強探索和穩定訓練過程?。

3. 可擴展和高安全的訓練基礎設施?

為了支持大規模并行訓練，研究者設計了一套解耦的、穩健的基礎設施?。

分離式架構：推理、訓練（使用GPU）和環境交互（使用CPU）被分離開來?。大量的 "智能體工作單元"（Agent Workers）在獨立的CPU服務器上并行收集數據，與中心訓練引擎通信，提高了整體效率和擴展性?。
輕量級沙箱：每個智能體都在一個由 Bubblewrap 技術創建的安全沙箱中運行?。這種沙箱開銷小，且無需 root 權限，極大地增強了安全性和部署的便捷性?。

實驗結果

性能提升：該研究在多個開放域問答數據集（如 HotpotQA, SimpleQA）上進行了測試?。實驗表明，僅使用 NB-Agent 的基礎結構（L0-Scaffold）就能超越傳統方法?。經過強化學習訓練后（L0-RL），性能更是得到巨大提升?。例如，在使用 Qwen2.5-7B 模型時，SimpleQA 數據集的準確率，HotpotQA 都有很大提升，這東西其實不比數學，現在很多RL都妹太做這塊，所以看到這還是挺開心的。?
模型協同效應：研究發現，那些本身就為工具使用預訓練過的模型（如 Qwen-3-4B-Thinking），在接受 L0 框架的強化學習訓練后，表現出性能提升，推理模型效果好也是正常的，它中間產物都能作為外置的context

這張圖展示了一個用于訓練AI智能體（Agent）的端到端強化學習訓練流程（Training pipeline）。下面我們來詳細解釋它的各個組成部分以及它們是如何協同工作的。

這個系統的核心目標是讓一個AI智能體（圖中的NBAgent）通過與環境互動、執行任務、獲得獎勵并從中學習，來不斷優化自身的決策能力（即策略）。

核心組件詳解

這張圖可以分為三個主要部分：1. 智能體執行與數據收集（右側），2. 核心訓練引擎（左側），以及?3. 控制與數據處理模塊（中間）。

1. 智能體執行與數據收集 (Agent Execution & Data Collection)

Agent Workers (智能體工作單元)：這是智能體實際執行任務的地方。它們運行在遠程的CPU服務器上，可以并行啟動多個，從而高效地收集大量訓練數據。
NBAgent: 這是智能體本身，它根據當前策略生成決策。
Brwap Sandbox (沙箱環境)：為了安全和隔離，每個智能體都在一個輕量級的沙箱環境中運行。這可以防止智能體執行的代碼影響到系統其他部分，并且開銷很低，適合大規模并行部署。
Inference Server (SGLang) (推理服務器)：這是一個獨立的GPU服務器，專門負責運行AI模型以進行快速推理。當Agent Worker需要決策時，它會發送“Chat Requests”到這里，推理服務器上的模型會生成下一步的動作，然后返回給Worker。這種CPU-GPU分離是典型的解耦式架構（Decoupled Architecture），可以獨立擴展，避免性能瓶頸。

2. 核心訓練引擎 (Training Engine - FSDP)

Training Engine (FSDP)?：FSDP (Fully Sharded Data Parallel) 沒啥可解釋的了，這個要是不懂看pytorch去。它包含三個關鍵模型：
- Actor (演員)：即策略模型，是我們要訓練的主角。它負責根據當前狀態生成動作。
- Critic (評論家)：在強化學習中，Critic通常用于評估Actor所做動作的好壞或當前狀態的價值，以幫助Actor更好地更新。
- Ref Model (參考模型)：這是一個基準模型，通常是訓練開始前的原始模型。它的作用是在訓練中計算KL散度懲罰，確保訓練過程的穩定性，防止Actor模型在更新后偏離原始策略太遠。
Agentic Policy Gradient (智能體策略梯度)：這是本流程采用的核心算法。與傳統方法不同，它將智能體一次完整的“思考-編碼”序列視為一個單一的、完整的動作來進行優化。圖中它包含“Step Level Advantage”（步驟級別優勢）和“Token Level Advantage”（詞元級別優勢），其獎勵和優勢計算整的非常詳細。

3. 控制與數據處理 (Control & Data Processing)

Single Controller (單一控制器)：這是整個流程的“指揮官”。它負責啟動和管理Agent Workers，并協調數據在各個模塊之間的流動。
Trajectories (軌跡)：Agent Worker在執行一次完整任務后會產生一條“軌跡”，包含了該任務中的每一步狀態、采取的動作、獲得的結果等一系列數據。這是訓練模型所需的最原始的數據。
Dynamic Sampling (動態采樣)：收集到的軌跡會經過一個采樣過程。這里采用了DAPO-Inspired Rejection Sampling技術，其實也沒啥特殊的，你就當是拒絕采樣策略就成了。
Agentic Reward (智能體獎勵)：這是用于評估軌跡好壞的獎勵函數。它是一個多維度的、可驗證的獎勵函數。獎勵的來源包括：
- Final Answer：最終答案的正確性。
- Stepwise Format：每一步輸出的格式是否規范。
- Code Execution：生成的代碼是否能成功執行。
- Length Penalty：對過長的、不必要的步驟進行懲罰。

完整工作流程

整個訓練流程是一個持續循環的閉環，具體步驟如下：

啟動與分發：Single Controller?啟動多個并行的?Agent Workers。
決策與執行：每個?Agent Worker?向?Inference Server?發送請求。服務器上的?Actor?模型（當前最新策略）生成一個動作（“思考-編碼”序列）。
環境交互：Agent Worker?在其?Brwap Sandbox?安全環境中執行這個動作，并記錄結果。
收集軌跡：當一個任務完成后，完整的交互記錄形成一條?Trajectory，并被收集起來。
數據處理：收集到的多條?Trajectories?經過?Dynamic Sampling?篩選，并由?Agentic Reward?模塊計算出每條軌跡的綜合獎勵分數。
模型訓練：高質量的軌跡和對應的獎勵被送到?Training Engine。引擎利用?Agentic Policy Gradient?算法計算出如何更新模型。這個過程是嚴格的Strict On-Policy訓練，現在的跟LLM掛鉤的RL，我幾乎都卡不到Off-policy了，并使用KL散度懲罰來保證穩定性。
權重更新：Training Engine?將訓練好的新模型權重（Update Weights）發送到?Inference Server，以更新其上的?Actor?模型。
循環迭代：Agent Workers?在下一次請求時，就會使用這個更新后的、更強大的Actor模型來做決策。整個流程不斷重復，Agent的能力也隨之螺旋升天，也屬于左腳踩右腳了，只是踩的不是基礎模型，踩的t-1時刻的自己

收集trajectory sampler的邏輯如圖所示

Trajectory Sampler (軌跡采樣器)?的工作流程，詳細展示了系統如何生成、執行并收集用于AI模型訓練的“軌跡”數據。

分步解讀整個流程。

登場角色（參與者）

首先，我們來了解一下圖中的幾個主要角色：

ARF (ActorRefRollout): 整個流程的發起者和最終用戶。可以理解為訓練過程中的主控制器，它需要收集一批軌跡數據來進行模型訓練。
IE (InferenceEngine): 推理引擎。它封裝了需要被訓練的AI模型（即Actor模型），負責接收請求并作出決策。
TS (TrajSampler): 軌跡采樣器。這是本流程的核心協調者，負責創建工作單元、監控任務并收集最終結果。
TSS (TaskServer): 任務服務器。在遠程執行模式下，它是一個用于管理和分發任務的中間件。
Worker: 工作單元。這是實際執行任務的“工人”，每個Worker負責處理一個獨立的任務，并在一個隔離的安全環境（bwrap）中運行。
FS (Storage): 存儲系統。一個用于暫存所有Worker生成的軌跡數據的地方，比如一個文件系統或數據庫。

詳細流程解讀

整個流程可以分為五個主要階段，圖中用不同顏色的方框標出：

1. 準備推理引擎 (Prepare Inference Engine)

流程:?ARF?首先向?IE?發出指令，準備好推理引擎。IE?完成準備后（例如，加載模型到GPU），會通知?ARF。
目的: 確保AI模型已經就緒，可以隨時響應決策請求。

2. 啟動任務并創建工作單元 (Parallel Creation of Workers)

流程:
- 本地執行 (Local Execution):?TS?直接在本地通過子進程（subprocess）的方式，在安全沙箱（bwrap）中創建每一個?Worker。
- 遠程執行 (Remote Execution):?TS?向任務服務器?TSS?發送HTTP POST請求來創建任務，然后?TSS?在遠程機器上創建?Worker。
目的: 快速、并行地啟動大量獨立的任務執行單元，以提高數據收集效率。

3. 并行執行任務 (Parallel Execution of Workers)

流程: 所有?Worker?開始并行地工作。每個?Worker?內部會進行一個循環，直到任務完成：
1. step():?Worker?在自己的環境中執行一步任務。
2. 請求決策:?Worker?向推理引擎?IE?發送一個HTTP請求（通常是與OpenAI API兼容的格式），請求模型根據當前狀態給出下一步的動作。
3. 獲取決策:?IE?返回HTTP響應，其中包含模型生成的決策。
4. 寫入數據:?Worker?將剛剛完成的這一步交互（狀態、動作、結果等）記錄下來，并寫入到共享的?Storage?中。
目的: 這是實際的數據生成階段。每個Worker獨立地與模型互動，并將交互過程實時記錄下來，形成原始的軌跡數據。

4. 收集結果 (Collection of Results)

流程:
1. TS?會持續監控所有?Worker?的狀態，直到它們全部完成任務。監控方式同樣分為兩種：
2. 所有?Worker?都完成后，TS?會從?Storage?中讀取所有原始的軌跡數據。
3. TS?對這些原始數據進行后處理（例如，計算獎勵、格式化等）。
4. 最后，TS?將處理好的軌跡數據返回給最初的調用者?ARF。
目的: 匯總所有并行的工作成果，并將其整理成訓練算法可以直接使用的數據格式。

5. 清理推理引擎 (Cleanup Inference Engine)

流程:?ARF?在成功獲取到軌跡數據后，向?IE?發送清理指令。IE?釋放資源（如卸載模型、釋放GPU內存）后，通知ARF。
目的: 釋放系統資源，完成一次完整的數據采集周期。

其實就是一個分布式、并行化的軌跡數據采集系統：

解耦: 將決策（IE）、執行（Worker）和協調（TS）分離開，提高了系統的靈活性和可擴展性。
并行化: 通過并行創建和執行大量的Worker，極大地提升了數據采集的效率。當然這就是A3C準確說是A2C的思想
兼容性: 支持本地和遠程兩種執行模式，可以根據計算資源的分布靈活部署。
健壯性: 通過將中間結果寫入Storage，即使某個Worker失敗，也不會丟失所有數據。

這張圖詳細解釋了?NB-Agent?的架構和工作流程。我們來解讀一下。

核心概念

NB-Agent?是一個通用的智能體（agent），它遵循?“代碼即行動”（Code-as-Action）?的范式。它的工作方式模仿了程序員在?Jupyter Notebook?中的交互過程，通過生成并執行代碼片段來與環境互動和解決問題。這個過程本質上是一個?REPL（Read-Eval-Print Loop，讀取-求值-打印-循環）。

架構組件詳解

整個系統可以分為幾個關鍵部分：

1-LLM: 這是Agent的大腦。它負責接收任務和歷史信息，然后進行思考并生成下一步要執行的代碼。

2-上下文 (St?Context): 這是在第?t?步輸入給模型的所有信息。它包括：

- 系統提示 (System Prompt): 對智能體的身份、能力和行事規則的總體指示。
- 用戶任務 (User Task): 用戶提出的需要解決的原始問題。
- 歷史記錄: 過去所有的行動（a1, a2...）和對應的輸出（o1, o2...）

3-Python 環境 (Python Environment / Jupyter Kernel): 這是Agent的干活的。所有由模型生成的代碼都在這個真實、有狀態的Python環境中執行。它包含：

- 預定義工具 (Predefined Tools): 提供給智能體的一系列可用函數，如網頁搜索、文件查看器等。
- 記事本 (Notepad): 這是一個非常關鍵的組件，是智能體的長期記憶模塊。它是一個可以通過代碼修改的對象，包含用于規劃（Plan）、存儲事實（Fact）和起草答案（Draft）的結構。代碼可以將重要信息保存在這里，以克服模型上下文窗口的長度限制。

? ? ? 記事本本質上解決了場下文的限制，是因為以往的不管長期短期記憶幾乎都會一股腦的還是發給LLM，還時會擠爆context，但是因為這個有jupyter來定義各種代碼工具，所以就像想找啥，直接寫個python search函數，取走這一小段數據放入上下文就完事了，這個設計還是比較合理的 ? ? ?

- 變量 (Variables): 代碼執行過程中產生的變量也會被保存在這個環境中，供后續步驟使用。

4- 上下文管理器 (Context Watcher): 這是一個輔助模塊，負責管理模型的有限上下文。它有兩個主要功能：

- 修剪 (Trim): 當對話歷史變得太長時，它會策略性地移除一些舊的信息，以確保上下文不會超出模型的最大長度限制。
- 預算提醒 (Budget Notification): 它可以提醒模型剩余的token預算或步數，幫助模型更好地規劃后續操作。

然后咱們分步驟來解讀工作流程

Agent的工作流程是一個“思考-編碼-觀察”的循環，具體步驟如下：

用戶輸入 (User Input): 用戶提出一個任務，例如“花旗銀行是哪年成立的？”。
模型輸入 (Model Input): 用戶任務和所有相關的歷史信息被打包成上下文?S_t，輸入給大型語言模型。
輸出行動 (Output Action): 模型生成一個包含兩部分的行動?a_t：
- 思考 (<think>): 模型首先在?<think>?標簽內生成一段“內心獨白”，分析問題并制定計劃。例如：“要解決這個問題，我需要先確定花旗銀行的成立年份…”。
- 編碼 (<code>): 接著，模型在?<code>?標簽內生成一小段可執行的Python代碼來實現它的計劃。例如：query = "year Citibank was founded"; web_search(query)。
執行代碼 (Executed as code cell):?<code>?塊中的代碼被發送到 Python 環境中執行。
單元格輸出 (Cell output): 代碼執行的結果（例如，搜索結果或計算值）被捕獲，作為本次行動的輸出?o_t。這個輸出會成為下一步輸入給模型的新信息，從而形成一個完整的閉環。

這個循環會不斷重復，直到智能體認為已經找到了最終答案，然后調用一個特殊的工具（如?submit_answer()）來結束任務。通過這種方式，NB-Agent 能夠像一個真正的開發者一樣，通過不斷試錯和迭代來解決復雜問題，其實就是標準的A2C訓練任務，只是執行的定義都有代碼來干了，VR也是基于代碼的好壞給的。

這個好處是比較容易理解的，它這個paper里給的例子無非就是DR這種，有人會說，企業里面的系統多復雜，怎么怎么樣

我們舉個具體的例子來看，比如企業員工報銷流程

根據論文來講它現階段使用的工具主要是通用目的的，例如網頁搜索 (Web search)、文件/網頁查看器 (File viewer/Web page viewer) 等?。此外，它還有一些用于自身狀態管理的內部工具，比如記事本工具 (notepad_tool) 和提交最終答案的工具 (submit_final_answer_tool)。

如果將其應用于整合CRM、ERP等多個系統來處理報銷流程，訓練思路是否一樣？

答案是：核心的訓練思路和框架是完全一致的，但這需要進行大量的定制化工程，并且會面臨更多挑戰。

一、核心訓練思路為何一致？

這篇論文提出的L0框架，其核心是“代碼即行動”（Code-as-Action）的范式，并通過可驗證的獎勵（RLVR）進行強化學習?。這個思路具有很強的通用性，完全可以遷移到企業流程中：

工具的抽象化：在L0框架眼中，web_search()?和?crm.lookup_employee()?本質上沒有區別。它們都是可以在Python環境中被調用的函數（即工具）。您可以將CRM、ERP、報銷系統的所有API都封裝成一個個Python函數或類，作為“預定義工具”提供給智能體。

報銷場景下的工具可能包括：
- erp.create_reimbursement_form(details)
- crm.get_employee_info(employee_id)
- ocr.scan_receipt(image_path)
- approval_system.submit_for_manager_approval(form_id)
“思考-編碼-觀察”循環的適用性：這個循環非常適合處理復雜的業務流程。
- 思考: "收到張三的報銷申請，金額500元。我需要先在CRM中核實他的員工信息和部門。"
- 編碼:?employee = crm.get_employee_info(name='張三')
- 觀察: 得到返回的員工數據?{'id': '123', 'department': 'Sales'}。
- 思考: "信息無誤。接下來，我需要在ERP系統中為他創建一個報銷單。"
- 編碼:?form_id = erp.create_reimbursement_form({'employee_id': '123', 'amount': 500})
- 以此類推，直到流程走完。
可驗證獎勵（RLVR）的適用性：企業流程通常有非常明確的“成功”或“失敗”狀態，這使其成為應用RLVR的理想場景，從這個維度保險成功沒成功比你是不是從互聯網搜出來對的答案可容易驗證多了。
- 最終答案正確性: 報銷單是否成功提交并通過審批？金額、事由是否完全正確？這些都是可以自動驗證的，可以直接作為最終獎勵? $R_{final}$ 。
- 代碼執行正確性: 對CRM/ERP的API調用是否返回了成功代碼（如HTTP 200）還是錯誤代碼（如401未授權、404未找到）？這可以作為至關重要的中間步驟獎勵，引導智能體學會正確調用API?。
- 格式合規性: 這一點保持不變，依然需要智能體生成格式清晰的思考和代碼塊?。

二、可能需要解決的關鍵挑戰

雖然思路一致，但將L0框架從開放域問答應用到企業流程自動化，難度會增加，其實主要需要解決以下挑戰：

工具開發與環境搭建：您需要投入大量工程資源來開發穩定、可靠的API封裝（即工具）。更重要的是，您不能直接在生產環境訓練，必須搭建一個與生產環境高度一致的、可供智能體無限次試錯的沙箱/測試環境。這本身就是一個巨大的工程，這個基本上難了，就不說搭建一個1：1的ERP，搭建一個測試ERP服務都要好多申請流程和工作，所以這至少是個公司級別項目。
獎勵函數的設計有肯能更復雜：報銷這事好理解，但是實際生產中企業流程的“正確性”可能更難定義。報銷單金額正確，但事由填錯了怎么辦？如何自動驗證？這需要與業務邏輯深度綁定，設計出能夠準確反映業務成功的獎勵函數。反饋鏈條也可能更長（例如，審批可能需要幾天），需要更精細的中間獎勵設計。
狀態與事務管理：企業流程對事務性要求很高。如果報銷流程在中間某一步失敗了（例如，創建了報銷單但提交審批失敗），是否需要回滾操作？Agent需要學會處理失敗、重試和補償事務，這比簡單的問答要復雜得多。
安全與權限控制：賦予一個AI智能體操作CRM和ERP的權限是極其危險的。必須設計一套嚴格的權限管理和審計系統，并確保Agent運行的沙箱環境（論文中提到的Bubblewrap?）是絕對安全的，以防范潛在的濫用或攻擊。