Polar: Agentic RL on Any Harness at Scale

发表时间: 2026-05 · arXiv:2605.24220 (NVIDIA)

Binfeng Xu, Hao Zhang, Shaokun Zhang, Songyang Han, Mingjie Liu, Jian Hu, Shizhe Diao, Zhenghui Jin, Yunheng Zou, Michael Demoret, Jan Kautz, Yi Dong

速读

一句话结论 本文提出了一个名为 Polar 的智能体强化学习基础框架，它通过在模型 API 边界监听和重构交互轨迹，实现了在不修改任何底层代码的情况下对任意闭源或复杂智能体系统进行强化学习训练，并在真实编码任务中显著提升了基础模型的性能。

要解决什么问题 现有的智能体强化学习正从单步任务转向需要与代码库或操作系统持续交互的长时程场景，这类场景通常产生包含数十个交互步骤和数万个词元的轨迹。原有做法要求用户修改智能体或其运行环境（即 harness，指代包裹智能体运行的复杂软件系统）的代码，以适配特定的强化学习框架。这种做法卡在两个机制瓶颈上：首先，许多真实的 harness 是高度复杂、异构甚至闭源的，强行“打开黑盒”进行代码级集成不仅工程负担极重，而且破坏了原有的事件循环和工具格式化逻辑；其次，由于供应商 API 通常只返回文本或 JSON，而非推理后端所需的精确词元 ID 和对数概率，传统的转录本解码再编码过程会产生重分词漂移，导致训练信号无法准确附着在行为策略实际采样的词元上，从而丢失了强化学习中最关键的保真度。

怎么做的 核心思路是放弃与智能体 harness 的代码级集成，转而将智能体的 LLM API 流量作为强化学习的交互接口。因为所有智能体都必须通过 API 与模型通信，Polar 在智能体和推理服务器之间插入了模型 API 代理。该设计能绕开上述卡点，是因为它将 harness 视作黑盒，仅监听网络请求即可捕获提示词、采样词元、对数概率和响应，在外部重构训练轨迹。关键设计由三个部件构成。首先是“Rollout 即服务”的异步架构，网关内部将运行时初始化、智能体执行和运行后评估隔离在不同工作池中，使 CPU 密集型的环境准备不会阻塞受 GPU 限制的模型推理。其次是多供应商兼容的模型代理，负责将各类 API 请求统一转换为本地推理格式，记录词元级数据后，再将响应伪装成原供应商格式返回，确保执行路径不断。最后是词元级别忠实的轨迹重构模块。为解决长对话被碎片化的问题，其“前缀合并”策略会将满足严格前缀关系的请求拼接成链。对于相邻补全，若前一个提示词 $P_i$、采样响应 $R'_i$ 与下一个提示词 $P_{i+1}$ 满足 $P_{i+1} = P_i || R'_i || T_i$（$T_i$ 为智能体插入的中间上下文），则予以合并，合并后的轨迹响应为 $R'_1 || T_1 || \dots || R'_k$。为保证训练信号正确，Polar 引入了关键不变量：仅对真实采样的助手词元赋予真实对数概率且损失掩码设为 1，对规范化的中间部分赋予合成对数概率且掩码设为 0。

效果如何 实验在真实的软件工程任务基准 SWE-Gym 和 SWE-Bench Verified 上搭建。在线强化学习采用 Qwen3.5-4B 作为基础模型，结合 Slime 框架和 GRPO 算法；离线数据生成使用 Qwen3.5-122B-A10B 模型。对比基线体现为四种不同技术路线的真实编码 harness：代表不熟悉工具模式的 Codex、代表复杂编排的 Claude Code、代表模型已较好适应的 Qwen Code 以及 Pi。量化结果表明，Polar 在所有 harness 上均显著提升了基础模型性能，其中在 Codex 上的 pass@1 准确率从 3.8% 跃升至 26.4%，提升 22.6 个百分点；在 Pi 上从 34.2% 提升至 40.4%。在轨迹构建策略的消融实验中，前缀合并策略相比逐请求策略，将三个训练步骤的耗时从 189.5 分钟降至 35.2 分钟，实现 5.39 倍加速，并将 Rollout 阶段的 GPU 平均利用率从 20.4% 提升至 87.7%。作者也指出了逐请求策略的代价与失效场景：由于信誉分配存在噪声，将单个调用作为独立轨迹易导致“奖励黑客”现象，即短轨迹因碰巧获得全局奖励而产生虚假高分。此外，在离线数据生成任务中，Polar 处理了 1638 个实例，取得 30.8% 的总接受率，证明了其在分布式长时程任务中的扩展能力。

