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

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

• 0x00 概要

• 0x01 基础

  • 1.1 Agentic RL 的需求与难点
  • 1.2 系统架构
  • 1.3 组件边界说明
  • 1.4 数据流

• 0x02 从 Slime 说起

  • 2.1 Slime 的职责定位
  • 2.2 Slime 端到端做了什么
  • 2.3 Slime 的扩展点体系

• 0x03 Miles 的升级

  • 3.1 升级思路 --- 三层利用策略
  • 3.2 分工边界
  • 3.3 Miles工作全景
  • 3.4 Miles 对 Slime 扩展点的利用
  • 3.5 完整工作
  • 3.6 结论

• 0x04 Miles 的逻辑分层

  • 4.1 问题域总结
  • 4.2 分层架构图
  • 4.4 详细映射表
  • 4.5 各层工作量分布

• 0x05 Miles 每项工作解决的问题

  • 5.1 L5: Agent/Session/Tool 语义层
  • 5.2 L4: 训推一致性治理层
  • 5.3 L3: 训练后端扩展层
  • 5.4 L2: 基础设施层
  • 5.5 L1 生态层

• 0x06 对比

  • 6.1 整体设计哲学差异
  • 6.2 关键机制对比
  • 6.3 Miles 的优势
  • 6.4 Uni-Agent 值得借鉴的设计

• 0x07 Agentic RL 8 大关键维度

• 0xFF 参考

0x00 概要

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

Miles 的技术特色总结如下：

特色	核心理念	实现
Agentic-First	Agent 开发像写普通应用	Session Server + TITO + agentic_tool_call
正确性优先	消除所有训推不一致源	R3 + FP8 统一 + True On-Policy + TIS/MIS
性能极致	GPU 永不空闲	全异步 + 投机解码 + 零拷贝 + 部分 rollout
渐进式保证	从宽松到严格可选	Staleness(宽) → TIS(中) → True On-Policy(严)
工程纪律	静默错误 → 显式断言	Chat template 验证 + 运行时 prefix 校验
插件化扩展	新模型零改核心代码	miles_plugins/ + middleware_hub
Multi-Agent	从轻量到生产级	内置示例 → MrlX 完整框架

下图可以看到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 范式对比

以下数值不是精确值。

维度	传统 RLHF（单轮）	Agentic RL（多轮）
交互轮次	1 轮	10-50+ 轮
序列长度	<4K tokens	8K-64K+ tokens
单次 Rollout 时长	<10s	60-600s
Token 归属	全部归模型	混合：model token (loss_mask=1) + env token (loss_mask=0)
环境依赖	无	强依赖外部环境（Docker/API/沙箱）
失败模式	少	超时/环境崩溃/格式错误/上下文满/沙箱死亡
Reward 来源	固定 Reward Model	环境结果（test pass, task complete）
Credit Assignment	短序列，信号直接	长序列，Reward 在末尾
Off-policy 风险	低	高（生成慢，模型可能已更新多次）

1.1.2 核心难点

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

难点	具体表现	影响
多轮状态管理	50 轮 × 200 token = 10K+ token 需要在 session server 中累积追踪	内存和 tokenization 一致性压力
Token 混合属性	env token（工具返回/用户输入）mask=0，model token mask=1；错标一个 = 梯度噪声	一个 token 错标 → 该样本梯度方向偏移
Tokenization 一致性	Jinja loop.last 导致 10% prefix 变化，首轮 tokenization 被后续轮覆盖	10% token 不一致 → 训练数据质量下降
训推不一致 (log prob)	推理用 SGLang（FP8/int4），训练用 Megatron（BF16），log prob 不一致	KL 估计失真 → 优势函数偏差
MoE 路由翻转	~5-15% token 在训练和推理时路由到不同 expert；精度差异导致 expert 选择不同 → 梯度计算在错误 expert 上	前向 log prob 和反向梯度路径不一致 → 训练崩溃
长尾延迟	一个慢 Agent 会话阻塞整个 batch，GPU 利用率暴跌	GPU 利用率断崖下降
On-Policy 过期	120s 推理窗口内模型已更新 2-3 步，但 rollout 仍使用旧模型权重	重要性采样权重偏离
Credit Assignment	50 轮后 reward=1，不知道哪步贡献最大	策略梯度信号极稀疏
异构 Agent 协同	不同 agent 用不同模型、不同训练循环、消息队列通信	数据结构不统一、reward 非对称
规模可扩展性	1TB+ MoE 模型数十 GB 参数同步	RDMA 带宽成为瓶颈

1.2 系统架构

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

mile-1-1

