Shopify Agent冷启动实战：零对话数据训练生产级AI的三步法

当企业级Agent要进入生产环境时，容错率极低——尤其是处理业务流程的Agent。它面对的不是闲聊，而是后台里的规则、条件、动作和自动化流程。一次工具调用错误，就可能触发错误的业务规则，造成真实的经济损失。

Shopify近期发布了一篇详细的技术博客，讲述了他们如何将一个生产级AI Agent从零落地的完整过程。其中最值得关注的，是他们解决"冷启动"问题的思路——在没有任何真实用户对话数据的情况下，如何构造高质量的训练样本。

业务背景：让AI助手自动生成电商工作流

Shopify有一个产品叫Shopify Flow，本质上是电商后台的自动化工作流工具。商家可以用它设置各种规则：高风险订单自动提醒团队、库存低了自动发通知、客户完成某个动作后自动打标签、发邮件、触发后续流程。

Flow属于iPaaS（集成平台即服务）和RPA（机器人流程自动化）在电商垂直领域的具体实现。在电商运营中，商家每天面对大量重复性决策：库存管理、订单风控、客户分层、营销触达等。传统做法依赖人工操作或开发者编写代码，而Flow通过可视化的**触发器-条件-动作（Trigger-Condition-Action）**范式，让非技术人员也能搭建自动化规则。这种模式在Zapier、Make等通用自动化平台中已被验证，但Shopify的优势在于深度集成自有生态——包括订单、库存、客户、折扣等数百个原生数据对象和事件，使得自动化规则可以直接操作核心业务实体，而非仅做表层的数据搬运。

现在，Shopify希望让自己的AI助手**Sidekick（内部代号Cyclone）**直接帮商家生成这些Flow。商家只需说一句自然语言，Cyclone就要输出一条可以在后台执行的完整自动化业务流程。

难点在于Tool Call的复杂性：模型要知道什么时候该搜索工具、什么时候该选触发器、什么时候该加条件、什么时候该配置动作，最后还要把这些组件组装成Shopify后台能执行的工作流。这不是一个简单的问答任务，而是一个多步骤、强约束的工具调用链路。

Tool Call（工具调用）是当前AI Agent架构的核心能力，源自OpenAI在2023年推广的Function Calling机制。其本质是让大语言模型在生成自然语言回复之外，还能输出结构化的函数调用指令——包括函数名称和参数。模型本身并不执行这些函数，而是由外部系统接收指令后实际执行，再将结果返回给模型进行下一轮推理。在Shopify的场景中，Tool Call的复杂度远超普通的单次函数调用：模型需要在一次对话中串联多个工具（搜索可用组件、获取组件配置schema、校验参数合法性、组装最终工作流），形成一条多步骤的调用链路。任何一步的参数错误或调用顺序错乱，都会导致生成的工作流无法执行甚至触发错误的业务逻辑。

为什么自己微调，而不是直接用闭源大模型？

Shopify在原文中的判断非常直接：

如果你基于封闭模型构建AI产品，那么任何有API密钥的人都能获得类似能力。真正长期的差异化，不是"我也接了一个大模型"，而是专有数据、训练方案、基础设施，以及迭代速度。

这一决策涉及AI工程中的经典权衡：便利性与可控性。直接调用GPT-4、Claude等闭源模型API，优势是开箱即用、无需训练基础设施，但劣势同样明显——模型行为不可控（供应商可能随时更新模型导致输出漂移）、数据隐私风险（业务数据需发送至第三方）、成本随调用量线性增长、且无法形成技术壁垒。微调开源模型则需要投入GPU集群、训练pipeline和评估体系，但一旦建成，企业获得的是一个完全自主可控的模型资产。Qwen-32B是阿里通义千问团队开源的大语言模型，参数量320亿，在代码生成和工具调用等任务上表现优异，且其Apache 2.0许可证允许商业使用和微调，这使其成为企业级Agent微调的热门基座选择。

最终结果也验证了这个判断：微调后的Qwen-32B模型速度提升2.2倍，成本降低60%，并且性能超过了闭源大模型。

冷启动困境：没有对话数据怎么办？

训练一开始就遇到了核心问题：这个能力还没发布，没有真实用户对话，也没有真实交互数据。可是要提高Tool Call的准确性，又必须有高质量的训练样本。

冷启动（Cold Start）问题最早在推荐系统领域被广泛讨论——新用户或新物品没有历史交互数据，系统无法做出有效推荐。在AI Agent领域，冷启动的挑战更为严峻：不仅缺少用户偏好数据，连基本的输入-输出样本对都不存在。传统的监督学习依赖大量标注数据，而强化学习从人类反馈（RLHF）则需要真实的人机交互轨迹。当一个全新的Agent能力尚未上线时，这两种数据来源都不可用。业界常见的应对策略包括：使用强模型生成合成数据（Synthetic Data）、从相似任务迁移学习、或通过规则系统先上线一个基础版本来收集数据。

Shopify的做法非常巧妙——不是先猜用户会怎么说，而是先看用户已经做成了什么。

答案就藏在Shopify Flow里。很多商家早就手动创建过大量Flow，有些已经运行过，有些还在频繁使用。这些不是对话数据，但它们是用户意图的结果。用户没有留下问题，却留下了做好的答案。

这就像你没听见顾客点菜，但你看到了桌上的菜。菜不是点菜单，但它能帮你倒推顾客大概想吃什么，以及厨师是怎么做出来的。

