中科院软件所开源"终端特工"：用AI合成训练数据，让大模型真正学会操控命令行

这项研究来自中国科学院软件研究所中文信息处理实验室及中国科学院大学，论文以预印本形式发布于2026年5月，编号为arXiv:2605.29559，感兴趣的读者可通过该编号查阅完整论文。

**一个让AI学会"用电脑"的难题**

多数人对人工智能的印象，可能是对话框里那个能聊天、能写文章的聪明助手。但有没有想过，如果让AI真正坐到一台电脑前，独立打开黑黢黢的命令行窗口，一行一行地输命令、处理报错、调整策略，最终完成一项复杂的系统任务——它能做到吗？

命令行界面，也就是那个程序员经常使用的全是文字的操作界面，是数字世界里最底层、最通用的操作方式。无论是管理服务器、处理大量数据、部署软件，还是排查网络问题，命令行几乎无处不在。对于AI来说，掌握这种界面意味着它真正具备了在真实计算机系统中独立工作的能力，而不只是在对话框里给出一些建议。

然而，训练这样的"终端特工"AI面临一个棘手的困境。现有的训练方式，大多依赖从GitHub、Stack Overflow等网站上爬取的真实案例——就像请一个厨师学徒专门去餐馆偷师，看别人怎么炒菜。这种方式有两个明显短板：一是覆盖的菜系有限，想要哪类菜谱不一定有；二是偷来的菜谱质量参差不齐，还无法验证好不好吃。更关键的是，当AI在某道菜上学得不够好时，你没办法专门为它定制一批针对性的练习题。

中科院软件所的研究团队为这个问题提出了一套全新的解决方案：与其去外面找现成的训练材料，不如自己从零开始"印教材"——完全由AI自动生成训练所需的终端环境、任务题目，以及判断答案对不对的评测标准。这套方案被命名为LiteCoder-Terminal-Gen，而基于此构建的两大数据集和训练好的AI模型，统称为LiteCoder-Terminal项目。

**一、从零造题：这套"自动出卷机"是如何工作的**

要理解LiteCoder-Terminal-Gen的核心思路，可以把它想象成一个能自动出题、自动建考场、自动生成参考答案、自动出评分标准的智能教育系统——而且这一切都不需要任何外部教材。

整个生产流程分为两大阶段。第一阶段是"想出题目"，第二阶段是"把题目变成真正能做的考场"。

在第一阶段，研究团队首先确定了十个终端任务领域，涵盖人工智能与机器学习、构建工具、数据科学、网络、安全、系统管理、版本控制、编程、科学计算以及游戏。针对每个领域，团队精心设计了一套"引导话术"，输入给大语言模型，让模型扮演用户的角色，自然而然地说出符合该领域的真实任务需求。

这个技巧有点像心理暗示——不直接告诉模型"你来出题"，而是把一段对话的开头写好（比如"现在你有一台Ubuntu容器，你的任务是……"），然后在末尾加上一个"用户发言开始"的标记，模型就会自动续写用户可能提出的实际问题。通过控制这段引导性开头，就能引导模型生成特定领域的高质量任务描述。

生成了大量原始题目后，还需要一道"可行性过滤"关卡。一个专门的评判模型会对每道题打分，过滤掉三类不合格的题目：复杂到荒谬的（比如"请在一晚上写出一个操作系统内核"）、描述模糊没有明确成功标准的，以及依赖GPU或需要外部账号登录等现实中无法满足的资源的。只有通过这三关审核的题目，才能进入第二阶段。

第二阶段是把"想法"变成"可以实际运行的考场"，这是整个系统最精妙的部分，由五个步骤组成。

第一步叫做"指令精炼"。原始题目虽然描述了任务意图，但往往不够精确——文件放在哪里、输出格式是什么、精度要求是多少，都没有说清楚。这一步专门负责把模糊的描述改写成可测试的精确规格，比如明确规定"输入文件在/app/input.json，输出必须写到/app/output.csv，结果精确到小数点后两位"。同时，指令中绝对不能透露任何解题提示或测试用例，否则就像考试前把答案告诉了学生。

第二步叫做"环境搭建"。这一步负责为题目创建一个真实可运行的Docker容器环境——相当于给考生准备好考场和所有考试材料。系统会在一个预设的Ubuntu系统镜像基础上，生成对应的环境配置文件，并准备好题目所需的输入数据文件。值得注意的是，准备的依赖工具不能太齐全，否则题目就被"剧透"了。

第三步叫做"解题合成"。系统会为每道题自动生成一份参考解法脚本，这份脚本扮演双重角色：一方面证明这道题确实是可以解出来的（因为有了可运行的脚本），另一方面为下一步生成评分标准提供参照。

