从一份脚本到一组服务：Agentic RL 系统的架构抉择

上一篇详解拆的是两台机器的内部：推理引擎与训练引擎怎么分工，weight sync 桥上埋着哪些坑。本篇往上抬一层（L12 p.28-41）：这两台机器，加上环境与奖励、权重同步，再加上形形色色的 agent harness，该怎么组织成一个系统？

讲义给这一节划的主线，是从「一份脚本跑全部」到「一组服务谈协议」。这一节不怎么谈算法，谈的是系统组织，代价照样真金白银。

组织选错，换一个 harness 就要重写一遍工程。8 张 H100 和 4 张 Mi350，挂不进同一个训练。模型上了生产线，却回不了训练循环。

一、先解 harness 这道题

agentic RL 相对传统 RLHF，最大的新增变量是 harness 这层 agent 框架 / 脚手架的多样性：Codex、Claude Code、OpenHands、Pi、Hermes、Prime Agent…… 每家的 rollout 逻辑与环境交互方式都不同（L12 p.29）。

讲义点名的反模式，是为每个 harness 手写一套 rollout 与环境代码。看着直接，实则 harness 一升级就得追着改，研究精力全赔在胶水上。

Agent Lightning（微软，2025）的正解叫 harness 无关，harness-agnostic。做法是起一个 middleman 代理服务，把 Chat Completions、Responses、Anthropic 这些推理 API 原样模拟出来。

harness 以为自己在直连推理服务，实际每个请求都先过代理。代理一边转发，一边把 logprobs、r3 等训练要用的细节落进 rollout store（L12 p.29）。

于是换 harness 从一次工程重写，降级为一次配置切换。「Train ANY AI Agents with RL」这句口号的全部底气就在这儿。

二、SPMD 直控，还是一组服务谈协议

讲义 L12 p.30-33 给出组织光谱的两端。一端是 SPMD，全称 Single Program Multiple Data，单程序多数据：一份 Python 在所有 rank 上跑，用进程组分工。

# SPMD 示意（L12 p.30）：一份程序、两个进程组
train_pg = dist.new_group(ranks=[0, 1, 2, 3])   # 训练引擎
infer_pg = dist.new_group(ranks=[4, 5, 6, 7])   # 推理引擎
# 训练 rank：更新完异步把新权重发过去
publish_weights_async(dst=infer_pg)
# 推理 rank：采样轨迹，权重到了就刷新
refresh_weights_if_ready()

好处是直控一切：训练、推理、同步都在同一个进程空间里，没有跨服务开销。代价是不灵活：换引擎、加节点、改拓扑都得动这份主程序，讲义 L12 p.30 把它对应到 AReaL <1.0 时代。

另一端是一切皆服务（everything-as-a-service）加单控制器：沿服务边界切开系统，边界即 API。

六类服务各就各位（L12 p.31-33）：

• Agent 服务：跑 harness。
• 环境 / 奖励服务：对齐 Open Reward Standard。
• 编排器：CPU 上的训练循环。
• 训练服务：如 Tinker 的 training API。
• 推理服务：SGLang/vLLM 的 API。
• 权重同步服务：可托管也可自建，托管如 OpenReward。

换来三层好处：

• 关注点分离：编排器只是轻量 CPU 程序，研究者试新算法不必背上训练 / 推理引擎的重依赖。
• 模块化：协议一致即可整组换实现。
• 独立发版：各组件升级互不绑架。

对照系里，HybridFlow/veRL（EuroSys 2025）的单控制器 + 混合编程，与 OpenRLHF 的 Ray 解耦，在这两端之间各占一个站位。

三、服务化买到的四张票

第一张，弹性扩容。rollout 是长尾负载，忙闲不均。服务化后，推理能力以 API 面目出现，动态加推理控制器或节点即可临时提速。多集群的异构算力也能挂上同一个编排器：讲义的示例是 8×H100 与 4×Mi350 同场训练（L12 p.34-36）。

第二张，控制面再进化。AstraFlow（Haizhong Zheng et al.，2026）用数据流取代以 trainer 为中心的控制：训练逻辑写成算子与数据依赖，原生支持多 agent RL 与多策略协同训练（L12 p.37）。仓库开在 Infini-AI-Lab/astraflow。

第三张，多策略与在线 RL。微服务架构便于同时训多个模型：异构策略的多 agent rollout 各走各的服务（L12 p.38）。

更进一步是部署后在线 RL。Cursor 的生产实践里，Composer 每 5 小时就能从真实用户交互产出新 checkpoint；Cursor Tab 同在其在线 RL 产品线 (L12 p.39; 出处 AReaL 2.0, 2026)。RL 不再是训完再部署：部署之后，训练还在继续。

第四张，多租户多 LoRA。8 个 LoRA run 并发跑，总吞吐优于 8 个串行，代价是单个 run 的端到端时间变长。

每个并发 run 对应训练服务里的一个 “用户”，推理侧需要 Grouped-GEMM/SGMV 这类特殊内核，把多个 LoRA 的矩阵运算拼进同一批（SkyRL+Trajectory Labs，2026；L12 p.40）。

多租户 LoRA serving 的奠基工作，要回溯到 2023 年的 Punica。把多租户多 LoRA 的 RL 训练和解耦训练服务走通的先驱是 Tinker：每个 run 一个 training client，每个 LoRA checkpoint 一个 sampling client（L12 p.41）。

四、天平为什么倒向服务化

辩论主线贯穿 L12 p.28-41：SPMD 性能直控 vs 服务化灵活解耦。传统 RLHF 里这道题好答，一个模型、一种环境、一桶同构 GPU，SPMD 的直控最划算。

agentic RL 把这些前提逐条拆掉：

• harness 多样，见第一节
• 算力异构，见弹性扩容
• 策略不止一个，见多策略与多租户
• 模型常驻生产线，见在线 RL

这四个变量都在给单文件主程序加分支，服务化恰好逐个接得住。所以这一讲的落点不是服务化必然更快，而是边界画对、性能用内核与网络补、灵活性拿复利。p.42 预告的下一讲 Sandboxing and Credential Management，讲的就是其中一条边界上的安全代价。

与本讲的连接

本篇下钻 6b 伴读的架构视角。伴读给出脚本→服务的主线与六类服务边界，本篇补上锚点与四张票：

• harness 无关与 middleman 代理：L12 p.29
• SPMD 与进程组伪代码：p.30
• 服务边界与三层好处：p.31-33
• 弹性与异构集群：p.34-36
• AstraFlow：p.37
• 多策略：p.38
• Cursor 在线 RL：p.39
• 多租户多 LoRA：p.40
• Tinker：p.41
• 下一讲预告：p.42

跨篇看，《双引擎解剖》讲两台机器内部，五段分解、weight sync 两个暗坑；本篇讲机房怎么盖。那篇的两条通道，在本篇升格为权重同步服务与 rollout store：前者是六类服务之一，后者是贯穿其间的数据通道（L12 p.29）。

留一个行动项：读任何 RL 系统的架构图，先圈出服务边界。隔着一条 API 的两个框，问三个问题：换 harness 要改几行代码？加一台机器要不要停训？能不能再挂一个策略？三问答完，翻回 p.34-36 对答案：8×H100 和 4×Mi350，挂在同一个编排器下。