做 Agent 的人多少都撞过同一堵墙：线上跑得挺稳的那套 agent，一旦要拿去做强化学习，就得在训练框架里从头再写一遍。重写出来的东西看着像双胞胎，训练出的策略丢回真实 harness 里却经常失灵。微软研究院亚洲把这条路重新铺了一次——开源的 Agent Lightning v1.0 只有 3500 行，主张却相当锋利：部署时用的那个 Agent Harness，一行不改，直接参与 强化学习。
被忽略的那层壳，其实决定了训练上限
训练脚本里的 agent，和上线跑的往往是两个物种
典型流程是这样：研究员把工具调用、多轮对话、上下文裁剪、失败重试，用 Python 在 rollout worker 里复刻一遍。为了跑得动、跑得快，复刻版顺手砍掉了一堆"无关细节"——接口超时怎么兜底、工具返回的脏数据怎么清洗、system prompt 的拼接顺序、历史消息压缩到什么长度。
于是模型在实验室里学的是干净版本的最优解，上线后面对的是带噪音的那一版。这算不上 reward hacking，更准确的叫法是环境错配。而错配的代价，通常被记在"模型泛化不行"的账上。
harness 是策略的一部分，不是外挂
很多人把 harness 当成框架选型题：用 LangChain 还是 OpenAI Agents SDK。但 harness 真正干的事，是在每次模型调用前后做出一连串决策——给模型看什么、允许它调什么、什么时候判定它该收手。这些决策直接塑造了动作空间和观测空间。
把它们从训练回路里摘出去，等于让模型在一个被抽掉关键约束的世界里学走路。走得挺好，回到现实就摔。
它靠什么把训练接回真实环境
一个中间层，把执行和梯度彻底分开
Agent Lightning 的解法是解耦。agent 进程里照旧跑着原来的框架，只是它发出的每一次模型请求，被路由到 Agent Lightning 提供的兼容端点；执行过程中产生的状态、动作、奖励，写进一个中心化的 store。训练器在另一头轮询这个 store，取轨迹、算梯度、更新权重，新权重再被 agent 的下一次调用取走。
关键在于，整个过程 harness 一行没动。它不知道自己在被训练，这恰恰是设计目的。
3500 行是个刻意的数字
放在今天的开源生态里，3500 行小得有点反常。潜台词是：这层基础设施应该薄到能通读、能 fork、能塞进现有系统而不引发架构地震。
轻量同样意味着它不替你解决所有问题。工具沙箱、环境模拟、rollout 并发、失败重试、状态一致性——这些活儿还在调用方手里。框架负责连接，不负责代劳，边界划得相当明确。
奖励只有最后一分，信用怎么分
真正的硬骨头在信用分配。一个 agent 为了订完一张票调了二十次模型，中间搜索过、纠错过、走错路又退回来。最后任务成功，奖励是 1。这 1 分该摊给哪几步？
Agent Lightning 把整段执行拆成有层级的决策序列，让每一轮模型调用都能被单独归因，而不是把一条几十步的轨迹当成一个巨大动作。多轮、多 agent 的场景里，这件事对成败的影响远大于选哪个 RL 算法。
这套范式改变了谁的工作
算法团队不再独占话语权
Harnessed Agentic RL 动摇的是一种分工惯性。以前模型训练归算法团队，agent 工程归应用团队，中间隔着一道翻译成本。现在这道墙被压薄了：应用团队维护的 harness 直接决定训练数据长什么样，也直接决定模型学不学得会。工程判断头一回这么直接地变成了训练信号的一部分。
便宜不等于简单，真实系统会带来真实方差
得泼点冷水。真实 harness 进训练回路，意味着不确定性也来自真实世界：工具接口不稳定、外部 API 限流、同样的搜索每次返回不同结果。推理时这些噪音可以忍，进了训练回路就变成方差来源。
所以顺序不能反。先有本事把环境做得可复现，再谈算法调优。跳过后一步直接调参，跑出来的曲线会很难看，而且你找不到原因。
接下来值得盯的两个信号
第一，有没有团队敢把线上流量的一部分直接喂进训练回路。那才是这套范式的极限测试，实验室里的模拟环境永远测不出这个。
第二，围绕 store 这个中间层会不会长出生态——轨迹回放、失败样本筛选、跨框架的 harness 兼容层。半年内如果只有论文和 demo 在流转，说明门槛还太高；如果冒出了专门做 harness 版本管理的工具，那这条路就算是真的通了。
到那时再回头看，3500 行可能不是克制，而是一份邀请函。
