Microsoft Research Asia 发布 Agent Lightning v1.0：3,500 行代码的真实 harness 智能体 RL 训练框架

System architecture diagram. On the left, agents with harnesses — mini-SWE-agent, OpenHands, and OpenClaw — run on a Kubernetes cluster. They connect to three components: an API Gateway containing a Rollout API and an LLM API Proxy, a Rollout Controller containing a local reconciler and a Kubernetes reconciler, and a Customized Trainer containing a sample adapter and monitoring. These connect in turn to an inference engine and a training engine holding the model.

一览

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

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

为解决这一问题，微软亚洲研究院的研究人员提出了 Harnessed Agentic RL 训练范式，并开源了完全重构的 Agent Lightning v1.0 (opens in new tab)。与原版 Agent Lightning 相比，v1.0 更加注重保持轻量化、与真实 harness 集成，以及提供完整、可复现的智能体 RL 训练流水线。

Agent Lightning v1.0 围绕 Harnessed Agentic RL 重新构建，具有以下关键改进：

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

传统智能体 RL 的局限

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

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

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

Figure 1: Side-by-side comparison of two training loops. In Agentic RL, the environment exchanges actions and observations with a tokenizer, which passes action and observation tokens to the policy model. In Harnessed Agentic RL, an agent harness handling context and orchestration sits between the environment and an OpenAI-like API, which exchanges input and output tokens with the policy model. — 图 1. 传统智能体 RL 与 Harnessed Agentic RL 的对比。在传统智能体 RL 中，训练框架管理环境和智能体循环。在 Harnessed Agentic RL 中，harness 同时管理两者。

用真实 harness 训练的四大挑战

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

重新分词与样本合并：harness 以文本形式保存上下文，但 RL 训练需要 rollout 期间采样得到的 token ID。将文本重新经过聊天模板和分词器处理可能导致 token 边界偏移，因此相邻调用并不总能合并为一个样本。
优势计算：重新分词、子智能体和上下文摘要可能把一次 rollout 拆分为多个样本。直接在样本层面计算基线和优势，会导致产生更多样本的 rollout 被重复计入，从而改变 rollout 层面原有的统计关系。
损失归一化：按样本数量平均损失会给产生更多样本的 rollout 更高的权重。由于样本数量往往只是 harness 行为的产物，损失归一化也必须避免因此被扭曲。
训练后端调度：样本数量和长度只有在 harness 结束后才知道，而 GPU 数量和数据/张量并行配置通常是固定的。后端必须将可变的工作负载映射到固定的资源上。

聚焦：系列活动

微软研究院论坛

欢迎加入我们，围绕通用 AI 时代的研究持续交流思想。可点播观看最新一期节目。

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

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

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

Figure 2: System architecture diagram. On the left, agents with harnesses — mini-SWE-agent, OpenHands, and OpenClaw — run on a Kubernetes cluster. They connect to three components: an API Gateway containing a Rollout API and an LLM API Proxy, a Rollout Controller containing a local reconciler and a Kubernetes reconciler, and a Customized Trainer containing a sample adapter and monitoring. These connect in turn to an inference engine and a training engine holding the model. — 图 2. Agent Lightning v1.0 系统架构，展示了 API 网关、rollout 控制器和定制化训练器。

共置异步 RL

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

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

Figure 3: Three GPU scheduling timelines. Synchronous RL uses four GPUs at low efficiency, with long idle gaps before a single update block. Collocated Async RL uses the same four GPUs at high efficiency, interleaving full and partial rollouts with update blocks. Asynchronous RL reaches high efficiency but requires eight GPUs. Bars are colored for full rollout, partial rollout, and update. — 图 3. 同步 RL、异步 RL 与共置异步 RL 的对比。共置异步 RL 在占用更少 GPU 的同时提高了利用率。

在 Kubernetes 上运行智能体

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

Figure 4: Flow diagram. An API Gateway holds three rollouts, two queueing and one running. The Rollout Controller polls the gateway and uses a Kubernetes reconciler to create jobs on a Kubernetes cluster, and a local reconciler to watch and list local processes. Status updates flow back to the gateway. — 图 4. Agent Lightning v1.0 中的 Rollout 控制器原生支持 Kubernetes，可直接将智能体作为标准 Kubernetes 作业运行。

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 个百分点。

编程智能体实验进一步印证了前文对两大挑战的分析：优势计算和损失归一化。与样本级处理相比，rollout 级优势计算结合 rollout 级归一化获得了更高的验证奖励，并在训练过程中保持策略熵更加稳定（图 5）。

Figure 5: Two line charts plotting 200 training steps. On the left, validation reward: rollout-level advantage combined with rollout-level normalization reaches the highest reward at about 0.37, above rollout-level advantage alone and sample-level advantage. On the right, policy entropy: rollout-level advantage alone climbs steeply to about 0.65, while the combined method stays lower and steadier. — 图 5. Qwen3.5-9B 在 SWE-smith 验证集上的通过率与策略熵。