CoderForge-Preview：最大开源编码智能体数据集

随着编码智能体（Coding Agent）能力不断提升，研究社区面临一个关键瓶颈：缺乏大规模、高质量的开源训练数据。虽然闭源模型持续进步，但开源模型因难以获取长上下文、测试验证的智能体轨迹而发展受限。

我们发布 CoderForge-Preview，这是迄今最大的开源编码智能体轨迹数据集——包含 25.8 万条测试验证轨迹（15.5 万条成功，10.3 万条失败），覆盖 5.1 万个任务和 1655 个仓库。我们还分享了使用该数据集训练 32B 和 4B 模型的结果。通过开源 CoderForge，我们希望加速整个开源 AI 社区的进步，让全球研究者都能基于我们的工作构建、研究和改进。微调 Qwen-3 32B 在 SWE-Bench Verified [8] 上达到 59.4% pass@1，在 ≤32B 参数的开源数据模型中排名第一。

我们发布了完整的轨迹数据集，以及 32B 模型的评估轨迹。

• 数据集
• 32B 评估轨迹

CoderForge-Preview 数据详情

我们使用 Qwen3-Coder-480B 从三个不同任务源生成智能体轨迹，并通过拒绝采样过滤掉未通过测试的解决方案。这个过程产生了 25.8 万条长上下文轨迹（最高 128K Token），覆盖 5.1 万个任务。我们保留了其中 15.5 万条高质量、测试验证的轨迹用于监督微调（SFT）训练。

任务来源

任务来自三个数据集：R2E-Gym [5]、SWE-Smith [6] 和 SWE-Rebench [7]。

表 1：任务数量反映了在我们执行环境中有效的实例。

实验设置

智能体执行框架（Harness）方面，我们将 OpenHands v0.52.1 框架 [4] 集成到 R2E-Gym [5] 数据生成框架中。它包含四个主要工具：bash 执行（execute_bash）、文件编辑（str_replace_editor）、日志思考（think）和任务完成（finish）。OpenHands 预装在每个 Docker 评估环境中，让 LLM 智能体能够通过标准化的动作/观察接口与隔离的代码仓库交互。

每个任务在独立的 Docker 容器中执行，智能体最多迭代 100 步，通过发出 bash 命令和文件编辑来生成最终补丁。

我们使用 Qwen3-Coder-480B 作为数据生成的主要模型，参数设置为 temperature=0.7，top_p=0.8，max_new_tokens=32,768。为了提高成功轨迹的数量，我们为每个问题生成多个轨迹：R2E-Gym 和 SWE-Rebench 生成 8 个，SWE-Smith 生成 4 个。我们只保留最终补丁通过所有仓库测试的轨迹。

为避免评估数据泄露，我们排除了与 SWE-Bench Verified 样本共享相同（仓库，base_commit）对或问题描述的任何任务。

与其他数据集对比

表 2：CoderForge-Preview 与其他开源编码智能体数据集的比较。

CoderForge-Preview 数据在同类开源数据集中规模最大、性能最佳。拥有 25.8 万条总轨迹和 15.5 万条成功轨迹，上下文长度达 128K，在规模和长上下文覆盖上都大幅超越先前数据集。

各任务源的轨迹成功率

对于每条轨迹，我们运行任务提供的相关测试来检查模型是否解决了问题。R2E-Gym 任务的解决率始终最高，从 Pass@1 的 62.9% 提升到 Pass@8 的 80.3%。SWE-Rebench 也从多尝试采样中显著受益，从 57.5% 提升到 Pass@8 的 73.9%。SWE-Smith 的提升较为温和，从 Pass@1 的 58.8% 增加到 Pass@4 的 64.9%。

整体趋势表明，多样本生成能有效提高成功轨迹的产出，随着尝试次数增加，回报逐渐减少但保持稳定。

最终任务源分布

我们根据轨迹是否成功解决任务进行过滤，得到以下任务分布。在我们的 SFT 实验中，只使用成功轨迹进行训练。

轨迹特征分析

数据生成成本

表 3：各任务源的数据生成成本和效率指标。

大规模数据生成得益于高效的长上下文推理和积极的提示缓存。在 R2E-Gym、SWE-Smith 和 SWE-Rebench 上，我们进行了 1564 万次 API 调用，处理了 4520 亿个 prompt token，生成了 291 亿个 output token，整体缓存命中率约 90%。按照每百万 prompt token 0.50 美元、每百万缓存 token 0.25 美元、每百万 output token 2.00 美元的定价模型，生成这个大规模长上下文轨迹数据集的总成本为 13 万美元。

轨迹长度分析

表 4：各数据源的轨迹长度分布和总训练 token 数。

