8.0
热点
AI SCORE
开源项目2026-10-08 00:00
Agent Lightning：3500行轻量Agent强化学习框架
Microsoft Research#AI Agent#强化学习#Microsoft
Editor brief · 编辑速览
将现有AI Agent接入强化学习训练的轻量框架，无需重建即可改进Agent决策能力，代码仅3500行。
Harnessed Agentic RL：Microsoft Research Asia 引入了一种训练范式——部署时使用的同一套 Agent 执行环境直接参与强化学习过程，无需在训练框架内部重新实现 Agent。
轻量级设计：Agent Lightning v1.0 以大约 3500 行代码实现了一套完整的 Agent RL 控制平面。
原生 Kubernetes 支持：Agent 以标准 Kubernetes Job 的形式运行在自建集群、云 Kubernetes 或本地基础设施上，不依赖付费的商业沙箱服务。
数据高效的训练配方：一条端到端编码 Agent 流水线，基于约 6000 条训练样本（来自开源数据集），将 Qwen3.5-9B 在 SWE-bench Verified 上的 Pass@1 从 41.8% 提升到 56.4%，绝对提升 14.6 个百分点。
AI Agent 已从单一模型演变为由模型、工具和执行环境构建的复杂全栈系统。其能力越来越依赖于在模型外部协调它们的 Agent 执行环境（harness）。强化学习（RL）是一种 AI 系统通过试错进行学习的方法，由奖励和惩罚引导其行为。RL 可以提升这些 Agent 的表现，但大多数 Agent RL 系统要求开发者将 Agent 在训练框架内部重新实现。这代价高昂，也意味着被训练的 Agent 与最终部署的 Agent 并不完全相同。
为此，Microsoft Research Asia 的研究人员提出了 Harnessed Agentic RL 训练范式，并开源了完全重构的 Agent Lightning v1.0（在新标签页中打开）。与原始的 Agent Lightning 相比，v1.0 更强调保持轻量级、与真实执行环境集成，以及提供完整、可复现的 Agent RL 训练流水线。
Agent Lightning v1.0 围绕 Harnessed Agentic RL 重构，主要改进包括：
传统 Agentic RL 假设训练框架拥有与环境的交互循环。在 ReAct 风格的循环中，模型生成一个动作，环境返回一个观察结果，观察结果被追加到上下文中，模型再生成下一个动作——整个 Rollout 映射为一段连续的 token 轨迹。早期的 RL 系统（如 verl、AReaL、slime）都是这样构建的，这意味着训练一个 Agent 需要在 RL 框架内部重建其循环逻辑。
真实的执行环境已经超越了这一假设。编码 Agent（如 mini-SWE-agent、OpenHands、OpenCode、Claude Code、Codex）各有其上下文管理方式、工具协议、执行逻辑和依赖项，通用 Agent 系统亦然。为训练重建其中任何一个代价高昂，而且重建后的 Agent 可能不再与部署的 Agent 行为一致。
Agent Lightning 走了另一条路。它在 Agent 和模型之间放置了一个 LLM 代理。Agent 继续按以往方式运行：只需将之前调用模型 API 的端点指向 Agent Lightning，训练框架就能观察和记录其模型调用。在 v1.0 中，研究人员进一步将此范式正式定义为 Harnessed Agentic RL：部署时使用哪套 Agent 执行环境，训练时就是哪套执行环境直接参与强化学习（图 1）。
图 1. 传统 Agentic RL 与 Harnessed Agentic RL 的对比。在传统 Agentic RL 中，训练框架管理环境和 Agent 循环。在 Harnessed Agentic RL 中，执行环境管理两者。
Harnessed Agentic RL 与传统 Agentic RL 的核心区别在于：环境交互循环由 Agent 执行环境而非训练框架处理。训练系统只能观察一系列 LLM 请求和响应对，因此一次 Rollout 可能被拆分为数量不定的训练样本。这带来了四个关键挑战：
Retokenization 与样本合并：执行环境将上下文保存为文本，但 RL 训练需要 Rollout 期间采样的 token ID。将文本再次通过聊天模板和分词器可能改变 token 边界，因此相邻的调用并不总能合并为一个样本。
优势计算：Retokenization、子 Agent 和上下文摘要可能将一次 Rollout 拆分为多个样本。直接在样本级别计算基线和优势会导致产生更多样本的 Rollout 被重复计数，从而改变了原始的 Rollout 级别统计关系。
损失归一化：按样本数平均损失会给产生更多样本的 Rollout 赋予更大权重。由于样本数往往只是执行环境行为的产物，损失归一化也必须避免被其扭曲。
训练后端调度：样本数量和长度只有在执行环境完成后才能知晓，而 GPU 数量和数据/张量并行配置通常是固定的。后端必须将可变的工作负载映射到固定资源上。
在系统设计中，Agent Lightning v1.0 将简洁性作为首要原则。整个框架约 3500 行代码，包含三个核心组件：API Gateway、Rollout Controller 和 Customized Trainer（图 2）。
API Gateway 存储 Rollout、模型和事件，并作为兼容 OpenAI 的 LLM 代理提供服务。它将执行环境中每次模型调用关联到其 Rollout，并记录训练所需的提示词、响应和对数概率。Rollout Controller 启动和管理 Agent 执行，可以作为本地进程或标准 Kubernetes Job 运行，使 Agent 执行与训练器保持分离。Customized Trainer 基于 verl 构建，创建 Rollout、等待其完成、收集样本，并通过样本适配器组装最终训练样本。因此，对于现有的 Agent 执行环境，只需将模型端点指向 Agent Lightning 代理，通常就能快速接入 RL 训练。
图 2. Agent Lightning v1.0 系统架构，展示 API Gateway、Rollout Controller 和 Customized Trainer。
不同 Agent 的 Rollout 时间差异很大。同步 RL 等待批次中最慢的 Agent，造成 GPU 空闲；而完全异步 RL 提高了利用率，但需要独立的 GPU 池分别处理 Rollout 和训练。作为回应，Agent Lightning v1.0 引入了 Collocated Async RL，允许 Rollout 和模型更新共享同一组 GPU。
系统收集到足够的 Rollout 后，更新开始：API Gateway 暂停接受新请求，并等待已在进行中的请求完成，更新完成后 Rollout 恢复。整个状态转换对外部 Agent 执行环境透明。在实验中，该方法相比同步 RL 实现了约 2 倍的端到端加速，同时使用的 GPU 数量少于传统异步 RL（图 3）。
图 3. 同步 RL、异步 RL 和 Collocated Async RL 的对比。Collocated Async RL 在占用更少 GPU 的同时提高了利用率。
收集足够的 Rollout 意味着同时运行大量 Agent，这会消耗大量 CPU、内存和计算资源。其他 Harnessed Agentic RL 框架通常将这些 Agent 托管在商业沙箱服务（如 Modal Sandbox 或 E2B）上，成本随规模快速增长。Agent Lightning v1.0 则将它们作为标准 Kubernetes Job 运行，复用现有的自建集群、云 Kubernetes 或本地基础设施（图 4）。现有计算资源得到更高效利用，大规模 Rollout 成本更低，整个流水线保持开源和可复现。
图 4. Agent Lightning v1.0 中的 Rollout Controller 提供原生 Kubernetes 支持，直接将 Agent 作为标准 Kubernetes Job 运行。
为验证该方法，研究人员在 SWE-smith、mini-SWE-agent 和 Qwen3.5-9B 上构建了完整流水线，覆盖数据清洗、环境构建、奖励黑客防护和 RL 训练。训练集包含约 6000 条样本，无需大规模计算。仅 RL 训练就将 Qwen3.5-9B 在 SWE-bench Verified 上的表现从 41.8% 提升到 56.4%，提升 14.6 个百分点。
编码 Agent 实验进一步证实了此前对两个挑战的分析：优势计算和损失归一化。与样本级别处理相比，Rollout 级别优势结合 Rollout 级别归一化实现了更高的验证奖励，并在训练过程中保持了更稳定的策略熵（图 5）。
图 5. Qwen3.5-9B 在 SWE-smith 验证集上的通过率和策略熵。