A1 主要贡献

核心问题与研究目标

用于语言智能体的强化学习（RL）正从简短的单步任务转向需要与外部环境（如代码库、网页浏览器、操作系统）进行持续交互的智能体（agentic）场景。这些场景通常会产生包含数十个交互步骤和数万个词元（token）的长时程轨迹。在这种转变中，训练目标本身——通常是一个复杂的软件系统，被称为“harness”——成为了一个核心的系统挑战。将这些复杂的、异构的、有时甚至是闭源的 harness 集成到传统的 RL 框架中非常困难，不仅集成负担重、灵活性差，而且常常导致重要训练信号的丢失。现有系统如 SkyRL-Agent、PRIME-RL、Agent Lightning 和 rLLM 等，虽然尝试降低集成成本，但仍要求用户修改其智能体或 harness 以适应 RL 框架。

鉴于这些问题，本文的核心研究问题是：我们能否在不“打开黑盒”的情况下，即不修改智能体 harness 或强迫其遵循特定 RL 框架的情况下，使用强化学习来训练智能体？

核心观察与创新思路

本文的关键观察是，尽管智能体的内部实现千差万别，但所有基于大型语言模型（LLM）的智能体都必须与模型进行通信。这个模型 API 边界提供了一个存在于智能体外部的通用接口。因此，本文提出不与智能体 harness 本身集成，而是通过监听智能体的 LLM API 调用来实施训练。通过捕获智能体的提示（prompt）、采样词元、对数概率和响应，并将它们转换为 RL 轨迹，可以将任何智能体 harness 视为一个可训练的“黑盒”。

基于此，本文提出了 Polar，一个智能体 RL 基础框架，它能够将任何智能体作为黑盒进行训练。Polar 的核心思想是将智能体的 LLM API 流量用作 RL 接口，通过模型 API 代理来监听和记录交互，从而在不改变 harness 的情况下重构出用于训练的轨迹。

主要贡献

• 基于代理的 harness rollout 与重构：提出一种新范式，使用智能体的 LLM API 载荷作为 RL rollout 接口，使得现有的 harness 无需任何内部代码修改即可直接作为 RL 环境。
• “Rollout即服务”架构以扩展 RL 基础设施：Polar 将任务提交、运行时设置、harness 执行、轨迹重构、评估和训练器回调等环节通过异步服务边界进行分离，从而能够与现代 RL 基础设施进行原生扩展。
• 词元级别忠实的轨迹重构：Polar 将原始模型请求转换为词元级别忠实的训练轨迹。它提供了保守的“逐请求”重构和用于高强度 rollout 的“前缀合并”策略，并保留了基于注册表的可扩展接口。
• 在真实世界编码 harness 上的端到端验证：通过在多种流行的软件工程任务 harness 上进行 RL 训练，并使用自定义编码 harness 进行离线 SFT 数据生成，验证了 Polar 的有效性。

A3 背景知识

本节内容对应论文的“Related Work”章节，对相关工作进行了定性比较。

2.1. 智能体 RL 系统

与 ProRL Agent 的比较：第一波 LLM RL 基础设施大多假设 rollout 生成是训练器拥有的一个 Python 函数，但这在多轮智能体中变得捉襟见肘。ProRL Agent【20, Prorl agent: Rollout-as-a-service for rl training of multi-turn llm agents, 2026a, https://arxiv.org/abs/2603.18815】为多轮智能 体 rollout 引入了服务边界，将沙箱设置、智能体执行和奖励计算与训练过程分离。Polar 继承了“rollout 应为一种服务”这一高层思想，但改变了集成契约。用户不再是在 rollout 服务内部实现一个智能体处理器，而是提供一个 harness 适配器来准备配置并启动原生可执行文件。然后，模型代理从外部观察该 harness。

与 SkyRL-Agent 的比较：SkyRL-Agent【4, Skyrl-agent: Efficient rl training for multi-turn llm agent, 2025, https://arxiv.org/abs/2511.16108】是一个用于高 效 RL 训练和评估多轮、长时程智能体的全栈系统。其优势在于，一旦任务被表示为其环境和智能体抽象，训练就会非常高效。Polar 是其补充：它针对的是更早期的系统问题，即如何运行一个预先存在的 harness，并保持其内部事件循环、工具格式化和上下文策略不变。

