NLP——Data-Recipes-OpenThoughts-Agent

注：本文包含 AI 辅助创作

参考链接：
- 原始论文：(OT-Agent)OpenThoughts-Agent: Data Recipes for Agentic Models, 20260623, UC Berkeley & Stanford
- OpenThoughts 官方开源网站：openthoughts.ai 发布了训练集，数据 Pipeline 和模型等

Paper Summary

整体总结：
- 背景：
  - 公开讨论 Agent 筛选训练数据的工作较少
  - 现有的开源工作，如 SWE-Smith、SERA 和 Nemotron-Terminal，通常针对单一基准
- 本文介绍了一个六阶段 SFT Data Pipeline（完全开源 + 面向多个领域 Agentic 模型）
  - 进行了详细的消融实验（拿了许多认知）
    - Insight：任务来源和多样性很重要性
  - 针对 Agentic RL 数据也做了针对性研究
  - 由此产生的数据集 OpenThoughts-Agent-v2 （100K 数据）
- 在 Qwen3-32B 上，基于这个数据微调模型
  - 输出模型： OpenThinker-Agent-32B
  - 七个 Agentic 基准的平均值上最强的开源数据 <= 32B 模型（Qwen3 家族或更早）
    - 比现有的最强开源数据 Agentic 模型 (Nemotron-Terminal-32B, $40.9\%$) 提高了 3.9 个百分点
- 在 8B 规模上，将 SFT 数据与的 pymethods2test RL 数据集相结合，进一步优于最强的现有 <= 8B 的 Baseline
  - 认知：表明 Agentic 后训练的 SFT 和 RL 阶段可以被设计为组合使用
- 问题：
  - RL 研究仅在 8B 下进行（未测试 32B）
  - 所有 SFT 运行都从 Qwen3 家族开始（没有其他模型家族）
  - 最大的训练集包含 100K Trajectory（数量其实不太够）

Introduction and Discussion

公开文献中关于如何训练最先进的 Agentic 模型的信息很少，尤其是在训练数据方面
- DeepSeekV4 模型权重开源，详细介绍了架构和训练过程，但训练数据部分只有两段
在开源领域已有初步的为 Agent 筛选训练数据的工作： SWE-Smith (2024)、SERA (2026)、Mentron-Terminal (2026) 和 OpenSWE (2026) 等
- 但这些工作通常一次只关注一个基准，例如 SWE-Bench (2024) 或 Terminal-Bench (2026)
对于开源 AI 研究而言，目前很难理解如何训练和改进 Broadly Capable Agentic 模型
OpenThoughts-Agent (OTAgent) 关注 Agentic 模型的训练数据
- 借鉴先前 OpenThoughts 工作 (2025) 的 Insight，专注于 SFT 的后训练数据，目标是在多个 Agentic 基准上提高模型的性能
- 全面的 Agentic SFT 数据筛选 Pipeline ，并对其进行了 100 多次消融实验
实验关键发现：
- 与 Reasoning 数据一样，Instructions 的选择是数据 Pipeline 中最重要的因素之一
- 在基准测试中表现最强的模型不一定是最好的教师
- 过滤训练数据，保留具有更多模型轮次 (turns) 的执行轨迹 (execution traces) 可以改进最终的训练集
- 在最大规模的训练实验中，重复使用最顶级的几个来源会导致收益递减
  - 因此本文作者扩展了数据源集合以增加多样性
实验结果：
- 基于实验汇集了一个用于微调 Agentic 模型的顶尖训练集
- 使用来自 Pipeline 的 100K 个数据点微调了 Qwen3-32B 模型，并在广泛的 Agentic 任务套件上，与使用 Qwen3 或更早的基础模型且规模 $\leq 32$B 的其他开源数据模型相比，取得了最佳性能（见表 1）
  - 在 SWE-Bench Verified 上达到 $54.0\%$，在 Terminal-Bench 2.0 上达到 $26.2\%$
    - 注：Mentron-Terminal32B 分别为 $41.9\%$ 和 $25.1\%$
  - 其他 Agentic 基准测试（包括 Aider Polyglot (2024)、BFCL-Parity (2025)、GAIA-127 (2023) 和 FinanceAgent-Terminal (2025)）上也优于先前的工作
表 1:
- 训练时未使用的 OOD 基准上也表现出了良好的泛化能力
  - 注：In-domain (ID) 和 Out-of-Distribution (OOD) 在这里指的不是“训练集是否泄露了测试集数据”，而是指任务的形式和技能领域是否匹配
- 同时在 Terminus-2 和模型原始评估框架 (harness) 中评估每个模型，并为每个模型报告两个框架下的最高准确率
- 此表中的所有模型均由 Qwen3-32B 训练而来
图 1 显示
- 本文训练集不仅是因为规模大而表现良好
- 在计算资源固定的方式下，全面优于其他开源数据集
本文还研究了用于 RL 的数据筛选
- 本文简要记录了现有开源 RL 数据 Curation 工作（如可复现性、可用性和扩展性）的挑战，并引入了一个新的 RL 数据集
- 在两阶段（SFT + RL）中对一个 8B 模型进行后训练来验证这些数据的有效性
  - 最终该模型在 7 个 Agentic 基准测试的平均值上，优于最佳的单阶段 8B 模型，以及现有的最强 $\leq 8$B Baseline 模型（详情见表 10）

Data curation

Data curation 包括数据来源选择、数据标注/验证，有时还包括过滤 (2023; 2025)
针对 Agent 的数据筛选的严谨公开研究较少

Agents and their benchmarks

LLM 评估在过去五年中发展迅速；
- 从 GPT-3 等开创性模型主要报告 MMLU 等多选题基准（通过探测续写 Token 的对数概率来评估），社区迅速发展到直接评估生成式模型的开放式补全
随着 OpenAI 的 O 系列模型问世，专门的 Thinking 格式变得流行，并且开发了如 AIME（静态）以及 LiveBench 和 LiveCodeBench（动态）等专门基准来挑战思考模型

Agentic Models

进一步发展，SWE-Bench 和 Terminal-Bench 等基准为 GitHub 问题解决等离散任务分配分数 (2026; 2024)
在整个过程中，Evalchemy 和 Harbor 等标准化评估平台使基准测试更加经济实惠和可复现 (2025; 2026)
过去一年半里，随着 Agentic AI 进入研究主流，已经提出了各种数据筛选策略，用于 AI Agent 的有效后训练，涵盖 SFT 和 RL 数据筛选 (2025; 2026; 2026; 2026; 2026; 2026; 2026)
- 这些工作有两个关键局限：
  - 第一：它们几乎完全专注于 SFT 或 RL，很少关注这些步骤如何相互作用
  - 第二：它们倾向于关注单一基准或一小簇紧密相关的 Agentic 基准
本文工作侧重于跨 Agentic 基准的泛化、SFT 和 RL 之间的交互，涵盖了几种流行的模型规模，并利用了一系列 Agentic 基准，包括本工作中新增的 OpenThoughts-TB-Lite
注：最近的工作使用 Qwen-3.5 作为其实验的基础模型 (2026)
- 本文继续使用 Qwen-3 作为基础模型，以便在整个项目中进行一致的比较
- 吐槽：这有点怪了，在 Qwen-3.5 上效果是不是提升不明显？
  - 理解：不是的，是其他的模型复现难度太高

Public frameworks for building agents

健全的工程实践是本工作的核心焦点（也是核心挑战）
SFT 框架是 Llama-Factory 的一个分支 (2024)
- 作者将其扩展以支持 ALST 长序列训练 (2025)
RL 框架是 SkyRL 框架 (2025) 的扩展版本
- 大部分改进已在 (2026) 中描述
作者使用 Harbor: A framework for evaluating and optimizing agents and models in container environments, 2026, Harbor Framework Team 进行环境、基准和 Harness 管理

SFT Data Pipeline

Pipeline

