Terminal-Universe: Turning Agent Trajectories into Scalable Terminal Environments——将智能体轨迹转化为可扩展的终端环境

一、研究背景与问题

核心矛盾

• 轨迹丰富，环境稀缺：终端代码智能体产生大量轨迹数据，但真实、可执行的环境却很少

• 轨迹 vs 环境：轨迹是固定的单次演示，质量受限于生成模型；环境可重复查询、验证、生成更难任务，是后训练真正需要的资源

• 人工构建环境的瓶颈：专家构建的基准（如 Terminal-Bench）质量高但数量有限，无法满足大规模后训练需求

现有方法的三条路径及局限

关键洞察：轨迹本身记录了环境的文件结构、内容变化，足以反向重建可执行环境——这正是 Terminal-Universe 的出发点。

二、核心方法

整体思路

将"从环境生成轨迹"的传统流程反向：从轨迹恢复环境 → 在环境中合成新任务 → 用教师模型生成解决方案轨迹 → SFT 训练

2.1 环境重建（三阶段）

阶段一：确定性回放

• 按时间顺序回放文件读写操作

• 恢复每个文件在智能体修改之前的状态

• 排除智能体创建的文件和所有后期更改

• 结果：部分工作空间（只包含轨迹中暴露的文件）

阶段二：智能体补全

• 补全智能体根据任务和现有文件，填充缺失内容：

  • 创建缺失的配置文件、脚本、数据、模式文件

  • 补全被截断的文件

  • 安装/配置依赖项

• 关键约束：不实现任务本身，只提供可工作的上下文

阶段三：环境过滤

• 智能体评判员检查工作空间是否"任务充分"

• 充分标准：源文件、配置、数据结构足以让有能力智能体开始工作

• 结果：37,273 个充分环境（终端池 93.5%，SWE 池 77.1%）

2.2 四种重新查询机制

① 意图恢复

• 从源轨迹反向提取用户的原始意图

• 单轮 → 直接使用；多轮 → 合并澄清和约束

• 恢复出：核心目标、成功标准、约束条件

② 单工作空间合成

• 在单个重建的工作空间内探索

• 每个环境生成 5 个候选任务（基于真实场景、可验证、多样化）

• 随机选 1 个进行展开和验证

• 产出：25,386 条轨迹

③ 广度扩展：跨工作空间合成

• 挖掘不同工作空间间的方向性依赖关系

• 流程：

  • 分析每个工作空间的领域和能力

  • TF-IDF 检索相似候选对

  • LLM 判断依赖方向（参考有，目标缺）

  • 生成跨代码库任务（目标可写 + 参考只读）

• 任务特点：求解者必须自己阅读参考仓库、内化实现、适配到目标

• 教师 pass@1 从 72.3%（单工作空间）降至 49.2%（跨工作空间），难度显著更高

• 产出：3,512 条轨迹

④ 深度扩展：多轮用户查询

• 已解决任务基础上引入用户智能体

• 三种交互风格：

  • 特性扩展（62.7%）：通过后加新需求

  • 特性修订（29.3%）：失败后要求修复

  • 特性冲突（8.0%）：有意覆盖之前的需求

• 核心机制：

  • 需求跟踪器记录活跃/已满足/已更新需求

  • 轮次级验证（私有验证器，求解者看不到测试）

  • 失败→自然语言抱怨，保留错误诊断和恢复监督

• 平均 4.51 轮，69.6% 包含可修复的失败

• 产出：3,079 条轨迹

2.3 验证与过滤

• 每个任务配备智能体编写的 pytest 验证器

• 要求：新功能测试在初始状态必须失败（"红检"），保留测试必须通过

• 教师模型展开解决方案（Qwen3.7-Max，Claude Code 框架）

• 仅保留所有测试通过的轨迹

• 总 SFT 数据：31,977 条记录，约 14.2 亿 token

三、实验与结果

3.1 实验设置

• 基础模型：Qwen3.5-27B

• 训练：SFT 两轮，学习率 7×10⁻⁶，批次 256，序列长度 256k

• 单轮评估：Terminal-Bench 2.0/2.1（Terminus2-XML 和 Claude Code）

• 多轮评估：EvoCode-Bench v2（MT@4 和 Case Score）

3.2 主要结果

单轮性能（Terminal-Bench 2.1）

多轮性能（EvoCode-Bench v2）

对比其他任务合成方法：Terminal-Universe 在所有对比方法中表现最佳（表 3）。

3.3 关键消融结论

四、数据统计

源数据与重建规模

最终 SFT 语料

五、主要贡献

六、局限性与未来方向

Terminal-Universe 通过从已有智能体轨迹中反向恢复可执行环境，再在这些环境中合成新任务并用强教师生成高质量演示，实现了终端智能体训练数据的规模化、高质量、可验证构建，在单轮和多轮基准上均取得显著提升。

这里是自己的论文阅读记录，感兴趣的话可以参考一下，如果需要阅读原文的话可以看这里，如下所示：

摘要