上表显示了各数据源生成的智能体轨迹长度分布。轨迹长度中位数在 36K-42K token 之间，平均长度约 41K token，P99 长度接近 100K token，凸显了数据的长上下文特性。整个数据集包含 67 亿个总训练 token。

表 5：各数据源成功与失败轨迹的平均智能体步数。

我们比较了各数据源成功与失败轨迹的平均智能体步数。在所有情况下，失败轨迹需要的步数明显更多，平均比成功轨迹多 18-28%。通过只训练成功轨迹，我们旨在推动模型实现高效任务解决和简洁决策，而不是从冗长的无效序列中学习。

许可证过滤

为确保数据集能被负责任地使用，我们对每个任务引用的确切提交版本中的每个仓库进行了全面的许可证审核。我们从每个仓库的特定提交 SHA 中检索 LICENSE 文件，并使用 scancode-toolkit 进行识别——这是 Linux 基金会和 SPDX 项目使用的行业标准许可证检测引擎。

我们只保留来自宽松开源许可证仓库的轨迹：

CoderForge-Preview 训练实验

训练设置

我们选择密集模型 Qwen3-32B [1] 作为微调的基模型。

为了支持 128K 长度序列的高效训练，我们通过 Ulysses [2] 采用序列并行（Sequence Parallelism），分割序列维度并使用优化的 all-to-all 通信来计算注意力。此外，由于数据集中轨迹长度不一，我们使用多打包（multi-packing）将多个较短轨迹打包到同一训练序列中，同时通过边界感知掩码（boundary-aware masking）[3] 防止跨示例注意力污染。

我们使用token 级损失公式，在FSDP 和序列并行 GPU 上聚合整个批次中所有 token 的梯度。这意味着每个 token 对总损失的贡献相对于批次中的总 token 数进行归一化，从而长序列和短序列的权重保持一致。

给定 $L_i$：在 rank $r$ 上微批次 $i$ 的平均交叉熵损失，$n_i^{(r)}$：在 rank $r$ 上微批次 $i$ 中的有效 token 数，$N=\sum_{r}\sum_{i} n_i^{(r)}$：所有 rank 和微批次中的总有效 token 数，归一化损失计算为：

$$\mathcal{L} ;=; \frac{\sum_{r}\sum_{i} L_i, n_i^{(r)}}{\sum_{r}\sum_{i} n_i^{(r)}}$$

我们在 8 个节点（64 个 H100 GPU）上训练 Qwen3-32B 模型，使用 FSDP2（分片大小=8）、Ulysses 序列并行（大小=8）、BF16 精度、梯度检查点和 FlashAttention-2。为了最大化训练吞吐量，我们使用顺序打包（sequential packing）来充分利用 128K 上下文窗口，确保不同长度序列间的填充浪费最小。详细长度分析如下：

表 6：使用多打包采样（128K 上下文窗口）的训练序列长度分布。

聊天模板

我们采用 Qwen Coder 的聊天模板，它具有更适合 LLM 的 XML 格式工具调用（Tool Use）。我们还在 Huggingface 数据集的 trajectories-tokenized_qwencoder 子集中发布了带损失掩码的 token 化轨迹。

评估结果

我们在 SWE-bench Verified 上评估了模型性能。这个基准包含 500 个真实的 GitHub issue，专门测试端到端的软件工程能力。我们最好的模型在 第 3.13 个训练周期（epoch） 时，达到了 59.4% 的 pass@1 和 78.56% 的 pass@16。这显示了很强的单次尝试准确率和通过多次采样获得的优秀覆盖率。我们的训练数据 CoderForge-Preview Data 融合了多个来源的轨迹，以最大化多样性和覆盖范围。

重复惩罚（Repetition Penalty）

在训练初期，我们注意到很多 str_replace_editor 工具调用失败，原因是模型会重复它想要替换的字符串。我们研究了施加一个轻微的重复惩罚是否能抑制这种退化循环，同时又不影响精确的代码编辑。结果如下：

左图展示了不同训练周期下的评估分数，右图则可视化了每个检查点（checkpoint）的性能差异。

结论：对于生产部署，我们建议使用无重复惩罚的后期周期检查点。不过，对于提前停止（early-stopped）的模型，轻微的惩罚可以起到有用的正则化效果。

小规模实验

为了测试数据集在小规模模型上是否同样提供有效的学习信号，我们微调了 Qwen3‑4B。SWE-bench Verified 的结果显示，在 5 个训练周期内，这个 4B 模型的分数稳步提升至 43.0%（第 5 个周期）。

重复惩罚的消融实验也显示出与 32B 设置相似的趋势：它在早期（第 1-3 周期）有帮助，但在性能最佳的后期检查点上则没有益处。

4B 模型（43.0%）和 32B 模型（59.4%）之间的峰值性能差距证实了，模型容量对于复杂的智能体（Agent）任务很重要。但两者一致的改进轨迹也验证了，我们的训练数据在不同规模下都提供了真实有效的学习信号。