Miles 的系统架构如下：

mile-1-2

1.3 组件边界说明

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

组件	职责	何时需要
SGLang Engine	模型推理（ rollout 生成），每个实例管理一组 GPU	始终需要（无推理则无 rollout）
SGLang Router (sglang_router)	Round-robin / cache-aware 推理请求路由	多 GPU 推理（默认搭配 SGLang engine）
Miles Router (miles/router/)	最少连接负载均衡 + 健康检查 + 故障隔离 + radix tree 缓存中间件	高级路由需求：--use-miles-router + --miles-router-middleware-paths
Session Server	多轮会话管理 + TITO 增量 tokenization + OpenAI 格式代理	Agentic RL（多轮交互）：--use-session-server
Megatron Actor	分布式训练（前向/反向/optimizer step）	始终需要（--train-backend megatron，默认）
FSDP Actor	分布式训练（实验性后端）	--train-backend fsdp（小规模/非 MoE 模型）
Ray	分布式进程编排、Placement Group、Actor 生命周期	始终需要（框架基础设施）
mooncake TransferEngine	RDMA 零拷贝权重传输	P2P 模式（默认，--update-weight-transfer-mode p2p）

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 种优势估计器：

估计器	机制
GRPO	组内 reward 减去均值 + 可选 std 归一化
GSPO	组内 reward 归一化 + 序列级 KL 约束
PPO	GAE + value function clipping
REINFORCE++	逐 token 折扣累积 reward
REINFORCE++ Baseline	同上 + baseline 减方差
On-Policy Distillation	teacher - student log prob 差

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 训练工具链。

维度	Slime	Miles (fork)
设计初衷	通用 LLM RL 后训练框架	企业级大规模 Agentic RL
Agentic 支持	通过异步解耦架构支持	继承 + 增强 (多智能体 MrlX)
核心用户	GLM 系列模型训练	更广泛的企业场景

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 明确把以下内容(举例)设计成可插拔，这样开发者可以定制：

类别	扩展点	机制
Rollout	--rollout-function-path / --custom-generate-function-path / --eval-function-path	import path
数据	--data-source-path / --buffer-filter-path	import path
过滤	--dynamic-sampling-filter-path / --rollout-sample-filter-path	import path
Reward	--custom-rm-path / --custom-reward-post-process-path	import path
Loss	--custom-loss-function-path / --custom-tis-function-path / --custom-pg-loss-reducer-function-path	import path
训练	--custom-convert-samples-to-train-data-path / --custom-advantage-function-path	import path
Megatron Hooks	--custom-megatron-init-path / before-log-prob-hook / before-train-step-hook	import path
模型	args.spec / @register_model / @MegatronModelBridge.register_bridge	import + 注册
日志	--custom-rollout-log-function-path / --custom-eval-rollout-log-function-path	import path
ABC	DataSource / TrainRayActor / HfWeightIteratorBase / HuggingfaceAttention	继承

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 做 "跑得正确 + 跑得快 + 跑复杂场景"。因此，两者分工边界如下：

维度	Slime 负责	Miles 负责
训练主循环	基本闭环 (同步/异步骨架)	异步化增强 / AsyncRolloutWorker / Staleness
Ray 编排	PG / Actor Group / Rollout Manager	在上面加 runtime 语义，不改编排层
Rollout	单次 generate + eval + 基础 router	Session 多轮 + tool call + agent loop + 统一编排
训练后端	Megatron only	Megatron 增强 + FSDP + 跨后端公共抽象
权重同步	基础 HTTP 传输	broadcast + P2P RDMA + 多并行布局
MoE 支持	基础	+ R3 路由重放, 解决训推不一致
算法一致性	无系统治理	频谱：Staleness -> TIS -> R3 -> True On-Policy
Token 正确性	无验证	TITO + template 验证 + append-only 校验
可观测性	基础 logging	4 后端 Tracking + debug dump + profiling
模型生态	GLM 为主的支持	10+ 模型族 bridge + megatron_bridge patch

3.3 Miles工作全景

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

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

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

