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 ）是绝对安全的，以防范潜在的滥用或攻击。