【Agentic RL / 强化学习框架】Miles 项目技术分析---（1）--- 总体

0x00 概要

Miles 将 Slime 的"研究级 RL 框架"升级为"Agentic-first 的企业级生产系统"，核心创新在于用 Session/TITO 解决多轮 tokenization 正确性，用全异步 + staleness 解决性能，用 R3 + True On-Policy 解决稳定性。

Miles 的技术特色总结如下：

下图可以看到Miles的工作：

Miles 的工作 = 利用Slime扩展点 + 底层内核 / 精度改造 ◄─── 非扩展点 + RDMA 权重同步基础设施 ◄─── 非扩展点 + 训练后端深度改造 (FSDP/CP) ◄─── 非扩展点 + Chat Template 正确性工程 ◄─── 非扩展点 + 可观测性 / 调试系统 ◄─── 非扩展点 + 20+ 场景示例生态 ◄─── 非扩展点 + ......

注：在本文撰写时，朱小霖大神 已经发布了最新版本 slime v0.3.0: 面向 Agent 时代 ，因此，本文涉及的 slime 都是旧版本的表现，不代表 slime 的最新能力。

另：因为本文为从源码反推涉及，且编写仓促，所以肯定有错误，还请读者不吝指出，谢谢。

0x01 基础

1.1 Agentic RL 的需求与难点

在传统 RLHF 中，模型根据一个 prompt 生成一段回答，reward model 对该回答打分，完成一轮训练。

而在 Agentic RL 场景下，Agent（LLM）在一个有状态的环境中通过多轮交互来完成任务——调用工具、搜索信息、执行代码、与外部 API 交互。模型需要从交互的最终结果（而非中间回答的评分）中学习。

1.1.1 传统 RLHF vs Agentic RL 范式对比

以下数值不是精确值。

1.1.2 核心难点

Agentic RL 的需要是：框架可以处理 推理编排、长程训练、外部环境和工程维护方式等功能，其核心难点具体举例如下：

1.2 系统架构

Miles fork 自 slime，继承其核心的 RL 流水线架构：

Miles 的系统架构如下：

1.3 组件边界说明

Miles 由多个可独立启停的进程/服务组成，以下标准明各组件的职责边界：

1.4 数据流

miles 的 6 步完整流程如下：

1.4.1 步骤 1：Prompt 输入

路径：

JSONL 文件 → Dataset 加载 → tokenizer/processor 预处理 → RolloutDataSource.get_samples(batch_size) → 每个 prompt 复制 n_samples_per_prompt 份 → list[list[Sample]]

每个Sample的初始字段：—prompt,tokens,response,response_length,loss_mask,rollout_log_probs,rollout_routed_experts,reward,status,metadata等。

1.4.2 步骤 2：Agent 交互（多轮场景）

路径：

Sample → generate(Sample) → OpenAIEndpointTracer.create() → POST /sessions → session_id → custom_agent_function(base_url, prompt, kwargs, metadata) → Agent 内部多次 POST /sessions/{id}/v1/chat/completions → Session Server 代理到 SGLang Router → SGLang Engine 推理 → collect_records() → GET /sessions/{id} → compute_samples_from_openai_records() → TITO trailing token trim → list[Sample] (每轮一个) → merge_samples() / 保持多轮

1.4.3 步骤 3：训练数据转换

路径：_convert_samples_to_train_data()

