1. 摘要（Abstract）

本文研究的是面向终端环境的智能体训练数据构建问题。随着大模型智能体逐渐进入代码开发、系统运维、自动调试等真实任务，仅依赖静态文本数据已经难以训练出可靠的执行能力。终端任务的难点在于，模型不仅要理解指令，还要能在真实环境中执行命令、观察反馈、修复错误，并最终完成可验证的系统状态变化。因此，高质量的 terminal trajectories 对训练 agentic models 非常关键。

现有数据构建方法主要存在两个瓶颈。第一是执行性问题，每个任务往往需要对应的依赖、文件系统状态和运行环境，缺少可运行环境的轨迹很难反映真实终端操作。第二是可验证性问题，不同任务的输出形式差异很大，不能简单用统一文本答案判断是否完成。现有方法要么能扩展任务多样性但缺少真实执行 grounding，要么提供可执行环境但规模有限，难以支撑大规模 agent 训练。

针对这一问题，论文提出 TerminalTraj Pipeline，用于从真实 GitHub 仓库中自动构建 Docker 化执行环境、生成与环境对齐的终端任务，并通过可执行验证代码筛选成功轨迹。该流程首先利用模型评分筛选高质量仓库，再构建 Docker images，随后根据仓库中的 Markdown、Shell、代码文件和领域上下文生成任务实例，最后让 agent 在 Docker 环境中多轮交互，并用 pytest 等实例级验证代码确认任务是否真正完成。

最终，TerminalTraj 从 899,741 个 GitHub 仓库中构建出 32,325 个 Docker images，并生成 50,733 条 verified terminal trajectories，覆盖八种编程语言和八类专门领域。基于这些轨迹微调 Qwen2.5-Coder 系列模型后，模型在 TerminalBench 上取得明显提升，其中 TerminalTraj-32B 在 TB 1.0 上达到 35.30%，在 TB 2.0 上达到 22.00%，成为 100B 参数以下表现较强的 terminal agent 模型之一。更重要的是，该数据还能改善模型的 test-time scaling，TerminalTraj-32B 在 pass@16 下达到 63.75%。

这篇论文的核心价值不只是提出一个新数据集，而是系统性回答了 terminal agent 训练中的一个基础问题，即如何大规模构建既能真实执行、又能可靠验证的长轨迹数据。它把 agent 数据构建从普通文本合成推进到执行环境驱动的数据工程，对后续代码智能体、系统智能体和自动化工作流训练都有较强参考意义。

2. 研究背景与问题动机（Introduction）

近年来，AI agents 已经在代码修复、软件工程、工具调用和多轮推理任务中展现出较强能力，但许多评测和训练场景仍然简化了真实执行约束。真实终端任务并不是单纯回答问题，而是要求模型在命令行中读取文件、安装依赖、运行程序、处理错误输出，并根据环境反馈持续调整行动。TerminalBench 正是为了评估这种真实终端能力而提出的 benchmark。

要提升 terminal agent 的能力，关键不只是设计更好的 agent scaffold，也不只是换更大的 base model，而是需要大量高质量的训练轨迹。这类轨迹必须包含完整的 long-horizon interaction，例如模型如何观察环境、选择命令、解释 stdout 和 stderr、修正失败步骤，并最终完成任务。相比普通代码补全或问答数据，terminal trajectory 更接近真实人类开发和系统操作过程，因此训练价值更高。

但这类数据很难大规模构建。首先，每个任务都需要一个能够运行的环境。代码仓库里的文件本身并不等于可执行环境，缺少依赖、配置或 Dockerfile 时，agent 的操作就无法真实落地。其次，终端任务的答案并不一定是一个固定文本，很多任务的成功表现为文件被正确修改、服务被启动、配置生效或输出结果满足条件。因此，仅靠 LLM judge 或人工规则很难稳定判断任务是否真正完成。

已有工作在这两个方面各有不足。Nex-N1 等方法可以生成较多任务和交互轨迹，但验证过程更依赖规则或 LLM judge，与真实执行环境结合不够紧密。SWE-bench 风格的数据集提供了更真实的仓库级执行环境，但环境数量和任务覆盖又比较有限。TerminalTraj 的动机正是解决这个矛盾，即在保持执行真实性和可验证性的同时，把环境和轨迹构建扩展到更大规模。