随着基于终端的代码智能体日益普及，相应的智能体轨迹已大规模积累，而真实的、可执行的环境仍然稀缺。然而，环境才是智能体后训练真正需要的资源：每个环境都可以被重新查询以生成许多可验证的任务，并提供执行反馈，而轨迹只是一个固定的演示。我们观察到，与其从头生成环境，不如利用现有智能体轨迹中的工具执行历史，这些历史揭示了它们运行所在环境的结构和内容，这使得从轨迹本身重建这些环境成为可能。因此，我们引入了 Terminal-Universe，一个框架，它将每条轨迹转化为一个可重用的环境，并对其进行探索以合成新任务和进行持续交互。具体来说，Terminal-Universe 回放轨迹中记录的文件操作，将每个文件恢复到智能体修改之前的状态，从而产生一个部分工作空间；然后，一个补全智能体提供缺失的文件和依赖项。在这个恢复的工作空间上，我们既重建了原始意图任务，也合成了全新的任务。此外，我们还沿着两个互补的维度扩展环境对应的任务：广度（breadth）和深度（depth），以复现真实工程实践中的常规模式。对于广度，我们挖掘相关环境之间的方向性依赖关系，并合成跨越多个代码库的跨工作空间查询，正如开发者在现实世界开发中经常做的那样。对于深度，我们将初始的单轮查询扩展为多轮会话，通过一个用户智能体来捕捉迭代的用户反馈和需求细化。将 Terminal-Universe 应用于公开可用的终端智能体轨迹，产生了 37.3k 个任务充分的环境。在该语料库上对 Qwen3.5-27B 进行监督微调，在 Terminal-Bench 2.1 上将单轮性能提升了 11.9 个点，在 EvoCode-Bench v2 MT@4 上将多轮性能提升了 13.8 个点。

1 引言

随着基于终端的代码智能体日益普及，它们产生的轨迹已大规模积累，而真实的、可执行的环境仍然稀缺。这种差距很重要，因为轨迹和环境的价值并不等同。一条轨迹是一个固定的、单一的记录：其质量受限于产生它的策略模型的响应，并且我们无法检查它对代码库所做的更改是否正确。而环境则没有这些限制，因为同一个任务可以由更强的模型重新解决，结果可以由我们自己的测试来验证，并且可以在同一个工作空间上提出更难的任务。因此，对于后训练而言，环境才是值得扩展的资源。专家编写的基准测试展示了理想环境的样子。例如，Terminal-Bench (Merrill et al., 2026) 为每个任务都配有一个定制容器、一个指令和一个可执行的验证器。这种可靠性来源于人工努力，这也限制了可以构建的任务数量，而有效的后训练需要比人工策划多得多的环境。因此，提供大规模、真实、可验证的训练环境是我们面临的挑战。

现有工作通过三种方式扩展可执行环境。基于代码仓库（Repository）的方法从真实代码仓库的 git 历史中构建任务 (Pan et al., 2024; Jain et al., 2025)。对于过去修复的一个错误，他们使用 git 将代码仓库回滚到修复前的状态以形成环境，将原始错误报告作为任务，并复用随修复而来的测试来检查解决方案。扰动（Perturbation）方法选取一个通过其测试的代码仓库，注入一个错误使得某些测试现在失败，并要求智能体修复它 (Yang et al., 2025; Lin et al., 2026)。少数几个代码仓库可以通过这种方式产生许多任务，但每个任务都是修复任务，且任务范围受限于源代码仓库和可注入的错误类型。任务条件合成（Task-conditioned synthesis）根据类别或组合轴 (Gandhi et al., 2026; Ivison et al., 2026)、技能分类法 (Hua et al., 2026) 或技能图 (Fan et al., 2026) 的指导，从头开始一起生成任务及其环境。这些方法提供了对覆盖范围和任务-环境对齐的控制，但环境不与任何真实项目关联，因此其真实性完全依赖于生成器，而生成器倾向于产生小型、整洁的工作空间，而非真实代码。

图 1：Terminal-Universe 概览。轨迹和环境是同一 episode 的两个视图，因此先前的工作从环境中展开轨迹，而我们则反转映射，从轨迹中恢复环境（左）。重建分两个阶段进行，先是确定性回放，然后是智能体补全（中）。每个恢复的环境随后在单个工作空间内、跨多个依赖工作空间或多个用户轮次中被重新查询（右）。图 2 详细说明了每种机制。

在这些途径中，环境构建要么从现有环境开始，要么与从头生成的新任务耦合。轨迹，作为它们运行所在环境的观测，作为一种资源在很大程度上仍未被充分探索。轨迹中记录的工具调用已经揭示了其运行环境的内容和结构。例如，工具 Read 显示文件内容，Write 和 Edit 显示工作空间如何变化。这足以重建一个可执行的原始工作空间副本。因此，我们提出了 Terminal-Universe (图 1)，一个框架，它将每条轨迹转化为一个可重用的环境，并对其进行探索以合成新任务和进行持续交互。

具体来说，为了基于轨迹构建环境 (§3.1)，我们首先回放记录的文件操作，并将每个文件恢复到智能体更改之前的状态，保留智能体自身的编辑，以便工作空间以未解决的状态开始。由于回放通常只产生部分工作空间，一个补全智能体会自动提供任务所需的缺失文件和依赖项，同时不泄露解决方案。对于相应的任务，我们既重建原始意图查询，也合成全新的查询。此外，为了更好地匹配真实世界的软件工程场景，我们还沿着两个互补的维度扩展环境上的任务：广度和深度 (§3.2)。广度扩展超越了大多数任务合成所假设的单一代码仓库设置。我们识别相关环境之间的依赖关系，并构建跨越多个代码库的跨工作空间任务，这些任务难度更大，例如，阅读参考实现、将某个特性从一个项目迁移到另一个项目，或连接两个组件。深度扩展将单轮任务转变为多轮任务。智能体完成初始查询后，一个用户智能体会随着工作空间的变化提出有根据的后续问题——用新需求扩展它，或者，当一轮失败时，根据出错原因要求修复。我们验证每一轮，并将结果作为自然的、用户可见的反馈反馈给智能体。每个新任务都附带一个由智能体在容器内编写的验证器，我们只保留所有测试都通过的轨迹 (§4)。

