用WorkBuddy给ComfyUI加个调度外壳，批量出图自动化不再是难题

说实话，真正把我从 ComfyUI 的手工操作中解放出来的，不是换了更贵的显卡，而是我给自己本地的 ComfyUI 套了一个叫 WorkBuddy 的调度外壳。简单说，WorkBuddy 不是去改 ComfyUI 本身，而是在它外面包了一层任务管理管道，让“加载工作流 → 改提示词 → 点运行 → 等结果 → 手动存图 → 手工分类”这一整套重复劳动，变成“配置好参数 → 一键下发 → 自动排队出图 → 自动归档成册”的流水线。如果你也经常被本地 ComfyUI 的繁琐操作拖慢效率，或者想让出图任务批量、定时、可追溯地跑起来，这篇文章应该能给你一套直接能抄的思路。

ComfyUI 本身的节点式画布很好用，但它本质上是个“一屏一任务”的工具。你可以在画布里把工作流搭得特别漂亮，可一旦涉及到几十个提示词变体、多组参数对比、跨几个风格批量出图，人肉操作就变成灾难了。WorkBuddy 做的事，就是把画布里那张工作流当成“执行引擎”，而把“这次要跑哪些参数、跑完的图放哪儿、出问题怎么重试”这些调度逻辑，全部挪到外面统一处理。整套方案我已经跑了好几个月，中间踩过不少坑，也修了不少细节，下面从设计思路到落地步骤全部分享出来。

1. 出图流水线的整体设计与思路拆解

1.1 手动作图的真实痛点：效率损耗来自“切换”而不只是“运行”

大多数人用 ComfyUI 的低效，不是单张图生成慢，而是流程太碎。我之前的工作节奏是这样的：先在画布里调整提示词，填好种子，点一次 Queue，等生成完，右键保存图片，再去改下一组提示词，再点运行。听起来不复杂，但实际上每张图之间的“操作时间”往往比“生成时间”还要长，尤其是当你需要对比同一个提示词下不同采样器、不同 CFG、不同模型参数的效果时，这种来回切换的损耗会被成倍放大。

更麻烦的是，出图过程需要守在旁边。因为你不确定这次任务到底多久跑完、会不会中途报错，也没法预判结果好坏。我试过同时开几个浏览器标签页去排队，结果 ComfyUI 的 UI 操作变得卡顿，偶尔还会把工作流搞乱。后来我意识到，问题的核心不是“画画本身”，而是缺少一个统一的任务入口。

我把需求拆成了三块：

• 任务描述标准化：一次任务不仅包含工作流 JSON，还要包含这次要替换哪些参数、生成多少张、用什么命名规则。
• 执行过程自动化：把“点击 Queue”变成“向 API 提交一个 prompt_id”，然后自动轮询状态。
• 结果流转有序化：生成完的图片自动按项目、风格、日期归档，并且把使用的参数和图片对应起来。

WorkBuddy 就是顺着这三块需求长出来的。它不改变 ComfyUI 的任何节点逻辑，也不需要我重新搭一套图像生成引擎，只是把 ComfyUI 当作一个高性能的“渲染后台”，而 WorkBuddy 自身承担“生产调度员”的角色。

1.2 为什么选 API 而不是继续用界面操作

ComfyUI 本身提供了完整的 HTTP API，这是 WorkBuddy 能成立的前提。UI 界面适合交互探索，但批量调度场景下，API 有不可替代的优势：

• 可编程：任务提交、状态查询、结果获取都能用代码触发，不需要人盯屏幕。
• 可记录：每个请求的 prompt_id、参数、耗时都会被程序准确记录，方便复盘。
• 可叠加：同一个 ComfyUI 实例可以接受多个任务排队，WorkBuddy 只需要维护自己的队列，就能做到“任务攒着跑，人先干别的”。
• 稳定：绕开了浏览器前端那层状态同步的延迟和偶发卡顿。

我的选择是让 WorkBuddy 直接对 ComfyUI 的/prompt接口提交任务。提交之前，WorkBuddy 会读取一个标准的工作流模板，把模板里的占位符置换成每次任务的实际参数，再生成完整请求体发送出去。这个流程听起来有些绕，但实际上只比手动跑图多了一步准备工作，换来的却是一整套自动化的控制力。

提示：如果你的 ComfyUI 跑在局域网另一台机器上，记得在启动参数里加上--listen 0.0.0.0，否则默认只监听本机回环地址，别的机器没法访问 API。

