FACET：在终端任务合成中保留源意图与可执行状态

TL;DR FACET 通过细粒度代理构建可执行终端任务，以共享的修复后容器状态统一指令、参考解和验证器，并保留源技能意图，从而在 Terminal-Bench 2.1 上实现高效、可扩展的智能体训练。

问题

问题背景

终端 agent 的训练依赖可执行监督（executable supervision），每条任务需同时提供指令、初始环境、参考解和验证器。合成大规模高质量终端任务已成为该领域的关键瓶颈。

现有方法局限

当前合成方案存在两类显著缺陷：

• 跨工件不一致：指令、环境、参考解和验证器往往基于不同假设生成，导致任务不可解或验证结果错误。
• 源信息丢失：多阶段合成过程中，原始技能源所包含的目标、依赖关系、状态转移和过程约束容易被丢弃，生成的任务简化或偏离原始意图。

这些缺陷直接影响合成数据的有效性与可训练性。

为什么难且重要

难点在于信息保真与跨工件一致性需要同时满足：既要保留源技能中的细粒度执行意图，又要保证所有任务工件共享同一份可执行环境状态。多数现有工作只侧重生成规模，忽略了这两点。终端 agent 在自动化运维、软件工程等场景有广泛应用，可靠的任务合成是数据驱动训练的基础。

行业类比

类似用仿真数据训练机器人操作策略：若仿真器中物体初始位置、参考轨迹和奖励检查器不基于同一物理快照，策略将学到错误信号。

核心洞察

• FACET 的核心洞见在于将终端任务的所有工件（指令、参考解、验证器）锚定在同一个经过修复的容器状态上。与以往分别生成工件再尝试对齐的做法不同，这种共享可执行状态接地从源头消除了因环境假设不一致导致的不可解或错误评估，显著提升任务有效性。
• FACET 通过细粒度智能体重构保留源任务的目标、依赖、状态转换与程序约束，避免多阶段合成中的信息丢失。配合执行验证和定向修复，它只针对失效工件进行修正而不重新生成有效组件，与现有一次性生成再全量重试的流程相比，实现了更高一致性的可扩展任务合成。

方法

输入与信息源构建

FACET 的输入是原始终端任务相关的源技能（source skills），包括指令、脚本、文档等。首先执行信息源获取：对候选源进行收集与过滤，理解每个技能的目标、依赖、状态转换和过程约束，提取可复用的场景（scenario），并构建场景-技能仓库。

场景重建与参考方案

基于仓库中的场景，FACET 进行Agentic 场景重建：通过 agent 将相关技能组合为连贯、信息丰富的任务场景，同时生成场景表示（如依赖图、初始文件系统状态等）和参考解决方案。

可执行状态接地与任务生成

核心是可执行状态接地：FACET 先构造并修复执行环境（如 Docker 容器），使容器状态实际可运行；然后将该状态作为所有任务构件的共享基础。指令、参考解、验证器都从同一容器状态派生，保证 cross-artifact consistency。随后进行执行验证与针对性修复：运行参考解，对照验证器检查，若某构件失败，仅修复该构件而非重新生成全部，降低浪费。

输出

最终输出包含 instruction、initialized environment、reference solution、executable verifier 四元组的复杂终端任务，验证器包含密集可执行检查。这些任务的成功轨迹可作为数据高效的监督信号，用于微调终端 agent。

差异点：相比现有合成管线，FACET 通过共享可执行状态和源意图保留，避免了多阶段合成中的信息丢失与构件不一致问题。

实验

实验设计

FACET 在 Terminal-Bench 2.1 上评估任务质量与训练效用。实验包含三部分：

1. 数据集对比：将 FACET 生成的任务与现有终端数据集在轨迹级和任务级进行对比，衡量可执行性、验证器覆盖度和解决方案对齐。
2. 微调评估：在不同规模模型上微调，验证 FACET 任务的成功轨迹是否提供数据高效监督。
3. 生成方案消融：比较不同合成策略（如无环境接地、多阶段独立生成），分析任务有效性差异。

关键发现