在公开可用的终端智能体轨迹上，该流水线产生了 37.3k 个任务充分的环境。在这些环境之上，我们生成新的查询，并使用 Qwen3.7-Max 作为教师为每个任务展开一个解决方案轨迹。在生成的数据上训练 Qwen3.5-27B 验证了我们方法的有效性：它在单轮基准测试 Terminal-Bench 2.1 上提高了 11.9 个点，在多轮基准测试 EvoCode-Bench v2 MT@4 上提高了 13.8 个点 (§5)。大量的消融实验证实每个组件都有贡献，最值得注意的是，在重建环境中重新解决问题远远优于模仿原始轨迹。

表 1：代表性环境和训练数据构建方法的比较。策略总结了用于构建环境或训练任务的主要机制。环境计数统计可重用的源代码仓库/工作空间或独立构建的环境，任务数给出报告的任务或训练实例数量。验证表示可执行的任务验证器，多轮表示扩展的多轮查询，跨工作空间表示跨工作空间合成。

总之，我们做出以下贡献：

• 环境重建。我们将记录的智能体轨迹重新定义为可重用可执行环境的来源，并通过确定性回放和智能体补全来重建每一个——无需原始代码仓库或从头构建。

• 重新查询方法。我们通过生成新任务来扩展每个重建环境的效用。除了标准的单工作空间、单轮任务外，我们还通过跨工作空间任务合成贡献了广度扩展，并通过多轮用户查询贡献了深度扩展。每个任务都配有一个智能体撰写的验证器，只有通过的轨迹才被保留。

• 实证验证。在生成的语料库上微调 Qwen3.5-27B，在 Terminal-Bench 2.1 上比同一基础模型提高了 11.9 个点，在 EvoCode-Bench v2 MT@4 上提高了 13.8 个点。消融实验证实每个组件都有贡献，尤其值得注意的是，在重建环境中重新解决问题远远优于模仿原始轨迹。

2 相关工作

终端环境扩展。 现有方法通过三种主要途径扩展可执行工作空间：从真实开发历史中恢复代码仓库状态、修改正常运行的工作空间，或从生成的规格说明构建特定任务的环境。SWE-Gym (Pan et al., 2024) 和 R2E-Gym (Jain et al., 2025) 从与历史问题或提交相关的代码仓库版本构建环境。SWE-smith (Yang et al., 2025) 和 CLI-Gym (Lin et al., 2026) 从正常运行的代码仓库或 CLI 工作空间开始，并向其中引入错误或故障。SETA (Shen et al., 2026b) 则通过合成和自适应环境演化来扩展可验证的终端环境以用于强化学习。另一个独立的家族联合生成终端任务及其容器化的执行环境；我们下面讨论它们的任务构建策略。Terminal-Universe 则将记录的智能体轨迹作为起点。它回放每条轨迹中记录的文件操作，并使用智能体补全来恢复缺失的项目上下文，产生可重用、可执行的工作空间。

终端任务合成。 现有方法从抽象先验或具体可执行环境中推导任务。自顶向下（Top-down）流水线从类别或种子生成任务-环境对 (Gandhi et al., 2026; Pi et al., 2026; Zhu et al., 2026)，而更多结构化变体围绕能力分类、组合轴或技能图组织生成过程 (Hua et al., 2026; Ivison et al., 2026; Fan et al., 2026)。其他方法使用智能体技能、可执行元任务或求解器反馈来多样化和校准生成的任务 (Cheng et al., 2026; Pan et al., 2026; Meng et al., 2026)。

基于环境（Environment-grounded）的方法则从工作代码和项目上下文中推导任务。它们扰动健康环境、挖掘代码仓库文档、将任务基于真实问题，或在共享环境中联合实现指令、解决方案和验证器 (Lin et al., 2026; Wu et al., 2026a; Yang et al., 2026; Shi et al., 2026)。RST 通过延长解决方案并重新对齐其任务、验证器和环境来递归扩展已验证的种子 (Li et al., 2026b)。Terminal-Universe 将过去的智能体轨迹作为起点：它在生成新任务之前重建它们的工作空间，无论是在工作空间内部还是跨工作空间。

交互式和多轮智能体。 超越孤立的、单轮提示，最近的基准测试将智能体交互建模为动态的多轮对话。InterCode 通过容器化 shell 中的执行反馈形式化交互式编码 (Yang et al., 2023)。SWE-INTERACT (Raghavendra et al., 2026) 使用模拟用户逐步揭示需求并提供有针对性的修订，而 SWE-Together (Wu et al., 2026b) 通过一个状态条件用户模拟器回放真实的用户-智能体会话，在被评估的智能体取得进展时提供反馈。ICAE-Bench (Peng et al., 2026b) 使用自动化用户智能体从不完整的产品需求中评估交互式项目构建。在持久工作空间中，EvoCode-Bench v2 (Shen et al., 2026a) 评估智能体在连续开发请求中的表现。Terminal-Universe 通过深度扩展拥抱这种交互式设置，将重建的工作空间扩展到多轮会话中，以捕捉迭代的用户反馈和需求细化。

表 1 将 Terminal-Universe 与代表性方法进行了定位。与先前工作相比，它从记录的轨迹构建环境，并沿广度（跨工作空间合成）和深度（多轮查询）两个维度扩展任务。

3 Terminal-Universe

