依赖 API 节点的工作流有什么风险：从三次真实的节点移除说起

2026-08-09

先把结论摆在前面：ComfyUI 的 API 节点不是「装上就一直在」的东西。它是官方 core 里的一层，会随着上游闭源模型的生命周期被增、被删。这不是猜测，是 release notes 里能逐条查到的记录。

如果你的工作流是自己玩，删了大不了改一改；如果这条工作流被排进了某个每天要出活的流程里，那「哪天升级完打不开」就是一个必须提前想过的问题。

一、API 节点在 ComfyUI 里是什么位置

按 v0.31.0（2026-08-08）的官方 README，ComfyUI 的定位是 “The most powerful and modular AI engine for content creation.”，能力范围已经不止画图，Features 里列的是图像生成、图像编辑、视频生成、音视频生成、音频生成、3D 与视觉、文本生成七大类。

在这套体系里，模型来源分成两条腿：

一条腿是本地开源模型，README 说核心完全离线运行，不会下载任何东西，除非你主动要求。
另一条腿就是 API 节点，README 的说法是它提供对闭源模型的访问，举的例子是 Nano Banana、Seedance、Hunyuan3D。

第二条腿的性质和第一条完全不同。本地模型文件躺在你硬盘上，官方升级 core 不会把它删掉；而 API 节点是 core 代码的一部分，指向的是别人家的服务。别人家的服务停了，这个节点留在代码里也就没什么意义了——从下面那几条已经发生的记录看，官方会在后续版本里把它摘掉。

顺带一提，--comfy-api-base 这个参数控制 API 侧的基础地址，默认值是 https://api.comfy.org。这条参数存在本身就说明：API 节点的调用是要出网的。

二、三条真实的移除记录

这是本文最硬的部分，全部来自官方 release notes 条目：

版本	日期	移除条目	PR
v0.28.0	2026-07-15	移除 StabilityAI 节点	PR #14737
v0.28.0	2026-07-15	移除 IdeogramV1 与 IdeogramV2 节点	PR #14712
v0.31.0	2026-08-08	移除 Kling 已退役的 legacy 模型与 Virtual Try-On API	PR #15249

三条记录里，v0.31.0 那条写得最直白：条目原文里直接带着**「已退役的 legacy 模型」**这个说法。上游模型退役与节点被移除这两件事，在同一条 release notes 里被官方写在了一起。

需要说清楚的是：release notes 的条目就是这么一句话，我们没有别的材料。这三次移除各自有没有提前预告、有没有过渡期、有没有替代节点，官方在这几条里没写，本文也就不替它补。

三、同期它也在加东西，别读成「在收缩」

看到上面那张表，很容易得出「API 节点在缩水」的印象。事实不是这样。同一段时间里新增的条目同样密集：

版本	日期	新增条目	PR
v0.29.0	2026-07-29	新增 OpenAI GPT5.6 模型	PR #14957
v0.29.0	2026-07-29	新增 Google Gemini 3.5 Flash LLM 模型	PR #14972
v0.31.0	2026-08-08	新增 TopazAI Bloom 2 与 Wonder 3.5	PR #15294
v0.31.0	2026-08-08	新增 BFL Flux 3 video model	PR #15295

另外 v0.29.2（2026-07-31）的 release notes 里，整版的主要内容就是「前端修复与新的 api / partner 节点」。

把两张表放一起看，得到的才是准确的画面：这是一个持续吞吐的名单，进出都很频繁。所以风险的性质不是「这条路要没了」，而是「名单里的具体条目不保证长期在位」。你依赖的是「有 API 节点这个机制」还是「有某一个具体节点」，这两件事的风险完全不是一回事。

四、风险具体落在哪里

由上面这些事实，可以直接推出一条判断（这是推论，不是猜测）：依赖 API/partner 节点的工作流，存在「上游模型退役 → 节点被官方移除 → 这份工作流在新版本上打不开」的链路。

有两个放大因素值得单独提：

第一，ComfyUI 的发版节奏很快。 README 写明 core 大约每 2 周发一个新的 major stable 版本，另称遵循以周一为目标的每周发布周期，会因为模型发布或代码库大改而经常变动。节奏快意味着你和「上一个还能用的版本」之间的距离，比在慢节奏项目里拉开得更快。

第二，升级 core 不是只换了 core。 从 v0.31.0 的 requirements.txt 能看到三个精确 pin：前端包 comfyui-frontend-package==1.48.7、工作流模板 comfyui-workflow-templates==0.11.37、内置文档 comfyui-embedded-docs==0.5.9。这些是 == 死绑的，也就是说升级 core 会连带把前端、模板、内置文档一起换掉。release notes 里能看到它们被频繁 bump。

这里要克制一句：不要因此就断言「某个 UI 问题一定是前端版本变化导致的」——那需要具体证据，本文没有。这里只说清楚一件事：一次升级动的东西比你以为的多。

五、决策路径：四个岔口

不给通用建议，按你的处境往下走。

岔口一：你的工作流里到底有没有 API 节点

这是最先要回答的，而且很多人没认真数过。判断方式很朴素——把工作流打开，逐个看节点是本地模型节点还是指向闭源服务的 API 节点；README 里点名的 Nano Banana、Seedance、Hunyuan3D 这类就属于后者。

