摘要
FACET 面向 terminal Agent 的可执行监督构建，核心不是直接生成一条 instruction，而是先从相关 skills 重建场景与工作流，再在真实实现的 container state 上协调 instruction、reference solution 和 verifier，最后通过干净容器中的执行验证与定向修复筛选任务。（来源：原始论文记录（本地存档），§2.2-2.4，pp.3-6）
核心内容
方法与验证边界
- FACET 的三阶段 pipeline 将 source-intent preservation、scenario reconstruction 与 executable-state grounding 结合起来；环境、solution 和 verifier 共享已实现状态，减少跨 artifact 漂移。（来源：原始论文记录（本地存档），§2.3-2.4，pp.3-6）
- 验证器不是只检查文本答案：任务必须能构建环境、在初始状态不通过 verifier、执行 reference solution，并在目标状态通过 verifier；失败由执行 trace 路由到具体 artifact，任务级修复最多五轮。（来源：原始论文记录（本地存档），Algorithm 1 / Appendix C.2，pp.4-6, 20）
- 构建漏斗从 7,852 个 seeds 得到 6,078 个 validated tasks；环境修复最多三轮，任务修复最多五轮。（来源：原始论文记录（本地存档），Appendix A.4 / C.2，pp.16, 20）
监督与结果
- 论文用 Terminus-2 / DeepSeek-V4-Pro 在约 6K 任务上生成 rollout，筛选 1.2K 条完整成功轨迹，对 Qwen3.5-4B、9B、27B 做 SFT；这不是基于环境回报更新 policy 的严格 Agentic RL。（来源：原始论文记录（本地存档），§3.1、Appendix D，pp.6, 20-21）
- Terminal-Bench 2.1 得分分别从 17.60/27.34/40.82 提升到 24.72/35.58/47.57；对应绝对增益为 +7.12/+8.24/+6.75。（来源：原始论文记录（本地存档），Table 2，p.8）
- FACET 任务平均 11.86 turns、22.77 executable tests，P@1/P@3 为 27.00/35.00；更密集的检查点提高了任务验证强度，也使端到端 pass rate 较低。（来源：原始论文记录（本地存档），Table 1 / §3.2，pp.6-8）
与 Harness Engineering 的关系
- FACET 证明了可执行环境状态和 artifact-level verifier 可以成为 harness/task construction 的共享事实层；它还提供了从失败 trace 到具体 artifact 的有限修复路由。（来源：原始论文记录（本地存档），§2.4，pp.5-6）
- 它不应被写成持久 harness 自进化或 RSI：修复发生在单个任务构建流程内，模型更新是 SFT，论文把 RL 与 continued improvement 留作未来工作。（来源：原始论文记录（本地存档），§5，p.10）
相关页面
- 概念：Harness Engineering、Agent Failure Localization、Agentic RL、Self-Improving Harness
- 实体：无新建实体。
- 主题：AI Agent Failure Analysis、LLM Agent Self-Improvement
来源
- 原始文件：原始资料（本地存档）
- alphaXiv：https://www.alphaxiv.org/abs/2608.18580
- arXiv：https://arxiv.org/abs/2608.18580
- 项目页：https://stokou.github.io/FACET-Terminal/
- 代码：https://github.com/StoKou/FACET-Terminal
- 数据：https://huggingface.co/datasets/FACET-Terminal/FACET-Terminal-Tasks-6k
- 模型集合：https://huggingface.co/FACET-Terminal
- 定位信息：§2-3、§5、Appendix A.4/A.6/C.2/D，pp.3-10, 15-17, 20-21。