评估轨迹发布

我们发布了 CoderForge-Preview-32B 在 SWE-Bench-Verified 上的评估轨迹。

我们的评估设置如下：

• 执行框架（Harness）：OpenHands v0.52.1
• 采样参数：
  • temperature: 0.7
  • top_p: 0.8
  • max_tokens: 32768
  • max_iterations: 100

模型性能因代码仓库而异。排除样本量非常小的仓库（例如 n<5），scikit‑learn 的解决率最高（84.4%），其次是 matplotlib（64.7%）和 xarray（63.6%）。对于 Django（n=231，占基准测试的 46%），模型解决了 61.9% 的实例。一些较低的解决率（例如 seaborn）基于非常小的样本量，解读时需要谨慎。

评估提示模板

在数据生成和评估中，我们都采用了 OpenHands SWE-Bench 模板：

<uploaded_files>
/workspace/{{ workspace_dir_name }}
</uploaded_files>

I've uploaded a python code repository in the directory {{ workspace_dir_name }}. Consider the following issue description:

<issue_description>
{{ instance.problem_statement }}
</issue_description>

Can you help me implement the necessary changes to the repository so that the requirements specified in the <issue_description> are met?
I've already taken care of all changes to any of the test files described in the <issue_description>. This means you DON'T have to modify the testing logic or any of the tests in any way!
Also the development Python environment is already set up for you (i.e., all dependencies already installed), so you don't need to install other packages.
Your task is to make the minimal changes to non-test files in the /workspace/{{ workspace_dir_name }} directory to ensure the <issue_description> is satisfied.

Follow these phases to resolve the issue:

Phase 1. READING: read the problem and reword it in clearer terms
   1.1 If there are code or config snippets. Express in words any best practices or conventions in them.
   1.2 Hightlight message errors, method names, variables, file names, stack traces, and technical details.
   1.3 Explain the problem in clear terms.
   1.4 Enumerate the steps to reproduce the problem.
   1.5 Hightlight any best practices to take into account when testing and fixing the issue

Phase 2. RUNNING: install and run the tests on the repository
   2.1 Follow the readme
   2.2 Install the environment and anything needed
   2.2 Iterate and figure out how to run the tests

Phase 3. EXPLORATION: find the files that are related to the problem and possible solutions
   3.1 Use `grep` to search for relevant methods, classes, keywords and error messages.
   3.2 Identify all files related to the problem statement.
   3.3 Propose the methods and files to fix the issue and explain why.
   3.4 From the possible file locations, select the most likely location to fix the issue.

Phase 4. TEST CREATION: before implementing any fix, create a script to reproduce and verify the issue.
   4.1 Look at existing test files in the repository to understand the test format/structure.
   4.2 Create a minimal reproduction script that reproduces the located issue.
   4.3 Run the reproduction script to confirm you are reproducing the issue.
   4.4 Adjust the reproduction script as necessary.

Phase 5. FIX ANALYSIS: state clearly the problem and how to fix it
   5.1 State clearly what the problem is.
   5.2 State clearly where the problem is located.
   5.3 State clearly how the test reproduces the issue.
   5.4 State clearly the best practices to take into account in the fix.
   5.5 State clearly how to fix the problem.

Phase 6. FIX IMPLEMENTATION: Edit the source code to implement your chosen solution.
   6.1 Make minimal, focused changes to fix the issue.

Phase 7. VERIFICATION: Test your implementation thoroughly.
   7.1 Run your reproduction script to verify the fix works.
   7.2 Add edge cases to your test script to ensure comprehensive coverage.
   7.3 Run existing tests related to the modified code to ensure you haven't broken anything.

8. FINAL REVIEW: Carefully re-read the problem description and compare your changes with the base commit {{ instance.base_commit }}.
   8.1 Ensure you've fully addressed all requirements.
   8.2 Run any tests in the repository related to:
     8.2.1 The issue you are fixing
     8.2.2 The files you modified
     8.2.3 The functions you changed
   8.3 If any tests fail, revise your implementation until all tests pass

Be thorough in your exploration, testing, and reasoning. It's fine if your thinking process is lengthy - quality and completeness are more important than brevity.

局限性

数据方面：

• 对不同执行框架（Harness）的适应性：我们使用单一的执行框架和工具集生成所有数据，没有进行排列组合。因此，用这些数据进行监督微调（SFT）训练的模型，在使用不同的执行框架、工具和提示模板时，性能可能会下降。
• 任务范围：鉴于我们的数据源主要关注修复 bug，用这些数据进行 SFT 训练的模型，在执行该范围之外的任务（例如功能实现）时，能力可能较弱。
• 用户交互：大多数真实的编码智能体使用都涉及用户干预和与智能体的协作，表现为在整个轨迹中而不仅仅是开始时发送用户消息。目前，这种交互类型在开放的编码智能体数据集中是缺失的，包括我们的数据集。因此，仅用这些数据进行 SFT 训练的模型，在交互式场景中可能表现不佳。

