企业官网建设流程全解析

CLI-Universe: Towards Verifiable Task Synthesis Engine for Terminal Agents

作者：Zhanbo Hua, Yifan Yao, Weihao Xie, Yongchi Zhao, Minghao Liu, Ruizhi Qiu, Zhewei Huang, Zun Wang, Yiyan Ji, Yunhai Ye, Letian Zhu, Xinping Lei, Han Li, Zhiyuan Ma, Zili Wang, Zhaoxiang Zhang, Jiaheng Liu
核心发表机构：Nanjing University、StepFun、ZODA、Shanghai AI Lab、Huazhong University of Science and Technology
论文链接：arXiv:2606.22883v1
发布于：arXiv 预印本（cs.AI）

一、核心贡献 / Core Contributions

• 提出 CLI-Universe 任务合成引擎：这是一个“由内向外”（inside-out）的终端智能体（terminal agent）训练任务合成框架。与现有方法从表面工件或已有仓库反向构造任务不同，CLI-Universe 从多维能力分类法（multi-dimensional capability taxonomy）出发，通过组合采样生成候选任务，再经证据引导的深度研究（evidence-guided deep research）将任务锚定到真实技术材料上，最终以 Docker 化环境和多阶段可执行验证保证任务质量。
• 构建了严格的五阶段可执行验证流水线：包括 rubric 门控的测试构建（rubric-gated test construction）、提示条件过滤（hint-conditional filtering）、严格失败-通过检查（strict fail-to-pass checking）等关键环节。从候选生成到最终数据集的完整流水线中，约三分之二的候选被系统性地丢弃，仅保留真实的（genuine）、可验证的（verifiable）和非平凡有挑战的（non-trivially challenging）任务。这种高淘汰率并非浪费，而是高质量监督信号的核心保障。
• 发布了高度蒸馏的数据集 CLI-Universe-6K：包含 6,000 条由教师模型 Kimi-K2.6 在通过验证的 CLI-Universe 任务上采样的成功轨迹。在轨迹选择上，仅保留通过全部测试用例的成功轨迹；这一策略使数据量相对于原始 10k 轨迹减少 40%，但下游任务性能反而显著提升。
• 实现了新的开源数据训练最先进水平（SOTA）：在 Qwen3-32B 上微调 CLI-Universe-6K，在 Terminal-Bench 2.0 上达到 33.4%（avg@4），刷新了在开源数据上训练的 ≤32B 参数模型的最优成绩，并超越了多个参数规模大一个数量级的开放权重模型（如 1T 的 Kimi-K2-Instruct 和 480B 的 Qwen3-Coder）。这一结果有力证明了结构化、高保真合成数据相对于盲目扩大数据规模的数据效率优势。
• 系统性地验证了每个设计决策的有效性：通过管道组件消融、轨迹选择策略消融、教师模型消融、数据规模分析和跨基准泛化实验，逐个环节证实了从任务生成到验证过滤的每一步都对最终性能有可量化的贡献，而非整体管道的“黑盒”式成功。

二、研究背景与动机 / Background & Motivation

近年来，基于大型语言模型（LLM）的终端智能体在复杂命令行（CLI）任务上展现了令人瞩目的能力——从调试程序、管理系统、安全分析到数据工程流水线搭建，这些智能体需要在一个完全开放、多步骤、高不确定性的环境中进行规划、执行和验证。然而，能力的上限在很大程度上受制于一个根本性瓶颈：高质量、可执行的训练数据严重稀缺。终端智能体任务与普通代码生成任务有着本质区别：它要求模型在真实 shell 环境中进行多轮交互，需要处理环境状态的变化、工具调用的失败、长距离依赖的保持以及最终目标状态的验证。这意味着训练数据不仅是“指令-应答”对，而是完整的、可执行的环境-轨迹-测试三元组。这类数据的获取成本极高，人工构建难以规模化。

为了突破这一瓶颈，研究者们提出了多种合成数据管道。但这些现有管道存在一个普遍倾向：通过将表面层人工制品（surface-level artifacts）——如开源仓库、文档、模板、配置文件——改造成任务来扩大数据规模。论文将这类方法概括为“扩展任务来源”（scaling task sources）而非“扩展任务质量”（scaling task quality）。这种策略带来了三个系统性的问题。

第一，指令模糊（ambiguous instructions）。当任务是从已有工件倒推出来时，指令往往是“在这个仓库里做点什么”这类含糊的描述，缺乏精确的输入/输出契约。模型无法从中学到清晰的意图理解能力，反而可能学会猜测指令背后的模糊意图。第二，执行路径浅（shallow execution paths）。表面工件改造出来的任务往往只需要一两条命令就能完成，不具备真实的探索、调试和多步骤规划需求。模型即使完成了任务，其轨迹中也不包含有价值的长程推理和错误恢复行为。第三，测试脆弱（brittle tests）。由于任务本身缺乏严格的可验证目标，测试用例往往只是简单检查某个文件是否存在或某条命令是否执行成功，无法区分“真正解决问题”和“偶然通过”。这类测试即使被通过，也只能提供微弱的学习信号，甚至可能引导模型学习到投机取巧的行为。

