Chat2Workflow：基于自然语言生成可执行可视化工作流的基准测试 Chat2Workflow: A Benchmark for Generating Executable Visual Workflows with Natural Language
首个多轮对话生成Dify/Coze工作流的评测基准，覆盖6大领域237实例
前置知识
可视化工作流(Visual Workflow)
可视化工作流是用有向无环图(DAG)把LLM节点、HTTP请求、If-Else分支等连接起来的编排范式，平台(Dify、Coze)按图自动执行。边 $E=\{(v_i, p, v_j)\}$ 上的 $p \in \mathbb{Z}_{\geq 0}$ 标端口号，确保数据沿指定路径流动。
本文核心是评估LLM从自然语言直接生成此类可部署DAG的能力，节点、边、端口是任务形式化 $G(V,E) \leftarrow M_\theta(q,H)$ 的基础
Chain-of-Thought与结构化输出
CoT引导LLM先生成推理步骤再给最终答案，可显著提升复杂任务表现。本文把它具化为三段标签：$$(选节点)、$$(设计意图)、$$(JSON输出)，最后规则化转为YAML。
三段式CoT是本文方法核心，简化了LLM的直接生成难度并兼顾了可执行性，是任务形式化 $G \leftarrow r \leftarrow \{\hat{V}, p, r\}$ 的关键
ReAct与Agentic Workflow分野
ReAct Agent动态交替推理与行动、灵活但稳定性欠佳；Agentic Workflow预定义DAG、由平台按图执行、以灵活性换可靠性。70%真实部署采用后者，代表平台即Dify/Coze。
本文聚焦Agentic Workflow自动生成，理解二者差异才能体会'resolve=真正跑通'这一评估为何远比普通agent评测复杂
LLM-as-a-Judge评测
用强LLM(GPT-5.1等)替代人类对模型输出做格式合规与功能正确判断。本文在Pass阶段审355实例、Resolve阶段审463实例，并经三人一致复核，最终一致率达97.18%/93.09%。
工作流无法用简单指标评估，必须依赖LLM判断格式/逻辑一致性，理解这种弱监督评测的设计权衡是把握实验方法的关键
研究动机
工业部署中主流agent范式是可执行可视化工作流(Dify/Coze平台)，通过DAG把LLM、HTTP、If-Else、迭代器节点连起来执行。相比ReAct更可靠但几乎全靠人工搭建：开发者设计拓扑、写提示词、随需求变化反复修订，成本高、易出错。超70%真实agent部署采用未微调LLM+显式工作流。但'自然语言能否直接生成工作流'缺系统研究：实际需求复杂且隐含，难以推断控制流；用户需求随对话轮次变化，需增量修改并保持一致性。现有自动化评测(ToolBench、ShortcutsBench等)停留在抽象表达层面，仅检查关键元素，不考虑真实执行效果、节点结构依赖或平台约束，更忽略多轮变更场景，无法回答'LLM能否生成真正能跑、可部署的工作流'这一工业级问题。
本文的目标是本文的具体目标有三层：(1)构建首个聚焦'自然语言生成可执行可视化工作流'的基准Chat2Workflow，共覆盖Research、Document、Enterprise、Developer、Education、AIGC六大领域，包含27个任务、79条多轮指令、237个测试实例(每条指令3个测试用例)，全面覆盖从初版搭建到增量修改的真实场景；(2)设计两阶段渐进式评估协议——Pass Rate衡量格式与结构合规(能否解析、转换、变量一致、逻辑正确)，Resolve Rate衡量在Dify平台上真实执行后的功能正确性，并采用LLM-as-a-Judge配合人工三方一致复核保证评测可靠性；(3)在4个闭源+11个开源、共15个代表性模型上做系统评估，量化当前LLM在工作流生成任务上的能力边界，并提出一个错误驱动的agentic baseline探索性能上限，为后续工业级自动化研究奠定基础。
与已有工作不同的是，本文的独特切入角度是'真实可部署性'与'多轮演化'两个被现有基准系统性忽略的维度。已有工作(如AutoFlow、AFlow、ComfyUI-R1、FlowAgent)在工作流自动化方面多停留在单轮、抽象表达层，缺少'生成后真去Dify/Coze执行并对比真实输出'的端到端评测；而Chat2Workflow的关键差异在于把benchmark直接嵌入了Dify 1.9.2平台——所有生成的工作流都被规则化转换为YAML、上传执行、对比真实输出，得到一个能反映部署可行性的Resolve Rate指标。同时，本文把多轮对话作为一阶公民设计：27个任务每轮都以前一轮为基础进行增删改，要求模型维护长程历史与变量一致性，并通过逐轮Pass/Resolve曲线揭示'随轮次增加性能如何退化'这一工业实际痛点。配合四类错误归因(Format/Graph/Semantics/Consistency)与一个含Auto-Repair和5次重试的agentic baseline，本文既是诊断工具也是改进起点。
核心方法
任务形式化为多轮交互：给当前指令 $q$ 与历史 $H$，让模型 $M_\theta$ 生成工作流 $G(V,E)$，$V$ 是预填参数节点集，$E=\{(v_i, p, v_j)\}$ 中 $p \in \mathbb{Z}_{\geq 0}$ 为端口号。直接生成完整工作流难，用三段CoT：$$(选节点 $\hat{V}$)、$$(理由 $p$)、$$(JSON $r$)，再规则化转为Dify可导入YAML，即 $G \leftarrow r \leftarrow \{\hat{V}, p, r\} \leftarrow M_\theta(q,H)$。方法分三块：(1)节点知识库——挑20种高频节点按五元组预定义为系统提示；(2)基准构造——按Prune→Filter→Cluster→Abstract→Chain→Instantiate六阶段构建多轮指令；(3)双轨评估——Pass走格式检查、Resolve走Dify真实执行，agentic baseline做5次重试+Auto-Repair。
核心创新是'CoT标签+简化JSON+真实执行+错误驱动修复'四合一。**(a)** 三段CoT先'点菜'再'写菜谱'后'出菜'，简化JSON只暴露主变量，大幅降低单步复杂度与格式维数。**(b)** Pass/Resolve解耦揭示'格式合规≠执行成功'——GLM-4.6平均resolve(35.02%)仅pass(62.45%)的56%，Education场景低47.48pp。**(c)** 首次在Dify 1.9.2真实平台执行评测，而AFlow/FlowAgent仅比对抽象结构。**(d)** 错误驱动baseline动态提取Variable Summaries抑制上下文衰减，并对四类高频错误(冗余code fence、JSON解码、违反拓扑排序、节点选择与workflow不一致)做Auto-Repair。增益：GPT-5.2 resolve 47.40%→53.45%(+6.05%)、pass 67.51%→78.06%(+10.55%)；GPT-5.1 resolve 34.46%→39.24%(+4.78%)、pass 47.26%→64.14%(+16.88%)。
方法步骤详情
五步流水线。**Step 1(节点知识库)**：从Dify/Coze文档与GitHub提炼20高频节点，每条抽象为五元组($$/$$/$$/$$/$$)，简化I/O(主变量必填、次变量默认)。**Step 2(数据构造)**：Prune替换不支持节点；Filter丢弃不可测；Cluster聚六大场景(Research/Document/Enterprise/Developer/Education/AIGC)；Chain志愿者手工串2–4轮指令；Instantiate生3测试用例(相关HF数据、真实网络、LLM合成)。**Step 3(生成)**：以节点知识库为提示按三段CoT输出。**Step 4(执行)**：代码框架把JSON转Dify原生YAML上传。**Step 5(评估)**：Pass做格式/转换/变量一致性/LLM-judge；Resolve先Dify执行再LLM-judge。三人复核一致率97.18%/93.09%。
技术新颖性
新颖性体现在四个层面。**(1)任务形式化清晰度**：把多轮工作流生成显式建模为 $G(V,E) \leftarrow M_\theta(q,H)$ 与加入CoT中间表示的 $G(V,E) \leftarrow r \leftarrow \{\hat{V}, p, r\} \leftarrow M_\theta(q,H)$，让Pass/Resolve差异有了数学边界。**(2)数据集构造系统性**：六阶段流水线把生产配置系统降维为可评测多轮指令，比AFlow随机采样或FlowAgent人工模板更真实。**(3)双轨评估严谨性**：Pass Rate四步检查+Resolve Rate真实执行，LLM-as-a-Judge配三人一致复核，既保证可扩展又兼顾可靠性，首次量化'格式合规≠执行正确'。**(4)错误驱动agentic baseline**：5次重试+Auto-Repair是首个针对工作流的'反思式'修复范式，通过动态Variable Summaries抑制上下文衰减，绝对提升resolve 4.78–6.05pp。这些组合让Chat2Workflow既是评测基准也是改进起点。
实验结果
15模型评测核心发现：(1)**Pass-Resolve差距普遍**——GLM-4.6平均差27.43pp(Education 47.48pp)，Kimi-K2-Instruct差距最小(11.68pp)但绝对差。(2)**能力上限远未达工业可用**——最强闭源Gemini仅60.20% resolve，开源GLM-4.7仅46.55%；Developer场景对所有模型最难(最高44.44%)。(3)**规模/对齐/推理影响**——Qwen-3 8B→235B pass 13.92→40.93%、resolve 6.61→24.47%稳定提升；Kimi-K2-Thinking全面优于Instruct，证明显式推理对结构化输出更稳健。(4)**多轮性能退化**——图4显示几乎所有模型随轮次下降。(5)**四维错误诊断**——Format/Graph/Semantics/Consistency。(6)**Agentic baseline增益**——GPT-5.1 +16.88pp pass/+4.78pp resolve，GPT-5.2 +10.55pp/+6.05pp。
查看结构化数据
| 任务 | 指标 | 本文 | 基线 | 提升 |
|---|---|---|---|---|
| Chat2Workflow总平均(全部6领域237实例) | Pass Rate | Gemini-3-Pro-Preview: 80.17% (GPT-5.2: 67.51%, Claude-Sonnet-4.5: 71.31%) | GPT-5.1: 47.26%, Qwen-3-8B: 13.92% | Gemini vs 最弱Qwen-3-8B: +66.25pp; agentic GPT-5.2 vs zero-shot: +10.55pp |
| Chat2Workflow总平均(全部6领域237实例) | Resolve Rate | Gemini-3-Pro-Preview: 60.20% (Claude-Sonnet-4.5: 47.96%, GPT-5.2: 47.40%) | Qwen-3-8B: 6.61%, GPT-5.1: 34.46% | Gemini vs Qwen-3-8B: +53.59pp; agentic GPT-5.2 vs zero-shot: +6.05pp |
| Developer领域(最难点) | Pass / Resolve Rate | Gemini-3-Pro-Preview: 70.83% / 44.44%; GPT-5.2: 70.83% / 38.89% | Qwen-3-8B: 12.50% / 1.39%; Kimi-K2-Instruct: 29.17% / 5.56% | Developer绝对水平最低, 揭示代码/工程类工作流为当前模型短板 |
| Research领域 | Pass / Resolve Rate | Gemini-3-Pro-Preview: 77.78% / 62.96%; Claude-Sonnet-4.5: 68.89% / 56.30% | Qwen-3-8B: 40.00% / 21.48%; Deepseek-V3.2: 51.11% / 40.74% | Research是六领域中相对表现最好的领域, Gemini仍领先GPT-5.1约29.1pp resolve |
| AIGC领域 | Pass / Resolve Rate | Gemini-3-Pro-Preview: 74.08% / 54.32%; GLM-4.7: 70.37% / 50.61% | Qwen-3-8B: 7.41% / 6.79%; GLM-4.6: 64.82% / 39.51% | 开源GLM-4.7在此场景与闭源模型差距较小, 仅落后Gemini约3.7pp |
| 多轮性能退化(Round 1→3) | Resolve Rate趋势 | GPT-5.2: 53.33→50.37→54.55(三轮波动); Kimi-K2-Thinking: 44.44→46.67→? | Kimi-K2-Instruct等多模型在第三轮显著下降(>15pp) | 整体趋势表明长程指令跟随仍是难题, 验证多轮设计必要性 |
局限与改进
作者明确承认三项局限。**其一数据集规模有限**——尽管27任务×79指令×3用例=237实例经严格人工交叉审核，仍难穷尽工业业务流程中近无限的逻辑组合。**其二节点接口被简化**——只暴露主变量的key-value对，次要变量默认填充，可能无法捕捉某些节点所需的复杂参数配置。**其三节点类型仅20种**——覆盖标准场景，但RAG检索、Agent节点、Knowledge Base等Dify 1.x后引入的关键节点仍待纳入。补充观察：**(a)评估协议本身有偏**——GPT-5.1与DeepSeek-V3一致率97.18%/96.62%意味着~3%判例有分歧，Resolve阶段LLM judge偏向'形式合规'而非深度语义，可能高估真实可用性。**(b)多轮失败模式尚未充分建模**——只展示StudyPlanner任务R2失败样例，图4退化曲线缺乏针对性诊断。**(c)开源模型总体偏弱**——最佳开源GLM-4.7的resolve(46.55%)仍比最佳闭源Gemini(60.20%)低13.65pp。
独立分析的弱点
独立分析五点改进方向。(1)**Resolve离工业可用差距大**——最强Gemini仅60.20%。改进：引入形式化验证(SMT求解)做well-formedness预检，对Iteration嵌套做结构证明。(2)**节点仅20种限制表达力**——缺Knowledge Retrieval/Agent/Tool/Rerank等关键节点。改进：扩展50+按'核心-扩展-实验性'分级。(3)**多轮上下文衰减未根本解决**——agentic baseline靠Variable Summaries仅提升4.78–6.05pp。改进：借鉴LLM Compiler的plan-and-execute范式，以diff表达增量。(4)**评判偏形式合规**——semantic/consistency错误隐蔽。改进：专用critic做self-consistency、多模型ensemble、执行轨迹反向归因。(5)**对开源模型不友好**——GLM-4.7比Gemini低13.65pp。改进：发布'开源专版'SKILL.md含few-shot exemplar和self-debug循环。
未来方向
可延伸方向六条。**(1)节点库扩展**——增量纳入Knowledge Retrieval/Tool Agent/Rerank/Workflow Tool，扩展到RAG场景，预计实例数翻倍。**(2)错误驱动的训练信号**——把Auto-Repair轨迹收集为SFT/RLHF数据反哺训练，让模型内化'尝试-纠错'范式以减少重试成本。**(3)形式化约束引入**——把节点功能抽象为precondition/postcondition契约，使LLM生成时受约束求解，类似Code-as-Policies与CoT-to-Code混合路径。**(4)人机协作工作流生成**——既然全自动达60%resolve，探索'AI-first但human-in-the-loop'：模型先生成+自动修复，对剩余失败让用户做最小修改。**(5)跨平台扩展**——当前仅Dify 1.9.2，未来拓展Coze、LangGraph、n8n验证方法在不同YAML schema下的可迁移性。**(6)多模态输入**——目前指令限文本，未来引入视觉编码让模型从示例工作流截图直接反推节点与连线。
复现评估
整体良好但有门槛。**开源**：Chat2Workflow以MIT协议发布在GitHub zjunlp/Chat2Workflow，27任务×79指令×237测试用例全公开；baseline基于OpenCode v1.3.17，SKILL.md与系统提示将整合进仓库；评测脚本与LLM-judge提示(图8/9)公开。但节点库仅20种，扩展需自建。**算力**：模型API可商业接口或开源部署(Qwen-3-{8B,14B,32B,235B,Coder-480B}、GLM-{4.6,4.7}、DeepSeek-V3.{1,2}、Kimi-K2-{Instruct,Thinking})。Resolve需在Dify 1.9.2真实执行——一次benchmark需同时配Dify服务、LLM节点(Qwen-3-Max、Qwen-3-VL-Plus)、文图模型(Z-image-Turbo)与TTS(GPT-4o-mini-TTS)。**一致性**：两阶段97.18%/93.09%可复现。**难度中等偏高**——格式易复现，但Resolve受Dify版本/底层模型/网络影响，建议固定版本号。
论文图表
左侧展示'SciencePopularization'多轮任务的Round 3示例：用户输入requirement变量、模型需输出text与picture；中间展示了模型生成的三段式CoT输出(节点选择、设计原理、JSON工作流)与Dify平台上的可视化DAG；右侧突出'产品级可执行'——生成的工作流可经转换直接部署至Dify/Coze等真实平台。
这是全文核心motivation的可视化锚点，把抽象的'自然语言生成工作流'具象化为输入-推理-输出的端到端pipeline，与文中形式化定义 $G(V,E) \leftarrow M_\theta(q, H)$ 严格对应。
饼图展示237实例在六大领域的不均匀分布：Research占比最大(~22%)突出'知识获取与推理'诉求；Developer(~18.5%)与Document(~18.5%)并列反映工程/结构化场景需求；Education(~14.8%)与Enterprise(~14.8%)体现流程自动化；AIGC(~11.1%)虽小但具创意性。
揭示benchmark覆盖广度与领域偏置，是评估模型跨域能力多样性的关键依据；帮助读者理解为何Developer/AIGC场景对模型最具挑战性。
展示评估pass rate所用的完整system prompt：严格按Rule 1(Ground-Truth节点覆盖)与Rule 2(逻辑一致性 + 双向精确节点匹配)判断node_selection/design_principle/workflow三段之间是否自洽，并以<reason>+<result>双标签格式输出。
展示评测严谨性——通过条款化的判断规则与双向约束(不仅要求gt_nodes⊂selection，还要求selection与workflow节点完全一致)，保证评测可复现且不受模型幻觉干扰。
评估workflow执行结果是否满足当前轮指令的完整提示词，包含queries/input/output/reference_answer四部分输入，五条评估原则(指令对齐、信息利用、输出正确、缺失处理、最终判定)，明确说明'不评判文件部分'。
与Figure 8配套，揭示Resolve Rate评测如何处理真实执行中的多源信息(历史指令、输入变量、输出变量、参考答案)，是LLM-as-a-Judge严谨性的另一面。