从业务结果倒推训练数据的三步法

第一步：筛选可靠的Flow样本

Shopify从生产环境中筛选高质量的Flow，设定了严格的筛选标准：

• 最近7天运行过，确保是活跃的业务流程
• 来自拥有多个合格Flow的商家，排除偶然创建的低质量样本
• 同一类描述只保留一个样本，保证不同工作流类型都有覆盖

第二步：用强模型反向生成用户请求

拿到一个经过验证的Flow之后，用更强的大模型反向生成一句合理的自然语言请求——也就是推测"商家可能会怎么说，才会得到这个Flow"。

用强模型为弱模型生成训练数据，在学术界被称为知识蒸馏（Knowledge Distillation）的一种变体。微软的Phi系列小模型、Google的Gemma等都大量使用了合成数据进行训练。但Shopify的做法更进一步：不是简单地让强模型生成问答对，而是从真实业务产物出发进行反向工程（Reverse Engineering）。这种方法的关键优势在于锚定了真实性——生成的训练样本以实际运行中的业务流程为ground truth，而非凭空构造。在NLP领域，这类从答案反推问题的技术也被称为问题生成（Question Generation），已在阅读理解、FAQ构建等场景中被验证有效。但将其扩展到多步骤工具调用轨迹的构造，是一个工程复杂度显著更高的任务，因为需要确保每一步中间调用的逻辑合理性和参数正确性。

第三步：构造完整的工具调用轨迹

这是最关键的一步。不仅要有输入（用户请求）和输出（最终Flow），还要补出理想Agent的完整工具调用过程：先搜什么工具、再看哪些候选、再取哪些配置、然后怎么加条件和动作、最终组装成可执行的Flow。

这里最重要的不是最终结果，而是中间路径。有了路径，模型才知道面对一句用户请求时，应该怎么找、怎么筛、怎么取配置结构、怎么组装流程。

构造的不是问答对，而是完整调用链路

Shopify构造的训练数据不是一条"问题→答案"的短线，而是一条完整的链路：

业务结果 → 用户问法 → 工具路径 → 最终回答 → 可执行工作流

这批合成数据集最终被用来微调Qwen-32B。同时，Shopify还构建了一个包含300个手工样例的基准测试集，覆盖预期中的Flow使用范围，评估三类指标：

1. 语义正确性：生成的工作流在语义上是否完成了用户想做的事
2. 语法正确性：有没有会导致执行失败的格式错误，比如条件写坏了、引用错了、配置无效
3. 延迟：从用户提出请求到工作流交付出来需要多长时间

Shopify设计的这三类评估指标反映了企业级AI系统评估的核心原则：不能只看"模型觉得对不对"，还要看"系统能不能跑起来"和"用户等不等得起"。语义正确性评估的是意图理解层面——生成的工作流是否真正完成了用户想做的事，这通常需要人工评审或使用LLM-as-Judge（用另一个大模型作为评判者）的方式。语法正确性则是工程层面的硬约束——一个JSON格式错误、一个不存在的字段引用、一个类型不匹配的参数，都会导致工作流在Shopify后台执行失败。延迟指标则直接关系到用户体验，在交互式Agent场景中，超过10秒的响应时间会显著降低用户信任度和使用意愿。300个手工构造的基准测试样例虽然数量不大，但在企业级评估中已属于较高投入——每个样例都需要领域专家手动编写并验证，确保覆盖边界情况和常见错误模式。

对企业AI落地的启发

Shopify的这套冷启动方法对所有想做企业级AI Agent的团队都有参考价值：

如果你没有交互数据，不要只等用户开口。可以先从用户已有的输出结果入手，反向推导训练样本。

企业里的真实数据，可能藏在审批流里、藏在配置表里、藏在历史工单里、藏在已经运行的自动化规则里。你要先认出它是业务痕迹，再把它翻译成训练样本。

但原文也坦诚提醒：这只是第一步。靠这套方法启动之后，仍然存在显著差距需要缩小。因为倒推出来的用户请求终究是合成数据，它不可能完全代表真实用户上线以后会怎么说。合成数据的分布偏差（Distribution Shift）是一个已被广泛研究的问题——模型在合成数据上训练后，面对真实用户的多样化表达、模糊意图、甚至错误描述时，可能出现性能下降。因此，冷启动之后的关键动作是尽快建立真实数据的收集和反馈闭环，用线上数据持续迭代模型。

核心工程判断可以总结为一句话：**很多企业AI的训练数据不是收集来的，而是从业务系统里挖出来、翻译出来的。**这种"从结果倒推意图，从意图补出路径"的思路，是在真实用户数据积累起来之前，最务实的冷启动策略。

核心要点

• Shopify通过从已有的商家Flow业务结果反向推导，解决了Agent训练的冷启动问题——没有真实对话数据时，从用户已完成的输出倒推意图和工具调用路径
• 微调Qwen-32B后的专有模型实现了速度提升2.2倍、成本降低60%，性能超过封闭式大模型，验证了自主训练的长期价值
• 训练数据构造分三步：筛选生产环境中可靠的Flow样本、用强模型反向生成用户请求、补全完整的工具调用轨迹（中间路径比最终结果更重要）
• 企业AI的训练数据往往不是直接收集来的，而是从审批流、配置表、历史工单等业务系统中挖掘和翻译出来的
• 合成数据仍有局限性，无法完全代表真实用户行为，冷启动只是第一步，后续仍需持续缩小与真实场景的差距