3. 系统框架与整体设计（TerminalTraj Pipeline）

TerminalTraj Pipeline 的整体流程可以分为三个部分。第一部分是数据源收集，作者从 GitHub 中收集八种主流编程语言相关的仓库，并补充文档、视频、图像、数据文件和网页服务等外部上下文。第二部分是 Docker image curation，系统通过模型评分筛选高质量仓库，并从仓库中提取或构建可运行的 Docker 环境。第三部分是 instance generation 和 trajectory verification，系统根据环境生成任务 query 和验证代码，再让 agent 在终端环境中执行任务，最后通过代码验证筛选成功轨迹。

这个 pipeline 的关键思想是把真实开源仓库转化为可交互、可验证的 agent 训练环境。传统数据合成往往从任务描述出发，让大模型凭空生成问题和答案。TerminalTraj 则反过来，从可运行仓库和 Docker 环境出发，再生成与环境强绑定的任务。这种方式可以避免任务与环境脱节，使生成的问题必须依赖具体文件、依赖关系、命令工具和运行状态来解决。

在数据源层面，作者并不只收集代码文件，而是有意识地保留与执行相关的信息，例如 Dockerfile、Shell 脚本、Markdown 文档和构建配置。对于领域任务，系统还额外引入外部上下文，例如 Hugging Face 数据、Linux 文档、图像、视频和网页链接等，使任务不局限于普通代码执行，而是覆盖数据处理、多模态、SQL、安全、QEMU、模型训练与评估、环境交互和 Web service 等不同场景。

从整体设计看，TerminalTraj 的重点不是单纯扩大轨迹数量，而是把环境、任务、执行和验证四个环节串起来。每条最终保留下来的轨迹，都必须来自一个实际 Docker 环境，并通过对应验证代码确认成功。这使得数据本身更接近真实 terminal workflow，也更适合训练模型的实际操作能力。

4. 核心方法（Docker 环境构建与任务生成）

TerminalTraj 的第一项关键技术是 model-based repository scoring。原始 GitHub 仓库质量差异很大，很多仓库缺少完整依赖、构建配置或可执行入口。如果直接尝试构建 Docker image，会浪费大量计算资源。作者因此训练了一个 ScoreModel，根据代码文件的完整性和可执行性给每个文件打分，再汇总成仓库质量分数。低于阈值的仓库会被丢弃，从而提高后续 Docker 构建成功率。

这一设计解决的是环境稀缺问题。过去一些方法依赖 stars、commits 等启发式指标筛选仓库，但这些指标不一定代表仓库适合构建可执行环境。TerminalTraj 改为直接预测仓库的执行质量，使筛选目标和最终任务构建目标更一致。实验也显示，高分仓库不仅 Docker build 成功率更高，生成出来的任务质量也更好。

第二项关键技术是 Docker-aligned instance generation。系统不是随意生成任务，而是读取同一仓库中的 Markdown、Shell 和代码文件，让大模型反向推断什么样的用户需求会需要执行这些脚本或代码片段。这样生成的 query 与仓库环境天然对齐，agent 需要真正进入 Docker 环境中执行命令，才能完成任务。

第三项关键技术是 executable validation code。与固定答案或 LLM 打分不同，TerminalTraj 为每个任务生成可执行验证逻辑，通常以 pytest suite 的形式出现。验证代码会检查最终环境状态，例如文件是否生成、配置是否正确、程序输出是否满足要求，而不是检查 agent 是否使用了某条固定命令。这种 state-based verification 更适合终端任务，因为真实任务通常允许多种解决路径，只要最终状态正确即可。

在轨迹生成阶段，作者使用 Qwen3-Coder-480B 进行 trajectory rolling。agent 通过标准终端接口观察 stdout 和 stderr，执行命令，处理错误，并多轮修正计划。每个 query 会采样多次以增加轨迹多样性。只有最终通过验证代码的轨迹才会保留，因此数据质量主要由真实执行结果把关，而不是由模型自评决定。

5. 数据集规模与质量分析（Dataset Analysis）

