Agent Lightning: Train ANY AI Agents with Reinforcement Learning

发表时间: 2025-08 · arXiv:2508.03680 (Microsoft Research)

文章标题: Agent Lightning: Train ANY AI Agents with Reinforcement Learning
作者/机构: Xufang Luo∗, Yuge Zhang∗, Zhiyuan He∗, Zilong Wang, Siyun Zhao, Dongsheng Li, Luna K. Qiu, Yuqing Yang; Microsoft Research

A1 主要贡献

本文提出了 Agent Lightning，这是一个灵活且可扩展的框架，能够为任何 AI 智能体（Agent）启用基于强化学习（RL）的大语言模型（LLM）训练。

核心问题与研究目标：
现有用于 LLM 的 RL 方法主要针对静态、单次调用的任务，如偏好对齐或数学推理，难以适用于复杂的智能体场景。智能体的执行通常涉及多次 LLM 调用、与外部工具的交互以及动态的工作流，这种复杂性和多样性为应用 RL 带来了算法设计和系统实现上的巨大挑战。此外，现有 RL 框架通常要求在训练系统内部重建智能体，这对于使用不同框架（如 LangChain、OpenAI Agents SDK、AutoGen）或从零开始构建的、多样化的现实世界智能体来说，是劳动密集型、易于出错且难以扩展的。

本文的目标是创建一个灵活、可扩展的框架，以解决上述挑战，使得任何现有的 AI 智能体都能通过 RL 进行训练和优化，且几乎无需修改代码。

创新点与主要贡献：
Agent Lightning 通过在算法和系统层面的专门设计，实现了智能体执行与 RL 训练的完全解耦，其主要贡献如下：

  1. 首个实现智能体与RL训练完全解耦的框架：Agent Lightning 无需修改代码即可无缝应用于任何 AI 智能体，无论其实现方式如何。这种解耦将训练与智能体的执行逻辑对齐，直接提升了智能体在真实应用中的性能，并充当一个统一的数据接口，收集多样化的智能体生成数据以提升模型能力。

  2. 创新的算法设计：

    • 智能体的马尔可夫决策过程（MDP）表述与统一数据接口：将智能体执行抽象为 MDP，定义了一个统一的数据接口。该接口将智能体执行期间收集的数据直接转换为训练轨迹，屏蔽了各种智能体执行逻辑的复杂性。
    • 分层RL算法（LightningRL）：引入了一个带有信用分配模块的分层 RL 框架，该模块将轨迹级别的回报分配给每次调用生成的响应。此设计与现有的单轮（single-turn）RL 算法无缝集成，实现了高效训练。

  3. 创新的系统设计：

    • 训练-智能体分离（TA Disaggregation）架构：通过 Lightning Server 和 Lightning Client 实现了 RL 训练和智能体执行的清晰分离，为任何智能体提供标准化的模型训练服务。
    • 智能体运行时（Agent Runtime）：作为 Lightning Client 的一部分，它透明地管理智能体执行并收集轨迹，无需修改代码。此设计使得在训练场景中可以复用可观测性基础设施（如 OpenTelemetry），确保了可扩展性和与不同智能体框架的无缝集成。
    • 自动中间奖励（AIR）机制：利用系统监控信号为智能体执行的中间步骤自动分配奖励，有效缓解了 RL 训练中的稀疏奖励问题。


图 1: Agent Lightning 概述，这是一个灵活且可扩展的框架，可为任何 AI 智能体启用强化学习。

A3 背景知识

2 现代 AI 智能体

由于 AI 智能体的多样性和快速发展，精确定义它们具有挑战性。本文不旨在引入新定义，而是提供一个抽象的表述作为对 AI 智能体的共同理解：AI 智能体是一个在其执行过程中包含一次或多次 LLM 调用的软件系统。这个宽泛的定义涵盖了从遵循预定义代码路径的基于工作流的系统【Anthropic, 2024】到能够进行动态规划、推理和长周期操作的先进多智能体系统【Anthropic, 2025; AI, 2025; Xu & Peng, 2025】的广泛现有 AI 智能体。本节将对现代 AI 智能体进行高层次的介绍，包括智能体构建中使用的常见组件、这些组件的典型编排方式以及用于轻松开发智能体的框架。

2.1 组件

