gr.Workflow 重建 A1111：扩散工作流工程化

用 Gradio Workflow 重建 AUTOMATIC1111：73 节点工程化答案

Hugging Face 团队用 gr.Workflow 把 AUTOMATIC1111 的十一条媒体管线重写成 73 个节点的一张画布：没有循环、四类算子把本地 Python 与远端调用分开、36 个节点里 22 个完全在进程里跑。这不是又一个 ComfyUI 分身，而是对扩散工作流「怎么组织」这个老问题的一次结构化回答，中文工程师值得看一遍它做对了什么。

本文基于 Hugging Face 官方博客 2026 年 9 月发布的《Rebuilding AUTOMATIC1111 with Gradio Workflow》（原文）梳理与延伸。原文是产品公告偏工程实录，我这里换一个视角：不再介绍 Workflow1111「能做什么」，而是把它当成对「节点式扩散工作流应该怎么设计」的一份工程主张，跟中文社区熟悉的 A1111、ComfyUI 放在一起对比，看它到底松开了哪几个结。

为什么这件事值得单独聊

国内做 Stable Diffusion 生产环境的团队，路径基本是两条：一条是 A1111，插件生态最厚、上手最快，但只要跑起来一个像样的 pipeline，就得在若干个 tab、若干个扩展、若干条不透明的 hook 之间来回跳；另一条是 ComfyUI，节点式画布把 A1111 拆开摊平了，可复用性大幅上升，代价是每个真正有用的节点几乎都由第三方 custom node 提供，画布一旦复杂就变成 Python 插件包版本控制地狱。

这两条路的共同点是：把「模型调用」「本地计算」「另一段程序」全部塞进同一种节点抽象里。你不看代码，光看画布分不出哪个节点是一次 HTTP 请求、哪个是本地 CPU 上的 NumPy、哪个是别人写的扩展。Workflow1111 给出的答案，是在算子层面把这四件事显式分开——这才是它区别于 ComfyUI 的关键，不是画布好看。

四类算子：类型系统就是运行边界

gr.Workflow 只有四种 operator：

fn：一段普通 Python 函数，跑在承载画布的进程里；
model：通过 InferenceClient 调用 Hugging Face Hub 上的模型，等价于一次远端推理；
space：调用另一个 Gradio Space，可以把一个完整应用当作原子节点复用；
dataset：从 Hub 数据集里取一行。

这四类的分法看起来平淡，但落到工程语义上有几个非常硬的后果。第一，只有 model 和 space 会走网络，读一眼节点类型就知道这一步会不会踩到限流、鉴权、超时；A1111 里的一个扩展、ComfyUI 里的一个 custom node，你只能进代码里查 import 才能确定。第二，fn 节点是纯函数，脱离画布可以直接 pytest；这一点在长期维护里的价值远超过任何画布界面的美化。第三，把「另一个应用」抽象成 space 节点，等于承认「原子」的粒度可以是一个完整 Space，而不是必须切碎到函数级别——这直接解决了 ComfyUI 里「上游作者把自己写成一个 300 行的巨型 custom node」的问题：那本来就应该是一个独立的 Space，通过网络边界隔离，而不是被强塞进你的画布进程。

原文里给出的实测数字很有说服力：整张画布 36 个 operator 节点，其中 32 个是 fn 节点，32 个 fn 里又有 22 个「完全在进程内跑，不发起任何网络调用」。也就是说，画布上大约三分之二的节点，在你断网、在你上游 API 挂掉、在 Hub 维护窗口期间，仍然可以正常工作。这个「优雅降级」不是宣传语，是可以从节点类型统计里直接读出来的架构性质。

没有循环是特性，不是缺陷

gr.Workflow 里没有 loop operator。第一次听到这个设计约束，很多人的反应是「那怎么做批处理」；但原文举的 prompt matrix 例子说得很清楚：一个基础 prompt「a lone oak tree」搭配四个后缀（sunrise / thunderstorm / Milky Way / autumn fog），画布上是四个并排的 text-to-image 节点，最后由一个 fn 节点把四张图拼成 contact sheet。

没有循环、四个节点在同一依赖深度，运行时的行为就是默认并行。四张图同时开始生成，总耗时约等于最慢那一张。而在 ComfyUI 里，同样的效果要么手动铺四条链路，要么依赖某个特定 custom node 提供的循环节点，二者在语义上都不如「你想同时跑就把节点并排画出来」这么直接。

这背后的设计取舍值得单独点出：把循环从算子集里拿掉，意味着画布本身变成一张纯粹的 DAG（有向无环图）。DAG 的调度问题在过去二十年里已经被数据工程界打磨得非常成熟——Airflow、Prefect、Dagster、包括各家 CI/CD 系统本质都在做同一件事。把扩散工作流也约束成 DAG，等于让它接管这一套现成的心智模型：拓扑排序、并行调度、失败重试、局部重放，全部有现成参考答案。相反，一旦画布容许循环和条件跳转，它就退化成一门「图灵完备但难以推理」的可视化编程语言，ComfyUI 的部分复杂工作流已经开始遇到这类问题。

txt2img 管线：把 A1111 拆成三个明白的节点

看一眼原文里 txt2img 的组织方式，能直接感受到这种分层的好处：

prompt-builder（fn 节点）：把用户输入拼上选定的 style preset，清理冗余空格。这一步纯 Python，不需要 GPU，也不需要网络。
model 节点：把处理好的 prompt 送到通过 Inference Providers 调用的 checkpoint。这一步是唯一走网络的。
post-process（fn 节点）：把生成参数写回 PNG 的 metadata。这一步同样是本地。

A1111 的 txt2img tab 里，同样这三件事是绑死在一个 Python 类里的：你想换 prompt 拼装策略，得看懂它的；你想改元数据写法，得改另一处；你想接入不同的推理后端，得读源码找 hook。Workflow1111 把这三步拆成三个节点后，任何一步都可以被替换、被单测、被并入其它管线。同样的 prompt-builder 节点可以被 hi-res fix、img2img、prompt matrix 复用，这就是 A1111 里那个「怎么让每个 tab 用同样的样式模板」的老问题最自然的解法：让它变成一个节点。