在上一篇文章中，我们构建了五个小型gr.Workflow图，并暗示了要构建像 AUTOMATIC1111 的stable-diffusion-webui那样复杂的东西需要什么。在这篇文章中，我们将带你了解Workflow1111，在这里我们将 AUTOMATIC1111 的大部分功能集重建为单个工作流画布。Workflow1111 是一个由十一条媒体流水线组成的图，使用七十三个节点构建。它汇集了用于文生图、高分辨率修复、图生图、提示词矩阵网格、VLM 反推、检测到局部重绘蒙版、ControlNet 风格标注器、背景移除、PNG Info 存储以及图生视频的 SOTA 模型。

你可以使用 Hugging Face 账户登录或提供访问 token 来运行这些流水线中的任意一条。登录后，模型调用将使用你自己的配额。

👉 试用 Workflow1111，或复制该 Space 并开始为你的用例重新接线。

让我们走一遍画布。

画布上有什么

所有媒体流水线都由我们上一篇帖子和官方指南中介绍的同样四种算子类型构建而成。画布上的每个节点封装一个算子，算子的输入和输出就变成你连接边的端口。作为四种算子类型的快速参考：fn是一个 Python 函数，model是通过InferenceClient调用的模型，space是另一个 Gradio Space，dataset是 Hub 数据集中的一行。

让我们逐一来看这些流水线。

文生图

这是核心流水线。它具备你在 A1111 的 txt2img 标签页中会看到的那些控件：负面提示词、步数、CFG、种子、宽度和高度，外加一个用于选择 checkpoint 的model_id字段。提示词首先经过一个提示词构建器fn节点，该节点会追加所选风格预设并清理文本，然后进入一个model节点，通过 Inference Providers 调用 checkpoint。一个后处理fn节点在输出时将生成参数写入 PNG 的元数据中，这正是 PNG Info 流水线之后读取回来的内容。

高分辨率修复

在 Automatic1111 中，高分辨率修复首先对 txt2img 的输出进行放大，然后运行第二次去噪。在这里，它改为一个两节点的绕行。文生图的结果进入一个带有精修指令（“增强精细细节和微观纹理，保持构图完全一致”）的FLUX.1-Kontextmodel节点，返回时变得更清晰、更大。

图生图

同一个 Kontext 节点同时充当图生图标签页。上传一张图片，描述你想要的改动，它就会返回编辑后的图像。

让 LLM 来写提示词

从一个粗略的提示词开始，比如“暴风雨中的灯塔”。这条流水线会把它发送到一个 Qwen3-4Bmodel 节点，再由一个小型 fn 节点把回复整理成一份干净的标签列表，上限为四十个：“stormy sea, wet rocks, dramatic composition, low angle shot, volumetric lighting, ominous tone”。你可以把任意扩散模型节点连接到这个输出上来渲染图像。

与 ComfyUI 不同，这里不涉及自定义节点。在 Gradio 工作流中，LLM 和扩散模型都只是同一画布上的普通 model 算子。

把图像读回成提示词

这就像 AUTOMATIC1111 的 Interrogate 按钮，只不过由 VLM 而非 CLIP 来执行解读。Qwen2.5-VL 看着一张夜市照片，写出一段可能生成它的提示词。一个 ViT 分类器节点读取同一张图像并返回标签：restaurant 51.9%、tobacco shop 15.6%、toyshop 9.1%。

两个节点使用相同的图像输入，因此 gr.Workflow 会并行运行它们，你大约只需运行一个节点的时间就能得到两个答案。

检测到修复掩码

AUTOMATIC1111 需要你手动绘制修复掩码。而这条流水线则通过检测器自动生成掩码。DETR 在一张街景照片中检测到六个对象（三个人、一只狗、一辆自行车和一辆汽车），随后工作流分为两条分支：一条将检测到的边界框绘制在原图上，另一条将它们转换为掩码，供下游的修复流水线使用。

绘制和掩码生成均在本地通过 Pillow 和 NumPy 完成。只有检测调用需要离开本机。

提示词矩阵

这类似于 AUTOMATIC1111 的提示词矩阵。一个基础提示词"一棵孤零零的橡树"通过一个 fn 节点与四个后缀（日出时分、雷暴中、银河之下、秋雾中）组合，每个变体分别送入各自的文生图节点。最后一个节点将四张结果拼接成一张联系表。

gr.Workflow 没有循环操作符，因此四个文生图节点并排排列在画布上。由于它们处于相同的依赖深度，因此并行运行，四张图像同时开始生成。

放大与背景移除

这就像 Automatic1111 里的 Extras 标签页。有两个放大节点，它们走的是不同的路径。第一个是本地Lanczos重采样，在一个fn节点中完成，无需网络调用，速度与 Pillow 缩放一样快。第二个是AuraSR ×4，它是画布上的第一个space节点：它会调用 Hub 上的一个Space，并把结果当作任何其他节点输出一样处理。

背景去除的工作方式也是如此。BRIA RMBG-2.0是另一个space节点，因此整个模型都存在于它自己的 Space 中，而这个画布只是调用它。

标注员

Canny、线稿、素描、luma-depth 和色调分离，这些通常是你在 Automatic1111 的 ControlNet 扩展中才能获得的前置处理器。而在这里，每一个都是一个用纯 NumPy 编写的 fn 节点，背后没有任何模型。在一张预加载的建筑立面示例照片上，每个标注器在 CPU 上大约需要半秒钟。