智能体的构建组件：通常，智能体的构建组件可以分为两类。

  • LLMs：大型语言模型（LLM），或更广义的基础模型（FM），是智能体内部的核心推理和生成引擎。每次 LLM 生成都是从输入（提示）到输出（响应）的无状态映射。由于其巨大的计算需求，LLM 通常运行在高性能服务器或云平台上，智能体通过 API 端点访问它们。一个智能体可能会利用多个 LLM，每个 LLM 由唯一的端点 URL 标识，以执行不同任务或实现多样化功能。我们将智能体使用的 LLM 集合定义为 $M = \{M_i\}_{i=1}^m$，其中 $m$ 是智能体中 LLM 的数量。
  • 工具：工具是智能体调用以执行特定任务的功能，例如从数据库检索信息、执行代码或与 API 交互。工具可以是无状态的或有状态的。工具的实现方式多样，可以是外部 API、本地程序或库。近期的趋势是，工具通常遵循模型上下文协议（MCP）【Protocol, 2025】或其他智能体通信协议，以标准化智能体与工具之间的交互。我们将智能体可用的工具集表示为 $T = \{T_j\}_{j=1}^t$，其中 $t$ 是工具的数量。

2.2 编排

组件的动态编排：使用组件集 $M \cup T$ 作为功能构建块，编排——包括执行流程、依赖关系和组件间的顺序——通常由用户根据任务需求定制。这种编排通常既不是固定的也不是确定性的。现代 AI 智能体表现出动态行为，其中 LLM 可能会根据不断变化的上下文决定后续行动或选择工具。例如，一个 RAG 智能体可以通过让 LLM 决定是优化查询还是直接回答问题，从而与数据库进行可变次数的交互。这种动态交互虽然捕获了丰富的特定任务行为，但也给数据建模和下游学习带来了巨大挑战，使得使用当前的 RL 训练框架实现不同智能体变得不切实际且不可扩展。

2.3 实现

智能体的实现方式：开发者有多种创建 AI 智能体的方法。一些人可能选择从零开始构建以获得完全的控制和定制。另一些开发者则可能利用成熟的智能体开发框架，如 LangChain 【LangChain, 2025】、OpenAI Agents SDK 【OpenAI, 2025】和 AutoGen 【AutoGen, 2025】，这些框架提供了基础设施并加速了开发。这些框架通过提供模块化组件（LLM 和工具）和灵活的动态编排机制来促进开发。然而，无论智能体是自建还是使用框架构建，它们通常都缺乏自动自我改进的机制，也不涉及智能体优化。在现实世界场景中，尤其是在处理私有数据时，智能体的性能往往达不到要求，因此需要自动化优化。

A2 方法细节

3 Agent Lightning

本节将阐述所提出的 Agent Lightning 框架。首先在 3.1 节定义统一的数据接口，该接口规定了在智能体执行期间收集哪些数据，且与智能体设计无关。接下来，在 3.2 节展示智能体中的马尔可夫决策过程，为强化学习（RL）奠定基础。然后，在 3.3 节介绍我们的分层 RL 算法，该算法利用在智能体中收集的数据来更新 LLM。最后，在 3.4 节描述我们量身定制的基础设施，其中包含几个优雅的设计元素，显著简化了智能体训练过程。

3.1 统一数据接口

数据驱动优化的基础：数据驱动的智能体优化从根本上依赖于智能体执行期间生成的数据。因此，在 Agent Lightning 中，我们定义了一个统一的数据接口，规定了这些数据如何输入到 RL 训练算法中。这个接口具有高度的通用性，可以应用于从任何 AI 智能体收集的数据。AI 智能体是一种特殊的软件，其执行过程可以表示为一个有向无环图（DAG）【1, Alfred et al., 2007; Abadi et al., 2016】。在这个图中，每个节点对应于来自集合 $M \cup T$ 的组件调用（LLM 或工具），而每条边代表组件之间的依赖或控制流。然而，从无组织的智能体执行跟踪中解析一个完整的图是相当困难的，并且我们发现，这对于训练目的来说是不必要的。通过利用马尔可夫决策过程（MDP）中的概念，我们只需要识别当前状态和影响状态转换的关键因素（即调用），就可以执行 RL 优化。

3.1.1 状态和调用

