Terminal-Universe：不造环境了，直接从轨迹里"挖"出来
做 agent 后训练的人大概都有这种体验：轨迹数据现在遍地都是，随便一个框架跑一圈就是几万条，但真正能用的可执行环境少得可怜。轨迹能干嘛？能 SFT，但上限被产生它的那个模型锁死了；环境能干嘛？可以反复 re-query、可以验证、可以让更强的教师模型重新解一遍——这才是后训练真正吃掉的资源。
问题在于，造环境这件事一直很难规模化。今天要聊的这篇 Terminal-Universe（arXiv: 2609.04148）给了一个我觉得相当聪明的视角转换：别从零造环境了，轨迹本身就把环境暴露给你了。
核心摘要：终端代码智能体的轨迹里，Read/Write/Edit 这些工具调用已经完整暴露了它运行时 workspace 的内容和结构。Terminal-Universe 干脆把映射方向反转——不是从环境 rollout 轨迹，而是从轨迹反向重建环境：确定性重放文件操作恢复部分 workspace，再用 completion agent 补齐缺失文件和依赖。在重建出的 37.3k 个 task-sufficient 环境上，沿广度（跨工作区任务）和深度（多轮用户交互）两轴扩展任务，SFT Qwen3.5-27B 后 Terminal-Bench 2.1 提升 11.9 个点，EvoCode-Bench v2 MT@4 提升 13.8 个点。这不是底层算法突破，是一条实打实的数据管线工程，但这条管线踩中了这个领域最痛的供给瓶颈。
📖 论文信息
- 标题：Terminal-Universe: Turning Agent Trajectories into Scalable Terminal Environments
- 作者：Jie Wu, Zhenru Zhang, Beichen Zhang, Xuwu Wang, Yuhui Su, Mouxiang Chen, Peng Wang, Zhihai Wang, Que Shen, Hao Zhou, An Yang, Fei Huang, Yujiu Yang, Dayiheng Liu
- 机构：Qwen Team, Alibaba Group；Tsinghua University
- 链接：https://arxiv.org/abs/2609.04148 （2026 年 9 月 3 日提交）
🎯 为什么环境比轨迹值钱
先说清楚这篇论文的核心论点，因为它决定了后面所有设计的动机。
轨迹和环境的差别，论文里列得很直白：
| 维度 | Trajectory（轨迹） | Environment（环境） |
|---|---|---|
| 本质 | 单一的、冻结的记录 | 可复用的资源 |
| 质量上限 | 受限于产生它的策略模型 | 可被更强模型重新求解 |
| 可验证性 | 没法检查代码修改对不对 | 可通过自有测试验证 |
| 任务扩展 | 不可扩展 | 同一 workspace 上可提更难任务 |
说实话，这个对比表看起来平平无奇，但它后面的消融实验直接把这个论点砸实了——先卖个关子，§6.1 那组数据我看完是真的愣了一下。
现有扩环境的三条路各有硬伤：SWE-Gym/R2E-Gym 这类仓库回滚法依赖真实 git 历史；SWE-smith/CLI-Gym 这类注入 bug 的扰动法产出全是修复类任务，范围窄；Endless Terminals、TMax 这类从零合成法的问题更微妙——生成出来的 workspace 往往"小而整洁"，和真实项目里的屎山代码完全两个物种。
Terminal-Universe 的观察是：轨迹的工具执行历史里，Read 展示文件内容，Write/Edit 展示 workspace 变更。这些加起来，足以重建一个可执行的 workspace 副本。
方向反转。就这么简单，但之前没人系统性地做。
🏗️ 方法：三阶段重建 + 四路再查询
图1：框架全貌。左半边把一条轨迹变成可执行 workspace，右半边在 workspace 上产出四类任务。注意 Multi-Round 那个例子：用户说"no, cache parsed schemas must be thread-safe"——这就是后面要说的深度扩展，失败轮次的反馈被保留在对话里，变成错误恢复的监督信号。
环境重建：先重放，再补全，最后过滤
Stage 1：确定性重放。按时间顺序处理轨迹里的 read/write/edit，收集每个被访问路径的最早观测版本——也就是智能体动手改之前的样子。智能体自己创建的文件排除掉，单独留着做验证。这一步是纯确定性操作，不用模型。
但问题也明显：轨迹只暴露智能体碰过的路径，终端输出还可能被截断。所以重放出来的 Ê₀ 是个部分 workspace，平均只有 2.9 个文件。2.9 个文件能干啥？基本啥也干不了。
Stage 2：智能体补全。一个 completion agent 基于部分 workspace 和恢复的任务，把缺失文件、不完整文件、依赖都补齐。关键约束是：让任务可解，但不实现解决方案本身——不能泄漏答案。补全之后平均文件数从 2.9 涨到 22.4，workspace 充分性在 Terminal 池从 40.2% 拉到 93.5%，SWE 池从 20.1% 拉到 77.1%。这个提升幅度说明补全不是锦上添花，是这条管线能不能成立的生死线。
Stage 3：环境过滤。一个 agentic judge 拿只读 shell 检查每个 workspace，结合任务判断源码、配置、数据、结构够不够支撑任务，只留 "sufficient" 的。
所有 workspace 跑在统一的 ubuntu:24.04 容器里带网络访问，不搞仓库定制镜像——这个选择牺牲了边缘场景保真度，换来部署成本大幅下降，我觉得是务实的取舍。
再查询：一个环境，四种用法
环境重建好之后，怎么把它的价值榨干？四条路：
意图恢复（Intent Recovery）：把源轨迹规范成"用户请求—动作—文件变更"的时间流。单轮轨迹直接取用户请求当任务；多轮轨迹只保留用户明确陈述的需求，模型脑补的一律不要。
单工作区合成（Single-WS）：生成器检查 workspace，在 groundedness、结构多样性、可验证性约束下合成 5 个候选任务，随机选 1 个做 rollout 和验证。
跨工作区合成（Cross-WS，广度轴）：这是我觉得最有意思的一块。真实开发从来不是单仓库的——你会读别人的参考实现、迁移特性、连接组件。流程是：先给每个 workspace 做技术画像（domain、语言、框架、能力）→ TF-IDF 最近邻找候选对 → LLM judge 识别有向依赖边（target 缺 reference 已实现的能力）。任务设定是 target 可写、reference 只读，查询只给目标行为和挂载路径，不泄露 reference 内部细节——solver 必须自己去导航、理解、适配。
多轮用户查询（Multi-Round，深度轴）：从初始查询开始，workspace 跨轮保留，引入 user agent。两个协同机制：需求追踪器维护 active/satisfied/updated 状态，每轮可增改约束；轮级 verifier 写验收测试，solver 和测试脚本严格隔离，user agent 把结构化测试结果翻译成用户口吻的抱怨。三种交互风格：feature extension、feature revision、feature conflict。最多 6 个 follow-up 轮，保留的 3,079 条记录平均 4.51 轮，69.6% 包含随后被修复的失败。
失败轮保留在对话历史里这一点值得多说一句——这直接给了模型错误诊断和恢复的监督信号，而不是只有"一路顺风"的演示。
验证与过滤
每个任务由专用 agent 在容器内写自包含 pytest 套件，迭代本地执行直到能严格评估公共接口。教师模型 Qwen3.7-Max（xhigh effort）在 Claude Code 脚手架里 rollout，temperature 1.0、256k 上下文、最多 500 个 agent turns、4 小时超时。接受标准很硬：Single-WS/Cross-WS 必须全部测试通过；Multi-Round 裁剪尾部连续失败轮，至少保留 2 个已验证通过轮。所有轨迹过 13-gram 去污染检查。
📊 实验：数字说话
数据规模
种子轨迹要求末尾 workspace 至少 5 个文件、100 行，严格排除 Terminal-Bench 衍生来源。重建产出 68,263 个环境，过滤去重后剩 37,273 个 task-sufficient 环境。Python 占 84.7%，数据处理、DevOps、安全负载合计超 80%。SFT 语料 31,977 条（Single-WS 25,386 + Cross-WS 3,512 + Multi-Round 3,079），约 1.42B tokens。
主结果
训练配置：Qwen3.5-27B，SFT 2 epochs，恒定学习率 \(7\times10^{-6}\)，全局 batch 256，256k 序列长度。Terminal-Bench 报 6 次独立运行平均通过率。
| Model | Base | Data | TB2.0 | TB2.1 | MT@4 | Case |
|---|---|---|---|---|---|---|
| Qwen3.5-27B（基座） | – | – | 41.6 | 46.2 | 6.3 | 67.8 |
| Qwen3.7-Max（教师） | – | – | 69.7 | 74.5 | 39.8 | 83.4 |
| RST-27B | Qwen3.5-27B | 37.5k | 49.4 | – | – | – |
| TMax-27B | Qwen3.6-27B | 14.6k | 42.7 | 44.9 | 17.1 | 72.5 |
| CalibForge-35B-A3B | Qwen3.5-35B-A3B | 5.4k | 47.6 | – | – | – |
| Nemotron-Terminal-32B | Qwen3-32B | 490k | 27.4 | 27.9 | 0.0 | 13.7 |
| Terminal-Universe-27B | Qwen3.5-27B | 32.0k | 52.8 | 58.1 | 20.1 | 76.1 |
几个值得停留的点：
- TB2.1 从 46.2 到 58.1，涨 11.9 个点；TB2.0 到 52.8，涨 11.2 个点。之前同基座最好的 RST-27B 是 49.4，被超了 3.4 个点。
- MT@4 从 6.3 到 20.1，涨 13.8 个点——多轮这块的基座起点低到离谱，Multi-Round 数据的收益格外大。
- 注意 Nemotron-Terminal-32B：490k 数据量，TB2.0 只有 27.4。数据量翻 15 倍，分数被 32k 的 Terminal-Universe 甩开 25 个点。环境质量对数据量的碾压，这张表体现得再清楚不过了。
消融：这篇论文最值钱的部分
重解 vs 模仿（Table 4，TB2.1）。这组数据是我说的"愣了一下"的那组：
| Variant | Claude Code | Terminus2-XML | Avg |
|---|---|---|---|
| 基座 | 47.8±2.0 | 46.2±3.9 | 47.0 |
| 直接模仿源轨迹（35.8k） | 33.0±3.9 | 40.3±2.1 | 36.7 |
| Intent Recovery 重解（35.8k） | 51.3±3.1 | 52.9±1.4 | 52.1 |
直接拿源轨迹做 SFT，性能暴跌 10.3 个点。同样的轨迹，重建环境后让教师重解，反而涨 5.1 个点。一来一回差了 15 个点以上。这个实验把"轨迹是冻结的劣质资产"这件事彻底钉死了——你模仿的每一个错误决策都被原样继承，而重解能用更强模型把质量上限重新打开。
补全的作用（Table 5）：replay-only 48.7±3.5，加补全 52.9±1.4。涨 4.2 个点，方差还大幅收窄。有意思的是 replay-only 也比基座高 2.5——教师会自己先修补 workspace 再解题，说明 workspace 残缺时模型在浪费 turn 干体力活。
Verifier 过滤（Table 6）：Single-WS 加不加 verifier 差别不大（56.4 vs 56.0），但 Cross-WS 用不到一半数据（3.5k vs 7.1k）反超 2.2 个点。越难的任务，过滤越值钱。直觉上也说得通：难任务里坏样本的毒性更强。
广度轴（Table 7/8）：Single-WS 56.4，加上 Cross-WS 后 58.4。Cross-WS 轨迹明显更长更难——1.6 倍 assistant turns、1.9 倍 tool calls、教师 pass@1 从 72.3% 掉到 49.2%。分类收益上 model training 涨 15.0、debugging 涨 10.0。
深度轴（Table 9，EvoCode-Bench）：加 Multi-Round 后 MT@4 涨 2.6、Case 涨 5.0；去掉轮级验证反馈，MT@4 掉 2.2。grounded 反馈（真实测试结果翻译成的抱怨）确实在指引模型延续修复。
扩展轴消融（Table 10）——这组实验是对"以环境为扩展核心"动机的直接验证，固定约 35k 数据预算：
| Variant | Envs | Records | TB2.1 |
|---|---|---|---|
| 环境扩展 | 35,116 | 35.1k | 56.0±3.3 |
| 查询扩展 | 17,558 | 35.1k | 53.8±3.3 |
| 解扩展 | 17,558 | 35.1k | 53.9±2.4 |
扩环境涨 2.8 个点，扩查询扩解基本无效。同样的数据量，花在环境多样性上的回报远高于花在同环境多任务上。这个结论对做数据工程的人很有指导意义：别再一个 workspace 上薅第二个 query 了，去搞新环境。
🤔 我的判断
这篇论文的定位要放准：它不是算法创新，是数据供给管线的范式翻转。核心 insight 一句话——轨迹暴露了环境，所以轨迹可以逆转成环境。这个观察本身不复杂，但把它做成一条带确定性重放、智能体补全、验证过滤、广度深度两轴扩展的完整管线，并且每个环节都拿出消融数据证明必要性，这个工程完成度是很高的。
几个亮点我觉得值得记住：重解 vs 模仿那 15 个点的差距，等于给"轨迹蒸馏"路线敲了记警钟；扩展轴消融直接告诉你数据预算该往哪花；Cross-WS 的有向依赖建模（TF-IDF 粗筛 + LLM judge 定向）是个可复用的模式。
问题也有。单一教师 Qwen3.7-Max 同时生成任务、解和验证器——教师的能力盲区会限制任务覆盖，教师解里的错误也可能被自己的测试漏过，这是自指风险，作者自己也承认了。另外统一 Ubuntu 容器在复杂编译场景会掉保真度，84.7% 的 Python 占比意味着低层语言场景的泛化是存疑的。还有个我个人没完全想透的点：workspace 充分性判断由 agentic judge 做，这个 judge 的误判率在边缘案例上到底多少，论文没给细查。
跟同期工作比，和 RST（37.5k 环境）规模相当但多了多轮和跨 workspace 支持，和 TMax 这类纯合成路线比赢在环境来自真实轨迹。方向上，"环境即资产、轨迹可逆转"这个思路我觉得会成为 agent 数据工程的标配——尤其是那个观察：同一 workspace 上的多条轨迹可以聚合重放，合并出比任何单条轨迹都更复杂的环境。随着智能体越来越强，这条管线会自动变得更值钱，这是个挺优雅的 scaling 属性。
如果你在做 agent 后训练的数据管线，这篇值得细读，尤其是消融实验每一组都对应一个工程决策。
觉得有启发的话，欢迎点赞、在看、转发。跟进最新AI前沿，关注我