该应用中有 36 个算子节点，其中 32 个是 fn 节点，而这 32 个中有 22 个完全在进程内运行，无需网络调用。如果你断网，大约三分之二的画布仍能正常工作。由于这些只是普通的 Python 函数，你还可以直接测试它们，无需画布、服务器或 GPU。

PNG 信息

AUTOMATIC1111 会把生成详情存储在 PNG 的 parameters 文本块中，PNG Info 标签页会将其读回。Workflow1111 也是如此。文生图流水线上的后处理节点负责写入这些元数据，而这条流水线会将其读回，包括提示词、负面提示词、步数、CFG、种子、图像尺寸和模型。

图生视频

PNG Info 读取的那个图像节点同时也馈送给一个 Wan 2.2 I2V A14B 节点，由它将其动画化；在演示示例中，一只沉睡的狐狸醒来并开始活动。这里没有第二个上传框，因为一个参考节点可以馈送给任意多个下游流水线，所以一次上传就能在同一画布上既读取其元数据又被动画化。

在自己的 GPU 上运行模型

到目前为止，每一次模型调用都发生在别人的硬件上，通过 Inference Providers 或一个 Space。这正是你无需自己的 GPU 就能构建并运行 Workflow1111 这类东西的原因。

不过，一个 fn 节点本质上就是 Python，因此它同样可以在本地加载模型并在你自己的 GPU 上运行。FastVideo/fastvideo-fasth3-preview 就是一个 gr.Workflow 应用，正是这么做的。它运行 FastH3，这是 MiniMax-H3 的四步蒸馏版本，并在 ZeroGPU 上生成带配乐的视频。

整个应用归结为一个绑定函数：

@spaces.GPU(duration=get_duration, size=GPU_SIZE)
def _generate(prompt_embeds, text_token_tags, height, width, num_frames, seed):
    ...

gr.Workflow(bind={"generate": generate, "status": status}).launch()

ZeroGPU 会在函数需要时为其分配一块 GPU，调用结束后再释放。gr.Workflow 无需了解这些细节，它只需调用 fn 节点即可。

这也不仅限于 Spaces。把 bind= 指向一个加载本地 checkpoint 的函数，在你自己的机器上运行 .launch()，Workflow1111 画布就能驱动你自己的 GPU。

每个输出都是一个 API

画布上的每个输出节点都会变成一个 REST 端点，无需手写任何路由。Workflow1111 暴露了其中九个：/image、/edited_image、/generated_prompt、/recovered_prompt、/detected_objects、/x_y_grid、/upscaled_local、/annotator_map 和 /png_info。

from gradio_client import Client

client = Client("ysharma/Workflow1111", oauth_token="hf_...")

image, params, hires = client.predict(
    "a red fox in a snowy pine forest",  # Prompt
    "",                                  # Negative prompt
    "Cinematic",                         # Style preset
    "enhance fine detail",               # Hires refine instruction
    api_name="/image",
)

这些相同的端点同时也是 MCP 工具。用 mcp_server=True 启动（指南），每个输出节点都会作为一个工具出现，供 AI 助手调用。把 Claude Code、Cursor 或任何 MCP 客户端指向该服务器 URL：

{
  "mcpServers": {
    "workflow1111": {
      "url": "https://ysharma-workflow1111.hf.space/gradio_api/mcp/",
      "headers": { "X-HF-Token": "hf_..." }
    }
  }
}

现在，智能体可以在一个更大的任务中把生成图像、读回提示词或运行检测作为步骤来执行，无需任何胶水代码。每个调用方都在 X-HF-Token 请求头中发送自己的 token，因此该 Space 本身不持有任何 token。

它与 ComfyUI 的定位对比

AUTOMATIC1111 给了我们功能清单，但真正被拿来和 Gradio Workflow 这款工具比较的是 ComfyUI，因为两者都是节点图。对于很多人想要构建和发布的东西，gr.Workflow 覆盖了相同的范围。

• 一个节点可以是你并不拥有的硬件。它可以通过 Inference Providers 运行，调用 Hub 上的任意 Space 或任意 API，或者从数据集中拉取。Workflow1111 就是这样在没有自己的 GPU 的情况下运行的。
• 每个输出都会变成一个带类型的 REST 端点。这些端点由该图生成。
• 访客可以用自己的身份运行工作流。开启 OAuth，分享公开 URL，任何人都可以登录并使用该应用，无需安装任何东西。
• 在同一画布上混合模型和模态。扩散模型、LLM、VLM、检测器和视频模型都可以成为同一个工作流的一部分。
• 需要自定义的东西？写一个函数。自定义节点就是一个 Python 函数，所以它能做 Python 能做的任何事。

结果就是一个多模型流水线，人们可以在浏览器中打开、登录、立即使用，并从代码中调用。

构建你自己的

Workflow1111 有 73 个节点，但它最初只是这样：

import gradio as gr

def your_function(text: str) -> str:
    pass

gr.Workflow(bind=[your_function]).launch()

bind= 将你的函数变成节点，edges= 将它们连接起来，.launch() 在浏览器中打开画布，让你可以在那里继续编辑。准备好之后，gradio deploy 会把整个东西放到一个 Space 上。gr.Workflow 指南 有完整的细节，包括 JSON schema 和每一种算子类型。

如果你想从已经能用的东西开始，打开 Workflow1111，点击 Duplicate，然后从十一条流水线中选一条来修改：删除节点、替换模型、重新连接流程。如果你想从更小的开始，上一篇博文 里有五个工作流，每个大约一分钟就能跑起来。

无论你构建了什么，都把它发到 X 上并 @@gradio。我们很乐意帮你推广你的工作流。