用合成数据喂出来的终端智能体，凭什么只用 1 万条轨迹就能打平 50 万条的效果？

🎯 核心摘要：训练一个能在命令行里干活的 AI 智能体，最头疼的事是什么？不是模型不够大，而是训练数据太难搞——你得从 GitHub 上爬仓库、整理 issue、构建可执行环境，费时费力还覆盖不全。中科院软件所这篇 LiteCoder-Terminal 提出了一条"零依赖"的合成路线：直接从领域规范出发，用 LLM 自动生成可执行、可验证的终端训练环境。11,255 条合成轨迹训出来的 32B 模型，在 Terminal Bench 上的表现竟然能和用了 50 万条轨迹的 Nemotron-Terminal 打平——数据效率差了 43 倍。这不是底层算法突破，但工程上的数据生成范式确实值得关注。

📖 论文信息

  • 标题：LiteCoder-Terminal: Scaling Long-Horizon Terminal Environments for Learning Language Agents
  • 作者：Xiaoxuan Peng, Kaiqi Zhang, Xinyu Lu（共同第一作者）, Boxi Cao, Yaojie Lu, Hongyu Lin, Xianpei Han, Le Sun
  • 机构：中国科学院软件研究所中文信息处理实验室，中国科学院大学
  • arXiv：2605.29559
  • 资源：https://huggingface.co/Lite-Coder/

🧠 问题出在哪：终端智能体的训练数据瓶颈

你想过没有，为什么 SWE-bench 那条赛道上模型进步飞快，但"在终端里完成复杂系统任务"这件事进展却慢得多？

区别在于任务性质。SWE-bench 本质是"给你一个 bug 描述，生成一个 patch"——输入输出相对确定。但终端任务是另一回事：你得在一个部分可观察的环境里，跨多个步骤执行命令，根据反馈动态调整策略，管理文件系统状态、网络配置、权限变更……这更像是在玩一个文本冒险游戏，只不过游戏世界是真实的 Linux 系统。

Terminal Bench 系列基准（1.0、2.0、Pro）就是为了评估这种能力而设计的。但评估有了，训练数据从哪来？

传统路线是这样的：从 GitHub/Stack Overflow 上爬取真实仓库和 issue → 人工或半自动整理成可执行任务 → 构建 Docker 环境 → 收集智能体轨迹。这条路有三个硬伤：

  1. 领域覆盖受限：你只能爬到开源社区里有的东西，网络安全、系统管理这些领域的高质量 issue 本来就少
  2. 环境可控性差：真实仓库的依赖关系复杂，Docker 环境经常构建失败
  3. 无法靶向训练：模型在"版本控制"上弱，你没法按需生成这个领域的训练数据

LiteCoder-Terminal-Gen 的核心命题就是：能不能完全抛开外部数据源，从零合成出可执行、可验证的终端训练环境？

🏗️ 方法核心：五阶段合成管线

整体架构

整个 LiteCoder-Terminal-Gen 框架分为三大块：任务生成 → 环境合成 → 轨迹收集。

图1：领域到任务生成流程

图1：从领域规范到可行任务的生成流程。利用 Magpie 式采样策略，将领域特定的系统提示拼接 <user_start> 标签后送入 LLM（DeepSeek/Kimi），让模型在用户角色下自回归生成任务描述，再经 Judge LLM 做可行性过滤。

第一步：领域到任务生成

这个设计挺巧妙的。作者没有让 LLM 直接"请生成一个网络安全任务"（这种方式容易生成千篇一律的东西），而是用了 Magpie 论文的技巧——把对话模板的 <user_start> 标签直接拼到领域系统提示后面，利用模型的自回归特性"补全"出用户查询。

覆盖了 10 个终端领域：AI/ML、构建工具、数据科学、网络、安全、系统管理、版本控制、编码、科学计算和游戏。

生成之后还有一道可行性检查——Judge LLM 会评估任务是否满足：适中复杂度、清晰描述、可用资源（毕竟你不能生成一个"请配置一个 Kubernetes 集群"然后期望在单机 Docker 里跑通）。

第二步：五阶段环境合成

