Prime Intellect 整合 23 个任务集，提供 36.5 万+ SWE、终端与搜索智能体 RL 环境

扩展智能体强化学习：面向软件工程、终端和搜索的 365,000+ 环境

开放研究生态已经为三大智能体领域——软件工程、终端使用和网络研究——产出了许多优秀的数据集，但每一个都自带其专属的测试框架、镜像约定、评分脚本和失败模式。

一个 taskset API 背后的 23 个 taskset

领域 · TASKSET任务

软件

工程

swesmith 83,519openswe 36,884swerebench_v2 32,079scaleswe 17,202swelego 15,903multiswe 6,835r2e_gym 4,578swebench_pro 731swebench_verified 500swebench_multilingual 300senior_swe_bench 50

终端

tmax 14,600terminal_lego ~13,800openthoughts_tblite 100terminal_bench_2 89

搜索

papersearchqa 59,907wideseek 44,632s1_deepresearch ~15,000openseeker 11,677deepdive 3,250browsecomp 1,266redsearcher 1,000browsecomp_plus 830

总计23 个 taskset

我们将它们全部整合。我们在一个 taskset API、统一的运行时/沙箱钩子以及一条命令背后，提供对 23 个智能体 taskset 的第一方集成：跨 20+ 种语言的约 198,000 个软件工程任务、约 28,600 个终端任务以及约 137,600 个搜索任务——总计约 365,000 个任务，可在 Prime Intellect 基础设施上用于评估和强化学习训练，并在原始数据需要修复之处重新上传了经过验证和清理的数据集。

uv pip install "git+https://github.com/PrimeIntellect-ai/research-environments.git#subdirectory=environments/swe/scaleswe_v1"

# Example running ScaleSWE in Codex harness on Prime Sandboxes:
uv run eval scaleswe-v1 --harness.id codex --harness.runtime.type prime -n 3

让这条单一命令成为可能的是 verifiers v1，它将环境分解为三个相互独立的层：taskset、harness 和 runtime。本文讲述的是其中 taskset 这一部分。

一份契约，三个领域

每个上游 taskset 都为其自身的 harness 做出了合理的选择——而这些选择无法组合。SWE-bench 在生成的评估脚本中应用测试补丁；R2E-Gym 将测试烘焙进镜像并与预期输出进行比较；搜索基准则各自发明自己的评判器。如果你想在所有任务上训练同一个智能体，就需要在不破坏每个 taskset 自身评分语义的前提下，将这些生命周期规范化。

我们的集成保留了每个 taskset 原有的评分路径——上游日志解析器、上游报告生成、上游测试命令——并将周围的一切规范化：

一个 API。每个 taskset 都从类型化配置（数据集、划分、过滤器）加载，根据任务的镜像配置沙箱，并使用该 taskset 自身的逻辑进行评分。添加 filter_fn 或切换划分在任何地方都以相同方式工作。
一个镜像仓库。 任务镜像存放在我们自己的 Prime 镜像仓库中，与沙箱同地部署——约 135,000 个预构建的开源任务镜像，据我们所知，这是任何沙箱提供商托管的最大此类目录。没有标志，没有命名空间映射，部署时也没有 Docker Hub 速率限制——否则当你对 Docker Hub 运行一千个并发部署时会立即遇到这些限制。你还可以预构建并上传自己的镜像（prime images push），或直接从 Docker Hub 复制现有镜像（prime images transfer-bulk）。
一个完整性标准。 在部署过程中，智能体与评分机制位于同一个沙箱内，因此容器中任何可读的内容都可能被用于奖励黑客攻击。因此，每个集成都会在评分之前扣留评分材料——测试补丁、预期输出、评分脚本。一些原始作者选择将其保持可见：R2E-Gym 将其评分测试以可读形式放在镜像内的 /r2e_tests 中，而 Multi-SWE 的容器在 /home 下携带可读的评分 shell 脚本和 test.patch。对于他们的评估时附加测试框架来说，这是一个不错的选择，但对于实时 RL 沙箱来说则不然，因此我们的集成会隐藏这些工件，仅在评分时恢复它们。
一个验证标准。 在数据集获得默认位置之前，我们会对其运行黄金补丁和空操作验证，并重新上传清理后的版本，同时保留排除项以保持透明——下一节将介绍具体方法。

任务集的常见形态是数据模式加上少量钩子：

import verifiers.v1 as vf

class MyTaskData(vf.TaskData):
    base_commit: str      # state the sandbox resets to
    test_patch: str       # grading material - withheld until scoring
    gold_patch: str       # reference fix - used only by `validate`