状态的定义：我们将状态定义为智能体执行的一个快照，其中可能包含程序计数器、变量值、调用堆栈、资源上下文等信息。这些可以抽象为一组随智能体执行而随时间演变的变量。同一任务 $x$ 可能被执行多次，由于智能体的动态行为，会产生不同的执行轨迹。对于任务 $x$ 的第 $k$ 次执行，在时间步 $t$ 包含 $V$ 个变量的状态表示为：

状态的演变与语义变量：在智能体执行期间，状态会持续变化。然而，并非所有中间操作都对智能体优化至关重要。我们主要关注那些被组件使用或修改并代表关键语义（如程序意图）的关键变量，我们称之为语义变量（Semantic Variable）【21, Lin et al., 2024】。一个关于状态和语义变量的具体例子在 3.1.3 节和图 2 中提供。

组件调用：语义变量的改变是通过智能体的组件调用（Component Invocation）发生的。假设任务 $x$ 的第 $k$ 次执行由 $N$ 个组件调用组成：

其中第 $i$ 个组件调用定义为一个 call：

在这里，$C_i \in M \cup T$ 表示此次调用中被调用的组件（LLM 或工具），$input_{x,k}$ 和 $output_{x,k}$ 代表输入和输出数据。$meta_{x,k}$ 包含调用的相关元信息，如 $C_i$ 的名称、类型、版本、API 端点，以及运行时参数（如 LLM 调用的采样策略和温度）。

状态与调用的关系：由于状态代表了智能体的一个快照，所有的输入和输出都是特定时间步的语义变量：

并非状态中的所有信息对于被调用的组件都是必要或可见的。例如，在图 2 中，尽管状态包含 4 个语义变量，但 LLM 在编写第一个查询时只能看到用户输入，而搜索工具只接收生成的查询作为输入。

3.1.2 奖励和数据集

奖励信号的引入：为了能够从智能体执行期间收集的数据中学习，我们引入了奖励信号来衡量任务完成的质量。每次智能体执行都附带了标量奖励 ${r_1, . . . , r_N}$，其中每个 $r_i \in \mathbb{R}$ 对应第 $i$ 次调用的质量。一次带有奖励信号的执行表示为：

奖励的类型：奖励信号可以在智能体执行的中间步骤或结束时提供。中间奖励 $r_i (i < N)$，如工具调用成功或部分任务完成的指标，提供更细粒度的反馈。最终奖励 $r_N$ 通常评估智能体完成任务的整体成功情况。在许多现实场景中，只有终端奖励 $r_N$ 可用，这代表了中间奖励 $r_1, . . . , r_{N−1}$ 缺失的特殊情况。

数据集的构成：用于训练或评估的数据集由一个任务集 $X = {x_1, . . . , x_{|X|}}$ 和一个奖励函数组成，其中 $| \cdot |$ 表示集合的大小。任务可以被多次执行，并根据奖励函数进行标注。

3.1.3 一个示例说明

RAG 智能体示例：为了具体说明智能体执行和统一数据接口，我们考虑一个典型的检索增强生成（RAG）智能体，如图 2 所示。该智能体旨在通过首先检索相关文档，然后基于这些文档生成一个答案来回答用户查询。智能体包含两个主要组件：生成策略模型（$M = {\text{LLM}}$）和一个搜索工具（$T = {\text{Search}}$）。


图 2: Agent Lightning 中统一数据接口的图示。左侧面板描绘了智能体执行流程，其中每个状态转换由语义变量的更新表示（绿色矩形表示具有有效值的变量；灰色矩形表示在当前状态下尚未分配的变量）。右侧面板展示了在智能体执行过程中收集的相应轨迹，演示了统一数据接口如何系统地捕获所有相关的转换以进行基于 RL 的优化。

执行流程：执行流程如下：
1. 用户提交一个特定任务（$x$），附带问题（UserInput）。
2. 智能体调用 LLM，根据 UserInput 生成一个搜索查询（Query）。
3. 搜索工具使用生成的 Query 检索相关段落（Passages）。
4. 智能体再次调用 LLM，利用检索到的 Passages 和原始的 UserInput 生成最终答案（Answer）。