TerminalTraj 的数据规模比较大。作者一共爬取 899,741 个 GitHub 仓库，覆盖 Go、C++、C、HTML、Java、JavaScript、PHP 和 Python 八种编程语言。经过质量筛选后，得到 196,051 个高质量仓库，并最终构建出 32,325 个 Docker images。随后，系统生成 1,030,695 个任务实例，并通过 agent 执行和验证筛选出 50,733 条 verified trajectories。

从数据漏斗看，最终 verified trajectory rate 只有约 4.92%。这个比例看起来不高，但恰恰说明筛选标准比较严格。大量任务虽然可以生成，但 agent 未必能完成，或者最终状态不能通过验证代码。作者保留的并不是所有生成轨迹，而是真正在执行环境中完成任务的轨迹。因此，这个数据集的特点不是宽松收集，而是高精度过滤。

作者还分析了 Docker image curation 的效率。随机选择带 Dockerfile 的仓库时，Docker build 成功率约为 9%。如果选择仓库分数高于 0.5 的样本，成功率提升到 19.5%，接近翻倍。论文实际采用更宽松的 0.2 阈值以保留语言和任务多样性，但仍能达到约 17% 的构建成功率。这说明 model-based filtering 在规模化环境构建中确实能节省计算成本。

实例质量方面，作者把任务按仓库分数分层抽样，并从 Task Soundness、Evaluability、Information Sufficiency 和 Behavioral Constrainedness 四个维度进行人工和 LLM 评价。结果显示，仓库分数越高，生成实例质量也越高。这说明仓库层面的可执行性信号能够传导到任务层面，从而同时改善环境构建和任务生成质量。

6. 实验设置与模型训练（Experiment Setup）

实验部分主要评估 TerminalTraj 数据对 terminal agent 能力的提升。作者选择 Qwen2.5-Coder 系列作为 backbone，包括 7B、14B 和 32B。选择 Qwen2.5-Coder 而不是 Qwen3-Coder 的原因是，Qwen2.5-Coder 发布时间早于 TerminalBench，可以降低 benchmark 污染风险。训练方式采用多轮监督微调，并使用 Megatron-LM 框架完成训练。

评测基准是 TerminalBench 1.0 和 TerminalBench 2.0。这两个 benchmark 都用于测试智能体在真实终端环境中的任务完成能力。作者遵循 TerminalBench 的评测协议，并使用 Terminus-2 作为主要 agent scaffold。对于没有公开 TerminalBench 结果的模型，作者进行了四次独立运行，并报告平均性能和置信区间。

对比模型覆盖面比较广，包括闭源模型、超大规模开源模型、30B 左右开源模型以及已有 agentic training 方法。闭源模型包括 Gemini、Claude 和 GPT 系列。开源模型包括 DeepSeek-V3.2、GLM-4.7、Kimi-K2、Qwen3-Coder 和 Nex-N1 系列。这样的设置可以同时比较 TerminalTraj 在同等规模、小于 100B 参数范围和超大模型之间的位置。

从实验目的看，作者想证明的不只是 TerminalTraj 数据能让 Qwen2.5-Coder 变强，而是想说明执行环境驱动的数据构建比纯文本式或 judge-based 轨迹筛选更有效。因此，后续实验不仅看主结果，还看 pass@k scaling、领域消融、验证方式对比和与 Nex-N1 数据集的比较。

7. 实验结果与性能分析（Results）

主结果显示，TerminalTraj 数据带来了非常明显的提升。Qwen2.5-Coder 原始 backbone 在 TerminalBench 上表现较弱，7B 在 TB 1.0 上只有 6.25%，在 TB 2.0 上为 0.00%。经过 TerminalTraj 训练后，TerminalTraj-7B 提升到 23.01% 和 10.10%。14B 模型提升到 28.91% 和 19.10%。32B 模型提升到 35.30% 和 22.00%。这些结果说明，terminal trajectories 对模型的真实执行能力提升非常直接。