这些问题的根源在于，现有管道在任务生成阶段就将质量上限锁死了。如果任务本身没有清晰的能力规格、没有锚定到真实世界的技术约束、没有经过可执行层面的验证，那么下游任何精心的训练策略都无法弥补数据在源头上的缺陷。

CLI-Universe 的出发点正是对这一现状的回应：任务合成不应从“有什么材料”出发，而应从“我们希望模型具备什么能力”出发。论文提出了一个原则性的任务合成引擎，核心思路是“由内向外”：首先基于结构化能力分类法明确定义要生成的任务类型，然后通过证据引导的深度研究将每个候选任务锚定到真实技术材料中，最后用多阶段可执行验证确保任务既能被解决、又不会被平凡地解决。这个思路将任务合成从一个“回收利用”的过程转变为一个“设计与制造”的过程，从根本上提升了合成数据的质量上限。

三、方法 / Methodology

3.1 总体框架 / Overall Architecture

CLI-Universe 的整体管道分为三个阶段：任务蓝图构建（Blueprint Construction）、环境实现（Environment Realization）以及测试构建与可执行过滤（Validation & Filtering）。

第一阶段从多维能力分类法出发，通过组合采样生成候选任务规格，然后由一个专门的研究智能体对候选任务进行证据引导的深度精炼，将任务锚定到真实世界的技术材料中。这一阶段的产出是一个经过验证的任务蓝图（blueprint），其中包含面向用户的指令、用于参考解决方案构建的内部提示（internal hint）以及环境检查清单（environment checklist）。第二阶段将蓝图实例化为 Docker 化环境，包括资产物化（asset materialization）、环境组装和冒烟测试。第三阶段并行运行测试智能体和解决方案智能体：测试智能体生成候选测试套件并对照 rubric 迭代修订；解决方案智能体在内部提示引导下生成成功轨迹。随后，经过提示条件过滤和严格的失败-通过检查，最终保留能够实现“未解决→已验证”状态转换的高质量任务-轨迹对。

整个管道是一个严格的漏斗结构。从候选生成到最终数据集，每一阶段都设置了质量关卡，任何无法通过某阶段验证的候选都会被直接丢弃。论文报告称，端到端仅有 33.6% 的候选被保留——约三分之二被丢弃。这个数字不是管道低效的体现，而是其质量控制的直接效果：在任务合成领域，淘汰低质量候选正是为了确保保留样本的每个都承载足够的训练信号。

3.2 关键模块 / Key Modules

3.2.1 候选任务生成：多维能力分类法

CLI-Universe 的任务生成不是无约束的头脑风暴，而是在一个精心设计的四维分类法空间中进行组合采样。这四个维度是：领域（domain）、技能类型（skill type）、能力（capability）和工程支柱（engineering pillar）。每个维度都有一组预定义的候选值池，各领域内维护该维度允许的值组合，以保证生成的候选具有现实性。

领域维度定义了任务所属的应用场景，包括软件工程、调试、系统管理、文件操作、安全、数据处理、数据查询、数据科学、科学计算、数学、优化、机器学习、模型训练、视频处理、Web 与 API 工具、游戏和个人助理等 17 个类别。技能类型维度标注任务所要求的核心专项技术知识——算法、数据处理、系统、配置、Shell 脚本、数学、部署、密码学——每个任务只标注一个主导技能类型，以保持学习信号的聚焦。能力维度描述任务应引发的推理行为，如探索（在制定计划前探查陌生工作区）、错误恢复（读取显式失败信号并调整计划）、长程规划（在超过 10 个有意义轮次中维持连贯计划）、约束满足（同时维持多条相互拉扯的硬性规则）、逆向工程等；每个能力都有严格的触发/签名/非规则（trigger/signature/not），确保标注的一致性。工程支柱维度则刻画智能体执行的工作形态：新功能创建、调试、系统编程、DevOps、功能迭代、大规模重构。

生成过程首先在四维空间中采样组合作为锚点（anchor），例如“数据处理 × 密码学 × 逆向工程 × 调试”这样一个组合，然后在这些锚点的约束下进行任务想法的头脑风暴。这种方法确保了任务多样性体现在底层技能和能力模式上，而非仅仅停留在表面主题的更换。生成的任务想法按创造性（creativity）、技术接地性（technical grounding）和可行性（feasibility）三个标准打分，只有最高分的候选进入下一阶段的证据引导精炼。