Sample[] → { "tokens": [...], # prompt + response 完整 token "response_lengths": [...], # 每样本 response 长度 "rewards": [...], # 归一化后的奖励 "raw_reward": [...], # 原始奖励 "loss_masks": [...], # 每 token 是否参与 loss "truncated": [...], # 是否被截断 "rollout_log_probs": [...], # SGLang 推理时的 log prob（用于 TIS） "rollout_routed_experts": [...], # R3 路由数据 "weight_versions": [...], # 推理时的权重版本（用于 staleness 检测） }

1.4.4 步骤 4：训练

路径：train_actor()

rollout_data → get_data_iterator() → micro-batches → [if R3] _fill_replay_data() → 解析 routed_experts 到 Replay 对象 → [if KL] _switch_model("ref") → compute_log_prob(ref_log_probs) → _switch_model("actor") → compute_log_prob(log_probs) → compute_advantages_and_returns() → GRPO/PPO/REINFORCE++ → train() → Megatron 前向 + 反向 + optimizer step

优势函数计算的核心逻辑见，支持6 种优势估计器：

1.4.5 步骤 5：权重同步

路径：[actor.py] → [mixin.py] → [p2p.py]

Megatron GPU params → TP all_gather (收集 tensor parallel 分片) → EP all_gather (收集 expert parallel 分片) → Megatron→HF 格式转换 → ParameterMapper.map() (HF name → SGLang name) → load_weights() → shared CPU buffer → mooncake RDMA write → SGLang GPU memory → post_load_weights() (FP8 重量化) → weight_version++

1.4.6 步骤 6：循环（全异步变体）

路径：[train_async.py]

rollout_data_next = generate(rollout_id + 1) ← 提前启动 rollout_data_curr = await rollout_data_next ← 等待本次 train(rollout_id, rollout_data_curr) ← 训练与下次 rollout 重叠

0x02 从 Slime 说起

在 Slime 基础上，Miles 将 Slime 的 "支持 Agentic"升级为 "Agentic-first"，提供开箱即用的 Agent 训练工具链。

2.1 Slime 的职责定位

Slime 是 "分布式 RL/LLM 训练底座" - 负责把 Ray + Megatron + SGLang 组织成可训练、可 rollout、可评估的闭环系统。Slime 的核心职责不是定义具体 agent 玩法，而是提供：

• 训练主循环(train.py,train_async.py):rollout->train->save->eval->update weights
• Ray 资源编排(Placement Group, Train Actor, Rollout Manager 生命周期)
• Megatron 训练后端(模型初始化, train/save, loss/value/log prob 计算)
• SGLang rollout 基础设施(启动推理引擎, router, generate/eval, 健康检查)
• 插件 / 扩展点(25+ 个--xxx-path动态导入接口)

Slime 不负责：复杂 agent/session/tool/多轮语义、训推精确一致性治理、多后端。

2.2 Slime 端到端做了什么

在train.py里，Slime 负责完整训练编排：

分配 GPU -> 启动 rollout manager -> 创建 actor/critic -> 每轮：generate rollout -> train -> save -> eval -> update rollout weights

在 rollout 层面：

• 启动 / 恢复 SGLang engine
• Router 地址与端口管理
• Offload/onload
• 健康监控
• 多 server group 组织

在训练后端：

• Megatron 初始化
• Tokenizer/config 加载
• Model/optimizer/scheduler 初始化
• Rollout 数据转训练 batch
• Policy/value/log prob/loss 计算
• Actor -> rollout 权重同步

2.3 Slime 的扩展点体系

Slime 明确把以下内容(举例)设计成可插拔，这样开发者可以定制：

0x03 Miles 的升级

Miles 将 Slime 的"研究级 RL 框架"升级为"Agentic-first 的企业级生产系统"，核心创新在于用 Session/TITO 解决多轮 tokenization 正确性，用全异步 + staleness 解决性能，用 R3 + True On-Policy（当前支持 dense 模型）解决稳定性。

3.1 升级思路 --- 三层利用策略

虽然 Slime 提供了扩展点，但是 Miles 并没有简单的利用扩展点，而是“利用扩展点 + 新增架构层 + 深度改造核心” 三者并行。具体可以分为三层：

• Layer C: 新增架构层 (Miles 独创)Session Server / TITO / Miles Router / Agent Hook → Slime 完全没有预见
• Layer B: 深度改造 (修改 Slime 核心 + 扩展点)改默认 rollout/data-source / 删 advantage hook 类 / 优化 rollout 合约 / bridge 路径切换
• Layer A: 直接利用扩展点 (Slime 设计的 path hooks)custom-generate / custom-rm / dynamic-filter ， Miles 用户进一步通过这些接口接入自己的逻辑

3.2 分工边界

Slime 做 "能跑起来"，Miles 做 "跑得正确 + 跑得快 + 跑复杂场景"。因此，两者分工边界如下：

3.3 Miles工作全景

下表为Miles工作全景，对于主要工作领域进行分类，看看属于三层中哪一层。其中：

• Layer A. 利用扩展点：通过 Slime 预设的--xxx-path接口注入实现

• Layer B. 新增架构层：Slime 完全没有的模块，Miles 从零建设
• Layer C. 深度改造/修改核心：对 Slime 原有代码的深度改造 / 重写

具体统计