• 从 FACET 任务收集的成功轨迹能一致提升 多尺度模型在 Terminal-Bench 2.1 上的表现，证明其监督质量。
• 任务具有密集可执行检查 和高可解性；但端到端成功率仍然较低，部分进展（如完成部分步骤）普遍，难度主要源于组合性要求。
• 环境修复和共享状态是任务有效的关键：不依赖环境接地的方案会生成不可解或验证不一致的任务。

与基线的深度解读

传统多阶段合成常因各组件独立生成而引入不一致假设，导致任务不可解或错误评估。FACET 的核心优势在于可执行状态共享：指令、参考解和验证器都基于同一修复后的容器状态，从根本上减少跨工件冲突。与单纯扩大数据量相比，FACET 更强调源意图保留，避免了信息丢失。实验中的生成方案消融进一步证实：环境接地构造对任务有效性和解决方案-验证器对齐至关重要，这为可扩展终端任务合成确立了关键原则。

行业影响

落地场景

FACET 自动合成可执行终端任务，并保证指令、环境、参考解与验证器一致。适用于训练/评测终端智能体的产品：

• 企业 IT 自动化 / DevOps 平台：生成配置管理、日志分析、部署脚本等任务，训练运维 agent。
• 云厂商 / 容器服务：基于共享容器状态生成可复现环境与验证器，作为云上 agent 任务生产流水线。
• 开发者工具：为代码代理生成 repo 级终端任务，增强复杂开发场景执行能力。

典型 use case：电商平台后端自动化中合成“清理过期订单日志并生成日报”任务；金融企业运维中生成“批量查询交易数据并修复异常记录”任务。FACET 确保这些任务可解且评测准确。

商业价值

• 降本：替代专家手工构造终端任务，减少指令设计、环境初始化和验证器编写的人力成本，尤其在大规模训练数据需求下效果显著。
• 提质：shared executable-state grounding 减少任务不可解或错误评测比例，提升训练数据有效率，使模型在 Terminal-Bench 2.1 上获得稳定提升，缩短迭代周期。
• 增收/体验：训练好的终端智能体可嵌入企业级助手或自动化运维产品，提供更高成功率的自动化执行，降低人工介入，增强产品竞争力。

与现有工作流的接口

• 训练 pipeline：FACET 输出标准四元组（指令、环境 image、参考 solution、verifier），可直接接入 SFT / RL 数据流。
• 容器化基础设施：生成的环境基于 Docker 等容器，可对接现有 CI/CD 系统（如 GitHub Actions、Jenkins），实现自动评测与回归。
• 基准评测：与 Terminal-Bench 2.1 等公开基准衔接，便于横向比较不同终端 agent 能力。

FACET 可作为现有 agent 训练栈中的数据合成层，而非替代整套系统。

局限

• **覆盖范围受限于源技能采集与过滤流程**：FACET 的 source-skill repository 构建依赖对现有 agent skills 的收集、过滤与理解，若源技能分布偏窄或缺失某些复杂终端操作模式，生成的任务可能难以覆盖长尾场景。论文未详细讨论源技能覆盖度对任务多样性和难度分布的影响，也未在实验中量化不同源技能集下任务质量的稳定性，这一依赖限制了框架在完全陌生领域的可迁移性。
• **环境构造与执行验证的迭代成本较高**：FACET 在环境 construction 与 repair 阶段需要通过执行验证和 targeted repair 来保证容器状态一致性，这引入额外的计算与时间开销。论文未报告生成单个任务的平均计算成本和失败重试次数，也未与纯合成方法在资源效率上进行对比。对于大规模任务生成，这种环境 grounding 可能成为扩展瓶颈，尤其当任务需要复杂初始化状态或大量依赖时。
• **评估范围较单一，泛化性有待考证**：实验仅在 Terminal-Bench 2.1 上验证 fine-tuning 效果，且用于训练的模型规模可能有限；论文未在更多终端基准（如 SWE-bench 终端变体、OSWorld 终端子集）或不同架构模型上做广泛测试。此外，成功轨迹的监督信号是否会在不同终端环境或真实生产场景中保持有效性，尚未得到充分检验，可能影响该方法的通用结论。