Agent Lightning: Train ANY AI Agents with Reinforcement Learning

论文阅读：Agent Lightning: Train ANY AI Agents with Reinforcement Learning

论文标题：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
发表位置：arXiv preprint / CoRR
arXiv 编号：2508.03680
首次提交：2025 年 8 月 5 日
原文链接：https://arxiv.org/abs/2508.03680
项目代码：https://github.com/microsoft/agent-lightning
主题：Agentic RL、Agent Post-training、Multi-turn RL、LLM Agent、强化学习系统
核心问题：如何让已经使用任意 Agent 框架构建好的复杂 Agent，在几乎不修改 Agent 代码的情况下，直接接入现有的 LLM 强化学习训练系统？

1. 论文要解决什么问题？

Agent Lightning 想解决的其实不是“怎么设计一个更聪明的 Agent”，而是另一个更底层的问题：

一个已经存在的 Agent，究竟应该怎样接入 RL 训练？

对于普通的 LLM 强化学习，这件事比较简单。

例如数学题训练时：

  1. 给模型一个问题；
  2. 模型生成一个回答；
  3. 根据答案正确与否计算 reward；
  4. PPO、GRPO 等算法根据 reward 更新模型。

整个过程大致就是：

prompt
  ↓
LLM
  ↓
response
  ↓
reward
  ↓
RL update

但是 Agent 完全不同。

一个现实中的 Agent 可能包含：

  • 多次 LLM 调用；
  • 不同角色的 Agent；
  • 搜索工具；
  • 数据库；
  • Python / Shell；
  • 外部 API；
  • MCP server；
  • 条件分支；
  • 循环；
  • 动态规划；
  • Agent 之间的通信。

例如一个 RAG Agent 可能执行：

用户问题
  ↓
LLM 生成检索 query
  ↓
搜索工具
  ↓
返回文档
  ↓
LLM 判断是否继续搜索
  ↓
再次搜索
  ↓
LLM 生成答案

一个 Coding Agent 的执行流程可能更加复杂。

问题在于，传统 PPO、GRPO 等 LLM RL 框架通常并不知道这些 Agent 逻辑。

它们更习惯处理：

prompt → response → reward

而不是：

Agent framework
    ↓
LLM
    ↓
Tool
    ↓
LLM
    ↓
Environment
    ↓
LLM
    ↓
Tool
    ↓
...

因此很多已有 Agentic RL 方法采用一种比较直接的做法：

把 Agent 多轮执行过程中产生的所有内容拼成一条长序列，再通过 mask 告诉训练框架哪些 token 是模型生成的、哪些 token 不应该计算 loss。

例如可以抽象成：

Prompt
LLM output
Tool output
LLM output
Environment feedback
LLM output
...

最后拼成：

[Prompt][LLM][Tool][LLM][Environment][LLM]...

然后给不同位置设置 mask。

这种方法在简单、顺序式的多轮任务中可行，但论文认为它有几个问题：

  1. 训练逻辑和 Agent 执行逻辑紧密耦合；
  2. 不同 Agent 的执行方式不同，很难设计统一的数据拼接方式；
  3. multi-agent、动态 workflow 等复杂结构更难处理；
  4. 多轮内容不断拼接以后 sequence 会越来越长；
  5. mask 的构造、debug 和 kernel 实现都更加复杂；
  6. 想把一个已经写好的 LangChain、AutoGen 或 OpenAI Agents SDK Agent 接进 RL 系统，往往需要重新实现它的 rollout 逻辑。

Agent Lightning 的目标，就是把这个耦合关系拆开。

作者希望最终做到：

Agent 负责按照原来的方式运行，RL 系统负责训练模型，双方通过一套统一的数据接口通信，而 RL 系统不需要知道 Agent 内部到底是怎么编排的。

这就是论文标题中所谓：

Train ANY AI Agents with Reinforcement Learning

这里的重点其实不是一种新的 reward，也不是一种新的 PPO/GRPO，而是建立一个：

Agent execution ↔ RL training

之间的通用接口。

2. 作者如何抽象现代 Agent？

在正式介绍 Agent Lightning 之前，论文首先给出了一个非常宽泛的 Agent 定义：

AI Agent 是一个执行过程中包含一次或多次 LLM 调用的软件系统。

这种定义故意没有限制 Agent 必须采用 ReAct、Plan-and-Execute 或某一种固定范式。

因此：

  • workflow Agent；
  • tool-use Agent；
  • RAG Agent；
  • multi-agent system；
  • 动态规划 Agent；

都可以被包含进来。

作者把 Agent 中的组件粗略划分成两类。

2.1 LLM

LLM 是 Agent 中负责推理和生成的组件。

单次 LLM 调用可以看成一个无状态映射：

input → LLM → output

一个 Agent 可以使用一个模型，也可以使用多个不同模型。

2.2 Tool

Tool 是 Agent 调用的外部功能，例如：

  • 数据库；
  • 搜索引擎；
  • Python；
  • API；
  • 文件系统；
  • MCP tool；
  • calculator。