3.2.2 证据引导精炼

候选任务在进入蓝图阶段之前，需要经过一个关键的“接地”过程——证据引导精炼。这是 CLI-Universe 区别于表面工件改造法的核心机制之一。

一个专门的研究智能体被分配来对每个候选任务做迭代式精炼。该智能体检索真实世界的技术材料——包括开源仓库、官方文档、issue 讨论、教程和使用示例——并将这些证据逐步整合进任务规格中。具体来说，证据被用来锚定任务中的工具选择（必须使用哪些真实存在的工具）、现实约束（哪些限制条件是实际工作中会遇到的）、已知失败模式（哪些坑是该领域中真实存在的）以及输入/输出契约（任务产物的精确格式和验证方式）。精炼过程持续进行，直到任务规格足以支撑后续的查询生成、环境构建和测试生成。如果一个候选任务无法被充分锚定——例如依赖的工具不可用、约束条件相互冲突——该候选会被直接丢弃。

论文通过一个对照实验量化了证据引导精炼的效果。将精炼前后的任务分别交给求解器尝试，结果显示：经过证据引导精炼的任务，求解器所需回合数增加了 3.45 倍，而通过率下降了 13.3 个百分点。这两个变化方向看似“变差了”，但实际上正是设计意图的体现——精炼后的任务更加真实、更加具有挑战性，不再是可以轻松解决的表面任务；求解器需要投入更多的探索和推理才能完成。这证明精炼提高的是任务的真实难度，而不是通过拉长轨迹来制造虚假的困难。

3.2.3 蓝图形成与验证

精炼后的候选任务被编译为结构化的蓝图。蓝图包含三个关键组件：面向用户的指令（user-facing instruction），即最终呈现给智能体的任务描述；内部提示（internal hint），用于引导参考解决方案的构建，但不会出现在实际任务查询中；环境检查清单（environment checklist），明确规定环境应包含的资产、配置和文件系统布局。

蓝图本身也需要经过验证。论文引入了一个基于 rubric 的审查流程：所有审查者——无论是人类专家还是 LLM 评判者——都按照一套明确的评分标准评估蓝图的清晰度、完备性和可实现性。实验数据表明，经过 rubric 化的蓝图验证后，人工审查接受率从 72% 提升到 91%，LLM 审查接受率从 75% 提升到 93%。更值得注意的是，人工与 LLM 的判断高度一致，说明 rubric 化的验证标准为蓝图质量提供了一种可扩展的自动化评估途径，而不必依赖昂贵的人工审查。

3.2.4 环境实现：资产物化、组装与冒烟测试

通过验证的蓝图进入环境实现阶段。这一阶段的目标是将蓝图中的环境检查清单转化为一个真实可运行、可复现的 Docker 化环境。

资产物化（asset materialization）过程首先根据蓝图要求从公开资源获取所需资产——源代码仓库、文档、数据集、配置文件、服务日志等。然而，现实中的外部资产几乎不会与任务规格完全匹配。因此系统需要进行针对性的适配操作：标准化数据格式以符合任务预期；注入受控故障（如引入 bug、破坏配置、设置陷阱）以创造调试场景；调整配置参数使环境状态与蓝图一致；将内容裁剪到预期工作流范围内。当外部资产不可用时，系统会从零开始合成资产，生成具有已知 ground-truth 属性的受控变体，同时产出验证元数据供下游测试使用。

环境组装将物化后的资产打包进 Docker 镜像，包括所有依赖项、运行时配置（环境变量、服务、权限）以及固定的包版本，确保环境的可复现性。资产按蓝图指定的文件系统位置放置，并关联组件间的引用（如配置文件中的路径、数据库连接串），使环境自包含。组装完成后，每个环境需要执行一套冒烟测试：依赖安装是否成功、服务能否正确启动、文件系统布局是否与蓝图一致、基本端到端可访问性是否满足。未通过冒烟测试的环境会被直接丢弃，因为一个无法稳定运行的环境不可能产生可靠的训练信号。

3.2.5 测试构建与可执行过滤

环境就绪后，系统进入质量把关最严格的验证阶段。这一阶段由四个关键机制组成，每个机制都针对一类特定的低质量样本。

第一步是测试构建与 rubric 门控。测试智能体基于已实现的环境和蓝图中指定的验证目标，生成候选测试套件。每个测试都会被反复对照一组测试用例 rubric——覆盖正确性、确定性、边界覆盖等维度——进行检查，不合格的测试被修订或替换，直到测试能够提供稳定且可执行的成功信号。

