AutoSynthData重做Agent训练数据

企业级 AI Agent 的训练瓶颈，正在从模型能力转向数据生产能力。

ServiceNow AI 近期公开的 AutoSynthData，是一套面向企业 Agent 的合成数据生成方法：它从业务任务和企业工具环境出发，自动生成用户请求、任务步骤、工具调用、执行结果与最终回复，再通过规则或模型验证这些轨迹是否真正完成了目标。

这和让大模型批量改写几万条问答并不是一回事。普通数据增强主要改变“用户怎么提问”，AutoSynthData 更关心 Agent“如何把事情做完”。

截至 2026 年 10 月 2 日，AI Agent 已经从聊天机器人进入软件操作、工单处理、客户支持、IT 运维和业务审批等流程。模型能否调用正确工具、理解企业字段、处理异常状态、在权限边界内完成多步任务，决定了它是不是一个可交付的数字员工。AutoSynthData的价值，正是把这些难以收集的过程数据变成可持续生产的训练资产。

企业 Agent 缺的不是对话，而是轨迹

企业 Agent 训练数据是描述 Agent 如何理解任务、规划步骤、调用工具并完成业务目标的结构化样本，而不只是用户问题与模型答案组成的问答对。

这一区别很重要。

如果训练目标只是客服问答，数据可以大致写成“用户提问—客服回答”。但一个 IT 服务台 Agent 处理“帮我给新员工开通开发环境”时，可能需要完成以下动作：

1. 从请求中识别员工身份、部门和所需权限。
2. 查询员工是否已经存在于人力资源系统。
3. 根据岗位匹配权限模板。
4. 检查设备、许可证和审批状态。
5. 创建工单或调用配置系统。
6. 遇到权限不足、字段缺失或资源不可用时，转为人工处理。
7. 返回可审计的执行结果。

真正需要训练的不是一句“好的，我来处理”，而是整个决策链条。模型要知道何时查数据、何时调用工具、何时停止操作，尤其要知道什么时候不能自作主张。

传统企业数据很难覆盖这些情况。生产系统里的高价值流程往往数量有限，涉及隐私和权限，失败样本更少见，长尾异常则几乎不会被均匀记录。一个 Agent 可能在常规流程上表现不错，但碰到字段为空、重复工单、权限冲突或跨系统状态不一致，就会暴露问题。

AutoSynthData的出发点，是把企业 Agent 的训练数据从静态文本扩展为可执行的任务轨迹。

AutoSynthData到底生成什么

AutoSynthData生成的是带有业务目标和执行过程的合成 Agent 数据，而不是单纯的自然语言改写样本。

从公开介绍来看，这套方法的核心流程可以理解为四个阶段。

第一阶段：从企业任务定义种子场景

企业首先需要提供少量真实或人工编写的任务描述、业务规则、工具说明和成功条件。它们可以是“重置用户密码”“查询订单状态”“创建变更请求”这类明确动作，也可以是带有约束的复杂任务。

这些种子数据不需要覆盖所有表达方式，但必须能够说明三个问题：用户想完成什么，Agent可以使用哪些工具，什么结果才算成功。

这一步决定了合成数据是否贴近企业流程。如果种子任务只写“处理客户退款”，却没有退款金额上限、订单状态、审批权限和异常分支，后续生成的样本即使语言很自然，也很可能只是看起来合理。

第二阶段：扩展用户请求和任务变化

系统围绕一个业务目标生成不同表达、上下文和约束。例如，同一个“查询订单”任务，可以变成简短口语、带错别字的输入、多轮追问、缺少订单号的请求，或同时包含多个目标的复杂请求。

这类扩展能覆盖企业交互里的常见长尾：

• 用户不知道准确字段名称，只能用业务俗称描述。
• 用户一次提出多个请求，Agent必须判断先后顺序。
• 关键参数缺失，Agent需要追问，而不是猜测。
• 用户提供了互相矛盾的信息，Agent需要校验。
• 用户要求的动作超出权限，Agent必须拒绝或转交人工。

阿里云公开的数据增强模板也将同义改写、口语噪声、追问扩展、要素结构和对抗样本列为常见增强方式，并称 50 条种子数据可生成约 550 条训练数据。但这类数量提升只能说明文本覆盖扩大，不能直接等同于 Agent 能力提升。AutoSynthData进一步把样本放进工具执行和结果验证环节，目标是验证行为链是否成立。