Tool 本身既可能是 stateless，也可能维护自己的状态。

真正让 Agent 复杂起来的，是这些组件之间的 orchestration（编排）。

例如 LLM 可能根据当前结果决定：

继续搜索？
调用工具？
修改 query？
直接回答？
把任务交给另一个 Agent？

因此 Agent 的运行轨迹并不一定是一条固定、确定的链。

Agent Lightning 要做的事情，就是：

无论这些组件到底怎么编排，都把它们转换成 RL 能够理解的统一形式。

3. Agent Lightning

论文的方法部分主要包含四层：

  1. Unified Data Interface：统一 Agent 执行数据；
  2. Agent 的 MDP / POMDP 建模：建立强化学习形式化；
  3. LightningRL：把 Agent trajectory 转换成现有 LLM RL 可以训练的数据；
  4. Training-Agent Disaggregation：从系统层把 Agent 与训练框架解耦。

其中前三者更多解决“训练数据怎么定义”的问题，第四部分解决“工程上怎么真正把任意 Agent 接进来”。

3.1 Unified Data Interface：不理解整个 Agent，只记录关键变化

这是整篇论文最重要的思想之一。

从程序执行角度，一个 Agent 可以表示为某种执行图：

  • 节点表示一次组件调用；
  • 边表示控制流或依赖关系。

理论上，我们当然可以把整个 Agent execution graph 全部恢复出来，再分析：

谁调用了谁
为什么调用
哪条分支被执行
哪些变量被修改

但作者认为：

为了做 RL，没有必要解析整个 Agent execution DAG。

真正需要知道的是：

在模型每一次做决策的时候，它看到了什么、输出了什么，以及之后获得了什么 reward。

3.1.1 State：Agent 当前执行到哪里了？

对于任务 \(x\) 的第 \(k\) 次运行，作者把时刻 \(t\) 的 Agent state 定义为一组变量：

\[\mathrm{state}_t(x,k) = \left\{ \mathrm{variable}^{x,k,t}_i \right\}_{i=1}^{V} \]

这些变量可以包含：

  • program counter；
  • 当前变量值；
  • call stack；
  • resource context；
  • 用户输入；
  • 已经生成的 query；
  • 检索到的 passages；
  • 当前中间结果。

但显然并不是所有程序变量都值得记录。

例如：

for 循环执行到第几次
某个临时字符串变量
内部计数器

通常与 Agent 学习没有直接关系。

因此作者重点关注所谓的 Semantic Variable：

对 Agent 当前语义状态真正重要的变量。

例如一个 RAG Agent 中：

UserInput
Query
Passages
Answer

就属于 Semantic Variables。

3.1.2 Call：什么东西改变了 State？

Agent state 的重要变化一般来自某一次组件调用。

一次调用被表示为：

\[\mathrm{call}^{x,k}_i = \left( \mathrm{meta}^{x,k}_i, \mathrm{input}^{x,k}_i, \mathrm{output}^{x,k}_i \right) \]

其中：

\[\mathrm{output}^{x,k}_i = C_i \left( \mathrm{input}^{x,k}_i \right) \]

\(C_i\) 可以是：

  • LLM；
  • Tool。

meta 则保存组件名称、类型、版本、API endpoint，以及 LLM temperature、sampling strategy 等运行信息。

因此作者没有试图要求所有 Agent 拥有相同的代码结构。

只要能够记录：

哪个组件被调用
    ↓
输入是什么
    ↓
输出是什么

就可以统一描述 Agent 的执行。

3.1.3 Reward

在执行过程中，还可以给每次调用关联一个 reward。

完整执行因此可以抽象成若干：

(call, reward)

reward 可以来自中间步骤，也可以只在 episode 结束后出现。

例如：

LLM 生成 query       reward = 无
Search tool          reward = 无
LLM 生成最终答案      reward = 1

现实任务中非常常见的情况就是：

前面没有 reward，只有最终任务完成后才得到 terminal reward。

Agent Lightning 的接口同时支持这两种情况。

3.1.4 用一个 RAG Agent 理解 Unified Data Interface

论文 Figure 2 给了一个很直观的例子。

一个 RAG Agent 包含：

  • 一个 LLM；
  • 一个 Search tool。

执行过程为：

UserInput
   ↓
LLM
   ↓
Query
   ↓
Search
   ↓
Passages
   ↓
LLM
   ↓
Answer
   ↓
Reward

状态中的 Semantic Variables 一开始是：

UserInput = 已知
Query     = 空
Passages  = 空
Answer    = 空

第一次调用 LLM：

Query = LLM(UserInput)

于是 Query 被填入。

随后：

Passages = Search(Query)

最后：

Answer = LLM(UserInput, Passages)

最终 reward 根据 Answer 的质量计算。

image

【Figure 2（Unified Data Interface：展示 RAG Agent 的 Semantic Variables 如何随 LLM / Search 调用更新，以及完整执行轨迹如何被抽取成 RL trajectory）】

Figure 2 中尤其重要的是右半部分。