1.3 WorkBuddy 的整体架构：前端任务单 + 后端调度器 + 归档器

WorkBuddy 被我分成了三个模块，每个模块只负责一件事，这样排查问题的时候不用在代码里到处找：

• 任务单模块：负责定义“这次要跑什么”。每个任务单包含工作流模板文件名、参数字典、输出前缀、优先级、超时时间。
• 调度模块：负责和 ComfyUI API 打交道，包括提交任务、查询排队状态、检查错误、失败重试。
• 归档模块：负责在任务完成之后，把输出图片从 ComfyUI 的输出目录搬到按日期/项目划分的目录，并把参数信息写进一个 JSON 元数据文件。

这三个模块之间用 JSON 文件传递信息，不用数据库，因为对我来说脚本的目的就是简单透明。任务单可以手动写，也可以由一个“参数生成器”批量生成。比如我要跑 20 组不同提示词的风格对比，只需要提前把提示词写进一个 CSV 或 YAML，WorkBuddy 会把它展开成 20 个独立任务。

这张图在别人眼里可能觉得有点简陋，但实际用起来特别顺手。因为问题一旦发生，我只需要看调度日志就知道卡在哪一步，不需要去猜。

2. 环境准备与 WorkBuddy 的核心配置

2.1 让 ComfyUI 露出 API 接口：开发者模式、端口与安全设置

在用 WorkBuddy 之前，我先把 ComfyUI 的 API 能力摸了一遍。ComfyUI 的 UI 里有一个“开发者模式”开关，打开后你可以在设置里看到“在画布中显示 API 格式”的选项，把工作流切换成 API 格式后，能看到每个节点的class_type和inputs，这就是 WorkBuddy 要用的基本素材。

我习惯的启动命令是这样：

cd path/to/ComfyUI python main.py --listen 127.0.0.1 --port 8188

如果只是本机跑，--listen 127.0.0.1就够了，没必要对局域网开放，减少不必要的暴露。如果确实需要远程调用，可以监听局域网地址，但我建议加一层简单的访问控制，而不是裸奔在网络上，毕竟 ComfyUI 的 API 能直接执行任意工作流，等于把计算资源开放了出去。

启动之后，可以用curl简单测一下 API 是否可用：

curl http://127.0.0.1:8188/system_stats

返回一段 JSON 就说明服务正常。这一步看似多余，但我在好几个机器上排查过半天，最后发现是服务没起来，所以把验证放在最前面能省很多时间。

2.2 WorkBuddy 的目录结构与配置文件

WorkBuddy 本身的代码和配置，我按下面这个结构组织：

workbuddy/ ├── tasks/ # 任务单，一个 JSON 文件代表一次批量任务 │ ├── style_compare_01.json │ └── batch_portrait.json ├── templates/ # 从 ComfyUI 导出的 API 格式工作流模板 │ ├── txt2img_basic.json │ └── img2img_upscale.json ├── output_archive/ # 归档目录，按 日期/项目/ 归类 ├── logs/ # 运行日志，按天滚动 ├── workbuddy.py # 主程序 ├── scheduler.py # 调度模块 └── archiver.py # 归档模块

任务单的 JSON 示例：

{ "template": "txt2img_basic.json", "name": "portrait_style_A", "output_prefix": "portrait_A", "priority": 5, "timeout": 600, "params": { "prompt": "a portrait of a young woman, soft lighting, painterly style", "seed": 42, "steps": 28, "cfg": 7.0, "sampler_name": "euler_ancestral", "width": 1024, "height": 1024 } }

看起来内容不多，但每项都会有对应的作用。template告诉 WorkBuddy 用哪张画布；params是真正要替换到工作流节点里的值；output_prefix是出图文件前缀；timeout是超时保护，防止某个任务异常卡住时 WorkBuddy 一直等下去。

这里想强调一个细节：模板里的占位符替换不是盲目地全局替换，而是针对特定节点做注入。比如 txt2img 工作流中，提示词文本可能分别在“正向提示词节点”和“反向提示词节点”里，如果只按变量名全局替换很容易出错。WorkBuddy 的做法是在模板 JSON 里额外记录“哪些节点的哪些字段允许被任务参数覆盖”，这样的白名单机制比我最初做的“全字段替换”安全得多。

2.3 端口、路径与参数约定：一次核对清楚

我建议你在搭 WorkBuddy 之前，先把下面几个变量对齐，否则后面会遇到很多“看起来没报错但就是不对”的问题：