class MyTask(vf.Task[MyTaskData]):
    async def setup(self, runtime: vf.Runtime):
        ...  # prepare the repo inside the task's image

    async def finalize(self, trace: vf.Trace, runtime: vf.Runtime):
        ...  # capture the agent's diff into the trace for posterity

    @vf.reward
    async def solved(self, runtime: vf.Runtime) -> float:
        ...  # restore tests, apply test_patch, run the upstream grading path

    async def apply_gold_patch(self, runtime: vf.Runtime):
        ...  # apply the reference fix

    async def validate(self, runtime: vf.Runtime) -> bool:
        ...  # gold patch must score 1.0; not calling `validate` must not

class MyTaskset(vf.Taskset[MyTask, vf.TasksetConfig]):
    def load(self) -> list[MyTask]:
        ...  # (dataset, split, filter_fn) -> tasks pinned to images

我们不断在内部对这些任务集进行评估或训练，这持续验证了它们与我们的沙箱基础设施之间的交互，并且我们定期更新数据集、镜像和集成。

经过验证的重新上传

任务集行只有在能够产生干净的奖励信号时才有用：应用黄金补丁 → 测试通过；无补丁 → 测试失败。相当一部分开放智能体任务数据未能满足这一前提条件——镜像损坏、依赖网络的测试、预期输出漂移，以及无需触碰代码即可解决的任务。

因此我们进行了验证。对于每个数据集，我们在全新沙箱中通过完整评分路径运行黄金补丁，将失败重试最多 10 次以区分偶发失败与确定性损坏，运行独立的第二轮以捕获噪声行，并运行多次 无编辑 轮次以丢弃无需任何修复即可得 1.0 分的任务。结果重新上传到 SWE RL 集合中，并保留了被丢弃的行，因此你可以审计每一次排除：

R2E-Gym-Subset-Verified：4,578 行中的 4,522 行通过 10 次重试黄金验证；56 个丢弃项主要是网络/时序敏感的 aiohttp/tornado 测试。
SWE-Lego-Real-Data-Verified：4,432 行中的 4,323 行，方法相同。
Multi-SWE-RL-Verified：2,232 行通过两次黄金补丁验证以及一个无编辑过滤器，该过滤器捕获了零编辑即可评为已解决的任务。
SWE-rebench-V2-Filtered-Verified：从 32,079 行原始数据中保留 6,275 行——针对整体损坏镜像的语言级丢弃、两次独立黄金验证并移除偶发行，以及清理了内联 GitHub issue/PR 引用的问题陈述。
SWE-Bench-Verified-Quick：500 个 Verified 实例中的 468 个，丢弃最慢的示例以用于快速在线评估。

这些通过背后的工具随附了 verifiers，因此你可以自行复现它们。uv run validate <taskset-id> 是 eval 的无模型版本：对于每个任务，它在独立的运行时中运行黄金检查（setup、应用参考修复、测试必须通过）和仅 setup 的空操作检查（没有修复时测试必须不通过）——--only-gold 和 --only-setup 选择其中一侧。而 uv run debug <taskset-id> --command "<cmd>"（或 --script-path）会设置任务的沙箱，在其中运行任意命令或上传的脚本，并持久化追踪记录——这是在不编写 harness 的情况下探查容器任务状态最方便的方式。

软件工程任务