与 PRIME-RL 和 Slime 的比较：PRIME-RL【15, Prime-rl: Async rl training at scale, 2026, GitHub repository, https://github.com/PrimeIntellect-ai/prime-rl】专注于大规模异 步 RL，具有训练器-推理分离、陈旧策略步语义以及对验证器环境的支持。Slime【25, slime: An llm post-training framework for rl scaling, 2025, GitHub repository, https://github.com/THUDM/slime】类似地连接 了 Megatron 训练与 SGLang rollout 引擎，并暴露了可定制的数据生成接口。这些系统解决了流水线的策略优化和推理扩展方面的问题。Polar 不是一个替代训练器，而是一个 rollout 基底，可以为异步训练器提供来自比典型可验证奖励函数更重的 harness 的轨迹。

2.2. 低侵入式智能体工具化

与 Agent Lightning 和 rLLM 的比较：Agent Lightning【9, Agent lightning: Train any ai agents with reinforcement learning, 2025, https://arxiv.org/abs/2508.03680】提出了训练-智能体解耦架构和统一的数据接口，用于将智能体执行转换为可训练的转换。rLLM 【17, rllm: A framework for post-training language agents, 2025, GitHub repository, https://github.com/rllm-org/rllm】同样旨在以最少的代码更改来跨框架训练智能体。这两个系统都认识到研究人员不应为了训练而重写整个应用程序 。

Polar 的差异点：Polar 的不同之处在于选择了最小的集成点。对于许多编码和终端智能体而言，最可靠的接口不是 SDK 回调图，而是 harness 已经使用的供应商 API 端点。因此，网关代理成为了观察设备：它接受 Anthropic、OpenAI Chat、OpenAI Responses 和 Google 风格的请求；将它们转换为本地推理后端；并记录训练器所需的词元级字段。这种选择比通用的可观察性工具化更窄，但对于以命令行程序、包管理工具或二进制文件形式实现的 harness 来说，它非常健壮。

2.3. SWE 任务评估与基准

与 Harbor 的比较：Harbor【7, Harbor: A framework for evaluating and optimizing agents and models in container environments, 2026, GitHub repository, https://github.com/harbor-framework/harbor】在容器化环境中评 估 Claude Code、OpenHands 等智能体，并支持并行执行。这种“评估优先”的设计与 Polar 的“harness 原生”动机高度一致。区别在于模型边界和训练数据契约。Harbor 使用特定于供应商的配置启动每个 harness，不提供转换模型协议或调解 harness 模型流量的网关。因此，模型替换受限于原生 harness 和外部端点已支持的功能。而 Polar 在此边界放置了一个代理，因此同样风格的 harness 执行可以产生可直接被 RL 训练器使用的词元 ID、对数概率、损失掩码和奖励。

SWE-bench 和 SWE-Gym 的作用：SWE-bench【8, Swe-bench: Can language models resolve real-world github issues?, 2024, International Conference on Learning Representations, https://arxiv.org/abs/2310.06770】将解决真 实 GitHub 问题作为基准，需要代码库理解、编辑和可执行验证。SWE-Gym【13, Training software engineering agents and verifiers with swe-gym, 2024, https://arxiv.org/abs/2412.21139】通过提供训练环境、验证器和轨迹扩展了这一方向。这些工作负载是 对 rollout 基础设施的天然压力测试，因为它们结合了昂贵的运行时设置、稀疏的补丁级奖励、长尾的执行时间以及 harness 侧状态偏离干净评估器状态的多种可能性。

2.4. 词元保真度与重分词漂移

问题的核心：在智能体 RL 中，训练信号只有附着在行为策略采样的词元上才是正确的。这在智能体 harness 中很难实现，因为供应商 API 可能返回文本、工具调用 JSON 或流式事件，而不是推理后端使用的确切词元 ID 和对数概率。vLLM 和 Agent Lightning【1, No more retokenization drift: Returning token ids via the openai compatible api matters in agent rl., 2025, vLLM blog, https://blog.vllm.ai/2025/10/22/agent-lightning.html】的讨论强调，解码和重新编码一个转录本可能会产生与原始生成不同的词 元 ID。

Polar 的解决方案：Polar 遵循相同的词元保真度原则，但将其应用于任意的 harness rollout：生成的助手（assistant）词元从推理响应中复制，非生成的中间词元取自规范的提示分词，损失掩码仅将行为策略的词元标记为可训练。

A2 方法细节