图 2 详细说明了环境重建、四种重新查询变体以及验证的机制。以下小节分别描述环境重建 (§3.1)、重新查询 (§3.2) 和验证 (§3.3)。

3.1 环境重建

从轨迹 τ 中记录的文件和命令操作，我们恢复一个可执行的工作空间 E^，它近似于产生 τ 的环境 E。这种恢复本质上有损的，因为未访问的文件、隐式系统依赖项和外部网络资源没有留下直接痕迹。因此，我们分三个阶段进行重建：确定性回放恢复 τ 直接暴露的文件状态，智能体补全提供其遗漏的潜在上下文，环境过滤只保留对恢复的任务 q 足够的工作空间。

阶段 1：确定性回放。 回放按时间顺序处理 τ 中的读、写和编辑操作，以恢复每个被访问路径在轨迹中可见的最早和最新文件内容。重建的初始工作空间 E^0​ 收集每个预先存在的文件在其最早观察到的版本（在智能体首次更改之前）的内容；智能体创建的文件被排除，智能体的文件更改被单独记录以供后续验证。由于轨迹只暴露智能体接触过的路径，并且当轨迹只显示文件的部分内容或终端输出被截断时，文件内容可能不完整，因此 E^0 仍然是一个部分工作空间。

阶段 2：智能体补全。 给定部分工作空间 E^0​ 和恢复的任务 q，一个补全智能体创建缺失的文件、补全部分文件，并恢复使 q 可解决（但不实现它）所需的依赖项。我们用 E^ 表示最终补全的工作空间。我们将此阶段应用于所有回放的工作空间，其对工作空间复杂度的影响详见 §4。

阶段 3：环境过滤。 一个补全的工作空间只有在其暴露足够的项目上下文以支持其任务时才是有用的。一个智能体评判员使用只读的 shell 和文件工具检查每个 E^，并根据恢复的任务 q，标记工作空间为充分或不充分，依据是其源代码、配置、数据和结构是否为有能力的智能体提供了足够的上下文来处理该任务 (§ B.3)。只有充分的工作空间被保留用于下游任务生成，每个阶段的充分率和最终计数在 §4 中报告。

每个重建的工作空间运行在标准化的 ubuntu:24.04 容器中，具有网络访问权限。与特定于代码仓库的镜像相比，这种设计降低了成本并简化了部署，尽管先前工作报告称其解决率略有降低 (Zeng et al., 2026)。

3.2 重新查询

虽然重建产生了可执行环境，但重新查询决定了如何有效地利用其潜在能力空间。我们引入了四种互补的重新查询机制，在整篇论文中分别表示为意图恢复、单工作空间、跨工作空间和多轮。意图恢复重建源任务，而单工作空间在单个工作空间内合成新任务。跨工作空间通过连接相关工作空间提供广度，多轮通过将初始查询扩展为交互式会话来提供深度。

意图恢复。 将一个或多个源用户请求合并为一个独立的任务。

我们将每条源轨迹规范化为用户请求、智能体行动和文件更改的时间流。对于单轮轨迹，唯一的实质性用户请求直接定义任务。对于多轮轨迹，第一个实质性用户请求确定任务主题，而后续请求在它们澄清、约束或扩展同一任务时被纳入；不相关的任务转移被排除。我们使用智能体行动和文件证据来解释请求，但只保留用户陈述的需求 (§ C.1)。

单工作空间合成。 从单个重建的工作空间推导新的查询。

一个离线生成器检查每个工作空间，并在落地性、结构多样性和可验证性约束下合成五个独立的候选任务。我们为每个环境随机选择一个有效候选用于展开和验证。

广度扩展。 在单个查询中连接相关工作空间。

跨工作空间合成。 为了合成跨越多个代码库的任务，我们发现恢复环境之间的方向性依赖关系。一个智能体首先分析每个工作空间的技术领域和已实现能力。然后，我们通过 TF-IDF 最近邻搜索检索候选对，并采用 LLM 评判员来识别方向性依赖边，即目标工作空间缺少参考工作空间中已实现的某项能力。

我们为每一对分配恰好一个任务。每个跨工作空间任务将一个可写的目标工作空间与一个以只读方式挂载在单独路径的参考工作空间配对。任务生成器确认功能差距是真实的，并指定目标中弥合该差距的可观察行为，这些行为可通过确定性的本地命令进行验证。查询仅提供这些目标行为和参考的挂载路径，而不提供其内部细节，使参考成为真正的依赖项。因此，求解者必须自行导航、内化并适配参考实现。

深度扩展。 通过用户智能体的后续问题扩展已解决的终端任务。

多轮用户查询。 从一个初始的终端查询开始，我们在编码轮次之间保留工作空间，并在初始响应之后引入一个用户智能体。延续过程采用两种协调机制以确保连贯且真实的多轮轨迹：

在各轮次中，用户智能体的请求分为三种交互风格：(i) 特性扩展，在成功验证后引入新的落地需求；(ii) 特性修订，由测试失败触发，基于观察到的行为要求错误修复；以及 (iii) 特性冲突，修改或覆盖先前的规格说明以反映变化的用户意图。每种请求的风格自然地遵循轮次结果和会话上下文，观察到的分布情况在 § E.3（表 17）中报告。会话持续最多六个后续轮次，或直到发出终止标记。

图 3 报告了经过 §3.3 中轮次级选择后的延续数据的通过/失败模式：保留的 3,079 条记录平均有 4.51 轮，其中 69.6% 包含一个会话随后修复的失败，保留了恢复监督信息。

图 3：多轮会话中的通过/失败模式。

3.3 验证与过滤

