论文链接：arxiv.org/abs/2608.18580 发表时间：2026 年 8 月（Hugging Face Daily Papers 2026-08-21 批次，108 票排名第二） 机构：中国科学技术大学（MoE Key Lab of BIPC）+ 上海人工智能实验室 + 复旦大学（三机构合作） 代码：论文含 GitHub 图标链接（正文未显式列出 URL，可关注论文页面更新）
一、论文背景
1.1 什么是终端 Agent？
如果你用过 Claude Code、Codex CLI、Cursor 这类编程助手，你对"终端 agent（terminal agent）“就已经不陌生了：它是一个能直接操作计算机终端的大模型智能体——你给它一个目标（“把这个仓库的测试跑通”、“分析这份日志找出报错原因”、“把这批图片统一转成 webp 并压缩到 200KB 以下”），它自己拆解任务、敲命令、看输出、修错误，循环往复直到完成。
这和"聊天式"大模型有本质区别。聊天模型输出的是文本，错了顶多答非所问；终端 agent 输出的是改变真实系统状态的命令——文件被写入、依赖被安装、进程被启动。它的行为直接作用于一个有因果关系的世界：上一步 cd 到了哪个目录，决定了下一步相对路径指向哪里；上一步安装的库版本，决定了代码能否 import 成功。终端是比"代码补全"严酷得多的战场，因为环境会记得你做过的一切。
也正因为如此，终端 agent 的评估和训练都异常困难。传统代码评测（HumanEval、MBPP 之类）只要求模型写一个函数、跑几个单元测试；而终端任务要求模型在几十轮交互中维持对环境的准确理解，处理路径、权限、版本冲突、隐藏文件、后台进程等无穷的现实细节。能力天花板不在"会不会写代码”，而在"能不能在真实系统的泥潭里把一件多步骤的事情做完"。
1.2 Terminal-Bench 与 Harbor：这个领域的"基础设施"
2025 年以来，这个领域逐渐长出了自己的评测生态。Terminal-Bench 是目前最有影响力的终端 agent 能力基准，其 2.1 版本包含一系列真实世界终端任务；与之配套的 Harbor 框架定义了任务的打包格式——一个任务不再是一段 prompt，而是一个完整的"包裹"：初始环境（通常是 Docker 容器）、自然语言指令、参考解法、以及可执行验证器（一组测试脚本，agent 声称完成后由验证器判定是否真的达标）。
Terminal-Bench 2.0/2.1 全部加起来只有约 89 个任务。这个数字道出了一个尴尬现实：人工构造终端任务极其昂贵。你得设计一个有意义的目标、手工搭建出"半成品"环境（比如一个有 bug 的项目、一份残缺的配置）、写出参考解法、再写一套能无歧义判定成败的验证脚本——每个环节都要人工反复调试。89 个任务对评估尚且紧张，对训练（需要成千上万个任务）更是杯水车薪。
1.3 为什么需要任务合成？现有管线的两大失败模式
于是业界自然转向任务合成（task synthesis）：让 LLM 自动生成训练任务，用"可执行验证器是否通过"作为免费且可扩展的监督信号。这构成了一个看似完美的飞轮——生成任务 → 过滤 → 用通过的任务训练 agent → agent 更强 → 生成更好的任务。
但飞轮转起来就会发现，多阶段合成管线系统性地表现出两种失败模式，这也是 FACET 全文的出发点：
失败模式一：源信息丢失。 合成管线通常是多阶段的：先从源材料（技能文档、代码仓库、教程）提取想法，再逐步加工成任务四件套。每一步"压缩"都在丢东西——源材料里体现的能力要求（这个工具到底能干什么）、依赖关系（这个技能依赖哪些前置步骤）、中间状态（执行到一半时系统应该是什么样）、IO 契约（输入输出文件的格式约定）、过程约束（必须用某种方法做、不许碰某些文件）……经过三四道工序，最终任务只剩一个干瘪的目标描述，与源材料承载的真实意图早已貌合神离。
失败模式二：任务制品漂移。 一个合法的终端任务是紧耦合的四件套：指令 I（告诉 agent 做什么）、初始环境 E（agent 启动时面对的世界）、参考解法 S（示范如何完成）、可执行验证器 V（判定是否完成，附运行时元数据 M）。这四者必须彼此一致。但独立生成它们时，漂移几乎不可避免：指令让 agent 处理 data/records.csv，环境里根本没有这个文件（I 与 E 漂移）；解法假设输出是 JSON，验证器却检查 CSV（S 与 V 漂移）；验证器要求某个状态可达成，但从初始环境出发根本无路可达（V 与 E 漂移）。四件套中任何一件与其他不一致，这个任务就是无效的——用它训练 agent，等于用错误的标准答案教学生。
FACET 这个名字——Flexible Assisted Construction with Executable-state grounding for Terminal tasks（面向终端任务的柔性辅助构建与可执行状态接地）——点明了它要同时解决这两个问题：**保持源意图（Preserving Source Intent）**对应失败模式一，**可执行状态接地（Executable State）**对应失败模式二。标题里的两个关键词，正是两大失败模式的解药。
二、定位与关联工作
在 FACET 之前，终端任务合成已经是一条拥挤的赛道。把主要玩家放在一起看，能更清楚 FACET 站在哪里：
| 系统 | 核心思路 | 与 FACET 的差异 |
|---|---|---|
| Nemotron-Terminal | 数据工程管线，工业级规模产出终端训练数据 | 关注规模与数据流水线，未显式处理源意图保持与制品间一致性 |
| Tmax | 极简配方（simple recipe），用最少的工序生成任务 | 简单意味着信息压缩更剧烈，容易同时踩中两大失败模式 |
| Endless-Terminals | RL 环境扩展，为强化学习提供源源不断的任务 | 重在环境数量与多样性，验证器质量参差 |
| TerminalWorld | 从真实终端录制出发构建任务 | 天然保真，但受限于录制素材，难以自由组合扩展 |
| Terminal-Lego | 环境接地，强调轨迹质量（16.60 项检查/任务） | 关注点在轨迹质量，接地深度不及 FACET 的 22.77 |
| SkillSynth | 技能图，从 agent 技能出发组织任务 | 与 FACET Stage 1 的技能库思路相近，但缺少后续的状态接地机制 |
| Agent Skills 规范（agentskills.io） | 社区技能包的标准格式 | 提供了 FACET 的原料来源，本身不解决任务合成问题 |
可以看到两个流派：一派（Nemotron-Terminal、Tmax、Endless-Terminals）主打规模与吞吐，用工业管线把任务数量堆上去；另一派（Terminal-Lego、SkillSynth、TerminalWorld）主打质量与接地，强调任务要贴着真实环境。FACET 的独特站位是：同时抓住了"信息完整性"与"制品一致性"两条质量主线，并且给出可操作的机制（情景重构 + 共享可执行状态）来保证它们——然后用实验证明，把质量做扎实之后，规模不需要很大（6078 个任务、1.2K 条 SFT 轨迹）就足以撬动显著的性能提升。
三、问题定义：什么样的任务才算"合法"？
FACET 对问题的形式化非常干净，值得细读。
3.1 任务与接受准则
一个终端任务定义为四元组 T = (I, E, S, V)（附带运行时元数据 M）：指令、初始环境、参考解法、可执行验证器。任务合法当且仅当接受准则 A(T) 成立：
A(T) = B(E) ∧ ¬νV(e0) ∧ (eT ≠ ⊥) ∧ νV(eT)
四个条件是合取关系，缺一不可：
- B(E)：初始环境 E 能成功构建（Docker 能起来、初始化脚本不报错）——环境本身得是可用的；
- ¬νV(e0)：验证器 V 在初始状态 e0 上不通过——如果任务还没开始验证器就绿了，说明任务没有实际要求，agent 躺赢，训练信号为零；
- eT ≠ ⊥：参考解法 S 能无错执行完毕（执行到终止状态，而非中途崩溃）——得存在一条真的能走通的路；
- νV(eT)：验证器在终止状态 eT 上通过——解法走到的终点确实满足任务要求。
这四条看起来朴素，但每一条都堵死了一种常见漏洞：环境建不起来的任务、不用做就"完成"的任务、无解的任务、解完了却不达标（或验证器本身错乱）的任务。用合取式的判定逻辑想问题，是这篇论文给所有任务合成工作上的第一课：任务的有效性是"工程制品的一致性"问题，而不是"文本看起来像不像任务"的问题。
3.2 两个本质子问题
在此之上，论文把多阶段合成的困难提炼为两个本质子问题：
子问题一：信息保持。 从源材料到任务制品是一条逐级压缩的信息链。源材料中的能力、依赖、中间状态、IO 契约、过程约束，必须在最终制品中以某种形式存活下来。这个子问题的难点在于**“丢什么"不可预知**——不同源材料的关键信息位置不同，固定模板必然丢信息，需要的是能跟随源材料结构动态理解的机制。
子问题二：跨制品一致。 I、E、S、V 四件套是分头生成的文本制品，但它们必须共同指向同一个数学对象——“从 e0 出发经 S 到达 eT 且 V 在 e0 红、eT 绿”。难点在于文本之间没有天然的同步机制：生成 I 时并不知道 E 里到底有哪些文件；写 V 时并不知道 S 实际产出什么格式。四个生成器各写各的，一致性只能靠运气——除非让它们共享某种"事实锚点”。
第二部分的方法设计，全部围绕这两个子问题展开。
四、问题解法：三阶段框架
FACET 的完整管线分三个阶段：信息源获取 → 情景重构与参考构建 → 可执行状态接地构建。前两个阶段对付"信息保持"，第三个阶段对付"跨制品一致"。
4.1 Stage 1：信息源获取——71K 技能库
合成要有源头。FACET 从 OpenClaw / ClawHub / GitHub 三处收集 agent 技能包，经过四道过滤（不安全内容、私有依赖、不可读内容、重复项），再做结构化理解，最终沉淀出超过 71K 个有效技能。
但原始技能只是"散装知识"，下一步是将其组织成可用于生成的情景-技能库：对技能做情景假设提取与嵌入检索，再由模型 judge 逐对评估情景与技能的相关性、互补性、非冗余性、可执行性——只有四项都达标的配对才入库。整个库按五顶层类别、34 个细分类别组织，覆盖了终端操作的广大空间。
这一步的质量门槛（特别是"可执行性"这一关）决定了后面所有阶段的下限：库里不可执行的东西，后面不可能凭空变可执行。
4.2 Stage 2：情景重构与参考构建——把丢掉的信息找回来
针对子问题一（信息保持），FACET 设计了五模块的代理式重构流程，像五个分工明确的"研究员"接力处理每个技能：
- 技能分析：这个技能到底提供什么能力、依赖什么；
- 情景探索：这个技能可能出现在什么样的真实工作情景中；
- 关联过滤：哪些关联信息是任务真正需要的，剔除噪声；
- 演化恢复：这是最关键的一环——恢复跨技能依赖、中间产物、状态转移。源材料里"做完 A 才能做 B"“B 的输出是 C 的输入"这类时序与数据依赖，正是最容易被多阶段压缩丢掉、又对终端任务最致命的信息；
- 信息扩展：补充必要的背景，让情景完整自洽。
重构后的情景用五维表示 Dc 描述：
- d_goal（目标）：任务要达成什么；
- d_context（上下文）：发生在什么背景里；
- d_capability（能力）：需要哪些技能与能力；
- d_state（状态）：初始/中间/终止状态各是什么样；
- d_io-tool（IO 与工具）：输入输出契约、涉及的工具与格式。
五维整合为完整情景 C 之后，生成参考制品的顺序也有讲究：先生成解法参考 RS = fS(C)，再生成指令参考 RI = fI(C, RS)。为什么解法在前？因为解法直接"贴着"环境与能力走，而指令是对解法的"人话化"概括——先有可行的路径，再描述这条路要通向哪里，比反过来更不容易写出"环境里根本没有的文件"。生成后再由一致性对齐模型做交叉检查，确保 RI 与 RS 不互相矛盾。
这一阶段相当于把 Stage 1 技能库里的"散装知识"，重构成信息完备且内部自洽的任务蓝本——但请注意，此时的 RI 与 RS 仍然只是文本，还没有任何真实环境为它们背书。这正是 Stage 3 要解决的。
4.3 Stage 3：可执行状态接地——Algorithm 1 的核心设计
这是全文最核心、也最有启发性的部分。所谓接地，就是让任务的每个制品都对齐到一个真实存在、可执行验证的计算状态上，而不是停留在生成器的想象里。
Algorithm 1 的流程可以概括为三步：
第一步：环境清单规划。 从情景 C 出发，规划初始环境 E 应该包含哪些资产——哪些文件、什么目录结构、装哪些依赖、预置什么半成品状态。
第二步：资产物化。 把清单变成真实文件：通过网络检索获取真实数据、用程序生成构造内容、用扰动增强（fixtures）制造"半成品感"——比如故意留下几行没写的代码、几条脏数据，让任务有真实的"待修补感"而非玩具感。
第三步：构建-初始化循环修复（≤3 轮）。 尝试构建环境并初始化到 e0；失败则依据失败轨迹定位问题、修复环境定义。修复以"失败轨迹 + Z 规范"为约束——Z 规范的作用是防止修复演变成删任务需求：修环境的目的是让环境能用，而不是把任务要求悄悄改掉（否则任务会退化成"环境里什么都有、验证器直接通过"的空壳）。
到这里环境有了。接下来的设计才是论文的点睛之笔——可执行状态共享（executable state sharing）：
把已经构建好的容器状态 e0 暴露给后续所有生成器，并按固定顺序生成：指令 I ← (RI, e0)，解法 S ← (I, e0)，执行 S 得到 eT，验证器 V ← (RI, RS, e0, eT)。
也就是说，四个制品不再分头独立生成，而是排成一条Forward 链，每个生成器都读同一个真实容器：写指令时能看到 e0 里真实存在的文件与目录（再也不会引用不存在的路径）；写解法时指令已经定了、环境也是真的（照着真实环境写可行路径）；验证器生成时手上不仅有指令、解法，还有解法真实执行出来的终点状态 eT（照着真实结果写断言，而不是猜格式）。
一个直观的类比：这就像先建好厨房，再写菜谱。传统做法是先凭想象写菜谱（指令）、再想象着写做法（解法）、最后想象着写验收标准（验证器），等到真的开火（构建环境）才发现菜谱里的食材厨房根本没有。FACET 反过来：先把厨房建好、食材摆好（物化环境到 e0），厨师照着真实食材写菜谱，然后真的把菜做一遍（执行 S 得到 eT），最后对照着做出来的成品照片写验收标准（生成 V）。菜谱、做法、验收标准全部锚定在同一个真实厨房的真实状态上，想不一致都难。
最后是验证与定向修复。环境就绪后跑完整接受准则四条件；若失败，按执行轨迹定位责任制品，只修复该制品（≤5 轮），而不是把四个制品推倒重生成。定位的依据依然是"事实"：哪个环节的失败轨迹指向哪个制品，就修哪个——指令引用了不存在的东西就修指令，解法跑不通就修解法，验证器断言与真实状态不符就修验证器。这种"外科手术式"的修复把修复动作的副作用限制在单制品内，避免了"修 A 坏 B"的连锁震荡。
五、评估与实验证据
论文的实验回答了三个问题：合成的数据集本身质量如何？用它训练 agent 有多大幅度？核心设计（共享接地）真的是性能来源吗？
5.1 数据集对比：检查密度是第一梯队
表 1 将 FACET 数据集（6078 个任务）与五个同类数据集对比，最突出的指标是每任务可执行检查数 22.77——所有对比数据集中最高（Terminal-Lego 16.60、Nemotron-Terminal 6.18、Endless-Terminals 5.51、TerminalWorld 3.98、Tmax 3.29）。验证器包含的检查项越多，判定越精细、越难被"钻空子"，任务的监督信号越强。同时任务平均轨迹长度 11.86 轮，与 TerminalWorld 的 11.94 基本持平，属于需要真实多轮交互的长任务。
有意思的是 P@1 仅 27.00、P@3 也只有 35.00（即由强 agent 尝试一次/三次的通过率）——这个数字不高于同类数据集。论文没有回避，而是给出了诚实解读：单次通过率低恰恰是检查点密集的必然代价——22.77 项检查构成一长串合取条件，每一项都是独立的失败机会，合取成功率自然被压低。这与后面任务分析中"89.40% 单项检查通过率 vs 20.94% 完整任务成功率"的落差相互印证：任务的难度不在于单点，而在于组合要求的精确、完整满足。
5.2 SFT 主结果：三个尺度一致提升
用 Terminus-2 agent（DeepSeek-V4-Pro 驱动）在约 6K 任务上 rollout，筛得 1.2K 条完整成功轨迹做 SFT（LLaMA-Factory 训练）。Terminal-Bench 2.1 结果（表 2）：
| 模型 | SFT 前 | SFT 后 | 提升 |
|---|---|---|---|
| Qwen3.5-4B | 17.60 | 24.72 | +7.12（相对 +40.5%） |
| Qwen3.5-9B | 27.34 | 35.58 | +8.24 |
| Qwen3.5-27B | 40.82 | 47.57 | +6.75 |
三个尺度全部显著提升，其中 4B 小模型相对涨幅最大（+40.5%），说明高质量终端数据对能力底子薄的小模型增益尤为明显。最引人注目的是：Qwen3.5-27B 训后 47.57 分，距离 Qwen3.5-397B 的 49.06 只差 1.49 分，而参数量约为其 1/15。用 1.2K 条轨迹，几乎把一个 27B 模型"喂"到了 15 倍大模型的水平——这是整篇论文最有传播力的一行数字。
5.3 生成顺序消融：共享接地的直接证据
第三组实验直接检验核心设计：固定 100 个情景，分别用三种顺序生成任务制品——
| 生成顺序 | 初始有效率 | 修复后产出 |
|---|---|---|
| Forward（I→S→V，共享 e0/eT） | 46.5%（46/99） | 83/100 |
| Joint（三者联合生成） | 37.5% | 65/100 |
| Reverse（I→V→S） | 24.2% | 63/100 |
Forward 的初始有效率接近 Reverse 的两倍。更关键的诊断数据是：Reverse 的失败中有 56.5% 源于跨制品契约错配——先写验证器再写解法，验证器凭空假设的状态/格式与后来解法的实际产出对不上，这正是"制品漂移"的典型形态，而 Forward 通过让验证器最后看着真实 eT 生成，把这类失败基本消灭。
统计检验也做了：配对符号检验下 Forward vs Reverse 为 29 胜 9 负，p = 0.0017，显著；Forward vs Joint 为 27 胜 18 负，p = 0.233，不显著——即 Forward 明确优于 Reverse，相对 Joint 有优势但未达显著（Joint 联合生成也能部分缓解漂移，只是修复后的最终产出仍落后：83 vs 65）。
5.4 任务分析：难在"组合"，不在"单点"
对失败任务的分析显示：单项检查通过率高达 89.40%，完整任务成功率却只有 20.94%；54% 的失败任务仅差 1-2 个检查项。换句话说，agent 不是"不会做"，而是"做不完整"——差一点点格式、差一个边角要求。这一发现既解释了 P@1 为什么低，也指明了终端 agent 训练的下一个攻坚点：长尾约束的精确满足。另外，涉及结构化数据的任务明显比叙事文档类任务可靠——可机器校验的格式约束比语义性的要求更容易做对。
六、根源解释：为什么"共享接地"如此有效？
看完数据，值得停下来追问一层：为什么仅仅改变"生成顺序 + 共享状态"这样朴素的机制，能带来初始有效率翻倍、契约错配近乎消灭的效应？ 论文的证据链可以整理成一条清晰的因果链。
6.1 因果链：从共享容器到契约错配消失
根因：文本制品之间没有天然的同步机制，而真实状态有。 指令、解法、验证器都是模型生成的文本，文本之间的一致性只能靠生成器的"想象力"维持；而容器状态 e0 / eT 是客观事实，事实天然是单一的——所有读它的生成器自动对齐。
于是因果链是：暴露共享的真实容器状态 → 环境侧的任何修复、变化即时同步到所有下游生成器 → 跨制品契约错配从源头消失（Reverse 中占 56.5% 的失败类别在 Forward 下基本不出现） → 初始有效率从 24.2% 翻倍至 46.5% → 修复成本同步下降（修复只需处理单制品问题） → 最终产出 83/100，领先 Joint 与 Reverse 约 20 个百分点。
注意一个常被忽视的细节：“共享"与"顺序"缺一不可。 Reverse（I→V→S）同样是顺序生成，为什么这么差？因为它是"先写验收标准、再做菜”——验证器生成时既没有真实环境可看，也没有解法结果可参照，只能凭空假设 eT 的样子；等解法真的执行出来，假设与现实的裂缝已无法弥合。Forward 则让每个生成器都站在前序制品的真实产物之上：指令看 e0、解法看 I 与 e0、验证器看 eT。顺序的本质是让"事实"先于"假设"生成。
6.2 数据效率的来源：密度 × 质量，而非数量
另一个值得解释的数字是：为什么区区 1.2K 条 SFT 轨迹就能带来三尺度一致提升？
对比一下常见的认知：SFT 数据动辄几万、几十万条。FACET 的反例说明，对终端 agent 这种"每个样本都承载完整多轮交互"的场景，数据效率来自检查密度与轨迹质量，而非数量：
- 密度：每任务 22.77 项可执行检查意味着每条通过验证的成功轨迹，都是在 22.77 个独立约束下被证实为"完整正确"的样本——监督信号的有效浓度极高；
- 质量：所有轨迹都是 Terminus-2 真实 rollout 出来、并通过接受准则四条件完整验证的成功轨迹，没有一条是"近似对"或"部分对"的样本。SFT 阶段模仿的每一步，背后都有可执行证据兜底。
一句话总结这部分：FACET 用"接地"换"密度"，用"验证"换"纯度"，最终用密度和纯度换来了数量不重要。
七、知识反推：从这篇论文能学到的领域知识
把论文的机制性结论反推成领域层面的认识，我认为有四条值得记录：
第一，终端任务合成的瓶颈已从"生成"转移到"一致性"。 LLM 生成一个"看起来像任务"的文本毫无难度，瓶颈全在四件套的一致性上。这暗示未来合成框架的竞争点不是谁的 prompt 更花哨，而是谁的事实锚定与修复机制更工程化。
第二，“接受准则"是任务合成管线的质检门，其严格程度决定数据集上限。 A(T) 的四条件合取（环境可构建、初始不通过、解法可执行、终止通过）应当成为终端任务合成的行业常识——任何一个条件被放松，产出的就是负样本。
第三，验证器密度是终端任务"含金量"的可量化指标。 每任务可执行检查数这个指标第一次让"任务难度/监督强度"变得可比较（22.77 vs 16.60 vs 3.29 的对比一目了然）。但它有代价——合取逻辑会压低表面通过率，评估数据集时不能只看 P@1 高低就下结论。
第四，终端 agent 当前的主要失败模式是"完整性"而非"能力”。 89.40% 的单项通过率与 54% 的 near-success 表明，模型知道怎么做，但会在 1-2 个边角约束上失手。这对后续训练（强化"检查清单式"的自我核查行为）与产品设计（完成前的自动自检环节）都有直接指引。
八、通用性灵感：跳出终端任务的启示
FACET 的两个核心机制——情景重构保信息、共享状态接地——其适用范围远不止终端任务合成。以下几条是我认为最值得迁移的通用原则：
1. 共享接地协调多制品生成。 任何需要生成多个相互约束的制品的场景（前后端代码 + API 契约 + 测试 + 文档；数据库 schema + 迁移脚本 + 数据校验规则；需求文档 + 设计稿 + 验收标准），都可以套用"先物化一个客观锚点，再让所有生成器读同一个锚点"的模式。让制品对齐"事实"比对齐"彼此的描述"便宜得多——因为事实不需要双向同步。
2. 先环境后任务（环境先行）。 顺序设计的本质是把最不可塑的约束放在最前面。环境是最难改的（构建成本高、修复代价大），指令是最好改的（一段文本）。Forward 顺序让易变制品去适配难变制品，天然减少返工。这个原则适用于一切"多约束系统"的构造顺序决策。
3. 定向修复优于整体重生成。 失效时按执行轨迹定位责任制品、只修该制品（≤5 轮），而不是推倒重来。这在自动化合成管线中尤其重要：整体重生成会引入新的随机性，可能修好了 A 又坏了 B，陷入循环；定向修复把每一步的变更半径限制住，修复过程可收敛。同时要配一道"防护栏"（如 Z 规范）防止修复退化为降低要求。
4. 接受准则的"四条件"设计范式。 B(E) ∧ ¬νV(e0) ∧ (eT≠⊥) ∧ νV(eT) 的结构可以推广为通用验收设计：产物可用 × 初始未满足 × 存在可行路径 × 终态确实满足。无论是设计自动评估、构建合成数据管线、还是写一个复杂功能的验收标准，检查这四个条件能挡住绝大多数"看似完成实则无效"的情况。
5. 数据效率 = 密度 × 质量，而非数量。 1.2K 轨迹 + 22.77 检查密度的组合胜过海量低密度数据。这对所有做合成数据/SFT 的团队都是一剂清醒剂：与其堆量，不如给每个样本加权可执行的验证密度——一条被 22 项检查证实完全正确的轨迹，价值远超二十条"大概对"的轨迹。
6. 诚实呈现负向指标是可信度的来源。 论文没有藏起 P@1 偏低的事实，而是给出机制解释（合取成功率与检查密度的数学关系）。这种"负指标 + 机制解释"的呈现方式，比只报喜的做法可信度高得多，值得所有论文写作与结果汇报借鉴。
九、总结
FACET 用一个干净的诊断-处方结构回应了终端任务合成的核心痛点：两大失败根源（源信息丢失、制品漂移）分别对应两大机制（五维情景重构、共享可执行状态接地），前者保住"任务值得做"，后者保住"任务做得成"。
三个数字勾勒出它的全部说服力：6078 个任务、每任务 22.77 项可执行检查的数据底座；生成顺序消融中 46.5% vs 24.2% 的初始有效率差距与 p=0.0017 的显著性提供的机制证据；以及仅用 1.2K 条 SFT 轨迹让 Qwen3.5-27B 距 397B 模型仅 1.49 分的训练收益。
如果只带走一句话，我会选论文结论里的这条原则：源意图保持 + 可执行状态共享接地，是可扩展终端任务合成的关键——而它背后的更一般性洞见是：当多个生成器需要彼此一致时，别让它们对话，给它们一个共同的、真实的世界。