ComfyUI 深度调研：AI 创作工具为什么会长成节点图

原文链接：Comfy-Org/ComfyUI

大家好，我是若风。

最近我重新看了一遍 Comfy-Org/ComfyUI 这个项目。

说实话，我以前对 ComfyUI 的理解也有点单薄：一个给 Stable Diffusion 用的节点式 GUI，适合喜欢折腾工作流的人，把模型、采样器、提示词、ControlNet、VAE、LoRA 一路连起来，最后出图。

这个理解没错，但现在已经明显不够用了。

这次把 README、源码目录、server.py、execution.py、comfy_execution/graph.py、openapi.yaml 和 release 信息放在一起看，我的感受是：ComfyUI 已经不是一个单纯的生图界面，而是在变成 AI 内容创作的工作流引擎。

这个变化很关键。

因为 AI 创作工具正在从「单模型单任务」走向「多模型多步骤」。一张图可能先文生图，再局部重绘，再上采样，再换脸，再进视频模型，再补音频。一个产品图可能要走品牌风格、背景生成、局部修复、尺寸适配、批量导出。一个视频镜头可能要串图像模型、视频模型、3D 模型和外部 API。

如果工具只提供一个输入框，它很快就会被复杂需求撑爆。

ComfyUI 的答案是：把 AI 创作拆成节点，把节点连成图，把图交给执行引擎跑。

截至 2026 年 5 月 30 日，我通过 GitHub API 看到 Comfy-Org/ComfyUI 有约 114.9k Star、13.4k Fork，主语言是 Python，许可证是 GPL-3.0，最新 release 是 v0.22.0。它的 README 也已经把定位改得很明确：ComfyUI 面向视觉专业用户，强调对每个模型、参数和输出的控制，并且支持图片、视频、3D、音频和 API 节点。

所以这篇文章想回答的，不是「ComfyUI 怎么安装」，而是一个更本质的问题：

为什么 AI 创作工具最后会长成节点图？以及 ComfyUI 的工程设计到底强在哪里？

先说结论

如果只用一句话概括 ComfyUI，我会这么说：

ComfyUI 是一套围绕 AI 创作工作流设计的节点图执行系统，GUI 只是入口，真正的核心是图、节点、队列、缓存和模型资产管理。

它做对了 5 件事：

这也是 ComfyUI 和很多「提示词框 + 参数面板」工具最大的差异。

普通界面更像相机：你调参数，按快门，得到结果。

ComfyUI 更像合成软件：你搭一条流水线，然后让系统按图执行。

这听起来更复杂，但它换来的是控制力。

它到底解决了什么问题

AI 创作一开始看起来很简单。

输入 prompt，选模型，点 generate。

但只要真实做过几轮，你就会发现事情很快变复杂。

你想固定人物一致性，要接 LoRA 或 IP-Adapter。你想控制姿势，要接 ControlNet。你想重绘局部，要有 mask。你想做高清图，要先低分辨率生成，再 latent upscale，再二次采样。你想做视频，要从图片、关键帧、运动控制、视频模型一路串起来。

这时候传统表单式 UI 会出现一个问题：参数越来越多，但结构越来越不清楚。

所有能力都堆在面板里，用户看不到数据是怎么流动的，也很难复用其中一段。

节点图的价值就在这里。

它把「一次生成」拆成多个明确步骤：

• 模型从哪里加载
• prompt 怎么编码
• latent 怎么初始化
• sampler 怎么运行
• VAE 怎么解码
• 图片怎么保存
• 中间哪些部分可以缓存
• 哪些节点变化以后需要重新执行

这不是视觉上的花活，而是 AI 工作流天然需要的表达方式。

因为生成式 AI 的复杂度，不在单个按钮，而在步骤之间的依赖关系。

节点为什么是 ComfyUI 的基本单位

ComfyUI 源码里最值得看的，是它如何把节点定义成可执行单元。

