Microsoft Research Asia 开源 Agent Lightning v1.0：3,500 行代码的真实 harness 智能体 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 智能体已从单一模型演变为由模型、工具和执行环境构成的复杂全栈系统。其能力越来越依赖于在模型之外协调它们的智能体框架。强化学习（RL）是一种让 AI 系统通过试错学习的方法，以对其行动的奖励和惩罚为指导。RL 可以让这些智能体变得更好，但大多数智能体 RL 系统要求开发者在训练框架内重新实现智能体。这成本高昂，而且意味着被训练的智能体并非最终部署的那个智能体。

为解决这一问题，微软亚洲研究院的研究人员提出了驾驭式智能体强化学习（Harnessed Agentic RL）训练范式，并开源了完全重建的 Agent Lightning v1.0 （在新标签页中打开） 。与原始版本相比，Agent Lightning v1.0 更强调保持轻量、与真实框架集成，以及提供完整、可复现的智能体 RL 训练流水线。

Agent Lightning v1.0 围绕驾驭式智能体强化学习进行了重建，主要改进包括：

· 轻量 ：整个框架约 3,500 行代码。Agent Lightning v1.0 在一个足够小巧、清晰、易于理解、修改和扩展的代码库中实现了完整的驾驭式智能体强化学习系统。

· 在真实智能体框架上训练 ：智能体通过 Agent Lightning v1.0 中的大语言模型（LLM）代理访问模型，现有框架代码保持不变。

· 原生 Kubernetes 支持 ：智能体直接以 Kubernetes 作业的形式运行，无需外部商业沙箱服务。自管理集群和本地基础设施均可支持大规模 rollout。

· 完整的编码智能体训练示例 ：一个基于 Qwen3.5-9B 构建的端到端流水线将 SWE-bench Verified 上的 Pass@1 从 41.8% 提升至 56.4%，绝对提升 14.6 个百分点，且仅使用了约 6,000 条训练样本。

传统智能体强化学习的局限

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

真实的 harness 已经超出了这一假设。mini-SWE-agent、OpenHands、OpenCode、Claude Code 和 Codex 等编码智能体各自带来自己的上下文管理、工具协议、执行逻辑和依赖，通用智能体系统也是如此。为训练重建一个 harness 成本高昂，而且重建后的智能体行为可能不再与部署的智能体一致。

Agent Lightning 走了一条不同的路。它在智能体与模型之间放置一个 LLM 代理。智能体照常运行：只需将原先调用模型 API 的端点指向 Agent Lightning，训练框架就能观察并记录其模型调用。在 v1.0 中，研究者更进一步，将这一范式正式定义为 Harnessed Agentic RL：部署时使用哪个智能体 harness，训练时就由哪个 harness 直接参与强化学习（图 1）。

使用真实 harness 训练中的四个挑战

Harnessed Agentic RL 与传统 agentic RL 的一个核心区别在于，环境交互循环由智能体 harness 处理，而非训练框架。训练系统只能观察到一系列 LLM 请求与响应对，因此一次 rollout 可能被拆分成数量不定的训练样本。这带来了四个关键挑战：

· 重新分词与样本合并 ：harness 以文本形式保存上下文，但 RL 训练需要 rollout 期间采样的 token ID。将文本再次经过 chat template 和 tokenizer 可能会改变 token 边界，因此相邻调用并不总能合并为一个样本。

· 优势计算 ：重新分词、子智能体和上下文摘要可能将一次 rollout 拆分成多个样本。直接在样本级别计算基线和优势，会导致产生更多样本的 rollout 被重复计数，从而改变 rollout 级别原有的统计关系。

· 损失归一化 ：按样本数平均损失会给产生更多样本的 rollout 更大权重。由于样本数往往只是 harness 行为的产物，损失归一化也必须避免受其扭曲。

· 训练后端调度 ：样本数量和长度只有在 harness 完成后才可知，而 GPU 数量和数据/张量并行配置通常是固定的。后端必须将可变的工作负载映射到固定的资源上。

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

在系统设计上，Agent Lightning v1.0 将简洁性作为首要原则。整个框架约 3,500 行代码，包含三个核心组件：API Gateway、Rollout Controller 和 Customized Trainer（图 2）。

API 网关存储 rollout、模型和事件，并充当兼容 OpenAI 的 LLM 代理。它将 harness 中的每次模型调用与其 rollout 关联起来，并记录训练所需的提示、响应和 log probabilities。rollout 控制器启动并管理 agent 执行，既可以作为本地进程，也可以作为标准 Kubernetes 作业，从而将 agent 执行与训练器分离。基于 verl 构建的定制训练器创建 rollout、等待其完成、收集样本，并通过样本适配器组装最终的训练样本。因此，对于现有的 agent harness，只需将模型端点指向 Agent Lightning 代理，通常就足以快速接入 RL 训练。

共置异步 RL

不同 agent 的 rollout 时间差异很大。同步 RL 会等待批次中最慢的 agent，导致 GPU 空闲，而完全异步 RL 虽然提高了利用率，但需要为 rollout 和训练分别设置 GPU 池。为此，Agent Lightning v1.0 引入了共置异步 RL，让 rollout 和模型更新共享同一组 GPU。

一旦系统收集到足够的 rollout，更新就会开始：API 网关暂停接受新请求，并等待已在进行的请求完成，更新完成后 rollout 恢复。整个状态转换对外部 agent harness 是透明的。在实验中，这种方法相比同步 RL 实现了约 2 倍的端到端加速，同时使用的 GPU 比传统异步 RL 更少（图 3）。

在 Kubernetes 上运行 agent

收集足够的 rollout 意味着要同时运行许多 agent，这会消耗大量 CPU、内存和计算资源。其他 Harnessed Agentic RL 框架通常将这些 agent 托管在 Modal Sandbox 或 E2B 等商业沙箱服务上，成本会随规模迅速上升。相反，Agent Lightning v1.0 将它们作为标准 Kubernetes 作业运行，复用现有的自管理集群、云 Kubernetes 或本地基础设施（图 4）。现有计算资源得到更高效的利用，大规模 rollout 成本更低，整个流水线保持开源且可复现。

6,000 个训练样本，性能提升 14.6 个百分点

为了测试该方法，研究人员在 SWE-smith、mini-SWE-agent 和 Qwen3.5-9B 上构建了完整流水线，涵盖数据清洗、环境构建、reward-hacking 防护和 RL 训练。训练集包含约 6,000 个样本，无需大规模计算。仅 RL 训练就将 Qwen3.5-9B 在 SWE-bench Verified 上从 41.8% 提升到 56.4%，提高了 14.6 个百分点。

编码 agent 实验进一步证实了此前对两个挑战的分析：优势计算和损失归一化。与样本级处理相比，rollout 级优势结合 rollout 级归一化实现了更高的验证奖励，并在训练期间保持策略熵更稳定（图 5）。

技术报告

GitHub 项目

在新标签页中打开

文章 Agent Lightning v1.0：一个 3,500 行的轻量级智能体强化学习框架，用于通过真实测试框架训练智能体 首次出现在 Microsoft Research 。