本文目标是为 SFT 编码和 Terminal Agent 创建最佳的（task，trajectory）对数据集
- 定义：最佳数据集是指能产生在下游基准测试中性能最高的 Agent 的数据集
本文独立地消融每个 Pipeline 步骤，并根据三个基准的平均 z-score 选择性能最佳的策略
- 计算每个候选策略准确率在该阶段全部候选集上的 z-score （减去该阶段每个基准的平均值，再除以其标准差），然后对得到的三个基准的 z-score 取平均
- 这种标准化方法使得每个基准在排名中具有相同的权重（候选集中的准确率范围不同）
详细 Pipeline 见 3.1-3.6
默认设定：
- 轨迹由 GLM-4.7-AWQ (2026) 作为 Teacher 在 Daytona 沙箱内的 terminus-2 Harness 中生成
- 注：使用规模为 10K 的数据集进行实验
  - 因为这个规模在成本上足够经济，同时又足够大，能提供有意义的信号

Training

对每个消融实验
- 使用完整的 Pipeline 为每种数据策略生成 10K 条轨迹
- 使用全参数 SFT 在每个数据集上微调 Qwen3-8B (2025)
- 学习率为 4e-5，使用 Cosine schedule，全局批大小为 96，训练 7 个 Epochs，上下文长度为 32K
每个 10K 条数据的微调在 GH200 上需要 160 GPU-小时，本文能够并行运行数十个 Pipeline 消融实验
- 这些实验为最终的 OpenThoughts-Agent Pipeline 设计提供了参考
- 附录 C 节中包含了关于超参数、训练基础设施和每个阶段 SFT 设置的更多细节

Evaluation Setup

在一个 Agent 基准集上评估模型，这些基准探索长周期软件工程和终端使用行为
核心套件由三个基准组成：
- （1）OpenThoughts-TBLite（100 个任务）(2026)：
  - 一个包含 100 个 Terminal-Bench 风格任务的集合，平衡了四个难度等级，并被设计为完整 Terminal-Bench 2.0 性能的快速 Proxy
- （2）SWE-Bench-Verified-100（100 个任务）(2024)：
  - 从 500 个任务的人类验证的 SWE-Bench Verified Split 中按仓库分层抽样的子集
  - Agent 针对一个 Python 仓库的固定 commit 生成一个 Patch，通过 Harness 给出 0-1 分数
- （3）Terminal Bench 2（89 个任务）(2026)：
  - 手工制作、人工验证的任务，涵盖软件工程 (SWE)、生物学、安全、系统管理和机器学习
所有评估均在隔离的 Daytona 沙箱 (2026) 中使用 terminus-2 (2026) Agent Harness 运行，每个任务进行 $n = 3$ 次随机重复运行，并报告跨试验的标准误差
为了衡量泛化能力， Pipeline 实验排除了一组保留的 OOD 基准
- 这些基准仅在 Pipeline 实验完成后才进行测量
- 这组保留基准包括 Aider Polyglot (2024)、BFCL (2025)、MedAgentBench (2025)、GAIA (2023) 和 FinanceAgent-Terminal (2025)
注：G 节包含有关评估基础设施和每个基准配置的更多详细信息

Sourcing Tasks

表 2: 任务来源选择在所有 Pipeline 阶段中具有最大的影响范围
- 问题解决任务和人工编写的基础设施问题占据主导地位，但改进在不同基准间呈现不均衡分布
- 完整排名见附录 A.1
由于 SFT Agentic 数据集由任务描述和 Agent 轨迹对组成
- 生成任务描述的策略 可能会使 SWE-Bench-Verified-100 的下游准确率产生高达 $30\text{pp}$ 的差异，在 Terminal-Bench 2.0 上产生 $10\text{pp}$ 的差异（表 12，排名 1 对比排名 95）
- 任务生成策略 的设计空间很大，包括合成任务生成、人工任务生成等
- 此外，任务生成策略所覆盖的领域知识和技能 也可能导致下游性能的巨大差异
为了高效地找到最佳的任务数据生成策略，对 95 种任务生成策略进行了消融实验，涵盖了不同的初始来源、生成模式（合成 vs. 非合成）以及这些任务的知识领域
- 表 2 中报告了研究结果
  - 表现最佳的任务生成策略包括合成问题解决任务（如 SWE-Smith 和本文的 IssueTasks 数据集）、人工编写的计算机使用问题（如 StackExchange SuperUser 和 Tezos）以及其他策略
  - 选择不同任务生成策略的影响导致下游评估结果存在巨大差异
    - TerminalBench 2.0 的得分范围从 $10.9\%$ 到 $0.4\%$
  - 观察：在顶级数据生成策略中，性能提升是不均衡的：
    - 顶级的编码相关数据集（如 SWE-Smith）大大提升了 SWE-Bench 的性能，而人工编写的基础设施问题（如 StackExchange SuperUser）则提升了 TerminalBench 2.0 的性能

Mixing Tasks

本文任务描述集将来自第 3.1 节任务生成策略的混合体
关于数据混合策略有丰富的文献，但本文仅根据第 3.1 节中每个任务生成策略的相对排名，消融了使用前 1、前 2 等数据集的混合情况
- 对于 Top-$N$ 混合策略，本文选取前 $N$ 个数据生成策略，并从每个策略中采样 $\frac{10K}{N}$ 个任务描述
- 理解：因为本文的实验数据量级就是 10K
混合策略的结果在表 3 中
- 混合前 4 或前 8 个任务生成策略的效果最好，并且优于未混合的 Top-1 Baseline ，因为它在所有基准上表现良好，而不仅仅是在 SWE-Bench 上
表 3: 混合排名靠前的任务生成策略，任务内随机打乱
- 混合前 4 到前 8 的策略产生最强的均衡性能，通过避免过度专业化，优于未混合的 top-1 Baseline

Task Augmentation Strategies

在初始生成任务描述之后，一个自然的假设是，通过阐明其要求或增加其难度来改进它们可以提高数据集质量
本文探索了不同的任务描述增强方法，例如使用 LLM 组合来自不同来源的任务、为每个任务添加新的约束、强化任务描述等
这些干预措施的结果在表 4 中
- 发现：所有干预措施都未能改善在生成后保持任务描述不变的 Baseline
表 4: 任务描述增强策略在噪声范围内
- 没有一种 LLM 驱动的增强策略能够可靠地优于未增强的 Baseline

Filtering Tasks

在确定了任务生成策略的最终组合后，从一组任务描述中 过滤掉质量差的任务可以提高下游性能
- 注：这里重复了 OpenThoughts 中的任务描述 Filter 集消融实验
表 5 中发现了类似的结果：
- 在测试的 Filter 中，LLM 任务描述 Filter 产生了最大的改进（平均 +3 pp，表 5）
- 将任务过滤到那些 GPT-5 需要更多 Token 来解决的任务，可以在所有基准测试中带来大约 3 个百分点的改进
表 5: 使用基于 LLM 的难度信号过滤任务描述可提高性能
- 选择 GPT-5 生成更长响应的任务，平均比随机选择提高了 $\sim 3\text{pp}$

Teacher Model

在选择了生成任务描述的方法集之后，对生成 Agentic Rollouts 的设计选择进行了消融实验
先前的工作表明，Teacher 的选择可以对下游评估产生显著影响 (2025)
- 基于这一认识，本文采用第 3.2 节中最佳的任务描述组合，并使用在 TerminalBench 2.0 上表现良好的不同教师生成数据集
- 包括 GPT-5.3-Codex、Kimi K2.5、GLM-4.6-AWQ、GLM 5，以及本文 Baseline GLM-4.7-AWQ
如表 6 所示
- 尽管 GPT-5.3-Codex 是表现最好的模型，但作为教师，它比 GLM-4.7-AWQ 更差，在 TerminalBench 2.0 上的性能下降了大约 $5\%$
- 最好的教师是 GLM 4.7（注：尽管它比 Kimi K2.5 更旧且性能更差（例如，在 Terminal Bench 上））
表 6: 教师模型消融：
- 更强的模型 $\neq$ 更好的教师
- 尽管 GPT-5.3-Codex 在这些基准上是最强的模型，但它是最弱的教师，在 Terminal-Bench 2.0 上比 GLM 4.7 AWQ 低了约 $\sim 5\text{pp}$