第三阶段：生成多步工具调用轨迹

工具调用轨迹是记录 Agent 在一次任务中如何选择工具、填写参数、读取结果并继续决策的结构化过程。

例如，用户要求“找出本季度仍未关闭、金额超过 10 万元的客户工单，并创建一份汇总”，一个合格轨迹至少要包含：查询工单、过滤状态、筛选金额、聚合客户信息、生成结果，以及在数据不完整时进行说明。

这里的难点是工具返回结果不能只是固定文本。不同工具状态、返回字段和错误信息，会改变 Agent 的下一步动作。AutoSynthData的意义在于，它不是让模型凭空想象一次对话，而是让合成过程尽可能遵守企业环境里的工具接口、数据约束和任务目标。

换句话说，训练样本不再只是“答案长什么样”，而是“在这个状态下，下一步应该做什么”。这更接近强化学习中的轨迹，也更接近企业软件真正运行的方式。

第四阶段：用验证器筛掉看似正确的样本

合成数据验证器是检查样本是否满足任务目标、工具约束和业务规则的程序或模型组件。

这是整个方案最关键的一层。大模型可以生成大量流畅的过程，但流畅不代表正确。它可能调用一个不存在的工具，填入不符合格式的参数，跳过审批步骤，或者在工具返回失败后仍然声称任务完成。

企业 Agent 的质量验证至少应覆盖以下维度：

• 任务完成度：最终状态是否满足原始目标。
• 工具合法性：调用的工具和参数是否符合定义。
• 状态一致性：前一步的输出是否能支持下一步决策。
• 权限合规性：是否执行了当前角色无权执行的动作。
• 异常处理：工具失败、数据缺失和冲突输入是否得到正确处理。
• 回答可追溯性：最终回复是否对应真实执行结果，而不是模型自行编造。

如果只有生成器，没有验证器，合成数据很容易形成“错误自我复制”。模型先生成一个错误流程，再用相似模型评估它，最后把错误轨迹加入训练集，结果是数据量增加了，可靠性反而下降。

它与普通数据增强有什么不同

普通数据增强是围绕已有样本制造更多语言变体的方法；Agent合成数据则是围绕任务目标生成可执行、可验证的决策过程。

| 对比维度 | 普通数据增强 | AutoSynthData式Agent数据生成 | |---|---|---| | 主要对象 | 用户问题、问答文本 | 任务、工具调用和完整执行轨迹 | | 变化方式 | 改写、扩写、加入噪声 | 改变目标、状态、约束和异常分支 | | 质量判断 | 文本流畅、语义相似 | 任务是否完成、动作是否合法 | | 主要收益 | 提高语言覆盖和鲁棒性 | 提高规划、调用工具和异常处理能力 | | 主要风险 | 语义漂移、重复样本 | 虚构工具、错误轨迹和规则污染 | | 适合场景 | 分类、问答、检索增强 | 工单、审批、运维和跨系统流程 |

这也是为什么企业 Agent 的数据工程不能只看样本数量。一个生成了 100 万条自然语言改写的数据集，可能不如几万条经过执行验证的多步轨迹有用。

对企业落地意味着什么

AutoSynthData最现实的价值，是降低企业 Agent 从原型走向生产时的数据冷启动成本。

新业务上线时，企业往往没有足够的真实交互记录。低频但高风险的任务，比如权限变更、财务审批、数据导出和生产环境操作，更不可能靠自然积累快速获得训练样本。通过任务模板、工具描述和业务规则，企业可以先生成一批覆盖正常路径与异常路径的样本，再用人工抽检和沙盒执行校验结果。

它还适合处理“失败样本稀缺”问题。生产数据通常记录成功操作更多，失败操作更少；但 Agent 的可靠性往往由失败处理能力决定。合成系统可以主动构造权限不足、工具超时、参数缺失、结果为空和状态冲突等场景，将这些原本难以收集的案例加入评测和微调数据。

另一个价值是让评测更接近真实工作流。企业不应该只问模型“这句话该怎么回答”，还要测试它是否能在连续 5 到 10 个步骤中保持状态一致，是否会重复调用工具，是否会在失败后胡乱重试，以及是否会把未完成任务报告为已完成。