在 nodes.py 里，大量节点都会声明自己的 INPUT_TYPES、RETURN_TYPES 和执行函数。也就是说，一个节点不是画布上的装饰方块，而是一个有输入、输出、类型约束和运行逻辑的 Python 类。

这件事很重要。

因为它让 ComfyUI 的 UI 图和后端执行图可以共享同一套语义。

前端看到的是节点、端口、连线；后端看到的是节点 id、class type、inputs 和依赖关系。用户拖出来的图，最终可以变成 JSON prompt 交给服务器执行。

这也是为什么 ComfyUI 的工作流可以保存成 JSON，也可以从生成的 PNG、WebP、FLAC 里恢复。图不是临时界面状态，而是创作过程本身。

换句话说，ComfyUI 保存的不只是结果。

它保存的是「结果是怎么来的」。

这对 AI 创作特别关键。因为 AI 生成的可复现性很弱，很多时候你真正想留下来的不是一张图，而是模型、seed、采样器、prompt、后处理链路和资源路径的完整组合。

图执行：不是从左到右跑一遍

如果只是把节点按顺序跑一遍，ComfyUI 就没那么有意思了。

真正关键的是执行引擎。

在 comfy_execution/graph.py 里，可以看到 DynamicPrompt、TopologicalSort、ExecutionList 这些抽象。它们处理的是一个更底层的问题：当用户给出一张图，系统如何知道哪些节点要先跑，哪些节点在等输入，哪些节点已经有缓存，哪些节点是动态展开出来的。

这背后其实是一个有向图执行问题。

比如保存图片节点依赖 VAE 解码，VAE 解码依赖 sampler 输出 latent，sampler 又依赖模型、正向条件、负向条件和初始 latent。只要其中一环没准备好，下游就不能执行。

ComfyUI 不是靠界面上的位置判断顺序，而是根据连线和输入依赖做拓扑调度。

README 里也提到一个很关键的特性：只执行有正确输入的输出部分，并且如果两次提交之间只有最后一段变化，就只重新执行变化及其依赖的部分。

这就是节点图相对普通脚本的优势。

你不是每次都从头跑完整流程，而是让执行器理解依赖，把没变的中间结果尽量复用。

对于大模型推理来说，这不是小优化。

一次视频生成、一次高清修复、一次多 ControlNet 工作流，都可能非常贵。能少跑一步，就是真的少烧显存、少等时间。

缓存机制：ComfyUI 的隐藏护城河

很多人用 ComfyUI，直觉上会觉得它「可控」。

但从工程角度看，ComfyUI 的一个核心价值是：它让可控和可计算绑在了一起。

在 execution.py 里，可以看到 ComfyUI 有多种缓存策略，比如经典缓存、LRU、RAM pressure cache、空缓存。节点执行时，它会根据输入签名、节点 id、输出对象等信息决定哪些结果可以复用。

这件事在 AI 工作流里特别难。

因为节点输出可能是 tensor、模型对象、latent、图片、mask，也可能是更复杂的中间对象。它们有的很大，有的绑定 GPU 内存，有的不能简单序列化。

ComfyUI 的做法不是把所有东西都落盘，而是在执行期间维护对象缓存和输出缓存，结合图依赖判断复用边界。

这也是为什么它更像一个执行引擎，而不是一个普通 GUI。

GUI 负责让你搭图。

执行引擎负责判断这张图怎么跑才不浪费。

后端 API：从个人工具走向生产管线

ComfyUI 的另一个变化，是 API 叙事越来越明显。

项目根目录里有 openapi.yaml，里面把本地 ComfyUI API 描述得很完整：提交 workflow、查询队列、查看历史、上传文件、查看文件、查询节点定义、模型列表、用户设置、WebSocket 实时进度等。

最核心的路径是 /api/prompt 和 /ws。

你可以把 workflow 作为 JSON 交给 /api/prompt，服务器验证图以后返回 prompt_id，再通过 WebSocket 监听执行进度、节点状态和输出消息。

这件事意味着 ComfyUI 可以进入很多 GUI 之外的场景：