工作领域	Layer A. 利用扩展点	Layer B. 新增架构层	Layer C. 深度改造/修改核心
① Rollout 生成	agentic_tool_call/multi_turn/single_turn	generate_utils/ (token对齐/loss_mask/prefill log prob)	inference_rollout/ 重构调度架构
② Session & 多轮	-	Session Server / Linear Trajectory / TITO / Template 验证 / --custom-agent-function-path	-
③ Reward 体系	8+ 内置 RM	rm_hub/ 异步框架	-
④ 样本过滤	check_reward_nonzero_std / check_no_aborted	filter_hub/ 协议抽象	-
⑤ 数据源	RolloutDataSourceWithBuffer	-	默认数据源切换
⑥ 训练 Loss	保留 loss/tis 扩展点	training_utils/loss.py 跨后端公共层	Loss 重构 (TIS/OPD/true-on-policy/CP)
⑦ 训练一致性	-	True On-Policy 契约 / FP8 统一内核	训练侧可直接用 rollout log prob
⑧ MoE 路由	-	-	R3 路由重放注入 MoE 层
⑨ 权重同步	-	P2P RDMA 零拷贝	多并行布局支持 + broadcast 增强
⑩ Router & 中间件	-	Miles Router / RadixTree 中间件	-
⑪ 训练后端	args.spec 保留	FSDB 后端 / training_utils/ 抽象	Megatron actor 增强 (LoRA/CP/P2P/debug)
⑫ SGLang 集成	-	sglang_utils/ 引擎管理	rollout 启动改造
⑬ 模型插件	10+ 模型 bridge	megatron_bridge/ Core patch	bridge 加载路径切换
⑭ 可观测性	保留 log 扩展点	Tracking 4 后端 / Debug Engine	Tracking 生命周期改造
⑮ 训练主循环	-	-	全异步 / Staleness 过滤 / AsyncRolloutWorker
⑯ 参数系统	-	200+ 新参数 / 插件自注册 args	删除 advantage hook; 默认值调整

具体统计

改造方式	涉及领域数	工作量占比
A. 利用扩展点（Layer A）	5	~15%
B. 新增架构层（Layer B）	12	~45%
C. 修改核心（Layer C）	10	~40%

---

3.4 Miles 对 Slime 扩展点的利用

3.4.1 Miles 主动提供内置实现的扩展点



说明：以下统计仅覆盖 --xxx-path 类 import-path 扩展点。若把 args.spec、@register_model bridge 注册等机制也算入，Miles 利用的扩展接口更多。

”

Slime 扩展点	Miles 注入的实现	目的
--custom-generate-function-path	agentic_tool_call:generate, multi_turn:generate, single_turn:generate	Agent/多轮/单轮生成
--rollout-function-path	InferenceRolloutFn	统一 rollout 编排架构
--dynamic-sampling-filter-path	check_reward_nonzero_std, check_no_aborted	训练质量守门
--data-source-path	RolloutDataSourceWithBuffer	支持样本回收重生成
--custom-rm-path (框架)	rm_hub/ 8+ 种 RM 类型	开箱即用 reward

3.4.2 Miles 保留但不提供内置实现的扩展点 (~19 个)

这些接口在 Miles 中仍然可用，留给最终用户（不完全列举，仅统计本文关注的主要 hook）：

• --custom-loss-function-path
• --custom-tis-function-path
• --custom-pg-loss-reducer-function-path
• --custom-reward-post-process-path
• --custom-convert-samples-to-train-data-path
• --custom-model-provider-path
• --custom-megatron-init-path
• --custom-megatron-before-log-prob-hook-path
• --custom-megatron-before-train-step-hook-path
• --custom-rollout-log-function-path
• --custom-eval-rollout-log-function-path
• --buffer-filter-path
• --rollout-data-postprocess-path
• --rollout-sample-filter-path
• --rollout-all-samples-process-path
• --eval-function-path
• args.spec
• @register_model (用户可扩展更多模型)
• @MegatronModelBridge.register_bridge

3.4.3 Miles 删除的扩展点 (1 个)

扩展点	原因
--custom-advantage-function-path	Miles 直接内置 advantage 计算，不再暴露

3.4.4 Miles 在扩展点之上新增的层

Miles 不只 "使用 "Slime 的扩展点，还创造了新的扩展点（以下是例子）：

Miles 新增扩展点	定义位置	说明
--custom-agent-function-path	miles/utils/arguments.py	Agentic RL 的 Agent 函数接口
--use-session-server + TITO 参数族	miles/utils/arguments.py:1660-1697	Session Server + TITO 整套基础设施
--miles-router-middleware-paths	miles/utils/arguments.py:1128-1160	Router 中间件插件系统
Plugin 可自注册 CLI args	miles/utils/arguments.py:1699-1714	Generate 插件可通过 fn.add_arguments(parser) 添加自己的参数
Class-based rollout 合约	miles/rollout/inference_rollout/compatibility.py	从纯函数升级为类

3.5 完整工作

3.5.1 全新增模块

