过去几周，我一直在思考如何用自然语言来编写 Agent 工作流。起初我的思路是通过 LLM 从自然语言中提炼出可用于表达 Workflow 的 DSL，再由 DSL 来驱动流程引擎。但是在实现过程中，我发现流程引擎的能力与 DSL 的匹配度其实很难把握，其中的根源在于 DSL 本身的设计，往往具有局限性。在使用了 ComfyUI 的工作流之后，我有了新想法，这篇文章就来聊一聊。
什么是 ComfyUI？
在 AIGC 领域，除了 LLM，我想你应该都了解文生图这个领域，而该领域的开源模型 Stable Diffusion 则占据了大半江山。由于开源社区的强大，SD 的生态非常丰富。作为其官方公司 Stability 仅仅发布了底座模型，甚至都没有 UI，而社区目前最主流的两大 UI（WebUI 和 ComfyUI）都非官方作品，却派生了更大的社区空间。（最近新的 UI 工具 forge 也涌现出来，开源真的促进发展。）
WebUI 以配置为操作模式，用户通过选、填来完成模型操作。而 ComfyUI 则是以工作流为操作模式，用户需要通过配置出一个个的 pipeline，通过不同节点和连线来完成模型操作和内容生成。两者各有优势，但在灵活性和深度上，ComfyUI 更胜一筹。如果 WebUI 是一次冒险旅行，那么 ComfyUI 则是一场拉力赛，前者短时间浅尝辄止，后者有些累人但柳暗花明。如果你还没有用过，建议你现在就去尝试一下。
Workflow 本身就是模型
ComfyUI 最吸引人的地方在于它的工作流是可以被分享的，在社区 openart.ai 上，民间高手们分享着自己的工作流，其他小伙伴可以下载这个工作流，并导入到自己的 comfyui 中去，再替换自己的 prompt，就能用相同的参数，生成该工作流预设的效果的图片。
注意，我这里说的是，用相同的参数。
这不就是模型吗？在 comfyui 的每一个节点中，我们需要配置好节点参数，在运行工作流时，这些参数就会生效。以一个 workflow 作为蓝本，对它节点上的参数做细微的调整，就能在原来的图片效果基础上做细微变化，这不就是微调吗？目前，在 comfyui 的生态中已经有近百的插件，也就意味着我们可以构建出非常庞大的 workflow，而通过微调 workflow，以达到自己最满意的效果之后，在后续的全部工作中，我们就可以再次使用这个 workflow，只需要传入不同的初始 prompt 即可。
你看，这样的工作模式，不就是模型的工作模式吗？而 comfyui 的 workflow 导出后，仅仅是一个 json 文件。
移植可能性？
基于这种理念，我发现在 Agent 的工作流搭建中，直接照抄，是完全可以的。在 Stable Diffusion 的模型操作中，comfyui 插件甚至可以调用第三方模型，只要确保节点的输入输出符合 workflow 中的要求即可。
同样的道理，Agent 工作流不也是这样吗？只要确保我们的节点有符合要求的输入输出即可。于是，我有了移植 ComfyUI 到 Agent 工作流创建中的想法。如果可以在现有的 ComfyUI 的基础上，加入 Agent 的工作流搭建能力，不仅可以解决 Agent 工作流编程问题，还能直接将 LLM 和生图模型结合在一起，甚至在 Stable Diffusion 生成视频的能力，构建完全自动化的营销短视频生成、发布流程，也不是不可能。于是我开始研究 ComfyUI 的源码。
然而，结果有点小失望，ComfyUI 和 Stable Diffusion 的绑定比较深，虽然我们可以用它来实现上述的设计，但是当我去尝试封装它的代码时，发现似乎没有什么工作可以做，除非全部重写一遍，把它重构为一个与 SD 解耦的纯 AI 模型工作流，但如果是这样的话，可能要做的工作比较多，最终可能就做出一个类似 coze 一样的平台，成本有点大，感觉没必要。而 ComfyUI 之所以如此流行，还和它的性能有关，或者说它的 python 部分真的很少，以至于整个仓库没多少代码，运行起来当然是有不错的性能表现。
工作流技术揭秘
Workflow 本质上是流程引擎的应用，只不过世界上的流程引擎各有各的怨念，家家有本难念的经，看上去所有的流程都差不太多，但是细细一看，又哪哪都不同。
我们从使用的角度，往往会从图出发来设计 workflow。这也是为什么 comfyui 能流行起来的原因，因为它封闭了流程执行的内部细节，用看得见的流程图来作为直观的操作入口。和 bpmn 这样的业务流程图设计差别巨大，以组织软件运行为目标的流程图往往会以'节点'作为容器来运行某个软件或程序，并以'边'来表达节点之间的数据流向。