这是整篇论文最核心的工程贡献。原始任务描述只是一段自然语言，要变成可执行环境，需要经过五个阶段：

图2：LiteCoder-Gen 五阶段合成管线

图2：从原始任务描述到完整可执行环境的五阶段管线。每个阶段都以前序阶段的累积执行日志为条件，确保因果一致性。

阶段1 - 指令精炼：把模糊的任务描述重写为可测试的规范。关键约束是所有文件路径必须绑定到 /app 下的绝对路径，输出格式必须确定性可验证（JSON 键名、CSV 列名、浮点精度都得定死）。还有一个细节——精炼器被明确提示"不要泄露解决方案提示"到指令中。

阶段2 - 环境初始化：生成 Dockerfile 和输入工件。基于 Ubuntu 24.04 模板扩展，而非从零编写。提示经过调优确保"预装的依赖不会把任务简单化"——比如任务要求你配置 nginx，环境里不会预装 nginx。

阶段3 - 解决方案合成：生成完整的 solve.sh。这个工件有双重作用：(a) 证明任务确实可解；(b) 为验证器提供参考答案。

阶段4 - 验证器生成：这一步最有意思。为了确保验证器既不太松（接受懒惰解决方案）也不太紧（误拒合法变体），作者设计了一个四阶段对抗迭代：

步骤 动作 目的
Draft 基于规范写初始断言 建立基线
Attack 模拟懒惰学生（空文件、硬编码假数据） 如果通过说明断言太弱
Refine 模拟用不同策略的专家 如果被拒说明断言过度指定
Finalize 综合前三步写最终版本 平衡鲁棒性和灵活性

这个 Draft-Attack-Refine-Finalize 的设计思路，其实在软件测试领域有对应——mutation testing 的理念。只不过这里是让 LLM 自己跟自己对抗。

阶段5 - 资源配置：自动推断 CPU、内存、存储配额和超时时间。

每个阶段都有轻量级存在性检查，失败触发重试。最终产物是一个自包含的 Harbor 格式任务目录。

第三步：轨迹收集与过滤

用 MiniMax M2/M2.1 作为教师模型，通过 Terminus-2（86.6%）、OpenHands（7.1%）和 Claude Code（6.3%）三种脚手架收集轨迹。

过滤环节用 LLM 判官从四个维度打分：

  • 适应性：遇到错误能否换策略，而非死循环
  • 接地性：是否关注实际输出，而非凭空假设成功
  • 持久性：面对 "command not found" 是否尝试变通
  • 显式拒绝：直接拒绝执行的轨迹一律排除

最后做 13-gram 去污染，确保与 Terminal Bench 评测集无重叠。

📊 数据集长什么样

图3：LiteCoder-Terminal-SFT 数据集分布

图3：左侧是 10 个领域的分布饼图（大致均衡，最大 12.0% 构建工具，最小 7.3% 科学计算）；右侧是 Top-20 命令分布——cat 以 17.2% 遥遥领先，其次是 ls（10.6%）和 echo（10.2%）。

几个值得注意的数据点：

  • 总量：11,255 条专家轨迹（SFT）+ 602 个可验证环境（RL）
  • 平均轮次：每条轨迹 27.4 轮交互——这不是简单的单步命令，是真正的长时域任务
  • 命令覆盖：超过 720 个不同的 Linux 命令，从常见的 cat/ls/grep 到稀有的 mongod/kubeadm/nasm 都有

🧪 实验结果：数据效率是最大亮点

主实验

模型 TB-1 (pass@1) TB-2 (pass@1) TB-Pro (pass@1) 平均
Qwen3-4B-Instruct（基线） 6.25 1.12 3.50 3.62
LiteCoder-Terminal-4b-sft 14.69 4.78 21.50 13.66
Qwen3-30B-A3B-Instruct（基线） 16.56 5.34 20.50 14.13
LiteCoder-Terminal-30b-a3b-sft 24.38 12.36 31.50 22.75
Qwen2.5-Coder-32B-Instruct（基线） 12.19 4.49 13.50 10.06
LiteCoder-Terminal-32b-sft 29.06 18.54 34.00 27.20
TerminalTraj-32B（50.7K 轨迹） 33.44 23.88 30.50 29.27
Nemotron-Terminal-32B（490.5K 轨迹） 27.81 21.35 37.00 28.72