本节详细阐述 Polar 的设计与实现，对应论文的“Polar”章节。我们旨在解决这样一类智能体 RL 任务：策略通过一个现有的 harness 而不是自定义的 rollout 循环来执行。任务从一个指令和一个运行时开始；harness 在使用工具、编辑文件、派生子智能体或管理上下文的同时调用模型端点。执行后，一个评估器会给出一个结果或轨迹级别的奖励。Rollout 系统必须将原生的模型交互保存为可供训练器使用的轨迹，包括：提示上下文、采样的助手词元、可选的行为策略对数概率、损失掩码、奖励和来源信息。

3.1. 架构

Polar 的核心组件：Polar 有两个核心组件：一个 rollout 服务器和多个网关节点。Rollout 服务负责协调任务和全局调度。网关节点执行会话、托管模型代理、构建轨迹并运行评估。这种划分将持久的任务管理与每个会话的执行和捕获分离开来。

Rollout 服务器：Rollout 服务接受一个 TaskRequest 并将其扩展为 num_samples 个独立的会话。会话是调度的基本单位，它包含会话 ID、任务 ID、超时预算、运行时规范、智能体规范、轨迹构建器、评估器和回调 URL。该服务将会话分派到网关节点，持久化存储精简的终端结果，通过轮询暴露任务状态，并在会话完成时接受网关的回调。

网关节点：网关节点负责每个会话的生命周期。它启动运行时、准备 harness、运行 harness 命令、从捕获的补全中构建轨迹、评估输出、拆除资源并返回结果。同一个网关还托管 harness 用于模型调用的代理端点。这种同地部署将补全捕获与会话注册表绑定，避免了独立的轨迹收集服务。

与训练框架的解耦：训练框架独立于 Polar 服务器。服务边界原生支持大规模高效的异步 RL。图 5a 展示了与 Slime 结合的一个例子：一个后台工作进程提交 Polar 任务，接收任务完成回调，将轨迹转换为 Slime 的 Sample 对象，并应用轨迹感知的奖励后处理。

3.2. Harness 与代理捕获

通过代理进行观察：Polar 通过将其模型调用路由到网关代理来观察原生 harness。通过 harness 通常的环境变量或配置文件，将其模型基础 URL 指向网关。

代理处理流程：对于每个传入的模型请求，网关执行四个步骤：
1. 检测供应商 API：使用请求路径和头部信息来区分 Anthropic Messages、OpenAI Chat Completions、OpenAI Responses 和 Google generateContent 风格的调用。
2. 规范化请求：一个供应商转换器将角色、内容部分、工具定义、工具选择、停止控制和生成参数转换为本地推理服务器所使用的 OpenAI Chat Completions 格式。转换器还会添加训练所需的字段，如 logprobs=true。
3. 捕获词元级数据：网关将规范化后的请求转发给推理服务器，并存储一个补全记录，其中包含请求消息、响应消息、提示词元 ID、采样的响应词元 ID、结束原因以及来自推理后端的对数概率。
4. 返回供应商格式：响应被转换回 harness 所期望的模式。对于流式请求，我们的实现会获取一个非流式的上游响应，并生成一个合成的、符合供应商格式的流。这在简化词元忠实捕获的同时，保持了与期望服务器发送事件（SSE）的 harness 的兼容性。

代理边界的设计：代理边界被有意地设计在智能体框架之下。它不需要理解 harness 如何规划、管理工具或决定何时停止。它只需要保持 API 兼容性，并记录足够的信息来重构训练样本。

3.2.1. Harness 适配器

适配器的轻量化设计：Polar 中的 harness 适配器在设计上非常小。它可能安装配置、注册 MCP 服务器或技能、写入供应商设置，并返回运行智能体的 shell 命令。一个通用的 shell 命令 harness 可用于包装智能体执行。我们还集成了流行的智能体 harness 作为快捷方式，如 claude_code、codex、gemini_cli、qwen_code、opencode 和 pi。

3.2.2. 运行时接口

通用接口与后端支持：运行时实现了一个用于启动、停止、执行、上传、下载和取消的通用接口。我们的首个版本支持用于 HPC 设置的 Docker 和无根的 Apptainer。由于网关代码仅依赖于运行时接口，任务可以无缝地更换隔离后端。

3.3. 异步 Rollout 分段

解决混合成本问题：长时程的 harness rollout 混合了多种不同的成本：运行时启动、依赖准备、harness 执行、评估器设置、测试执行、补丁应用和拆除。Polar 通过在每个网关内部进行阶段隔离的执行，防止这些成本相互阻塞（如图 3 所示）。

3.3.1. 节点内工作池