模块	说明
miles/router/	R3 路由重放系统 - 自定义路由代理、健康检查、Worker 隔离、中间件加载
miles/utils/fp8_kernel.py	统一 FP8 Triton cast 内核
miles/true_on_policy/	True On-Policy 训练契约系统 (config、schema、contracts、model_profiles)
miles/backends/experimental/fsdp_utils/	实验性 FSDP 路径, 含 MoE helpers 和 Qwen3-MoE 支持
miles/backends/megatron_utils/kernels/int4_qat/	INT4 QAT CUDA 内核
miles_plugins/ 全部	插件层 - mbridge (DeepSeek V3.2, GLM4 等模型桥接)、megatron_bridge、models 适配器
miles/rollout/sleep_rollout.py	Sleep/vLLM 模式 rollout
docs/developer/migration.md	从 slime 迁移到 Miles 的指南
rollout/session/	Session Server + TITO 增量 tokenization
rollout/generate_hub/agentic_tool_call.py	Agentic RL 生成框架
true_on_policy/config.py	Kernel policy 生成器
P2P 权重传输子模块	mooncake RDMA 零拷贝同步

3.5.2 大幅修改模块

模块	改动内容
train.py + train_async.py	从同步循环升级为同步/异步双模式
megatron_utils/	大量新增：R3 replay、P2P 权重同步、megatron_to_hf 模型扩展、colocate 内存管理
sglang_utils/	SGLang 引擎封装层：FP8 pipeline、PD 分离、多模型配置、外部引擎支持
Chat Template 工具链	TITO tokenizer + TokenSeqComparator + 固定 Jinja 模板系统

3.5.3 继承核心

• RL 流水线结构（rollout → train → update_weights）
• 后端布局（megatron_utils / training_utils）
• 工具集（arguments, misc, ray_utils 等）
• 模块化参数解析（Megatron args + SGLang args 的合并机制）
• Ray Actor 基类

3.6 结论

Slime = "能跑起来" - 提供训练底座 + 25 个扩展点。

Miles = "跑得正确 + 跑得快 + 跑复杂场景"。

Miles的工作以B（新增）+C（改核心）为主，纯利用扩展点的工作只是冰山一角。真正的价值在于Slime完全没预见的“会话化正确性“和“训推致性治理“等新架构层，是对计算核心、传输层、正确性保障、可观测性做了全面的工程建设。---- 具体体现为：

• ~15% 利用扩展点 (RM/filter/generate/data-source 等 --xxx-path 接口 + bridge 注册)
• ~45% 新增架构层 (Session/TITO/True On-Policy/P2P/Router/FSDP/Tracking)
• ~40% 修改核心 (rollout 架构/loss/Megatron actor/权重同步/训练循环)

Miles 的价值不在于 "在扩展点上插实现"，而在于解决 Slime 最初设计时 **根本没预见的三类问题 **：

1. 多轮 token 正确性 (TITO + Template + Token 对齐)
2. 训推 bit-exact 一致性 (True On-Policy + R3 + FP8)
3. 大规模 Agentic 场景的性能 (全异步 + RDMA + RadixTree)

0x04 Miles 的逻辑分层

上面的角度是从如何改造 Slime 的思路来看，我们下面看看从解决问题角度来看，或者说从业务逻辑角度来看看如何对Miles进行分层。

4.1 问题域总结

Miles 对于问题域的解法如下。

问题域	核心痛点	Miles 的解法	主要改造方式
正确性	多轮 token 漂移、MoE 路由翻转、训推 log prob 偏差	TITO + Template 验证 + R3 + True On-Policy + FP8 统一	B+C
Agent 开发体验	每个 Agent 重写 boilerplate	Session Server + agentic_tool_call + custom-agent-path	A+B
性能	GPU 空闲率高、权重同步慢、前缀重复计算	全异步 + P2P RDMA + RadixTree 缓存	B+C
算法能力	需要 GRPO/TIS/OPD/多后端/多模型	Loss 重构 + FSDP 后端 + 10+ bridge	A+B+C
生产可靠性	样本质量、worker 故障、训练诊断	Filter + Router 健康检查 + Tracking + Debug	A+B
规模扩展	1TB+ MoE、千卡、多并行	P2P + CP + 多布局权重同步 + megatron_bridge	B+C

4.2 分层架构图

以上问题域的解法可以分为如下 L1 ~ L5 这 5 层。

═══════════════════════════ Miles 增强层 ══════════════════════
──────────────────────────────────────────────────────────────
L5: Agent/Session/Tool 语义层 
 Session Server / TITO / agentic_tool_call / Agent Hook 

──────────────────────────────────────────────────────────────
L4: 训推一致性治理层 
 True On-Policy 契约 / R3 路由重放 / TIS / FP8 统一内核 

