你已经搭好一个能改代码的 AI Agent：它会调用模型、读文件、运行工具，也知道何时继续和停下。现在你想用强化学习让它做得更好，却往往要在训练框架里把这套流程再造一遍。成本高不说，训练出来的还是一个“仿制版”Agent，和真正部署的系统未必表现一致。
Microsoft Research Asia 发布并开源了完全重构的 Agent Lightning v1.0，试图省掉这次重复建设。它提出 Harnessed Agentic RL：让部署时使用的同一套 Agent Harness 直接参加强化学习。Agent Harness 是驱动 Agent 的外层程序，负责连接模型、工具、运行环境和状态。简单说，微软想训练真实上岗的那套系统，而不是先在训练框架里另搭一个练习场。
目前关于 v1.0 的架构、代码规模和实验效果，都来自 Microsoft Research 官方博客，尚无材料显示有第三方复现或独立评测。
不重搭 Agent，只改模型入口
强化学习（RL）让系统根据行动得到的奖励或惩罚来调整策略。在 Agent 场景里，奖励可以来自任务是否完成、回答质量或工具操作结果。
传统 Agent 强化学习通常由训练框架掌管整个交互循环。以 ReAct 式流程为例，模型先生成一个动作，环境返回观察结果，系统把结果放回上下文，模型再决定下一步。整段过程可以被训练框架视为一条连续的 token 轨迹。Token 是模型处理文字时使用的基本单位。
问题在于，现实中的 Agent 已经不只是一个模型。它还有自己的上下文管理、工具协议、执行逻辑和软件依赖。微软列举的 coding agent 包括 mini-SWE-agent、OpenHands、OpenCode、Claude Code 和 Codex。若把每套 Agent 的循环重新写进训练框架，不仅费事，还可能改变它原本的行为。
Agent Lightning 的做法像是在现有通话线路中接入一个转接台。开发者把 Harness 原先调用模型 API 的地址指向 Agent Lightning 的 LLM proxy——即大语言模型代理。Agent 仍按原来的方式运行，代理则观察并记录它与模型之间的请求和响应。按照微软的说法，现有 Harness 代码不必因此重写。
真正难的是把运行记录变成训练材料
让真实 Harness 掌管交互，也带来新的麻烦。训练系统不再完整控制 Agent 的每一步，只能看到一串模型请求和响应。同一次任务运行，也就是一次 rollout，可能被拆成数量不定的训练样本。
微软归纳了四个问题。
第一是重新分词与样本合并。Harness 通常以文本保存上下文，但强化学习需要模型当时实际采样的 token ID。若事后再用聊天模板和 tokenizer——把文字切成 token 的组件——处理一遍，边界可能变化，相邻调用未必能准确拼回一条样本。
第二是 advantage 的计算。Advantage 可以理解为：某次行动比通常水平好多少。重新分词、子 Agent 和上下文摘要都可能把一次 rollout 切成多段。如果直接按样本计算，产生片段较多的 rollout 会被重复计数，破坏原本以整次任务为单位的统计关系。
第三是损失归一化。损失是训练时衡量模型偏差的数值。如果简单按样本数取平均，片段更多的 rollout 会获得更大权重。但片段多少可能只是 Harness 的工作方式造成的，不代表这次任务更重要。
第四是训练后端调度。只有 Harness 跑完以后，系统才知道样本有多少、每段多长；GPU 数量和并行配置却通常提前固定。训练后端必须把不断变化的工作量塞进固定资源。
供稿材料说明了这四道难题，却在后续解决方案展开前截断。因此，目前只能确认 v1.0 以真实 Harness 为中心重新划分了训练系统的职责，不能据此补写每个问题的具体算法。
约3500行代码，想降低的是工程门槛
微软称，Agent Lightning v1.0 的完整强化学习控制平面约有 3500 行代码。控制平面不是执行任务的 Agent，而是负责调度任务、收集轨迹、分配训练作业和管理状态的基础设施。这个数字的意义不在于“代码越少越先进”，而在于它试图把一套容易理解、修改和扩展的训练基础设施交给开发者。
它还原生支持 Kubernetes——一种管理和调度容器化程序的平台。Agent 可以作为标准 Kubernetes job，运行在自管集群、云端 Kubernetes 或本地基础设施上，不依赖付费商业沙箱服务。不过，这不等于训练无需隔离环境，也不等于没有计算资源和运维成本。
微软还公布了一项 coding agent 实验：端到端流程使用约 6000 个基于开源数据集的训练样本，把 Qwen3.5-9B 在 SWE-bench Verified 上的 Pass@1 从 41.8%提高到56.4%，绝对提升14.6个百分点。SWE-bench Verified 用真实的软件缺陷修复任务测试模型；Pass@1 表示第一次尝试成功的比例。
这组结果让 Agent Lightning 看起来不仅是接口层改造，也可能真正改善任务表现。更值得关注的，则是它把强化学习从“重新实现整个 Agent”变成“接入现有 Agent”。如果这条路径经得住验证，开发者更容易让训练环境贴近实际部署环境，也更容易替换和比较不同 Harness。
局限与未知
- 约3500行的统计口径没有披露，“完整、轻量、可复现”等表述目前仍是微软一方的产品主张。
- SWE-bench Verified 成绩缺少足够的评测设置细节，包括模型检查点、推理预算、Harness 与基线是否条件一致；约6000个样本如何生成、筛选和去重也不清楚，因此尚不能判断数据污染风险或与其他公开成绩直接比较。
- 现有材料没有第三方复现。它证明了一个值得尝试的工程方向，但还不足以证明这套方案能稳定适配不同 Agent、工具环境和训练规模。