智能体验证器构建。 每个单工作空间或跨工作空间任务都配有一个由专用智能体在目标容器内编写的可执行验证器。根据任务规格说明和工作空间文件，验证器智能体通过迭代的本地执行制作一个自包含的 pytest 套件，严格评估提示中指定的公共接口和预期行为 (§ D)。

解决方案展开。 候选解决方案使用教师模型在任务容器内的 Claude Code 框架 (Anthropic, 2026) 中展开。展开使用温度 1.0，top-p = 0.95，交错思考，上下文窗口为 256k token，单次响应限制为 65,536 token，在 176k token 时触发主动总结，最多 500 个智能体轮次，壁钟超时为四小时。任务环境提供容器化的网络访问以获取缺失的依赖项 (§3.1)。

验证和数据选择。 对于单工作空间和跨工作空间，编写的测试套件在展开后的最终工作空间状态下运行，只有当所有测试都通过时，轨迹才被接受。多轮数据在轮次级别进行选择：我们从终止的会话中修剪连续失败的轮次后缀，并且仅当会话包含至少两个通过验证的轮次时才保留它。在成功恢复之前的中间失败被保留，为错误诊断和恢复提供监督。接受的轨迹被格式化为多轮 SFT 演示，并针对评估基准进行严格去污 (§5)。

为了为上述机制提供具体直观的理解，我们在附录中详细介绍了几个综合案例研究。§ E.1 追踪了一个轨迹到查询的示例，§ E.2 跟踪了一个跨工作空间代码仓库集从候选来源到选定任务的过程，§ E.3 跟踪了一个多轮延续从验证器驱动的修订到受控需求变更的过程（图 8）。§4 报告数据集大小，§F 报告交互统计信息。

4 规模化数据构建

4.1 种子选择

我们从不同的终端风格 CLI 和软件工程语料库中获取原始智能体轨迹。如果执行轨迹结束时观察到的工作空间状态包含至少 5 个文件和 100 行代码，则该轨迹被保留为可行种子。为防止数据泄漏，我们严格过滤掉所有源自 Terminal-Bench 的数据集。完整的来源细分和选择统计信息详见 § A。

4.2 重建统计

从源轨迹池中，重建流水线产生了 68,263 个重建环境。如图 4 所示，回放的终端工作空间最初包含很少文件，因为在原始展开期间生成的解决方案文件被保留。智能体补全显著丰富了这些环境，将平均文件数从 2.9 增加到 22.4。虽然 SWE 种子源自更丰富的代码仓库状态，但补全同样扩展了其上下文广度（完整的复杂度分布见表 13）。

图 4：智能体补全前后的平均工作空间大小。

在污染过滤和代码仓库级去重之后，我们将第 3.1 节中的阶段 3 充分性评判器应用于存活的补全环境。

表 2：在恢复意图下的工作空间充分性。

如表 2 所示，仅确定性回放对终端工作空间的充分率为 40.2%，对 SWE 工作空间为 20.1%。智能体补全显著提高了覆盖率，在代码仓库级去重后，分别对 38,294 个评估的终端环境和 1,900 个 SWE 代码仓库（每个代码仓库一个代表性重建）达到了 93.5% 和 77.1%。总共，任务导向的评估识别出 37,273 个完全充分的环境，适用于下游任务生成 (§ A)。

图 5 展示了重建终端池的多样性：Python 是主要编程语言 (84.7%)，其次是 C++ 和 C，数据处理、DevOps 和安全工作负载合计占技术领域的 80% 以上。

4.3 SFT 语料库组成

这些任务充分的环境是我们四种重新查询变体的基础：意图恢复重建原始任务，单工作空间产生新的仓库内任务，跨工作空间发现仓库间的依赖挑战，多轮将初始查询扩展为迭代会话。在整个终端池中，经过验证器过滤的单工作空间、跨工作空间和多轮合成产生了 31,977 个 SFT 演示（25,386 个单工作空间，3,512 个跨工作空间，和 3,079 个多轮轨迹），总计约 14.2 亿训练 token。中位数交互统计信息在 §F 中提供。

5 实验

5.1 设置

训练。 我们在 Terminal-Universe 数据上对 Qwen3.5-27B 进行两轮 SFT 微调。我们使用恒定的 7×10⁻⁶ 学习率，全局批次大小为 256，序列长度为 256k token。训练前，我们针对 Terminal-Bench 任务运行 13-gram 污染检查，并从所有四种重新查询变体中排除源自 Terminal-Bench 的数据集。

单轮评估（Terminal-Bench 2.0 和 2.1）。 我们使用 Claude Code（版本 2.1.126）和 Terminus2 (Merrill et al., 2026) 及 XML 解析器评估 Terminal-Bench。评估镜像了解决方案展开 (§3.3) 的解码和执行配置，采用温度 1.0，top-p = 0.95，交错思考，256k 上下文窗口，65,536 token 轮次限制，176k token 主动总结，最多 500 个智能体轮次，以及四小时壁钟超时。对于 Claude Code，交互式和网络检索工具（WebFetch， WebSearch, AskUserQuestion, EnterPlanMode, ExitPlanMode）被禁用。每个容器运行在 12 个 CPU 核心和 32 GiB 内存上。报告的分数代表六次独立运行的平均通过率。Terminal-Bench 2.0 和 2.1 之间的差异记录在基准更新中。