• ComfyUI 的 API 地址：统一写成http://127.0.0.1:8188，如果自定义了端口要同步。
• 输出目录：ComfyUI 的输出路径通常在ComfyUI/output，WorkBuddy 不直接改它，只负责在任务完成后把文件复制/移动到归档目录。
• 图片格式命名：ComfyUI 默认输出 PNG，文件名带随机串。WorkBuddy 统一按项目名_参数摘要_序号.png的方式重命名，便于一眼看出是哪组参数出的图。

这些约定刚开始不觉得有多重要，跑了一周后回头看，绝对救命。比如有一次我生成了一堆风格对比图，因为没有把参数摘要写进文件名，只能靠肉眼去猜哪张图对应哪个参数组合，整个过程让人抓狂。现在 WorkBuddy 会在文件名里带上种子号和 CFG，比如portrait_A_seed0042_cfg7.0_01.png，一目了然。

3. 核心功能拆解与关键实现

3.1 任务队列与并发控制：ComfyUI 一次只跑一张，WorkBuddy 负责排队

ComfyUI 自己的队列机制是先进先出，支持在 UI 上点击多个 Queue 排队，但它的能力边界比较朴素。WorkBuddy 做了一层更灵活的任务排队，主要解决三个问题：

• 优先级：有些任务可以等，有些任务需要插队。
• 依赖关系：有些任务必须等前面的任务跑完才能开始（比如先生成草稿图，再做图生图放大）。
• 错误隔离：一个任务失败不能导致后面全部任务停止。

WorkBuddy 调度模块的核心逻辑是：先读取任务单，生成一个有序任务列表，然后逐个向 ComfyUI 的/prompt接口提交。每次提交后拿到一个prompt_id，接着进入轮询循环，每 3 秒查询一次/history/{prompt_id}判断是否完成。

并发方面，我的建议是不做真正的多并发。ComfyUI 后端默认同一时间只会执行一个任务，多开几个提交请求也只是在 ComfyUI 的队列里排队，并不会真正并行。而且如果你的显卡显存有限，同时跑多个任务反而容易导致 OOM。所以我让 WorkBuddy 默认只有一个“在飞任务”，其他任务在本地等待。这种“串行执行、链式提交”的方式虽然看起来不够炫酷，但最稳定，尤其适合需要长时间跑批的场景。

3.2 参数展开与批量出图：从“一张一张改”变成“一组一组跑”

批量场景里最常见的操作就是“换提示词、换种子、换采样器参数”。WorkBuddy 的参数展开器支持从一个简单的列表自动生成多个任务：

# params_batch.yaml base_prompt: "a portrait of a young woman, soft lighting, painterly style" style_variants: - "watercolor style" - "oil painting style" - "pencil sketch style" negative_prompt: "blurry, low quality" steps: [24, 28] seeds: [42, 100, 200]

WorkBuddy 会按“笛卡尔积”的方式把这些参数组合展开，生成 3 种风格 × 2 种步数 × 3 个种子 = 18 个任务。这个听起来很机械，但它刚好符合出图对比的需求：变量收敛、条件清晰、结果可控。

这里有个实操经验：不要一开始就把参数空间放得太大。我最初做了一组 5 个风格 × 5 个采样器 × 3 个种子 = 75 个任务的全量跑，结果一半的图都因为某种组合不理想而浪费了。后来我改成“先跑小规模探索集，确认方向后再放大规模”，效率反而更高。WorkBuddy 很适合分阶段执行，一次任务跑一组小批量，把探索和量产分开。

3.3 输出管理与去重策略：别让 output 目录变成垃圾场

ComfyUI 运行时间长了，output目录就是重灾区：文件堆积、命名混乱、分不清谁是谁。WorkBuddy 的归档模块是我最得意的一部分。

任务跑完后，WorkBuddy 会做三件事：

• 根据历史记录找到该prompt_id对应的输出图片文件列表。
• 把文件复制到output_archive/日期/项目名/目录下，并重命名为包含参数摘要的格式。
• 写一个meta.json，记录完整参数、模型名、采样器、种子、耗时等信息。

复制而不是移动，是因为有时候 ComfyUI 的 UI 还在用这些图，直接移走可能会让 UI 里的预览路径失效。归档之后，原始输出目录我定期用脚本清理，这样两边都不会乱。

去重逻辑也很简单：对同一任务生成的图片，比较文件 SHA256 哈希，如果哈希一致说明是完全相同的输出，只保留一份。这个情况在固定种子但没有改变工作流时偶尔会出现，虽然不常见，但有总比没有好。