论文使用一个巧妙的一致性实验验证了测试构建管道的保真度：将相同的测试构建管道应用于 89 个 Terminal-Bench 2 任务，然后检查管道生成的测试与 Terminal-Bench 2 官方 ground truth 的匹配程度。结果显示，官方解决方案通过合成测试的比例高达 91%，而 LLM 智能体裁判对两者的语义匹配度为 88%。这表明管道生成的测试与官方验证标准高度一致，有能力准确判断任务是否被真正完成。

第二步是解决方案构建。解决方案智能体被提供已实现的环境和蓝图中的内部提示，生成一条能够成功解决任务的轨迹。内部提示包含关键解决步骤和预期中间状态，相当于为解决方案智能体提供了“路线图”，但这条路线图不会出现在最终的任务查询中。这样设计的目的在于：锚定一条合理的解决路径，同时保留任务面向外部模型时的真实难度。生成的轨迹只有在能够在已实现环境中真正解决任务、并且与测试套件确立的可执行完成信号一致时，才会被保留为候选训练数据。

第三步是提示条件过滤（hint-conditional filtering）。一个独立的智能体在没有任何内部提示的条件下尝试解决任务。只有当“无提示尝试失败”且“有提示尝试成功”同时成立时，该候选——即任务与对应轨迹配对——才会被保留。这一机制的目的是剔除那些平凡可解（trivially solvable）的任务。如果一个任务在没有提示的情况下轻而易举地被解决，说明它的难度不足以提供有价值的训练信号；反之，如果任务在有提示的情况下仍然无法被解决，则说明任务可能超出了当前模型的能力范围或存在规格问题。提示条件过滤确保最终数据集中的每个任务都处于“有挑战但可解决”的最佳难度区间。

第四步是失败-通过过滤（fail-to-pass checking），这是整个验证流水线的最后一道关卡。对每个保留的解决方案，系统施加一个双向条件：生成的测试必须在初始环境上失败（证明测试不是空洞的“永远通过”测试）；在执行提示引导的解决方案轨迹后必须通过（证明轨迹确实达到了目标状态）。这个检查同时去除了两类有害样本：空洞任务（测试平凡通过，无法提供区分度）和无支撑轨迹（虽然运行了一堆命令但实际未达成目标状态）。只有通过这一检查的样本，才被认为实现了从“未解决状态”到“已验证状态”的可执行转换。

经过上述五阶段过滤——候选评分、证据精炼、蓝图验证、环境冒烟测试、测试/解决方案双重过滤——从最初的候选池到最终数据集，仅有 33.6% 的候选被保留。另约三分之二被丢弃。这种高淘汰率是 CLI-Universe 数据高保真度的直接保障：保留的不是最容易生成的样本，而是最难被“糊弄”过去的样本。

原论文对应图片（Primary failure attribution on failed TB~2.0 trajectories.）：

四、实验 / Experiments

4.1 数据集与评估指标 / Datasets & Metrics

论文构建了 CLI-Universe-6K 数据集，包含 6,000 条高质量轨迹。这些轨迹由教师模型 Kimi-K2.6 在通过完整验证的 CLI-Universe 任务上采样产生，然后经过严格的成功/失败过滤——只有通过全部测试用例的成功轨迹被保留。

训练设置方面，学生模型为 Qwen3 密集系列（8B、14B、32B），使用多轮 SFT（multi-turn SFT）进行微调。训练超参数包括：AdamW 优化器（β2=0.95）、峰值学习率1 × 10 − 5 1 \times 10^{-5}1×10−5、cosine 学习率调度（最小值为1 × 10 − 6 1 \times 10^{-6}1×10−6）、warmup 比例 0.03、权重衰减 0.01、最大梯度范数 1.0、训练 5 epochs、上下文长度 64K、bf16 精度，使用 32 块 NVIDIA H200 GPU，全局 batch size 为 64。完整的训练细节在论文附录中给出；这些超参数不是本文的贡献点，但确保了训练过程的可复现性。

评估设置方面，主要基准为 Terminal-Bench 1.0（TB 1.0）和 Terminal-Bench 2.0（TB 2.0）。评测脚手架使用 Terminus 2，每个任务最多 200 轮，报告指标为 avg@4。泛化性评估使用 BFCL v4（函数调用基准）和 VitaBench（多轮工具使用基准）。所有基线模型和 CLI-Universe 模型都在同一评测框架下运行，以保证对比的公平性。

4.2 主实验结果 / Main Results

论文的主实验结果由三个相互关联的层面构成：与现有模型的直接对比、CLI-Universe 内部不同规模模型的缩放表现，以及跨基准的泛化能力。

