AutoSynthData：把智能体的失败，变成可验证的训练任务

原文发布日期：2026 年 10 月 2 日 智能体在业务流程里做错了，团队往往先改提示词，或补几条示例。ServiceNow CoreAI 团队在 Hugging Face 发布的 AutoSynthData 文章，讨论了另一条路线：把失败暴露出的能力缺口，转成可以执行、可以验收的新任务，再用这些任务训练模型。 这篇文章介绍的是团队的方法与实验，不是 Hugging Face 的独立评测。Easycha 没有复现实验，以下将原文事实与编辑分析分别说明。 官方方法：先找缺口，再生成题目 AutoSynthData 对比目标模型的失败与更强教师模型的成功，提炼需要补足的能力。一个训练任务由系统说明、用户请求和验证器组成。任务不仅要像真实需求，还必须在给定环境里做得到，并对当前模型有一定挑战。 为降低照搬评测题的风险，生成器接收经过清理的能力卡，而不是原始评测提示、实体、执行轨迹或验证器细节。原文将这一做法用于限制评测信息进入生成过程，但这不等于所有相似性与污染风险已经消失。 流水线先生成并验证核心任务，再扩展成不同请求、实体和初始状态的变体。变体不能继续作为下一轮变体的种子，以限制内容逐步偏离原始能力目标。公共控制器负责生成与覆盖，环境适配器负责执行、回放和状态核验。 验收器也需要被验收 一份漂亮的题面并不能保证训练样本可靠。原文通过执行参考轨迹，确认预期结果能够通过验证；同时修改预期结果，检查错误状态是否会被拒绝。候选任务可以经过有限次数的批评与修复，但修复后仍须重新通过检查。 验证器还应接受不同的正确解法，而非只认某一条固定调用顺序。批次层面则检查重复、能力分布失衡与覆盖缺口。这样，样本质量就不只由生成文本是否流畅来决定。 Easycha 分析：这一点对工单、订单等工具调用应用很有价值。假设目标是把工单交给正确团队，验收应检查最终负责人和状态，也应拒绝误改其他记录的结果。这个例子是工程说明，并非本文复现得到的测试结论。 实验说明了什么 团队报告，在 EnterpriseOps Gym Hybrid 的配置下生成了两千条样本，耗时约十八小时。监督微调后的最佳检查点，平均 Pass@1 提高了 7.2 个百分点，对应约 35% 的相对提升。两种表达的分母不同，不能把它写成成功率增加了三十五个百分点。 这些结果来自指定模型、教师、环境和训练设置，不能直接推广到任意 API 或线上流程。文章展示的是监督微调实验，强化学习属于后续方向；也不能仅凭方法文章，就认定完整生成流水线已公开发布代码。 Easycha 分析：应用团队可以借鉴哪些部分 即使没有模型训练条件，也可以借鉴“失败分类、构造变体、执行核验”的流程，把它用于内部回归测试。这是对方法的应用建议，不是原文已经验证的额外收益。 落地时应先固定一个小业务环境，保留初始状态、可用工具与验收规则，再从反复出现的失败类型中挑选少量任务。新增样本要与独立测试集分开，并记录生成、执行和人工复核成本。 这套方法的实际门槛，在于能否可靠地重建环境和编写验证器。错误的验收标准会把错误行为变成训练目标；过于相似的变体也可能只增加数量。对开发者而言，先证明每道题能做、能判、值得学，再扩大数据规模，更有助于判断投入是否有效。