FACET：终端任务合成中的源意图保留与可执行状态对齐 FACET: Preserving Source Intent and Executable State in Terminal Task Synthesis
重构技能场景并以真实容器状态对齐工件，合成高密度可验证终端任务
前置知识
终端智能体（Terminal Agent）
指在命令行环境中自主完成任务的 LLM 智能体：接收自然语言指令，迭代执行 shell 命令（查看文件、装依赖、写脚本、跑程序、修报错）来改变环境状态，并根据每步执行反馈决定下一步动作。成败取决于最终环境状态是否满足全部要求，而非回答是否流畅合理。
本文的全部目标就是为这类智能体合成训练任务与成功轨迹，评测也在 Terminal-Bench 2.1 这类容器化终端环境中进行；理解其'改状态、看反馈'的工作方式，才能理解为什么任务包里的四个工件缺一不可且必须一致。
可执行验证器（Executable Verifier）
一段可运行的检查程序（通常为 pytest 测试集），在智能体完成后对容器最终状态断言：文件内容、schema、服务行为等。任务通过与否由 $\nu_V(e_T)$ 是否全部通过决定，实现'以执行结果打分'的客观评价，避免 LLM 主观判分的噪声与可博弈性。
验证器是指令、环境、解法之外的第四个工件，论文的核心贡献正是让四者共享同一份真实容器状态以保持一致；'平均每任务可执行检查数'（FACET 达 22.77）也是衡量数据集验证密度与任务难度的关键指标。
Harbor 任务格式
开放的智能体任务打包与执行框架：每个任务含 instruction.md（指令）、environment/（Dockerfile 与 fixture）、solution/（参考解法）、tests/（验证器）与 task.toml（元数据），可在沙箱容器中统一运行智能体并收集 rollout。
FACET 的产出直接遵循 Harbor 格式，论文的验收标准（镜像可构建、初始态验证器不通过、解法可执行、终态通过验证）都是在这个框架上自动化检验的，复现时也必须按此目录结构交付。
监督微调（SFT）与教师轨迹
用更强教师模型（DeepSeek-V4-Pro 驱动的 Terminus-2）在合成任务上采样 rollout，仅保留完全成功的交互轨迹作专家演示，再对 Qwen3.5-4B/9B/27B 做全参数微调（LLaMA-Factory，3 epochs，8×H200）。
合成任务本身不是终点：论文仅用 1.2K 条成功轨迹就让三个规模的基础模型在 Terminal-Bench 2.1 上稳定提升 6.75–8.24 分，这是'数据有效'的最终证据，也是判断这类合成管线价值的核心指标。
任务验收判据 $A(T)$
论文将任务形式化为 $T=(I,E,S,V,M)$，仅当 $A(T)=B(E)\land\neg\nu_V(e_0)\land(e_T\neq\perp)\land\nu_V(e_T)$ 时接受：环境可构建、验证器拒初始态、解法可执行、终态通过验证，四个条件分别封堵四类废任务。
这是理解全文'跨工件一致性'诉求的钥匙：四个条件分别封堵了环境建不起来、任务太简单、解法跑不通、验证器失效这四类废任务，论文的所有机制设计都是围绕提高满足该判据的概率展开的。
研究动机
终端智能体的后训练需要大规模可执行监督，但手工出题成本高，自动合成又很难'凑齐'一个有效任务包：一个终端任务是 $T=(I,E,S,V,M)$ 的紧耦合整体——指令、初始化环境、参考解法、可执行验证器——任何两个工件的假设不一致，整个任务就会作废。论文指出两类系统性失败。第一类是源信息丢失：技能等源素材本就蕴含能力依赖、中间状态、输入输出契约与流程约束，而多级生成会把这些信息逐级压缩成一句简化的任务描述，最终任务只保留源素材的一小部分结构和复杂度。第二类是工件漂移：指令提到环境里根本不存在的文件，解法假设了不同的 schema 或依赖版本，验证器去检查一个该任务根本产生不了的状态；在阶段之间传递文本规格说明只能缓解、无法保证所有工件都落在同一个真实执行的容器状态上。现实后果是：现有终端数据集平均每任务可执行检查只有 3.29–16.60 个，且同一求解器下 P@1 普遍偏高（Endless-Terminals 83.00、Tmax 80.00、TerminalWorld 57.00），说明任务约束稀疏、偏简单。
本文的目标是本文的目标是构建一条能从海量异构 Agent 技能稳定合成'复杂且可验证'终端任务的完整流水线，并同时守住两条底线：其一是信息保真——保留源技能中的用户意图、跨技能依赖、中间状态与流程约束，而不是把它们压缩掉；其二是跨工件一致——保证指令、环境、解法、验证器四件工件相互对齐、可在同一容器中联合执行。产出的任务必须满足严格验收判据 $A(T)=B(E)\land\neg\nu_V(e_0)\land(e_T\neq\perp)\land\nu_V(e_T)$，且通过在这些任务上收集的成功轨迹做 SFT 后，要在 Terminal-Bench 2.1 上对 4B/9B/27B 多个规模的基础模型带来一致提升，以此证明'源意图保留 + 共享可执行状态对齐'是可扩展终端任务合成的关键原则，而不只是工程技巧。
与已有工作不同的是，已有合成管线从领域规格、技能分类图、可复用仓库、终端录像、社区问答或程序化任务签名构造任务，普遍把技能当作孤立的任务模板直接翻译成任务描述，或仅在文本规格层面协调各工件。本文的独特切入有两点。其一，'先重构、后出题'：不直接把技能对转换成最终任务，而是先用五个智能体模块做场景重构，恢复连贯的用户场景、跨技能依赖、中间产物与解法工作流，把信息密度在进入任务生成之前就抬起来。其二，'可执行状态作为共享锚点'：在生成最终工件之前先把环境真实构建并修复好，再把实现的容器初始状态 $e_0$ 作为只读共享接口暴露给指令、解法、验证器三个生成器，使它们看到的是同一份文件、schema、服务与依赖；验证器最后还参考参考解法执行后的终态 $e_T$。此外配套'定向修复'——验证失败时路由到责任工件、只修坏件而不重造整包——并用对照实验证明生成顺序本身（先解法后验证器）就显著影响任务有效率。
核心方法
直觉上，FACET 先造一个真实自洽的小世界，再让所有题目材料对着它来写，流水线分三阶段。Stage 1 信息源获取：从 OpenClaw、ClawHub、GitHub 收集技能包，滤除不安全、依赖私有资源与重复项并规范化为结构化记录，得 71,341 个有效技能；再抽取场景假设，经嵌入检索聚合为场景–技能对 $p_c=(c,X_c)$，由模型裁判按相关、互补、非冗余、可执行过滤得仓储 $P$。Stage 2 场景重构与参考构建：经技能分析、场景探索、关联过滤、演化恢复、信息扩展五模块得到五维表示 $D_c$（目标/情境/能力/状态/IO 与工具），融合为完整场景描述 $C$，再生成解法参考 $R_S=f_S(C)$ 与指令参考 $R_I=f_I(C,R_S)$ 并做一致性对齐。Stage 3 可执行状态驱动构造：规划环境清单→物化资产→构建并修复环境（至多 3 轮）→观察真实初始态 $e_0$→顺序生成指令与解法、执行得 $e_T$、生成验证器→Harbor 打包→四条验收加定向修复（至多 5 轮）。
核心创新是'可执行状态共享接地'：不在生成阶段之间传'描述'，而是传'世界本身'。环境被真实构建、初始化之后，其容器状态 $e_0$（文件、schema、端口、服务、依赖版本）成为所有工件生成器的共享只读上下文；如果环境修复改了文件名、路径、包版本或服务配置，下游所有生成器自动看到新状态，从机制上消除了'指令写 A 文件、验证器查 B 文件'这类漂移。与已有方法的本质区别有三：其一，任务不再是逐工件独立生成的'看起来合理'的文本，而是对着同一个已实现执行状态整体构造出来的可执行 bundle；其二，生成顺序本身是设计对象——先解法后验证器（$I\to S\to V$），验证器还能观察 $e_T$，从而对行为与最终状态做断言而非精确命令匹配，兼容多种正确解法；其三，失败修复是工件级的定向路由（构建失败归环境、解法跑挂归解法、断言缺陷归验证器、指令–状态不符归指令或环境），保留已验证有效的部分。验收判据 $A(T)=B(E)\land\neg\nu_V(e_0)\land(e_T\neq\perp)\land\nu_V(e_T)$ 把这些设计固化成可自动执行的质量门。
方法步骤详情
Stage 1 输入技能包、输出仓储 $P$：收集→过滤→结构化理解→场景抽取→检索聚合为 $p_c$→裁判 $J(p_c)$ 过滤。Stage 2 输入 $p_c$、输出规格 $Z=(C,R_S,R_I)$：技能分析提取能力、工具与可观察效果；场景探索提出共同用户目标的情境；关联过滤保留真正用上技能的场景；演化恢复组织连贯工作流并恢复跨技能依赖与中间状态；信息扩展补充资源、约束与成功条件。五维描述融合为 $C$，先写解法参考 $R_S$，再写指令参考 $R_I$，对齐模型校验两参考初态与目标一致、指令要求均有解法支撑。Stage 3 产出 Harbor 任务包：环境智能体先产出 manifest，在受限镜像内物化资产并本地化公共资源，并扩充 fixture 干扰项；构建失败则循失败轨迹修复，至多 3 轮。随后记录初始态 $e_0$，依次生成指令 $I$、解法 $S$，执行得终态 $e_T$，再据 $I,R_S,e_0,e_T$ 生成验证器 $V$；验证四条件（镜像可建、验证器拒初始态、干净容器解法可跑、终态过验证），失败由路由器定位责任工件定向修复、全流程重验，至多 5 轮。
技术新颖性
技术新颖性分三层。表示层：SkillSynth 等用场景中介图组织技能，本文把技能组合重构为带显式状态迁移与 I/O 契约的五维场景表示 $D_c$ 再降为自然语言 $C$，使后续每步共享语义参照，比直接采样技能模板更能抵抗多级生成的信息压缩。机制层：Terminal-Lego 研究环境接地的轨迹质量，本文把'接地'推进到工件协调——以真实容器状态为共享通道协调指令/解法/验证器，并用消融证明这是决定性设计：同一 100 条语义路径上，Reverse（先验证器）初始有效率仅 24.2%、其中 56.5% 的失败是跨工件契约失配；Forward 达 46.5%，配对符号检验对 Reverse 29:9（$p=0.0017$）显著占优。工程层：环境规划与资产物化分离、网络资源本地化、fixture 扰动扩充、失败类型路由修复，把 500 个共同输入上的验证产率做到 70.0%（350 个任务），约为 TerminalWorld 工作流复现（27.8%）的 2.5 倍、简化基线（15.6%）的 4.5 倍。整体上，论文把终端任务合成从'逐件生成合理组件'推进到'整体构造连贯可执行任务'。
实验结果
①数据集对比：6,078 个验证任务平均 22.77 个检查/任务，远超基线 3.29–16.60；统一求解器下 P@1/P@3 仅 27.00/35.00。②后训练：仅 1.2K 条成功轨迹 SFT，Qwen3.5-4B 17.60→24.72（+7.12）、9B 27.34→35.58（+8.24）、27B 40.82→47.57（+6.75）；27B 距 15×大的 Qwen3.5-397B 仅差 1.49。③任务分析：89.40% 检查通过但仅 20.94%（1,270/6,066）任务全对；54.00% 失败仅差 1–2 个检查；指令越长、验证面越宽越难。④生成顺序：Forward/Reverse/Joint 初始有效率 46.5%/24.2%/37.5%，产量 83/63/65；Forward 优于 Reverse（29:9，$p=0.0017$），与 Joint 不显著（$p=0.233$）。⑤管线消融（500 输入）：FACET 验证 350 任务、产率 70.0%，对比 TW 复现 27.8%、基线 15.6%，且任务最难（P@1 25.1），产率提升非靠降难度。
查看结构化数据
| 任务 | 指标 | 本文 | 基线 | 提升 |
|---|---|---|---|---|
| 终端智能体后训练（Qwen3.5-4B） | Terminal-Bench 2.1 平均通过率（Terminus-2，3 次尝试取均值） | 24.72（FACET-Terminal-Qwen3.5-4B） | 17.60（Qwen3.5-4B 基础模型） | +7.12（相对提升 40.5%） |
| 终端智能体后训练（Qwen3.5-9B） | Terminal-Bench 2.1 平均通过率 | 35.58（FACET-Terminal-Qwen3.5-9B） | 27.34（Qwen3.5-9B 基础模型） | +8.24（三个规模中绝对增益最大） |
| 终端智能体后训练（Qwen3.5-27B） | Terminal-Bench 2.1 平均通过率 | 47.57（FACET-Terminal-Qwen3.5-27B） | 40.82（同规模基础模型）；49.06（约 15 倍大的 Qwen3.5-397B） | +6.75；与 397B 模型差距缩至 1.49 分 |
| 可执行终端任务端到端合成 | 验证通过产率（500 个共同技能对输入，Harbor oracle 验证） | 70.0%（350 个验证任务） | TerminalWorld 工作流复现 27.8%（139）；无场景重构的简化基线 15.6%（78） | +42.2 / +54.4 个百分点 |
| 任务检查密度（验证严格度） | 平均每任务可执行检查数（pytest 收集的测试项） | 22.77（全部 6,078 个任务） | Terminal-Lego 16.60；Nemotron-Terminal 6.18；Endless-Terminals 5.51；TerminalWorld 3.98；Tmax 3.29 | 较最强基线高约 37%，较多数基线高 3–6 倍 |
| 工件生成顺序消融（100 条共享语义路径） | 初始有效率 / 最终产量 | Forward（$I\to S\to V$）：46.5% / 83 | Reverse（$I\to V\to S$）：24.2% / 63；Joint（一次生成）：37.5% / 65 | 初始有效率对 Reverse +22.3pt（配对符号检验 $p=0.0017$）；对 Joint $p=0.233$ 不显著 |
局限与改进
作者承认的局限：教师成功率仅 20.94%，大量 rollout 因一两个检查失败而作废，二值奖励掩盖了 89.40% 的检查级正确进展；跨数据集对比是描述性的——FACET 的低 P@1（27.00）部分来自更密的验证器，各数据集领域、构造与验证器设计不同，不构成严格受控的难度比较；生成顺序消融中 Forward 与 Joint 差异不显著（$p=0.233$），且 Forward 允许 5 轮修复而 Reverse/Joint 只允许 3 轮，最终产量比较的是完整管线配置而非同等预算下的修复效率，部分解覆盖也极不均衡（Joint 95/96 vs Forward 7/99），负判别指标只能描述性报告。我的观察：技能源限于 OpenClaw/ClawHub/GitHub 的 agent-skills 生态，类别有偏（多媒体创作 24.42%）；环境必须完全本地化、评测期离线，与真实联网运维场景有差距；合成成本高，仅工件生成约 4.14 分钟/任务（不含验证修复），全流程依赖 DeepSeek-V4-Pro 级教师；评测统一用 Terminus-2 脚手架，跨脚手架泛化未验证。
独立分析的弱点
弱点一：奖励粒度太粗。89.40% 检查通过却只有 20.94% 任务通过，54% 失败只差 1–2 个检查，而 SFT 只能用 1.2K 条全对轨迹，'接近成功'信号被丢弃。改进：把 pytest 级检查结果转成部分/过程奖励做 RLVR/GRPO 训练，或收集'只差一步'轨迹训练自我修复。弱点二：教师依赖。任务合成与 rollout 都靠 1.6T 的 DeepSeek-V4-Pro，数据上限被教师能力封顶（成功率 20.94%），小教师难以自举。改进：按检查密度课程化出题，对失败轨迹做差异提示后重采样回收。弱点三：验证器判别力缺乏系统性度量——Joint 方案暴露 9 例弱验证器（不完整解也通过），三种方案负判别覆盖悬殊（95/96 vs 7/99、9/91），'验证器是否误放行'未纳入验收。改进：把对抗性部分解测试纳入强制验收流程。弱点四：生态与分布偏移。技能源与类别分布（多媒体 24.42%）未必代表真实生产运维任务；任务全部要求离线可评，联网排障缺失；评测全在 Terminus-2 下进行，换脚手架泛化未验证。改进：引入真实终端录像与生产事故库补充源，并跨脚手架评测。
未来方向
作者明确提出两个方向：把框架扩展到更广泛的程序性知识源和更多样的交互环境；研究生成的任务与执行反馈如何支撑强化学习与智能体的持续改进。基于论文成果还可自然延伸：① 检查级奖励的 RL——89.40%/20.94% 的巨大差距说明奖励塑形空间最大，可用本文验证器直接输出稠密奖励；② 难度可控合成——利用五维场景表示与检查密度做课程学习，把任务 P@1 校准到目标区间（论文已观察到指令长度、验证广度与难度的相关）；③ 自我改进闭环——用当前策略模型替代教师做 rollout，失败任务经定向修复或提示升级后回收，逐步降低对 DeepSeek-V4-Pro 的依赖；④ 把'共享可执行状态接地'范式推广到浏览器、GUI、notebook 等其他智能体环境，构造统一的验收判据 $A(T)$；⑤ 数据配比研究——FACET 合成任务与真实录像、人工任务的最优混合比例；⑥ 4B 模型 40.5% 的相对增益提示小模型蒸馏终端能力性价比很高，可进一步探索端侧小模型的终端智能体。此外，27B 距 397B 仅 1.49 分的结果值得在更多基准上复核'数据质量替代模型规模'的结论边界。
复现评估
复现条件较好但门槛不低。开源：论文首页标注提供 Code、Model & Datasets 与项目页，三个微调模型、6,078 个任务与 1,200 条轨迹预期随论文发布；任务遵循开放的 Harbor 格式，验收协议（Table 8 的 Docker round-trip：基线验证须 reward 0、oracle 验证须 reward 1）完全可自动化。数据：源技能来自公开的 OpenClaw/ClawHub/GitHub，但 71,341 个技能的清洗、场景配对与裁判过滤依赖强模型，重跑成本高；附录 A.4 给出完整漏斗（7,852 种子→6,078 任务）可估算配额。训练：8×H200、LLaMA-Factory 全参数 SFT、3 epochs、lr $1\times10^{-5}$、序列长 32,768，微调 27B 是主要开销。综合难度中高：完整复现合成管线需要 DeepSeek-V4-Pro 级教师 API、Docker 基础设施与多轮修复预算；若只复用发布数据做 SFT 与评测（每任务 3 次尝试、每次 2 小时超时），门槛低得多，是最省路径。
论文图表
(a) 71,341 个保留技能在 5 个顶级族、34 个细分类目上的分布：多媒体创作与出版 24.42%、AI/智能体与工具 21.28%、软件/系统与安全 21.11%、数据分析与研究 17.39%、文档/效率与工作流 15.79%。(b) 6,078 个验证任务在 9 个任务族上的分布，各占比 9.59%–11.99%，接近均匀。
展示数据源生态的广度与最终任务分布的均衡性：技能端高度多样且偏创作/工具类，而输出端被刻意均衡到 9 个任务族，说明场景重构与配额设计在控制数据偏差。
基于 1,270 条成功教师轨迹（15,075 个助手轮、39,136 次命令）的统计。左图：cat 单命令占 46.4%（18,168 次），前三名 cat/python3/ls 合计 69.5%，前十名 88.4%，观察类命令占 84.7%。右图：95.6% 的轨迹以纯观察轮开局；动作轮之后 53.1% 回到观察轮、仅 28.7% 连续动作；观察轮后 55.6% 仍是观察轮，呈典型'观察–行动–验证'循环。
揭示成功轨迹的微观行为模式：命令词表高度集中、先看后动、动后必查。这既是理解教师数据质量（长轮次、多检查背后的交互习惯）的依据，也为后续用这些轨迹训练模型为何有效提供行为学解释。