与现有模型的对比。在 Terminal-Bench 2.0 上，CLI-Universe-32B 取得 33.4% 的 avg@4 分数，显著超越所有同尺寸、使用开源数据训练的模型。SkillSynth-32B 为 29.6，Nemotron-Terminal-32B 为 27.4，TerminalTraj-32B 为 22.0，LiberCoder-32B 为 19.5。这一优势在 14B 和 8B 规模上同样成立：CLI-Universe-14B 为 23.0，对比 SkillSynth-14B 的 19.9、Nemotron-Terminal-14B 的 20.2、TerminalTraj-14B 的 19.1；CLI-Universe-8B 为 10.9，对比 SkillSynth-8B 的 13.5 以下的表现。

更引人注目的是，33.4% 的成绩超越了几个参数规模大一个数量级的开放权重模型：Kimi-K2-Instruct（1T 参数）为 27.8，Qwen3-Coder-480B（480B 参数）为 23.9，LiberCoder-235B 为 31.0，Minimax-M2.1（229B 参数）为 29.2。在 TB 1.0 上，CLI-Universe-32B 也取得了 38.8% 的成绩。这直接验证了论文的核心主张：结构化、高保真的合成数据可以弥补模型参数规模的不足。

从与基线模型的相对提升来看，CLI-Universe 带来的增益是惊人的。Qwen3-32B 基线的 TB 2.0 分数仅为 3.4，经 CLI-Universe-6K 微调后跃升至 33.4，绝对提升 +30.0 个百分点。在 14B 规模上从 4.0 提升到 23.0（+19.0），在 8B 规模上从 2.5 提升到 10.9（+8.4）。这组数据揭示了一个重要的规律：基线 Qwen3 模型在 8B 到 32B 范围内几乎持平（2.5 / 4.0 / 3.4），说明没有针对性的智能体数据，单纯扩大模型规模并不会解锁终端智能体能力；而同样的 CLI-Universe 数据在更大模型上带来了更大幅度的提升，说明数据质量与模型容量的组合存在协同效应——高质量数据能让更大模型的容量优势真正发挥出来。

按任务类别的表现分解。论文进一步将 TB 2.0 的结果按细粒度类别分解，以理解 CLI-Universe 数据在哪些类型的任务上带来了最大的能力提升。在大多数类别上，Qwen3-32B 基线的得分接近零——终端智能体能力几乎完全未被激活；CLI-Universe 微调后在几乎所有类别上实现了显著激活。绝对增益最大的类别包括数据处理（+62.5）、机器学习（+50.0）、数据查询（+50.0）和模型训练（+43.8），这些都是 CLI-Universe 分类法中重点覆盖的领域。系统和软件类别的增益也相当可观：系统管理 +41.7、安全 +37.5、软件工程 +28.8。值得注意的是，视频处理和游戏类别在 32B 模型上没有任何增益，这意味着当前分类法或任务生成在这些领域存在覆盖不足的问题，为未来管线扩展指明了方向。

跨基准泛化。CLI-Universe 数据是否只是让模型过拟合了 Terminal-Bench 的任务分布？为了回答这个问题，论文在 BFCL v4 和 VitaBench 上评估了训练后的模型。在 BFCL v4 上，CLI-Universe-32B 达到 58.0 分，相比 Qwen3-32B 基线的 46.7 提升 +11.3；在 VitaBench 上达到 27.0 分，相比基线的 15.4 提升 +11.6。8B 模型在两个基准上分别获得 +7.0 和 +1.1 的提升。这些结果表明，CLI-Universe 任务所训练出来的能力——工具编排、环境状态追踪、多步骤规划——具有跨基准的适用性，模型学到的是通用的终端智能体技能，而非针对特定评测集的数据拟合。

错误研究。论文还进行了一项系统的失败归因研究。方法是对每个模型在每个 TB 2.0 任务上执行两次轨迹推演，使用 Codex with GPT-5.4 作为评判者，将每条失败轨迹按 9 种失败模式中的“最根本原因”进行归类。9 种失败模式分为三大类：执行（Execution）——包括不遵守规范、步骤重复、未意识到终止；连贯性（Coherence）——包括上下文丢失、任务偏离、推理-行动不匹配；验证（Verification）——包括过早终止、无/错误验证、弱验证。

对于前沿闭源模型，失败主要集中在验证类别，占比为 47% 到 60%。这意味着 Claude-Opus-4.5、GPT-5.3-Codex、GLM-5 和 DeepSeek-V4-Pro 这些模型的智能体通常在执行和推理上表现出色，但在任务接近完成时没有正确检查目标状态是否真正满足。进一步分析揭示了两种截然不同的验证风格：Opus 以“弱验证”为主（36%，GPT 仅为 10%）——执行了检查但过于浅层；而 GPT 以“无/错误验证”为主（47%，Opus 仅为 20%）——倾向于完全跳过检查。GLM-5 和 DeepSeek-V4-Pro 遵循 GPT 的模式，但执行类错误占比稍高。