第四步叫做"评测器生成"，也是技术含量最高的一步。评测器的核心是一套自动化测试脚本，它负责判断AI给出的解法是否真正解决了问题。但这里有一个微妙的陷阱：评测器是在看到参考解法之后才生成的，很容易只认这一种解法，一旦AI用了不同但同样正确的方法，反而会被误判为错误。

为了解决这个问题，团队设计了一套四阶段的"攻防打磨"流程。首先，初步写出一个检查条件；然后，模拟一个"懒惰学生"——输出空文件、胡乱数据、或者写死一个假结果——如果这些居然能蒙混过关，说明检查条件太宽松；接着，模拟一个"换路子的高手"——用完全不同的实现方式但同样达到目的——如果这被误判为错，说明检查条件太严苛；最后，综合前两轮的反馈，写出一个真正健壮的评分标准。

第五步叫做"资源配置"。系统读取前四步生成的所有内容，自动估算这道题需要多少CPU时间、内存空间和存储容量，生成最终的配置文件，一道完整的题目就此诞生。整个五步流程中，每一步都会读取所有前置步骤的输出日志，确保前后逻辑一致，避免出现"评测器要检查的文件根本没生成"这类荒唐的逻辑错误。

**二、让AI真正"上场做题"：轨迹收集与质量把关**

有了可运行的题目环境之后，下一步是让能力强大的教师模型来实际做题，把整个解题过程——思考、输命令、看到输出、再思考、再调整——完整记录下来，形成一条"交互轨迹"。这些轨迹就是后续用来训练小模型的"教科书"。

研究团队使用了MiniMax公司的M2和M2.1两个强力模型作为教师，通过Harbor这个统一框架来运行任务并收集轨迹。为了让教科书尽量多样，团队还让这些模型在三种不同的"操作风格"下工作：Terminus-2、Claude Code和OpenHands这三个不同的智能体脚手架。每条轨迹记录了模型的推理过程、执行的命令动作，以及终端返回的实际观察结果，完整保留了面对长期复杂任务时"思考-行动-观察"的循环过程。

收集来的轨迹不会全部直接使用，还要经过严格的质量筛查。一个专门的评判模型会从四个维度审核每条轨迹。

首先是"适应性"——AI遇到错误时有没有真正换思路？如果AI一遍又一遍地重复同一个命令，或者只是改改语法但本质上还在走同一条死路，这条轨迹就会被丢弃。好的轨迹应该展示AI理解了报错原因，并切换到了完全不同的工具或策略。

其次是"踏实性"——AI有没有无视实际反馈、自说自话？如果AI忽视了明显的报错信息，或者在没有验证的情况下就声称任务完成了，或者忘记了自己刚才犯过的错误，这条轨迹同样不合格。

再次是"韧性"——AI遇到障碍时有没有轻易放弃？如果AI一碰到"命令不存在"这类环境限制就立刻宣告任务不可完成，而没有尝试任何变通方案，这条轨迹也会被过滤掉。需要注意的是，如果轨迹因为外部超时而中断，这不算放弃；只有AI主动声明任务无法完成时，才认定为放弃。

最后是"拒绝行为"——AI有没有直接拒绝执行任务？任何直接说"我无法帮助完成这个"的轨迹，一律剔除。

通过这四重筛查，留下来的轨迹质量大幅提升。为了防止训练数据与评测题目"撞题"，团队还对所有指令做了13-gram的去重过滤，确保与Terminal Bench评测集没有重叠，最终形成了名为LiteCoder-Terminal-SFT的正式数据集。

**三、数据集长什么样：11255条轨迹里都藏着什么**

最终的LiteCoder-Terminal-SFT数据集包含11255条专家级交互轨迹，覆盖前述十个任务领域，平均每条轨迹长达27.4轮对话。从领域分布来看，各类别分配相当均衡，其中构建工具占比最高（12%），系统管理和网络各占11.6%，安全占10.6%，数据科学和版本控制各占10.4%，人工智能与机器学习占9.7%，编程和游戏各占8.2%，科学计算占7.3%居末位。

从数据来源的操作框架看，绝大多数轨迹（86.6%）来自Terminus-2，OpenHands贡献了7.1%，Claude Code贡献了6.3%。

更能体现数据丰富度的是命令覆盖范围。研究团队把所有轨迹中实际执行的命令提取出来，与Linux命令标准词典对比，发现这些轨迹共覆盖了超过720个真实Linux命令。常用的文件操作（cat、ls、head、tail、wc、find、grep）、版本控制（git）、包管理（apt、apt-get、dpkg、pip、cargo）、编译构建（make、gcc、go、python3）、系统管理（chmod、ps、systemctl、ufw、su）、网络与安全（curl、wget、openssl、gpg、nginx）一应俱全，甚至还包括mongod、kubeadm、grafana-cli、bison、nasm、lvcreate这类专业小众工具。这说明这套数据生成方式并不局限于简单的代码编写场景，而是真正覆盖了广泛的终端使用场景。