Filtering Agent Rollouts

过滤掉质量较低的 Agentic 轨迹是提高数据集质量的一种方法
本文应用了简单的启发式 Filter ，包括：
- 移除生成过程中达到超时的轨迹
- 移除子 Agent 轨迹
  - 问题：为什么可以移除子 Agent 轨迹，这里会带来问题吧
  - 回答：这里只是实验，并不是真的用这个策略了，最后验证有效的策略是移除轮次少于 5 次的轨迹数据
- 移除轮次少于 5 的轨迹
如表 7 所示：
- 产生更长 Agentic 轨迹的方法能带来更好的性能，过滤掉轮次少于 5 的轨迹在下游评估分数上产生了最大的改进
- 注：由于更长的轨迹也包含更多的 Token，在第 A.3 节中验证，在匹配的 Token 预算下，这种增益仍然存在，确认它源于更高质量的多轮监督，而不是额外的训练计算量
表 7: 过滤 Agent 轨迹：保留更长的轨迹有帮助
- 最少轮次 (minimum-turns) Filter 在所有三个基准上都优于 timeout 和 Subagent Filter

Scaling Up SFT Data

扩展数据集规模是提升下游性能的强大方法
在完成 Pipeline 消融实验后，最终 Pipeline 生成了一个包含 10K 数据点的数据集
为了增加数据集规模，可以采用几种简单的策略：
- 方法 1：使用相同的任务描述，为每个任务生成更多的 Agentic Rollout
  - 本文从方法 1 开始（因为它最简单）
- 方法 2：从原始来源中使用更多的任务描述
  - 方法 2 也是一个简单的修复方法，但受到初始来源的限制，例如，Tezos 仅包含 997 个 Unique 任务描述
- 方法 3：使用合成增强（Synthetic Augmentation）来创建新的任务描述
- 方法 4：使用更多的初始来源（即扩大 Top-N 的 N）
关于任务 4：
- 本文尝试在 100K 规模下从 Top-4、Top-8 和 Top-16 数据集中获取更多任务（方法 4 的结果见表 8）
- 在 Top-4 之外添加更多来源并不能可靠地帮助提升性能：
  - Top-8 在每项基准上并未显著优于 Top-4，扩展到 Top-16 则在每项基准上都有所下降
  - 理解：因为越往后的数据集，效果越差，加进来质量也不行
- 注：本文在其余实验中保留原始的 Top-4 来源混合，并不再进一步追求方法 4
- 表 8：在更大的数据规模下，任务来源的多样性影响可忽略不计
  - 在 Top-4 之外添加来源并不能可靠地提升性能
  - 所有行均为在 100K 行数据集上使用 $\geq 5$ 轮 Trace Filter 训练的 32B SFT 模型
关于任务 3：
- 本文针对专项合成任务增强（方法 3），并在图 3 中报告结果
- 具体方法：
  - 选取第 3.2 节中得分最高的四个来源（swe-smith、stackexchange-superuser、stackexchange-tezos 和 issue-tasks）
  - 用 Tezos 的合成增强版本替换其子集（将其替换为自身的合成增强版本）
    - 注：Tezos 提供的 Unique 任务描述最少（仅 997 个 Unique 任务）
  - 将第 3.3 节中的指令重写策略应用于相同的 997 个基础问题，将其不同的表面形式从约 902 个扩展到超过 21K，而无需引入任何新的底层问题
  - 使用第 3.4 节中的 gpt-5-nano 响应长度信号作为上采样权重 ，而不是作为硬性的 top-$k$ Filter
    - 每个 Unique 任务至少获得一次 Rollout，剩余容量按分数比例分配
  - 注：本文目标是在每个数据集规模上保持完整的任务覆盖
  - 然后，统一在所有四个来源上应用 $\geq 5$ 轮 Trace Filter
  - 结果：在更大的数据集规模上看到了持续的性能提升，这表明增强方法克服了方法 1 中观察到的有限任务描述多样性瓶颈
方法 1 vs 方法 3 的结果如图 3 所示
- 方法 1：从 31.6K 到 100K 性能趋于平稳（在 SWE-Bench Verified-100 上 +3pp，在 Terminal-Bench 2.0 上 −2pp；两者均在标准误差范围内）
  - 这表明任务描述的多样性是瓶颈
- 方法 3：三个基准上都在持续改进
- 图 3：合成增强（Synthetic Augmentation）的扩展效果超过了上采样（Upsampling）的平稳期
  - 两种方法都基于相同的 10K 基础数据，仅在超出该规模时产生差异
  - 方法 1（为每个任务描述上采样额外的 Rollout）从 31.6K 到 100K 趋于平稳
  - 方法 3（合成任务增强）在所有三个基准上持续改进
  - 注：误差条表示三次随机重复运行的标准误差

OpenThoughts-Agent-v2

在 100K 规模下，本文观察到 32B SFT 模型的最佳性能
- 在 Terminal-Bench 2.0 上达到 $26.2\%$
- 在 OT-TBLite 上达到 $41.3\%$
- 在 SWE-Bench Verified-100 上达到 $55.7\%$
- 从 31.6K 开始呈现单调提升
  - 在 SWE-Bench Verified-100 上增加了 $+7.7\text{pp}$
  - 在 Terminal-Bench 2.0 上增加了 $+5.0\text{pp}$
图 4 中报告了最终 100k 规模数据集 OpenThoughts-Agent-v2 的完整数据生成 Pipeline （OpenThoughts-Agent-v2 合成过程）
- 从最初的 4 个任务来源开始，包括合成的 GitHub Issues、人工编写的 Linux 任务和人工编写的加密货币问题
- 重复任务描述并对 Tezos 问题进行合成增强
- 使用 GLM-4.7-AWQ 生成 Agentic Rollout，并过滤掉少于 5 轮的 Trace

Reinforcement Learning

许多备受瞩目的 RL 数据集，包括 SWE-Smith 和 R2EGym (2025;2024)，都遵循了类似的方法：
- 选择一个具有代表性的 GitHub 仓库，其状态和依赖关系可以捕获在 Docker 容器中，选择或合成一个有缺陷的提交及失败的测试，并生成一个自然语言问题描述，描述该问题并要求 Agent 使失败的测试通过
本文将这些工作纳入一个更大规模、更系统的消融研究系列
- 类似于在 SFT 领域的工作，研究模型性能在多大程度上取决于 RL 训练数据的来源
- 为了隔离这一点，本文进行了一项受控的数据来源消融实验，如下所述

Experimental Details

为了控制计算消耗，将 RL 研究聚焦在 8B 规模
使用 RLOO 算法 (2024) 和标准的二元奖励（Binary Rewards）进行异步 RL，奖励基于验证器成功（预期 PASS：PASS，预期 FAIL：FAIL，适用于所有测试）
从一个蒸馏的 8B 检查点（OTAgent-ColdSFT）开始进行 RL，该检查点是在由 GLM 4.7 AWQ 教师生成的 SWE-Smith Trace 上训练的，该教师带有 Thinking 能力，本文也对其进行了训练
本文主要运行在 24 块 A100 80GB GPU 上进行，批次大小为 64，总挂钟时间约为 46 小时
- 有关更多技术细节和完整的超参数，请参考第 D 节

Sourcing Tasks in RL