CLI-Universe-32B 的失败模式分布则呈现显著差异：验证类失败从闭源模型的近半降至 27%，而执行类上升为最大类别（44%）。其中最突出的转变是“步骤重复”从基线模型的 0–7% 跃升至 23%。定性分析表明，这一失败模式在性质上与 SOTA 模型不同——CLI-Universe 模型并非跳过验证，而是在执行过程中更容易卡住，重复相同的操作而无法取得稳定进展。这与论文附录中记录的 build-pov-ray 任务案例高度一致：智能体在 357 轮中重复curl命令 165 次、find命令 151 次、grep命令 44 次，尽管推理中多次提到要改变策略，实际执行的命令却始终不变。

错误研究揭示了一个重要的方向性问题：CLI-Universe 的训练数据针对“验证纪律”这一能力维度产生了显著的训练效果，但代价是暴露了执行稳定性的不足。这也呼应了论文在局限性部分承认的事实：合成数据的质量上限最终受到底层模型能力的制约。

4.3 消融实验 / Ablation Study

4.3.1 管道组件消融

为了评估管道各组件的贡献，论文在 1k 任务子集上对 Qwen3-32B 进行了消融实验。完整管道的 TB 2.0 分数为 26.7。依次移除关键组件后，性能出现显著下降：

• 移除资产策略（asset strategy）：分数降至 20.5（-6.2），是所有消融中影响最大的单个组件。资产策略决定了环境的多样性来源——如何从真实世界获取、适配和合成资产——直接影响了任务覆盖的广度和真实性。这一结果说明，种子环境的多样性是任务覆盖范围的主要驱动因素，也是管道中最难被替代的部分。
• 移除测试用例 rubrics：分数降至 22.8（-3.9）。没有 rubric 门控的测试构建容易产生脆弱的、低区分度的测试，从而削弱整个验证体系的有效性。
• 移除查询 rubrics：分数降至 23.3（-3.4）。查询（即任务指令）的质量直接决定了模型能否理解任务意图；缺乏 rubric 约束的查询容易产生模糊或不完整的指令。

三个组件的贡献相互独立且互补，移除任何一个都会造成显著性能回退，说明 CLI-Universe 的每个质量控制环节都不可省略。

4.3.2 轨迹选择策略消融

数据过滤是否是提升效果的关键？论文对比了两种轨迹选择策略：保留全部约 10k 条轨迹（包括失败和不完整轨迹）与仅保留 6k 条通过全部测试的成功轨迹。结果显示，完整 10k 轨迹训练得到 28.2 分，而 6k 成功轨迹训练得到 33.4 分。数据量减少 40%，性能反而提升 +5.2 个点。

这一结果对终端智能体数据合成领域具有重要的方法论启示：失败和不完整的交互轨迹会引入噪声和错误模式，若不加过滤地纳入训练集，会降低整体监督信号的质量。许多现有方法倾向于“尽量多保留数据”，但 CLI-Universe 的证据表明，在数据合成管道中，正确性质量过滤远比原始轨迹数量更重要。这与论文摘要中“高度蒸馏数据集”（highly distilled dataset）的表述直接对应——“少而精”是 CLI-Universe-6K 设计的核心原则。

4.3.3 教师模型消融

CLI-Universe 管道的有效性是否依赖于特定的教师模型？论文在相同任务集上使用不同教师模型各采样 6k 轨迹，蒸馏到相同的 Qwen3-32B 学生模型上。使用 Kimi-K2.6 作为教师获得 33.4 分，使用 DeepSeek-V4-Pro 作为教师获得 31.2 分。两者都能显著超越所有同规模开源数据训练模型，说明管道对教师模型的选择具有鲁棒性——并不需要依赖某一个特定的前沿模型才能产生强监督信号。同时，2.2 分的差距也表明教师模型质量会直接传导到下游微调效果：更好的教师产生更好的轨迹，进而训练出更好的学生。

4.3.4 数据规模与数据效率

论文进一步考察了训练轨迹数量对性能的影响。在 Qwen3-8B 上使用规模递增的训练子集进行微调，结果显示性能随数据规模稳步提升，在最大实验预算下没有出现饱和迹象。这意味着 CLI-Universe 合成管线有能力继续产生有效的监督信号，当前 6k 的数据规模尚未到达收益递减点；扩大数据池有望带来进一步的性能提升。