工作池的分工：每个网关为 INIT、RUNNING 和 POSTRUN 使用隔离的工作池，外加一个有界限的 READY 缓冲区。
- INIT：启动运行时并执行准备操作。
- READY：保存已初始化的运行时，直到有可用的运行槽位。
- RUNNING：执行 harness。
- POSTRUN：构建轨迹、运行评估器、执行运行后钩子、发送回调并拆除资源。
就绪缓冲区允许 CPU 密集型的运行时准备在后台进行，而不会阻塞受 GPU 限制的智能体执行。

3.3.2. 评估器预热与超时

后台准备与部分轨迹恢复：当评估器请求一个干净的运行时，网关会在智能体运行期间开始准备该运行时。每个会话也带有一个共享的截止时间；如果一个 harness 在模型调用被捕获后超时，网关仍然会进入 post-run 阶段，以便可以恢复带有终端超时状态的部分轨迹。

3.4. 轨迹重构

接口与策略：轨迹构建器接口将一个有序的 CompletionSession 转换为一个 Trajectory。CompletionSession 是为一个 harness 会话存储的、由代理捕获的模型调用序列。Trajectory 包含一个或多个 Trace 对象，每个对象都包含提示词元 ID、响应词元 ID、损失掩码、提示消息、响应消息、工具定义、对数概率、奖励和元数据。可以无缝地向注册表中添加自定义的轨迹策略，我们提供了两种策略：逐请求（per request）和前缀合并（prefix merging），如图 4 所示。

3.4.1. 逐请求（Per Request）

保守的基线策略：per_request 构建器是保守的基线，如图 4 左下角所示：每个补全都成为一个轨迹。这对于单个调用是无损的，但它可能将一个连贯的多轮智能体会话 fragmented 成许多短样本。对于复杂的编码 harness，解决一个编码问题可能会产生数百个这样的轨迹，这增加了下游训练器的负担。

3.4.2. 词元忠实的前缀合并

重构长轨迹的策略：prefix_merging 构建器在 harness 会话的某些部分保留仅追加的对话历史时，会重构更长的轨迹，如图 4 右下角所示。它不假设整个会话是单个对话。相反，对于一个包含补全 $C_1, \dots, C_N$ 的会话，其中补全 $C_i$ 具有提示词元序列 $P_i$、原始采样响应词元序列 $R'i$、响应对数概率 $\ell_$ 以及提示/响应消息 $M_i$，Polar 将这些补全划分为有序的链：

其中 $t_{C_1} < t_{C_2} < \dots < t_{C_k}$。一个新的补全只有在规范化的消息级分组键将其识别为候选延续，并且与该链中最后一个提示满足严格的词元前缀关系时，才能加入现有链。对于一个链内相邻的补全 $C_i$ 和 $C_{i+1}$，这个检查是：

因此，子智能体、并行的智能体分支、上下文压缩、提示重写或独立的工具中介对话会自然地形成额外的链，而不是被强制合并到一个全局轨迹中。

链内合并过程：合并随后独立地应用于每个链。考虑一个链 $C = (C_1, \dots, C_k)$，并记 $P_i = P_{C_i}$，$R'i = R'$，以及 $\ell_{R'_i} = \ell_{R'_{C_i}}$。主要挑战是 $P$ 包含了前一个助手轮次的规范化服务器渲染，以及在下一次生成提示之前由 harness 插入的中间上下文。前一个助手的主体不能从这个规范化渲染中复制，因为行为策略的词元是原始采样的词元 $R'_i$。设 EOT 表示回合结束词元 ID。对于链中两个相邻的补全，定义规范化尾部：

我们在 $P_{i+1}$ 中定位第一个 $P_i$。如果 $P_i$ 已经以 EOT 结尾，则中间部分 $T_i$ 是该 EOT 之后的后缀；否则 $T_i$ 从该 EOT 开始，这样助手轮次在下一个提示上下文之前仍然是闭合的。这个链所代表的词元序列是：

最终轨迹与损失掩码：因此，发出的轨迹每个链包含一个轨迹 $Tr(C)$，其中第一个提示 $P_1$ 作为轨迹提示存储，剩余的后缀 $R'_1 || T_1 || \dots || R'_k$ 作为轨迹响应存储。显式的损失掩码在从采样响应 $R'_i$ 复制的词元上为 1，在从规范化中间部分 $T_i$ 复制的词元上为 0。真实的响应对数概率条目被复制用于 $R'_i$ 的词元。中间部分的位置会收到合成的对数概率条目，以使 response_logprobs 与 response_ids 保持对齐；可训练性由 loss_mask 控制。

