自然语言直接生成 Dify 工作流：ChatDify 三智能体在 100 项生产场景任务上把成功率提到 0.96
核心概要
在 Dify 这类平台上搭建 LLM 工作流，过去要手动挑选节点、填写参数并连线，既费时又容易出错。ChatDify 把这一过程交给规划、执行、审查三个智能体协作完成：规划智能体把自然语言需求拆成有向无环图，执行智能体按节点模式生成参数并编译成 Dify 的 DSL，审查智能体用静态检查和沙箱运行加 LLM 评判做闭环修正。在 100 项取自生产场景的 Dify 任务上，以 Qwen-3.7、GLM-5.1、DeepSeek-v4 为后端，成功率分别为 0.96、0.91、0.75，高于带动态修复的零样本基线。
深度剖析
用户只需用自然语言描述目标，ChatDify 就能生成可在 Dify 上直接执行的完整工作流，包括节点选择、参数填写和节点间连线。 此前用户必须在 Dify 界面里逐个手动选择、连接并配置节点，这要求同时理解任务逻辑和平台的具体功能，工作流越复杂认知负担越重。 在 100 项取自生产场景、覆盖 8 个类别的 Dify 任务上，ChatDify 在 Qwen-3.7、GLM-5.1、DeepSeek-v4 三个后端上的成功率分别为 0.96、0.91、0.75，而带动态修复的零样本基线为 0.67、0.45、0.36。
三个智能体分工对应工作流必须同时满足的三个层面：结构、配置和语义。 规划智能体把请求拆成功能块，并从 Dify 知识库检索相近的工作流子图模板，再实例化为具体节点和依赖关系，形成有向无环图计划。 执行智能体依据上游节点的输出上下文生成参数，并按节点模式约束编译成 Dify DSL；审查智能体先做拓扑、变量类型和模式合规的静态检查，再在沙箱中端到端运行并用 LLM 评判语义是否符合请求，不合格则回到修复循环。
可靠性主要来自完整的规划—执行—审查流程，而不只是运行时的反复修复。 去掉动态运行探测后，三个后端的成功率分别从 0.96 降到 0.73、从 0.91 降到 0.71、从 0.75 降到 0.44；静态检查则额外带来 3 到 8 个百分点的提升。 修复轮次分析显示，大部分收益在前两轮出现，例如 Qwen-3.7 从 0.73 升到 0.95，第三轮收益更小而 token 成本更高。
启示与展望
评估限定在 Dify v1.11.2 平台和 100 项取自生产场景的 Dify 任务上，覆盖 8 个类别，后端为 Qwen-3.7 max、GLM-5.1 和 DeepSeek-v4 pro。作者指出，迁移到其他工作流平台需要替换知识库、节点模式和沙箱执行器，但这些组件在规划—执行—审查设计中是模块化的。
成功率同时衡量执行成功与 LLM 判定的语义成功，并不完全反映人对任务完成的判断；每次检查只依赖一个合成测试用例，且评判者与生成器共用同一骨干模型，成功率可能高估真实水平。作者的手工抽查发现多数工作流表现符合预期，但更严格的评估需要多个测试用例和独立标注者。动态探测与 LLM 评判也带来额外 token 成本，输入 token 占报告总量的 80% 到 90%。