zhaoweiguo 的知识库

Dynamic Workflows 与 Dify / 扣子等低代码工作流平台的区别

7分钟阅读

核心差异成立，但不宜把前者称为”静态 DAG”。Dify/扣子的常规工作流由人预先在画布中定义，运行时按该定义执行；它们也支持条件、循环/批处理、子工作流和工具调用，因此图并不必然是严格 DAG，单次 LLM 节点也可以通过 Agent/工具配置做多步决策。Dynamic Workflows 的独特之处是：Claude 可以针对本次任务在运行时生成或改写 JavaScript 编排程序，把子任务数量、并行拓扑和验证阶段交给程序决定。按 building-effective-agents 的术语，前者默认偏预定义 Workflow，后者可实现 Orchestrator-Workers；这描述的是默认控制权，不是能力上的绝对二分。

维度Dify / 扣子 workflowDynamic Workflows
流程谁设计人在可视化画布上拖节点连线Claude 现场写 JS 脚本，结构由任务决定
表达形式可视化工作流图及其配置；可包含分支、循环和子工作流，平台内部会序列化为定义带顶层 await 的 JavaScript 程序
节点粒度LLM / Agent、知识检索、HTTP、代码、条件、循环/批处理等可组合节点agent() 子 Agent（独立上下文、可使用所授予的工具），加上 JavaScript 控制流
分支与并行流程骨架由设计时定义；可按变量条件、循环或批处理运行可由运行时数据生成任务集合并扇出；受运行时并发和额度限制
中间状态平台变量池 / 会话变量脚本变量，不回流进主上下文
交付物可发布的应用：API endpoint、WebApp、机器人会话内的运行，可按 s 存为斜杠命令复用
目标用户产品/运营/低代码开发者写代码的开发者，任务多为一次性大规模工程作业
执行位置云端服务（或自托管 Dify）本地 CLI / Desktop / SDK
质量模式可显式增加校验、评分、人工审批或多 Agent 节点，质量策略可审计、可固化很适合生成独立验证 Agent；是否做对抗验证仍取决于 Claude 生成的脚本或预置 workflow
复用形态模板市场、应用发布.claude/workflows/ 项目内共享，支持 args 传参

选型：面向外部用户/系统、需要发布 API 或机器人、权限和运行记录治理、并希望把流程确定性固化为产品配置时，优先 Dify/扣子；在本地代码库或研究会话中，任务拆分结构无法预先枚举且需要临时调度大量独立子 Agent 时，优先 Dynamic Workflows。两者可以叠：先用 Dynamic Workflows 探索有效的编排，再把已稳定、可枚举的部分落地为平台工作流。

内置 /deep-research 与平台官方模板：差异最小但没归零

/deep-research 是 Anthropic 预写好的捆绑 workflow，流程骨架不再由当前任务现场设计；这点确实更接近 Dify/扣子中的预制研究模板。差异转为运行时与交付模型，而不是”动态/静态”：

维度/deep-researchDify/扣子同类模板
节点本体可调度具有独立上下文和工具面的子 Agent；具体工具权限和自主程度由 runtime/workflow 定义由画布组合 LLM/Agent、检索、搜索、HTTP、代码和循环等节点；节点内部可有工具调用与多步决策
扇出宽度预置脚本可依据运行时数据展开子 Agent；实际宽度受 workflow 配置、并发和额度限制循环/批处理可遍历运行时数组；并行与并发能力取决于具体平台和工作流配置
验证机制内置交叉检查 + 对每条声明投票，未过检的过滤掉（v2.1.196 起无法核实的标”未验证”而非驳回）需在画布上自己加校验节点和评分逻辑
可改性可查看并保存运行脚本；保存后可用 JavaScript 直接改写控制逻辑在画布和节点配置中改写；可扩展范围受平台节点、插件和代码节点能力约束
交付物会话内报告，无对外 API可发布成 API/WebApp/机器人对外服务
运行位置本地 CLI，消耗自己的订阅额度云端/自托管服务

结论：真正的分界不是”动态 vs 静态”，也不是”自主 Agent vs 单次调用”的二元划分，因为两侧都能组合 Agent、工具、循环与校验。更可靠的边界是编排控制权与交付形态：Dynamic Workflows 把控制流作为 Claude 可运行时生成的本地程序，优化临时探索和大规模 Agent 调度；Dify/扣子把控制流作为人维护的、可视化、可治理、可发布的应用定义，优化稳定业务流程的交付与运营。

相关

关系图谱

反向链接