正确性不变式：这种构造在每个发出的轨迹中给出了一个简单的正确性不变式：

<blockquote>

每个可训练的词元都与 rollout 期间的行为策略相匹配，任何非生成的词元都被掩码掉。

</blockquote>

图 5b 比较了上述两种策略在相同配置下的 GPU 利用率。

图5：Polar 提高了 rollout-训练边界的 GPU 利用率。(a) 展示了由 Polar 服务启用的异步 RL 流水线。Rollout 服务器使用现有策略持续进行推理，而训练器仅在收到足够批量的已评估轨迹组后才进行步骤更新。(b) 展示了在相同工作负载和拓扑下 3 个训练步骤的时间跨度，前缀合并比逐请求重构发出更少的训练器更新，并显著加速了训练过程。

3.5. 评估与奖励传播

评估器机制：评估器是基于注册表的自定义策略，在轨迹构建之后运行。它们接收轨迹、会话产物，以及可选的刷新后的运行时上下文。内置的评估器包括会话完成奖励、可配置的基于输出的测试评估器，以及一个 SWE-Bench/SWE-Gym harness 评估器。

奖励传播方式：结果奖励可以广播到每个轨迹，而带有过程奖励的任务可能需要逐轨迹分配。评估器注册表允许直接扩展到自定义的基于规则的验证、智能体即裁判（agent-as-judge）评分和特定于任务的奖励塑造。

A4 实验环境

• 数据集：

  • 在线 RL：使用 SWE-Gym 的 SkyRL-v0-293-data 数据集的训练部分进行策略优化，使用 SWE-Bench Verified【8, Swe-bench: Can language models resolve real-world github issues?, 2024, International Conference on Learning Representations, https://arxiv.org/abs/2310.06770】进行评估 。
  • 离线数据生成：使用来自七个 SWE-Gym 代码库的 1,638 个实例。

• 模型架构：

  • 在线 RL：Qwen3.5-4B 作为基础模型。
  • 离线数据生成：Qwen3.5-122B-A10B，配置为 TP=8，max_model_len=32,768。

• 硬件配置：

  • 离线数据生成：单个 8xH100 SGLang 服务作业。
  • 在线 RL：训练超参数见附录表4，具体GPU型号未详述。

• 软件配置：

  • Harnesses：

    • 在线 RL：Codex, Claude Code, Qwen Code, Pi。
    • 离线数据生成：pi-coding-agent v0.67.68。

  • RL 框架：Slime，使用 GRPO 算法。

  • 基础设施：Polar。
  • 运行时：Docker 和 Apptainer（基于 SWE-Gym 参考镜像，并添加 Node.js 22）。
  • 推理引擎：SGLang（用于离线数据生成）。

A4 实验结果

4.1. 在编码 Harness 上的 SWE-Gym GRPO 训练

实验内容：
使用 Polar 和 Slime，从同一个 Qwen3.5-4B 基础模型检查点开始，对四种不同的编码 harness（Codex, Claude Code, Qwen Code, Pi）进行标准的 GRPO 训练。训练使用 SWE-Gym 数据集，评估在 SWE-Bench Verified 上进行。所有实验均使用 prefix_merging 策略重构轨迹。

实验结果：

• 训练过程奖励（图 6）：所有 harness 的训练奖励都显示出提升。

  • Codex：pass@1 奖励从训练初期的 9.5% 稳步上升到末期的 54.5%。
  • Claude Code：从 28.8% 上升到 67.0%。
  • Qwen Code：从 61.6% 上升到 66.0%，波动较大。
  • Pi：从 61.6% 提升到 76.2%。

• SWE-Bench Verified 评估结果（表 1）：Polar 在所有四种 harness 下都提升了基础模型的性能。

  • Codex：pass@1 从 3.8% 提升到 26.4%（+22.6 个点）。
  • Claude Code：从 29.8% 提升到 34.6%（+4.8 个点）。
  • Qwen Code：从 34.6% 提升到 35.2%（+0.6 个点）。
  • Pi：从 34.2% 提升到 40.4%（+6.2 个点）。

分析结论：

• Polar 能够为模型不熟悉的 harness（如 Codex）带来巨大的适应性增益，因为它将奖励直接与原生执行路径中采样的词元关联起来。
• 即使对于模型已经较好适应的 harness（如 Qwen Code），harness 原生的 RL 训练仍然能带来性能提升。