──────────────────────────────────────────────────────────────
L3: 训练后端扩展层 
 Megatron 增强 (LoRA/CP/replay) / FSDP / training_utils 抽象 

──────────────────────────────────────────────────────────────
L2: Router/Session/Middleware 基础设施层 
 Miles Router / RadixTree / SGLang 引擎管理 

──────────────────────────────────────────────────────────────
L1: RM/Filter/Tracking/Debug/Plugin 生态层 
 8+ RM / Dynamic Filter / 4 后端 Tracking / 10+ 模型 bridge 

═══════════════════════════  Slime 底座 ═══════════════════════
──────────────────────────────────────────────────────────────    
训练主循环 | Ray 编排 | Megatron 后端 | SGLang rollout | 扩展点体系

这 5 层具体信息如下：

层级	定位	归属的 Jobs
L5 Agent/Session/Tool 语义层	多轮 Agent 语义、工具调用、对话管理	① Session & 多轮、② Rollout 生成（agentic_tool_call/multi_turn 部分）
L4 True-on-policy 一致性治理层	训推 log prob 对齐	③ 训推一致性、④ MoE 路由 (R3)
L3 训练后端扩展层	Megatron/FSDP/Loss/训练主循环	⑤ 训练 Loss、⑥ 训练后端、⑧训练主循环、⑦模型插件、⑨ SGLang 集成
L2 Router/Session/Middleware 服务层	通信、路由、权重同步、基础设施	⑩Router & 中间件、⑪ 权重同步、⑫ 数据源、⑬ 参数系统
L1 RM/Filter/Tracking/Debug/Plugin 生态层	奖励、过滤、监控、调试、插件	⑭ Reward 体系、⑮ 样本过滤、⑯可观测性

4.4 详细映射表

L5 Agent/Session/Tool 语义层
├─ Job① Session & 多轮 (Session Server, TITO, LinearTrajectory)
├─ Job② Rollout 生成 (agentic_tool_call, multi_turn, single_turn)
└─ (chat template autofix 也属此层)

L4 True-on-policy 一致性治理层
├─ Job③ 训推一致性 (契约系统, FP8统一, logprob直用)
└─ Job④ MoE 路由 (R3 路由重放)

L3 训练后端扩展层
├─ Job⑤ 训练 Loss (GRPO/PPO/TIS/OPD 跨后端公共层)
├─ Job⑥ 训练后端 (FSDP + training_utils 抽象)
├─ Job⑦ 训练主循环 (全异步/staleness/AsyncRolloutWorker)
├─ Job⑧ 模型插件 (10+ bridge + NemotronH patch)
└─ Job⑨ SGLang 集成 (sglang_utils + 启动改造)

L2 Router/Session/Middleware 服务层 / 基础设施层
├─ Job⑩ Router & 中间件 (Miles Router + RadixTree)
├─ Job⑪ 权重同步 (P2P RDMA + 多并行布局)
├─ Job⑫ 数据源 (RolloutDataSourceWithBuffer)
└─ Job⑬ 参数系统 (200+ 新参数 + 插件自注册)

L1 RM/Filter/Tracking/Debug/Plugin 生态层
├─ Job⑭ Reward 体系 (8+ RM + rm_hub 异步框架)
├─ Job⑮ 样本过滤 (filter_hub + 内置规则)
└─ Job⑯ 可观测性 (4 后端 Tracking + Debug 工具)

4.5 各层工作量分布

层	Jobs 数量	改造比重	核心价值
L5 语义层	2	*****	差异化核心：Agentic 多轮能力
L4 一致性层	2	****	技术护城河：训推对齐
L3 训练后端层	5	*****	基础能力：异步+大规模训练
L2 服务/基础设施层	4	***	生产就绪：路由+同步+配置
L1 生态层	3	***	开箱即用：RM+过滤+监控

注: Job② "Rollout 生成" 跨越两层 — generate_utils (token 对齐、loss_mask) 属基础设施层, 而 agentic_tool_call/multi_turn 属语义层。

0x05 Miles 每项工作解决的问题

Miles工作全景：领域×改造方式×解决的问题

5.1 L5: Agent/Session/Tool 语义层

主要是：Session Server / TITO / agentic_tool_call / Agent Hook

① Session & 多轮