数据效率的比较更加直观。在 32B 规模上，CLI-Universe-6K 达到 33.4 分，而使用相同数据量（6k 条）的其他开源数据训练方案——Nemotron-Terminal 为 28.9，TerminalTraj 为 18.0——都存在显著差距。与 Qwen3-32B 基线 3.4 分相比，CLI-Universe 的增益为 +30.0，Nemotron 为 +25.5，TerminalTraj 为 +14.6。CLI-Universe 在每条轨迹上的信息密度显著更高。论文进一步对比了达到或超过特定基线所需的轨迹数量，结果是 CLI-Universe 数据所需的训练轨迹数量少 1–2 个数量级（10–100 倍）。这不是微调技巧的胜利，而是任务内在质量和验证机制驱动的结果：每一条 CLI-Universe 轨迹都经过完整验证、锚定真实技术约束、并经过难度过滤，因此每一条都能传递比普通合成轨迹多得多的学习信号。

原论文对应图片（Component ablation.）：

原论文对应图片（Component ablation.）：

原论文对应图片（Component ablation.）：

原论文对应图片（Generalization across agentic benchmarks (BFCL~v4, VitaBench).）：

原论文对应图片（Generalization across agentic benchmarks (BFCL~v4, VitaBench).）：

五、相关工作 / Related Work

CLI-Universe 的研究背景横跨两个密切相关的领域：终端智能体的进展与终端智能体合成数据。

终端智能体。近年来，基于 LLM 的终端智能体取得了长足进步。大量 agent 脚手架（scaffold）——如 Claude Code、Codex CLI、Gemini CLI、OpenHands、OpenCode 等——通过增强 LLM 的规划、执行和工具调用能力，使模型能够在真实终端环境中完成复杂任务。评测方面，Terminal-Bench 提供了人工设计的、覆盖多样领域的容器化评测环境，已成为终端智能体能力评估的事实标准之一。然而，开源模型与闭源系统在终端任务上的差距仍然明显。一个关键原因是数据瓶颈：终端智能体需要的是完整的“环境-动作-观察-验证”序列数据，而这类数据的获取远远比普通指令微调数据更难。

终端智能体的合成数据。已有工作大致可分为两类。

第一类是从技能/领域分类法生成任务，代表工作包括 Endless-Terminals、TermiGen、Data Engineering 和 SkillSynth。这类方法的优点是覆盖面广，能够枚举出多样化的任务主题和技能组合；但其局限在于，逐任务的验证质量和训练信号密度缺乏保证。分类法生成的候选任务未必锚定到真实技术约束，可能产生指令模糊、执行路径浅的问题。

第二类是从现有基础设施中提取任务，代表工作包括 TerminalTraj 和 CLIGym。这类方法从开源仓库收集 Docker 环境，或将正常配置转换为故障状态来创造调试场景，能够获取大量“现成”的任务。然而，这类任务同样以数量为目标，验证质量保证不足，容易继承原始环境中的噪声和不确定性；而且“改装”出来的任务往往缺乏精确的完成标准。

CLI-Universe 与上述方法的互补性体现在三个层面。第一，任务来源是结构化的能力规格而非表面工件，保证了任务设计是在明确的能力目标指导下进行的。第二，证据引导的深度研究将每个任务锚定到真实世界的技术材料，使任务具备真实工具、真实约束和真实的失败模式。第三，多阶段可执行验证——rubric 门控测试、提示条件过滤、失败-通过检查——确保每个保留的轨迹都符合最严格的质量标准。论文反复强调的一个关键指标是端到端约三分之二候选被淘汰：与“批量生产、质量波动”的现有方法相比，CLI-Universe 的策略是“集中生产、严格把关”，其收益在数据效率实验中得到了量化——十倍甚至百倍的数据效率优势。

六、局限性与展望 / Limitations & Future Work

尽管 CLI-Universe 在数据效率和终端智能体能力解锁方面展示了显著优势，论文自述和实验结果共同揭示了若干不容回避的局限性。

与最强闭源系统的差距仍然明显。在 TB 2.0 上，CLI-Universe-32B 的 33.4 分虽然超越了多个规模更大的开放权重模型，但与 Claude-Opus-4.5 的 57.8 分仍存在约 24 个百分点的差距。错误归因研究提供了洞察：闭源前沿模型的失败主要集中于验证环节，而 CLI-Universe 模型的失败集中在执行环节——特别是步骤重复。这提示我们，当前合成数据管道可能在“验证纪律”维度上产生了过强的训练效应，但在“执行稳定性”维度上的覆盖尚不充分。未来的工作需要在任务生成时更有针对性地引入需要长程稳定执行、抗重复探索的任务模式。

合成数据质量的上限受制于底层模型能力。CLI-Universe 的整个管道——从候选任务的构思、研究智能体的事实查找、环境构建、解决方案生成到测试构建——都依赖基于 LLM 的智能体。尽管存在评分门控和可执行验证等质量保障机制，合成数据的质量上限最终由底层模型的能力决定。如果教师模型在某个任务类型上本身就缺乏能力，那么即使管道能够识别并过滤掉失败的尝试，也无法凭空产生超过教师能力的成功轨迹。论文的教师模型消融实验表明，Kimi-K2.6 和 DeepSeek-V4-Pro 都能产生有效的监督信号，但这并不能排除“更强的教师是否始终带来更好的学生”这一问题的边界条件。