在本文消融实验中，每次运行都使用相同的超参数和评估标准，唯一改变的是 Agent 训练所用的数据集
本文比较了 8 个任务（SWE-Smith 和 R2EGym 和六个来源），六个来源涵盖：
- 重新表述为 Python 合约的竞赛编程问题（pymethods2test）
- 真实仓库错误修复（inferredbugs）
- 竞赛编程环境（code-contests）
- LLM 过滤的 Nemotron code-oracle 混合（nemotron-code-oracle）
- LLM 验证的自由职业者任务集（llm-verifier-freelancer）
- 自然语言到 Bash 的任务（nl2bash）
评估条件与第 3 节所述相同
- 训练日志表明，所有来源在一定程度上都是可学习的
- inferredbugs 和 nemotron-code-oracle 运行在整个训练过程中显示出健康、单调上升的平均奖励（分别约为 $0.21 \rightarrow 0.46$ 和 $0.06 \rightarrow 0.36$，跨导出步骤）
- code-contests 在一个低得多的奖励上限处趋于平稳 $(0.06 \rightarrow 0.14)$

The data source matters，数据来源很重要

表 9 显示
- 来源消融实验的原始平均准确率跨度达到 7.6 个百分点，大于 2.0 个百分点的运行间可重复性方差（见表 20），但小于第 3 节所述的 SFT 来源消融实验产生的方差
- 数据来源强烈影响 Agentic RL 性能
- 在固定训练 Pipeline 、仅改变来源的八次 8B RL 运行中，性能差异远超噪声
最强的来源 pymethods2test 是 Codeforces/CodeChef/TopCoder 风格竞赛编程问题的混合体
- 这些问题被重新表述为单函数 Python Contracts，带有合成的文档字符串式任务描述和自动生成的单元测试套件
  - 不涉及多文件编辑、仓库导航、跨轮次的 Shell 状态累积
  - 涵盖的技能包括 1D/2D 动态规划、字符串和模式匹配（KMP）、组合数学、矩阵/网格构造、临时性谜题以及格式化表格/字符串生成
  - 参考解决方案平均约 20 行代码，任务描述约 200 个单词
- 该数据集具有高度可重复性（没有可能过时的 GitHub 引用）、高度可用性（所有任务使用相同的构建环境）并且具有清晰且在此情况下适当适中的难度上限
- 简洁但具有挑战性的源任务促使冷启动模型采用一致的问题解决模式
  - 理解：这里应该是是指解题 Pipeline 一致等，而不是不探索
- 在 RL 期间，它将思考和探索性（sed 和 grep）工具调用的循环替换为紧凑的探索、修补和提交策略
  - 理解：这里是说比较多的探索变成较少的探索，跟多修补和提交？
- 本文：将在第 F 节中进一步分析 pymethods2test 结果背后的涌现行为变化，以及为什么其 RL 信号比替代方案更能推动策略更积极地探索
在替代方案中
- 合成和竞赛编程来源（inferredbugs、code-contests）在 ID（In-domian）上领先
- 更多样化的工具使用来源（llm-verifier-freelancer、nl2bash）在 OOD 上具有竞争力（尽管 ID 得分较弱）
- 适度的 ID/OOD 解耦表明，强调单函数代码正确性的数据来源最清晰地转移到 SWE/Terminal 核心基准，而更广泛的工具使用数据以一定的 ID 成本换取了 OOD 泛化能力
  - 只有 pymethods2test 在这两方面都处于领先地位
- 注：In-domain (ID) 和 Out-of-Distribution (OOD) 在这里指的不是“训练集是否泄露了测试集数据”，而是指任务的形式和技能领域是否匹配

Results

表 10 中展示了完整的后训练 Pipeline （SFT + RL）在核心基准以及整个基准套件的平均值上均优于 Baseline ，平均比 Qwen3-8B 基础模型提高了 18 个百分点
- 每个单元格报告该模型在所有评估的 Agent Harness 中针对该基准达到的最高准确率 $(\%)$
- 平均值是此处报告的七个基准中各列评估单元格的均值（问题：怎么看着 RL 后没咋涨（第一列相对第二列））
“Undertrained（训练不足）”的 SFT 模型从 RL 中获益更多，并最终优于纯蒸馏模型和 RL-only 模型
- 与先前工作一致，本文在表 11 中发现，当 SFT 模型是考虑 RL 而选择的时，RL 提供的增益最大 (2025)
- 在 Agentic 基准测试中，在 Terminus-2 Harness 上表现不佳的 Qwen3-8B 模型无法从 Agentic RL 中受益
- 在较少数据上进行 SFT 的模型提供了更好的起点
表 11：在中等强度的 SFT 基础上进行 RL 优于其他策略
- SFT + RL 模型（1），从中等强度的 SFT 基础模型（3）开始，优于从较弱 SFT 基础模型（4）开始的 RL 以及 SFT-only（3）
- 每个单元格报告在 Terminus-2 Harness 中达到的最高准确率（%）
- 标准化 = 5 个条目中每个基准 z-score 的均值
问题：表 10 和表 11 中的分数为什么对不齐，比如 OT-Agent-ColdSFT+RL-8B 在 SWE-bench Verified 上的效果
- 表 10 展示完整后训练 Pipeline （SFT + RL）的最终实力，报告的是每个模型在其最佳配置下能达到的最高分，整合了多个 Harness 的结果，并取最大值
  - 这是为了公平地与其他论文报告的顶尖分数进行比较
- 表 11 是消融研究结果，作为一个控制变量实验，专门研究“SFT基座模型的质量”对 RL 训练效果的影响
  - 它严格保持 RL 算法和设置不变，只改变 RL 的起点（不同的 SFT 模型）
  - 为了确保对比的公平性和因果性，它严格限定所有模型都在完全相同的评估框架（Terminus-2 harness）下进行评估

附录 A：Full SFT Pipeline Ablation Tables

本节包含了第 3 节中总结的 SFT 管道实验的完整消融表
所有实验均遵循第 3 节中描述的设置：
- 每个数据集包含 10K 条轨迹
- 使用 Qwen3-8B 进行全参数 SFT 微调，并在每个基准测试上进行三次随机重复运行，标准误差以下标形式报告

A.1 Task Generation Strategies (Full Ranking)

表 12 和表 13 报告了表 2 中总结的所有 95 种任务生成策略的完整排名
策略按照三个基准测试上的归一化平均 $z$ 值进行排序
表 12 & 13：完整任务生成策略排名
- 每个基准测试单元格：原始准确率 $(\%)$
- 平均列显示原始平均值和归一化 $z$ 值平均值

A.2 Mixing Strategies (Full Results)

表 14：完整混合策略结果
- $N \in \{1,2,4,8,16,32\}$ ，从每个 Top-$N$ 源中采样 $10K / N$ 个任务
- 报告两种情况：在训练批次内随机打乱和顺序轮询
  - 理解：随机打乱和顺序轮询看起来差着一些，但不同方式下排名变化较大，更多感觉是因为本身分数差异就较小导致的排名波动
- 混合 Top-4 到 Top-8 策略在两种方式下都能产生最强的均衡性能
- 每个基准测试单元格：原始准确率 $(\%)$ 及其标准误差下标
  - 粗体值在列最大值的 1 个标准误差范围内

A.3 Filtering for Longer Episodes: A Compute-Controlled Ablation

第 3 节表明，保留具有更多模型轮数的执行轨迹可以提升训练集质量
由于较长（$\geq 5$ 轮）的轨迹在每个样本中也包含更多 Token，这种收益可能源于两个原因之一：
- 多轮监督的质量更高
- 仅仅是更大的训练计算量预算
在固定行数下，min-turns filter 相比未过滤的子集大约多出 $45\%$ 的 Token，因此这两种解释是混淆的，除非均衡 Token 预算
- 理解：min-turns filter 是指保留最长的轮次
本文构建了两个消耗相同 $\sim 145\text{M}$ Token 的训练集（表 15 报告了结果）：
- 第一个保留最长（$\geq 5$ 轮）的 Episode（9,859 行）
- 第二个从数据池中抽取随机子样本（14,470 行）
- 表 15：即使在匹配的 Token 预算下，min-turns filter 依然有效
  - 两个模型都是 Qwen3-8B 在子集上微调的，每个子集都被截断到相等的 $\sim 145\text{M}$ Token 预算