训练方面：

• 有限的模型规模探索：由于资源限制，我们只训练了两种规模的模型。探索更大的模型很可能会带来进一步的性能提升。
• 最小化的超参数调优：由于资源限制，我们使用了固定的训练配置（学习率 1e-5，余弦调度，128K 上下文窗口），没有进行广泛的超参数搜索。系统地调整学习率、批大小、预热步数和损失权重，可能会改善收敛性和最终性能。

评估方面：

• 对于本次发布，我们主要使用标准的 SWE-Bench-Verified 进行评估，该基准最近引发了大量关于其信号质量的讨论。在下一轮迭代中，我们将在更多的编码和终端智能体基准上进行评估。

结论

在这项工作中，我们专注于大规模智能体（Agentic）数据生成，从开源社区汇集了 51K 个不同的任务，并生成了长视野、多步骤的监督微调（SFT）轨迹。我们的结果表明，一个简单的数据生成流程结合纯 SFT 训练，可以在智能体编码性能上带来显著提升。

展望未来，我们计划进一步扩展数据生成规模，使用不同的执行框架、工具、排列组合，并训练更大的模型，以更好地理解性能扩展的上限。此外，我们打算遵循 DeepSWE [9] 的训练范式，在我们微调后的模型之上应用智能体强化学习（Agenetic Reinforcement Learning），以推动进一步的性能提升。

BibTeX 引用

@misc{CoderForge2026,
  title        = {CoderForge-Preview: SOTA Open Dataset for Training Efficient Agents},
  author       = {Ariyak, Alpay and Zhang, Junda and Wang, Junxiong and Zhu, Shang and Bianchi, Federico and Srivastava, Sanjana and Panda, Ashwinee and Bharti, Siddhant and Xu, Chenfeng and Heo, John and Wu, Xiaoxia Shirley and Zou, James and Liang, Percy and Song, Leon and Zhang, Ce and Athiwaratkun, Ben and Zhou, Zhongzhu and Wu, Qingyang},
  year         = {2026},
  month        = feb,
  publisher    = {Together AI Blog},
  url          = {https://www.together.ai/blog/coderforge-preview},
  note         = {Project core leads: Alpay Ariyak; Zhongzhu Zhou; Qingyang Wu}
}

参考文献

[1] Qwen Team. "Qwen3-32B." Hugging Face Model Card (2025). https://huggingface.co/Qwen/Qwen3-32B

[2] Jacobs, Sam Ade, et al. "DeepSpeed Ulysses: System optimizations for enabling training of extreme long sequence transformer models." arXiv preprint arXiv:2309.14509 (2023).

[3] imoneoi. "Multipack Sampler: Padding-free distributed training of LLMs." GitHub repository (2024). https://github.com/imoneoi/multipack_sampler

[4] Wang, Xingyao, et al. "OpenHands: An open platform for AI software developers as generalist agents." arXiv preprint arXiv:2407.16741 (2024).

[5] Jain, Naman, et al. "R2E-Gym: Procedural environments and hybrid verifiers for scaling open-weights SWE agents." arXiv preprint arXiv:2504.07164 (2025).

[6] Yang, John, et al. "SWE-smith: Scaling data for software engineering agents." arXiv preprint arXiv:2504.21798 (2025).

[7] Badertdinov, Ibragim, et al. "SWE-rebench: An automated pipeline for task collection and decontaminated evaluation of software engineering agents." arXiv preprint arXiv:2505.20411 (2025).

[8] Jimenez, Carlos E., et al. "SWE-bench: Can language models resolve real-world GitHub issues?" ICLR 2024, arXiv preprint arXiv:2310.06770 (2028).

[9] Luo, Michael, et al. "DeepSWE: Training a state-of-the-art coding agent from scratch by scaling RL." TogetherAI/Agentica Blog (2025).

[10] Shen, Ethan, et al. "SERA: Soft-Verified Efficient Repository Agents." arXiv preprint arXiv:2601.20789 (2026). https://arxiv.org/abs/2601.20789

[11] Nex-AGI Team. "Nex-N1: Agentic Models Trained via a Unified Ecosystem for Large-Scale Environment Construction." arXiv preprint arXiv:2512.04987 (2025). https://github.com/nex-agi/Nex-N1

[12] Trofimova, Maria, et al. "OpenHands Trajectories with Qwen3-Coder-480B-A35B-Instruct." Nebius Blog (2025). https://nebius.com/blog/posts/openhands-trajectories-with-qwen3-coder-480b‍

‍