改造方式	具体工作	解决的问题
B	Session Server (FastAPI)	状态持久化 - 多轮 Agent 对话历史跨请求保持；提供 OpenAI 风格 chat/completions 接口 (session scoped: /v1/sessions/{id}/v1/chat/completions)
B	LinearTrajectory	可回滚的轨迹管理 - Agent 产出有误时单步回退而非丢弃整条轨迹
B	TITO Tokenizer	多轮 token 前缀不变性 - 每追加一轮之前 token 不变，否则 logprob/loss_mask 全错
B	Chat Template 验证+autofix	静默 bug 预防 - 社区模板 loop.last/loop.index 破坏前缀一致性
B	--custom-agent-function-path	Agent 逻辑解耦 - 业务代码与训练框架彻底分离

② Rollout 生成

改造方式	具体工作	解决的问题
A	agentic_tool_call / multi_turn / single_turn	降低 Agent 开发门槛 - 用户只写 agent 函数，无需处理 tokenization/session/sample 转换
B	generate_utils/ (token 对齐、loss_mask 构建、prefill logprob)	消除 token 错位 - stop token 与下一轮模板渲染重复时自动 trim 对齐
C	inference_rollout/ 重构调度架构	统一 rollout 编排 - 训练/评测/中断/过滤/RM 调用重构为统一 pipeline

5.2 L4: 训推一致性治理层

③ 训练一致性

改造方式	具体工作	解决的问题
B	True On-Policy 契约系统	在受支持配置下对齐 log prob - 通过契约+deterministic 设置让两侧计算路径尽量 bit-exact (当前覆盖 qwen3 dense 契约)
B	FP8 统一内核	精度源对齐 - 两侧各用各的 FP8 cast -> 数值不一致 -> 统一 kernel
C	训练侧可直接用 rollout logprob	跳过重算 - 契约保证一致后无需浪费算力重算

④ MoE 路由

改造方式	具体工作	解决的问题
C	R3 路由重放	MoE 梯度正确性 - 推理选 Expert{2,7} 训练选 Expert{2,8} -> 梯度在错误 expert 上。存储开销：bytes ≈ (tokens-1) × num_layers × topk × 4 (dtype=int32)，以 32K token × 60 layers × top8 为例约 60MB/样本

5.3 L3: 训练后端扩展层

⑤ 训练 Loss

改造方式	具体工作	解决的问题
B	training_utils/loss.py 跨后端公共层	避免重复实现 - GRPO/PPO/TIS/OPD 不应在 Megatron 和 FSDP 各写一遍
C	Loss 大幅重构	支持新算法 - true-on-policy logprob 直用、OPD 蒸馏、CP 下 token 对齐

⑥ 训练后端

改造方式	具体工作	解决的问题
B	FSDP 实验后端	多后端选择 - 小模型不需要 Megatron 复杂性
B	training_utils/ 抽象	代码复用 - data/parallel/cp/log 在后端间共享
C	Megatron actor 增强	高级训练 - LoRA/CP 超长序列/debug/多模型切换

⑦ 训练主循环

改造方式	具体工作	解决的问题
C	全异步模式	GPU 利用率 - 同步等 Agent 60-120s -> GPU 空闲 >90%; 异步后 wall_time ≈ max(rollout, train)
C	Staleness 过滤	训练质量 - 异步下旧样本 importance ratio 偏离 -> 丢弃重生成
C	AsyncRolloutWorker	持续供给 - 独立线程+有界队列+背压

⑧ 模型插件

改造方式	具体工作	解决的问题
A	10+ 模型 bridge	广泛模型支持 - 每个模型权重命名/MoE/MTP 结构不同
B	megatron_bridge/ Core patch	特殊架构 - NemotronH (Mamba+MoE) 需 patch Megatron Core

⑨ SGLang 集成

改造方式	具体工作	解决的问题
B	sglang_utils/	引擎管理标准化 - 参数约束统一管理避免配置错误
C	rollout 启动改造	支持新特性 - True On-Policy 需要特殊启动参数

⑩Router & 中间件

改造方式	具体工作	解决的问题
B	Miles Router	生产级服务 - worker 故障自动隔离、最小并发路由、健康检查
B	RadixTree 中间件	推理效率 - 多轮交互前缀重复，缓存后只推理增量

5.4 L2: 基础设施层

⑪ 权重同步

改造方式	具体工作	解决的问题
B	P2P RDMA 零拷贝 (Mooncake TransferEngine)	同步速度 - 1TB+ 模型 HTTP 太慢，RDMA 直写 GPU 显存
C	多并行布局支持	大规模部署 - TP/PP/CP 下权重分片需正确收集+分发

⑫ 数据源

改造方式	具体工作	解决的问题
A	RolloutDataSourceWithBuffer	支持 buffer 回收 - staleness 过滤后样本需回收重生成