• 内部工具批量生成产品图
• 电商素材流水线自动跑多个尺寸
• 视频团队把固定工作流封装成按钮
• 后端服务根据用户输入拼 workflow
• AI Agent 调用 ComfyUI 作为视觉生成后端

这里有个很现实的判断：如果一个 AI 创作工具没有 API，它很难进入生产系统。

因为生产系统需要排队、重试、状态查询、文件上传、权限隔离、日志和结果回收。单纯 UI 很难承载这些东西。

ComfyUI 现在的路线，是把 GUI 和 API 都建立在同一套图执行能力上。

这比「先做一个界面，再补几个接口」要健康得多。

前端拆分：ComfyUI 不再把自己锁在单仓库里

README 里还有一个容易被忽略的信息：ComfyUI 已经把新前端迁移到了单独的 ComfyUI_frontend 仓库，核心仓库通过 comfyui-frontend-package 依赖拿到编译后的前端包。

requirements.txt 里也能看到：

comfyui-frontend-package==1.44.19
comfyui-workflow-templates==0.9.91
comfyui-embedded-docs==0.5.1

这个拆分很有意思。

它说明 ComfyUI 已经不再是一个「Python 后端顺手塞一点静态页面」的项目，而是变成了 Core、Frontend、Desktop、Cloud、Templates、Docs 多个部分协同的产品体系。

README 的 Release Process 也提到三个相互关联的仓库：

• ComfyUI Core：负责稳定核心版本
• ComfyUI Desktop：基于稳定 core 构建桌面版
• ComfyUI Frontend：前端独立开发，再周期性合入 core

这套结构其实很像成熟开源产品的演进路径。

早期项目可以一个仓库全包，跑起来最重要。

等用户规模、插件生态和发布节奏上来以后，前端体验、核心执行、桌面分发、云服务就会有不同的迭代速度。硬塞在一起，最后会互相拖累。

模型资产管理：节点图之外的第二个战场

做 AI 创作工具，最麻烦的往往不是 UI。

是模型文件。

checkpoint、safetensors、VAE、CLIP、LoRA、ControlNet、upscale model、embedding，每类模型都有自己的目录习惯。很多用户还会同时装 Automatic1111、InvokeAI、ComfyUI、Fooocus，不想重复存一堆几十 GB 的权重。

ComfyUI 的 folder_paths.py 和 extra_model_paths.yaml.example 就是在解决这个问题。

它允许用户配置额外模型搜索路径，把不同工具的模型资产复用起来。main.py 启动时也会处理 extra model paths、output directory、input directory、user directory，并把 checkpoints、clip、vae、diffusion_models、loras 等路径注册进去。

这件事看起来很琐碎，但其实是 AI 创作工具能不能长期使用的关键。

因为模型生态会不断膨胀。

今天是 SDXL、Flux、Qwen Image，明天是新的 video model、3D model、audio model。工具如果没有稳定的资产组织方式，就会变成一个巨大的文件夹迷宫。

ComfyUI 用节点图处理计算流，用模型路径处理资产流。

这两条线合起来，才是完整的工作流系统。

API Nodes：开源模型和闭源模型开始接到同一张图上

README 里有一句信息量很大：ComfyUI 原生支持最新开源模型，同时 API nodes 可以访问 Nano Banana、Seedance、Hunyuan3D 等闭源或外部模型能力。

这意味着 ComfyUI 的节点图正在从本地推理扩展到混合推理。

过去我们理解 ComfyUI，经常默认它是「本地显卡 + 开源模型」工具。

但今天的 AI 创作已经不是这样了。

有些步骤适合本地跑，比如稳定的 SDXL/Flux 工作流、私有素材、可控批量生成。有些步骤更适合云 API，比如昂贵视频模型、3D 生成、专有能力、临时高峰算力。

如果这些能力都能变成节点，用户就不用在多个产品之间手动搬运结果。

一张图里，本地节点和 API 节点可以共同组成流程。

这可能是 ComfyUI 后面最重要的方向之一：它不只是本地开源模型的界面，而是 AI 模型能力的编排层。