3.4 工作流模板的“白名单替换”机制

这是 WorkBuddy 里最容易翻车的部分。ComfyUI 的 API 格式 JSON 是一个很深的嵌套结构，如果你像我最初一样直接用json.loads后全局遍历替换所有与params同名的键，很容易误伤。比如提示词里恰好有字符串"seed"，或者某个节点的class_type名称里包含关键词，全局替换会把不该变的字段也改掉。

我的做法是预先在模板文件里用注释标注哪些节点是可注入的。比如在模板 JSON 对应的配置块里写明白：

"injectable_nodes": { "3": ["text", "seed"], "4": ["text"], "5": ["steps", "cfg", "sampler_name"] }

这里的3、4、5是节点 id，WorkBuddy 只允许注入这几个节点里的指定字段。其他字段一律不碰。这种“白名单”方式的优点在于：哪怕模板升级换代，只要节点 id 对应的语义不变，就能安全复用；一旦节点 id 因为工作流修改而失效，WorkBuddy 会给出警告而不是悄悄改错。

注意：每次从 ComfyUI 导出新的 API 工作流后，记得先手动检查节点 id 有没有变化。节点 id 是画布上的title位置相关的整数，调整过画布布局后，导出格式里 id 可能改变，WorkBuddy 不会自动帮你适配。

4. 实操过程：把一套工作流跑成真正的流水线

4.1 从 ComfyUI 画布到 WorkBuddy 任务单：完整流程演示

我用一个具体的例子来说明。假设我要给自己的一个头像项目生成一批风格变体，基础工作流是标准的 txt2img，模型用的是本地的某一个 checkpoint，期望输出 1024×1024 的图。

第一步，在 ComfyUI 画布里把工作流搭好，导出 API 格式，存成templates/portrait_base.json。

第二步，写一个任务单tasks/avatar_variants.json，里面指定：

• template:portrait_base.json
• params: 3 种风格、4 个种子、1 组采样参数
• output_prefix:avatar_variant

第三步，运行 WorkBuddy 主程序：

python workbuddy.py --task tasks/avatar_variants.json

WorkBuddy 会输出类似这样的日志：

[10:02:01] Loaded template: portrait_base.json [10:02:01] Generated 12 tasks from parameter grid [10:02:02] Submitting task 1/12: prompt_id=7a3f1c2e-9d22-4b98-a6e1-2b8f3f1b9c45 [10:02:32] Task 1/12 completed in 30.2s, output: avatar_variant_style01_seed0042_01.png [10:02:33] Submitting task 2/12: ...

这里的 12 个任务，每张平均耗时 30 秒左右，加起来大约 6 分钟，全程不需要我坐在屏幕前。

4.2 实际效果：工作量不变，但我的“在场时间”变短了

使用 WorkBuddy 前后，我的时间分配变化非常明显。以前跑 12 个变体，我得时不时回到屏幕前看有没有跑完、要不要手动点下一步；现在只需要下发任务，5 到 10 分钟后来看归档目录就行。中间可以去处理别的工作，比如写文案、画分镜、修素材。

另一个改变是出错率降低。以前手动跑批，如果某个参数在界面里输错了，可能要跑到一半才发现，前几张图全部作废；WorkBuddy 因为使用了同一套参数展开逻辑，每一张图的参数都有据可查，一旦发现问题，只需要修正任务单重新下发，不需要担心“上次哪张图是用哪个参数的”这种问题。

这里我也要坦白一个一开始没做好的事情：我没给 WorkBuddy 做“结果预览”功能，导致每次只能去目录里翻图。后来我加了一个简单的 HTML 画廊生成器，每次归档完自动生成一个 gallery 页面，里面按任务分组展示图片和参数信息，翻看结果方便多了。这件事推荐尽早做，否则对比效果时效率还是打折。

4.3 快速出图的关键参数选择

跑批量出图时，参数选择直接决定了整个批次的时间成本和质量稳定性。我自己的经验是：

• 步数不宜拉满。默认 28 步确实比 20 步细节好一些，但并非所有风格都需要那么高；风格探索阶段用 20 步，量产阶段再视情况上浮。
• 采样器别换来换去。一个项目尽量固定一种采样器，不然结果之间可比性变差。
• CFG 保持在 5~8 之间，太低了画面容易糊，太高了容易过锐化。
• 种子复用要谨慎。如果换模型或换工作流结构，同名种子的效果完全不一样，对比时要注意。