完整执行数据可能包含：

LLM call
Search call
LLM call

但如果现在真正要优化的只有 LLM，那么 RL 部分只需要抽取：

LLM input → LLM output → reward

也就是说：

Tool 调用仍然属于 Agent execution 的一部分，但它不一定直接成为 policy optimization 的训练样本。

这使 Agent Lightning 可以知道完整 Agent 发生了什么，同时只选择真正需要优化的组件。

3.2 把 Agent 建模成 POMDP

有了前面的统一接口，作者进一步把 Agent 执行形式化为一个 POMDP：

\[\mathcal{M} = (\mathcal{S},\mathcal{O},\mathcal{A},\mathcal{T},\mathcal{R}) \]

其中：

  • \(\mathcal{S}\)：Agent 的完整 state space；
  • \(\mathcal{O}\)：policy LLM 实际能够观察到的信息；
  • \(\mathcal{A}\)：LLM 能采取的 action；
  • \(\mathcal{T}\)：状态转移；
  • \(\mathcal{R}\)：reward function。

这里有一个非常关键的定义：

在 Agent 层面，一次完整的 LLM response 被视为一个 action。

假设第 \(t\) 次 LLM 调用输出：

\[\mathrm{output}_t = (y_{t,1},y_{t,2},\ldots,y_{t,N_t}) \]

虽然模型内部仍然是一个 token 一个 token 地生成，但 Agent 层面把整段 output 看作：

\[a_t \in \mathcal{A} \]

执行这个 action 后：

state_t
   ↓
LLM 看到 input_t
   ↓
生成 output_t
   ↓
Agent / Tool / Environment 继续运行
   ↓
state_{t+1}

如果当前 action 获得 reward \(r_t\)，整个 episode 的 return 为：

\[R = \sum_{t=1}^{T} r_t \]

优化目标自然就是让 policy 获得更大的 return。

这里实际上形成了两个不同的粒度：

Agent 层：
一次 LLM call = 一个 action

LLM 层：
一个 action 内部仍然由很多 token 构成

这个双层结构正是后面 LightningRL 被称为 hierarchical RL 的原因。

3.2.1 从复杂 Agent execution 中抽取真正需要训练的数据

对于 policy LLM \(\pi_\theta\)，Agent Lightning 从完整执行记录中提取：

\[\mathrm{execution}^{RL}(x,k) = \left\{ \left( \mathrm{input}^{x,k}_t, \mathrm{output}^{x,k}_t, r^{x,k}_t \right) \right\}_{t=1}^{T} \]

并且：

\[\mathrm{output}^{x,k}_t = \pi_\theta \left( \mathrm{input}^{x,k}_t \right) \]

也就是说，训练框架最终真正看到的是：

Transition 1:
(input_1, output_1, reward_1)

Transition 2:
(input_2, output_2, reward_2)

Transition 3:
(input_3, output_3, reward_3)
...

它并不需要知道：

input_2 为什么长这样？
之前调用了什么工具？
Agent 为什么进入这条分支？
这个 prompt 是哪个 template 拼出来的？
中间经过了哪个 Python function？

因为这些复杂逻辑已经由 Agent 本身执行完了。

RL trainer 只关心：

模型当时看到了什么，然后生成了什么。

这就是所谓 Agent execution 与 RL training 的解耦。

3.2.2 为什么 input 不能简单理解成“历史对话”？

论文特别强调：

每次 LLM 调用的 input 可以由 Agent 任意构造。

例如：

  • 完整 conversation history；
  • 之前步骤的摘要；
  • 检索文档；
  • 当前 tool result；
  • structured prompt；
  • 当前 Agent role；
  • template 动态生成的 instruction。

因此 Agent Lightning 不要求：

input_t =
input_{t-1} + output_{t-1} + observation

这种固定形式。

Agent 完全可以把过去的信息压缩、重组甚至重新组织成新的 prompt。

这也是它与“把所有 turn 拼成长序列”的方法之间非常本质的区别。

3.2.3 对 multi-agent 的支持

Agent Lightning 还区分了两种情况。

一个 LLM 扮演多个 Agent

例如 Text-to-SQL 系统里面：

SQL Writer
Checker
Rewriter

表面上是三个 Agent，但实际上都调用同一个 LLM，只是 prompt 不同。

Agent Lightning 可以根据 transition 选择：

训练 Writer
训练 Rewriter
不训练 Checker

不需要对整条 trajectory 做复杂 mask。

多个不同的 LLM

如果不同 Agent 使用不同参数的 LLM，则情况更复杂。

论文指出，一种简单方案是：

把每个 LLM 看成独立 MDP，分别优化。

但这会忽略多个 policy 之间的相互依赖。

更严格的方法可能需要：

  • Multi-Agent Reinforcement Learning；
  • game theory；
  • multi-policy coordination。

本文并没有解决这一问题。

因此论文所谓支持 multi-agent，并不意味着它已经解决了任意 multi-LLM 联合强化学习。

