正在加载，请稍候
微软 2026 年 8 月开源的 Agent Lightning v1.0 用约 3500 行代码改了一条默认路径：不再把智能体搬进训练框架重写，而是让线上运行外壳直接参与强化学习。本文拆三个可验证数字、三条接入判据和一条反面教训。
2026 年 8 月开源的 Agent Lightning v1.0 只有约 3500 行代码，却改了一条默认路径：线上跑的那套运行外壳不用改写一行，就能进强化学习训练循环。
先给一个可核实的时间锚。截至 2026 年 10 月 8 日，GitHub API 显示该仓库为 18,581 stars / 1,657 forks，语言 Python，MIT 许可，最后一次代码推送是 2026-09-29。仓库创建于 2025-06-18——v1.0 是一次彻底重构，v0.x 的旧实现被留在独立分支上。对正在做 AI Agent 训练框架选型的团队来说，这条时间线本身就说明：这个领域前一版的做法，不到一年就被推翻了。
过去 agentic RL 的默认做法是：挑一个训练框架，然后把智能体的行为逻辑在框架内部重新实现一遍——工具调用、上下文管理、多轮控制流、沙箱环境，全搬进去。这条路能跑通，但必然产生两套实现：一套在生产跑，一套在训练里跑，两者漂移速度完全不同。工具签名改一次、上下文压缩策略调一次、控制流加一个分支，训练侧就要跟着改一次；而且改错往往不报错，只会让奖励信号悄悄变味。
Agent Lightning v1.0 的技术报告（arXiv:2608.17528，2026 年 8 月 18 日提交）把这件事说得很直接：现代智能体跑在一层壳里，这层壳管理工具、上下文和控制流，因此它本身就是系统的关键组成部分。报告把这种范式称为 harnessed agentic RL——部署时用的那套壳直接参与模型后训练。它与传统路线的根本区别在于：环境交互循环归外壳所有，训练器只观察一串 LLM 请求-响应对。
代价没有消失，只是被挪到明面上。报告列出了这套范式必须正面解决的五项难题：retokenization（重新分词导致的漂移）、sample merging、advantage calculation、loss normalization、backend scheduling。它们在「重写一遍」的路径里会被掩盖，在「不重写」的路径里必须逐个解掉——这也是整个项目只用 3500 行就能讲清楚的原因。
接入方式很朴素。官方 Basics 文档用的说法是 Zero-code-change integration：现有智能体只需把 OpenAI 兼容的模型地址指向 Gateway 即可被纳入训练。系统拆成三个组件——API Gateway（存储执行记录、模型接口与事件，并提供 OpenAI 兼容代理）、Rollout Controller（把排队的请求变成真实运行，支持本地子进程与 Kubernetes Job 两种模式）、Customized Trainer（跑在 verl 之上，把网关采集到的请求转成训练样本）。报告还提到，这种用模型代理连接任意智能体与 RL 训练的解耦架构，后来被 verl Uni-Agent、AReaL 2.0、slime、Polar 等框架采纳。
官方给出的结果都能追溯到具体脚本和评测口径，这比数字本身更重要。
| 配置 | 训练样本 | SWE-bench Verified | 绝对增量 |
|---|---|---|---|
| Qwen3.5-9B，FSDP，端到端编码流水线 | 约 6,000 | 41.8% → 56.4% | +14.6pp |
| Qwen3.5-35B-A3B，MoE，4×B200 | 1,792（约 1.8K） | 47.8% → 61.6% | +13.8pp |
| 同上，继续训到 2,816 样本 | 2,816 | 61.6% → 60.6% | −1.0pp |
边界条件不能省。两组数字都使用官方评测脚本、覆盖全部 500 个实例；样本计数按每步 16 个折算；MoE 那条路径用 4×B200，actor 走 Megatron、推理侧走 vLLM，并启用 R3 路由重放——MoE 的 token 在推理与训练阶段可能选到不同专家，必须记录推理时的专家路由，让 Megatron 侧更新时重放同一批专家。4×B200 拓扑只是起点，官方明确要求 batch size 按可用内存自行调整。
真正值得管理者注意的是第三个数字。官方文档给了逐步曲线：
最优点在中段，再往下训反而掉了 1 个百分点。这说明 SWE-bench 微调的边际收益不单调，训练预算的分配方式（什么信号停止、什么时候收手）比总量更关键。任何把它讲成「样本越多越好」的说法，都跳过了官方自己贴出的这条曲线。
比数字更值得抄的是数据清洗与奖励作弊防护，这部分随流水线一起开源了。数据侧：原始 SWE-smith 数据集包含 128 个 Python 仓库的 59,136 条可执行任务，清洗依次删掉 18,033 条空 problem statement、1,265 条在仓库镜像里缺分支的记录、测试数超过 200 的昂贵用例；再用 Qwen3.5-9B 对每个候选跑 4 次做难度探测，删掉四次全对的（几乎没有学习信号），保留有对有错的约 5,000 条，补入 1,000 条四次全错的以避免训练集偏向简单题，最终得到约 6,000 条训练样本 + 400 条验证样本。
奖励侧：编码类智能体完全可以绕过解题直接拿到参考补丁——翻 Git 历史、用 curl/wget 下载上游源码、用 pip 装回原包，或借 urllib 之类的网络库。官方做了两层限制。一是仓库隔离：工作负载启动前，外层框架会切出任务分支并把 .git 移到可见 testbed 之外，凡涉及 Git、隐藏元数据、装包、下载文件、改动测试脚本的命令一律拦截。二是网络隔离：强烈建议加一条 Kubernetes network policy，拒绝相关 pod 的所有出站流量，只保留通往 AGL 网关的连接。最终奖励由隔离环境内的 FAIL_TO_PASS / PASS_TO_PASS 测试算出。文档说得很白：这些控制是训练设置的一部分，削弱它们会让模型拿回参考代码、污染奖励信号。
这是这套范式的定义性特征，也是判断一个框架能不能真接上你现有系统的第一道门。如果接入方案要求你重建工具层、把上下文管理搬到训练侧，那不论数字多好看，你都是在给第三套实现付维护费。v1.0 的做法是把执行 ID 编进代理地址的路径里，每次模型调用自动归属到正确的轮次；调用方只需把 base URL 指过来，照常请求 /chat/completions。
评估时可以把这条判据量化成一句可验证的话：接入后，生产外壳需要改动的代码行数是多少？答案是零，就值得继续评估；答案是「要抽一个适配层」，就先确认这个适配层将来由谁维护。关于这层壳在企业平台里的定位，《AI Agent 平台搭建：2026 年为什么 harness 比模型更重要》从 Nvidia 研究与 22 个前沿模型的作弊审计切入，讲的是工程侧护栏为什么决定交付质量；本文讲的是训练侧如何把同一层壳当作既有资产复用——一个回答「怎么把它做对」，一个回答「怎么把它用起来」。两篇论点不重叠，建议对照阅读。
v1.0 的原生 Kubernetes 支持，指的是把工作负载直接当成 Kubernetes Job 跑、不依赖外部沙箱服务。接入前先自查三件事：依赖能否打成仓库级镜像；并发上限与节点配额是否匹配；控制面与训练面能否分机部署。官方编码示例就是两台机器：一台 K8s 控制机负责连集群、准备镜像、跑 agl-controller 创建 Job；另一台 GPU 机跑 agl-server（即网关）与 verl 训练器。启动顺序固定为 server → controller → trainer，而且网关地址必须从控制机和集群里的 pod 都能访问——这一条在混合云或跨集群场景里最容易踩坑。本地最小验证路径只需单卡 A100，网关默认监听 8181 端口，Windows 上要走 WSL。
上游发布的是完整工作流与训练脚本，而不是一句「我们在某 benchmark 上提升了 X」。对企业而言，可复现意味着三件事：基座分数的口径固定（同一套评测脚本、同样的实例数）、数据清洗步骤可审计、奖励函数可读。三者都满足，结果才可能写进内部技术评审。反之，如果你只拿到最终分数，就无法判断提升来自模型、数据，还是评测脚本的放宽。
这个项目真正值得抄的不是数字，而是一条失败教训的反面：先把运行外壳的抽象做干净，再谈训练。
原因在于，这类系统里有几处「抽象不干净就会静默出错」的地方。第一处是事件模型。一次执行（rollout）是一个完整单元，状态在 QUEUING / RUNNING / SUCCEEDED / FAILED 之间流转；events 是 append-only 的，包含每次模型调用自动记录的 model_request、结束时由调用方上报的 reward、以及自定义诊断事件。注意一次执行不等于一个训练样本——GRPO 这类算法会从同一条输入派生多个独立试跑，好让训练器比较它们的奖励。如果外层没把「一次执行」建模清楚，奖励就会被挂到错误的粒度上，而这种错误在日志里通常只表现为「指标不涨」，很难反查。
第二处是样本合并的边界。训练器只在多次模型调用的 token 历史严格连续时才合并它们。这不是优化，是正确性条件：合并错了，advantage 就是在错误的序列上算的。第三处是异步训练的暂停与排空。长任务耗时差异极大，同步训练会被单个慢任务拖住整个更新步。v1.0 支持 collocated 异步采集：活跃的提示组数必须严格大于单步消费组数，经验起点是 2:1；权重更新前网关会暂停新的模型请求并等待在途请求结束。但异步会带来策略陈旧，官方建议开启 verl 的 rollout correction，用 token 级重要性采样、裁剪阈值取 2 来纠正。而且每个组必须完整保留——当并行采样数 n 取 4 时，四个同组样本要全部结束，这一组才能被优化器使用，否则 GRPO / RLOO 的组内统计会失真。
把这三处放在一起看，结论就出来了：如果你的外壳连「一次执行」的边界、「一次模型调用」的归因、「一次奖励」的粒度都说不清楚，那么上线强化学习训练之后，你调的每个超参都在偿还此前欠下的工程债——账单会以「训练不稳定」的形式出现，极难归因。还有一个容易被忽略的实践含义：这套采集模型天然要求完整的调用链日志。《AI Agent 事故取证：OpenAI 一批失准报告之后，日志要留到什么粒度才够复盘》讲的是越权事故之后靠日志定位注入点的取证粒度，本文讲的是同一批日志如何被复用为训练事件——一个面向事后追责，一个面向事后训练，可以互为前置条件。
它指承载智能体运行的那层壳：管工具调用、上下文窗口的组装与压缩、多轮控制流，以及执行环境（沙箱、镜像、超时）。编排框架更多指编排代码本身，而壳层是这套编排在真实环境里跑起来的完整支撑。v1.0 的核心论点就是：这层壳属于系统本身，训练时不该被丢掉或重写。
不必，这正是 v1.0 想证伪的默认假设。它通过一个 OpenAI 兼容代理把模型请求截流下来，训练器只看到请求-响应对，环境交互循环仍留在你自己的壳里。代价是 retokenization、样本合并、优势计算、损失归一化、后端调度这几项必须正面解决。
官方设定是「约 6,000 条训练样本 + 中等算力」，把 Qwen3.5-9B 从 41.8% 拉到 56.4%；MoE 那条路径甚至只用 1,792 条。样本量的意义取决于清洗质量与难度分布——难度探测、剔除全对样本、补入全错样本这几步，比单纯堆量更影响结果。
不能直接迁移。这批数字的口径是官方评测脚本 + 全部 500 个实例 + 仓库级隔离测试；你的业务若缺「可自动判定对错」的验收器（类似 FAIL_TO_PASS / PASS_TO_PASS），同一套流水线跑不出同样的信号质量。可迁移的是方法：先保证奖励不可作弊，再谈模型规模。
会。官方对策是开启训练框架提供的策略校正，用 token 级重要性采样并对裁剪阈值取 2；同时建议以 2:1 的活跃组/消费组比例起步，并在网关侧用暂停与排空保证权重更新时的请求一致性。
如果你正在评估自建平台要不要引入强化学习训练，可以先从「我们有没有一套可自动判定对错的验收器」这个问题开始。蓝曜炬辉（www.lanyaoai.com）在智能体交付上积累的评测口径与日志链路细节都整理在 /cases，可以对照自己的场景做一次可行性盘点。
stable/05-basics/、stable/75-example-coding-agent/、stable/76-example-coding-agent-moe/、stable/35-asynchronous-training/、stable/01-quick-start/