数据接口的体现：完成后，一个奖励函数（例如，RAG F1 分数）评估生成的 Answer 的质量。根据我们的表述，每个状态封装了语义变量的当前值（图 2 中的绿色矩形表示有值的变量，灰色矩形表示无值的变量）。随着智能体执行，调用一个组件（LLM 或工具）会更新相关的语义变量，导致状态转换到下一个。因此，给定任务 $x$ 的智能体执行被表示为一个有序的调用序列（如图 2 右侧所示），每个调用包括组件、其输入、输出以及相关的奖励（通常仅对最终调用可用）。

数据接口的优势：重要的是，我们的统一数据接口捕获了所有状态变化，包括由非 LLM 组件引起的变化，从而实现了灵活且高度可定制的优化方法。例如，它支持对多智能体系统中的特定智能体进行选择性优化（详见 3.2.2 节和 4.1 节的实验），以及模型微调之外的优化，如提示词优化。通过在每个状态中捕获完整的执行上下文，我们的统一数据接口为策略学习提供了足够的信息，实现了智能体执行与 RL 训练的清晰解耦。这种设计适应了任意复杂的智能体交互逻辑，无需显式解析整个执行 DAG，从而极大地简化了对多样化智能体工作流的 RL 优化。

3.2 智能体中的马尔可夫决策过程

3.2.1 表述

