Agent Lightning v1.0：用于训练智能体的轻量级强化学习框架

概览

• 基于真实环境代理的强化学习（Harnessed Agentic RL）：微软亚洲研究院推出了一种训练范式，其中部署时使用的同一套代理环境直接参与强化学习，无需在训练框架内重新实现代理。
• 设计轻量：Agent Lightning v1.0 仅用约 3,500 行代码即可提供完整的代理强化学习控制平面。
• 原生 Kubernetes 支持：代理作为标准的 Kubernetes 作业运行于自管集群、云 Kubernetes 或本地基础设施上，无需依赖付费的商业沙箱服务。
• 数据高效的训练配方：端到端的编码智能体管道使 Qwen3.5-9B 在 SWE-bench Verified 上的 Pass@1 指标从 41.8% 提升至 56.4%，提升了 14.6 个百分点，且仅使用了基于开源数据集的大约 6,000 个训练样本。

AI 智能体已从单一模型演变为由模型、工具和执行环境构建的复杂全栈系统。它们的能力越来越依赖于在模型外部协调它们的代理环境（agent harness）。强化学习（RL）是一种 AI 系统通过试错进行学习的方法，其行动受到奖励和惩罚的引导。RL 可以让这些智能体变得更好，但大多数代理 RL 系统要求开发人员在训练框架内重新实现代理。这不仅成本高昂，而且意味着被训练的代理与最终部署的代理并不完全一致。

为解决这一问题，微软亚洲研究院的研究人员引入了“基于真实环境代理的强化学习”（Harnessed Agentic RL）训练范式，并开源了全面重构的 Agent Lightning v1.0。与初代版本相比，Agent Lightning v1.0 更加强调保持轻量级、集成真实环境以及提供完整可复现的代理 RL 训练流水线。

Agent Lightning v1.0 围绕 Harnessed Agentic RL 进行了重构，主要改进包括：

• 轻量级：整个框架仅约 3,500 行代码。Agent Lightning v1.0 在一个足够小且清晰的代码库中实现了完整的 Harnessed Agentic RL 系统，便于理解、修改和扩展。
• 在真实代理环境上进行训练：在 Agent Lightning v1.0 中，代理通过大语言模型（LLM）代理网关访问模型，从而保持现有环境代码不变。
• 原生 Kubernetes 支持：代理直接作为 Kubernetes 作业运行，无需外部商业沙箱服务。无论是自管集群还是本地基础设施，均能支持大规模 rollout。
• 完整的编码智能体训练示例：基于 Qwen3.5-9B 构建的端到端流水线，仅使用大约 6,000 个训练样本，就将 SWE-bench Verified 上的 Pass@1 指标从 41.8% 提升至 56.4%，绝对提升幅度达 14.6 个百分点。

传统代理强化学习的局限

传统的代理强化学习假设训练框架拥有与环境交互的循环。在 ReAct 风格的循环中，模型生成动作，环境返回观察结果，观察结果被追加到上下文中，然后模型生成下一个动作，因此整个 rollout 映射为一段连续的 token 轨迹。早期的 RL 系统如 verl、AReaL 和 slime 都是以此方式构建的，这意味着要在 RL 框架内重建智能体的循环才能对其进行训练。

真实的环境已超越了这一假设。像 mini-SWE-agent、OpenHands、OpenCode、Claude Code 和 Codex 这样的编码智能体，以及通用智能体系统，都自带各自的上下文管理、工具协议、执行逻辑和依赖项。为训练目的而重建其中一个不仅昂贵，而且重建后的智能体可能不再表现出与部署时相同的行为。

Agent Lightning 采取了不同的路径。它在智能体和模型之间放置了一个 LLM 代理。智能体继续像以前一样运行：只需将之前调用模型 API 的端点指向 Agent Lightning，训练框架即可观察并记录其模型调用。在 v1.0 版本中，研究人员进一步正式定义了这种范式为“受控具身强化学习”（Harnessed Agentic RL）：部署时使用的任何智能体控制框架，都直接参与训练期间的强化学习过程（图 1）。

使用真实控制框架训练的四大挑战