多轮评估（EvoCode-Bench v2）。 我们在 EvoCode-Bench v2 (Shen et al., 2026a) 上评估深度扩展，它包含 26 个编码任务和 227 轮（每个任务 5-15 个请求）。工作空间和会话是持久的，累积验证器检查当前和先前的活跃需求。我们的 Qwen3.5-27B 检查点使用 Terminus2-XML，温度 1.0，交错思考，256k token 上下文，每轮 65,536 token 限制，176k token 主动总结，每个请求轮次最多 500 个智能体轮次，每个状态化任务总壁钟限制为 10 小时。每个任务评估四次独立运行。MT@4 使用失败停止评分：一次运行仅在第一次失败前连续通过的轮次获得分数，并且如果任何运行成功到达该任务-轮次，则该任务-轮次被计分。该分数对每个任务内已计分的轮次进行平均，然后跨任务平均。案例分数对任务内的验证器案例通过率进行平均，然后跨任务和运行平均，以衡量部分进展。

5.2 主要结果

表 3 报告了单轮和多轮性能。在完整混合数据集（经过验证器过滤的单工作空间、跨工作空间和多轮轨迹，共 32.0k 条记录）上微调 Qwen3.5-27B，在 Terminal-Bench 2.0 上达到 52.8%，在 Terminal-Bench 2.1 上达到 58.1%（分别比基础模型提高 11.2 和 11.9 个百分点）在 Terminus2-XML 下。在 Claude Code 下，它在 Terminal-Bench 2.1 上达到 58.2%（比基础模型提高 10.4 个百分点）。

表 3：Terminal-Bench 和 EvoCode-Bench v2 结果 (%)。Terminal-Bench 列报告平均 Pass@1。绿色粗体标记任务合成方法中的最佳分数，蓝色下划线标记第二佳分数。带 \\* 的分数是我们按照 §G 中的配置在发布模型上测量的，其他分数取自相应报告。

在 EvoCode-Bench v2 上，完整混合数据集将 MT@4 从 6.3 提高到 20.1，案例分数从 67.8 提高到 76.1，表明完整混合数据集训练也提高了在具有累积需求的持久任务上的性能。

6 分析与消融研究

我们的方法包含多个设计选择，本节将隔离每个选择的贡献。我们提出以下问题：(1) 重建环境并重新解决它是否真的比在原始轨迹上训练更好 (§6.1)？(2) 智能体补全是否重要，还是确定性回放就足够了 (§6.2)？(3) 验证器过滤是否值得丢弃的数据 (§6.3)？(4) 在固定的预算下，应如何在重新查询轴——广度 (§6.4)、深度 (§6.5) 以及更多环境与更多查询之间分配 (§6.6)？我们最后测试了该流水线是否能迁移到终端工作空间之外 (§6.7)。

6.1 任务重新解决

这项消融研究询问是否真的需要重建：重新解决恢复的任务是否比简单模仿原始轨迹更好？表 4 在 Terminal-Bench 2.1 上比较了这两者。为了保持比较的清晰性，意图恢复未经过验证器过滤，因此验证器选择在此不起作用。

表 4：Terminal-Bench 2.1 上源轨迹 SFT 和意图恢复的比较 (%)

重新解决优于源轨迹 SFT。源轨迹和意图恢复使用相同的 Qwen3.5 聊天模板和工具调用模式进行 SFT。源 SFT 保留了原始智能体的行为，而意图恢复使用更强的教师来在重建的工作空间中重新解决恢复的任务。

6.2 智能体补全的影响

这项消融研究询问智能体补全是否物有所值，还是仅确定性回放就足够了。我们通过在与意图恢复语料库上训练来隔离第二个重建阶段，这些环境仅使用回放重建，没有补全。仅回放变体在确定性回放重建的 35,809 个源实例上训练，而补全变体是相同数量的生产级意图恢复语料库。两者共享恢复的查询和教师配置，仅在环境重建模式上有所不同。

表 5：智能体补全对意图恢复的影响。

智能体补全有所帮助。在相近的训练量下，在补全环境上训练比在仅回放环境上训练高出 4.2 个百分点（52.9 对 48.7），并且运行更稳定（±1.4 对 ±3.5）。这与表 2 中的充分性结果一致：仅回放使大多数终端工作空间任务不充分，而补全恢复了重新解决所依赖的执行上下文。

仅回放监督仍然比基础模型有所改进。仅回放变体仍然比基础模型提高了 2.5 个百分点（从 46.2 到 48.7）。检查其展开过程发现，当面对不完整的工作空间时，教师通常会在处理任务之前修复缺失的文件或进行设置。这些轨迹仍然有用，但部分监督侧重于修复工作空间而不是解决恢复的任务。

6.3 验证器过滤的作用

这项消融研究询问丢弃验证失败轨迹是否值得移除的数据量。对于每种合成方法，我们比较在同一启动任务池中，使用所有教师轨迹与仅使用通过验证的子集进行训练的效果。

表 6：验证器过滤对单工作空间和跨工作空间的影响。

验证器过滤对于更困难的任务更为重要。对于每种合成方法，我们比较在同一启动任务池中，所有教师轨迹与通过验证的子集。在单工作空间数据上，通过验证的子集表现与完整语料库相似（56.4 对 56.0），且记录更少。在跨工作空间数据上，保留验证失败的轨迹会将性能降低至 53.2，而通过验证的子集以不到一半的数据达到了 55.4。这种效果在多轮合成中也很明显：移除轮次级验证监督会降低 EvoCode-Bench 的两项指标（表 9）。

6.4 广度扩展

这项消融研究询问跨工作空间任务是否在单工作空间合成之外增加了监督。表 7 评估了跨工作空间相对于单工作空间基线的表现。单独的跨工作空间在 Terminus2-XML 下达到 55.4，而将其添加到单工作空间会将性能从 56.4 提升至 58.4。

