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

更漂亮的是 PNG Info 的闭环：post-process 节点把参数写进 PNG parameters 文本块，PNG Info 管线里的一个 fn 节点再把它读出来。这条闭环全部在本地完成，即使 Hub 全挂了也不影响你回看自己历史生成参数。原文没强调这一点，但对追求可复现的团队来说，这才是「工作流工程化」的核心——生成物本身携带足够多的元数据，让每一次运行都可以被反演。

Hi-res fix 与 img2img：一个 Kontext 节点顶两个 tab

A1111 里 hi-res fix 是先上采再二次去噪，img2img 是另一个独立 tab。Workflow1111 把两者合并到 FLUX.1-Kontext 的同一个 model 节点上：hi-res 版给 Kontext 一条 enhance fine detail and micro-texture, keep the composition identical 的 refine 指令；img2img 版让用户直接描述想改什么，Kontext 返回编辑后的图。

这里的重点不是 Kontext 本身多强，而是一旦模型能力足够通用，UI 上「上采」「编辑」这类历史遗留 tab 就可以合并成同一个节点的两种调用方式。A1111 的 tab 结构是十几年前 Stable Diffusion 生态形成时的产物，那时候每个能力都要专用管线；今天生成模型的能力大幅扩张，还硬把它们摆成十几个 tab 就是在维护考古。

用 LLM 写 prompt、用 VLM 读图：模型即节点

把 Qwen3-4B 用作 prompt 生成器，把 Qwen2.5-VL 用作图片 interrogator，在 Workflow1111 里是两个普通的 model 节点，没有专门的 LLM 扩展、没有专门的 VLM 插件。这个「没有扩展」是关键：ComfyUI 里想接入一个 VLM，你得找到一个（可能已经不再维护的）custom node；A1111 里 CLIP interrogator 是官方内置的独立按钮。Workflow1111 的答案是：既然 Qwen3-4B 已经是 Hub 上的模型，那它就应该跟扩散模型走同一条 InferenceClient 通路，同一种节点类型。

更值得注意的是原文提到 ViT 分类器和 VLM 在同一张图上并行运行——两个节点共享同一个 image 输入，画布调度器识别到它们在同一深度、无依赖，就会自动并行。这是 DAG 调度器的免费红利，画布作者一行调度代码都不用写。

检测转遮罩：把手工画蒙版的活自动化

A1111 里 inpaint 蒙版要用户拿画笔在图上手绘。Workflow1111 的做法：DETR 检测出图里的物体（原文的例子是街景里三个人、一只狗、一辆自行车和一辆汽车），画布分叉——一个分支把检测框画在原图上给用户预览，另一个分支把框转成一张二值蒙版供下游 inpaint 节点使用。

原文特意点出：画框和造蒙版都在本地用 Pillow 和 NumPy 完成，只有 DETR 那一次检测出网。这就是四类算子分工的直接收益：如果画蒙版这一步也走远端，一张图往往需要几十上百次调用，成本和延迟都不可接受；把它固定为 fn 节点，就把「本可以本地做的事」从网络路径上拿掉了。这跟前端页面里「表单校验一定要在客户端也做一份」是同一种工程直觉。

Extras 与 Annotators：本地与远端的分工范例

Extras 里两个 upscaler 走了不同路：一个是 fn 节点里的本地 Lanczos 重采样，快到只受 Pillow 速度限制；另一个是 space 节点 AuraSR ×4，把一个完整的超分辨率 Space 当作原子调用。同样，背景去除也是一个 space 节点（BRIA RMBG-2.0），整个模型住在自己的 Space 里，画布这边只是发起调用。

Annotators 那五个 ControlNet 风格的预处理器——Canny、line art、sketch、luma-depth、posterize——每一个都是纯 NumPy 写的 fn 节点，背后没有模型，CPU 上跑一张图大约 0.5 秒。这一段特别值得中文工程师注意：很多我们习惯当作「模型能力」的东西，其实是可以用几行 NumPy 干掉的经典图像处理。ComfyUI 里 ControlNet preprocessor 常被打包成一个巨型 custom node（依赖一大堆权重下载），Workflow1111 提示我们，这类工作大部分根本不需要走模型路径。