安全边界：本地工具也要防网页攻击

看 server.py 时，我注意到一个细节：ComfyUI 对本地服务的请求来源做了防护。

代码里有 create_origin_only_middleware，会检查 Sec-Fetch-Site、Host 和 Origin。注释里解释得很直白：防止随机网站向 127.0.0.1 上的 ComfyUI 队列提交 workflow。

这个细节值得单独拿出来说。

很多本地 AI 工具默认跑在 localhost，大家容易觉得「反正只在本机，不用太在意安全」。

但浏览器世界里，恶意网页能不能请求本地端口，是一个真实问题。尤其 ComfyUI 这种工具，如果被外部网页诱导提交任务，轻则占用显卡，重则可能处理本地文件或调用带密钥的 API nodes。

ComfyUI 不是把自己当成玩具脚本来写，它已经开始按长期运行的本地服务来考虑安全边界。

这也是它工程化程度提高的标志。

它适合什么，不适合什么

ComfyUI 很强，但它不是所有人的最佳入口。

它特别适合这几类场景：

• 需要精细控制模型、参数和中间结果
• 需要把工作流保存、复用、分享和版本化
• 需要混合图片、视频、3D、音频或外部 API
• 需要用 API 把生成能力接入内部系统
• 需要批量生产并减少重复推理成本

它不太适合这几类场景：

• 只想输入一句话快速出图
• 不想理解模型文件、节点连接和显存限制
• 需要严格权限、多租户、安全审计的企业云平台
• 需要高度封装、不暴露底层参数的消费级产品

这不是缺点，而是定位。

ComfyUI 的本质是把复杂性摊开，让你能控制它。

如果用户根本不想看复杂性，Midjourney 或某些封装型工具会更舒服。

但如果用户要把 AI 创作变成稳定流程，ComfyUI 的节点图反而会越来越有优势。

我最看好的方向

我看完 ComfyUI 后，最看好的不是「它又支持了多少新模型」。

模型支持当然重要，但那更像持续跟进生态。

我真正看好的是 3 个方向。

第一，App Mode。

README 里提到，复杂工作流可以通过 App Mode 暴露成简单 UI。这个方向非常关键。因为节点图适合搭建者，但不一定适合最终使用者。最理想的状态是：专家用节点图搭流程，普通用户用 App Mode 填少量参数。

第二，API 化和 OpenAPI 化。

一旦 workflow 可以稳定通过 API 提交、监听、查询、回收结果，ComfyUI 就能从桌面工具进入自动化生产。很多公司内部的 AI 素材系统，真正需要的不是重新发明一个推理后端，而是有一个能跑复杂视觉 workflow 的执行层。

第三，本地和云的混合节点。

本地模型保护隐私、降低边际成本；云模型提供最新能力和弹性算力。ComfyUI 如果能把两者统一进节点图，就会成为一个非常自然的 AI 创作编排器。

这三个方向合在一起，ComfyUI 的形态会很清楚：

搭建者看到节点图。

使用者看到 App。

系统看到 API。

底层看到本地和云的混合模型能力。

最后

ComfyUI 能火，不只是因为它赶上了 Stable Diffusion 和开源生图浪潮。

更深层的原因是：它选对了表达复杂性的方式。

AI 创作不是一次函数调用，而是一张图。

模型是节点，prompt 是节点，采样器是节点，VAE 是节点，ControlNet 是节点，上传、保存、预览、API 调用也都可以是节点。节点之间的连线，就是创作过程里的因果关系。

当一个领域的复杂度来自依赖关系，节点图就会变得很自然。

这也是我这次重新看 ComfyUI 最大的感受：

ComfyUI 表面上是 AI 生图 GUI，实际上是在把 AI 创作从「调参数」推进到「搭系统」。

如果未来视觉内容生产真的进入多模型、多步骤、多角色协作的时代，ComfyUI 这种工作流引擎会越来越像基础设施，而不只是一个好用的开源工具。