阶跃星辰（StepFun）与南京大学联合发布 CLI-Universe，一个面向终端 Agent 的可验证任务合成引擎。仅用引擎生成的 6,000 条高质量轨迹微调 Qwen3-32B，得到 CLI-Universe-32B。在 Terminal-Bench 2.0 上达到 33.4% 准确率，远超 Qwen3-Coder（480B，23.9%）和 Kimi-K2-Instruct（27.8%）。 合成引擎采用多维能力分类学采样 → 证据驱动深度研究 → 多阶段可执行验证流水线，约 2/3 候选任务被过滤，仅保留真实可验证的挑战性任务数据集、模型权重和 Docker 评估环境尚未开源，社区关注度极高。
一句话说清楚：CLI-Universe 在解决终端 Agent 的什么问题
训练一个能在真实终端中执行多步命令的 AI Agent 很难。不是模型不够大，而是没有足够好的训练数据。
终端 Agent 的任务场景极其多样——从配置 Git 仓库、用 OpenSSL 生成证书，到编译 Linux 内核、管理 Docker 容器——每一步命令的执行结果都依赖当前环境状态，一个幻觉命令就能让整条轨迹报废。更麻烦的是，合成训练数据时很难判断「这个任务到底有没有被正确完成」。
现有合成方法通常是事后修补：从已有的文档、脚本或日志中逆向拼凑出任务，再附上一个粗糙的测试脚本。结果往往是指令模糊、执行路径过浅、测试过于脆弱，模型学不到真正有用的推理能力。
CLI-Universe 换了一个思路：从头设计一个能够系统性生成「真实且可验证」终端任务的引擎，而不是从已有素材中薅数据。
核心方法：三层流水线生产高保真合成数据
CLI-Universe 的任务合成引擎由三个紧密配合的阶段组成，每个阶段都在解决一个特定维度的数据质量问题。
阶段一：多维能力分类学采样——确保任务覆盖面不偏科
传统合成方法随机生成任务，容易出现某些技能被过度代表、另一些技能完全缺失的问题。
CLI-Universe 定义了一个多维能力分类学（multi-dimensional capability taxonomy），包含四个维度：
- 领域（Domain）：软件工程、系统运维、数据处理、安全、DevOps 等
- 技能类型（Skill Type）：文件操作、进程管理、网络配置、包管理、权限控制等
- 能力层级（Capability）：单步执行、条件判断、循环编排、多工具协同等
- 工程支柱（Engineering Pillar）：可复现性、错误恢复、日志调试、性能优化等
引擎在这些维度的交叉空间中等概率采样，确保生成的候选任务在技能空间中的分布均匀，而不是集中在某些热门模式上。
阶段二：证据驱动的深度研究——每个任务都有真实世界锚点
候选任务生成后，CLI-Universe 不会直接把它丢进训练集。它执行一轮证据驱动的深度研究：针对每个候选任务，引擎自动搜索真实世界的技术材料（man 手册、官方文档、代码仓库 README、技术博客、Stack Overflow 讨论等），验证这个任务是否对应一个真实存在的终端操作场景。
这个步骤的根本目的，是消除「伪任务」——那些看起来合理但在实际环境中没有明确对应操作的合成任务。只有找到足够真实世界证据支撑的候选，才会进入下一阶段。一个直观的类比是：不是让模型背诵虚构的考试题，而是确保每道题都来自真实工程中的实际需求。
阶段三：多阶段可验证执行流水线——用 Docker + 严格测试确认任务质量
通过证据验证的任务蓝图会被实例化为 Docker 化环境，进入一条严格的多阶段执行验证流水线：
- 评分标准门控测试构造（Rubric-Gated Test Construction）：为每个任务自动生成多条评分标准驱动的测试用例，不是用简单的「输出匹配」来判断对错，而是用多维度评分标准检查终端状态
- 提示条件过滤（Hint-Conditional Filtering）：给任务附加不同程度的提示信号，测试模型是否能在不同提示条件下正确执行，筛选出即使带提示也有足够难度的任务
- 严格失败通过检查（Strict Fail-to-Pass Checking）：确保任务在未正确完成时测试严格失败，在正确完成后测试严格通过，消除测试本身的歧义
论文披露，从候选生成到最终验证的全程中，大约三分之二的候选任务被丢弃。留下的三分之一是那些真正真实、可验证、且具有足够挑战性的高质量任务。
成绩单：33.4% 的 Terminal-Bench 成绩意味着什么
CLI-Universe 引擎生成了 CLI-Universe-6K 数据集，包含 6,000 条经过完整验证的高质量轨迹。用这个数据集微调 Qwen3-32B 后得到的 CLI-Universe-32B，在 Terminal-Bench 2.0 上达到 33.4% 的准确率。
这个成绩放在当时的上下文中看：
CLI-Universe-32B 以 32B 参数量、仅 6K 训练轨迹，大幅领先参数规模大一个数量级的模型。Qwen3-Coder（480B）是它 15 倍的大小，Kimi-K2-Instruct 也是体量大得多的 MoE 架构。这组对比清晰地证明：在终端 Agent 这个特定能力域中，数据质量比模型规模更重要。
论文也明确指出，这是「在 32B 及以下规模、使用开源数据训练的模型中的新 SOTA」——一个诚恳的限定，表明它并未与完全闭源的超大模型进行全面比较。
Terminal-Bench 2.0 本身是一个涵盖约 89 个任务的终端 Agent 评测基准，覆盖软件工程、系统运维、数据处理、ML 工具链、安全配置等领域。它的特点是多步交互、真实环境（Docker 沙箱），评测成本较高（主流模型单次评测约 1K–1K–50K+）。
与同期工作的对照
CLI-Universe 发布同期，另一个重要工作 TMAX（AI2 + 华盛顿大学）也展示了类似趋势：用 14.6K 多样化 Docker 环境 + outcome-only DPPO 训练，9B 模型达到 27%。两者共同指向一个方向——高质量的合成环境和可验证任务比模型大小的 Scaling 更关键。
意义与局限
为什么值得关注
CLI-Universe 的最大价值不在于 33.4% 这个具体数字，而在于它验证了合成数据引擎方法论的可行性。终端 Agent 的训练长期受困于数据瓶颈——手工标注成本极高，自动合成又质量难保。CLI-Universe 的三层流水线（多维采样 → 证据研究 → 可验证执行）提供了一个可复现的解决方案框架。
从行业信号来看，阶跃星辰（StepFun）选择在 Agent 基础设施层而非应用层发力，与同期国内大模型厂商的布局形成差异化。南京大学团队的学术积累（分布式系统、操作系统方向）也与终端 Agent 这个垂直方向天然契合。
当前局限
论文本身也有一些诚实的边界：
- 数据集、模型权重和 Docker 评估环境尚未开源。社区已经在积极呼吁，但截至发稿时还需等待 StepFun 的正式发布。没有开源工具链意味着其他团队暂时无法复现或扩展这个工作。
- Terminal-Bench 2.0 本身存在一定争议。第三方审计发现约 25.7% 的任务存在实现缺陷（隐藏依赖、评分标准错误、验证器脆弱性），清洗后有评测被报告分数提升约 9.6%。这意味着领军模型中可能含有一定的测量噪音。
- 6K 轨迹的高效性令人印象深刻，但 CLI-Universe-32B 在域外泛化上表现如何尚不清楚——如果终端环境超出了合成引擎的训练分布，模型能力是否会快速衰减？
- 论文聚焦于 SFT（监督微调），未涉及后续的 RL 阶段。TMAX 的工作已经表明，在高质量 SFT 基础上叠加 RL 通常还能带来显著提升，CLI-Universe 的合成引擎能否同样服务于 RL 阶段的奖励模型训练，是一个值得关注的方向。
作者、代码与资源
CLI-Universe 由来自 阶跃星辰（StepFun） 与 南京大学 的 17 位研究者共同完成。论文由 Hua Zhanbo、Yao Yifan 等担任一作，Liu Jiaheng 等担任通讯作者。
截至 2026 年 7 月 2 日，CLI-Universe-6K 数据集、CLI-Universe-32B 模型权重以及 Docker 评估环境尚未对外发布。论文详细描述了合成引擎的设计原理和实验设置，对于希望自建类似 Agent 数据管线的开发者团队具有重要的参考价值。
对于使用 Qwen3 系列模型构建终端 Agent 的开发者，这篇论文提供了一条清晰的路径：与其追求更大规模的基座模型，不如花精力在合成引擎和数据质量上——用几千条高保真轨迹就能让一个 32B 模型的能力发生质变。
AI 速览
