作者：朱小霖
原文：https://zhuanlan.zhihu.com/p/2044533166694732929
毫无疑问，OpenClaw 和 Opus 一起撞开了 agent 时代。
slime 从一开始坚持的 server-based engine + custom rollout 设计，其实早已为这个方向留好了位置。但 agent 时代真正到来之后，我们也更清楚地意识到：一个 RL 训练框架不能只是“能跑 agent”，还需要在推理编排、长程训练、外部环境接入和工程维护方式上，为 agent 任务提供更系统的支持。
agent 时代不只意味着要支持更复杂的 RL 训练任务，也意味着要重新思考：在 AI 逐渐参与代码生产之后，一个训练框架应该如何保持清晰、克制和可维护。slime v0.3.0 就是在这些思考中应运而生的。
面向 Agent 的功能强化
我们应该如何去思考 agent 需要的功能呢？我想，一个训练框架最容易失控的时刻，往往不是功能太少，而是为了追一个新方向，把一整套临时方案直接糊到原有设计上，agent 训练尤其容易诱发这种问题。我们更倾向于反过来做：不把“支持 agent”当成一个巨大目标，而是把它拆成一组更底层的 infra task。就像斯诺克里不是一杆把红球堆全打散，而是用几杆把局面慢慢整理开。v0.3.0 的很多更新，本质上都是在做这样的事情。
RL 框架无外乎推理 + 训练，我们分开来说。
更细致的推理需求
Agent 带来了呈数量级增加的 token 消耗，也带来了对推理的更强需求，相信每家公司都把推理成本优化放在了重中之重。从 RL 框架的角度来说，我认为主要有 2 点需求：
- rollout 要足够快，能够承载长程、多轮、工具密集的 agent 任务；
- 推理配置要足够接近线上系统，让模型能通过 RL 框架从 pretrain / sft 训练链路自然过渡到真实部署形态。
两者叠加起来对 RL 框架的推理配置提出了更高的自由度要求。这也是 slime 一开始坚持单推理后端和参数透传设计的原因之一：我们无需手动注册推理框架日新月异的参数，唯一需要考虑的是在 pd 分离情况下的配置。
在 pd 分离中，由于 prefill 和 decode 的计算特性不同，两者的最优配置可能不一致，而 slime 曾经的配置方案只能提供一套参数。为此，我们扩展了 slime 的 sglang 配置方法，加入了基于 yaml 的多 server 配置，用户可以通过 --sglang-config 进行配置。
在设计参数的过程中，我们还考虑到了复杂 rm 系统，opd 多 teacher 等潜在需求，从而将 config 开放为可以注册多组不同模型，不同 router 的形式，把 slime 推理侧从“一套 server 参数”扩展成了“可组合的 server / router 拓扑”（详细文档见：SGLang Config: Advanced Engine Deployment）。
在这样的扩展下，我们可以较为轻松地适配 sglang 的任意配置，很多用户甚至拿 slime 作为 sglang 的多机启动器。这其实说明用户需要的不只是一个 RL 框架，而是一个能稳定拉起复杂推理拓扑的 infra 入口。在此背景下，我们进一步优化了 --debug-rollout-only：在只启动 SGLang 的模式下，不再引入训练侧 NCCL group 等额外资源占用，让 rollout-only / serving-only 场景更接近真实推理部署,让推理侧与训练侧更加干净地分离。
除去自由度上的扩展，我们发现在 agent 任务的另一个变化是：多轮交互和工具调用会显著增加 prefill 压力，prefix cache / HiCache 的命中率和容量开始直接影响 rollout 吞吐。
这让我们重新审视了训练侧对 host memory 的占用。为此，我们学习了 miles 团队的优化经验（radixark/miles#719），在训推一体任务中不再 offload fp32 的梯度与 bf16 的参数，省下 6 * param 的内存量，从而间接提升 agent 任务的 rollout 速度。
长程任务所需的训练特性
相较于推理侧 infra 感满满的适配，训练侧的变化则需要我们对算法的判断。
我们首先支持的是对 compact, subagent 等 harness 行为的训练适配，也就是由一条 prompt 会生成多条训练数据（后称一组数据）导致的变长训练 batch size 的问题。
过去，这类场景很容易迫使框架在两种不理想的方案中二选一：要么 trim 掉多出来的 sample，要么 padding 到固定 batch size。前者会浪费 rollout，后者会引入不必要的计算和显存压力。
v0.3.0 之后，slime 支持训练 batch size 随 rollout 结果自然变化：不需要丢弃 sample，也不需要为了凑 batch 额外 padding。对于 compact / subagent 产生的一组数据，slime 会在训练中保持合理的归一化方式，使其行为更接近“一个长 sample 被拆成多段”后的训练形式。
除去支持 compact 与 subagent 的训练，我们意识到长程任务可能会激起大家对 reward shaping 或者 value function 的探索，重拾 PPO 类算法方案。所以我们重构了 PPO 的实现，将 actor 和 critic 始终共卡，这样用户从 GRPO 切到 PPO 时，不需要因为额外引入 critic 再增加一套 GPU 资源。
同时，我们也支持 actor / critic 使用不同的 Megatron 配置，便于用户分别调整两侧的并行策略、学习率或其他训练参数（详细文档见：Megatron Config: Role-Based Training Overrides）。
此外，由于 agent 任务的 rollout 时间较长，越来越多的用户在选择异步训练，尤其是 fully async 的训练。因此，v0.3.0 把 fully async 从 example 级别的能力提升为主目录维护的正式功能。值得一提的是，目前的 fully async 接口和 partial rollout 的异步设置一致，这意味着用户不需要为训推一体和训推分离维护两套异步 rollout 逻辑，同一个接口可以覆盖 partial rollout 和 fully async 两类场景。
slime/agent：把常用 Agent 组件沉淀下来
从 slime 的使用角度看，我们仍然更推荐用户通过 custom rollout 接入自己的 agent harness。agent 任务的环境、工具、reward 和状态管理差异太大，框架不应该假设所有 harness 都长成同一种样子。也特别感谢 NVIDIA-NeMo/ProRL-Agent-Server 或者 Gen-Verse/OpenClaw-RL 等工作基于 slime 开展 agent RL 方向的探索。这些外部实践帮助我们更清楚地看到：哪些能力应该留给 custom rollout，哪些组件值得沉淀进框架本身。
但是在交流过程中，我们还是发现需要在 slime 中需要提供一些 agent 工作常用的工具组件，并且需要提供样例。所以在上述的训练和推理功能加强之外，我们在 slime 中加入了 slime/agent/ 目录，添加了如 trajectory 合并，openai/anthropic 请求劫持这样的功能。同时我们也加入了一个 coding agent rl 的例子：
这个例子展示了一条完整的 coding agent RL 链路：外部环境镜像负责提供真实任务环境，Claude Code 在环境中运行并通过 slime 内部的 SGLang endpoint 推理，Anthropic adapter 负责劫持和记录请求，最终再通过 patch 导出、环境重启和自动打分生成 reward，并将多段请求合并成可训练样本。
我们希望用这样的方式更好地体现 slime 在 agent 方面的能力，同时也会用样例来更好地测试与迭代 slime 的 agent 工具。希望这些补充能让大家更方便地用 slime 进行 agent RL。
Agent 辅助的项目维护
我认为在接下来的时代，代码项目会逐渐分成两类。
一类项目可以在每次新模型发布之后被快速重写，旧代码本身没有太多沉淀价值；另一类项目则更像 Postgres 一样，真正的价值来自长期积累下来的设计、边界条件、验证经验和用户信任。训练框架的验证需要巨量的金钱和时间，而 slime 作为一个经历过大量真实大规模训练验证的开源框架，有机会成为后者。因此，我们需要用非常谨慎的态度去思考 coding agent 应该如何参与日常维护。
在我看来，使用 coding agent 编程主要有 2 个主要的风险，
一个是代码的巨幅膨胀形成的个人注意力 DDoS：代码产量上去了，但维护者 review、理解和消化这些改动的能力没有同步提升，最终只能心有余而力不足。
另一个是人的参与感降低导致的 ownership 缺失：当开发者不再真正理解代码为什么这样设计，也不再把代码看作自己的作品，项目的架构质量就会在一次次“看起来能跑”的改动中慢慢劣化。
这两点都会严重损伤项目质量，也和 slime 轻量、简洁的代码风格相悖。因此，在核心组件的开发上，我们仍然会采用相对保守的方式，将 AI 视为讨论对象、review 辅助和局部编码工具。这样开发者仍然需要充分参与设计和实现，也能继续像过去一样认真思考架构，保证代码处在一种适合人理解、适合长期维护的状态。
另一方面，对于测试和可视化这样的内容，我们则可以通过 AI 来充分提升产量。过去几个月里，我们用这种方式构建了大量测试，尤其是补充了很多 CPU-only 单元测试，甚至通过在 CPU 环境中模拟部分 Megatron 行为来提升稳定性。我们希望通过这种方式，让 slime 不只是一个经历过大量大规模实战验证的框架，也能成为一个日常测试最为扎实的开源项目。
当然，随着 AI 能力的继续发展，我们和 agent 协作的方式也一定会继续变化。之后我们也会更多分享 slime 开发过程中关于 coding agent、测试构建和项目维护的实践经验。
转眼 slime 开源就快一年了。我们也从最开始一两个人维护的小项目，逐渐变成了一个小团队共同推进的开源框架。希望 v0.3.0 的这些变化，能让大家更方便地训练自己的 agent，也能让 slime 在接下来的版本里继续保持克制、清晰和可靠。
最后还是继续不要脸地求一个 star。如果 slime 帮到过你，或者你也认可这种开源训练框架的方向，欢迎点一下支持我们。每一个 star 都是我们继续坚持开源的重要动力。
以上。