Hugging Face 9 月 10 日发文，展示了用 Gradio Workflow 重建的 Workflow1111，把 AUTOMATIC1111 的功能集合搬成了一张由 11 条媒体流水线、73 个节点组成的图。作者是 Yuvraj Sharma 和 Abubakar Abid。
对没跟过这条线的读者，AUTOMATIC1111 是 Stable Diffusion 时代最广为使用的本地图形界面，几乎定义了那两年 AI 绘画的操作习惯：正负提示词、采样器、高清修复、图生图、ControlNet 插件。后来社区重心逐渐移向节点式的 ComfyUI，但 A1111 的功能清单一直是事实上的基准线。
搬过来的是哪些功能
文章列出的复刻项包括：带风格预设的文生图、高清修复（放大加一轮去噪）、图生图编辑、用大模型改写提示词、图片反推描述、用目标检测生成重绘蒙版、提示词矩阵批量出图、放大与抠背景、Canny 与线稿等 ControlNet 类标注器、PNG 元数据读写，以及图生视频。
背后调用的模型包括 FLUX.1-Kontext、Qwen2.5-VL、DETR、ViT 分类器、BRIA RMBG-2.0 和 Wan 2.2 I2V。
Gradio Workflow 本身定义了四类算子：fn 是 Python 函数，model 通过 InferenceClient 调模型，space 直接接别的 Gradio Space，dataset 取 Hub 上的数据集行。这四类里只有 fn 完全在自己机器上，其余三类的算力都在别处。
与 ComfyUI 的分工
文章给出的对比里，几条差异比较实：一个节点可以是你并不拥有的硬件；每个输出自动成为一个带类型的 REST 端点；支持 OAuth，浏览器里登录即可用；不同模态可以放在同一张画布上；自定义节点就是 Python 函数，Python 能做的它都能做。
最小启动代码只有三行——导入 gradio、写一个函数、gr.Workflow(bind=[your_function]).launch()。部署用 gradio deploy 推到 Spaces。另外整套工作流支持 MCP，意味着智能体可以把它当工具调。
性能上文章只给了一个数字：预加载图片后，CPU 标注器每个约 0.5 秒。许可证没有在文中写明。
对国内用户意味着什么
这套东西的实际可用性，取决于你在哪一侧。22 个纯本地节点意味着抠图、Canny、线稿、元数据这类活可以离线跑完，这部分不看网络。但 model 和 space 两类算子走的是 Hugging Face 的推理端点，国内直连的稳定性一直是个问题，FLUX.1-Kontext 和 Wan 2.2 这类重模型的调用尤其明显。
Wan 2.2 是阿里开源的视频生成模型，在国内有魔搭这条更近的分发路径。也就是说这张图里的模型多数在国内能找到对应的托管，但 Workflow 的运行时目前绑在 Hub 上，要换源得自己改 fn 节点去调本地或国内服务。这不是做不到，是一份额外的工程量。
从工具演化的角度看，A1111 到 ComfyUI 是从表单到图，Workflow1111 这一步是从”图跑在我的显卡上”到”图跑在谁的显卡上都行”。中间那层抽象一旦成立，本地显存就不再是能不能跑的前提，而变成了一个成本选项。这个判断能不能站住，往后一两年看社区里自建节点与租用节点的比例就知道。
参考来源：Hugging Face 官方博客、Gradio 文档、CocoLoop；节点数量、算子分类与耗时数字按原文核对，国内可用性部分为编辑判断。