Hugging Face 发布 Workflow1111，用 Gradio 的 gr.Workflow 在可拖拽节点画布上重建并编排 AUTOMATIC1111 的大部分图像生成功能，包含 73 个节点和 11 条流水线，支持本地处理与云端模型调用并可导出为 API/MCP 接口。该工作流展示了把分散功能拆解为可复用节点、便于共享部署与与智能体集成的新产品形态，但在循环节点、模型稳定性和成本控制等方面仍存在限制。
Hugging Face 发布了一套名为 Workflow1111 的示例工作流，尝试用 Gradio 新推出的 gr.Workflow，在一张可拖拽的节点画布上重建 AUTOMATIC1111 Stable Diffusion WebUI 的大部分功能。
根据 Hugging Face 于 2026 年 9 月 10 日发布的官方文章，Workflow1111 由 11 条媒体处理流水线和 73 个节点组成，覆盖文生图、高清修复、图生图、提示词矩阵、视觉语言模型图像解析、检测生成蒙版、ControlNet 风格预处理、放大、背景移除、PNG 参数读取以及图生视频等功能。Hugging Face 同时开放了可直接体验和复制的 Workflow1111 Space。
这不是对 AUTOMATIC1111 原有界面的简单仿制。Hugging Face 试图展示的是另一种产品形态：把原本分散在多个标签页、扩展和脚本中的图像生产能力，拆成可连接、可复用、可通过 API 调用的工作流节点。
从标签页到一张工作流画布
AUTOMATIC1111 的核心优势一直是功能丰富。它提供文本到图像、图像到图像、高清修复、提示词矩阵、PNG Info、放大和多种预处理能力，但这些功能通常以标签页或插件的形式存在。
Workflow1111 则把它们放在同一个画布中。用户可以从一个参考图像节点出发，同时把图像送入 PNG Info 流程读取生成参数，再送入图生视频流程进行动画化；同一个输入也可以被多个下游节点共同使用。
这套设计依托 gr.Workflow 的四类操作节点：fn 节点代表 Python 函数，model 节点通过 Hugging Face InferenceClient 调用模型，space 节点调用另一个 Gradio Space，dataset 节点则从 Hub 数据集读取一行数据。节点之间通过有类型的端口连接，画布可以检查输入输出是否兼容。
Gradio 官方工作流指南显示，工作流同时包含输入引用、处理步骤和输出结果三类节点。它既可以在浏览器中编辑，也可以保存为 workflow.json，由代码或其他编程代理继续修改。
73 个节点覆盖哪些能力
在文生图流程中，用户可以设置负面提示词、采样步数、CFG、种子、宽高和模型 ID。提示词先经过一个 Python 函数节点，添加风格预设并清理文本，再交给模型节点生成图像。最后，另一个函数节点把提示词、步数、CFG、种子、尺寸和模型等信息写入 PNG 元数据，供后面的 PNG Info 流程读取。
高清修复没有照搬 AUTOMATIC1111 中“先放大、再进行第二次去噪”的完整实现，而是采用一个由 FLUX.1-Kontext 驱动的两节点分支，用“增强细节和微纹理、保持构图不变”的指令对生成结果进行处理。该 Kontext 节点也可直接承担图生图功能：用户上传图片并描述修改内容，模型返回编辑结果。
工作流还加入了一个由 Qwen3-4B 驱动的提示词生成流程。用户输入“一场暴风雨中的灯塔”这样的粗略描述后，模型会生成一组标签，再由函数节点清理并限制在 40 个标签以内。Hugging Face 强调，这里不需要像 ComfyUI 那样编写专用自定义节点，语言模型和扩散模型都只是普通的 model 节点。
图像解析流程使用 Qwen2.5-VL 根据图片反推出可能的提示词，同时使用 ViT 分类器返回场景标签。检测到图像中的物体后，DETR 节点可以把检测结果分成两路：一路在原图上绘制边框，另一路生成可供后续修复使用的蒙版。
提示词矩阵则通过函数节点组合基础提示词和多个后缀，再分别送入四个文生图节点，最后拼成一张联系表。由于 gr.Workflow 当前没有循环节点，四个生成分支以并列方式存在；它们处在相同依赖深度，因此在交互式画布中可以并行运行。
大约三分之二的画布可在本地运行
Hugging Face 文章称，Workflow1111 中共有 36 个操作节点，其中 32 个是 fn 节点，22 个函数完全在进程内运行，不需要网络调用。Canny、线稿、素描、亮度深度和海报化等 ControlNet 风格预处理器，便是用 NumPy 编写的普通 Python 函数。
这意味着 Workflow1111 并不是一条完全依赖云端模型的流水线。模型调用可以通过 Inference Providers 或其他 Space 完成，但部分图像处理仍然在本地进行。文章给出的表述是，大约三分之二的画布在网络连接中断时仍可继续工作。
同时，用户也可以把本地模型加载代码放进 fn 节点，并通过 spaces.GPU 为函数申请 ZeroGPU。Hugging Face 以一个运行 FastH3 视频模型的工作流为例，说明 gr.Workflow 并不需要理解具体的 GPU 配置，它只负责调用绑定的 Python 函数。
这让它与面向本地节点编排的工具形成了不同侧重点。AIFlux此前报道的Qwen-Image-3.0关注的是模型如何直接产出更复杂、更接近成品的视觉内容；Workflow1111关注的则是如何把多个模型、函数和处理步骤组织成一条可重复运行的生产链。
每个输出都能变成 API 和 MCP 工具
Workflow1111 暴露了 9 个输出接口，包括 /image、/edited_image、/generated_prompt、/recovered_prompt、/detected_objects、/x_y_grid、/upscaled_local、/annotator_map 和 /png_info。
用户可以通过 gradio_client 调用这些接口，而不必打开画布。例如，文生图接口可以接收提示词、负面提示词、风格预设和高清修复指令，并返回生成图像、参数和高清修复结果。由于工作流本身就是标准 Gradio 应用，也可以通过 REST API 从其他程序接入。
Hugging Face 还展示了 MCP 接入方式。启用 mcp_server=True 后，画布上的输出节点可以成为 MCP 工具，供 Claude Code、Cursor 或其他 MCP 客户端调用。调用方需要在请求中提供自己的 Hugging Face 令牌，Space 不保存自身的模型调用凭据。
在使用层面，用户可以登录 Hugging Face 账户，或者提供访问令牌。模型调用会消耗用户自己的配额，而不是由示例作者承担。用户也可以复制 Workflow1111 的 Space，再删除节点、替换模型或重新连接流程。
它与 ComfyUI 的差异在哪里
Hugging Face 将 ComfyUI 视为最直接的比较对象，因为两者都采用节点图。但两者服务的目标并不完全相同。
ComfyUI 更强调本地模型、细粒度控制和复杂生成流程的自由组合；gr.Workflow 则试图把“可调用的模型、Space、数据集和 Python 函数”放到同一个面向部署的画布里。一个节点可以调用用户没有本地部署的硬件，一个输出可以自动成为 REST 接口，访问者也可以通过 OAuth 以自己的身份运行工作流。
这使 gr.Workflow 更接近“把工作流直接做成应用”的方向。用户不是只在本机调试节点，还可以把整个画布部署到 Hugging Face Spaces，让其他人登录后直接运行，再通过 API 或 MCP 把它嵌入更大的软件和智能体系统。
图生视频等能力也在沿着这一方向演变。AIFlux此前对Gemini Omni 1.1 Flash的报道显示，视频模型也正在从一次性生成转向可以延展、编辑和重复调用的生产流程。Workflow1111 把 Wan 2.2 I2V A14B 接到同一张画布上，体现的是相同的产品化趋势：模型能力不再是孤立的演示，而是流水线中的一个步骤。
不过，二者仍有明显边界。Workflow1111 目前没有循环节点，提示词矩阵需要显式放置多个并列生成节点；模型调用依赖 Inference Providers、Space 或用户自己的 GPU；“支持某项操作”也不等于所有模型都能稳定完成同样的任务。对于实际使用者而言，模型可用性、配额、延迟和生成结果的一致性，仍然需要在具体工作流中单独验证。
从复刻功能到重新定义创作工具
Workflow1111 的意义不只在于把 AUTOMATIC1111 的功能搬到 Gradio 上。它展示了一种更适合共享和部署的组织方式：把文生图、图像理解、检测、蒙版、放大、视频和元数据处理拆解成可以观察中间结果的节点，并让每个输出同时具备交互界面、API 和 MCP 调用入口。
对个人创作者来说，这意味着可以从现成的画布开始，替换模型或重接流程，而不必从空白项目搭建整套前端。对开发者和企业团队来说，工作流则可能成为连接多模型服务、内部函数和自动化代理的中间层。
但它是否能取代 AUTOMATIC1111 或 ComfyUI，还不能仅凭一次示例发布下结论。真正的考验包括：复杂流程能否稳定复现，云端模型的成本是否可控，本地和远程节点混用时延迟如何，工作流版本如何管理，以及 API 和 MCP 暴露后如何处理权限与资源消耗。
Hugging Face 给出的信息更像是一个方向性演示，而不是完整的性能评测。它证明的是：借助 gr.Workflow，一套规模接近成熟图像 WebUI 的多模型工作流，可以被放进一个浏览器画布，并进一步部署成可调用的应用。接下来，社区会决定这种画布式工作流究竟会成为 ComfyUI 的替代方案，还是另一种面向共享、部署和智能体集成的补充层。
来源： Hugging Face：Rebuilding AUTOMATIC1111 with Gradio Workflow；Gradio：Workflows；Hugging Face：Build Anything with gr.Workflow；AUTOMATIC1111 Stable Diffusion WebUI GitHub。