在使用最频繁的20个命令中，cat以17.2%的占比高居榜首，ls（10.6%）、echo（10.2%）、git（8%）和python3（7.1%）紧随其后，完整呈现了真实终端操作的命令分布规律。

**四、再进一步：用可验证环境做偏好训练**

光靠模仿教师的做法（也就是监督微调），AI能学到"怎么做"，但不一定能学到"为什么这样做比那样做更好"。为了解决这个问题，研究团队还构建了第二个数据集LiteCoder-Terminal-RL，包含602个完整的可运行终端环境，用于一种叫做"直接多轮偏好优化"（DMPO）的强化训练方式。

DMPO的工作原理可以用一个比喻来理解：假设你在教一个学徒解数学题，你不只是给他看标准答案，而是同时给他看两份解题过程——一份做得对、一份做得差——然后告诉他"这份好，那份不好"，让他自己体会差距在哪里。DMPO就是这个逻辑，区别在于它考虑了多轮交互的特性，并且对不同步骤按时间顺序打了折扣权重——越早期的步骤权重越低，越后期靠近结果的步骤权重越高，这比简单地把整个对话当成一个整体来打分更加合理。

具体操作中，团队从已经监督微调好的4B小模型出发，对每个环境独立采样两次完整的解题轨迹，再用自动生成的评测器给两条轨迹打分。只保留两条轨迹分数明显不同的环境，用得分高的作为"好示例"，得分低的作为"差示例"，构成训练对。这套训练信号完全来自之前自动生成的评测器，不需要任何人工标注。

**五、实验结果：训练效果怎么样**

训练好的LiteCoder-Terminal模型在三个评测基准上接受了考验，分别是Terminal Bench 1.0、Terminal Bench 2.0和Terminal Bench Pro。这三个基准由不同团队设计，考察AI在真实命令行环境中完成各类复杂任务的能力，其中Pro版本对各领域任务分布有更严格的均衡要求，难度也更高。

从监督微调的效果来看，进步幅度相当显著。以4B小模型为例，它的基础版本在Terminal Bench 1.0上只有6.25%的通过率，微调后提升到14.69%，提升了8.44个百分点。在更难的Terminal Bench 2.0上，基础版通过率仅1.12%，微调后达到4.78%，提升幅度超过四倍。中等规模的30B-A3B模型在Terminal Bench 2.0上的基础通过率为5.34%，微调后达到12.36%，同样超过两倍。最大的32B模型在Terminal Bench 1.0上从12.19%提升到29.06%，提升了约17个百分点；在Terminal Bench Pro上达到34%，在三个基准的平均得分达到27.20%。

与业界其他方法相比，LiteCoder-Terminal的表现也颇具竞争力。两个主要的竞争对手——TerminalTraj-32B和Nemotron-Terminal-32B——使用的训练轨迹数量分别是5.07万条和49万条，而LiteCoder-Terminal-SFT只有1.12万条，数量差距最多达到43.6倍。尽管如此，32B版本的LiteCoder-Terminal在Terminal Bench 1.0上超过了Nemotron-Terminal，在Terminal Bench Pro上也取得了顶尖成绩，综合平均分（27.20%）与两个竞争对手（29.27%和28.72%）的差距十分有限。这个结果说明，靠精心设计的合成数据来训练，在数据利用效率上比靠挖掘海量真实数据更有优势。

DMPO进一步强化训练的效果也有所体现，尽管提升幅度较温和。4B模型经过DMPO训练后，在Terminal Bench 2.0上从4.78%提升到6.10%，在Terminal Bench Pro上从21.50%提升到23.00%，综合平均分从13.66%提升到14.49%。Terminal Bench 1.0上略有小幅下降（从14.69%到14.38%），但整体平均分仍然上升。这个结果表明，自动生成的评测器确实能提供有效的正确性反馈信号，足以引导多轮交互任务的强化优化。

**六、深挖细节：哪些领域最重要，更多采样有没有用**

研究团队还做了一系列深入分析，揭示了一些有趣的规律。

第一项分析是"逐个删掉一个领域，看看成绩怎么变"。结果发现，删掉任何单一领域，整体成绩下降都不超过2.5个百分点，说明模型对各领域的依赖是分散的，没有哪一个领域是绝对关键的。但删掉"游戏"领域导致了最大的下滑（2.50分），其次是"安全"领域（2.15分）。这看起来有些反直觉——游戏和安全任务对命令行核心能力的贡献为何这么大？研究者的解释是，这两类任务往往包含复杂的边界情况处理和复杂的依赖管理，而这类能力可以迁移到所有其他任务上。相比之下，删掉"科学计算"或"构建工具"影响最小。