3.3 LightningRL：把 Agent RL 转换成现成的单轮 LLM RL

接下来是论文的核心算法 LightningRL。

理解 LightningRL 最简单的方法，是先看普通 GRPO 在做什么。

对于一个普通单轮问题：

Question x
   ↓
LLM
   ↓
Response
   ↓
Reward

LLM 的 response：

\[(y_1,y_2,\ldots,y_N) \]

最终训练仍然作用到每个 token。

论文用一个简化的 token-level loss 表示：

\[\mathcal{L}(\theta) = - \mathbb{E} \left[ \sum_{j=1}^{N} \log \pi_\theta (y_j \mid x,y_{<j}) \cdot A_j \right] \]

其中 \(A_j\) 是 token 对应的 advantage。

不同 RL 算法最大的区别之一，就是 advantage 怎么得到。

例如：

  • PPO 使用 value function / critic；
  • GRPO 使用同一问题多个 response 的 group reward 统计；
  • REINFORCE++ 可以使用 batch reward baseline。

问题来了：

一个 Agent episode 包含很多次 LLM call，怎么把 episode-level reward 交给这些只会训练“一次 response”的算法？

LightningRL 的答案是：

先处理 LLM call 之间的 credit assignment，再把每一个 LLM call 当成普通单轮 RL 样本训练。

3.3.1 LightningRL 的两层结构

LightningRL 可以理解成两个层次。

第一层：

整个 Agent episode
        ↓
episode return R
        ↓
Credit Assignment
        ↓
分配到不同 LLM action

第二层：

某一个 LLM action
        ↓
对应的一整段 response
        ↓
GRPO / PPO / REINFORCE++
        ↓
token-level optimization

所以这里的 hierarchical RL 并不是说作者重新设计了一整套复杂的 option framework。

它的核心实际上是：

在 Agent action 与 token action 两个粒度之间增加一层 credit assignment。

image

【Figure 3（Single-call GRPO、传统 multi-turn GRPO 与 LightningRL 的对比，重点展示 trajectory 被拆成多个 transition 后分别进行 credit assignment）】

3.3.2 本文的 Credit Assignment 其实非常简单

这一点非常重要。

理论上，假设一个 Agent 做了：

Action 1：生成搜索 query
Action 2：判断搜索结果
Action 3：再次生成 query
Action 4：生成最终答案

最后任务成功：

R = 1

真正困难的问题显然是：

这四个 action 分别贡献了多少？

例如可能：

Action 1 很好
Action 2 一般
Action 3 非常关键
Action 4 正确

理想情况下，应该进行细粒度 credit assignment。

但是 Agent Lightning 当前实现没有解决这个复杂问题。

论文采用的是非常简单的策略：

一个 episode 中所有 action 都获得相同的 value，并且都等于最终 return \(R\)。

也就是说，如果最终：

R = 1

那么这一 episode 中的各次 LLM call 都按照成功样本处理。

如果：

R = 0

则这些 action 都得到失败的反馈。

作者把更高级的 credit assignment，例如：

  • heuristic；
  • learned credit model；
  • high-level value function；

留作未来工作。

因此 LightningRL 真正的创新重点并不是“发明了一种特别强的 credit assignment 算法”，而是：

定义了一层 credit-assignment interface，使复杂 Agent episode 可以被拆成若干普通 LLM transition，之后直接复用现有 RL 算法。

3.3.3 GRPO 怎么接进来？

假设同一个任务 \(x\) 被执行多次：

Execution 1
Execution 2
Execution 3
...

由于 LLM sampling 和 Agent 动态行为不同，每次 execution 可能产生不同轨迹。

Agent Lightning 首先把每条 execution 拆成 transition。

例如：

Execution 1:
  transition 1
  transition 2

Execution 2:
  transition 1
  transition 2
  transition 3

Execution 3:
  transition 1
  transition 2

然后按照 task \(x\) 对相关样本进行 grouping，用于 GRPO 的 group statistics / advantage estimation。

这样底层 GRPO 本身不需要理解：

这是一个 LangChain Agent
这是第三次 tool call
这是 multi-agent workflow

它仍然只处理类似：

prompt
response
reward

的样本。

因此 Agent Lightning 更像是在复杂 Agent 和已有 RL optimizer 之间加了一层适配器：

Complex Agent Trajectory
          ↓
Unified Data Interface
          ↓
Credit Assignment
          ↓
Single-call transitions
          ↓
GRPO / PPO / REINFORCE++

3.3.4 为什么 transition 比“拼成长序列 + mask”更适合 Agent？

论文总结了几个优势。

第一，Context 可以自由构造

每个 transition 的 input 就是 Agent 当时真正传给 LLM 的 input。

它可以是：

  • 原始历史；
  • summary；
  • structured prompt；
  • 动态 instruction；
  • 当前角色描述。

训练侧不需要重建这些 context。

第二，不需要把整个 trajectory 拼起来

传统方法可能形成：

turn1 + observation1 + turn2 + observation2 + ...

Agent Lightning 则分别保存：