⑬ 参数系统 (200+ 新参数 + 插件自注册)

改造方式	具体工作	解决的问题
B	200+ 新参数	能力可配置 - 新功能都需要参数控制
B	插件自注册 CLI args	可扩展性 - generate 插件声明自己的参数
C	删除 custom-advantage-function-path	简化接口 - 内置即可，不再暴露

5.5 L1 生态层

⑭ Reward 体系 (8+ RM + rm_hub 异步框架)

改造方式	具体工作	解决的问题
A	8+ 内置 RM (math/dapo/f1/gpqa/remote...)	开箱即用 - 常见场景无需自己写 reward 函数
B	rm_hub/ 异步框架	高吞吐 reward - batch 化异步 RM，避免串行成为瓶颈

⑮ 样本过滤 (filter_hub + 内置规则)

改造方式	具体工作	解决的问题
A	check_reward_nonzero_std / check_no_aborted	防止无效训练 - 全对/全错组对 GRPO 无信号；ABORTED 组有噪声
B	filter_hub/ 协议抽象	过滤可插拔 - 不同任务不同逻辑，统一接口

⑯ 可观测性 (4 后端 Tracking + Debug 工具)

改造方式	具体工作	解决的问题
B	4 后端 Tracking (WandB/TensorBoard/MLflow/Prometheus)	统一监控 - 不同团队用不同工具，统一扇出
B	Debug 工具	快速诊断 - dump rollout/replay reward/直接发 SGLang 请求

0x06 对比

我们把miles和Uni-Agent进行对比。

6.1 整体设计哲学差异

维度	Miles（基于 Slime）	Uni-Agent（基于 verl）
底座框架	Slime (Megatron + SGLang)	verl (FSDP/Megatron + vLLM/SGLang)
环境管理	不管理，推给外部（Harbor/HTTP/ 用户代码）	框架内管理（AgentEnv 生命周期：start()/run_action()/close()）
Agent Loop	用户完全自定义（async def my_agent）	verl 提供 AgentLoopBase 抽象类，Uni-Agent 实现 UniAgentLoop
Token 对齐	TITO（精确，预计算 + 验证，bit-exact）	启发式 boundary_tokens 推断 + rollout_cache 增量追加（best-effort）
Session 实现	独立 FastAPI 服务（Session Server）	进程内 rollout_cache（token/trajectory cache） + AgentEnv 保持环境状态
MoE 支持	核心目标（R3 路由重放 + FP8 统一 + TIS）	支持 MoE 训练（Expert Parallel），但无路由重放机制
配置层次	命令行参数（argparse，单层）	训练层 Hydra + Agent 层 YAML 文件 + 样本层 tools_kwargs runtime override

---

6.2 关键机制对比