6k 轨迹的数据规模仍有探索空间。数据规模实验表明，在 8B 模型上性能随数据量增加而稳步提升，尚未出现饱和。这意味着当前的 6k 数据集虽然展示了令人印象深刻的数据效率，但可能远未达到该分类法空间所能支持的数据量上限。将管道扩展到更大、更多样化的任务池——特别是当前表现不佳的视频处理和游戏类别——可能带来进一步的性能提升。此外，论文尚未探索在更大规模的开源基座模型（如 70B 以上）上使用 CLI-Universe 数据的收益，也未探索结合强化学习（RL）的后续训练是否能进一步释放合成数据的价值。

任务分类法的覆盖存在盲区。类别分解实验显示，视频处理和游戏两个类别在 32B 模型上没有任何增益，而安全、系统管理等类别的增益虽大但仍然明显不足。这说明当前多维分类法在某些领域中的任务生成效果不佳，可能原因是这些领域的真实技术材料难以获取、任务自动化验证困难，或者候选任务生成阶段对这些领域的锚定不足。未来的管线扩展需要在分类法中引入更细致的领域子类，并针对识别出的稀疏区域优化候选生成和证据精炼策略。

错误模式的分布特征提示训练与评估之间的不一致。错误研究发现 CLI-Universe-32B 的步骤重复比例异常高（23%），这可能是训练数据中成功轨迹的执行模式过于“平滑”所致——经过严格过滤的成功轨迹往往展示的是从起点到终点的顺利路径，而现实中智能体经常需要在失败边缘试探和调整。过度过滤可能意外地剥夺了模型学习“从重复中摆脱”的机会。这是一个值得深思的问题：验证过滤虽然保证了数据正确性，但可能牺牲了训练分布的多样性——即失败经验本身也是有用的学习信号，问题在于如何在不引入噪声的前提下保留它们。

七、总结 / Conclusion

CLI-Universe 提出了一种从根本上不同的终端智能体任务合成思路：不是从已有工件倒推任务，而是从结构化能力规格出发，结合证据引导的深度研究与多阶段可执行验证，系统地“制造”而非“回收”高质量训练任务。这一思路的可行性得到了实验的有力支持：仅用 6,000 条经过严格验证的轨迹微调 Qwen3-32B，就在 Terminal-Bench 2.0 上达到 33.4%——刷新了开源数据训练的 ≤32B 模型最优成绩，超越多个十倍规模的开放权重模型，并在 BFCL v4 和 VitaBench 上展现出跨基准的泛化能力。从更深的层面看，这篇论文最重要的贡献并非一个具体的合成引擎或一个数据集，而是一个可复制的原则：在终端智能体训练数据的生产中，质量监控的统一标准、可执行的逐任务验证、和以能力分类法为导向的任务设计，能带来数量级层面的数据效率提升。端到端约三分之二候选被淘汰的“保守策略”，反而成为突破数据瓶颈的关键——因为智能体训练真正需要的不是更多的数据，而是更确定地值得学习的数据。

原文摘要:While recent LLM-based terminal agents have demonstrated promising capabilities, the scarcity of high-quality, executable training data remains a critical bottleneck. Existing synthesis pipelines typically scale by retrofitting surface-level artifacts into tasks, frequently yielding ambiguous instructions, shallow execution paths, and brittle tests that provide weak learning signals. To overcome this, we introduce CLI-Universe, a principled synthesis engine that constructs terminal-agent tasks. CLI-Universe generates candidate tasks by sampling combinations across a multi-dimensional capability taxonomy (domain, skill type, capability, and engineering pillar), then grounds each candidate through evidence-guided deep research over real-world technical materials. To ensure rigorous supervision, validated blueprints are instantiated into Dockerized environments and subjected to a multi-stage executable verification pipeline featuring rubric-gated test construction, hint-conditional filtering, and strict fail-to-pass checking. Across the full pipeline, from candidate generation to verification, approximately two-thirds of candidates are discarded, retaining only those that are genuine, verifiable, and non-trivially challenging. To validate our framework, we instantiate a highly distilled dataset of 6,000 trajectories called CLI-Universe-6K. Remarkably, fine-tuning Qwen3-32B on CLI-Universe-6K achieves 33.4% on Terminal-Bench 2.0. This sets a new state-of-the-art for models trained on open-source data at or below 32B parameters, and outperforms several models an order of magnitude larger, demonstrating the profound data efficiency of structured, high-fidelity synthesis.

PDF链接:https://arxiv.org/pdf/2606.22883v1

部分平台可能图片显示异常，请以我的博客内容为准