与 A1111、ComfyUI 的对比

把三者放在一起看：

• A1111 是「一个应用 + 无数 tab + 无数扩展」，胜在插件生态和上手速度，输在架构：每加一个功能都是往庞大代码库里插一段，测试和复用都要靠约定。
• ComfyUI 是「一张画布 + 一堆 custom node」，胜在可组合性和可视化，输在算子类型系统的缺失：你分不清哪个节点是网络、哪个是本地、哪个是别人写的重扩展。
• Workflow1111 是「一张画布 + 四类明确算子」，胜在算子类型化带来的可读性、可测性、可优雅降级；代价是节点粒度受限于这四种抽象，一些复杂控制流表达不了。

第三条的代价并非虚指：如果你需要在扩散工作流里跑循环、条件跳转、动态节点，Workflow1111 目前的表达力不如 ComfyUI。但对绝大多数生产化的扩散管线来说，你要的是 DAG 而不是编程语言；把控制流留给外部编排（Airflow / Temporal / 前端），把画布留给「怎么把这次生成一步一步做出来」，反而是更清晰的分工。

对中文工程师的实操意义

如果团队正在做几件事之一，Workflow1111 这套架构值得作为参考模板：

一，正在把 A1111 / ComfyUI 从个人使用推向生产化。生产化里第一个撞上的问题永远是「怎么测」——一个 250 节点的 ComfyUI 工作流，本地跑通一次和线上稳定跑通一百次是两回事。Workflow1111 的 fn 节点是普通 Python，可以脱离画布单测；这一条约束往前推，逼你把「能纯 Python 的部分」和「必须走模型的部分」在设计阶段就分开。

二，正在做私有部署或离线部署。国内不少企业客户对「必须能断网工作」有硬要求，Workflow1111 的 22/36 本地节点占比给出一个非常具体的目标：你能不能让自己的画布里有三分之二以上的节点在断网时仍可用？做不到就意味着一旦上游被限流或被封锁，整条管线立即瘫痪。

三，正在设计新的扩散工作流平台。四类算子的分法比「一切皆插件」清晰得多，也比「一切皆函数」严谨得多。它承认了不同调用形态（本地 / 远端模型 / 远端应用 / 数据）本质上不是同一种东西，直接把这个事实反映在类型系统里，是好设计的一贯做法。

四，想把扩散 pipeline 复用起来做产品。把 BRIA RMBG-2.0、AuraSR 这样的开源能力封装成 Space，然后在自己的画布里作为 space 节点调用，比复制一堆 Python 依赖到本地更符合微服务时代的分工。Hugging Face Spaces 的免费额度和 ZeroGPU 政策让这种「能力即服务」的分发方式变得可承担，Workflow1111 只是把它做到了画布层面。

一个仍然开放的问题

最后留一个值得继续观察的问题：node graph 类工具的宿命，是「简单场景用起来爽、复杂场景变成意面」。ComfyUI 在这条曲线上已经走了几年，社区里已经出现「工作流复杂到没人敢改」的抱怨。Workflow1111 的四类算子和 DAG-only 约束能不能延缓这条曲线，取决于它未来会不会为了迎合复杂场景而引入循环、条件、动态节点。原文没有回答这个问题，值得盯着看 Hugging Face 后续几个版本会不会守住「no loop」这条硬边界——守住了就是范式革新，破防了就是又一个 ComfyUI。

对写代码的人来说，这套架构最大的启发不在扩散工作流本身，而在于它示范了「用类型系统承载运行边界」这件事：当一个抽象里塞了太多本质不同的东西（本地函数 / 远端模型 / 远端应用），把它们拆成不同的类型，比在文档里写「注意某些节点会走网络」要有效一万倍。类型系统能守住的边界，注释永远守不住。