几个关键观察：

SFT 提升幅度惊人。32B 模型在 TB-1 上从 12.19% 跳到 29.06%，涨了将近 17 个绝对百分点。TB-2 上从 4.49% 到 18.54%，四倍多的增长。这说明基础模型确实缺乏终端交互的专项能力，而合成数据能有效补上这块短板。

数据效率是核心卖点。LiteCoder-Terminal 只用了 11.2K 轨迹，TerminalTraj 用了 50.7K，Nemotron-Terminal 用了 490.5K。数据量差了 4.5 到 43.6 倍，但 32B 模型的平均 pass@1（27.20%）与 Nemotron-Terminal（28.72%）只差 1.5 个点，在 TB-1 上甚至超过了它。

坦率地讲，这个数据效率优势可能部分来自于合成数据的"纯净度"——没有真实仓库里那些噪声和冗余，每条轨迹都是精心过滤过的高质量示范。但也可能存在另一种解释：合成数据的分布与 Terminal Bench 的评测分布恰好比较匹配（毕竟都是 LLM 生成的任务），这一点作者没有深入讨论。

DMPO 的增量收益

方法 TB-1 TB-2 TB-Pro 平均
SFT 基线 14.69 4.78 21.50 13.66
+ DMPO 14.38 6.10 23.00 14.49

DMPO 在 4B 模型上的提升不算大（平均 +0.83 个点），但方向是对的——在更难的 TB-2 和 TB-Pro 上有正向收益。

说到 DMPO 这个方法本身，它是 2024 年 EMNLP 上的工作，核心思想是：标准 DPO 把多轮交互当成单步决策来优化，忽略了环境状态的变化。DMPO 通过引入折扣状态-动作占用度量来修正这个问题，让早期决策获得更高权重（因为早期错误会级联影响后续所有步骤）。

\[\mathcal{L}_{\text{DMPO}} = -\mathbb{E}_{(\tau_w, \tau_l) \sim \mathcal{D}} \left[ \log \sigma \left( \beta \sum_{t=1}^{|\tau_w|} \alpha_t^{(w)} \log \frac{\pi_\theta(a_t^w | s_t^w)}{\pi_{\text{ref}}(a_t^w | s_t^w)} - \beta \sum_{t=1}^{|\tau_l|} \alpha_t^{(l)} \log \frac{\pi_\theta(a_t^l | s_t^l)}{\pi_{\text{ref}}(a_t^l | s_t^l)} \right) \right]\]

其中权重 \(\alpha_t = \frac{\gamma^{t-1}(1 - \gamma^{T-t+1})}{1 - \gamma^T}\) 是归一化折扣因子，\(\gamma=0.7\) 意味着越早的动作权重越大。

领域消融：哪些数据最值钱？

移除的领域 平均分下降
games ↓ 2.50
security ↓ 2.15
version control ↓ 1.58
coding ↓ 1.58
data science ↓ 1.39
ai_ml ↓ 1.31
system admin ↓ 1.02
networking ↓ 0.61
build tools ↓ 0.37
scientific comp. ↓ 0.27

有意思的是，"games"和"security"这两个看起来最"偏门"的领域，移除后对整体性能影响最大。作者的解释是：这些领域的任务往往涉及复杂的边缘情况推理和依赖管理，这些能力能广泛迁移到其他领域。

我的理解是，games 类任务可能涉及大量的编译配置、依赖解析和调试循环，security 类任务则需要精确的权限管理和多步验证——这些恰好是终端操作中最考验"长时域规划"能力的场景。

测试时扩展：合成数据教会了模型"探索"

图4：pass@k 随采样预算增长的曲线

图4：绿色是基础 Qwen3-Instruct，蓝色是 LiteCoder-Terminal。微调后的模型不仅 pass@1 更高，随着采样次数增加，pass@k 的增长斜率也明显更陡。