如果把出图任务当成化工生产，那么参数就是配方；WorkBuddy 每一次归档都能锁定配方，下次想要复现同样的结果，直接从meta.json里读参数重新提交即可。

5. 常见问题与排查技巧实录

5.1 队列一直 pending 但 UI 上没动静

这个问题我遇到好几次，排查下来主要有两个原因：

• ComfyUI 没有启动 API 监听，只打开了本地 UI。
• 工作流模板里的某个节点引用了不存在的模型文件，导致 ComfyUI 在加载节点时卡住。

处理办法：先用curl访问/system_stats确认 API 通，再检查模型路径。WorkBuddy 的任务单里如果写错了模型名，ComfyUI 不会第一时间报错，而是挂在队列里不动。后来我在 WorkBuddy 里加了一层预检，提交前先对模板里的模型文件路径做存在性校验，不存在的直接拒绝提交，这一下就少了很多无效任务。

5.2 任务报错但日志信息不明确

ComfyUI 的/history/{prompt_id}返回的错误信息有时候很笼统，比如ERROR: ValueError: ...，根本没到点子上。我摸索出的排查路径是：

1. 先看日志里是否包含prompt_id。
2. 打开 ComfyUI 的 UI 界面，看同一个任务在界面里的报错提示。
3. 如果 UI 里也没明确信息，把工作流在画布上重新跑一次，看具体是哪个节点报红。

WorkBuddy 里我加了“错误上下文捕获”，提交失败时除了记录 HTTP 状态码，还会尝试读取 ComfyUI 返回的exception_message。有了这两层信息，绝大多数问题都能定位到具体节点。

5.3 显存不足：OOM 问题与批量任务崩溃

批量跑图时最让人头疼的就是 OOM。WorkBuddy 本身不直接控制显存，但可以控制并发和单任务负载。我的建议是：

• 单任务 batch size 设置成 1，尤其在做高分辨率出图时。
• 避免同时提交多个任务到 ComfyUI 队列，串行就够了。
• 如果一张图的分辨率很高，可以考虑在同一工作流里加入分块放大等节点，而不是硬顶一整张大图。

出现 OOM 后，ComfyUI 进程有可能崩溃，这就不是 WorkBuddy 能自动恢复的了。我后来加了看门狗：定时请求/system_stats，如果连续几次请求失败，就用子进程重启 ComfyUI，并记录重启原因。这个功能虽然不怎么用到，但每次用上都值回票价。

5.4 常见问题速查表

6. 心得与后续扩展

6.1 把“盯屏幕”变成“看报告”之后，工作节奏完全不同了

自从 WorkBuddy 稳定运行后，我最大的感受不是单张图快了，而是整个工作节奏变了。以前出一个系列素材，需要预留一整块时间守在电脑前，现在变成可以随时下发任务，然后利用等待时间做别的事。归档目录里的meta.json让我随时能回答“这张图是用什么参数出的”这类问题，这在协作场景中尤其重要，省去了很多沟通成本。

6.2 可以继续扩展的几个方向

WorkBuddy 已经能满足我的主要需求，但它的框架还可以继续长出更多功能。我目前计划中的几个扩展方向是：

• 定时任务：用系统计划任务在每晚自动跑一批“探索性生成”，第二天早上看结果。
• 效果对比面板：在生成画廊里直接并排对比不同参数组的图，而不需要人肉反复看。
• 远程通知：任务批跑完后通过手机推送一条消息，连回来收图都自动化。
• 舒适区检测：统计每张图的生成耗时、失败率，辅助判断哪些参数组合最稳定。

6.3 个人经验：先跑通再做漂亮，日志永远比报错更可信

如果你也想给自己本地的 ComfyUI 搭一套类似的流水线，我给的建议是：第一版先不要追求界面花哨，Python 脚本加 JSON 配置足够用；第二版再考虑日志、告警、画廊这些增强功能。最重要的是日志要完整，每一步的状态、耗时、参数、输出路径都记录清楚。很多问题你以为是玄学，最后发现只是日志没记全。

WorkBuddy 这个项目让我对 ComfyUI 的掌控力上了一个台阶，也把“生成式出图”这件事从手工活变成了真正可管理、可复现、可扩展的生产流程。如果你也正在被繁琐的批量出图困扰，建议从一个小任务开始试起——把一套工作流跑通，然后让流水线帮你干剩下的活。