三层解耦：一次调用被拆成什么
Agentic RL 的推理链路里，一次模型调用不能只看成“输入文本、输出文本”。文章把这一层拆成三个独立对象：Agent 内部状态、协议请求、Token 序列。内部状态由 Harness 维护，协议请求是标准化接口，Token 序列才是模型真正接收的 ID。
多轮交互中，状态更新函数会引入上下文裁剪、压缩等变换。结果就是 session 历史即使只追加存储，也没法保证模型输入满足前缀关系。这个前提一旦不成立，后续训练样本的构造方式就必须改。
多轮 rollout 的前缀关系为何普遍失效
文章明确指出：多轮 rollout 的 Token 序列普遍不满足前缀关系。原因不复杂，Detokenization、输出解析、状态更新、协议转换、重编码，任何一个环节都可能改变 Token 切分，或者插入控制 Token。
这意味着线性合并相邻调用的训练样本需要满足严格条件。如果条件不满足，更稳妥的做法是把每次调用作为独立样本，或者通过 Prefix Tree 保持条件一致性。训练时精确复现条件序列，不是可选项，而是基本要求。
Gateway 采集：只记文本不够
黑盒 RL 采集环节，文章提出要部署协议兼容的 Serving Gateway。普通 API Gateway 只记录结构化消息或响应文本，无法恢复可靠的训练样本。Gateway 必须使用与推理服务一致的 tokenizer 和 chat template 生成 input_ids，或者由推理服务直接返回 Token ID 与生成概率。
同时还要标记 rollout ID、attempt ID 与模型版本。这样每条轨迹都能回溯到具体调用和具体版本，训练数据才具备可审计性。
评分、奖励、信用分配为什么要分开
训练数据流水线被设计成 Rollout → Group → Verifier → Reward → Credit Assignment → Sample 的分级结构。核心原则是三个阶段显式分离：Verifier 产出原始评分，Reward 模块按配置转换为训练奖励并保留映射，Credit Assignment 决定奖励如何作用于 rollout、call 或 token 级别。
这样拆分后，同一组原始结果可以复用于不同算法对比，也能明确区分环境评价与算法假设。文章强调，原始评分必须可审计，不同算法可以复用数据，而不是把评分和奖励变换混在一起。
样本追踪链路要保留哪些字段
样本构造需要保留完整追踪链路，具体包括：group_id、rollout_id、策略版本、mask 与概率。Trainer 边界检查要求每个生成 Token 可回溯调用与条件序列，每个 rollout 可回溯 group 与原始评分。
奖励变换配置要显式化，拆分合并不隐式改变权重。这样训练过程才能可复现、可审计。文章以 Pi、Claude Code、OpenClaw 为例，兼顾白盒与黑盒接入模式，给出生产级 Agentic RL 系统的结构化参考。
热门跟贴