第二项分析是"多试几次有没有用"。pass@k指标衡量的是给AI k次尝试机会，只要有一次成功就算通过——类似于考试允许补考几次。结果显示，经过LiteCoder-Terminal微调的模型，随着尝试次数从1增加到4，成绩提升幅度明显大于未微调的基础模型。以30B-A3B模型为例，在Terminal Bench 1.0上，pass@1是24.4%，pass@4达到40.0%，提升了15.6个百分点，这个增幅远超基础模型的对应提升。这说明微调不只是让模型"背下来"一些固定解法，而是真正提升了模型探索和找到正确路径的内在能力。

第三项分析是跨任务泛化，即"在命令行任务上练出来的能力，能不能迁移到代码修复任务上"。团队把训练好的模型拿去做SWE-bench测试——这是一个评估AI能否修复真实GitHub代码缺陷的权威基准。结果显示，4B模型的代码修复通过率从1.2%提升到5.2%，30B-A3B模型从5.8%提升到13.0%，提升幅度非常可观。这个结果意味着，通过长链条终端交互训练出来的能力，并不局限于命令行场景，对软件工程类任务同样有正向作用。

**七、这套方案的边界在哪里**

研究团队也坦诚地指出了两个主要局限。

第一个局限是数据偏差的问题。所有题目都是由大语言模型生成的，这意味着题目的分布会受到生成模型自身偏好和局限的影响，某些现实中重要但模型不擅长描述的场景，可能在数据集中被低估。

第二个局限是操作系统覆盖的问题。目前所有的训练环境都基于Ubuntu的Docker镜像，主要练习的是GNU/Linux系的工具命令。现实中还有其他Linux发行版以及完全不同的操作系统生态，这些场景目前还没有覆盖。未来如果能将管道扩展到更多操作系统环境，训练出来的AI在不同系统间的泛化能力会更强。

**说到底，这件事意味着什么**

归根结底，LiteCoder-Terminal做的事情，是在证明一件以前很多人存疑的事：不需要大量真实世界的人工数据，只靠AI自己生成练习题、自己验证答案，就能把一个AI训练成真正能独立操作复杂计算机系统的"终端特工"。

这对整个AI工具领域的影响，可能比乍看上去要深远得多。今天的AI助手绝大多数还停留在"给建议"的层面，而不是"自己动手干"。一旦AI能可靠地独立操作终端，那从自动运维服务器、自动分析数据、自动部署软件，到帮普通用户解决复杂的电脑问题，都将成为现实可期的应用场景。

当然，更强的终端操作能力也带来了安全方面的考量。研究团队在论文中明确建议，这类模型应当在人类监督下使用，并且运行在有资源限制、网络隔离和权限控制的沙箱环境中，不应在没有约束的情况下让AI自由执行命令。

有兴趣深入了解这项研究的读者，可以通过arXiv编号2605.29559查阅完整论文，相关模型和数据集也已在Hugging Face的Lite-Coder账号下开源发布。

Q&A

Q1：LiteCoder-Terminal-Gen和普通的爬取数据方法有什么本质区别？

A：普通爬取方式依赖从GitHub、Stack Overflow等网站收集现有数据，覆盖范围受限于已有内容，无法针对AI的薄弱点定向补充。LiteCoder-Terminal-Gen则完全从零生成，输入一个目标技能领域，系统自动生成题目、搭建运行环境、写出参考答案、构建评分标准，形成闭环。最关键的是，它能主动为AI的弱点定制练习题，而不是被动依赖现有数据。

Q2：DMPO和普通的微调训练有什么不同？

A：普通监督微调相当于让AI模仿教师的做法，学的是"怎么做"。DMPO则给AI看两条轨迹——一条好的、一条差的，让AI学会区分优劣，领会"为什么这样比那样好"。DMPO还专门考虑了多轮对话的特性，对不同时间点的步骤按重要程度打了折扣权重，比把整段对话简单地当一个整体评分更合理，特别适合命令行这类需要多步交互的任务。

Q3：LiteCoder-Terminal训练出来的模型只能用于命令行任务吗？

A：不是。实验表明，在命令行任务上训练出来的能力可以迁移到其他软件工程任务。研究团队把训练好的模型拿去测SWE-bench（一个修复真实代码缺陷的标准基准），4B模型的通过率从1.2%提升到5.2%，30B模型从5.8%提升到13.0%，提升幅度相当显著。这说明通过长链条终端交互学到的规划、反馈处理和状态追踪能力，是可以跨任务泛化的通用能力。