图6：SWE-Gym GRPO 训练曲线。每个面板显示了四种被评估的编码 harness 之一的每步结果奖励，相当于 rollout pass@1。RL 提高了所有 harness 的奖励，在涉及复杂提示、编排或不熟悉工具模式的执行路径上，增益尤为明显。

表1：SWE-Bench Verified 评估。所有行都从相同的 Qwen3.5-4B 基础模型开始，并在列出的 harness 上进行训练。分数是在完整基准测试上的 pass@1，在相应的 harness 上运行。

轨迹构建器消融实验：
- 实验内容：在相同配置下，仅改变轨迹构建策略，比较 per_request 和 prefix_merging。
- 实验结果（图 5b）：在三个训练步骤内，prefix_merging 策略将训练器更新数量从 1,185 次（逐请求）减少到 218 次（合并轨迹），总耗时从 189.5 分钟降至 35.2 分钟（5.39倍加速）。Rollout GPU 的平均利用率也从 20.4% 提升到 87.7%。
- 分析结论：per_request 策略由于信誉分配噪声问题，可能导致“奖励黑客”（reward hacking）现象，即轨迹因获得与自身贡献不符的会话级奖励而看似表现良好。prefix_merging 显著提高了训练效率和资源利用率。

4.2. 离线数据生成

实验内容：
将 Polar 用于分布式离线数据生成服务。使用固定的 Qwen3.5-122B-A10B 模型和 pi harness，在 1,638 个 SWE-Gym 实例上生成 SFT（监督微调）轨迹。每个任务在独立的容器化环境中运行，超时设置为 3600 秒。

实验结果：
- 数据产出：在 1,638 次尝试中，成功生成了 504 个“可接受”的轨迹（即通过了所有 FAIL_TO_PASS 和 PASS_TO_PASS 测试），总接受率为 30.8%，总成本约为 64 GPU 小时。
- 接受率分析（表 2）：不同代码库的接受率差异很大，从低于 20% 到超过 50% 不等，这与任务难度相关。
- 数据特征：生成的轨迹很长，平均每个会话有 104 条消息和 51 个助手轮次。
- 数据发布：该语料库已作为 HuggingFace 数据集以 Apache-2.0 许可证发布。

表2：使用 Polar、Qwen3.5-122B-A10B 和 pi harness 在 SWE-Gym 上生成的 SFT 数据的各代码库接受率。“Accepted”意味着智能体的补丁通过了 SWE-Bench 评估器中的 FAIL_TO_PASS 和 PASS_TO_PASS 测试。

分析结论：
- Polar 的核心原语（如会话级容器隔离、自动重试、网关调度）使其能被有效地改造为分布式离线数据生成服务。
- 该部署可以轻松扩展，用于更丰富的离线数据生成流程，如拒绝采样、验证器训练数据生成等，而无需更改编排代码。

A5 结论

Polar 将智能体在测试时的环境（harness）视为 RL 系统的一等公民，而非需要被移植到训练器中的实现细节。其核心设计选择是将集成边界移至模型端点：harness 正常运行，代理（proxy）观察词元级的模型流量，而 rollout 服务将完成的执行转化为可训练的轨迹和奖励。这种分离使得 rollout 能够独立于训练和推理进行扩展，同时保留了非标准 harness 的行为，这些 harness 的价值往往在于其工程细节。我们相信 Polar 为在现代扩展智能体 RL 基础设施开辟了一种新范式，并且我们正在积极开发和维护该框架，以适应生态系统的发展。

A6 附录

A.1. 框架对比

表3：对比 rollout 系统设计选择。我们发现现代 rollout 基础设施应满足以下标准：async RL support 意味着训练可以在生成继续的同时消费 rollout，并处理显式的策略版本或陈旧性；async rollout staging 意味着 rollout 执行被分解为独立调度的运行时准备、执行、后处理（重构/评估）和清理阶段；rollout as service 意味着一个持久的任务 API，可与特定的训练器循环分离；native-harness agnosticism 意味着 CLI、SDK 或应用程序 harness 可以在不被重写为框架环境的情况下进行训练。✓ 表示一流支持，● 表示部分或计划支持，✗ 表示我们在参考的代码或文档中未发现该属性作为主要设计契约。

