训练前沿知识工作代理：使用SkyRL的397B强化学习训练指南（18分钟阅读）

# 训练前沿知识工作代理：一份使用SkyRL的397B强化学习训练指南 来源：https://www.mercor.com/blog/training-frontier-knowledge-work-agents-a-397b-rl-training-guide-with-skyrl/ *我们如何对Qwen3.5-397B-A17B进行后训练的详细步骤：重点关注通常被忽视的基础设施和风险排除工作，展示更大模型的更强改进，并发布完整训练脚本。* 这是我们使用Mercor专家数据进行开源模型后训练系列的第三篇文章。一月，我们展示了不到1,000个专家标注任务（https://www.mercor.com/blog/expert-data-drives-model-performance/）能够几乎将一个开源模型在APEX-Agent基准上的分数提升近一倍。二月，我们将数据集扩展到约2,000个案例（https://www.mercor.com/blog/scaling-data-apex-agents/）。由此产生的模型，Applied Compute: Small，从GLM-4.7 355B后训练而来，在公司法领域取得第一名，总排名第四。这两次运行均使用了专有的强化学习技术栈。本文公开了这套方法：我们在公开的SkyRL框架上复现了这些成果，将其扩展到397B参数模型，并发布了完整训练脚本、模型权重和评估轨迹。 开源社区在如何训练具有竞争力的编程代理[1,2]方面取得了真实进展，参数规模在27B至32B之间。关于知识工作代理的公开研究则少得多，因为构建真实环境成本高昂，且长期任务轨迹的训练开销巨大。我们通过使用强化学习（RL）对Qwen3.6-35B-A3B进行后训练来解决这一空白，使其在APEX-Agent基准[3]上超越了Opus 4.5，该基准包含480个真实的知识工作任务。随后，我们将最佳方案扩展到Qwen3.5-397B-A17B，使Pass@1指标相对提升了70%，从16.11%提高到27.29%。该脚本设计用于在专有数据上运行，但我们详细记录了完整的任务格式，以便您将其指向自己的数据集。 ***图1：*** *在1,928个专家创建的APEX-Agent现成任务上进行后训练前后，在保留的APEX-Agent基准测试中的Pass@1得分。* ***图2：*** *按领域划分的收益。较深的条形图是后训练后的**`-Mercor`**模型。35B模型在公司法领域提升最大；397B模型在管理咨询领域提升最大。* 我们取每次运行的最终检查点，将其称为`Qwen3.5-397B-A17B-Mercor`和`Qwen3.6-35B-A3B-Mercor`。在这篇博文中，我们将逐步指导如何针对复杂知识工作进行前沿强化学习训练，包括我们发现的最佳实践和学到的经验。完整的训练源代码、模型权重和评估轨迹可在以下位置找到： - github.com/Mercor-Intelligence/ApexAgents-SkyRL-Recipe (https://github.com/Mercor-Intelligence/ApexAgents-SkyRL-Recipe) - huggingface.co/collections/mercor/apexagents-skyrl-recipe (https://huggingface.co/collections/mercor/apexagents-skyrl-recipe) 本博文的组织结构如下： - 背景：APEX-Agent基准与我们的训练设置 - 步骤1：环境、工具框架与Token核算 - 步骤2：强化学习系统调优 - 步骤3：过拟合运行 - 步骤4：在35B模型上的算法消融研究 - 步骤5：397B模型的主演运行 - 步骤6：评估与泛化 - 经验与展望 步骤1至3是风险排除工作。直到步骤4我们才投入大量计算资源。 ## 背景：APEX-Agent基准与我们的训练设置 APEX-Agent（https://www.mercor.com/blog/introducing-apex-agents/）是Mercor针对专业服务领域长周期跨应用任务的前沿基准。与仅包含提示的任务不同，每个任务都存在于一个特定环境中：一个模拟公司，拥有数十份PDF、电子表格、幻灯片，以及聊天和电子邮件服务器。许多任务共享同一个环境。代理通过MCP工具或代码执行来工作。480个基准任务及其所有文件均在Hugging Face上公开，您可以在排行榜上阅读一个示例投资银行任务（https://www.mercor.com/apex/apex-agents-leaderboard/investment-banking-analyst-agent/#sample-task）。 我们专注于不使用监督微调（SFT）热启动的强化学习，因为强化学习是后训练中最难掌握的部分。我们使用SkyRL（由伯克利Sky Computing实验室与Anyscale合作构建），原因有三：它易于集成任意代理工具框架，支持完全异步训练，且其兼容Tinker的训练循环允许我们更换计算后端。 我们使用APEX-Agent现成（OTS）数据集来锚定研究：包含管理咨询、投资银行和公司法领域的1,928个专家创建任务。它们的结构与公开基准相同，但没有任何环境或提示出现在基准中，因此不存在数据污染。 ## 步骤1：环境、工具框架与Token核算 在进行任何强化学习之前，必须正确设置环境和工具框架。这意味着三件事：健壮的环境基础设施（失败的轨迹会浪费GPU时间并导致奖励偏差）、正确的工具框架（框架的怪异行为会教会模型绕开*你的工具框架*，浪费本应用于任务探索的预算），以及精确的Token核算。 ### 1.0 运行位置（计算资源与代码） 我们使用Harbor来处理数据格式和轨迹生成生命周期管理。Harbor来自Terminal-Bench背后的团队：它在容器环境中评估和优化代理，跨Modal和Daytona等沙箱提供商并行运行试验，并为强化学习生成轨迹。在此之上，我们实现了自己的`BaseAgent`（代码在此处：https://github.com/Mercor-Intelligence/ApexAgents-SkyRL-Recipe/blob/main/apex_agents_skyrl_recipe/agents/archipelago.py），等效于Mercor的archipelago循环代理（https://github.com/Mercor-Intelligence/archipelago/tree/main/agents/runner/agents/loop_agent）。 Mercor OTS数据交付将每个环境作为`image.tar`传递，我们将其推送到ECR；在试验时，Modal拉取该镜像以启动沙箱。镜像包含环境的文件系统并运行操作它的MCP服务器（文档、PDF、电子邮件、聊天）。代理循环连接到沙箱的MCP服务器，并将它们的工具暴露给大语言模型。在我们的设置中，代理循环运行在GPU节点上；它同样可以运行在环境沙箱内、单独的容器中，或Ray集群中的其他CPU节点上。 ***图3：*** *一次强化学习试验的运行位置示意图。****左：****训练数据是一个HuggingFace数据集，包含预构建的Harbor任务目录（提示、配置、验证器），每个试验消耗一个任务目录。****中：****在Ray GPU集群上，SkyRL提供完全异步的训练循环、vLLM引擎和飞行中的NCCL权重同步；每个试验作为自己的Ray任务运行，其中Harbor的**`Trial`**驱动轨迹生成生命周期（环境启动 → agent.run() → 验证 → 清理），围绕我们的**`ArchipelagoAgent`**，它与引擎交换原始token ID。****右：****每个试验获得一个从其环境的ECR镜像启动的Modal沙箱，通过环境的文件系统暴露MCP服务器；代理完成后，Harbor在沙箱内运行验证器，奖励与轨迹一起流回训练器。* 代码仓库（https://github.com/Mercor-Intelligence/ApexAgents-SkyRL-Recipe）故意保持精简：SkyRL和Harbor是通过pip安装的依赖，无需fork，您编写的代码只是少量文件。 ``` ApexAgents-SkyRL-Recipe/ ├── apex_agents_skyrl_recipe/ │ ├── entrypoints/ │ │ └── main_tito_harbor_fully_async.py # 入口：将我们的配置连接到 │ │ # SkyRL的完全异步训练器 │ ├── tito_harbor_generator.py # 您编写的唯一SkyRL代码片段： │ │ # 实现GeneratorInterface，通过harbor的Trial │ │ # 将每次试验作为Ray任务运行 │ ├── agents/ │ │ └── archipelago.py # MCP工具调用代理，harbor的BaseAgent子类； │ │ # agents/目录下的其余文件是其辅助程序 │ │ # (例如 TITO 记账) │ └── harbor_trial_config/ │ └── archipelago_tito.yaml # 代理+试验配置：超时、重试、 │ # 沙箱设置 └── scripts/ # 包含我们在步骤2和4中调整的 # 所有SkyRL训练旋钮的启动脚本 ``` ### 1.1 环境基础设施的健壮性 一旦确定了运行位置，任务就是降低环境故障并保持GPU忙碌。这在很大程度上是一个“打地鼠”的过程，但为让您有个概念： - **为所有操作设置超时。**文件下载、MCP交互、容器清理。任何没有超时的操作最终都会挂起整个轨迹的端到端预算。 - **绕过LLM判官速率限制。**评估通过会生成适量的判官流量，但800+并发轨迹的强化学习会严重撞击速率限制。必要时跨判官API密钥进行轮询，并按指数退避重试，如`agents/llm.py`所示（https://github.com/Mercor-Intelligence/ApexAgents-SkyRL-Recipe/blob/main/apex_agents_skyrl_recipe/agents/llm.py）。 - **为每个进程隔离MCP客户端。**在数百个代理循环之间共享一个Python进程会导致MCP不断断开连接，使环境成为不必要的瓶颈。我们将每个代理循环作为自己的Ray任务运行。 - **对所有剩余错误进行分类，**判断是“试验失败”还是“可重试”。基于Harbor构建的好处之一是，其中许多容错机制已经存在（在`harbor-framework/harbor`中搜索`@retry`）；我们在此基础上添加的补丁位于`agents/archipelago.py`（https://github.com/Mercor-Intelligence/ApexAgents-SkyRL-Recipe/blob/main/apex_agents_skyrl_recipe/agents/archipelago.py），我们匹配的失败特征位于`metrics_helper.py`（https://github.com/Mercor-Intelligence/ApexAgents-SkyRL-Recipe/blob/main/apex_agents_skyrl_recipe/metrics_helper.py）。 **建议：**在您预期强化学习期间的并发度（对我们来说是300-600个轨迹）下，对您的完整训练集运行一次评估通过，并在训练前将非模型错误率降至尽可能接近零。步骤2涵盖了我们如何选择这个上限。不要过度依赖“在强化学习期间屏蔽错误”。 ### 1.2 优化工具框架 基础设施稳定后，查看工具框架本身。用未训练的模型运行一次评估通过，然后分析轨迹：有多少失败反映了真实的模型局限性，有多少来自工具框架的怪异行为或彻底的错误？在强化学习之前最小化后者，这样训练才能教导真实的能力，而非变通方法。这些问题只有通过阅读轨迹才能发现。这是一项缓慢的手动工作，但编程代理能很好地自动化它：让它们系统地分析轨迹，并使用诸如每个工具的失败率等指标来寻找模式。我们通过这种方式发现的问题包括： - 一些Python包最初在沙箱中缺失，导致代理花费大量轮次来发现实际安装了什么，或者回退到有时不太符合人体工程学的MCP服务器。 - PowerPoint MCP工具即使在成功时也对每次调用返回`None`。我们在`slides_output_validation_fix.py`（https://github.com/Mercor-Intelligence/ApexAgents-SkyRL-Recipe/blob/main/apex_agents_skyrl_recipe/agents/slides_output_validation_fix.py）中修补了MCP工具的实现。 - PDF阅读器MCP工具将二维布局扁平化为一维文本，导致多列表格混乱。我们引导模型使用Python包`pdfplumber`来代替。 对工具框架的这些修改也有帮助： - 当代理接近耗尽上下文预算时，引导模型总结收尾。 - 当工具调用解析失败时，提示模型重试，而不是直接让轨迹失败。 - 将工具结果截断到固定的token/字符预算，防止单次调用耗尽上下文。 这些修复共同将基础模型Qwen3.6-35B-A3B的平均奖励从22.74%提升到28.69%，无需任何训练。这些修复带来的提升大致相当于在未修复的工具框架上进行一个训练周期所能带来的提升。所有工具框架调整都在已发布的代码库中。 ### 1.3 Token输入Token输出（TITO） 最后，通过确保TITO（即上文提到的精确Token核算）使工具框架对强化学习友好。 **什么是TITO？**一些文章已经讨论了为什么这对强化学习很重要[4, 5]。简而言之：当将推理引擎的输出转换为训练器的输入时，我们绝对不能重新对引擎的文本输出进行分词，这会导致两种错位：（1）大语言模型实际生成的内容与训练器*认为*它生成的内容之间；（2）在多轮设置中，第N轮输出的token ID与后续轮次输入的token ID之间。 假设词汇表中有四个token：`0: <`、`1: search`、`2: `。如果大语言模型生成`0, 1, 3`，而我们直接将字符串``交给训练器，没有记录token信息，它可能会重新分词为`2, 3`，这种无声的错位会使训练偏离策略。 **如何实现TITO？**大致有三种选择： 1. 重写工具框架以使用`/completions`而不是字符串输入字符串输出的`/chat/completions`。控制力最强，工程工作量最大。 2. 让`/chat/completions`返回输入和输出的token ID（例如vLLM的`return_token_ids`）。工作量低，但它不能解决错位（2），因此每个轨迹会分裂成多个训练序列，损害系统性能。 3. 由强化学习框架提供一个代理，将`/chat/completions`转换为`/completions`并在内部跟踪token。最方便，代价是某些隐含性（例如，在工具框架侧的重试方面）。这即将在SkyRL中实现（issue：https://github.com/NovaSky-AI/SkyRL/issues/1959）。 我们采用了第一种方法；实现细节在`agents/tito.py`中（https://github.com/Mercor-Intelligence/ApexAgents-SkyRL-Recipe/blob/main/apex_agents_skyrl_recipe/agents/tito.py）。 ## 步骤2：强化学习系统调优 环境和工具框架确定后，我们转向强化学习技术栈本身。对于长周期代理强化学习，默认设置是完全异步训练并使用飞行中的权重更新，以最小化掉队者的影响[6, 7]。我们使用vLLM作为推理引擎，Megatron作为训练后端，并按以下顺序进行调优。 **1. 优化Megatron旋钮。**花一个通宵的Claude代码会话，使用一个虚拟脚本（https://github.com/NovaSky-AI/SkyRL/tree/main/examples/train_scripts/full_context）来优化Megatron的速度，调整： - 并行度（TP/EP/PP/CP） - CPU卸载粒度 - 微批次大小（`max_tokens_per_microbatch`）。我们使用动态微批次，这对训练器吞吐量至关重要。 **2. 在轨迹生成和训练之间划分集群。**我们采用的经验法则是：根据您的计算资源固定训练GPU的数量，然后分配尽可能多的轨迹生成GPU，以使训练器不等待。在SkyRL中，这体现在`timing/wait_for_generation_buffer`面板上，0表示训练器从不等待生成，因此始终忙碌。我们的推理与训练节点比例对于35B运行是12:4，对于397B运行是12:8。 **3. 设置轨迹生成并发度。**轨迹生成并发度（在代码仓库中为`generator.rate_limit.max_concurrency`）有两个上限；将其设置为两者中较低的一个。 - *系统*上限，通常是长周期任务的瓶颈，是KV缓存：总KV缓存容量（以token计）除以平均轨迹长度。可以通过CPU KV缓存卸载或更高的并行度（TP / PP / EP）来提高它。 - *算法*上限是您在完全异步训练中的过期容忍度，` (max_staleness_steps + 1) × mini_batch_size × n_samples_per_prompt` 条轨迹，对我们来说是`(3 + 1) × 16 × 16 = 1024`。超过此数量，额外的轨迹对训练器来说过于陈旧而无法接受。 系统上限在我们的两次运行中都是决定性因素：我们将35B的并发度设为550，397B设为300，远低于1024。 **4. 检查训练与推理不匹配。**配置设置好后，运行几个训练步骤，比较训练器和推理引擎之间的logprobs。正是通过这个检查，我们发现了vLLM CPU卸载、GDN模型和飞行中权重更新组合中的正确性问题。我们的差异在没有轨迹路由器重放的情况下保持很小。 ***图4：*** *训练器与推理引擎之间的平均logprob差异……*