这张图揭示了一个重要信号：基础模型在增加采样预算时很快饱和（重复相同的失败模式），而 SFT 后的模型能持续从更多尝试中获益。30B-A3B 变体从 k=1 的 24.4% 扩展到 k=4 的 40.0%，涨了 15.6 个百分点。

这说明合成轨迹不只是教会了模型"正确答案"，更重要的是教会了它"怎么探索"——遇到错误时换策略、尝试不同工具链、从反馈中学习。这恰好对应了轨迹过滤中"适应性"和"持久性"两个维度的筛选标准。

跨任务泛化到 SWE-bench

图5：SWE-bench 跨任务泛化结果

图5：尽管训练数据完全不涉及 SWE-bench 式的仓库级 bug 修复，终端交互能力的提升依然能迁移过去。4B 模型从 1.2% 到 5.2%，30B 模型从 5.8% 到 13.0%。

这个结果我觉得挺有说服力的。SWE-bench 的任务结构和 Terminal Bench 差异很大（前者是 patch 生成，后者是系统操作），但底层都需要"在终端里多步交互"的能力。合成终端轨迹训练出来的模型，这种底层能力确实泛化了。

🔬 我的判断

亮点

  1. 数据效率的故事讲得很好。11K vs 490K，效果接近——这对资源有限的团队是个好消息。零依赖合成意味着你不需要维护复杂的数据爬取管线。

  2. 验证器的对抗设计（Draft-Attack-Refine-Finalize）是整篇论文工程上最精巧的部分。这解决了合成数据最大的痛点：如何确保自动生成的测试用例既不太松也不太紧。

  3. 领域消融和跨任务泛化实验做得扎实，不只是报主表数字，还回答了"哪些数据有用"和"能力能否迁移"这两个关键问题。

值得商榷的地方

  1. DMPO 的收益偏小。只在 4B 模型上做了 RL 实验，平均只涨了 0.83 个点。作者没有在 32B 模型上跑 DMPO——可能是计算资源限制，但这让 RL 部分的说服力打了折扣。

  2. 合成数据与评测集的分布匹配问题。Terminal Bench 的任务也是人为设计的（Docker 环境 + 自动验证），和 LiteCoder-Terminal-Gen 的生成范式有天然的结构相似性。如果换一个更"野生"的评测场景（比如真实运维工单），效果是否还能保持？

  3. 教师模型的天花板。用 MiniMax M2 收集轨迹，学生模型的上限就被教师模型卡住了。论文没有讨论教师模型本身在 Terminal Bench 上的表现，这让人无法判断"学生学到了教师多少能力"。

  4. 只用了 Ubuntu 24.04。所有环境都是单一 OS，这在论文的局限性部分也承认了。真实世界的终端操作涉及各种发行版、macOS、甚至 Windows WSL，泛化性存疑。

工程启发

如果你也在做终端/代码智能体的训练，这篇论文的几个实践值得借鉴：

  • Magpie 式任务采样比直接 prompt "请生成一个任务"效果好，因为它利用了模型的自回归分布而非指令遵循能力
  • 四阶段对抗验证器设计可以迁移到任何需要自动生成测试用例的场景
  • 轨迹过滤的四个维度（适应性、接地性、持久性、非拒绝）是一套不错的质量标准，比简单的"通过/不通过"更细粒度

💡 收尾

这篇论文的核心贡献不在算法层面（SFT + DMPO 都是成熟方法），而在于数据生成范式的转变：从"依赖外部数据源"到"零依赖按需合成"。11K 条合成轨迹就能达到接近 50 万条真实轨迹的效果，这个数据效率故事如果能在更多评测场景下复现，对整个智能体训练领域都有参考价值。

不过，我对"合成数据能否完全替代真实数据"这个问题持保留态度。合成环境再精巧，也是在一个受控的 Docker 沙箱里。真实运维场景中那些诡异的环境变量冲突、版本不兼容、权限链路问题——这些"脏活"可能还是需要真实数据来覆盖。

如果你在做类似的终端智能体项目，这篇论文至少告诉你一件事：高质量的合成数据 + 精心设计的过滤标准，可能比海量但嘈杂的真实数据更有效。

觉得有启发的话，欢迎点赞、在看、转发。跟进最新AI前沿，关注我