从工程角度看，合成数据还可以成为版本回归测试集。每次修改提示词、工具描述、模型或编排逻辑后，重新执行同一组任务，就能比较任务成功率、平均步骤数、错误调用率和人工接管率的变化。

但它不是企业数据的替代品

AutoSynthData不能解决企业规则本身不清晰、工具接口不稳定和权限体系混乱的问题。

第一，合成数据的上限取决于种子任务和环境描述。如果企业无法准确说明业务目标、工具副作用和成功条件，生成器只会把模糊规则放大。

第二，模拟环境与生产环境之间存在差距。沙盒里一个工具可能始终返回结构化结果，生产系统却会遇到网络延迟、脏数据、并发更新和权限漂移。只在模拟环境中验证通过，不代表真实部署可靠。

第三，自动验证器也可能漏检。文本层面的判断很难发现隐蔽的业务错误，例如金额计算正确但税率适用错误，工单创建成功但缺少审计字段。因此，高风险流程仍需要人工复核和真实系统中的小流量验证。

第四，合成数据存在分布偏差。生成模型倾向于重复常见表达和典型流程，可能制造大量结构相似的轨迹。企业需要持续引入真实匿名样本、人工设计的极端案例和线上失败记录，避免训练集变成“模型想象中的企业”。

2026年，Agent数据工程会成为独立岗位

过去两年，企业建设 Agent 往往先选择模型和框架，再考虑数据。这个顺序正在改变。

随着 Agent 从单轮问答进入跨系统执行，企业真正需要维护的是一套任务资产：任务定义、工具目录、权限规则、成功标准、异常分支、验证器和回归测试集。AutoSynthData把其中的数据生产环节自动化，但它没有消除数据治理，反而让治理变得更重要。

Dataiku等企业平台正在把 Agent 的创建、编排、权限、监控和复用集中到统一控制面；云厂商则提供从日志中提取输入、输出、模型名称和 Trace ID 的数据管道。两类产品的发展说明，企业 Agent 的竞争已经不只是模型参数规模，而是能否持续观察、评测和改进一整套工作流。

对开发团队而言，最值得借鉴的不是“让模型多生成一些数据”，而是建立下面这条闭环：

1. 用真实业务目标定义任务，而不是从聊天记录中盲目抽样。
2. 为每个任务明确工具、权限、状态和成功条件。
3. 同时生成正常路径、缺参路径和失败路径。
4. 在沙盒或可控环境中执行轨迹。
5. 用规则验证器与模型评估器共同筛选样本。
6. 将线上失败案例匿名化后回流，更新任务和验证规则。
7. 用固定回归集比较模型升级前后的成功率与风险。

OpenAI Hub判断

AutoSynthData的核心价值不在于把企业训练数据从 1 万条扩展到 100 万条，而在于把“Agent应该如何完成工作”变成可以生成、执行和验证的数据对象。

它比单纯的问答扩写更接近企业实际需求，也比完全依赖人工标注更容易覆盖长尾流程。但它不是一台自动生产高质量数据的机器。企业仍然需要提供可信的任务定义、稳定的工具环境和可执行的成功标准。

对于客服问答、知识库检索这类场景，传统数据增强已经足够实用；对于审批、运维、工单和跨系统自动化，只有包含工具调用与状态变化的轨迹数据，才真正触及 Agent 能力的核心。谁能把真实失败持续转成可验证训练样本，谁才更可能把 Agent 从演示功能推进到生产系统。

这也是 AutoSynthData 在 2026 年仍然值得关注的原因：企业 Agent 的下一个瓶颈，很可能不是模型还不够大，而是没有足够多、足够真、足够可验证的工作过程供模型学习。

参考来源

• ServiceNow AI：AutoSynthData: Generating Training Data for Enterprise Agents：介绍 AutoSynthData 的设计思路，以及面向企业 Agent 生成训练数据的整体方法。
• 阿里云：数据增强合成：说明同义改写、口语噪声、追问扩展、要素结构和对抗样本等常见数据增强方式。
• Google Cloud：什么是合成数据？如何使用？：介绍合成数据的基本概念，以及生成式模型在结构化数据场景中的应用边界。
• Dataiku：Deliver AI agents at enterprise scale：展示企业 Agent 在创建、编排、治理和监督方面的产品化趋势。