单 LLM 智能体的 POMDP 表述：让我们从一个简单案例开始：一个包含单个待优化 LLM 的智能体。当我们将这个 LLM 视为一个策略模型时，我们可以将其决策过程建模为一个部分可观察马尔可夫决策过程（POMDP），这构成了应用 RL 的基础。POMDP 元组 $M = (S, O, A, P, R)$ 可以定义为：
* $S$ 是状态空间，对应所有可能的状态，即 $state_t \in S$；
* $O$ 是观察空间，对应策略 LLM 的所有可能输入，即 $input_t \in O$；
* $A$ 是动作空间，其中单个动作被定义为策略 LLM 单次调用生成的整个令牌序列，即 $output_t \in A$。
* $T (s'|s, a)$ 定义了到新状态的（通常未知的）转换动态；
* $R(s, a)$ 是奖励函数，将状态-动作对映射到标量奖励；

决策过程：具体来说，在每个步骤 $t$，智能体的快照是 $state_t$，LLM 观察到一个上下文 $input_t$。如 3.1.1 节所述，$input_t$ 是一个语义变量，代表了 $state_t$ 中对策略 LLM 决策可见或必要的部分。然后，LLM 生成一个令牌序列 $output_t = (y_{t,1}, y_{t,2}, . . . , y_{t,N_t})$ 作为其输出。这个序列被视为一个单一的动作，表示为 $a_t \in A$。执行 $a_t$ 后，智能体转换到一个新的状态 $state_{t+1}$。可能会提供一个标量奖励 $r_t = R(s_t, a_t)$ 来评估该动作的质量。回报定义为奖励的总和：

策略模型的目标是最大化回报。

3.2.2 为 RL 提取数据

轨迹数据提取：基于上述 MDP 表述，我们需要收集包含所有策略 LLM 决策及其相关奖励的轨迹以进行 RL。为此，我们从每次执行（即公式 5）中仅提取与更新由 $\theta$ 参数化的策略 LLM 相关的信息：LLM 调用的原始输入、输出及其奖励，表示为：

这里，$\pi_\theta$ 是待优化的 LLM，T 是此轨迹中的调用次数。图 2 演示了此数据提取过程。

提取的优势：LLM 调用是无状态且高度灵活的。它们的输入可以编码由复杂智能体逻辑产生的各种信息。对于 RL 训练，由于 MDP 的表述，我们可以忽略繁琐多变的逻辑和处理，仅关注 LLM 的当前输入和输出。这种方法避免了对高度动态的智能体运行所产生的轨迹进行繁琐但非平凡的解析，使得应用 RL 优化任何 AI 智能体成为可能。

总结与应用：总之，统一数据接口和 MDP 表述使 Agent Lightning 能够清晰地分离特定于任务的智能体设计和基于学习的策略优化，为在模块化和动态的智能体系统中进行有效的 RL 优化奠定了基础。

应用于单 LLM 多智能体设置：上述表述灵活地适用于具有单个 LLM 的多智能体场景，其中 LLM 可以根据提示在执行的不同阶段扮演多个角色。在图 2 的 RAG 案例中，第一次 LLM 调用时，我们可以指示模型专注于搜索，生成搜索查询 $a_1$。第二次 LLM 调用时，我们可以指示模型专注于回答问题，生成最终答案 $a_2$。Agent Lightning 能够通过在优化过程中包含相应智能体的转换来选择性地优化多智能体系统中的智能体。

扩展到多 LLM 设置：当必须联合优化多个具有各自参数的独立 LLM 时，一个直接的方法是将每个 LLM 视为一个独立的 MDP 并分别优化它们。然而，这忽略了策略之间的相互依赖性。一个更原则性的方法是使用多智能体强化学习（MARL）或博弈论，将每个 LLM 视为一个具有自己目标和策略的智能体【23, Lowe et al., 2017; 52, Zhang et al., 2021】。


图 3: LightningRL 算法图示。(a) 单次调用 GRPO，其中 LLM 一次性为任务生成响应。同一任务的输出被分组以进行优势估计。(b) 先前的多轮 GRPO。每个轨迹包含多个 LLM 调用，同一任务的轨迹被分组以进行优势估计。在优化过程中，非 LLM 生成的令牌被屏蔽（灰色虚线框）。(c) 我们提出的 LightningRL。轨迹被分解为转换，同一任务的转换被分组以进行优势估计。每个转换包括当前输入/上下文、输出和奖励。输入是当前智能体状态的一部分，奖励由信用分配模块计算。

3.3 LightningRL：一种用于优化智能体中 LLM 的分层 RL 方法

3.3.1 LLM 单轮强化学习初步

单轮 RL 算法：近期 LLM 的 RL 进展主要集中在单次调用问题上，模型一次性为提示生成响应。在这类设置中，给定任务 $x$，LLM 从策略 $\pi_\theta$ 逐个令牌生成响应 $output = (y_1, . . . , y_N)$，每个令牌被视为一个动作。响应生成后，根据解决方案的正确性或质量分配一个标量奖励 $r(x, output, \hat{y})$。典型的令牌级损失可以简化为：

其中 $A_j$ 是令牌级别的优势估计。不同算法的核心区别在于优势项 $A_t$ 的估计。标准 PPO 【33, Ouyang et al., 2022】使用学习到的评论家模型，而 GRPO 【36, Shao et al., 2024】通过将响应的奖励与同一提示生成的一组响应的奖励均值和标准差进行归一化来计算优势。REINFORCE++ 【14, Hu, 2025】使用更简单的基线，将优势定义为当前响应奖励与整个训练批次平均奖励之差。

3.3.2 通过 LightningRL 扩展到智能体场景

从单轮到多轮的挑战与解决方案：在我们的 MDP 表述中，我们将单次 LLM 调用生成的整个令牌序列视为一个动作。策略可能需要通过多次交互来完成一个完整的 episode。为了弥合这种差距，Agent Lightning 引入了一种简单的分层强化学习（HRL）方法，称为 LightningRL。该方法无需修改即可与现有的单轮 LLM RL 方法无缝集成，并有效支持在任何智能体场景中的优化。

LightningRL 的工作机制：如图 3 所示，Agent Lightning 使用转换来组织数据，每个转换定义为元组 $(input_{x,k_t}, output_{x,k_t}, r_{x,k_t})$。LightningRL 应用一个两步机制：首先，episode 级别的回报 $R$ 通过一个信用分配模块在动作之间分配；然后，它在每个动作内的令牌之间进一步分解，产生令牌级别的监督信号。在当前实现中，LightningRL 简单地假设 episode 内的每个动作具有相同的值，等于最终回报 $R$。第二步则由现有的单轮 LLM RL 算法处理。

LightningRL 的优势：
1. 兼容性：允许直接使用任何单轮 RL 算法，特别是轻量级且高效的无价值函数方法。例如，在 GRPO 中，我们将因相同任务 $x$ 而生成的不同执行数据分解为单个动作，然后按任务对这些样本进行分组以计算统计数据。
2. 灵活的观察构建：由于数据以单个转换的级别组织，每个转换都有自己的奖励，因此可以灵活地从状态中派生当前输入/观察。这与之前的方法形成对比，后者通常将一个轨迹中的所有轮次连接成单个响应并使用掩码来控制更新部分，这种方法不支持灵活和模块化的上下文构建。
3. 鲁棒性和可扩展性：与基于掩码的策略相比，LightningRL 提供了更鲁棒和可扩展的实现。它避免了与训练和智能体执行逻辑的紧密耦合，不会破坏 RoPE 等位置编码的连续性【41, Su et al., 2024】，并简化了代码验证和调试。此外，将数据组织成转换形式缓解了因累积上下文和连接所有轮次而导致的上下文过长问题。

更复杂的信用分配：信用分配模块允许未来集成更复杂的策略，例如基于启发式或学习模型分配信用。一个可能的未来工作方向是引入一个高层价值函数来单独估计每个动作的预期回报。尽管如此，我们的实验结果表明，简单的相同分配策略在多种场景和数据集中是有效的。

3.4 Agent Lightning 的系统设计

训练用于真实世界智能体的 LLM 是一项具有挑战性的工作，需要集成 RL 训练框架和智能体开发框架。Agent Lightning 框架通过提供一个统一的解决方案来应对这一挑战，促进了使用 RL 和其他优化技术无缝开发和训练智能体。

3.4.1 训练-智能体分离架构

RL 训练框架的组件：用于 LLM 的 RL 训练框架包括两个主要组件：训练器（trainer）和部署（rollout）。训练器负责更新模型权重，而部署则捕获训练器使用的数据，即轨迹。对于智能体任务，部署需要完整执行智能体，这不仅包括多次 LLM 生成，还包括执行本地代码，如工具使用。

核心创新：训练-智能体分离：Agent Lightning 的核心创新是其训练-智能体分离（Training-Agent Disaggregation）架构，该架构解耦了计算密集的 LLM 生成和轻量级但多样灵活的应用逻辑及工具。前者由 RL 框架管理，并向后者暴露一个类似 OpenAI 的 API，如图 4 所示。后者可以独立管理和执行，无需与 GPU 资源共存。


图 4: 训练-智能体分离架构。

智能体无关的训练与训练器无关的智能体：该架构的一个关键优势是训练框架和智能体之间的相互独立性。训练框架（如 VeRL【38, Sheng et al., 2024】）变得与智能体无关，只关心 LLM 的优化和硬件资源管理。反之，在客户端运行的智能体也与训练器无关，可以独立于训练框架的实现细节运作。

系统架构与工作流程：Agent Lightning 引入了一个双组件架构：Agent Lightning Server 和 Agent Lightning Client。服务器与 RL 框架集成，管理训练过程和 LLM 优化。客户端封装智能体，使其独立运行。工作流程如下：用户上传任务数据集后，服务器与 RL 框架一同初始化并协调训练过程。服务器将数据集分批，并通过清单方式将任务批次分派给客户端，同时为每个任务传递一个唯一的类似 OpenAI 的 API 端点。客户端在智能体运行时（3.4.2 节）中执行智能体以生成轨迹和奖励。这些轨迹被收集并报告回服务器，服务器处理数据并将其转发给训练框架以更新模型参数。

3.4.2 智能体运行时

Agent Lightning 客户端是一个智能体的运行时管理器，负责协调执行、捕获数据、处理错误并与服务器通信。

  • 智能体执行的数据并行：为了充分利用计算资源并减少部署延迟，Agent Lightning 客户端实现了两级并行策略：节点内并行（一个客户端在单机上运行多个工作进程）和节点间并行（多个客户端在不同机器上运行），从而实现灵活扩展和高效资源利用。
  • 无代码修改的数据捕获：为与现有智能体代码库无缝集成，客户端采用两种检测技术：一种基于 OpenTelemetry【32, OpenTelemetry, 2025】和 AgentOps【2, AgentOps, 2025】，自动检测智能体代码以捕获执行轨迹；另一种是嵌入在类似 OpenAI API 端点中的基本跟踪机制，轻量且可扩展。
  • 错误处理和鲁棒性：为确保训练过程的稳定性和可靠性，客户端集成了全面的错误处理机制。它能检测智能体代码未妥善处理的故障（如崩溃或长时间挂起的工具调用），确保这些故障不会中断整个训练过程，并支持任务重试或重新分配。
  • 自动中间奖励（AIR）：客户端提供 AIR 机制，将系统监控数据转换为中间奖励，从而为训练过程提供更频繁、信息更丰富的信号，以解决 RL 训练中奖励延迟和稀疏的问题。
  • 环境和奖励服务的可扩展性：对于轻量级的环境和奖励函数，它们可以直接在与智能体实例相同的工作进程中执行。对于资源密集型或初始化成本较高的环境和奖励函数（如手机模拟器），客户端支持将它们作为共享服务托管，以提高效率。

A4 实验环境与结果

实验环境

Agent Lightning 的有效性在三个不同的任务上得到了验证，每个任务都使用不同的智能体框架实现。表 1 总结了实验中的任务和设置。

表 1: 实验中任务和设置的摘要。

  1. Text-to-SQL (LangChain)

    • 数据集: Spider【51, Yu et al., 2018】，一个复杂的跨领域 text-to-SQL 基准，包含超过10,000个问题和200个数据库。
    • 模型: Llama-3.2-3B-Instruct【26, Meta, 2024】。
    • 硬件/软件配置: 使用 LangChain 实现为一个多智能体系统，包括SQL编写、执行、检查和重写等多个智能体角色。在训练中，选择性地同时优化SQL编写和重写两个智能体。

  2. 检索增强生成 (OpenAI Agents SDK)

    • 数据集: MuSiQue【44, Trivedi et al., 2022】，一个多跳问答基准。检索源为整个维基百科（2100万份文档）。
    • 模型: Llama-3.2-3B-Instruct【26, Meta, 2024】。
    • 硬件/软件配置: 使用 OpenAI Agents SDK 实现。检索工具使用 BGE 模型【7, BAAI, 2023; 53, Zhang et al., 2023】生成的嵌入和余弦相似度。

  3. 带工具使用的数学问答 (AutoGen)

    • 数据集: Calc-X【19, Kadlcˇ´ık et al., 2023】，包含需要推理和精确计算的数学问题，强调将外部工具（计算器）集成到推理流程中。
    • 模型: Llama-3.2-3B-Instruct【26, Meta, 2024】。
    • 硬件/软件配置: 使用 AutoGen 实现。智能体需要决定何时以及如何调用计算器工具来解决问题。

实验结果

4.1 通过 LangChain 实现的 Text-to-SQL

实验内容：在一个多智能体系统中，LLM 需要生成和修正 SQL 查询，并最终回答问题。奖励由最终答案的正确性决定。
实验结果与分析：如图 5 所示，Agent Lightning 实现了稳定的奖励提升。这表明它能够优化涉及代码生成和工具使用的复杂多步决策，并能在一个多智能体系统中选择性地优化一个或多个智能体。


图 5: Text-to-SQL 任务的奖励曲线。

4.2 通过 OpenAI Agents SDK 实现的检索增强生成

实验内容：在一个 RAG 任务中，智能体需要生成自然语言查询以从大型文档库中检索信息，并根据检索结果决定是优化查询还是生成答案。训练奖励是格式得分和答案正确性（F1分数）的加权组合。
实验结果与分析：图 6 表明 Agent Lightning 在这个具有挑战性的任务上实现了稳定的性能提升，证明了其在更复杂和开放的 RAG 场景中的有效性。


图 6: 检索增强生成任务的奖励曲线。

4.3 通过 AutoGen 实现的带工具使用的数学问答

实验内容：在一个数学问答任务中，智能体需要决定如何以及何时调用计算器工具来辅助解题。最终奖励基于答案的正确性。
实验结果与分析：如图 7 所示，Agent Lightning 在训练过程中持续提升性能。这证明了它在需要精确外部函数调用和推理的工具增强环境中的有效性。


图 7: 计算器任务的奖励曲线。

A7 补充细节

5.1 相关工作

LLM多轮RL的最新进展：近期工作如 RAGEN【48, Wang et al., 2025b】、Trinity-RFT【34, Pan et al., 2025】、rLLM【42, Tan et al., 2025】等探索了在多轮交互环境中的 RL。这些方法通常将智能体各轮次交互拼接成一个长序列，并使用特定掩码进行优化。Agent Lightning 的方法与之不同，通过 MDP 表述、统一数据接口和信用分配模块将数据组织成单个转换。这种基于转换的建模支持更广泛的智能体架构，缓解了上下文长度累积的问题，无需自定义掩码，并为更高级的 RL 算法（如分层 RL）解锁了潜力。

大规模LLM RL训练系统：verl【38, Sheng et al., 2024】、OpenRLHF【15, Hu et al., 2024】、TRL【46, von Werra et al., 2020】等系统主要关注单轮场景下的高效 LLM 训练。虽然它们也为基于智能体的应用提供了扩展，但通常要求开发者在训练系统内部重建智能体，这与现实中智能体开发生态的多样性相矛盾。Agent Lightning 的系统设计通过完全解耦 RL 训练与智能体，消除了在 RL 训练引擎中编写数据收集逻辑的需要，几乎无需修改智能体端代码，因此可以无缝集成各种智能体。

以算法为中心的多轮RL工作：ArCher【54, Zhou et al., 2024】和 WebShop【50, Yao et al., 2022】等工作探索了多轮 RL，但通常使用较小的策略模型或 PEFT，难以将其实现复用于大规模模型。

特定应用的RL训练：自 DeepSeek-R1【13, Guo et al., 2025】成功以来，RL 在特定场景（如 RAG 和编码）中的应用激增，例如 Search-R1【18, Jin et al., 2025】、R1-Searcher【40, Song et al., 2025】和 DeepSWE【24, Luo et al., 2025】。这些工作主要针对特定任务或场景，并依赖于预定义的工作流，而非通用的智能体训练。相比之下，Agent Lightning 提供了一个适用于任何 AI 智能体的统一方法。

5.2 未来工作

  • 更多优化方法：除了 RL，本框架也支持其他优化方法，如自动提示优化。通过引入“感兴趣组件”（Component of Interest, CoI）的概念，可以指定优化目标（例如，将提示模板渲染视为一个工具调用并进行优化）。
  • RL算法的改进：开发更高效的 RL 算法是解决更复杂智能体场景中模型优化的关键，包括长时程信用分配、探索算法、离线策略算法等。Agent Lightning 以转换为单位组织数据，为集成这些算法提供了便利。
  • 智能体RL系统基础设施的进步：进一步分离系统组件（训练器、部署/推理引擎和智能体工作流），以解决部署瓶颈并提高大规模 RL 训练的可扩展性。
  • 高效服务：探索更先进的 LLM 服务方法（如 Parrot【21, Lin et al., 2024】）以优化资源利用，并利用长上下文加速技术（如 Minference【16, Jiang et al., 2024】）来提升性能。

A5 结论

Agent Lightning 是一个灵活且可扩展的框架，通过将智能体执行与强化学习训练完全解耦，使得对任何 AI 智能体进行 RL 训练成为可能。该框架的核心是其统一的数据接口和分层 RL 算法（LightningRL），它们共同将复杂的智能体交互逻辑抽象为可训练的转换序列。系统层面，训练-智能体分离架构通过 Lightning Server 和 Client 提供了标准化的训练服务，使开发者能够以几乎零代码修改的方式优化现有智能体。实验证明，Agent Lightning 在文本到SQL、检索增强生成和数学工具使用等多种任务上均能实现稳定、持续的性能提升，展示了其在真实世界智能体训练和部署中的巨大潜力。未来的工作将集中在支持更多优化方法、改进 RL 算法和系统基础设施，以及提升服务效率上。

A6 附录

A 使用 Agent Lightning 优化现有智能体的示例

这是一个如何使用 Agent Lightning 优化现有智能体的示例。给定一个与游戏环境（例如，20个问题或猜数字）交互的简单智能体，我们可以使用 Agent Lightning 框架来优化其性能，而无需修改智能体代码本身。以下是智能体的典型文件夹结构：

列表 1: 智能体代码文件夹结构
列表 2: Agent Lightning 训练脚本

在此示例中，agent.py 文件包含智能体的逻辑函数 agent_function，它接收 LLM 的端点和游戏环境，并返回游戏的答案。游戏服务器由 environments/game_server.py 创建，使用保存在 data/train.jsonl 中的（游戏种子，真实答案）对。要使用 Agent Lightning 优化此智能体，我们可以创建一个 train.py 文件，该文件使用 Agent Lightning 框架来优化智能体的性能，而无需修改智能体代码。

B Agent Lightning 的流程图


图 8: 流程图