SWE-bench Verified（Jimenez 等，Princeton - 论文）是经典基准：来自主要 Python 仓库的真实 GitHub issue，通过编写补丁使隐藏的失败测试通过来解决，由 OpenAI 人工筛选至 500 个确认可公平解决的实例。swebench_verified_v1 针对官方实例镜像运行 Harbor Hub 打包。
SWE-bench Multilingual（Khandpur 等，SWE-bench 团队 - 博客、论文、swebench_multilingual_v1）将经典基准扩展到 Python 之外：官方 300 实例测试集涵盖 C、C++、Go、Java、JS/TS、PHP、Ruby 和 Rust。我们的集成封装了 Harbor 打包，并使用经典验证器进行评分。
SWE-bench Pro（Deng 等，Scale AI - 仓库）是更难的继任者：来自许可友好仓库的 731 个公开任务，带有大规模 diff。我们的集成（swebench_pro_v1）封装了 Harbor 打包，并根据每个任务的测试配置解析其托管镜像。
SWE-smith（Yang 等，Stanford / Princeton - 论文、swesmith_v1）反转了数据问题：它不挖掘 issue，而是向健康的仓库注入 bug，并保留能捕获这些 bug 的测试——涵盖八种语言的 88,130 个实例。任务分支携带 bug，并从 head commit 中移除失败测试；我们的移植让 agent 停留在该 head，仅在评分时通过 HEAD~1 恢复测试，并原样复用上游的评分和 profile 注册表。
R2E-Gym（Jain 等，UC Berkeley - 论文）从真实 commit 生成可执行环境，并合成 issue 描述——其精选子集中有 4,578 个实例。作者镜像让评分测试在容器内可读；r2e_gym_v1 仅在评分时恢复 /r2e_tests。我们发布了一个经过黄金验证的重新上传版本——4,578 个实例中的 4,522 个——taskset 默认使用该版本。
Multi-SWE（Zan 等，ByteDance - 论文、multiswe_v1）扩展到 Python 之外：涵盖 C、C++、Go、Java、JS、Rust 和 TypeScript 的 4,703 个容器化 RL 实例，按上游报告协议评分。我们的重新上传——RL 集加上 2,132 个任务的 Multi-SWE-bench 评估集——修复了 HF schema，并且我们隐藏了原始容器中可读的评分脚本和 test.patch。
SWE-rebench-V2（Badertdinov 等，Nebius - 论文、swerebench_v2_v1）持续将新的 GitHub PR 挖掘为任务——涵盖 20 种语言的 32,079 个任务，因时效性而自然去污染。我们内置了上游日志解析器（约 3.6k 行，每种语言生态一个）以保证评分保真度，在评分前隐藏测试补丁，并默认使用我们经过过滤和验证的重新上传版本。
Scale-SWE（Zhao 等 - 论文，scaleswe_v1）贡献了 20,181 个 Python 任务，测试补丁和脚本在评估前才应用，完全按照作者的规定。我们重新上传的版本包含通过验证的 17,202 个实例。
SWE-Lego（Tao 等，华为 - 论文）大规模构建 SWE-bench 风格的训练数据；我们托管了 4,432 个已解决的实数据实例，外加一个经过黄金验证的变体。swelego_v1 保留了原作者的评价模式：失败的测试在 rollout 期间保持隐藏，仅在评分时应用，在此之前会将 agent 触碰过的任何测试文件重置回 base_commit。
OpenSWE（Fu 等，GAIR - 论文）将 45,320 个任务与作为数据存储的每任务评估脚本配对。openswe_v1 在评分写入并运行评估脚本之前，将其保持在沙箱之外。
Senior SWE-Bench（Snorkel AI - 仓库，senior_swe_bench_v1）超越了问题解决：50 个公开的调查与设计任务，取自 12 个生产级开源仓库（gitea、posthog、teleport、immich 等），由上游验证器流水线评分——原生 pytest/vitest 检查加上可选的 LLM 评分标准评判。每个任务都从预构建的 Prime 镜像运行，并针对上游解决方案进行黄金验证。

我们所有经过筛选和验证的 SWE 重新上传版本都位于 Hugging Face 上的 SWE RL 集合中，每个都附有数据集卡片，详细记录与上游相比的确切变更、验证方法，以及为审计保留的排除项。

终端任务

Terminal-Lego（Yang 等，华为 / 港大 - 论文，terminal_lego_v1）是约 13,800 个经 Docker 验证的 Terminal-Bench 风格任务，由 SWE-Lego 团队从真实的 StackOverflow 问题构建——经过筛选、通过级联 LLM 生成转换，并且只有在通过 Docker 往返验证后才保留。每个任务是一个目录，包含指令、隐藏的 pytest 评分器和参考解决方案，并固定到 Prime 注册表中预构建的每任务镜像。
TMax（Ivison 等，Ai2 / UW - 论文，tmax_v1）是 14,600 个终端任务，固定在我们版本化的任务注册表中，每个任务都有预构建的 Prime 镜像。整个语料库经过了一次 validate 检查，全部 14,600 个沙箱均成功启动并完成设置，之后任务集才发布。
Terminal-Bench 2（Merrill 等，斯坦福 / Laude Institute - 论文）是社区标准的终端评估：89 个经过严格验证的任务，每个都有自己的环境、人工编写的解决方案和测试——上述语料库所参照的基准。terminal_bench_2_v1 通过相同的 Harbor 任务集将其封装，因此评估套件和训练语料库共享一种任务格式和一份评分契约。
OpenThoughts-TBLite（OpenThoughts-Agent 团队，Snorkel AI & Bespoke Labs - 博客，openthoughts_tblite_v1）是一个高信号的 100 任务基准，用于迭代终端 agent，每个任务都在自己的预构建容器中运行，并由隐藏的评分器评分。

所有终端任务集都位于 environments/terminal 下，附有一份概述 README，涵盖该组以及各任务集的变更日志。

搜索任务

这些搜索任务集共享一个设计决策：它们是与 harness 无关且无需工具的。任务集只提供问题和评分标准——harness 自带搜索工具（Codex harness 的内置网页搜索、我们 harness 的搜索技能，或你自己的工具）。相同的任务可以训练和评估任何具备搜索能力的 agent，而无需环境规定检索流程。