如果答案是「一个都没有」，本文后面的内容对你只是背景知识——你这条工作流不会被「某个 API 节点被移除」这件事影响（其它升级风险另说，本文不覆盖）。如果有，继续往下。

岔口二：能不能接受出网

--disable-api-nodes 这个参数的官方语义是两句：不加载所有 api 节点，同时阻止前端与互联网通信。README 的 Features 章节里配套的说法是：核心完全离线运行，不下载任何东西除非你要求，用这个参数强制内置功能保持离线。

这条参数适合两类人：

在内网/隔离环境里跑的。按这条参数的官方语义，加上它就不会加载 api 节点，也就不会引入本文讲的这类依赖。注意这只是消除了「API 节点被移除」这一条风险，不等于整套部署就安全了——升级本身还有别的变量。
不想让前端偷偷出网的。注意它的第二句语义——它管的不只是节点，还包括前端的对外通信。

反过来，如果你的产出链路里确实要用闭源模型，这条参数就不能加，风险要用别的方式管。

还要补一句诚实的：这个参数除了 help 里这两句语义之外，还会不会连带影响别的内置功能，官方在这里没有展开，本文也不猜。

# 只想让 ComfyUI 保持离线时的启动方式
python main.py --disable-api-nodes

（以上为按官方参数语义组合的示例，未逐项实测，以官方文档与 python main.py --help 的实际输出为准。）

岔口三：这条工作流是不是进生产

README 提到可以通过 API endpoints 把工作流集成进生产流水线，也提到 App Mode 能把最复杂的工作流暴露成一个简单 UI。这两句都只有一句话，具体端点、请求格式、鉴权方式官方在这里没给，本文不展开。

但只要你打算把工作流接进一条别人也在用的链路，判断就变了：个人使用时「打不开就改」是可接受的，生产链路里同样的事故是要有人负责的。这种场景下，把某个具体的 partner 节点放在关键路径上，等于把自己的可用性挂在一个你无法控制的名单条目上。

可行的做法是分层：能用本地开源模型完成的环节，就别用 API 节点顺手做掉；确实只能靠闭源模型的环节，单独隔出来，并且事先想好这一环挂了整条链路怎么办。

岔口四：跟 tag 还是跟 master

README 在 Release Process 里写得很明确：stable release tag 之外的 commit 可能非常不稳定，会弄坏很多自定义节点。从 v0.4.0 起，patch 版本用于把修复 backport 到当前 stable release，minor 版本用于 master 分支上的发布。

对本文这个话题来说，含义很直接：如果你的工作流本来就压着几个 API 节点，再去跟 master，等于把两种不确定性叠在一起。跟 tag 至少让「什么时候变」这件事变成一个你能挑时间的动作。

六、可执行的那一步：升级前先看 release notes 的移除条目

这是全文唯一一条具体动作，也是本文最想让你带走的东西。

升级 ComfyUI core 之前，去 Releases 页面把要跨过的那几个版本的 notes 拉一遍，专门找带「remove / removed」字样的条目。本文表格里那三条，就是这么找出来的——它们全都明明白白写在 release notes 里，只是大多数人升级时不看。

配套的两个习惯：

跨版本升级时别只看目标版本的 notes。从 v0.28.0 升到 v0.31.0，中间的 v0.29.0、v0.29.2、v0.30.0 都要扫一眼，移除条目是分散在各版本里的。
升级前留一份能回去的东西：旧版本的目录或环境，以及那份工作流 JSON 本身。ComfyUI core 按 README 的 Release Process 是打 stable release tag 发版的，版本之间有明确的锚点；但真正决定你能不能退回去的，是你自己手上有没有留下那份旧环境和那份工作流文件——这一步只能靠你自己，官方不负责。

七、有几个维度，官方没给数据，本文不比

写选型文章最容易滑出去的地方就在这里，所以明说：

各家 partner 模型的效果好坏——官方 release notes 只说了「新增了哪个模型」，没有任何评测数据，本文不比。
调用价格、额度、限流、SLA——一个字都没有，不比。
某个节点被移除时有没有弃用期、有没有官方替代——release notes 的条目里没写，本文不替它补。
Comfy Cloud 的价格、可用模型、限制——README 只把它定位为面向买不起本地硬件用户的官方付费云版本，地址是 comfy.org/cloud，除此之外没有事实，不写。

八、最后一句：不预测

看完前面那两张表，很自然会想问「那接下来会轮到谁」。这个问题本文不回答，也建议你别信任何人的回答。

我们手上只有已经发生的移除记录，没有任何关于官方后续计划的材料。基于三条历史记录去点名下一个，是编故事，不是分析。 你能做的是把机制吃透：知道这类节点会被增删、知道升级会连带换掉哪些包、知道去哪里查移除条目、知道 --disable-api-nodes 在什么处境下该加——这些是确定的，比预测有用得多。

延伸阅读

本文依据 ComfyUI 官方仓库（github.com/Comfy-Org/ComfyUI）的 README、comfy/cli_args.py、release notes 与官方安全公告整理，核对日 2026-08-09，对应版本 v0.31.0；文中引用的 issue 状态为该日期的快照。本文内容为官方文档与源码口径，非本机实测。参数、默认值与功能随版本变动，请以官方文档与 python main.py --help 的实际输出为准。