TerminalTraj-32B 的表现尤其值得注意。它不仅超过 Qwen3-32B-Nex-N1，还超过部分更大规模的 open-source agentic models。在 TB 1.0 上，TerminalTraj-32B 比 Qwen3-32B-Nex-N1 高 6.55 个点，在 TB 2.0 上高 5.3 个点。而且 TerminalTraj 使用的是 Qwen2.5-Coder-32B 作为基础模型，backbone 并不比 Nex-N1 更强，这说明数据质量本身提供了主要增益。

Test-time scaling 结果也很关键。作者使用 pass@k 评估模型在采样更多候选轨迹时的性能变化。原始 Qwen2.5-Coder 系列 pass@k 曲线较平，说明额外采样不能有效转化为成功率提升。TerminalTraj 系列则表现出更陡的 scaling 曲线，随着 k 从 1 增加到 16，pass@k 提升约 20% 到 30%。其中 TerminalTraj-32B 在 pass@16 下达到 63.75%，并在多数 k 值下超过 Qwen3-Coder-480B。这说明执行 grounded 的训练轨迹不仅提升单次准确率，也提升了模型利用推理时计算预算的能力。

领域消融实验进一步说明，多样化终端任务非常重要。作者从八个专门领域中各抽取 1,000 条轨迹，并配合 2,000 条 general-domain 轨迹形成训练集。移除任一领域都会导致性能下降，其中 Web Service 和 QEMU 的影响最大。去掉 Web Service 会让 TB 1.0 和 TB 2.0 分别下降 8.9% 和 7.4%，去掉 QEMU 则下降 9.7% 和 8.7%。这说明 terminal agent 需要大量不同工具、系统操作和环境交互数据，单一类型数据很难训练出稳健能力。

验证方式对比也支持论文的核心观点。作者比较了 LLM-verified 和 Code-verified 两种轨迹筛选方式。结果显示，在 1K、2K、4K 和 8K 不同数据规模下，使用代码验证筛选的轨迹训练效果始终优于 LLM 判断筛选。尤其在小数据规模下，code-based verification 的优势更明显。这说明真实执行验证比模型自评更可靠，也再次证明了可验证性是 terminal trajectory 数据质量的核心。

最后，作者将 TerminalTraj 与 Nex-N1 对比。尽管 TerminalTraj 的轨迹数量少于 Nex-N1，且使用的 backbone 更弱，但带来的性能增益更大。论文报告显示，TerminalTraj 在 TB 1.0 和 TB 2.0 上的提升幅度分别是 Nex-N1 的 1.7 倍和 1.3 倍。这说明对于 terminal agent 训练而言，轨迹数量不是唯一关键，环境多样性、执行真实性和验证质量同样重要。

8. 贡献与结论（Conclusion）

本文的主要贡献包括以下四点。

第一，提出 TerminalTraj Pipeline，用于大规模构建多样化、可执行、可验证的 terminal agent trajectories。

第二，引入 model-based repository scoring，将仓库筛选从启发式规则转为可学习的质量预测，提高 Docker image 构建效率，并支持持续扩展执行环境。

第三，提出 Docker-aligned instance generation 和 code-based trajectory verification，使每个任务都与具体执行环境绑定，并通过实例级验证代码判断 agent 是否真正完成任务。

第四，构建 32,325 个 Docker images 和 50,733 条 verified trajectories，并在 TerminalBench 上验证这些数据能显著提升 Qwen2.5-Coder 系列模型的终端任务能力和 test-time scaling 表现。

这篇论文真正抓住的问题是，terminal agent 的训练瓶颈不只是模型大小，而是缺少足够多的真实执行环境和可靠验证信号。很多 agent 数据看起来像多轮轨迹，但如果没有实际执行和状态验证，就很难保证模型学到的是可迁移的操作能力。TerminalTraj 的价值就在于把数据构建建立在 Docker 环境和 executable validation 之上，使训练信号更接近真实终端任务。

从研究意义看，这篇工作把 agentic data synthesis 推向了更工程化也更可信的方向。它说明未来训练可靠智能体时，仅靠文本任务、静态答案或 LLM judge 可能不够，必须让模型进入真实环境，并用程序化验证判断结果。对于代码智能体、科研自动化、系统维护和复杂 workflow agent 来说，这种执行 grounded 的数据构建思路都很有参考价值。