transition_1
transition_2
transition_3

因此长 Agent trajectory 不必变成一条极长 sequence。

第三，不需要复杂 masking

传统 multi-turn RL 需要区分：

哪些 token 是 LLM 输出
哪些 token 是 tool observation
哪些 token 是 environment
哪些位置需要 loss

LightningRL 每个训练 transition 本身就是：

input → output

因此天然知道：

input 不优化
output 是 policy generation

不需要额外构造复杂 mask。

第四，可以选择性训练 Agent 中某些角色

例如：

Writer    → train
Checker   → freeze
Rewriter  → train

只把 Writer 和 Rewriter 对应的 transitions 送给 optimizer 即可。

不需要把所有角色的 token 拼在一起，再设计角色级 mask。

3.4 Training-Agent Disaggregation：真正实现“任意 Agent”

到这里，前面的内容解决的是：

Agent 数据应该怎么表示。

但还有一个工程问题：

一个已经使用 LangChain、AutoGen 等框架写好的 Agent，怎么真的连接到 verl 之类的 RL trainer？

Agent Lightning 给出的系统答案叫：

Training-Agent Disaggregation，训练—Agent 解耦架构。

image

【Figure 4（Training-Agent Disaggregation：左侧为 RL Framework / Trainer / LLM Engine，右侧为任意 Agent framework，中间由 Agent Lightning Server 与 Client 连接）】

传统 RL system 通常同时负责：

Trainer
+
Rollout

对于普通数学题：

rollout = 给 prompt 调一次模型

没有问题。

但是 Agentic RL 的 rollout 实际变成：

运行整个 Agent

这意味着 rollout 中可能出现：

  • native code；
  • tools；
  • databases；
  • APIs；
  • MCP；
  • LangChain；
  • AutoGen；
  • OpenAI Agents SDK；
  • arbitrary Python dependencies。

如果强行把这些全部塞进 RL training framework，系统就会越来越复杂。

Agent Lightning 因此把二者拆开：

RL Training Side
      ↕
Agent Lightning
      ↕
Agent Runtime

3.4.1 Lightning Server

Server 位于训练侧。

它负责：

  • 管理训练过程；
  • 管理任务；
  • 收集数据；
  • 与 RL framework 对接；
  • 管理更新后的 policy model；
  • 向 Agent 暴露 OpenAI-like API。

换句话说，Agent 不直接关心：

模型是不是正在用 verl 训练
当前第几个 training step
参数怎么更新
GPU 怎么分配

它只看到一个类似普通 LLM API 的 endpoint。

3.4.2 Lightning Client

Client 位于 Agent 侧。

主要负责：

  • 运行 Agent；
  • 接收 server 分配的 task；
  • 收集 execution traces；
  • 计算或收集 reward；
  • 把执行数据发回 server。

于是完整训练循环变成：

Server 选择一批 task
        ↓
发送给 Client
        ↓
Client 运行原来的 Agent
        ↓
Agent 调用 Server 暴露的 LLM API
        ↓
产生 execution trace
        ↓
得到 reward
        ↓
Client 回传数据
        ↓
Server 转换成 RL transitions
        ↓
Trainer 更新模型
        ↓
新的模型继续提供 API
        ↓
下一轮 Agent rollout

因此：

Agent 只负责正常运行，Trainer 只负责正常训练。

两边都不需要深入理解另一边内部的实现。

论文将其称为：

  • Agent-Agnostic Training
  • Trainer-Agnostic Agents

3.4.3 为什么论文敢说“几乎 ZERO code modification”？

其中一个关键设计就是 observability。

Agent Lightning 使用类似 OpenTelemetry 的 tracing 机制记录：

  • LLM calls；
  • execution traces；
  • environment interactions。

因此不需要开发者手动在 Agent 的每一个 function 中写：

log input
log output
save trajectory
report reward

对于不兼容 OpenTelemetry 的 Agent，Agent Lightning 还在 OpenAI-like API endpoint 中提供了基础 tracing 机制。

因为 Agent 原本就需要调用 LLM API，所以可以在 API 这一层截获大量训练所需要的数据。

3.4.4 Agent Runtime 的其他设计

论文还介绍了几个偏工程层面的功能。

Data Parallelism

RL rollout 往往需要同时运行大量 Agent instance。

Agent Lightning Client 支持两级并行：

单机：
一个 Client → 多个 worker → 多个 Agent

多机：
多个 Client → 分布式运行 Agent

Error Handling

Agentic RL 中失败情况比普通 inference 更多。

例如：

  • Agent crash；
  • 网络错误；
  • Tool 长时间无响应；
  • LLM 输出格式错误；
  • RL exploration 产生异常行为。

Agent Lightning 可以：

  • 捕获失败；
  • retry task；
  • 把任务重新分配给其他 Agent instance；
  • 保存日志。

避免单个 Agent execution 把整个训练过程卡住。

3.4.5 Automatic Intermediate Rewarding（AIR）

Agent RL 的另一个经典问题是 sparse reward。

很多任务只有最后：