WideSeek（wideseek_v1）- WideSearch 风格的表格编制（Xu 等，RLinf / 清华大学 - 论文）：三个相互重叠的 2 万样本划分，共包含 44,632 个唯一问题；width 划分要求以完整的 Markdown 表格作为答案，按条目级单元格 F1 评分。
PaperSearchQA（papersearchqa_v1）- 54,907 个训练 + 5,000 个测试生物医学深度研究问题（Burgess 等，斯坦福大学 - 论文），由评判模型对照可接受答案进行评分。
OpenSeeker（openseeker_v1）- 11,677 个网络研究问答任务（Du 等 - 论文），使用原始评判提示词。
DeepDive（deepdive_v1）- 2,234 个 RL 问题，外加一个 1,016 问题的 SFT 划分（Lu 等，Z.ai / 清华大学 - 论文），由严格的框选答案评判模型评分的困难多跳研究任务。
S1-DeepResearch（s1_deepresearch_v1）-（Dong 等 - 论文）：约 15,000 个带标准答案的多跳解析问题，由评判模型评分。
REDSearcher（redsearcher_v1）- 1,000 个长时程网络研究问题（Chu 等 - 论文）。
BrowseComp（browsecomp_v1）- 1,266 个问题的浏览基准（Wei 等，OpenAI - 论文），采用其原始的 Explanation/Exact Answer/Confidence 格式。
BrowseComp-Plus（browsecomp_plus_v1）- 830 个 BrowseComp 查询，重新基于一个固定的、经人工验证的 100,195 篇网络文档语料库（Chen 等，滑铁卢大学 - 论文）。自带搜索的唯一例外：该任务集在语料库上提供基准自有的 BM25 search 工具，因此检索器是一个受控变量，运行可复现——由基准的 HLE 风格评判模型评分，同时跟踪证据召回率与准确率。

所有搜索任务集都位于 environments/search 下，并附有一个概述 README，涵盖该组及每个任务集的变更日志。

训练

上述所有内容都可直接接入 prime-rl。这个训练配置在 6 个 H200 节点上于 scaleswe_v1 上训练 GLM-4.5-Air，耗时 2 天。

下一步

这里描述的集成、验证 harness 和测试可见性变更位于 research-environments；经过验证的 SWE 数据集在这个 Hugging Face 集合中。将 prime-rl 指向任意任务集 id，你就可以开始训练了。如果你在这些任务集上训练，请引用原始论文——所有论文的 BibTeX 都收集在 SWE 任务集 README 中，我们的重新上传保留了上游许可证，并在每张卡片上链接回源数据集。

奖励信号可能朝两个方向说谎。假阳性就是奖励黑客行为，我们在自己的训练运行中亲眼见过它发生：智能体与评分机制共享同一个沙箱，而在 RL 压力下的策略最终会找到任何遗留的缝隙——它可以编辑的测试文件、可以篡改的评分状态、泄露预期答案的产物。在评分前扣留评分材料能显著提高门槛，但只要评分在智能体所在的环境中运行，这就只是缓解，而非保证。结构性修复已列入我们的路线图：在隔离的沙箱中评分，使智能体可以触及的环境与对其评分的环境彼此分离。

相反的一类失败——假阴性——是验证从构造上就无法捕捉的。从已合并 PR 中挖掘的任务继承了该 PR 的测试，而这些测试往往断言的是实现细节而非行为——某个特定的错误消息字符串、某个私有辅助函数的名字、某种精确的返回结构。一个以不同但同样正确的方式修复了底层问题的智能体仍然无法通过它们，奖励就表现为假阴性。金标准补丁验证对此视而不见：原始补丁按定义就能通过它自己的测试。在 RL 规模下，这些近乎命中是训练信号中的纯噪声——模型因正确的工作而受到惩罚。我们内部为缓解这一问题所做的努力是Agentic Judging。更多内容即将发布。

我们正在继续将验证扩展到尚未通过验证的数据集，并通过同一条透明流水线发布经过筛选的重新上传版本。如果你正在构建智能体，而这份清单中缺少某些东西，请告诉我们——或者更好的是，把它移植过来：任务集契约很小，而我们的沙箱承担了繁重的工作。

@article{primeintellect2026scalingagenticrl,
author = {Daniel Auras and Prime Intellect Team},
title = {Scaling Agentic RL: 365,000+ Environments for SWE, Terminal, and Search},
journal = {Prime Intellect Blog},
year = {2026},
month = {July},
note = {https://www.primeintellect.ai/blog/scaling-agentic-rl}
}