Large-Scale Terminal Agentic Trajectory Generation from Dockerized Environments

Step 1: 数据源收集（Data Sources Collection）

• 从 GitHub 收集 899,741 个代码仓库，覆盖 8 个领域（多模态、SQL、QEMU、Web 服务、安全、数据处理、模型训练与评估、环境交互）和 8 种编程语言
• 领域分类通过仓库的 README、文件结构等元信息自动判定
• 最终收集到 1,265,972 个数据源实例

Step 2: Docker 镜像策展（Docker Image Curation）

• 为每个代码仓库生成 Dockerfile 并构建镜像
• 引入 ScoreModel（基于奖励模型训练的质量预测器）对镜像进行质量评分
• 质量评分公式：Q_i = Σ ScoreModel(f_j) / N_i，其中 f_j 是镜像中的文件，N_i 是文件数量
• 设定阈值 τ=0.2，只有 Q_i > τ 的镜像才进入下一阶段
• 通过 ScoreModel 筛选后，Docker 构建成功率达到 19.5%，而随机选择仅 9%
• 最终成功构建 32,325 个 Docker 镜像

Step 3: 实例生成（Instance Generation）

• 对每个通过筛选的 Docker 镜像，生成任务描述（task query）和可执行验证代码（executable validation code）
• 任务描述使用大模型自动生成，描述需要完成的目标
• 验证代码是 pytest 测试套件，用于自动检验任务是否正确完成
• 每个镜像可生成多个不同难度的任务实例
• 最终生成 1,030,695 个任务实例

Step 4: 轨迹滚动与验证（Trajectory Rolling and Verification）

• 使用 Terminus-2 脚手架（scaffold）作为智能体与环境的交互框架
• 采用 Qwen3-Coder-480B 作为轨迹生成的"滚动模型"（rolling model）
• 每个任务实例在对应 Docker 容器中运行，记录完整的交互轨迹
• 轨迹验证：运行 pytest 验证代码，只有全部测试通过的轨迹才被保留
• 最终收集到 50,733 条经过验证的高质量轨迹

Step 5: 模型训练

• 使用 Qwen2.5-Coder 系列作为骨干模型（7B、14B、32B 三个规模）
• 采用 Megatron-LM 框架进行多轮监督微调（multi-turn SFT）
• 训练数据格式为多轮对话序列，模型学习在每个交互轮次中根据环境状态生成正确的命令

质量评分公式：

Q_i = Σ ScoreModel(f_j) / N_i

• Q_i：第 i 个 Docker 镜像的质量分数
• f_j：镜像中的第 j 个文件
• N_i：第 i 个镜像中的文件总数
• ScoreModel：一个训练好的奖励模型，输入文件内容，输出该文件对构建质量的贡献分数
• 阈值 τ=0.2：只有质量分数超过此阈值的镜像才被保留

这个公式的直觉是：一个高质量的 Docker 镜像应该包含"有价值"的文件（如配置良好的依赖、有意义的代码逻辑），而不是随机拼凑的文件。ScoreModel 学习了什么样的文件特征与高质量环境相关。

Pass@k 指标：

pass@k = 1 - C(n-c, k) / C(n, k)

• n：总尝试次数
• c：成功次数
• k：允许的尝试次数
• 该指标衡量在 k 次独立尝试中至少成功一次的概率，是评估代码生成和智能体性能的标准指标

Test-time Scaling：

通过增加推理时的采样次数（k 值），观察模型性能随 k 的增长趋势。TerminalTraj 训练的模型在 pass@k 曲线上表现出更好的缩放特性，说明训练数据质量对推理阶段的性能提升有显著帮助。

基准测试选择：选用 TerminalBench 1.0（46 个任务）和 TerminalBench 2.0（72 个任务）作为评估基准，这两个基准专门针对终端智能体设计，涵盖多个领域和不同难度级别，具有较强的代表性和挑战性。

对比方法：与多种方法对比，包括骨干模型（Qwen2.5-Coder 系列）、基于现有数据集训练的模型（Nex-N1、SETA）以及其他开源智能体框架。

消融实验：通过逐步去除流水线中的关键组件（ScoreModel 筛选、验证代码等），验证每个组件的贡献。

主要实验发现：

• TerminalTraj-32B 在 TB 1.0 上达到 77.08%（pass@1），比骨干模型提升 20+ 分
• TerminalTraj-32B 在 TB 2.0 上达到 63.89%（pass@1），比骨干模型提升 10+ 分
• 在 pass@8 设置下，TerminalTraj-32B 在 TB 1.0 上达到 87.50%，在 TB 2.0 上达到 76.39%
• 与 Nex-N1 数据集训练的模型相比，TerminalTraj 在 TB 1.0 上有 1.7 倍的提升，在 TB 2.0 上有 1.3 倍的提升
• 与 SETA 相比，pass@8 从 12.5% 提升到 45%

• Figure 1（流水线概览图）：展示了 TerminalTraj 从 GitHub 仓库到最终轨迹的完整四阶段流水线，包括数据源收集、Docker 策展、实例生成和轨迹验证。清晰呈现了数据的漏斗式筛选过程。
• Figure 2（ScoreModel 效果图）：对比了使用 ScoreModel 筛选与随机选择的 Docker 构建成功率，展示质量预测模型在资源优化上的显著效果。
• Table 2（主实验结果）：在 TB 1.0 和 TB 2.0 上的完整实验结果对比，涵盖不同模型规模和 pass@k 设置下的性能。TerminalTraj-32B 在所有设置下均为最优。
• Table 3（与现有数据集对比）：TerminalTraj 与 Nex-N1、SETA 等现有数据集的训练效果对比，证明 TerminalTraj 数据质量的优越性。
• Figure 4（Test-time Scaling 曲线）：展示 pass@k 随 k 增大的变化趋势，TerminalTraj 训练的模型展现出更优的缩放特性。
• Table 5（消融实验）：验证流水线各组件（ScoreModel、验证代码、数据规模）的贡献，证明每个设计选择的必要性。
• 附录领域分布图：展示了 8 个领域和 8 种编程语言在数据集中的分布情况，体现了数据的多样性。

• 计算成本高昂：整个流水线需要构建数万个 Docker 镜像并在其中运行大规模轨迹生成，计算资源消耗巨大。论文未详细报告总计算成本，但可以推测需要大量的 GPU 和 CPU 资源。
• Docker 构建成功率仍然较低：即使使用 ScoreModel 筛选，Docker 构建成功率仍仅 19.5%，意味着约 80% 的计算资源被浪费。如何进一步提高构建成功率是一个开放问题。
• 轨迹质量依赖滚动模型：轨迹的生成质量在很大程度上取决于 Qwen3-Coder-480B 的能力。如果滚动模型在某些领域表现不佳，生成的轨迹可能存在系统性偏差或遗漏。
• 验证代码的覆盖度：pytest 验证代码只能检查预定义的测试用例，无法保证任务的完整正确性。可能存在"通过了测试但实际解决方案不正确"的情况。
• 领域覆盖的均衡性：虽然覆盖了 8 个领域，但从附录数据来看，各领域的数据量分布不均匀，某些领域（如多模态、SQL）的数据量可能远大于其他领域。
• 语言覆盖有限：仅覆盖 8 种编程语言，对于一些重要的语言（如 Rust、Go、TypeScript 等）可能覆盖不足。