成功 = 1
失败 = 0

但中间可能发生了很多有意义的行为。

Agent Lightning 提出 AIR：

Automatic Intermediate Rewarding

其核心思想是：

利用系统运行过程中本来就能够观察到的 monitoring signal，自动构造 intermediate reward。

例如：

Tool call 是否成功
API 是否返回合法结果
某个步骤是否正确完成

这些系统信号可以转换成中间 reward。

这样不一定需要人工逐步标注每一个 Agent action。

不过论文在这一版本中主要强调 AIR 的机制和接口，并没有把它发展成一套复杂的新 reward-learning 算法。

4. 实验

论文并没有只在一个 Agent framework 上实验。

作者刻意选择了三个任务，并分别使用三个不同的 Agent framework：

任务 Text-to-SQL Open-domain QA Math QA
Agent Framework LangChain OpenAI Agents SDK AutoGen
Dataset Spider MuSiQue Calc-X
Tool SQL Executor Wikipedia Retriever Calculator
Agent 数量 3 1 1
被优化的 Agent 数量 2 1 1
Backbone Llama-3.2-3B-Instruct Llama-3.2-3B-Instruct Llama-3.2-3B-Instruct

这三个实验分别对应三种场景：

multi-agent + code/tool
RAG + iterative retrieval
tool-use + mathematical reasoning

它们主要用于验证：

Agent Lightning 是否真的能够跨不同 Agent framework 和 workflow 完成训练。

4.1 Text-to-SQL：LangChain + Multi-Agent

第一个实验使用 Spider。

Agent workflow 包含三个角色。

SQL Writer

负责根据问题生成 SQL。

Question
   ↓
SQL Writer
   ↓
SQL Query

SQL Executor

执行 SQL。

如果 SQL 有问题，会返回错误信息。

Checker

判断：

  • SQL 是否正确；
  • 查询结果是否有效；
  • 当前信息是否足够回答问题。

然后决定：

直接回答
或
重新生成 SQL

Rewriter

如果需要修改 SQL，则根据 Checker feedback 重写。

如果无需继续修改，它也负责根据检索结果回答最终问题。

完整流程近似：

Question
   ↓
SQL Writer
   ↓
SQL Executor
   ↓
Checker
   ↓
是否需要 rewrite？
   ├── 是 → Rewriter → SQL Executor → ...
   └── 否 → 生成最终答案

有意思的是：

这三个“Agent role”实际上由同一个 Llama-3.2-3B-Instruct 扮演，只是使用不同 prompt。

训练时作者没有优化所有角色，而是只优化：

  • SQL Writer；
  • Rewriter。

Checker 不参与更新。

这正好展示了 Agent Lightning 的 transition-based 设计：

只选择目标角色对应的 LLM transitions 进入训练即可。

reward 根据最终答案是否正确决定。

实验中的 train reward 和 test reward 都随着训练明显提升。

作者据此说明 Agent Lightning 可以处理：

  • multi-step decision；
  • code generation；
  • tool interaction；
  • selective multi-agent optimization。

4.2 RAG：OpenAI Agents SDK

第二个实验使用 MuSiQue。

MuSiQue 是一个 multi-hop QA benchmark。

Agent 需要：

  1. 根据问题生成检索 query；
  2. 从 Wikipedia 中检索文档；
  3. 根据结果决定继续修改 query，还是直接回答；
  4. 最终生成答案。

检索数据库使用整个 Wikipedia，包含约 2100 万篇文档。

Retriever 使用 BGE embedding 和 cosine similarity。

与前一个实验不同，这里没有使用多个 Agent role。

一个 LLM 负责整个 workflow。

训练 reward 由两部分组成。

第一部分是 correctness：

  • 预测答案与 gold answer 的 word-level F1。

第二部分是 format reward：

模型是否正确生成：

<think>...</think>
<query>...</query>
<answer>...</answer>

等规定格式。

总 reward 为：

\[R = 0.9R_{\mathrm{correctness}} + 0.1R_{\mathrm{format}} \]

实验中 train reward 与 test reward 都随着训练上升。

这一实验主要说明：

Agent Lightning 不只能够训练固定工具链，也可以处理 query 动态变化、自由文本检索以及多轮 RAG workflow。

4.3 Math QA：AutoGen + Calculator

第三个任务使用 Calc-X。

Calc-X 中的问题要求模型同时具备：

  • 数学推理；
  • calculator tool 调用能力。

Agent 使用 AutoGen 实现。

一个 LLM 负责：

理解问题
   ↓
决定是否调用 Calculator
   ↓
生成 Tool Call
   ↓
读取计算结果
   ↓
继续推理
   ↓
生成最终答案

reward 由最终答案是否正确决定。

实验结果同样显示训练过程中 performance 持续提升。

这一实验用于验证 Agent Lightning 对：

  • tool calling；
  • external function；
  • reasoning + tool integration；

场景的支持。

4.4 这些实验实际验证了什么？

这里需要区分两个不同的问题。

论文的实验主要验证的是：