对部分支持（●）的解释：
- SkyRL【4, Skyrl-agent: Efficient rl training for multi-turn llm agent, 2025, https://arxiv.org/abs/2511.16108】暴露了自定义生成器 和 Harbor 集成，但原生 harness 并非其默认的 rollout 单元。
- Agent Lightning【9, Agent lightning: Train any ai agents with reinforcement learning, 2025, https://arxiv.org/abs/2508.03680】提供了一 个 rollout 存储、队列和运行器控制平面，并进行了广泛的框架工具化，但其主要边界是轨迹/工作流的可观察性，而不是对不透明 harness 进程的分段执行。
- rLLM【17, rllm: A framework for post-training language agents, 2025, GitHub repository, https://github.com/rllm-org/rllm】包括完全异步的训练和捕获词 元 ID 及对数概率的模型网关，但其 rollout 服务抽象比分布式运行时生命周期服务要窄。
- OpenClaw-RL【12, Openclaw-rl: Scalable rl in real-world agentic settings, 2026, https://arxiv.org/abs/2603.10165】为真实世界的智能体设置解耦了服务 、rollout 收集、评判和训练；其支持是围绕 OpenClaw 和特定的终端、GUI、SWE 及工具调用配方组织的，而不是任意的原生 harness 提交。

A.2. SWE-Gym GRPO 超参数

表4：SWE-Gym GRPO 实验的训练超参数。该表报告了来自 examples/swegym_slime_grpo 的常规策略优化和 rollout 参数；集群拓扑和工作进程放置被省略。

A.3. 代表性任务载荷

以下是一个代表性的 Polar 任务载荷 JSON 示例，展示了如何定义一个在 Docker 环境中运行 codex harness 的任务，并使用 swebench_harness 进行评估。

{
    "task_id": "polar-swegym-{rollout_id}-{group_index}",
    "instruction": "Fix the issue in /polar/session/workspace.",
    "num_samples": 8,
    "timeout_seconds": 1200,
    "runtime": {
        "backend": "docker",
        "image": "{sample.metadata.runtime_image}",
        "network": "host",
        "workdir": "/polar/session/workspace",
        "prepare": [
            {
                "type": "exec",
                "command": "prepare repository, harness, and dependencies"
            }
        ]
    },
    "agent": {
        "harness": "codex",
        "model_name": "{served_model_name}"
    },
    "builder": {
        "strategy": "prefix_merging"
    },
    "evaluator": {
        "strategy": "swebench_harness",
        "refresh_runtime": true,
        "config": {
            "repo_dir": "/testbed",
            "patch_command": "cd /polar/session/workspace && git add -A && git diff --cached --binary",
            "instance": "{sample.metadata.instance}"
        }
    },
    "callback_url": "http://{trainer_host}:{callback_port}/callback/task_result",
    "metadata": {
        "group_id": "{rollout_group_id}",
        "policy_version": "{policy_version}",
        "rollout_step": "{rollout_step}"
    }
}

A.4. 代表性轨迹

以下是一个由 Polar 生成并发送给训练器的代表性 Trace 对象片段，其中包含了词元 ID、对数概率、损失掩码、消息内容和奖励等关键信息。

{
    "prompt_ids": [151644, 872, 198, 48348, ...],
    "response_ids": [91, 10042, 151645],
    "loss_mask": [1.0, 1.0, 0.0],
    "response_logprobs": [
        {"token": "git", "token_id": 91, "logprob": -0.12},
        {"token": " patch", "token_id": 10042, "logprob": -0.44},
        {"token_id": 151645, "logprob": 0.0}
    ],
    "prompt_messages": [
        {"role": "system", "content": "agent harness system prompt"},
        {"role": "user", "content": "task instruction and current tool state"}
    ],
    "response_messages": [
        {"role": "assistant", "content": "sampled assistant turn"}
    ],
    "tools": null,
    "finish_reason": "stop",
    "reward": 1.0,
    "metadata": {
        "session_id": "session-123",
        "task_id": "polar-swegym-0001",
        "builder": "prefix_merging",
        "harness": "codex"
    }
}

A.5. 服务 API 摘要

Rollout 服务 API：Rollout 服务暴露了一个小型的异步 API：
- POST /rollout/task/submit：提交一个非阻塞的任务请求。
- GET /rollout/task/{task_id}：轮询任务状态、部分结果和最终结果。
- GET /rollout/status：检查任务状态、节点状态和待处理的会话。
- POST /callbacks/session_result：接收网关会话回调。
- POST /nodes/register 和 POST /nodes/{node_id}/heartbeat：维护网关成员关系和调度指标。

网关 API：网关暴露了一个用于会话创建、状态查询和删除的控制接口，以及一个用于处理供应商风格模型请求的 catch-all 代理接口。会话删除被 rollout 流水线用作在持久化终端结果后的尽力而为的清理操作。