微软亚研院把「线上在跑的 Agent」直接拉进了强化学习训练场
国庆假期刚过，微软亚洲研究院就丢出一个挺有意思的开源项目：Agent Lightning v1.0 正式放出，代码托管在 GitHub，采用 MIT 协议，目前仓库星标已经冲到 1.8 万往上。这件事值得写，不是因为它又多了一个强化学习框架，而是它解决了一个很多做 Agent 训练的人都被卡过的真问题——你想用强化学习把一个智能体训得更强，结果发现得先把人家的 Agent 整个重写一遍塞进训练框架里。
这次 v1.0 是彻底重构后的版本，官方把代码量压到了大约 3500 行，主打一个「轻」和「真」。它提出的核心范式叫 Harnessed Agentic RL，翻译过来就是「带真实 Harness 的 Agent 强化学习」。一句话讲清它的思路：你线上部署时用的是哪个 Agent 运行框架（Harness），训练时就直接让这个 Harness 进强化学习环路，而不是另起炉灶重新实现一遍。这一版由微软亚洲研究院联合复旦大学、浙江大学、爱丁堡大学的研究者共同完成，比起早期版本更强调轻量、真实的 Harness 集成以及完整可复现的训练流程。技术报告同步挂到了 arXiv（编号 2608.17528），微软研究院官网也发了介绍长文。
Harnessed Agentic RL：不用重写 Agent，只改一个模型端点
要理解它为什么省事，得先看传统做法有多别扭。像 ReAct 这类经典 Agent，模型生成动作、环境返回观察、观察拼回上下文、模型再生成下一步，整个过程天然是一条连续的 token 轨迹，所以早期 verl、AReaL、slime 这些系统都假设「训练框架自己掌握环境和 Agent 循环」。结果就是：你想训一个 Agent，得把它的循环原样重写进强化学习框架。可现实里的 Agent Harness——不管是写代码的 mini-SWE-agent、OpenHands、OpenCode、Claude Code、Codex，还是通用 Agent 系统——都有自己的上下文管理、工具协议、执行逻辑和依赖。为训练重写一套，工程成本高不说，训出来的执行方式还可能跟真实部署对不上。
Agent Lightning 的解法很取巧：在 Agent 和模型之间插一个 OpenAI 兼容的代理（LLM Proxy）。Agent 照旧跑，你只把原本指向模型 API 的端点改指到这个代理，训练框架就能默默观察并记录每一次模型调用。官方已经验证能这么接进去的 Harness 一长串：mini-SWE-agent、OpenHands、OpenCode、Claude Code、Codex，还有 LangChain、AutoGen、OpenAI Agents SDK。等于说，你的生产环境在用什么，训练环境就能用什么，工具、上下文、控制流、执行环境全留在环内，一行业务代码都不用改。
3500 行代码搭起的控制平面：三件套各管一摊
光说范式有点虚，落到工程上 Agent Lightning v1.0 把系统拆成三个轻量组件，合计大约 3500 行代码。第一个是 API Gateway，负责存 rollout、模型和事件，对外提供兼容 OpenAI 的代理服务；Agent 每调一次模型，这次调用就自动关联到对应的 rollout，并把训练要用的提示词、回复和对数概率都记下来。第二个是 Rollout Controller，专门负责拉起和管理 Agent 执行，既能跑本地进程，也能直接把 Agent 当成一个标准 Kubernetes 任务扔上去跑，从而把 Agent 执行和强化学习训练器彻底解耦。第三个是 Customized Trainer，基于 verl 实现，负责建 rollout、等执行完、收样本，再通过样本适配器构造出最终的强化学习训练样本。
把已有 Harness 接进来，通常真的就只是把模型端点指到 Agent Lightning 的 Proxy 这一步。不过「让真实 Agent 进训练」没有嘴上这么轻松，论文里专门点了四个坑：上下文重新分词与样本合并、优势值计算、损失归一化，以及训练资源调度。因为环境循环由 Harness 管，一个 rollout 会被拆成数量不固定的训练样本，相邻调用未必能安全合并成同一样本；直接在样本层算基线和优势值，会让样本多的 rollout 被重复计入；按样本数平均损失，也会让产生更多样本的 rollout 拿到更大权重。Agent Lightning 把 rollout 层级当作重要的统计和优化单位，重新设计了样本构建、优势值、损失归一化和调度，才把这些扭曲抹平。
Collocated Async RL：让 rollout 和训练抢同一块 GPU
Agent 工作负载还有个烦人特性：rollout 时间高度不均匀。同步强化学习必须等一个批次里最慢的那个 Agent 跑完，大量 GPU 就这么空转；完全异步强化学习虽然利用率高，却通常要分别养一个 rollout GPU 池和一个训练 GPU 池，硬件开销直接翻倍。Agent Lightning v1.0 提了个叫 Collocated Async RL（共位置异步强化学习）的方案，让 rollout 和模型更新共享同一组 GPU：攒够一批 rollout 就开始更新，这时 API Gateway 暂停接新请求、等手里正在跑的请求结束，更新完再恢复 rollout，整个状态切换对外部 Harness 完全透明。
实测下来，这套方案相比同步强化学习拿到了大约 2 倍的端到端加速，同时又比传统异步强化学习用更少的 GPU。对想自己搭训练流水线的团队来说，这种「同一张卡既要采数据又要更新参数」的思路，比单纯堆机器要划算得多，也更符合中小团队的实际预算。
原生 Kubernetes：告别 Modal、E2B 这些按量付费的沙盒
强化学习训练阶段为了攒够 rollout，往往要并发跑成百上千个 Agent，Agent 执行本身就会吃掉大量 CPU、内存和计算。现有的某些 Harnessed Agentic RL 框架习惯依赖 Modal Sandbox、E2B 这类商业沙盒来承载这些 Agent，用起来方便，可一旦 rollout 规模上去，外部沙盒的调用账单也跟着飙升。Agent Lightning v1.0 选择原生支持 Kubernetes，直接把 Agent 作为标准 Kubernetes 任务运行，复用你已有的自建集群、云上 K8s 或本地基础设施，不依赖任何外部商业沙盒。好处很实在：既把已有算力榨干，又把从 Agent 执行到强化学习训练的整条链路保持完全开源、可控、可复现，大规模 rollout 的额外成本基本压到了零。
6000 条样本换来 14.6 个百分点：SWE-bench 实测
光讲设计不够服人，官方给的端到端实测最有说服力。他们基于 SWE-smith + mini-SWE-agent + Qwen3.5-9B 搭了一套完整的管线，涵盖数据清洗、环境构建、防 reward hacking 和强化学习训练，训练集只有大约 6000 条样本，而且没有依赖大规模算力。结果很漂亮：纯靠强化学习训练，Qwen3.5-9B 在 SWE-bench Verified 上的 Pass@1 从 41.8% 提升到 56.4%，绝对涨了 14.6 个百分点。顺带还验证了前面说的「优势值计算」和「损失归一化」两大坑——相比在样本层处理，用 rollout 层级的优势值和归一化，验证奖励更高，训练过程中的策略熵也更稳。
更夸张的是后来补的 MoE 例子：基于 Qwen3.5-35B-A3B，仅靠 1.8K 训练样本，SWE-bench Verified 就从 47.8% 提到 61.6%，涨了 13.8 个百分点。换句话说，这套范式对小样本、低成本把编程 Agent 训强特别友好，对预算有限又想自己炼 Agent 的团队，基本是把门槛打到了地板价。完整的数据清洗、防作弊和训练脚本也都开源了，社区可以直接复现。社区也已经开始跟进，腾讯优图基于修改分支验证了最高 128 张 GPU 的稳定收敛，还有把该范式用在狼人杀等游戏 Agent 上的案例，说明它不只能训编程 Agent，泛化到别的多轮任务同样站得住脚。
总结
Agent Lightning v1.0 盯着一个简单却关键的问题：既然未来的 Agent 跑在真实的 Harness 里，那训练时为什么不能直接用同一个 Harness？它用大约 3500 行代码给出了一个轻量、透明、可复现的回答，把工具调用、上下文、控制流和执行环境都留在训练环路里，还顺手用 Collocated Async RL 把 GPU 利用率和成本都优化了一档。对正在头疼「怎么把自家 Agent 训得更强」的开发者，这个项目值得 clone 下来跑一遍；对只想看热闹的普通读者，记住一句话就够了——以后给 AI Agent 做强化学习，可能真的不用再重写一遍 Agent 了。
相关阅读：