在 Token 预算固定的情况下，min-turns filter 仍然比随机对照组平均高出 $+3.5\text{pp}$
- 在 SWE-Bench Verified-100 上高出 $+5.4\text{pp}$
- 在 Terminal-Bench 2.0 上高出 $+3.8\text{pp}$
- OT-TBLite 在各基准测试的噪声范围内移动
结论：这种效果不能归因于额外的训练计算量，更长的 Episode 在多轮 Agentic 任务中确实能带来更高的准确率

附录 B：Scaling at 8B

本文 Pipeline 消融实验（第 3 节）使用 Qwen3-8B 作为基础模型
- 理解：第 3 节没有针对样本数量进行 Scaling up，对样本数量进行 Scaling up 是在第 4 节做的（而且是针对 32B Base 模型）
本节验证最终的 OpenThoughts-Agent 数据配方在 8B 模型规模上也能扩展（与图 1 中的 32B 趋势相呼应）
- 理解：这里相当于补全了在 8B 模型上的针对数据量的 Scaling Up
图 5 报告了当将 OpenThoughts-Agent-v2 数据集从 316 行扩展到 100K 行时，在 SWE-bench Verified-100 和 Terminal-Bench 2.0 上的准确率，同时与 Nemotron-Terminal-Corpus Baseline 和基础 Qwen3-8B 模型进行了对比
图 5：OpenThoughts-Agent 数据配方在 8B 规模上可扩展
- 在数据集规模上使用 OpenThoughts-Agent-v2 微调 Qwen3-8B 在 SWE-bench Verified-100 和 Terminal-Bench 2.0 上的准确率，与 Nemotron-Terminal-Corpus Baseline 和基础 Qwen3-8B 模型（虚线）对比
- OpenThoughts-Agent 在更大规模上领先，并在 100K 时在两个基准测试上都超过了 Baseline
- 误差条表示每个任务三次随机重复运行的标准误差
OpenThoughts-Agent 在大多数匹配的数据集规模下，在两个基准测试上都领先于 Nemotron-Terminal-Corpus Baseline
- 在 10K 行时，OpenThoughts-Agent 在 SWE-bench Verified-100 上达到了 $24.3\%$ 对比 $9.3\%$
- 与 32B 模型一样，性能在最大规模时继续提升而非趋于平稳：
  - 在 100K 行时，8B 模型在 SWE-bench Verified-100 上达到 $39.7\%$，在 Terminal-Bench 2.0 上达到 $10.9\%$（从 31.6K 时的 $26.3\%$ 和 $7.9\%$ 提升），在两个基准测试上都超过了 Nemotron-Terminal-Corpus Baseline （分别为 $34.3\%$ 和 $9.0\%$）
  - 这反映了在 32B 规模上合成任务增强的效果（第 4 节），即扩展任务描述的多样性克服了上采样的瓶颈

附录 C： SFT Hyperparameters

C.1 SFT training hyperparameters per data scale

Common to all 32B SFT runs
- 所有 32B 微调均从 Qwen/Qwen3-32B 开始，使用 qwen3（thinking）聊天模板，并共享以下优化设置
- 只有表 17 中的项目会随数据规模变化
Per-scale settings (32B)
- 随数据规模变化的两个消融旋钮是训练轮数和梯度裁剪阈值：
  - 较小规模训练更多轮数并使用较宽松的裁剪，较大规模训练更少轮数并使用更严格的裁剪（表 17）
- 表 17：32B 各规模 SFT 设置
  - 较小规模的运行（3.16K，10K）使用 32b_small 配方（7 轮，较宽松的梯度裁剪）
  - 较大规模的运行（31.6K，100K）使用 32b_large（5 轮，较严格的裁剪）
    - 所有其他设置（表 16）保持不变
  - 耗时是在 $24 \times \text{H100}$ 节点上对多样化的 Tezos Top-4 系列测量的
Common to all 8B SFT runs
- 8B 运行使用与 32B 运行相同的优化器和基础设施系列，但使用非 thinking 聊天模板和更长的训练周期（所有规模均为 7 轮）
- 固定设置总结在表 18 中

附录 D：RL Hyperparameters and Infrastructure

D.1 Hardware

D.2 Algorithm and optimizer

D.3 Training schedule

D.4 Distributed strategy

D.5 Generation (vLLM)

D.6 Rollout environment (Harbor / terminus-2)

D.7 Headline metrics at step 48

D.8 Reproducibility Artifacts

Pinned source commits (as of run start, 2026-02-27):

Repo Branch Commit

open-thoughts/OpenThoughts-Agent main 4e2b8422

penfever/SkyRL（fork） penfever/working ada3bd4f

laude-institute/harbor penfever/temp-override 94f358bc
完整 wandb 运行记录见 dogml, 已不可访问
公开 HF 检查点：laion/rl_swesmith-fixthink-pymethods2test-45
选择了 Llama-Factory（2024）的一个复刻版本，并对其进行了扩展以支持 ALST 长序列训练（2025）
RL 框架是流行的 SkyRL 框架（2025）的扩展版本
- 大部分改进已在 SkyRL-v0: Train Real-World Long-Horizon Agents via Reinforcement Learning, 2025 中描述
- 使用了 Harbor（2026）进行环境、基准测试和 Harness 管理

Repo	Branch	Commit
open-thoughts/OpenThoughts-Agent	main	4e2b8422
penfever/SkyRL（fork）	penfever/working	ada3bd4f
laude-institute/harbor	penfever/temp-override	94f358bc

附录 E：RL Run-to-Run Reproducibility

对于任何 RL 结果，一个自然的担忧是，所报告的改进中有多少是信号，又有多少是训练 Pipeline 中的噪声
- 为了探究这一点，本文评估了 pymethods2test 实验的三个近似重复的 RL 运行
- 所有三个运行都从相同的 GLM-4.7-distilled SWE-Smith 8B 检查点开始，并使用相同的 RLOO 配方、环境和第 5 节及附录 D 所述的 $24\times A100$ 设置
  - 它们仅在微小的训练选择上有所不同（一次运行的导出步数（exported step），学习率）
  - 问题：学习率不同算是微小不同？学习率不同还能算近似重复吗？
  - 问题：导出步数为什么算是一个小的变化，不影响训练吧，还是说这个是在评估一个 RL runs 上的多个评测？
- 由于这三个运行共享一个配置，仅存在这些小的扰动，因此它们下游评估分数的分布是对 RL Pipeline 可重复性的一个直接（尽管是保守的）估计
- 标题检查点 (pymethods2test-45) 在每个基准上都额外评估了两次，这使我们能够将评估噪声（重新运行同一个检查点）与训练运行噪声（重新运行 Pipeline ）区分开来
- 表 20 总结了比较结果；每个单元的方差使用混合估计量（在标题中定义）结合了评估内的二项式抽样和评估间的方差
  - 8B Agentic RL Pipeline 的运行间可重复性（Run-to-run reproducibility）
  - pymethods2test 实验的三个近似重复的 RL 运行，都从相同的 GLM-4.7-distilled SWE-Smith 8B 检查点开始，并使用 RLOO 在 $24 \times \text{A100}$ 上训练，它们的结果一致
  - lr5e-6 运行使用的学习率为 5e-6，而非其他两个运行的默认值（注：D.2 中，RL 的默认学习率似乎也是写的 5e-6 啊）