表 7：Terminal-Bench 2.1 上单工作空间、跨工作空间及其混合的结果 (%)

表 8：单工作空间和跨工作空间合成的轨迹与难度特征。

表 8 对比了同一教师下的两种合成变体。跨工作空间任务产生了显著更长且更复杂的轨迹：助理轮次是 1.6 倍，工具调用是 1.9 倍，每个记录的中位数 token 是 1.5 倍。它们对教师来说也更难：pass@1 从单工作空间任务的 72.3% 下降到 49.2%。将需求基于第二个代码库迫使智能体在编辑之前阅读并协调两个代码仓库，这延长了轨迹并提高了任务难度，而不仅仅是增加数据量。

跨工作空间如何扩展广度。 单工作空间通过从每个恢复的环境中合成一个新任务来提供工作空间内的基线。跨工作空间则通过要求在可写工作空间中进行更改，并将这些更改基于相关的只读工作空间中的证据，从而扩展了这一设置。这暴露了单工作空间任务中不存在的领域-操作组合，并要求智能体跨代码库协调信息。

跨工作空间数据在何处有帮助。 混合单工作空间和跨工作空间记录在 Terminus2-XML 下达到 58.4，相比单工作空间基线 (56.4) 有所提高。图 6 按任务类别细分了这种比较。软件工程是最大的类别，包含 26 个任务，从 46.9 提高到 49.1，而更大的提升出现在模型训练 (+15.0) 和调试 (+10.0) 中。有三个类别下降了 2.1 到 2.5 个百分点，这属于最多八个任务类别的运行间变异范围内。在这个最大类别中的提升，加上总体改进，表明跨工作空间数据在单工作空间合成之外增加了有用的监督。

图 6：在 Terminus2-XML 下，将跨工作空间数据添加到单工作空间训练中时，Terminal-Bench 2.1 各类别通过率的变化。省略了单任务类别。

6.5 多轮深度扩展

这项消融研究询问多轮延续数据是否能提高在持久性、累积性任务上的性能，以及生成过程中的轮次级验证是否重要。我们在 EvoCode-Bench v2 上进行评估。

多轮数据提高了深度。 将多轮数据添加到单工作空间中，将 MT@4 从 18.4 提高到 21.0，案例分数从 71.9 提高到 76.9。较高的 MT@4 表明模型在首次失败之前完成了更长的请求序列，而案例分数的提高表明它在整个会话中通过了更大比例的验证器案例。

轮次级验证指导有效的延续。 在匹配的单工作空间 + 多轮比较中，移除轮次级验证器反馈会使 MT@4 降低 2.2 个百分点，案例分数降低 3.7个百分点（表 9）。这表明，在生成过程中，关于会话成功或失败的信号有助于产生更有效的多轮演示，这比简单地将独立的单轮轨迹拼接起来更有效。

表 9：EvoCode-Bench v2 上多轮延续的消融研究 (%)

6.6 环境数量与每个环境的查询数量

这项消融研究询问，在固定预算下，是否应优先考虑更多环境还是每个环境的更多查询。我们固定总训练记录数约为 25k，并比较源自 25k 个不同环境（每个环境一个查询）的记录与源自 5k 个不同环境（每个环境五个查询）的记录。

表 10：环境数量与每个环境查询数量的比较。所有变体均使用单工作空间合成，固定总记录数约为 25k。

在固定记录数下，从更多环境中取样表现更好。表 10 显示，从 25k 个不同环境中各取一个查询 (56.4) 优于从 5k 个环境中各取五个查询 (55.0)。在固定预算下，优先考虑环境多样性比增加每个环境的查询数更有效。

6.7 泛化到 SWE 域

为了测试该方法是否适用于终端工作空间之外，我们在从 SWE 池重建的环境上运行意图恢复，并在 Terminal-Bench 2.1 上评估所得模型，该基准包含软件工程任务。

表 11：在 Terminal-Bench 2.1 上，在 SWE 重建环境上进行意图恢复的结果。

SWE 重建在单独使用时提高了性能。在 SWE 恢复的环境上训练达到 48.6，比基础模型高 2.4 个百分点（表 11）。然而，它落后于终端池版本（52.9），这可能是由于 SWE 重建的可用工作空间较少（§4.2 表 2）。我们将这两个池的混合留给未来的工作。

7 讨论与局限性

使用更丰富的源轨迹进行扩展。 虽然 Terminal-Universe 在应用于公共轨迹语料库时显示出强大的有效性，但我们对更高质量轨迹的实证观察表明，源轨迹的复杂度与在重建环境上合成的结果展开的复杂度之间存在正相关。具有更丰富操作动态（例如多文件操作和长工具使用链）的轨迹暴露了更广泛的工作空间状态，这反过来支持更多样化和要求更高的合成任务。环境复杂度也可以通过聚合来提高：当多个会话在同一工作空间上操作时，将它们一起回放会将每个会话暴露的状态合并到单个重建中，产生比任何单个轨迹都能恢复的更复杂的环境。总之，这些观察表明，随着智能体能力的进步使复杂轨迹越来越容易获得，该框架自然会扩展。

