AutoSynthData：企业 Agent 训练数据能否自动生成且可验证？

先说结论

企业 Agent 最难补的，往往不是再换一个更大的通用模型，而是缺少足够多、足够真实、还能自动验收的训练任务。ServiceNow 在 2026 年 10 月 2 日发布的 AutoSynthData，试图把这件事做成一条闭环：先观察目标模型在企业环境中的失败，再让更强的教师模型帮助提炼能力缺口，自动生成新的任务、轨迹和验证器，最后只把通过执行检查的数据用于训练。

我的判断是：AutoSynthData 的真正价值不在“合成数据”四个字，而在“生成—执行—验证—修复—再评估”的质量门禁。它展示了企业 Agent 训练从静态题库走向动态课程的一条可行路径，但目前的结果只证明了在 EnterpriseOps Gym 这类受控环境中的改进，不能直接等同于真实生产系统的成功率。企业如果要借鉴，应该先复制验证链，而不是先复制生成规模。

发生了什么

主来源是 Hugging Face 官方博客《AutoSynthData: Generating Training Data for Enterprise Agents》，发布日期为 2026-10-02，原始 URL：https://huggingface.co/blog/ServiceNow-AI/autosynthdata。文章来自 ServiceNow CoreAI，介绍了 AutoSynthData 的设计、质量控制流程以及 EnterpriseOps Gym 实验。

官方事实包括：一个可训练的 Agent 任务被抽象为三部分——系统规格、面向 Agent 的任务描述和验证器。系统规格定义环境规则、可用工具、初始化状态与约束；任务描述表达要完成的目标；验证器则判断最终环境状态是否满足要求。文章认为，合格任务必须同时满足可执行、贴近真实工作和具有适当难度三个条件。

AutoSynthData 会先在目标环境中评估目标模型，分析它在哪些能力上失败；随后由更强的教师模型执行相同或相关任务，帮助判断这些任务是否可解、成功行为是什么、最终状态需要满足哪些条件。系统把这些信息压缩为经过脱敏的能力规格卡，再依据规格卡生成不同提示、不同初始状态、不同实体和不同解决路径的新任务。生成器不会直接拿原始评测任务的提示、实体、轨迹或验证细节去复制样本。

官方还披露了两组实验。在 EnterpriseOps Gym 的 Hybrid 环境中，AutoSynthData 生成 2,000 个合成训练样本，约用时 18 小时；使用这些样本进行监督微调后，平均 Pass@1 提高 7.2 个百分点，相对提升 35%，验证器成功率从 63.01% 提高到 68.55%。在 ITSM 环境中，系统生成 1,994 个样本，用时 66 小时；平均 Pass@1 从 18.77% 提高到 27.18%。

这里要明确区分：以上数字是官方在 EnterpriseOps Gym 中报告的实验结果；本文关于生产落地、数据治理和 Agent 工程的判断，不是 ServiceNow 对其他环境的性能承诺。

技术细节

1. 生成对象不是一句提示词，而是一个可执行任务

普通的合成数据流程，容易停在“让模型写很多看起来像真的任务”。AutoSynthData 的关键不同，是把任务放进有状态的环境里。环境包含 Agent 可以观察和修改的状态、可调用的工具或接口，以及每次动作会带来的状态变化。一个任务如果依赖不存在的工具、不可访问的知识或不允许的状态转换，即使自然语言写得很像真实需求，也不应该进入训练集。

这使得训练数据从文本生成问题变成了系统测试问题。任务生成器要同时考虑初始状态、规则、工具组合、目标状态和清理方式。比如一个企业工单任务，不能只写“更新工单并通知相关人员”，还要明确哪些字段可改、通知动作是否允许、重复执行是否幂等、最终状态如何检查，以及失败后是否能恢复。

2. 难度要落在目标模型的能力边界

AutoSynthData 不追求把任务做得越难越好。文章描述的目标区域是：目标模型不能稳定完成，但教师模型仍能可靠完成。太简单的任务训练信号不足，太难或不可执行的任务则会把错误行为和噪声带进数据集。

在实验配置中，系统偏好目标模型三次尝试最多成功一次，而更强的求解器至少三次成功两次的任务。这个设置体现了“能力边界课程”的思想：每轮训练都应该集中处理当前模型真正缺的能力。模型升级后，原来有价值的任务可能已经变简单，下一轮生成就要把重点移动到仍然失败的区域。

这比固定题库更接近真实工程。企业流程会变，工具会增加，权限会调整，模型也会更新。训练集如果长期不根据失败分布变化，就会被模型逐渐“刷熟”，但不会覆盖新的薄弱点。

3. 正向验证和负向验证缺一不可

每个候选任务要经过多个门。正向验证会在目标环境执行参考轨迹，检查任务描述、初始状态、解决步骤和验证器是否彼此一致；也就是说，预期成功路径真的能让任务完成。负向验证则会修改预期结果的一部分，确认这些相关的错误状态不会被验证器误判为成功。

负向验证尤其重要。一个过于宽松的验证器可能只检查“工单存在”，却没有检查类别、负责人、优先级和通知状态；这样，Agent 即使没有完成真正目标，也能拿到成功信号。训练系统一旦奖励这种漏洞，模型学到的就不是业务能力，而是如何钻验收规则的空子。

如果候选任务失败，系统会让批评器分析原因，例如状态不一致、工作流不可执行、参考轨迹错误、验证器过弱，或任务与目标能力不匹配。之后进行次数受限的定向修复，修复后的样本必须重新通过相关检查，而不是只修改文本后直接放行。

4. 批次级检查防止数据集“看似很大、实际很窄”