重复的 RL 运行在 ID 上仅相差约 $1.6$ 个百分点，在 OOD 上相差约 $2.0$ 个百分点
- 分布内（Core）集合的均值在 $20.2 - 21.8\%$ 之间（范围 1.6 个百分点，跨运行标准差 0.8 个百分点）
- 分布外均值在 $26.5 - 28.5\%$ 之间（范围 2.0 个百分点，跨运行标准差 1.0 个百分点），包括学习率变体
- 这个运行级别的波动与每个单元的评估噪声相当，且略大一些：
  - pymethods2test-45 的两次重复评估在大多数基准上相差 $0.3 - 3.7$ 个百分点，其中小样本的 FinanceAgent-Terminal（50 个任务）是主要的异常值，约为 $11$ 个百分点，这与它较大的二项式抽样误差一致
  - 在基准级别，更大的分母相应地更稳定：
    - SWE-Bench-Verified（500 个任务）在不同运行间仅变化 $1.5$ 个百分点，而 50-127 个任务的 OOD 基准变化在 $2.7-5.3$ 个百分点之间
      - 说明：大多数基准级别的变异性是评估抽样噪声，而非真正的训练运行差异
    - 这两个单次评估运行（10-step 和 lr5e-6）仅报告了 binomial-only error bars，因为单次评估无法估计运行级别的方差
      - 但它们的均值仍落在经过两次评估的标题运行所设定的区间内

Takeaway

该 Pipeline 在 $\sim 2$ 个百分点水平上是可重复的：
- 表 10 中报告的性能提升：
  - 在核心基准上，相对于仅 SFT 的检查点，RL 带来的特定增益约为 $5$ 个百分点（例如，SWE-Bench-Verified 上 $+5.4$）
  - 完整 SFT+RL Pipeline 相对于 Qwen3-8B 基座模型约 $18$ 个百分点的增益
- 以上提升都显著大于此处测量的约 $1.6 / 2.0$ 个百分点的 ID/OOD 运行间波动，因此它们不太可能是训练运行噪声的产物
- 在此规模下比较 RL 检查点时，使用上述混合方差误差报告集合级别的均值，而不是单个最佳评估数值，是比较 RL 检查点的合适方式

附录 F：What RL Learns: Emergent Behavior Behind the pymethods2test Result

表 9 确立了 pymethods2test 是最强的 RL 数据源，但并未说明原因
本文在此提供了一个详细的机制性描述，说明 RL 之后涌现的行为变化
本文将标题性的 pymethods2test 运行与 llm-verifier-freelancer 运行（表 9 中最强的 OOD 备选方案）进行比较
本文分析结合了三种视角：
- (i) RL 轨迹本身（约 $11\text{k}$ 个 hero Rollout，约 $53\text{k}$ 个 Baseline Rollout）上的时间分箱行为统计数据
  - 理解：hero Rollout 应该是 Hero Run 产生的 Rollout（ Hero Run 应该是非正式用语，表示明星/主角/较好的运行）
  - 在实验科学（特别是机器学习）的语境中，hero run 是一个口语化表达，意思是：“在一系列对照实验中，那个表现最优异、被选为‘代表作’并用于深入分析的特定运行”
- (ii) 在预留的评估轨迹上测量的，RL 前基座检查点与 RL 后检查点之间的每条轨迹行为差异
- (iii) 一个成对的 LLM Judge (gpt-5-2025-08-07)，它读取每个运行的 30 个相同任务的前/后轨迹对，并报告胜者、置信度和行为标签

F.1 Legitimate exploration, not reward hacking

最大且最一致的变化都是探索活动的增加
- Reasoning 急剧扩展：
  - 每条轨迹的 think Token 数增加了一倍多 $(30.3\rightarrow 65.4, + 116\%)$
  - think 块数量大致翻倍 $(0.21\rightarrow 0.44)$
- 同时伴随着
  - 更多的自我修正（每条轨迹的短语数从 $0.63$ 到 $1.14$，$+81\%$）
  - 更多的工具调用 $(31.3\rightarrow 40.9, + 31\%)$
  - 更多的 assistant 消息 $(20.0\rightarrow 26.3)$
  - 更长的对话（$+12.9$ 轮，$+29\%$ Token）
- 因此，RL 后的策略比原本就已经很冗长的蒸馏基座模型更具探索性
在 30 个相同任务的前/后轨迹 pairs 中，Judge 在 $25 / 30$ 的情况下偏好 RL 后的 hero 策略（$83.3\%$，0 平局，$24 / 30$ 为高置信度）
最常见的行为标签是
- more-tool-calls（$73\%$ 的对）
- longer-trace（$53\%$）
- more-tool-errors（$50\%$）
- different-solution-strategy（$47\%$）
Judge 独立地看到了与指标相同的扩展
- 但这种变化并非统一地“更加冗长”：$8 / 30$ pairs（$27\%$）被标记为 fewer-tool-calls/shorter-trace，也就是说，在相当一部分任务上，RL 教会了策略进行精简
三个观察结果表明，这是真正的能力变化，而非 Reward Hacking 或格式化伪迹
- 首先，RL 后的策略发出了更多的工具调用和更多的 broken tool calls（工具错误每条轨迹从 $5.9\rightarrow 8.8$，$+48\%$）
  - 这与一个为了欺骗 brittle(脆弱的) Parser 而设计的策略所表现出的行为相反
- 其次，每次调用的工具错误率仅上升了 $+4.1$ 个百分点（$31.6\% \rightarrow 35.8\%$）：
  - 额外的绝对错误大多可以通过发出更多调用来解释，而非工具使用能力的退化
  - 问题：为什么错误率反而会上升呢？
- 第三，mark_task_complete 调用的占比实际上有所上升（$1.9\% \rightarrow 3.0\%$），这与一个学会了提前结束以获取格式化奖励的策略不一致
- 行为的扩展转化为预留集上的性能提升：
  - 在 100 个共享的 SWE-Bench-Verified 任务上，RL 将 18 个任务从失败转为通过，而仅有一个任务出现退化 （sympy_- sympy-15017）

Why this data source pushed the policy to explore（pymethods2test）

为什么（pymethods2test）这个数据源推动策略进行探索
RL 过程中的奖励轨迹（图 6，蓝色曲线）是关键背景：
- pymethods2test 提供了一个中等且未饱和的奖励（它在 0.47-0.51 附近徘徊，远未达到上限），并且难以提升
- 在 RLOO 下，这正是一种奖励“更努力尝试”的机制：思考更多、调用更多工具、尝试更多修复
  - 因为增量回报来自于更彻底地解决问题，而非快速利用捷径
- 在整个运行过程中，平均对话长度和思考预算增加，而奖励趋于平稳，直到策略过度扩展
  - 本文将这种崩溃解读为产生收益的相同探索压力的负面影响，而非一个独立的失败：第 E 节中的可重复性研究（在步骤 45 导出，以及一个 10 步和一个 lr5e-6 变体）是崩溃前状态对重新运行稳定的相应证据
表 21: pymethods2test RL 诱导的行为变化 (Behavioral shift induced by pymethods2test RL)
- 在预留的 SWEbench-Verified 评估轨迹上测量
- 每个轨迹的均值计算基于 preRL 基座检查点 (…GLM_4_7_swesmith_sandboxes…) 与 post-RL 检查点 (…rl_24GPU_base_exp_rpt_pymethods2test…) 的 300 个评估行
- 每个检查点对相同的 100 个底层 SWE-benchVerified 任务运行 $\times 3$ 次
- 特征在每个块内按（经过尺度归一化的）差异幅度排序
- 主导变化是探索活动的大幅增加：Agent 思考更多，调用更多工具，发出更多 assistant 消息，并进行更多自我修正
  - 关键是，每次调用的工具错误率仅上升了 $+4.1$ 个百分点，因此 $+48\%$ 的绝对工具错误上升主要是由于发出了更多调用，而非工具使用能力下降，并且 mark_task_complete 调用的占比实际上有所上升（$+1.1$ 个百分点）
    - 这反驳了简单的 Reward Hacking 或纯格式化解释
    - 注：个人认为，每工具调用的错误率在提升本身有问题，这种情况应该可以通过优化奖励格式来优化，实际上是有点点倒退的
    - 理解：
      - Tool errors / trace 是失败的工具调用总次数 / 轨迹总数
      - Tool error rate 是失败的工具调用次数 / 总工具调用次数 × 100%
  - 在相同的 100 个任务上，该策略将 18 个任务从失败翻转为通过，而仅有一个任务出现退化