机制	Miles 方案	Uni-Agent 方案	权衡
增量 Tokenization	TITO：全量预计算 → 运行时 prefix 校验 + autofix	rollout_cache 增量追加 + 基于 chat template 的 boundary_tokens 启发式推断	Miles 更精确但模板需适配；Uni-Agent 更通用但 best-effort
训推一致性	多级保证：Staleness>TIS>R3>True On-Policy；部分 recipe 用极小 clip_ratio（如 4e-4），另一些用标准值（0.2/0.28）；配合 staleness_threshold	Miles 解决根因；Uni-Agent 按场景选择保守或激进
并发控制	Semaphore（512×GPU） + FIRST_COMPLETED 调度	worker_concurrent = max(global_concurrent // num_workers, 1) + asyncio.Semaphore 类似思路	Miles 更细粒度
异常处理	3 个训练相关主态（COMPLETED/TRUNCATED/ABORTED） + 2 个扩展态（PENDING/FAILED） + filter	~11 种 exit_reason（token_limit/format_error/no_response/...） + 按 exit_reason 分类处理	Uni-Agent 更细粒度；Miles 更简洁
Partial Rollout	TRUNCATED status + 正常参与训练	显式 partial rollout + overlong_buffer_cfg（配置预留，当前标注 unused）	思路一致，实现形式不同
Reward	可插拔 RM（custom/remote/rule）	AbstractRewardSpec ABC + 环境内评估（如 reward 直接拿 AgentEnv 做容器内评测）	Miles 更灵活；Uni-Agent reward&env 耦合更紧密
Off-policy	过期回收 + TIS ratio 修正（MIS 通过钩子可接入）	async_training.staleness_threshold + mask_abnormal_exit_traj	都能检测，Miles 可修正而非仅丢弃

---

6.3 Miles 的优势

• R3 路由重放：MoE expert 路由记录 → 训练时精确重放；verl 支持 MoE 训练但无路由一致性保证
• True On-Policy 契约：FA3 对齐 + batch/TP 不变性 → bit-exact；verl 部分 recipe 用小 clip_ratio 缓解而非解决
• FP8 统一内核：推理训练同一 Triton cast → 消除精度差异；verl 依赖引擎默认精度
• Session Server 服务化：独立 FastAPI → 可跨进程 / 跨节点复用；Uni-Agent session 是进程内 rollout_cache + AgentEnv
• Chat Template 验证：编译期 loop.index 等 TITO 规范；Uni-Agent 的 boundary 探测不需要模板约束
• Miles Router 中间件：RadixTree 前缀复用 + Worker 健康检查；verl 用裸 SGLang/vLLM
• 插件系统：miles_plugins/ 支持 10+ 模型零改核心；verl 需 fork 或 monkey-patch

---

6.4 Uni-Agent 值得借鉴的设计

设计	Uni-Agent 做法	Miles 现状	可借鉴方向
细粒度异常分类	~11 种 exit_reason + 按类型分类处理	3 个主态 + 2 个扩展态 + filter	可考虑扩展 ABORTED 子类型
样本级配置	tools_kwargs 覆盖环境 /reward 参数（如 env.image, reward.*）	全局配置	可考虑 per-sample 配置覆盖
Timeout Budget	允许 N 次超时再终止（默认 budget=3）；无（超时即 ABORTED）	可增加容错次数
Terminal 健康检查	超时后 5 次 probe 探测沙箱存活（env.py:139-157）	由环境侧负责	可作为最佳实践推荐
Reward&Env 强耦合评估	reward 直接拿 AgentEnv 做容器内评测（如 swe_bench.py）	reward 与 env 解耦（通过 HTTP/custom-rm）	对于需要沙箱验证的场景可借鉴
Overlong Buffer	配置预留机制（overlong_buffer_cfg），设计意图为接近超长时施加 penalty	无（直接截断）	待 Uni-Agent 完整实现后可参考

---

0x07 Agentic RL 8 大关键维度

Agentic RL训练：从单一算法到系统协同 中提出，Agentic RL 需要从"算法"扩展为"系统闭环"，涵盖 8 个方面。我们用这个框架来衡量 miles 的成熟度：

#	维度	描述
1	环境与接口建模	定义 agent 能看 / 做什么、何时结束、如何验证
2	探索能力与多样性保持	维护可探索行为的 support，非增大采样噪声
3	算力分配与学习信号整理	预算投向最可能打开梯度的任务与状态
4	目标函数与策略优化	判断坏在哪，约束更新与控制漂移
5	Rollout 采样、异步并行与调度	调度策略本身就在改写训练分布
6	奖励、验证器与效率约束	reward 不只是答对，是怎样工作才算好
7	记忆、层级与并行 Agent	训练对象从 token policy 扩展到 operating policy
8	Infra 基础设施	不只承载算法，还在塑造效率、一致性和可扩展性
	总分

解读：

• Miles 强在 Infra(8) 和 Multi-Agent(7) ：生产级工程能力和系统协同
• Uni-Agent 强在 环境建模 (1) 和 奖励约束 (6) ：算法侧精细化设计
• 共同短板：探索策略 (2) 和 算力分配 (3) — 整个 Agentic RL 领域的开放问题

Miles 各维度具体情况：

1. 环境建模：Session Server OpenAI 接口；3 种终止状态；Harbor/HTTP/ 用户自定义 | 不管理 env 生命周期；无 env 抽象类
2. 探索多样性：KL loss 框架（low_var_kl，预留）；entropy_coef 参数；over_sampling 默认 coef=0 未启用；无 curiosity/curriculum
3. 算力分配：dynamic_filter 过滤无信号组；over-sampling 补偿；无优先级采样；无难度自适应
4. 目标函数：GRPO/DAPO；TIS 修正；True On-Policy；Staleness 过滤；Dr.GRPO 仅 stub
5. Rollout 调度：Semaphore（512×GPU）、FIRST_COMPLETED；全异步；over-sampling | 调度仍是 FIFO，无智能排序
6. 奖励约束：8+ 内置 RM；custom/remote；环境即 reward；无 overlong_penalty；无 timeout_budget
7. 多 Agent：内置 Solver/Rewriter/Selector；MrIX 外部框架；无层级 Agent；无跨 episode 记忆
8. Infra：P2P RDMA；RadixTree；R3；True On-Policy；FP8；mbridge；千卡级 —（最强维度）

---

0xFF 参考

本文使用 markdown.com.cn 排版