你让一个 AI 代理在终端里修程序。它先读代码，再运行命令、查看报错，反复尝试，最后由测试程序打分。真正训练这样的代理，难点不只在于选哪种强化学习算法。系统还要同时照看任务环境、生成过程、评分、模型更新和几十张加速卡；任何一环变慢或前后不一致，都可能让昂贵的计算白费。
Miles v0.1 想解决的正是这类工程问题。作者将它定位为面向前沿模型后训练的全栈、生产级系统。后训练（post-training）是基础模型完成大规模预训练后，再用示范、偏好或可验证任务继续调教的阶段。它负责把“会续写文字”的模型，塑造成更会听指令、推理和使用工具的产品。相比再提出一种 RL 算法，Miles 更值得注意的地方，是试图把整条流水线做成一个可部署、可替换、可扩展的系统。
本文的系统能力、性能数字和“生产级”定位均来自作者论文这一单一信源；其中部分功能仍属早期阶段，不能视为已经获得独立验证。
先让生成和训练同时转起来
强化学习（RL）可以理解为让模型反复尝试，再根据结果得分，提高高分做法以后出现的概率。一次完整循环包含三件事：模型执行任务并产生 rollout，环境给出奖励，训练器据此更新模型，然后把新权重送回负责生成的引擎。Rollout 就是一次完整尝试；在终端编程任务中，它可能包含多轮对话、命令调用、环境反馈和最终结果。
传统做法容易像两支轮流施工的队伍：生成端等训练端，训练端又要等一批任务里最慢的那一个。Miles 提供 fully asynchronous 模式，让生成与训练在两组 GPU 上并行推进。生成完成的轨迹先进入一个容量有限的缓冲区，训练器从中取出已经完成的轨迹组。这样，某个超长任务不会让整批硬件一起停下来。
异步也带来新问题：训练器不断更新，缓冲区里的轨迹可能来自较旧的模型。Miles 因此记录权重版本，并把“陈旧度”定义为当前训练权重版本与一组轨迹中最老权重版本的差。系统可以丢弃超出限制的轨迹，也会报告队列长度、平均陈旧度和丢弃数量。说白了，它不只追求让机器忙起来，还要让操作者看得出流水线究竟堵在哪里。
AI 走过的路，训练器必须原样看到
后训练还有一个不显眼但很要命的问题：生成端和训练端可能以为自己处理的是同一段经历，实际看到的 token——模型内部处理文字的基本单位——却并不相同。
多轮代理会经历消息解析、工具执行和对话模板重新渲染。任何一步都可能改变分词、删去历史推理，或重新序列化工具参数。训练器随后重建出的轨迹，可能根本不是模型当时采样出的那条轨迹。更新方向于是建立在一段“没有真正发生过的经历”上。
Miles 用 TITO（Token-In-Token-Out）session server 处理这个问题。它让服务器掌管 token 化，保存每轮输入输出的准确 token ID、生成概率和检查点；后续只处理新增部分。对于会分叉或压缩上下文的代理，它还支持树状保存不同历史分支。这里的核心判断很朴素：训练系统不能只保存整理过的聊天记录，还得保存模型当时真正走过的数字路径。
对 MoE（Mixture of Experts，混合专家）模型，事情还要更复杂。这类模型会为每个 token 选择少数“专家”子网络。生成端和训练端即便拿到同样的 token，也可能因为数值差异选中不同专家。Miles 的 R3 机制会记录生成时的专家路由，并在训练时重放。不过代价并不小：按作者给出的例子，一条 32K token、60 层的轨迹，其路由张量约占 60 MB。因此 R3 是按训练配方选择的能力，并非默认适用于所有场景。
全栈不等于所有东西都自己造
Miles 的 rollout engine 建在 SGLang 之上。对于多轮任务，它尽量把同一会话持续送到同一引擎，以复用 KV Cache——模型阅读长上下文时保存的中间结果，免得每一轮从头计算。作者报告，在其参考运行中，这种会话绑定与负载分配组合实现了 96% 的前缀缓存命中率。
训练端则可选 NVIDIA Megatron-LM 或 PyTorch FSDP。两者都是把大模型拆到多张加速卡上训练的后端。模型更新后，Miles 还提供三种权重同步传输方案，以适配不同部署拓扑。论文摘要没有在现有材料中完整展开三种方案各自的适用条件，因此目前只能确认它提供了这项选择，不能比较优劣。
系统覆盖的训练方式也不只一种：包括更新全部模型参数的 RL、只训练少量附加参数的 LoRA RL、让学生模型跟随当前策略输出的 on-policy distillation、使用示范答案训练的监督微调（SFT），以及作者所称的 true-on-policy rollout-training alignment。Miles 还把同一架构扩展到了 diffusion models，即通过逐步去噪生成内容的模型。
为什么值得关注
Miles 把“训练效果是否可信”当成系统问题，而不只是算法问题。它尝试同时处理吞吐率、轨迹陈旧、token 一致性、MoE 路由差异、低精度计算和权重同步。尤其在低精度训练上，作者强调生成端与训练端必须遵守同一量化约定：两边要用相同方式压缩权重数值，否则微小差异会逐层累积。报告列出了 BF16、FP8、MXFP8 和 NVFP4 等配方，但也明确表示部分格式仍处于 Beta 或早期阶段。
作者还给出一个端到端案例：在 GLM-5.2 744B-A40B 模型上，以 64 张 NVIDIA GB300 GPU 进行 fully asynchronous agentic RL，任务是让代理使用终端完成编程工作。前 30 个测量 step 的中位耗时为 263 秒。这个数字至少说明系统跑通了一个大规模、长链条案例，却不能证明它普遍更快：论文没有在所给材料中提供可比基线、吞吐量、序列长度、负载细节或长期稳定性区间。
Miles 已由作者公布在 GitHub，并设有项目网站。它所代表的方向比某个单项优化更宽：前沿后训练正在从“有一套算法”走向“有一套能持续运转、能检查错误、能替换组件的基础设施”。对于真正要训练工具型 AI 的团队，后者往往才是从实验走到部署之间最难补的一段。
局限与未知
- “production-ready”“frontier-scale”等说法目前是作者定位。现有单一信源不足以独立验证代码完整度、许可证、复现实验能力和长期故障恢复表现。
- fully asynchronous 允许训练使用稍旧的轨迹，而 true-on-policy 强调生成策略与训练策略对齐。Miles 用版本记录和陈旧度限制缓解这层张力，但严格定义及一致性保证仍需作者进一步说明。
- 263 秒只对应一个硬件、模型、任务组合和前 30 个 step。它是案例记录，不是跨系统性能结论。