F.2 The contrast: the LLM-verifier run compacts instead of explores，对比：LLM-verifier 运行精简而非扩展

在 llm-verifier-freelancer 上运行相同的 Pipeline 产生了截然相反的结果（表 22）
- 其 RL 过程中的奖励近乎单调地上升，从 $\approx 0.54$ 到 $\approx 0.73$，没有崩溃（图 7）
- 并且在此过程中，策略进行了精简：
  - 平均轮次下降（$- 7.8$），工具调用下降（$- 8\%$），think Token 下降（$- 42\%$），自我修正短语急剧下降（每条轨迹从 $19.7 \rightarrow 8.0$，$- 59\%$），而每条对话的 Token 数基本持平（$+1\%$）
- hero 运行上升的每一个行为轴， Baseline 运行都下降了
  - LLM Judge 从另一个方向看到了相同的情况：
    - LLM Judge 在 $22 / 30$ Pairs（$73.3\%$）中偏好 RL 后的 Baseline 策略，但现在主导标签是 fewer-tool-calls（$53\%$）、shorter-trace（$40\%$）和 different-tool-strategy（$40\%$）
    - LLM Judge 的顶级判断描述了一个 RL 前的策略，该策略陷入格式错误的工具参数的循环中，而 RL 教会了它停止犹豫并交付结果
    - 在 financeagent-14 上（RL 后胜出，高置信度），“ Baseline 轨迹冗长，有许多轮次（113）和工具调用（55）……RL 后的轨迹保持简短（12 轮，6 次工具调用）……避免了使用 EDGAR API，并且没有进行自我修正，更直接地朝着目标指标前进”
表 22: 相同 Pipeline 上的两个 RL 运行学习到了相反的行为策略
- pymethods2test “hero” 运行和 llm-verifier-freelancer “baseline” 运行共享完全相同的 Pipeline （GLM-4.7-distilled SWE-Smith 8B 基座，RLOO 配方，Rollout 环境，$24\times \text{A100}$）
  - 仅在 RL 数据源上有所不同
- 在每个行为轴上（behavioral axis），两个运行都向各自相反方向移动：
  - hero 策略扩展（更多轮次、Token、工具调用、思考、自我修正）
  - Baseline 策略精简（更少轮次、调用、思考、自我修正）
  - hero 的扩展与一条非单调的奖励曲线同时发生，该曲线在步骤 $\sim 35$ 附近达到峰值然后崩溃（图 6）
  - Baseline 的精简与一条平滑、单调的奖励上升同时发生（图 7）
  - 本文作者将此解读为以稳定性为代价换取探索（hero）与对现有策略的收紧（ Baseline ）
- RL 过程中的奖励和行为差异来自时间分箱的轨迹分析和前/后评估轨迹差异
- LLM Judge 的胜率是基于每个运行 30 个相同任务轨迹对的成对 gpt-5-2025-08-07 比较
  - 产生奖励的试验（排除错误/超时试验）上的平均奖励（这是一个条件奖励），与表 9 和 10 中报告的全试验 Harbor 平均准确率（错误 $= 0$）不同
  - hero 的条件奖励在此处下降，而其全试验准确率大约翻倍 $(0.19 \rightarrow 0.33)$
  - 评估相情感可参见第 F.3 节
  - 在相同的 100 个任务上，该策略将 18 个任务从失败翻转为通过，而仅有一个任务出现退化
问题：本文关于这部分描述不够清晰，图 6 和图 7 的时间轴也没对齐，也没用 Step 来标注，很奇怪

F.3 Connecting behavior to downstream evals

行为变化持续到预留的评估中，并与表 9 中的下游排名相关联
在 300 行的 SWE-Bench-Verified 评估中，崩溃前的 hero 检查点大致使基座策略的全试验奖励翻倍
- 即 Harbor 平均准确率，该指标将错误/超时试验计为 0，与表 9 和 10 中报告的指标相同（RL 后 0.33 对比 RL 前 0.19；图 6，标记）
- 并将 18 个任务从失败翻转为通过
尽管完成试验的平均奖励下降（$0.652 \rightarrow 0.541$，表 22），但全试验准确率上升了：
- RL 将基座模型原本会放弃（超时）的许多试验转化为完成的尝试，并且由于这些被挽救的试验是更难的，条件平均值下降，而全试验准确率上升
- Baseline 的精简也有助于其自身的评估（在 156 行的 FinanceAgent 评估上，RL 后 0.224 对比 RL 前 0.173），这就是为什么 llm-verifier-freelancer 在表 9 的 OOD 上具有竞争力的原因
- 但这种精简对奖励彻底性的 ID 核心基准的迁移效果较差

附录 G：Eval Setup

Evaluation Stack Overview

对于评估，使用 vLLM (2025) 提供模型服务，通过 Harbor (2026) 编排 Agent 试验，并将每个试验隔离在 Daytona (2026) 沙箱中
本文在以下基准上进行评估：
- Terminal Bench 2.0（89 个任务）(2026) ：手工制作、人工验证的任务，涵盖 SWE、生物学、安全、系统管理和机器学习
- SWE-Bench-Verified-100（100 个任务）(2024) ：
  - 按代码仓库分层的 500 任务人工验证 SWE-Bench Verified Split 的子样本
  - Agent 针对一个固定提交的 Python 代码仓库生成 Patch
- SWE-Bench-Verified（500 个任务）(2024) ：完整的 SWE-Bench Verified Split ，格式同上
- OpenThoughts-TBLite（100 个任务）(2026) ：
  - 精心筛选的 100 个 Terminal-Bench 风格任务集合，在四个难度等级上平衡，并被设计为完整 Terminal-Bench 2.0 性能的快速代理
- Aider Polyglot（225 个任务）(2024) ：
  - 一个多语言代码编辑基准（C++、Go、Java、JavaScript、Python、Rust），来源于 Exercism 并筛选出较难的问题
- BFCL-Parity（123 个任务）(2025) ：
  - Berkeley Function Calling Leaderboard (BFCL) 是一个综合性基准，用于评估大型语言模型根据自然语言指令正确调用函数/工具的能力
  - 这是 BFCL v4 的一个分层随机子样本
- MedAgentBench（300 个任务）(2025) ：一个临床 Agent 基准，运行在一个包含约 $\sim 700k$ 条记录的供应商 FHIR 服务器上
- GAIA-127（127 个任务）(2023) ：
  - GAIA 验证 Split 的一个纯文本子集，用于通用 AI 助手的多步骤事实型问答，涉及网页浏览、文件处理和工具使用
  - 对于此基准，本文在默认设置下进行评估，未设置搜索 API
- FinanceAgent-Terminal（50 个任务）(2025) ：
  - Vals AI 的 Finance Agent Benchmark 的一个终端 Agent 变体，涉及 SEC 10-K/10-Q 文件，并提供对 EDGAR/网络/RAG 工具的 Shell 访问
  - 对于此基准，作者在评估时向模型提供了 SERP 和 EDGAR API
所有数据集均按 Harbor 格式准备，对于 OOD 基准，使用 Harbor 适配器 (2026) 生成了数据集

Evaluation Setup

对于每个（模型、基准、harness）组合，执行 3 次重复运行，并报告平均 Pass@1 准确率及运行间的标准误差
使用训练的模型进行的所有评估都运行在 32K 上下文窗口、16K 输出上限以及 2048 Token 的主动式总结阈值下
每次执行默认有 32 个并发试验，并尽可能注册和重用 Daytona 快照，以避免在重复评估期间重建环境
- 这减轻了偶发性环境构建错误的发生，并总体上加快了评估速度
对于报告的每个 Baseline 模型，执行两次上述 Pipeline ：
- 一次在 terminus-2 下（与本文训练模型的设置一致）
- 一次在原始报告中指示的 preferred 脚手架和服务配置下