单个样本正确，不代表整个数据集有用。一个批次可能反复生成同一种容易任务，覆盖不了关键能力；也可能因为某个生成模式很成功，把大部分预算都花在同一类变体上。AutoSynthData 因此还会做批次级复盘，检查能力覆盖、重复程度、被拒样本、持续失败的目标和批评器反复指出的问题。

这种设计把“数据质量”从样本级扩展到分布级。对企业 Agent 来说，除了任务数量，还应该知道数据覆盖了多少工具组合、多少权限边界、多少失败类型、多少状态变化和多少不同的自然表达。没有覆盖统计，2,000 个样本也可能只是同一个流程换了 2,000 个名字。

对 Agent / 工程的影响

第一，企业应把训练数据生成和评测环境设计在一起。先定义一个不含真实敏感资料的合成环境，明确可观察状态、允许的工具、状态转换和最终验收，再讨论如何生成任务。环境没有确定的状态合同，生成器就无法保证任务真实可做，验证器也无法稳定判断结果。

第二，验证器必须像生产代码一样测试。至少要有正常路径、缺字段、权限不足、工具超时、重复提交、错误目标和部分成功等样例。程序可以确定性地检查状态与字段，模型可以帮助提出候选任务和分析失败，但模型不能自行宣布样本“已经正确”。验证器的版本、规则变更和覆盖范围都应进入评测记录。

第三，训练样本要和原始评测任务隔离。AutoSynthData 用能力规格卡而不是原始提示和轨迹来驱动生成，这个原则值得借鉴。否则，生成器很容易记住评测题的实体、措辞和标准答案，最后得到的是题面变体，不是真正的能力提升。企业应对训练、开发评测和最终验收使用不同的任务实例，并保留去重与泄漏检查。

第四，Agent 训练要关注“正确完成”之外的安全属性。一个任务通过了最终状态检查，不代表过程中没有越权读取、重复写入或泄露不必要的数据。训练和评测应同时记录工具调用序列、权限使用、失败后的行为、重试次数、耗时、回滚结果和敏感字段暴露情况。对高影响动作，还要把人工确认和可撤销性纳入成功条件。

第五，合成数据不能替代真实分布验证。EnterpriseOps Gym 的实验说明流程在受控环境中有效，但真实企业有历史脏数据、临时规则、权限差异、服务波动和未文档化习惯。上线前应使用脱敏的真实分布统计或高保真合成数据做留出验证，并把“验证器通过”与“业务人员认可”分开统计。

第六，成本也要进入课程设计。官方实验中，2,000 个 Hybrid 样本约用 18 小时，1,994 个 ITSM 样本约用 66 小时，说明环境执行、教师推理和质量检查会显著影响数据生产成本。工程团队不应盲目扩大样本数，而应优先生成能覆盖新能力、能暴露失败、且通过率稳定的任务。重复生成一批低信息量样本，既浪费推理预算，也会让模型过拟合流程表面。

我的判断

AutoSynthData 值得学的不是“让模型帮模型制造更多训练数据”，而是把合成数据放进可执行环境，用正向验证、负向验证和批次复盘守住质量。我会把它当作企业 Agent 训练的流程模板，而不是一套拿来就能提升生产成功率的魔法工具。

如果今天开始落地，最小版本应该只有一个低风险环境、十几类能力规格、确定性的状态验证器和可回放的失败记录。先证明生成的任务真的可做、错误结果真的会被拒绝、训练后提升能在独立留出任务上重现，再考虑扩大教师模型、样本规模和业务范围。顺序反过来，得到的通常只是更大、更难解释的训练集。

Q&A

Q1：来源、发布日期和原始 URL 是什么？

A：来源是 Hugging Face 官方博客《AutoSynthData: Generating Training Data for Enterprise Agents》，发布于 2026-10-02，原始 URL：https://huggingface.co/blog/ServiceNow-AI/autosynthdata。文章介绍 ServiceNow CoreAI 的任务生成、验证和 EnterpriseOps Gym 实验。

Q2：AutoSynthData 生成的到底是什么？

A：它生成的是放在企业环境中执行的任务样本，包含系统规格、任务描述、初始状态、解决轨迹和验证器等要素，而不是只有一段孤立的问答文本。样本需要通过执行、求解和验证后才进入训练集。

Q3：为什么一定要做负向验证？

A：因为验证器可能过于宽松，只检查了表面状态。例如只要记录存在就判成功，却没有检查字段、权限或通知结果。负向验证会修改相关结果，确认明显错误的状态不能通过，从而减少错误奖励。

Q4：官方实验能代表真实企业上线效果吗？

A：不能。Hybrid 和 ITSM 的提升是在 EnterpriseOps Gym 受控环境中得到的，证明的是这套流程在该环境中的训练价值。真实系统还要面对权限差异、数据质量、外部服务波动、业务规则和人工验收，必须独立留出验证。

Q5：小团队怎样做最小复现？

A：先做一个不含敏感信息的状态化模拟环境，定义工具 Schema、允许动作和最终状态；收集目标模型的失败类型，生成少量能力规格卡，再用正向与负向验证筛选任务。训练后用完全不同的一组留出任务比较首次成功率、重试率、越权率和回滚结果。

来源

1. ServiceNow CoreAI，AutoSynthData: Generating Training Data for Enterprise Agents，发布日期：2026-10-02，原始 URL：https://huggingface.co/blog/ServiceNow-AI/autosynthdata
2. EnterpriseOps Gym 数据集与实验信息，入口链接见上述官方文章。

本文区分官方事实与作者判断；官方实验结果对应 EnterpriseOps Gym 的特定环境、模型、教师、任务和训练设置，不构成其他生产系统的性能保证。
隐私自检：未写入姓名、账号、用户输入、内部网络细节、凭据或会话标识
封面 seed：2026-10-02-autosynthdata-agent-training（唯一）
coverWidth/Height：1600 / 900
categories：ai_tech