基于Docker化环境的大规模终端智能体轨迹生成 Large-Scale Terminal Agentic Trajectory Generation from Dockerized Environments
构建可执行的终端任务数据管道，在TerminalBench上提升20%性能
前置知识
Docker容器化
Docker是一种轻量级虚拟化技术，通过容器将应用及其依赖打包成可移植的镜像。在终端任务场景中，每个容器提供独立的Linux环境，包含特定的文件系统、工具和配置。Agent通过终端与容器交互，执行命令并观察输出。这种隔离确保了任务执行的安全性和可重复性，同时允许大规模并行执行。
本文的核心是将GitHub仓库转化为可执行的Docker环境，理解容器化原理是理解整个数据构建管道的基础。
Agent Trajectory（智能体轨迹）
智能体轨迹记录了Agent在完成任务过程中的完整交互序列，包括每一步的观察、决策和行动。在终端场景中，轨迹包含终端命令、文件操作、错误处理等多轮交互。Trajectory数据是训练Agentic模型的核心监督信号，通过监督学习让模型学会如何规划、执行和调试。
论文的目标就是生成高质量的终端轨迹数据，Trajectory的质量和多样性直接决定了训练出的Agent性能。
Executable Validation（可执行验证）
传统数据验证依赖人工审核或LLM判断，而可执行验证通过运行测试代码来自动检查任务是否真正完成。例如，验证Agent是否创建了特定文件、修改了系统配置或输出了正确结果。本文采用pytest测试套件作为验证逻辑，在Agent执行完成后自动运行，只有通过验证的轨迹才被保留。
这是本文与Nex-N1等现有工作的核心区别，可执行验证确保了数据质量，避免了Agent的幻觉问题。
Test-time Scaling（测试时扩展）
测试时扩展是指在推理阶段增加计算预算来提升性能的技术。典型做法是采样多个候选解并选择最佳答案（pass@k指标）。例如，pass@16表示采样16个解，只要有一个正确就算成功。这允许小模型通过更多计算来接近大模型的性能。
论文的重要发现是TerminalTraj训练显著改善了模型的测试时扩展能力，TerminalTraj-32B在pass@16达到63%，超越了更大的Qwen3-Coder-480B。
Repository Scoring（仓库质量评分）
仓库质量评分是一个预测性模型，用于评估GitHub仓库代码的完整性和可执行性。本文训练了一个以Qwen2.5-Coder-0.5B为骨干的奖励模型，对每个代码文件打分（0到1），然后聚合得到仓库的质量分数。高分仓库更有可能成功构建Docker镜像，从而提高数据构建效率。
这替代了传统的基于star数的启发式过滤，实现了自动化、可扩展的环境筛选，是构建32K Docker镜像的关键技术。
研究动机
现有终端智能体数据构建方法面临两大核心挑战：可执行性和可验证性。可执行性要求每个任务实例都有合适的Docker环境，但现有方法依赖启发式筛选（如star数），导致构建成功率低（随机采样仅9%），限制了数据规模。可验证性问题则来源于任务输出的异构性——不同任务的验证标准无法统一。Nex-N1等现有工作依赖LLM判断和手工规则来验证轨迹，与真实执行环境脱节，无法捕获终端任务中依赖文件系统状态、依赖解析、工具副作用等运行时行为。此外，SWE-bench类数据集虽然提供可执行环境，但规模受限（主要依赖高star仓库），环境多样性和任务数量都无法满足大规模训练需求。这种trade-off导致现有数据要么缺乏执行基础，要么以牺牲环境多样性为代价提供有限的可执行监督。
本文的目标是本文的目标是构建一个可扩展的终端智能体轨迹生成管道，能够同时满足三个核心要求：（1）环境多样性：覆盖多种编程语言和任务类型；（2）执行真实性：轨迹必须来自真实的Docker环境执行，而非模拟或LLM生成；（3）可验证性：每个轨迹都有自动化的可执行验证代码。具体而言，论文构建了32K个Docker镜像，生成了50,733个经过验证的终端轨迹，覆盖8种编程语言和8个专业领域（如QEMU虚拟机、安全分析、多模态处理等）。训练出的模型在TerminalBench 1.0和2.0上分别提升20%和10%，在100B参数以下模型中达到SOTA（35.30%和22.00%），并且展现出更强的测试时扩展能力。
与已有工作不同的是，本文的独特切入角度是将仓库选择重新表述为模型驱动的质量评分问题，而非启发式过滤。通过训练一个代码质量奖励模型，自动识别高质量仓库，克服了传统方法的环境可扩展性瓶颈。另一个关键创新是采用受TerminalBench启发的实例级可执行验证，而非Nex-N1的LLM判断器。论文还构建了跨8个专业领域（Web服务、SQL、QEMU、安全、数据处理、模型训练、多模态、环境交互）的任务实例，捕获现实世界中涉及专用工具和输入的任务需求。最后，通过采样多个Agent轨迹并选择通过验证的解，既保证数据质量又增加多样性。这种环境多样性、执行验证、领域特化的三重结合，填补了现有方法在构建大规模、高质量、可验证终端轨迹数据方面的空白。
核心方法
TerminalTraj Pipeline是一个三阶段自动化管道：数据源收集、Docker镜像构建、实例生成与验证。首先，从GitHub爬取899,741个仓库，优先选择包含Dockerfile和构建配置的仓库，确保代码是可执行环境的而非静态文本。然后，训练一个代码质量奖励模型对仓库评分，选择高质量仓库构建32,325个Docker镜像，构建成功率约17%。接着，利用仓库中的Shell脚本和Markdown文档的对齐关系，通过LLM合成任务查询和可执行验证代码。最后，部署Agent（Qwen3-Coder-480B）在Docker环境中交互，记录轨迹并执行验证代码，只保留成功验证的轨迹。整个过程通过自动化实现可扩展性，通过执行验证保证数据质量，通过领域特化覆盖多样化任务。
核心创新点在于三个层面的突破：（1）模型驱动的仓库筛选：将仓库选择从启发式方法（star数）转化为预测性质量评分，使用训练的奖励模型对代码打分，使得仓库选择完全自动化且可扩展；（2）可执行验证替代LLM判断：生成pytest测试套件作为验证逻辑，在Agent执行后自动运行验证，确保轨迹真正完成任务而非伪造成功；（3）大规模Docker环境构建：成功构建32K个可执行环境，远超现有工作的数百个规模，通过环境多样性解锁模型的测试时扩展潜力。与Nex-N1使用LLM判断器相比，本文方法与真实执行深度耦合；与SWE-bench类数据集相比，本文在环境规模上实现了数量级突破。
方法步骤详情
管道包含三个主要步骤：（1）数据源收集：爬取899,741个GitHub仓库，覆盖8种编程语言。过滤掉TerminalBench发布后的仓库以防止数据泄露，用LLM过滤掉与测试集参考解匹配的文件。针对8个专业领域，提取相关的Markdown和Shell文件（如Web服务的nginx配置、安全任务的hashcat工具使用）。同时收集外部输入（如HuggingFace数据、Linux文档、图像视频），构建需要处理外部信息的任务。（2）Docker镜像构建：训练以Qwen2.5-Coder-0.5B为骨干的奖励模型，对每个代码文件打分（0到1），计算仓库质量分数$Q_i = \sum ScoreModel(f_j)/N_i$，丢弃分数低于\tau=0.2的仓库。使用选中的仓库中的Dockerfile构建镜像，对缺少Dockerfile的领域任务自动注入依赖。成功构建32,325个镜像，构建成功率约17%，比随机采样（9%）提升近一倍。（3）实例生成与验证：对于每个镜像，提取Shell和Markdown文件对，提示LLM（Qwen3-Coder-480B）合成任务查询和pytest验证代码。对于领域特定任务，附加额外上下文（如数据文件、图像、链接）。然后部署Agent与Docker环境交互，使用Terminus-2脚手架管理交互循环，记录轨迹。对每个查询执行4次Agent以收集多样轨迹。最后运行验证代码检查Agent是否完成任务，只保留通过验证的轨迹。最终生成50,733个验证通过的轨迹，验证率约4.92%。
技术新颖性
技术新颖性体现在多个层面：（1）预测性质量过滤：首次将仓库选择表述为可学习的质量评分问题，而非依赖启发式规则。训练的奖励模型能够识别代码的完整性和可执行性，使得Docker构建成功率从9%提升到17.5%（高分仓库）。（2）实例级可执行验证：首次将TerminalBench的验证范式扩展到数据生成阶段，每个实例都配有专门的pytest测试套件，而非通用的LLM判断器或手工规则。实验证明，这种方法比LLM验证在相同数据规模下提升1.3-1.7倍性能。（3）跨领域环境多样性：构建了覆盖8个专业领域的大规模Docker环境，其中QEMU、安全、SQL等领域的任务需要特定的系统级工具和依赖，这种多样性在现有数据集中未见。（4）测试时扩展能力：论文首次系统分析了数据多样性对测试时扩展的影响，发现环境多样性使TerminalTraj-32B在pass@16达到63%，远超SETA方法（12.5%），表明执行基础的数据能够更高效地将推理计算转化为性能提升。
实验结果
论文在TerminalBench 1.0和2.0上进行了全面评估。与骨干模型Qwen2.5-Coder相比，TerminalTraj训练带来显著提升：7B模型从6.25%/0%提升到23.01%/10.10%，14B模型从6.25%/1.18%提升到28.91%/19.10%，32B模型从5.00%/4.49%提升到35.30%/22.00%。提升幅度在TB 1.0上达20%（32B模型），在TB 2.0上达10%以上。更重要的是，TerminalTraj-32B在100B参数以下模型中达到SOTA，超越了Qwen3-235B（358B）和DeepSeek-V3.1-Nex-N1（685B）等更大模型，展现出强大的规模效率。测试时扩展分析显示，TerminalTraj模型的pass@k曲线斜率远超骨干模型：TerminalTraj-32B在k从1增加到16时，pass@k从35.30%增长到63%，而Qwen2.5-Coder-32B的pass@k几乎不变（约5%）。对比实验表明，在相同数据规模下，基于可执行验证的轨迹比LLM验证的轨迹训练效果更好，4K数据规模下提升约30%。领域消融研究发现，移除QEMU或Web Service（WS）领域分别导致9.7%/8.7%和8.9%/7.4%的性能下降，说明领域特定数据对学习鲁棒的Agent行为至关重要。与Nex-N1对比，使用更少轨迹和更弱骨干（Qwen2.5 vs Qwen3）的TerminalTraj模型实现了1.7倍（TB 1.0）和1.3倍（TB 2.0）的性能提升，验证了环境多样性和执行验证的有效性。
查看结构化数据
| 任务 | 指标 | 本文 | 基线 | 提升 |
|---|---|---|---|---|
| TerminalBench 1.0 | Accuracy (%) | 35.30 | 5.00 (Qwen2.5-Coder-32B) | +30.30 points |
| TerminalBench 2.0 | Accuracy (%) | 22.00 | 4.49 (Qwen2.5-Coder-32B) | +17.51 points |
| TerminalBench 1.0 | pass@16 (%) | 63.00 | 5.00 (Qwen2.5-Coder-32B) | +58.00 points |
| TerminalBench 1.0 | Accuracy (%) | 35.30 | 28.75 (Qwen3-32B-Nex-N1) | +6.55 points |
| TerminalBench 2.0 | Accuracy (%) | 22.00 | 16.70 (Qwen3-32B-Nex-N1) | +5.30 points |
局限与改进
作者在论文中承认了一些局限性。首先，当前的验证率只有约4.92%，虽然这反映了任务难度和高质量筛选，但也意味着大量计算资源用于生成被过滤的轨迹。其次，论文主要关注监督学习，没有深入探索强化学习在轨迹数据上的应用，虽然交互性任务天然适合RL。此外，领域消融研究显示某些领域（如多模态）对整体性能贡献较小，可能需要调整数据分布。我自己观察到的其他局限包括：训练时使用Terminus-2脚手架，但推理时可能使用不同的脚手架，这种脚手架不匹配可能影响性能迁移。论文使用的Qwen2.5-Coder骨干较为陈旧（发布于TerminalBench之前），虽然避免了数据泄露，但可能低估了在最新骨干上的潜在收益。最后，论文主要关注Unix/Linux终端环境，对Windows PowerShell或跨平台任务的支持有限，这限制了方法的普适性。
独立分析的弱点
论文存在几个可改进的弱点。首先，4.92%的验证率意味着大量计算被浪费在生成无效轨迹上，未来可以改进实例生成策略（如更高质量的query合成、预检查脚本可执行性）来提高验证率。其次，领域数据分布不均衡，多模态等领域的贡献较小，可以调整采样策略或增加这些领域的任务复杂度。第三，论文主要评估TerminalBench，这是单阶段任务，未来需要在多阶段、长周期任务（如SWE-bench）上验证方法的有效性。第四，当前方法依赖固定的Agent模型（Qwen3-Coder-480B）生成轨迹，这可能导致轨迹多样性受限于单个模型的能力，未来可以探索使用多个不同的Agent模型或通过强化学习生成更多样化的轨迹。最后，论文没有深入分析不同类型的失败模式（如环境配置错误、验证代码bug、Agent能力不足等），这样的分析可以帮助针对性改进管道的各个环节。
未来方向
作者提出了几个有前景的未来方向。首先，将强化学习与TerminalTraj数据结合，利用交互性任务的特性通过RL进一步提升模型性能。其次，探索其他模态的Agent数据构建，如Web浏览器、GUI应用等，扩展方法的适用范围。第三，研究更高效的验证策略，如基于符号执行或模型预测的快速验证，减少执行开销。第四，分析失败模式并改进相应环节，如增强query生成的指令清晰度、提高验证代码的鲁棒性。此外，基于本文成果可延伸的方向包括：构建更大规模的环境库（如100K+ Docker镜像），探索跨环境的迁移学习，研究环境嵌入技术以便模型快速适应新环境，以及开发环境检索系统以便在推理时动态选择最相关的环境。另一个有趣的方向是将TerminalTraj与人类反馈结合，构建人类-协作的数据构建流程，进一步提升数据质量和真实性。
复现评估
论文在可复现性方面表现出色。所有代码和数据已在GitHub开源（https://github.com/multimodal-art-projection/TerminalTraj），包括完整的管道代码、训练脚本和评估协议。数据集包含50,733个验证通过的轨迹，每个轨迹配有查询、验证代码和环境信息。论文详细报告了训练超参数（序列长度65536、全局批次大小16、学习率$1\times10^{-5}$、余弦衰减调度等），使用Megatron-LM框架进行训练。算力需求方面，训练32B模型需要约8K个轨迹，论文未明确报告总计算量，但从规模推断需要数百GPU小时。评估方面，论文使用Terminus-2脚手架，进行4次独立运行并报告均值和95%置信区间，评估协议透明。主要挑战是重建Docker环境的资源需求，但由于提供了Dockerfile列表和构建流程，理论上可以重现。总体而言，论文提供了充分的实现细节和开源代码，复现难度中等偏高，主要限制在于计算资源需求。
论文图表
