6000 条数据把 32B 模型干到 SOTA：CLI-Universe 是怎么"造题"的
做 Agent 训练的人大概都有过这种憋屈：模型架构、训练框架、算力都齐了，结果卡在数据上。尤其是终端智能体（terminal agent）这种活——你得让模型在真实的 Linux 环境里敲命令、改配置、debug、跑数据管线，多步交互、状态依赖、还得有可执行的验证。这种任务的高质量训练数据，是真的难搞。
主流做法是什么？爬 GitHub 仓库、扒文档、把现成的执行轨迹和模板"翻新"成任务。听起来很合理，但你真用过就知道，这些素材压根不是为"训练任务"设计的。直接转换出来的东西，要么指令含糊不清，要么执行路径浅得一步到位，要么测试脆得一碰就碎——脚本能跑起来，但根本提供不了有效的监督信号。
其实核心矛盾就一句话：现有 pipeline 都在扩任务来源，而不是扩任务质量。
这篇 arXiv:2606.22883 提出的 CLI-Universe 就盯着这个问题来的。它不去翻新现成素材，而是反过来——先定义"我要考什么能力"，再去真实技术资料里"找证据把题坐实"，最后用 Docker 化的多阶段可执行验证把题筛一遍。整条流水线下来，约三分之二的候选任务被淘汰，只留下真实、可验证、且非平凡有挑战的。
最后的结果挺能打：只用 6000 条轨迹微调 Qwen3-32B，在 Terminal-Bench 2.0 上拿到 33.4 分，刷新了"用开源数据训练、参数量 ≤ 32B"这个组别的 SOTA，甚至超过了好几个大它一个数量级的开源模型。
论文信息
- 标题：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
- 机构：南京大学、StepFun、ZODA、华中科技大学、上海人工智能实验室
- arXiv：2606.22883（提交于 2026 年 6 月 22 日，20 页，5 图 3 表）
为什么"翻新现成素材"这条路走不通
先把动机讲透。终端智能体要学的东西，本质是一套"在真实环境里把活干完并验证完成"的能力。一个合格的训练任务，得满足三个硬条件：
- 真的难——需要多步交互，跟真实环境反复纠缠，而不是一行命令搞定
- 可执行验证——有严格的测试给出明确的监督信号，而不是"脚本跑通了就算对"
- 指令清晰——别让模型猜你到底要什么
现有的合成方法分两条路。一条是让 LLM 从技能/领域分类体系里枚举生成任务（覆盖面广），另一条是从现成基础设施里抽——比如从开源仓库收割 Docker 环境，或者把正常配置改坏制造 debug 场景。两条路都能把任务"数量"做上去，但对单个任务的验证质量、训练信号密度，几乎没有保证。
问题就在这。你想想看，一个从 README 里抠出来的"任务"，它的测试可能只是检查某个文件存不存在——模型随便 touch 一下就过了，这种轨迹喂给模型,学到的是啥？是投机取巧。
所以 CLI-Universe 干脆掉头，走了一条由内而外（inside-out）的路：不从现成产物倒推任务，而是先用结构化的能力规格定义任务该考什么，再去找证据把它落地。
方法：三阶段流水线，每一步都在做减法
整个 pipeline 分三大步，配合下面这张总览图看最清楚。
图1：CLI-Universe 三阶段流水线。Step 1 任务蓝图构建——结构化分类体系播种多样候选，每个候选经迭代式深度研究坐实后编译为蓝图；Step 2 环境实现——蓝图被实例化为带物化资产和可验证运行时的 Docker 容器；Step 3 可执行验证——测试 Agent 与解题 Agent 相互独立地验证任务，只有通过 rubric 测试和 fail-to-pass 检查的实例才被保留。
Step 1：任务蓝图构建——先定义"考什么"
这一步是整篇论文我觉得最聪明的地方。它不从素材出发，而是从四个正交维度的能力分类体系采样组合，作为任务的"锚点"：
| 维度 | 含义 | 举例 |
|---|---|---|
| Domain（领域） | 任务所属的技术领域 | 视频处理、文件操作、模型训练、数据科学、优化、数据查询 |
| Skill Type（技能类型） | 需要的专业技术知识 | 算法、系统、配置、密码学 |
| Capability（能力） | 任务要诱发的推理行为 | 探索、错误恢复、约束满足、长程规划 |
| Engineering Pillar（工程支柱） | Agent 执行的工作形态 | 新功能开发、debug、DevOps、重构 |
对每个领域，作者预定义了每个维度的取值池，然后采样维度组合作为锚点。给定一个锚点（比如"视频处理 + 系统 + 长程规划 + 重构"），就围绕它头脑风暴具体任务点子，强制任务去触发指定的能力模式——这样保证的是技能层面的多样性，而不只是表面话题的多样性。
生成的点子会按创意、技术扎实度、可行性打分，只有高分候选才进入下一步。
证据引导的精炼（Evidence-Guided Refinement）——这是 Step 1 的灵魂。一个专门的研究 Agent 拿着抽象点子，去真实技术资料里搜：仓库、文档、issue 讨论、教程、用法示例，把这些证据逐步揉进任务规格里，把它"坐实"到具体的工具、真实的约束、已知的失败模式、明确的输入输出契约上。搞不定的（比如需要不存在的工具、约束互相冲突）直接丢掉。
这一步有用吗？数据说话：经过证据精炼的任务，需要的解题轮数是未精炼版本的 3.45 倍，pass rate 反而降了 13.3 个点。
这个数我盯着看了一会儿。轮数翻 3 倍多、通过率掉 13 个点，说明精炼是真的在抬高任务的真实难度，而不是把轨迹无意义地拉长。这俩指标合在一起才有说服力——单看轮数变长可能是模型在瞎转，但配上通过率下降，就坐实了"题变难了"。
蓝图形成与验证：精炼后的候选被编译成一份蓝图，记录三样东西——面向用户的指令、用于构建参考解的内部 hint、以及环境检查清单。然后做基于 rubric 的蓝图审查。这一步让接受率从 72% 拉到 91%（人工评判），从 75% 拉到 93%（LLM 评判），而且人工和 LLM 评判高度一致。
Step 2：环境实现——把蓝图变成能跑的 Docker
只有通过验证的蓝图才进到这一步。
资产物化（Asset Materialization）：照着环境检查清单，系统去公开资源里搞来需要的资产——源码仓库、文档、数据集、配置文件、服务日志等等。但现成资产很少能精确匹配任务规格，所以系统会"改造"它们：规范化数据格式、注入受控的故障、调整配置参数、把内容裁剪到目标工作流。实在找不到合适外部资产的，就从零合成——造出有已知 ground-truth 属性的受控变体，并生成下游测试需要的验证元数据。
环境组装（Environment Assembly）：把物化资产打包进 Docker 镜像，连同依赖、运行时配置（环境变量、服务、权限）和钉死版本的包，确保可复现。每个组装好的环境还要过一遍冒烟测试——验证依赖装好了、服务起来了、文件布局对、基本端到端可达。过不了的直接丢。
Step 3：可执行验证——三道筛子，淘汰三分之二
这是保证训练信号质量的关键环节，也是这篇论文最硬核的工程。
测试构建（Test Construction）：一个测试 Agent 生成候选测试套件，然后拿一组测试用例 rubric（覆盖正确性、确定性、边界覆盖）逐条检查，反复精炼或替换，直到测试能给出稳定的可执行信号。
那这些自动生成的测试靠不靠谱？作者拿同一套测试构建流程跑了 89 个 Terminal-Bench 2 的官方任务，跟官方测试对比：官方解能通过我们合成测试的比例是 91%，用 Codex 配 GPT-5.4 做 agent-as-judge 的语义匹配达到 88%。这个交叉验证我给好评——它没有自说自话"我的测试很好"，而是拿公认的 ground truth 来对齐。
解构建 + Hint 条件过滤（Hint-Conditional Filtering）：解题 Agent 拿着环境和内部 hint 生成成功轨迹（hint 给关键步骤但不出现在任务 query 里，锚定解题路径同时保住任务的外部难度）。然后做一个很妙的对照——另一个 Agent 不给 hint 去做同一个任务：只有"无 hint 失败、有 hint 成功"的任务才保留。这一刀砍掉了那些不给提示也能轻松做出来的水题，让数据集聚焦在监督信号真有训练价值的任务-轨迹对上。
Fail-to-Pass 过滤：最后一道，要求生成的测试在初始环境上必须失败，在执行了 hint 引导的解题轨迹后必须通过。这个双向检查同时干掉两种垃圾——测试平凡通过的空任务，和压根没到达目标状态的无效轨迹。每个保留下来的样本，都被证明实现了"从未解状态到已验证解"的可执行状态转移。
三道筛子叠加，约 三分之二的候选被拒，端到端只有 33.6% 存活。下面这张图把每一步的收益和留存率都量化了。
图2(d)：五道筛子的逐阶段留存率，端到端仅保留 33.6% 的候选。论文用 (a)-(c) 分别验证了三个流水线阶段的有效性：证据精炼把解题轮数拉到 3.45 倍、pass rate 降 13.3 个点（难度真实上升）；rubric 蓝图审查把接受率提到 91%/93%（人工/LLM）；合成测试与 Terminal-Bench 2 官方 ground truth 在 91% 的抽样任务上一致。
实验：6K 数据，把 32B 顶到组别第一
作者用 Qwen3 dense 系列（8B / 14B / 32B）做基座，各微调 6k 条 CLI-Universe 轨迹（教师模型是 Kimi-K2.6）。评测主要在 Terminal-Bench 1.0 / 2.0 上，用 Terminus 2 scaffold，每任务 200 轮，报告 avg@4。
主结果：≤32B 组别通杀
先看主表。我把关键行摘出来：
| 模型 | 参数量 | TB 1.0 | TB 2.0 |
|---|---|---|---|
| 闭源 Claude-Opus-4.5 | – | 47.5 | 57.8 |
| 闭源 Gemini 3 Pro Preview | – | 46.4 | 56.9 |
| 闭源 GPT-5.2 | – | 54.4 | 54.0 |
| GLM-4.7 | 358B | 48.8 | 41.0 |
| SkillSynth-32B | 32B | 33.8 | 29.6 |
| Kimi-K2-Instruct | 1T | 44.6 | 27.8 |
| Nemotron-Terminal-32B | 32B | – | 27.4 |
| Qwen3-Coder-480B | 480B | 37.5 | 23.9 |
| TerminalTraj-32B | 32B | 35.3 | 22.0 |
| Qwen3-32B（基座） | 32B | 11.2 | 3.4 |
| CLI-Universe-32B | 32B | 38.8 | 33.4 |
| CLI-Universe-14B | 14B | 27.5 | 23.0 |
| CLI-Universe-8B | 8B | 19.1 | 10.9 |
CLI-Universe-32B 的 33.4 分，干翻了所有同规模、用开源数据训练的对手：SkillSynth-32B（29.6）、Nemotron-Terminal-32B（27.4）、TerminalTraj-32B（22.0）。更狠的是，它还超过了好几个大一个数量级的开源模型——480B 的 Qwen3-Coder（23.9）、1T 的 Kimi-K2-Instruct（27.8）。
当然得客观：跟最强闭源系统比，差距还在。Claude-Opus-4.5 是 57.8，CLI-Universe-32B 是 33.4，中间隔着一条不小的沟。论文自己也没回避这点。
增益随模型规模放大
这是我觉得比"刷榜"更有意思的一个发现。看模型缩放。
图3(b)：Qwen3 基座 vs CLI-Universe 在 8B/14B/32B 上的 TB 2.0 分数，蓝色徽章标注绝对增益。
Qwen3 基座在三个规模上几乎是平的：8B/14B/32B 分别是 2.5 / 4.0 / 3.4。单纯把基座模型做大，根本解锁不了终端智能体能力——这点挺反直觉的，但想想也对，base 模型没见过这类 agentic 数据，参数再多也使不上劲。
而训了 CLI-Universe 数据之后，同样的 checkpoint 跳到 10.9 / 23.0 / 33.4，相对基座的增益单调随规模放大：+8.4 → +19.0 → +30.0。
这说明 CLI-Universe 数据是"随模型容量缩放"而不是"饱和"的——越大的学生模型，能从同一批教师轨迹里榨出越多价值。换句话说，在这个区间里，大模型还没被数据难度卡住脖子，数据本身的难度和质量撑得住。
消融：拆哪个零件都掉 3-6 分
作者在 1k 任务子集、Qwen3-32B 学生上做组件消融，完整 pipeline 基线是 26.7 分：
- 去掉资产策略：掉 6.2 分（到 20.5）——最伤，说明播种环境的多样性是任务覆盖的主驱动
- 去掉 query rubrics：掉 3.4 分（到 23.3）——指令质量持续约束模型能学到什么
- 去掉测试用例 rubrics：掉 3.9 分（到 22.8）——高保真验证对可训练轨迹贡献明显
三个组件是互补的，不是冗余。每一阶的质量控制都对下游有贡献。
还有两个数据侧消融也值得记一下：
| 维度 | 设置 | #轨迹 | TB 2.0 |
|---|---|---|---|
| 轨迹选择 | 全保留 | 10k | 28.2 |
| 轨迹选择 | 仅成功轨迹 | 6k | 33.4 |
| 教师模型 | DeepSeek-V4-Pro | 6k | 31.2 |
| 教师模型 | Kimi-K2.6 | 6k | 33.4 |
注意第一行：只留 6k 条成功轨迹，反而比留全部 10k 条高 5.2 分。失败和不完整的交互引入了噪声，在这个规模上拖累训练信号。质量过滤比堆数量更重要——这跟整篇论文"做减法"的哲学是自洽的。教师模型那组则说明 pipeline 对教师选择是鲁棒的，换个前沿模型也能产出强监督，不绑死某一家。
数据效率：同样 6K，信息密度碾压
图3(c) 把三个数据源在 Qwen3-32B 上等数据量（都是 6k）对比：CLI-Universe 拿 33.4，Nemotron 28.9，TerminalTraj 18.0。换算成相对基座（3.4）的增益就是 +30.0 vs +25.5 vs +14.6。同样的轨迹数，CLI-Universe 的单条信息密度明显更高。这就回应了开头那句话——榜分的提升靠的是任务和验证的质量，不是轨迹数量。
泛化：不止刷 Terminal-Bench
为了证明不是过拟合到 TB，作者还在两个域外 agentic 基准上测：BFCL v4（函数调用）和 VitaBench（多轮工具使用）。CLI-Universe-32B 在 BFCL v4 上比 Qwen3-32B 高 11.3 分（58.0 vs 46.7），在 VitaBench 上高 11.6 分（27.0 vs 15.4）。说明学到的工具编排、环境状态追踪、多步规划这些能力是可迁移的，不是窄拟合到 TB 上。
分类目分析里，最大增益出现在数据处理（+62.5）、机器学习（+50.0）、数据查询（+50.0）、模型训练（+43.8）。但也有死角——视频处理和游戏类在 32B 上零增益，作者老实承认这是未来 pipeline 要补的方向。
错误分析：训出来的模型，"翻车姿势"变了
这部分是我个人最喜欢的，因为它没停在"我比你高几分"，而是去看失败的结构性差异。作者用 Codex 配 GPT-5.4，把每条失败轨迹归到 9 种失败模式之一，再聚成三大类：执行（Execution）/ 连贯（Coherence）/ 验证（Verification）。
图5：TB 2.0 失败轨迹的主要失败归因。每条失败轨迹被归到一个最主要的失败模式（互斥，每行求和为 100%）。9 种模式分三类：执行（违反规格、步骤重复、不知终止）、连贯（上下文丢失、任务偏航、推理-动作不匹配）、验证（过早终止、无/错误验证、弱验证）。
前沿 SOTA 模型主要栽在验证侧。四个闭源基线（Claude-Opus-4.6、GPT-5.3-Codex、GLM-5、DeepSeek-V4-Pro），验证类失败都是最大头，占 47%-60%。这说明它们不是不会执行、不会推理——而是干完活之后，不去正确检查目标状态到底满足没有就草草收工。
更细看，验证侧还分两种相反风格：Opus 是"弱验证"主导（36%，GPT 才 10%）——它查了，但查得太浅没抓住问题；GPT 是"无/错误验证"主导（47%，Opus 才 20%）——它干脆跳过检查。GLM-5 和 DeepSeek 跟 GPT 一个路子，执行侧还更糙一点。
而 CLI-Universe-32B 的失败画像挪到了执行侧。验证占比降到 27%，执行升成最大类 44%。最显著的变化是"步骤重复"，从前沿基线的 0-7% 飙到 23%。这是种性质不同的失败——不是跳过验证，而是在执行中卡住，对同一个操作反复打转、做不出稳定进展。
我对这个结论的解读是：CLI-Universe 的训练数据，因为有 fail-to-pass 这种强验证约束，把"验证意识"刻进了模型——所以它栽在验证侧的概率反而比顶级闭源还低。但 32B 的执行底子有限，于是瓶颈转移到了"卡住、打转"这种执行层面的问题上。这其实给后续优化指了路：执行侧的鲁棒性（比如循环检测、进展评估）是下一步该补的。
我的判断：这是一篇"工程哲学"很正的论文
先说亮点。
它把"数据质量"这件抽象的事，做成了可量化、可消融的工程。 整篇论文从头到尾贯彻一个信念——做减法。三分之二的候选被淘汰、只留成功轨迹反而更好、每道筛子都有数据支撑收益。这种"宁缺毋滥"的克制，在如今动辄"我们造了百万级数据"的氛围里，是挺难得的清醒。
inside-out 的设计真的漂亮。 先定义能力空间再找证据坐实，而不是从现成产物倒推，这从根上解决了"任务质量受限于素材"的问题。证据精炼那个 3.45 倍轮数 / -13.3 通过率的实验，把"难度提升"坐实得很扎实。
交叉验证做得诚实。 拿 89 个 TB-2 官方任务对齐自家测试（91% 一致），这种"用公认 ground truth 验证自己工具"的做法，比自吹自擂强太多。错误分析也没停在刷分，而是去挖失败的结构性差异——这是有研究品味的体现。
再说几个我会打问号的地方。
TB 2.0 的评估会不会有"同源优势"？ 论文的能力分类体系是"distilled from patterns observed across TB-Agent tasks"——也就是分类维度本身是从 TB 任务里提炼的。那么用这套分类合成的数据去刷 TB，天然就更对味。虽然 BFCL/VitaBench 的泛化结果缓解了这个担忧，但我还是觉得，在一个与 TB 分布更无关的基准上验证，结论会更硬。
baseline 全用 Terminus 2 scaffold，唯独 LiberCoder 用 OpenHands。 scaffold 对 agent 表现影响很大，这种混用多少让对比不那么干净。当然这可能是客观限制（人家就那么发的），但读者心里得有数。
6k 的天花板。 作者自己也承认数据规模小、quality ceiling 受教师模型能力约束、且没探索 RL 训练能不能进一步追平闭源。这些都是真实的开放问题，不是套话。
总的说，如果你也在做 agentic 数据合成——不管是终端、浏览器还是别的工具环境——CLI-Universe 这套"结构化采样 → 证据坐实 → 多阶段可执行验证"的范式都值得抄作业。尤其那个 hint-conditional filtering（无 hint 失败、有 hint 成功才保留）和 fail-to-pass 双向检查，是即插即用的好零件，能直接帮你把数据集里的水题清掉。
数据效率这件事，可能会越来越成为开源追赶闭源的主战场。与其卷数据量，不如卷每一条轨迹的信息密度——这篇论文给了一个相当扎实的样板。
觉得有启发的话，欢迎点赞、在看、转发。跟进最新 AI 前沿，关注我