Agent Lightning 能不能把不同框架、不同 workflow 的 Agent 接入同一套 RL training paradigm，并让它们稳定获得训练收益。

因此实验中特意覆盖了：

LangChain
OpenAI Agents SDK
AutoGen

以及：

multi-agent
RAG
tool-use

论文主要通过训练曲线展示 Agent performance 随 RL training 稳定提高。

但这一版本论文并没有给出大规模的：

  • 与其他 Agentic RL framework 的最终指标横向比较；
  • 多种 credit assignment 方法之间的系统消融；
  • masking-based 与 transition-based 方法的同条件性能对比；
  • 不同 RL optimizer 的完整 benchmark。

因此这些实验直接支持的结论主要是：

这套 abstraction 和系统确实可以跨多种 Agent 结构工作，并能够稳定完成 RL optimization。

而不是证明：

LightningRL 在最终任务指标上一定全面优于其他 RL 算法。

5. Agent Lightning 和传统 Multi-turn RL 最大的区别

论文 Discussion 中花了相当多篇幅讨论这个问题。

可以把两种思路概括成：

传统方案

Agent trajectory
      ↓
把所有 turn 拼接
      ↓
构造一条超长 sequence
      ↓
mask 非 policy token
      ↓
RL training

Agent Lightning

Agent trajectory
      ↓
抽取 policy LLM calls
      ↓
拆成 transitions
      ↓
Credit Assignment
      ↓
每个 transition 作为单轮 RL sample
      ↓
PPO / GRPO / REINFORCE++

两者的区别可以总结如下。

维度 Sequence Concatenation + Mask Agent Lightning
基本训练单元 整条 multi-turn trajectory 单次 LLM transition
Agent history 拼入长 sequence 由 Agent 自己构造当前 input
Tool output 拼入 trajectory 作为 Agent state / context 的一部分
Loss 控制 依赖 mask transition 本身确定 policy output
Agent workflow 更适合顺序式流程 支持动态 workflow
Multi-agent 需要复杂 token mask 可以直接选择目标 Agent transitions
Context 长度 随 turn 累积 每个 transition 独立
Agent 与 trainer 较紧耦合 明确解耦
RL algorithm 通常需要适配 multi-turn sequence 可以复用单轮 PPO / GRPO / REINFORCE++

因此 Agent Lightning 真正试图重新定义的是：

Agentic RL 的训练数据应该以什么为基本单位。

它认为不应该把：

整个 Agent trajectory

强行看成一个超长 LLM response。

而应该把：

一次 policy LLM invocation

看成 Agent-level transition。

6. 为什么这套方法能够做到 Agent-agnostic？

现在可以把全文核心逻辑串起来。

假设用户写了一个非常复杂的 Agent：

LangChain
    ↓
Planner
    ↓
Search
    ↓
Python
    ↓
Retriever
    ↓
Agent A
    ↓
Agent B
    ↓
MCP
    ↓
Final Answer

Agent Lightning 并不试图让 RL trainer 理解这套代码。

它只需要观察：

LLM Call 1
input_1 → output_1

LLM Call 2
input_2 → output_2

LLM Call 3
input_3 → output_3

以及最终：

reward

复杂的：

工具调用
if / else
loop
Agent 调度
prompt template
context management
MCP communication

全部留在 Agent runtime 内部。

因此：

Agent Framework
        │
        │ 负责：
        │ workflow
        │ tools
        │ context
        │ environment
        ▼
LLM API Call
        │
        │ Agent Lightning 捕获：
        │ input
        │ output
        │ reward
        ▼
Transition
        │
        ▼
Credit Assignment
        │
        ▼
GRPO / PPO / REINFORCE++

这就是这篇论文所谓“完全解耦”的核心。

7. 当前方法的边界

论文的 Future Work 实际上也暴露了当前版本几个比较明确的边界。

7.1 Credit Assignment 仍然非常粗

目前：

episode 中所有 action 简单共享最终 return。

对于短 trajectory，这种方法可能已经足够工作。

但对于真正 long-horizon Agent：

Action 1
Action 2
Action 3
...
Action 50

最后失败，并不意味着前 49 个 action 都做错了。

反过来，最终成功也不意味着所有中间 action 都值得强化。

因此作者明确把：

  • long-horizon credit assignment；
  • learned value function；
  • 更精细的 hierarchical RL；

列为未来方向。

7.2 多个独立 LLM 的联合训练尚未解决

当前框架可以方便地选择不同 Agent role 进行训练。

但如果 Agent A 和 Agent B 分别使用不同参数的模型，而且两个 policy 强耦合，那么简单分别优化可能无法学到最优协作策略。

论文指出，这种情况未来可能需要 MARL 或 game-theoretic 方法。

7.3 RL 并不是唯一优化目标

作者认为 Unified Data Interface 不应该只能服务 RL。

它实际上描述的是：

Agent 中哪些组件被调用
输入是什么
输出是什么
效果怎么样

因此理论上还可以优化：

  • Prompt；
  • Tool；
  • Routing；
  • 其他 Agent component。

