这项由浙江大学与腾讯合作完成的研究，于2026年4月以预印本形式发布在arXiv平台，论文编号为arXiv:2504.19667v1，有兴趣深入了解的读者可通过该编号查询完整原文。研究的核心问题听起来既简单又雄心勃勃：能不能让AI自动帮我们搭一套可以直接投入使用的工作流程？
在企业日常运营中，有一类东西叫做"工作流"——不是普通的文字流程图，而是真正能在软件平台上一键运行的自动化程序。打个比方，就像乐高积木的说明书，只不过这份说明书本身就是一台能自动拼装的机器。现在，Dify和Coze这样的平台让越来越多的企业能够通过拖拉节点的方式搭建这类流程，但问题在于，每一个节点的配置、每一条连线的逻辑，都需要专业工程师手动完成，耗时耗力，改一次需求就得重头推敲一遍。
研究团队因此提出了一个自然而然的问题：既然大语言模型（也就是ChatGPT这类AI）已经能写代码、能理解复杂指令，它能不能直接根据人类用自然语言描述的需求，帮我们把这套工作流原原本本地搭建出来，甚至在需求变化时随时修改？为了系统地研究这个问题，他们创建了一个名为**Chat2Workflow**的测试基准，并设计了一套配套的智能框架来帮助AI减少反复出错。这是目前该领域首个专门针对"从自然语言生成可执行视觉工作流"这一任务的正式基准数据集，因此具有相当的开创性意义。
---
一、工作流到底是什么，为什么它如此难以自动生成
要理解这项研究，首先得弄清楚"可执行视觉工作流"究竟是什么东西。在Dify或Coze这样的平台上，工作流看起来就像一张由方块和箭头组成的地图。每个方块叫做"节点"，代表一个具体的操作——比如调用大语言模型生成文字、用代码处理数据、发起网络请求、将文字转换成图片，等等。箭头则代表数据从一个节点流向下一个节点的路径。整张地图在后台以YAML格式的文件存储，平台读取这个文件后就能自动执行对应的任务流程。
这套系统的核心价值在于它的可靠性和可控性。相比于让AI自由发挥、每次给出不同答案，一个固定好的工作流就像一条装配线——每次输入原材料，输出的产品都遵循同样的质量标准。这正是现实企业更青睐工作流而非完全依赖AI随机发挥的原因。一项针对真实企业部署情况的调查显示，超过70%的真实AI部署案例中，开发者选择的都是这种预先定义好流程的工作流方式，而不是让模型自由生成。
然而，要让AI从一句人类语言出发，自动生成一张正确且可运行的工作流地图，难度远超想象。研究团队指出了两大核心挑战。其一，现实中的需求往往是复杂且隐式的——当用户说"我需要一个能生成科普文章的工作流"时，AI必须自行推断出这个任务需要哪些节点、这些节点应该如何连接、每个节点的参数应该怎么填写，任何一个环节出错都会导致整个流程无法运行。其二，现实中的需求会不断变化——用户在第一轮说"我要一个总结书籍内容的工作流"，第二轮又说"在此基础上再加一个生成人物传记并导出为Word文档的功能"，第三轮还要继续追加"再加一个根据传记内容生成配图的模块"。AI必须在理解历史对话的基础上，准确地对已有工作流进行增删改，既不能遗漏旧功能，也不能搞乱新旧逻辑之间的关系。
---
二、Chat2Workflow数据集是如何炼成的
为了评估AI在这个任务上的真实表现，研究团队没有凭空捏造测试题目，而是从真实的业务场景出发，踏踏实实地构建了一套高质量数据集。
他们的原材料来自Dify和Coze平台的官方资源库以及GitHub上的开源工作流配置文件——这些都是真实用户在真实场景中搭建并使用过的生产级工作流。团队拿到这些工作流之后，并没有直接把它们作为答案，而是反向操作：把工作流"翻译"成自然语言的任务描述，就像把一道做好的菜拆解回菜谱。
更关键的是，这些任务描述被设计成多轮对话的形式。同一个大任务会被拆分成两到四轮，每一轮都在前一轮的基础上增加、修改或细化需求。以书籍处理任务为例，第一轮要求"根据书名和作者名生成三分钟速读摘要"，第二轮要求"在此基础上再生成主角人物传记并导出为DOCX文件"，第三轮要求"根据传记内容生成一张插图"。这种设计模拟了现实中用户需求不断演进的真实场景，远比单轮测试更贴近实际使用情况。
经过严格的人工审核流程，团队剔除了所有指令模糊、中间步骤无效、依赖时效性来源或行为逻辑前后矛盾的案例，最终保留了27个任务，共计79轮多轮对话指令。这27个任务涵盖六大应用场景：AIGC内容生成（占22.2%）、学术研究（18.5%）、文档处理（18.5%）、教育（14.8%）、企业（14.8%）以及开发者工具（11.1%）。
为了让评估能够真正落地，每一条指令都配备了三个真实可执行的测试用例。这些测试用例的输入来自现有的公开数据集、互联网上的零散素材以及AI合成数据，输出则根据任务类型分为两种：对于输出结果比较明确的任务，测试用例会提供参考答案；对于更开放的任务，则只提供输入，由执行结果来判断是否符合要求。
---
三、AI如何生成工作流，背后有什么讲究
研究团队没有让AI直接"一口气"输出完整的工作流文件，因为那样太容易出错。他们采用了一种叫做"思维链"（Chain-of-Thought）的方法，让AI在给出最终答案之前，先把自己的推理过程分几个步骤展示出来，就像让一个人在解数学题之前先写出解题思路。
具体来说，AI的输出被分为三个部分，分别用特定标签包裹。第一部分是"节点选择"，AI需要列出这个工作流会用到哪些节点，比如"开始节点、大语言模型节点、文字转图片节点、结束节点"。第二部分是"设计原则"，AI需要用自然语言解释它打算如何设计这个流程，相当于在动手之前先讲清楚自己的思路。第三部分才是正式的"工作流"，以简化的JSON格式描述所有节点的具体参数以及节点之间的连接关系。
这个JSON文件随后会经过一个代码转换程序，自动变成Dify平台能够直接导入运行的YAML格式文件。整个流程就像先画草图、再写说明书、最后上机器实际制作——分步走比一蹴而就更不容易出差错。
为了让AI知道每种节点该怎么用，团队为20种最常用的节点类型专门整理了一份"节点知识库"，作为AI系统提示词的核心组成部分。这20种节点包括开始、结束、大语言模型、问题分类器、代码执行、文档提取器、HTTP请求、条件分支、列表处理、参数提取器、模板、变量聚合器、迭代、迭代开始、文字转语音、文字转图片、Mermaid图表转换、Markdown导出、谷歌搜索以及Echarts图表。这个节点集合虽然相对精简，但足以覆盖数据集中的所有任务场景。
---
四、如何判断AI生成的工作流到底好不好
这是这项研究最值得细说的地方。评价一段文字写得好不好，人眼一看大概就能判断；但评价一个工作流是否合格，光看它长什么样远远不够，必须真的跑起来才算数。
研究团队因此设计了一套两阶段递进评估体系，用两个指标来衡量：通过率和解决率。
通过率衡量的是第一阶段——工作流的"格式合法性"。具体来说，AI生成的输出必须经过四重检验：首先，输出格式是否正确，三个标签（节点选择、设计原则、工作流）都得有，且JSON部分能正常解析；其次，JSON能否成功转换为YAML文件；第三，工作流中声明的变量是否与预先定义的参考变量完全一致；第四，节点选择、设计原则和工作流三个部分在逻辑上是否互相一致，而且任务要求必须使用的关键节点是否都出现在了节点选择中。这四步全部通过，才算"格式合格"，才有资格被导入平台运行。
解决率衡量的是第二阶段——工作流真正运行后能不能完成任务。这一步又分两个检验：先看工作流运行时有没有报错、有没有产生实际输出；再看输出的内容是否满足指令要求，如果有参考答案的话，还要对照参考答案做语义层面的比较。对于输出中涉及文件的部分（比如生成的图片、音频、Word文档），还会单独检查文件类型是否匹配。
整个评估过程借助DeepSeek-V3模型来完成自动化判断。为了验证这套自动化评估是否可靠，团队还进行了人工抽样对比：在通过率评估上抽取了500个样本，人机一致率达到100%；在解决率评估上抽取了1282个样本，人机一致率也高达98.83%。这说明这套评估体系的可信度相当高。
---
五、15个顶级AI模型的实战成绩，差距令人意外
研究团队在Chat2Workflow基准上测试了15个代表性语言模型，每个模型独立运行三次取平均，最终结果令人大开眼界。
先说闭源模型的情况。在四个闭源模型中，Gemini-3-Pro-Preview表现最为亮眼，在六个场景下的平均通过率达到80.17%，解决率达到71.59%，两项指标均领跑所有模型。Claude-Sonnet-4.5的通过率为71.31%，解决率54.57%；GPT-5.2通过率67.51%，解决率54.71%；而GPT-5.1的表现相对逊色，通过率仅47.26%，解决率39.38%。
开源模型阵营则呈现出明显的参数规模效应。以Qwen-3系列为例，8B参数版本的平均解决率仅6.89%，几乎等同于随机水平；14B版本提升到15.19%；32B版本达到23.35%；235B版本进一步升至27.71%。从8B到235B，随着参数量的持续扩大，解决率稳步攀升，这条趋势线相当清晰。
GLM-4.7和GLM-4.6之间的对比揭示了一个微妙但重要的现象。GLM-4.6经过了专门针对格式规范的后训练，因此在某些场景下通过率确实高于GLM-4.7，比如在企业场景中GLM-4.6的通过率为63.89%，高于GLM-4.7的72.22%（笔误，原文GLM-4.6企业通过率63.89，GLM-4.7为72.22%，按原数据：GLM-4.6企业通过率63.89%，GLM-4.7为72.22%）。然而，当看解决率时，结论完全反转：GLM-4.7在企业场景的解决率为47.22%，而GLM-4.6仅有24.07%。这个现象说明，光靠训练让模型输出更符合格式规范，并不等于让工作流真正能解决问题——格式正确只是必要条件，不是充分条件。
思维型（Thinking）模型与指令型（Instruct）模型的对比同样耐人寻味。Kimi-K2-Thinking在全部六个场景下的解决率均高于Kimi-K2-Instruct，平均解决率分别为43.46%和31.08%。类似地，Qwen-3-235B-A22B的平均解决率（27.71%）高于参数量更大但不具备推理机制的Qwen-3-Coder-480B-A35B-Instruct（26.44%）。也就是说，让AI在给出答案之前多"想一想"，对工作流生成质量的帮助相当显著。
通过率与解决率之间的差距是另一个值得关注的现象。几乎所有模型的解决率都低于通过率，差距最大的是GLM-4.6，两者之间的平均差距高达20.96%。在教育场景这个极端情况下，GLM-4.6的通过率达到72.73%，解决率却只有29.29%，差距超过43个百分点。这说明，有相当比例的工作流在格式上完全合规，能成功导入平台，但运行之后根本无法完成实际任务——就像一辆外观完好无损、发动机却动不了的汽车。
---
六、随着对话轮次增加，AI的状态会怎样变化
Chat2Workflow的另一个独特设计是多轮对话。研究团队追踪了15个模型在前三轮对话中的表现变化趋势，结果几乎是一边倒的：随着轮次增加，绝大多数模型的通过率和解决率都在下降。
这个现象背后的逻辑并不复杂。每过一轮，模型需要处理的历史信息就多一份，需要理解的累积需求就复杂一层，需要在已有工作流基础上做出的精准修改就多一处。就像在一栋楼上不断加盖新楼层，每加一层，地基和结构所承受的压力就更大一点，稍有不慎就会出现裂缝。
不过，研究者也注意到一个稍显乐观的规律：随着轮次推进，大多数模型的性能下降幅度也在逐渐收窄。换句话说，第一轮到第二轮之间的性能跌落，往往大于第二轮到第三轮之间的跌落。对此，研究者提出了一个合理的解释：能熬过第一轮筛选、在第二轮仍然输出合格工作流的那些"案例"，本身就已经经历了一次自然淘汰，留下来的是质量较高的样本；这些样本在继续演化时，天然具备更强的抗压能力，因此性能衰减的速度放缓了。
---
七、一个典型失败案例：教育场景的工作流竞技场
为了让抽象的数据变得具体，研究团队选取了教育场景中的"学习规划师"（StudyPlanner）任务作为案例分析，重点剖析了第二轮任务的执行情况。
第二轮任务要求AI在第一轮"生成自学计划"的基础上，进一步构建一个能自动生成完整教程的工作流：先生成课程大纲，再按章节迭代生成每个知识点的详细内容，最后将所有内容整合成一份完整教程输出。
三个模型的表现形成了鲜明对比。Kimi-K2-Instruct生成的工作流在格式上看起来没什么大问题，却在边连接关系上犯了一个根本性错误。它在"迭代节点"（相当于一个循环执行单元）和其内部的"迭代开始节点"之间设置了一条边连接，而正确的做法是两者之间只存在包含关系，不存在连接关系——这个区别在节点文档中有明确说明，但模型没能正确理解。结果，这个看起来格式完整的工作流根本无法运行。
GLM-4.6则犯了另一类错误：它在节点选择部分没有声明"代码节点"和"迭代开始节点"，但在实际的工作流JSON中却用到了这两个节点。这就像一个厨师在采购清单上没有写鸡蛋，却在烹饪时偷偷用了两个鸡蛋——前后不一致，逻辑上自相矛盾，最终导致评估判定为不合格。
GPT-5.2则是这一轮的优等生，它生成了格式正确、逻辑一致、能成功运行的工作流，并且在实际测试中成功解决了输入的任务。研究者还展示了GPT-5.2在Dify和Coze两个平台上生成的工作流截图，从截图中可以看到，整个流程图包含了参数提取器、大语言模型、迭代、模板等多个节点，逻辑链条清晰，确实是一个可以真正部署使用的完整工作流。
---
八、加上"侦探模式"之后，AI能提升多少
面对上述种种失败模式，研究团队提出了一个"错误驱动的智能体框架"，试图探索AI在这个任务上的性能上界。
这个框架的运作方式类似于给AI配备了一套专门针对这个任务的工具包和操作规程。框架基于OpenCode平台（版本1.3.17）实现，核心设计分几个层面展开。
在基础提示层面，框架从零样本提示升级为结构化的"技能文档"（SKILL.md）驱动模式，明确列出工作流生成中的关键规则，包括多轮对话的上下文继承规则和变量引用规则，减少模型在这些细节上出错的概率。
在上下文管理层面，为了防止随着对话轮次增加、历史信息过多导致模型"记性变差"，框架会从前一轮的工作流中动态提取"变量摘要"，将最关键的上下文信息压缩提炼出来，作为补充输入喂给下一轮的生成过程。
最关键的是错误修复机制。框架设计了一个最多尝试5次的重试循环，每次生成后立刻进行结构和语义双重验证。一旦发现问题，框架不是简单地重新生成，而是调用四个专门的"自动修复模块"分别对付四类最常见的错误：代码围栏格式问题（AI输出的文本格式不对）、JSON解码失败（JSON格式语法错误）、拓扑排序违反（节点连接形成了环路，而工作流要求必须是有向无环图）、节点选择不一致（节点选择与实际工作流JSON不匹配）。
结果显示，这套框架对GPT-5.1的通过率提升从47.26%跃升至64.14%，解决率从39.38%提升至44.31%，绝对提升幅度约4.93个百分点；对GPT-5.2，通过率从67.51%提升至78.06%，解决率从54.71%提升至60.05%，绝对提升幅度约5.34个百分点。这些提升数字说明，专门针对这个任务设计的结构化方法确实有效，但即便如此，最好的结果也只是60%的解决率，离真正可靠的工业级水平还有相当距离。
---
九、这项研究的边界在哪里，未来还有多少路要走
研究团队在论文中坦诚地说明了Chat2Workflow目前的几个局限性，这种诚实恰恰让整项研究更加可信。
首先是规模问题。27个任务、79轮指令，对于系统性研究来说已经相当扎实，但现实世界中业务流程的复杂度和多样性几乎是无穷无尽的，这套数据集无法穷举所有情况。
其次是节点简化问题。为了让任务可执行，团队对每个节点的输入输出接口进行了简化，只保留了主要参数，次要参数设为默认值。但在真实部署中，很多复杂的业务场景需要精细调整那些"次要参数"，这部分复杂度目前还没有被纳入评估。
第三是节点种类有限的问题。20种节点类型能覆盖大多数标准场景，但Dify这样的平台实际上提供了数百种社区扩展节点，很多更复杂的真实业务需要用到那些目前不在测试范围内的特殊节点。
尽管如此，这项研究的意义在于，它提供了第一个系统性的、可重复验证的测试基准，让研究者和开发者能够客观衡量"AI自动生成工作流"这项能力的真实水平和瓶颈所在。在此之前，这个问题更多停留在定性讨论层面，现在终于有了量化数据可以依据。
---
说到底，Chat2Workflow做的这件事，是在问一个现实得不能再现实的问题：当你对AI说"帮我搭一个自动化工作流"，它能给你一个真正能用的答案，还是只是看起来像那么回事的答案？
研究的结论坦率而清醒。即便是目前最顶级的大语言模型，也只能在大约七成的情况下给出"格式正确"的工作流，而真正"能运行、能解决问题"的比例更低。在开发者这个场景下，所有模型的表现都尤其糟糕——这里涉及的逻辑最为复杂，对节点之间交互关系的理解要求最高。随着用户需求一轮轮演变，AI的性能还会进一步下滑，就像一个在嘈杂环境里边听边记、越记越乱的速记员。
加上专门设计的智能体框架之后，情况有所改善，但提升幅度仍然有限。这意味着，单纯依靠更大模型或更复杂的提示词，可能还不足以真正解决这个问题，未来可能需要在结构化推理、工具知识表示以及工作流专用训练等方向上做出更深入的探索。
对于普通用户来说，这项研究的直接意义是：在可预见的未来，让AI全自动搭建生产级工作流还需要一段时间，但AI作为辅助工具、帮助工程师减少重复劳动、加速原型验证，已经具备了相当的可行性。如果你对这个领域感兴趣，可以通过arXiv编号2504.19667查阅完整论文，或访问研究团队开放的GitHub仓库（github.com/zjunlp/Chat2Workflow）获取数据集和代码。
---
Q&A
Q1：Chat2Workflow基准测试中的"通过率"和"解决率"有什么区别？
A：通过率衡量的是AI生成的工作流在"格式"上是否合格，包括JSON能否正确解析、能否转换成YAML文件、节点声明是否前后一致等；解决率则衡量工作流真正运行后能不能完成任务。研究发现，通过率总是高于解决率，最极端的情况下两者差距超过43个百分点，说明格式合规只是工作流能用的必要条件，而非充分条件。
Q2：测试中哪个AI模型在自动生成工作流方面表现最好？
A：在Chat2Workflow基准上，Gemini-3-Pro-Preview综合表现最优，平均通过率80.17%，平均解决率71.59%，是所有15个测试模型中最高的。开源模型中GLM-4.7解决率最高，达55.98%。但即便是最好的模型，解决率也没有突破75%，距离真正可靠的工业级部署仍有明显差距。
Q3：为什么AI生成工作流的效果随着对话轮次增加而变差？
A：每增加一轮对话，AI需要理解的历史信息就更多，需要在已有工作流基础上做的精准修改也更复杂。简单来说，AI需要同时记住旧需求、理解新需求、还要保证修改后的工作流整体逻辑不出错，这三件事叠加在一起，出错的概率自然上升。研究团队观察到，几乎所有模型的性能都随轮次稳步下滑，这被认为是该任务中长程指令跟随能力的关键瓶颈。