局限性。 Terminal-Universe 也存在一些局限性。首先，我们为所有工作空间使用标准的 Ubuntu 24.04 容器，而不是通过像 SWE-Factory (Guo et al., 2026) 或 RepoLaunch (Li et al., 2026a) 这样的自动化流水线构建定制的、特定于代码仓库的环境。因此，需要专门系统依赖项或复杂编译步骤的边缘情况可能保真度较低。其次，我们重建工作空间的领域、语言和工具链分布从根本上受限于收集到的源轨迹的覆盖范围。超越这些分布进行扩展仍然是未来工作的重要方向。第三，单个教师生成任务、解决方案和验证器。因此，其能力差距可能限制任务覆盖范围，并且其在解决方案中的错误也可能被其测试遗漏。未来的工作可以使用多个教师和一个独立的模型进行验证器构建。

8 结论

在这项工作中，我们提出了 Terminal-Universe，一个基于轨迹的环境和任务合成框架，它将记录的智能体轨迹从固定的演示重新定义为可恢复、可重用的执行环境。通过确定性回放和智能体补全的两阶段过程，Terminal-Universe 恢复了潜在的工作空间状态，在每个环境中合成新任务，并跨工作空间（广度）和跨轮次（深度）扩展它们。实证评估表明，重新解决恢复的任务优于在源轨迹上进行 SFT，而经过验证器选择的单工作空间、跨工作空间和多轮轨迹同时提高了单轮和多轮终端智能体的性能。总体而言，我们的研究结果表明，记录的轨迹可以有效地重新用于交互式执行环境，为合成基于真实场景的智能体训练数据提供了一种可扩展的范式，而无需从头构建环境。

A 数据源与选择

表 12 总结了重建前后的每个包含源。一条轨迹能否被重建取决于其暴露的文件证据：多文件编辑轨迹揭示了足够的项目上下文以供重建，而以命令为主的 CLI 轨迹通常暴露很少的文件内容。我们排除了源自 Terminal-Bench 的语料库以及以只读操作或不支持的操作格式为主的源。

SWE 去重与去污。 公共 SWE 语料库通常包含同一任务的多个展开或不同格式。我们在每个源内按代码仓库、基础提交和问题陈述进行去重，选择其回放暴露最多工作空间内容的轨迹。然后，我们移除来自 SWE-bench Verified 代码仓库 (Jimenez et al., 2024) 的实例以及无法链接到源轨迹的记录。表 12 给出了最终的每个源计数。

表 12：源语料库和重建环境。轨迹列统计从每个语料库中抽取的源轨迹数量。

表 13：智能体补全前后的工作空间复杂度。单元格报告中位数 / 均值。

图 7 总结了核心重建和充分性阶段。

B.1 重建与补全

源语料库以不同方式编码文件操作，因此我们将读取、写入和编辑操作规范化为有序事件流。我们保留只读文件的观察内容，对于修改过的文件，保留首次更改前可见的内容。这些内容可能是部分的或被截断的。智能体创建的文件和所有后续更改都从回放的工作空间中排除。

补全智能体接收恢复的请求、部分工作空间和文件清单。它通过创建文件、补全部分文件以及配置现有项目所需的依赖项来填充缺失的项目上下文。它不得实现请求的任务或透露应在何处进行解决方案。

打包。 重建的项目放置在 /app 下。在其他文件系统位置访问的文件则单独存储。

提示：环境补全

[提示词内容，此处省略以节省空间]

补全质量。 对 30 个随机抽样的终端补全进行人工检查发现，其中 22 个仅包含任务相关的支持文件，而 8 个引入了大量非支持任务所需的文件或代码。在 30 个补全的工作空间中未发现任务解决方案。

B.2 工作空间充分性评估

评估范围。 我们评估每个存活下来通过去污和代码仓库级去重的终端重建。对于 SWE，我们为每个代码仓库评估一个代表性重建及其意图恢复任务。智能体评判员使用只读 shell 和文件工具检查每个工作空间。

评分。 当工作空间的源代码、配置、数据和结构为有能力的智能体提供了处理该任务所需的足够上下文时，该工作空间被认为是任务充分的。依赖项、缓存、生成输出和可以重新创建的可选文档不是必需的。评判员评估可用的项目上下文，而不是构建成功。

表 14 给出了相应的源级别细分。

表 14：智能体补全后，在恢复意图下工作空间充分性的源细分。

充分率反映了轨迹暴露了多少项目上下文。智能体补全可以在观察到的证据周围添加常见的项目文件，但无法恢复未见过的项目特定内容。某些 SWE 子集太小，无法进行细粒度比较。

B.3 失败分析

对于任务不充分的工作空间，评判员会指出缺失或截断的源文件、任务脚本、输入数据、配置和部署文件。缺失的测试、清单或包初始化文件通常表示源树不完整。

C 重新查询细节

在所有四种变体中，生成的请求指定一个可观察的目标，同时将实现策略留给编码智能体。

跨工作空间布局。 每个跨工作空间对作为 repo0 和 repo1 挂载在 /app/workspaces 下。生成智能体选择一个可写的目标和只读的参考。编码智能体看到相同的布局，验证器检查参考保持不变 (§3.3)。

提示展示。 模板保留每个生成器的输入、指令和输出模式。重复的规则和示例被缩短。尖括号中的值在运行时填充。

C.1 意图恢复

生成机制。 意图恢复接收清理后的任务、时间顺序的对话轨迹和文件证据。单轮轨迹直接使用其唯一的实质性用户请求。对于多轮轨迹，第一个实质性用户请求设定任务主题；后续请求仅在它们澄清、约束或扩展同一任务时被纳入，不相关的任务转移被排除。我们使用智能体行动和文件证据来解释请求，但只保留用户陈述的需求。只有生成的 core_objective 成为意图恢复指令；其余输出字段作为元数据保留。