论文进一步提出 Component of Interest（CoI） 的概念：

指定 execution trace 中究竟哪些组件是需要被优化的对象。

例如 prompt template rendering 可以被看成一个 tool call。

那么 prompt optimizer 就可以把这个组件当作 CoI。

不过这些属于论文提出的扩展方向，本文主要实验仍然集中在 LLM 参数的 RL optimization。

7.4 系统效率仍有优化空间

作者还提出未来进一步拆分：

Trainer
Rollout / Inference Engine
Agent Workflow

从而解决 Agentic RL 中 rollout latency 很高的问题。

另外包括：

  • long-context acceleration；
  • environment / tool resource scheduling；
  • 更高效 serving；
  • 更复杂的 distributed infrastructure；

也都属于未来工作。

8. 如何理解 Agent Lightning 的核心贡献？

如果只看名字：

LightningRL

很容易以为这篇论文的重点是发明了一种新的 RL optimizer。

但从整篇论文来看，它真正重要的贡献其实可以分成三层。

第一层：数据抽象

把任意 Agent execution 抽象成：

state
call
reward

再从中抽取：

(input, output, reward)

形式的 transitions。

这是 Unified Data Interface。

第二层：算法适配

Agent episode 的 reward 不能直接送给单轮 LLM RL。

因此增加：

Episode Return
      ↓
Credit Assignment
      ↓
Agent-level Actions
      ↓
Single-turn RL
      ↓
Tokens

这一层就是 LightningRL。

当前 credit assignment 很简单，但接口被独立了出来。

第三层：系统解耦

即使数据格式定义好了，如果还要求开发者把 Agent 重新写进 verl / RL trainer，那么依然很难真正做到通用。

因此论文进一步设计：

Training-Agent Disaggregation

让：

RL trainer

和：

Agent runtime

分别独立运行，通过标准接口通信。

这才使：

LangChain
OpenAI Agents SDK
AutoGen
from scratch

等不同 Agent 可以进入同一套训练系统。

因此整篇论文可以压缩成一条逻辑链：

任意 Agent workflow
        ↓
统一记录 execution
        ↓
抽取 LLM transitions
        ↓
对 Agent actions 做 credit assignment
        ↓
转换成普通单轮 RL samples
        ↓
复用 PPO / GRPO / REINFORCE++
        ↓
更新后的模型重新提供给原 Agent

9. 总结

Agent Lightning 关注的是一个非常工程化、但对 Agentic RL 十分核心的问题：

如何把现实世界中已经存在的复杂 Agent，接入 LLM 强化学习？

以往很多 Agentic RL 系统倾向于：

重新在 RL framework 中实现 Agent rollout
+
把多轮交互拼成长 sequence
+
使用 mask 完成训练

Agent Lightning 则提出另一种路线：

不把整个 Agent trajectory 当成一个超长 response，而是把每一次 policy LLM invocation 当成 Agent-level transition。

具体来说，Agent Lightning 首先通过 Unified Data Interface 将不同 Agent 的执行统一表示为 state、component call 和 reward，并从中提取：

(input, output, reward)

形式的 LLM transitions。

随后通过 LightningRL 建立两个粒度：

Agent level：
一次完整 LLM response = 一个 action

Token level：
response 内部每个 token 继续由 PPO / GRPO 等算法优化

中间的 Credit Assignment 模块负责把 episode return 分配给不同 Agent actions。

不过本文当前实现采用的是非常简单的方案：

episode 内各个 LLM action 共享相同的最终 return。

在此基础上，每个 transition 都可以重新变成标准的：

prompt → response → reward

训练样本，从而直接复用 PPO、GRPO、REINFORCE++ 等已有单轮 LLM RL 方法。

最后，Training-Agent Disaggregation 从系统层进一步把：

Agent execution

和：

RL training

拆开。

Agent 可以继续使用 LangChain、AutoGen、OpenAI Agents SDK 或自定义代码运行，而训练侧只负责模型 inference 和 parameter update。

因此 Agent Lightning 的核心价值并不是单独提出一个新的 RL objective，而是建立了一层：

任意 Agent
   ↕
统一 Agent RL 数据接口
   ↕
现有 LLM RL 算法

的通用中间层。

从这个角度看，这篇工作的核心问题可以浓缩成一句话：

不再要求 RL 系统理解 Agent，而是把任意 Agent 的真实执行过程转换成 RL 系统已经会处理的数据。

参考

  1. Xufang Luo, Yuge Zhang, Zhiyuan He, et al. Agent Lightning: Train ANY AI Agents with Reinforcement Learning. arXiv:2508.03680, 2025.
    https://arxiv.org/abs/2508.03680

  2. Agent Lightning GitHub Repository.
    https://github.com/microsoft/agent-lightning

  3. Microsoft Research — Agent Lightning.
    https://www.microsoft.com/en-us/research/project/agent-lightning/

posted @ 2026-10-22 20:50  YourF4u1t  阅读(25)  评论(0)    收藏  举报