终端 Agent 的训练一直有个绕不开的瓶颈：要让模型学会操作真实系统，你需要大量"可执行"的训练任务——每个任务至少耦合四件东西：一条指令、一个初始化环境、一份参考解法、一个可执行验证器。这四样如果是从彼此不一致的假设里分别生成的，产出的任务要么根本无解，要么验证器判错。中科大、上海人工智能实验室与复旦的团队在 8 月 19 日提交到 arXiv 的 FACET 框架（arXiv:2608.18580），给出的答案朴素得近乎反直觉：先把世界建好，再写任务。
任务合成的信息流失问题
论文指出的第一个痛点是信息保真。多阶段合成管线在逐步转换的过程中，会把原始素材里编码的目标、依赖关系、状态迁移和过程性约束一点点丢掉——最后生成的任务表面上完整，实际上和源头的意图已经对不上。第二个痛点是跨组件一致性：指令、解法、验证器各自生成，谁也不知道对方假设的环境长什么样。
FACET（Fine-grained Agentic Construction of Executable Tasks）的解法分三步走：先从信息源中获取并组织出 71K 以上可复用的 agent 技能，构建"场景—技能"库；再重建场景，恢复目标、依赖、中间状态、工具和输入输出契约；最后才是关键的一步——先把执行环境真正跑起来并修复，让容器状态成为指令、解法、验证器三者共享的接地（grounding）。哪个组件验证失败就定点修复哪个，不推倒重来。项目页把这套哲学压缩成一句话：Build the world first, then write the task。
1.2K 条轨迹撬动的提升
结果数字相当扎实。在 Terminal-Bench 2.1 上，仅用 FACET 任务收集到的 1.2K 条成功轨迹做微调：Qwen3.5-4B 从 17.60 提到 24.72（+7.12），Qwen3.5-9B 从 27.34 提到 35.58（+8.24），Qwen3.5-27B 从 40.82 提到 47.57（+6.75）。最有意思的参照是：27B 微调后的 47.57，距离 397B-A17B 基座在同一评测设定下的 49.06 只差 1.49 分——模型尺寸约是后者的十五分之一。需要说明，这些是论文自测数据，尚无第三方复现。
更值得看的是消融。任务生成的顺序本身决定了任务有效率：环境→指令→解法→验证器的正向顺序，最终验证通过率达到 83%；联合生成只有 65%，反向生成 63%。首轮通过率差距更悬殊（46.5% 对 37.5% 和 24.2%）。这组对照直接回答了"到底是数据多还是顺序对"的问题——在同样的模型和算力下，把环境放在生成链的最前面，本身就是任务有效性的来源。构造漏斗也印证了定向修复的价值：7,852 个场景种子，7,504 个环境构建成功（95.7%），首轮通过验证的任务只有 2,856 个（38.35%），经组件级修复后最终达到 6,078 个（81.63%）——修复环节让产出翻了一倍还多。
数据效率视角
把 FACET 放进同脚手架（Terminus-2）的数据集对比里看，轨迹效率的优势很直观：其他终端 Agent 数据集普遍需要 5K 到 32K 条轨迹（Nemotron-Terminal 5K、Terminal-Lego 32K），FACET 用 1.2K 条就支撑起 6,078 个任务、平均每任务 22.77 个可执行测试的密度。论文附录还给出轨迹行为统计：95.6% 的轨迹首回合是纯观察、84.7% 的回合包含观察命令——这种"先看再做"的行为模式正是从环境接地里自然长出来的。
所以呢
FACET 开源了 6,020 个公开发布的任务（FACET-Terminal-Tasks-6k）和 4B、9B、27B 三个微调 checkpoint，登上 Hugging Face Daily Papers 榜单（111 票）。对做 Agent 训练的团队，这篇工作的可迁移结论不是某个具体数字，而是一条工程原则：合成数据的下一步不是造得更多，而是造得更可执行——环境先落地，任务才站得住。当所有人都在卷模型和算力时，把"任务本身是否真实可解"当作一等公民来工程化，可能才是数据侧最被低估的杠杆。