说实话真正把我从 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 或 YAMLWorkBuddy 会把它展开成 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/outputWorkBuddy 不直接改它只负责在任务完成后把文件复制/移动到归档目录。图片格式命名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是节点 idWorkBuddy 只允许注入这几个节点里的指定字段。其他字段一律不碰。这种“白名单”方式的优点在于哪怕模板升级换代只要节点 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.jsonparams: 3 种风格、4 个种子、1 组采样参数output_prefix:avatar_variant第三步运行 WorkBuddy 主程序python workbuddy.py --task tasks/avatar_variants.jsonWorkBuddy 会输出类似这样的日志[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_id7a3f1c2e-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: ...根本没到点子上。我摸索出的排查路径是先看日志里是否包含prompt_id。打开 ComfyUI 的 UI 界面看同一个任务在界面里的报错提示。如果 UI 里也没明确信息把工作流在画布上重新跑一次看具体是哪个节点报红。WorkBuddy 里我加了“错误上下文捕获”提交失败时除了记录 HTTP 状态码还会尝试读取 ComfyUI 返回的exception_message。有了这两层信息绝大多数问题都能定位到具体节点。5.3 显存不足OOM 问题与批量任务崩溃批量跑图时最让人头疼的就是 OOM。WorkBuddy 本身不直接控制显存但可以控制并发和单任务负载。我的建议是单任务 batch size 设置成 1尤其在做高分辨率出图时。避免同时提交多个任务到 ComfyUI 队列串行就够了。如果一张图的分辨率很高可以考虑在同一工作流里加入分块放大等节点而不是硬顶一整张大图。出现 OOM 后ComfyUI 进程有可能崩溃这就不是 WorkBuddy 能自动恢复的了。我后来加了看门狗定时请求/system_stats如果连续几次请求失败就用子进程重启 ComfyUI并记录重启原因。这个功能虽然不怎么用到但每次用上都值回票价。5.4 常见问题速查表现象可能原因处理办法任务一直 pendingAPI 未监听 / 模型路径错误检查启动参数预检模型文件存在性提交返回 400模板 JSON 结构不对用 ComfyUI UI 重新导出 API 格式图片全黑或空白VAE 丢失 / 模型节点类型不匹配检查 VAE 节点确认模型是 checkpoint 还是 diffusers中文提示词乱码请求编码不是 UTF-8Python requests 中显式设置编码归档图片找不到prompt_id 不对应输出文件从/history返回结果里读取实际文件路径结果与上次不同种子受采样器/模型影响同参数再跑一次确认是否稳定6. 心得与后续扩展6.1 把“盯屏幕”变成“看报告”之后工作节奏完全不同了自从 WorkBuddy 稳定运行后我最大的感受不是单张图快了而是整个工作节奏变了。以前出一个系列素材需要预留一整块时间守在电脑前现在变成可以随时下发任务然后利用等待时间做别的事。归档目录里的meta.json让我随时能回答“这张图是用什么参数出的”这类问题这在协作场景中尤其重要省去了很多沟通成本。6.2 可以继续扩展的几个方向WorkBuddy 已经能满足我的主要需求但它的框架还可以继续长出更多功能。我目前计划中的几个扩展方向是定时任务用系统计划任务在每晚自动跑一批“探索性生成”第二天早上看结果。效果对比面板在生成画廊里直接并排对比不同参数组的图而不需要人肉反复看。远程通知任务批跑完后通过手机推送一条消息连回来收图都自动化。舒适区检测统计每张图的生成耗时、失败率辅助判断哪些参数组合最稳定。6.3 个人经验先跑通再做漂亮日志永远比报错更可信如果你也想给自己本地的 ComfyUI 搭一套类似的流水线我给的建议是第一版先不要追求界面花哨Python 脚本加 JSON 配置足够用第二版再考虑日志、告警、画廊这些增强功能。最重要的是日志要完整每一步的状态、耗时、参数、输出路径都记录清楚。很多问题你以为是玄学最后发现只是日志没记全。WorkBuddy 这个项目让我对 ComfyUI 的掌控力上了一个台阶也把“生成式出图”这件事从手工活变成了真正可管理、可复现、可扩展的生产流程。如果你也正在被繁琐的批量出图困扰建议从一个小任务开始试起——把一套工作流跑通然后让流水线帮你干剩下的活。
