中科院开源终端特工：AI合成数据训练大模型操控命令行

先给出几个核心判断：让AI真正掌握电脑操作，尤其是黑底白字的命令行界面，一直是行业内的硬骨头。中科院软件所的最新成果可能改变这一局面——他们推出了LiteCoder-Terminal方案，核心理念是：与其四处搜寻现成的训练数据，不如构建一台“自动出卷机”，让AI自行出题、搭建考场、批改答卷。

一个让AI学会"用电脑"的硬核挑战

多数人对AI的认知还停留在对话框里那个能聊天、写文章、画图的聪明助手。但假设这样一个场景：让AI真正坐到电脑前，面对布满代码的黑色终端，自主敲命令、分析报错、调整策略，最终独立完成复杂的系统任务——例如部署数据库、排查网络故障或批量处理文件。它能胜任吗？

命令行界面是程序员最熟悉的终端环境，也是数字世界中最底层、最通用的操控入口。从管理服务器、处理海量数据、部署应用到诊断网络问题，命令行几乎无处不在。对AI而言，掌握这一界面意味着它具备了在真实计算机系统中自主执行任务的能力，而不仅仅是给出建议或生成代码——它能“亲自上手”了。

但训练出这样的“终端特工”极其困难。现有方法主要从GitHub、Stack Overflow等平台爬取真实案例——好比想培养一位厨师学徒，就让他天天在餐馆后厨外偷师，观察大厨的操作。这种方式有两个明显短板：第一，能观察到的菜系有限，冷门领域可能根本没有素材；第二，偷学来的菜谱质量参差不齐，甚至难以验证是否靠谱。更要命的是，当学徒在某道菜上始终学不会时，你无法专门为他定制一道针对性练习题。

中科院软件所的研究团队给出了一套全新解法：与其四处搜寻，不如关起门来自编教材——完全由AI自动生成终端环境、任务题目以及评测标准。这套方案名为LiteCoder-Terminal-Gen，基于它构建的数据集和训练好的模型统称为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查阅完整论文，相关模型和数据集也已经开源发布。

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%，提升幅度相当显著。这说明通过长链条终端交互学到的规划、反馈处理和状态追踪能力，是可以跨任务泛化的通用能力。