Timeout-aware Evaluation

Agentic 试验受限于 Token 数量：
- 一个 8B 模型以 $\sim 150$ Token/秒解码，耗时十分钟的试验
- 即使 Agent 轮次相同，对于以 $\sim 30$ Token/秒解码的 32B 模型可能需要一小时
- 在不同模型大小之间保持每个试验的超时时间恒定，会混淆准确性
  - 较慢的模型会在较快的模型能完成的任务上超时
为了弥补这一点，本文应用了一个超时乘数 $m$（通过 harbor 配置中的 --timeout-multiplier flag）
- 对 8B 试验使用 $m = 2$，对 32B 试验使用 $m = 16$
为避免评估耗时过长，在应用乘数后，无论 $m$ 为何值，都对 Agent 执行设置了 2 小时的上限：
$$\text{effective_timeout} = \min (\text{cap},\text{base}\times m).$$
对于无法获得相当吞吐量的大型模型，使用第三方 API 来确保公平比较

Coderforge-Preview

本文未在主要结果表中包含未发布模型的开放数据发布；the most prominent example is CoderForge-Preview (2026)

Reproducing OpenSWE

(OpenSWE)daVinci-Env: Open SWE Environment Synthesis at Scale, 20260313-20260316, SJTU & GAIR (2026) 报告了在 Qwen-2.5-32B 基座上训练，在 SWE-Bench-Verified（完整 500 任务 Split ）上达到 $62.4\%$
本文尝试使用公开发布的 GAIR/OpenSWE-32B 检查点复现此分数
- 为了匹配他们的设置，本文使用了相同的温度 $= 0.7$、128K Token 上下文窗口、300 步预算，以及本文在通信中与本文分享的 SWE-Agent 配置
- OpenSWE 仓库主要提供数据 Pipeline 的细节，但在撰写本文时，脚手架或评估 harness 组件尚未公开发布，因此本文无法保证在每一个内部细节上都完全匹配
- 在本文的 SWE-Bench-Verified-100 子集上，本文测量到 $44.0\%$
- 本文尚未在完整的 500 任务 Split 上获得可直接比较的数字，因此与报告的 $62.4\%$ 的差距部分源于不同的分母，此外还可能存在其他方法论上的差异
  - We have not been able to fully attribute the residual gap and continue to investigate
  - 理解：本文尚未能完全复现 OpenSWE 的结果
表 23 中标记了 OpenSWE，并将其从主表 1 中排除，同时仍用下划线标记引用其报告的数字
表 23: OpenThinkerAgent-32B 是 32B 尺度模型（Qwen3 家族或更早）中，在主要表 1 共用的七个基准上平均准确率最强的模型
- 每个单元报告该模型在已评估的 Agent Harness 中的最佳准确率 $(\%)$
  - 下标是该单元每次运行的标准误差
- Avg 列计算的是每个模型在主要表 1 中使用的相同七个基准（SWE-Bench-Verified、Terminal-Bench-2、Aider-Polyglot、BFCL-Parity、MedAgentBench、GAIA-127、FinanceAgent-Terminal）上的平均准确率
- OpenThoughts-TBLite 和 SWE-Bench-Verified-100 作为列显示，但未计入平均值
- 模型按规模分组（8B、32B、Frontier）
- 在每个组内，准确率在组内该基准最大值的 1 个标准误差范围内的单元以粗体显示

Evaluation on Terminal-Bench 2.1

在本文的实验进行期间，Terminal-Bench 2.1 发布，它修订了 $31\%$ 的 Terminal-Bench 2.0 任务（28/89 个任务），以纠正三类缺陷：
- 规格-验证不匹配、资源不匹配和基准漂移 (2026)
由于 Terminal-Bench 2.0 是本文的两个核心基准之一，所以本文在 Terminal-Bench 2.1 上重新评估了一个代表性 Baseline （Qwen 3.5-27B），以验证本文的结论在新版本发布后是否依然成立
表 24 报告了在 TB2.0 和 TB2.1 中的准确率
- 观察到的变化（3.0 个百分点）远小于前沿 Agent 审计报告中所显示的、高达 12.0 个百分点的变化 (2026)
- 因此，本文继续在整篇论文中报告 TB2.0 的结果，因为重新评估每个模型在 TB2.1 上的表现将带来过高的成本
表 24: Qwen 3.5-27B 在 Terminal-Bench 2.1 上略有提升
- 但 2.1 和 2.0 之间的差距远小于前沿 Agent 的观察差距，这有助于说明本文在论文中报告 Terminal-Bench 2.0 结果的决定

Harness symbols

没有上标的单元使用默认的 harness terminus-2，非默认符号：$\ast =$ OpenHands (2025)，$\dagger =$ 常规 SWE-Agent (2024)，$\bullet =$ SERA-SWE-Agent（SERA 团队的 SWE-Agent 配置），$\S =$ R2EGym-Edit-Agent（在 R2EGym 评估 (2025) 中实现的自定义 ReAct 脚手架），$\P =$ SkyRL（SkyRL-Agent 评估 (2025) 中使用的简单 ReAct (2023) 脚手架），$\star =$ Mini-SWE-Agent (2024)
注：R2EGym-Edit-Agent 和 SkyRL-Agent 在 Harbor 的 Agent 套件中不直接可用

Color coding

绿色的模型名称也出现在主要表 1 中
橙色标记了作者尚未能完全复现其已发表结果的模型（详见 G 节）
- 它们的 SWE-Bench-Verified 和 SWE-Bench-Verified-100 单元也以橙色渲染，以标记这一差距
带下划线的数字是根据模型已发表的论文数字填写的，而非本文复现结果
注意：本文未在此表中包含未发布模型的开放数据发布，例如 CoderForge-Preview (2026)

Introduction and Discussion

Related Work

Data curation

Agents and their benchmarks

Agentic Models

Public frameworks for building agents

SFT Data Pipeline

Pipeline

Training

Evaluation Setup

Sourcing Tasks

Mixing Tasks

Task Augmentation Strategies

Filtering Tasks

Teacher Model

Filtering Agent Rollouts

Scaling Up SFT Data

OpenThoughts-Agent-v2

Reinforcement Learning

Experimental Details

Sourcing Tasks in RL

The data source matters，数据来源很重要

Results

附录 A：Full SFT Pipeline Ablation Tables

A.1 Task Generation Strategies (Full Ranking)

A.2 Mixing Strategies (Full Results)

A.3 Filtering for Longer Episodes: A Compute-Controlled Ablation

附录 B：Scaling at 8B

附录 C： SFT Hyperparameters

C.1 SFT training hyperparameters per data scale

附录 D：RL Hyperparameters and Infrastructure

D.1 Hardware

D.2 Algorithm and optimizer

D.3 Training schedule

D.4 Distributed strategy

D.5 Generation (vLLM)

D.6 Rollout environment (Harbor / terminus-2)

D.7 Headline metrics at step 48

D.8 Reproducibility Artifacts

附录 E：RL Run-to-Run Reproducibility

Takeaway

附录 F：What RL Learns: Emergent Behavior Behind the pymethods2test Result

F.1 Legitimate exploration, not reward hacking

Why this data source pushed the policy to explore（pymethods2test）

F.2 The contrast: the LLM-verifier run compacts instead of explores，对比：LLM-verifier 运行精简而非扩展

F.3 Connecting behavior to downstream evals

附录 G：Eval Setup

Evaluation Stack Overview

Evaluation Setup

Timeout-aware Evaluation

Coderforge-Preview

Reproducing OpenSWE

Evaluation on Terminal-Bench 2.1

Harness symbols

Color coding