受控具身强化学习与传统具身强化学习的核心区别在于，环境交互循环由智能体控制框架处理，而非训练框架。训练系统只能观察到一系列 LLM 请求和响应对，因此单次 rollout（执行轨迹）可能被拆分为可变数量的训练样本。这带来了四个关键挑战：

• 重新分词与样本合并：控制框架以文本形式保持上下文，但 RL 训练需要 rollout 期间采样的 token ID。再次通过聊天模板和分词器传递文本可能会导致 token 边界偏移，因此相邻调用并不总能合并为一个样本。
• 优势计算：重新分词、子智能体和上下文摘要可能将一个 rollout 拆分为多个样本。直接在样本级别计算基线和优势会导致产生更多样本的 rollout 被重复计数，从而改变 rollout 级别的原始统计关系。
• 损失归一化：按样本数量平均损失会使产生更多样本的 rollout 获得更大的权重。由于样本数量往往是控制框架行为的产物，损失归一化也必须避免因此失真。
• 训练后端调度：样本数量和长度只有在控制框架完成后才已知，而 GPU 数量和数据/张量并行配置通常是固定的。后端必须将可变的工作负载映射到固定资源上。

用 3,500 行代码构建完整的智能体 RL 控制平面

在系统设计中，Agent Lightning v1.0 将简洁性作为首要原则。整个框架约 3,500 行代码，包含三个核心组件：API 网关、Rollout 控制器和定制训练器（图 2）。

API 网关存储 rollouts、模型和事件，并充当兼容 OpenAI 的 LLM 代理。它将来自控制框架的每次模型调用与其对应的 rollout 链接起来，并记录训练所需的提示词、响应和对数概率。Rollout 控制器启动和管理智能体执行，可以作为本地进程或标准的 Kubernetes 作业运行，使智能体执行与训练器分离。定制训练器基于 verl 构建，负责创建 rollouts，等待它们完成，收集样本，并通过样本适配器组装最终的训练样本。因此，对于现有的智能体控制框架，只需将模型端点指向 Agent Lightning 代理，通常就足以快速连接到 RL 训练。

共置异步 RL

不同智能体的 rollout 时间差异很大。同步 RL 会等待批次中最慢的智能体，导致 GPU 空闲；而完全异步 RL 虽然提高了利用率，但需要为 rollout 和训练分配独立的 GPU 池。为此，Agent Lightning v1.0 引入了“共置异步 RL”（Collocated Async RL），允许 rollout 和模型更新共享同一组 GPU。

一旦系统收集了足够的 rollouts，更新便开始：API 网关暂停接受新请求，等待正在进行的请求完成，并在更新完成后恢复 rollout。整个状态转换对外部智能体控制框架是透明的。实验表明，与传统同步 RL 相比，该方法实现了约 2 倍的端到端加速，且比传统的异步 RL 使用了更少的 GPU（图 3）。

在 Kubernetes 上运行智能体

收集足够的 rollout 意味着需要同时运行大量智能体，这会消耗大量的 CPU、内存和计算资源。其他采用真实环境（Harnessed）的智能体强化学习框架通常将这些智能体托管在 Modal Sandbox 或 E2B 等商业沙盒服务上，随着规模扩大，成本会迅速攀升。相比之下，Agent Lightning v1.0 将它们作为标准的 Kubernetes 作业运行，复用现有的自管集群、云 Kubernetes 或本地基础设施（图 4）。这样更高效地利用了现有计算资源，降低了大规模 rollout 的成本，并且整个管道保持开源和可复现。

6,000 个训练样本带来 14.6 点的性能提升

为了测试该方法，研究人员在 SWE-smith、mini-SWE-agent 和 Qwen3.5-9B 上构建了一个完整的管道，涵盖了数据清洗、环境构建、奖励作弊防护以及强化学习训练。训练集包含约 6,000 个样本，无需大规模计算资源。仅强化学习训练就将 Qwen3.5-9B 在 SWE-bench Verified 上的得分从 41.8% 提升至 56.4%，提升了 14.6 个百分点。

编码智能体实验进一步证实了之前对两个挑战的分析：优势估计（advantage calculation）和损失归一化（loss normalization）。与样本级处理相比，结合 rollout 级优势估计和 rollout 级归一化的方法实现了更高的验证奖励，并在训练过程中保持了更稳定的策略熵（图 5）。