1. WorkBuddy 是什么它为什么能“管住” ComfyUI 这头猛兽很多人第一次听说 WorkBuddy会下意识把它当成另一个“ComfyUI 启动器”或者“图形界面封装工具”。我最初也是这么想的——直到我在某次连续出图失败后把本地 ComfyUI 的启动脚本、模型路径配置、队列管理、日志归档、GPU 温度监控全塞进一个 Python 脚本里折腾了三天才勉强跑通。那一刻我才意识到ComfyUI 本身是极简的、纯粹的、面向开发者的设计哲学但它对普通用户或中小型创作团队来说根本不是“开箱即用”而是“开箱即崩溃”。WorkBuddy 的核心定位从来就不是替代 ComfyUI而是在 ComfyUI 的底层能力之上构建一套可感知、可干预、可追溯、可复用的工程化操作层。它不碰 ComfyUI 的节点逻辑不改 WebUI 的前端渲染也不动任何模型加载机制它只做三件事接管输入、调度执行、捕获输出。这听起来简单但恰恰是绝大多数 ComfyUI 用户卡死的环节。举个最典型的例子你用 ComfyUI 做批量图生图要处理 200 张参考图每张图配 5 组不同提示词生成 1000 张图。原生 ComfyUI 怎么做手动上传→填参数→点生成→等完成→下载→再上传下一张……这个过程里你无法知道第 37 张图是不是因为显存溢出静默失败了也无法确认第 82 张图的 seed 是否被正确记录更没法在中途暂停后精准续跑——所有状态都藏在浏览器标签页里关掉就丢。而 WorkBuddy 把这件事变成了一个标准工作流你只需写一个 YAML 配置文件声明输入目录、提示词模板、采样参数范围、输出命名规则然后执行wb run --config batch_v2.yaml。它会自动扫描输入目录下的全部图像支持子目录递归按预设规则生成 1000 条独立任务描述含完整 prompt、negative prompt、seed、steps、cfg 等将每条任务序列化为 ComfyUI 的/promptAPI 请求体通过 HTTP 长轮询监听执行状态失败时自动重试可配置次数与间隔成功后下载图片元数据 JSON含 workflow、full_prompt、execution_time、gpu_util%按{input_name}_{prompt_hash[:6]}_{seed}规则归档到指定目录并写入 SQLite 数据库。提示WorkBuddy 不依赖 ComfyUI 的自定义节点或插件系统它完全走官方/prompt和/historyAPI。这意味着只要你的 ComfyUI 版本 ≥ v0.9.02023 年底起无需任何修改即可接入。我实测过从 v0.9.4 到 v0.12.3 全部兼容连/queue接口变更都做了自动适配。它之所以能“管成一条流水线”本质在于把原本离散、交互式、状态不可见的手动操作重构为有明确输入契约、有确定执行边界、有结构化输出产物的批处理单元。这不是 UI 层的美化而是工作范式的迁移——从“我在用 ComfyUI 做图”变成“我让 ComfyUI 为我执行一个定义好的出图任务”。这种转变带来的实际收益远超效率提升本身。比如我们团队曾用它支撑一个为期三周的 AI 视觉提案项目每天需产出 300 张风格统一但构图多变的场景图。过去靠 3 个人轮班守着 ComfyUI 页面错误率高达 12%漏传图、错配参数、覆盖文件接入 WorkBuddy 后仅需 1 人维护 YAML 配置和检查数据库日志错误率降至 0.3%且所有产出图均可通过wb query --prompt cyberpunk street --date 2024-05-12精准回溯。所以别再问“WorkBuddy 和 ComfyUI 有什么区别”——它们根本不在同一维度。ComfyUI 是引擎WorkBuddy 是仪表盘变速箱行车记录仪维修手册的集合体。你不需要懂内燃机原理也能开车但如果你想把车开上赛道、跑满 1000 公里、全程记录胎压油温、赛后分析每一圈过弯数据——你就需要 WorkBuddy 这套系统级工具。2. 流水线不是口号从单图调试到千图调度的四层跃迁很多用户第一次尝试 WorkBuddy会直接跳到“批量出图”章节试图用一个 YAML 文件搞定全部需求。结果往往是配置报错、任务卡死、输出混乱。这不是 WorkBuddy 的问题而是跳过了它设计的四层能力演进路径。我把这套路径称为“流水线成熟度模型”它严格对应真实项目推进节奏2.1 第一层单图原子任务封装Local Dev Mode这是所有工作的起点也是最容易被忽略的基础。WorkBuddy 要求你必须先将“一次成功出图”的完整上下文固化为可复现的最小单元。不是截图保存参数而是用wb capture命令抓取当前 ComfyUI 实例中正在运行的完整执行快照# 在 ComfyUI 正常运行状态下执行 wb capture --name portrait_v1 --desc 正脸肖像柔光8k细节该命令会自动调用/history获取最近一次成功执行的 prompt ID拉取/history/{id}获取完整 prompt JSON、workflow JSON、执行耗时、GPU 显存峰值将 prompt JSON 保存为tasks/portrait_v1/prompt.json将 workflow JSON 保存为tasks/portrait_v1/workflow.json生成tasks/portrait_v1/config.yaml包含基础参数如comfy_url: http://127.0.0.1:8188,timeout: 300自动创建tasks/portrait_v1/input/目录供你放入测试图若 workflow 需要。注意wb capture抓取的是“已执行成功”的状态而非当前画布。这意味着你必须先在 ComfyUI 中手动跑通一次确保节点连接无误、模型加载正常、VAE 解码稳定。我踩过的最大坑是某次 capture 后发现 output 节点被意外断开导致后续所有任务都只返回空 JSON——因为 WorkBuddy 忠实复现了那个“看似成功实则无效”的执行路径。所以每次 capture 前务必右键 output 节点 → “Validate Node”确认绿色勾选。这一层的价值是消灭“上次能跑这次不能”的玄学问题。所有参数、模型路径、节点版本都被锁定下次执行wb run --task portrait_v1结果必然一致。我们团队现在强制要求任何新 workflow 上线前必须完成 capture 并提交至 Git作为技术方案的“可执行说明书”。2.2 第二层参数变量注入Template-Driven Execution当单图稳定后自然要解决“微调参数快速出多版”的需求。WorkBuddy 采用 Jinja2 模板语法注入变量而非传统 CLI 参数拼接。例如你想对同一张输入图生成 5 种不同风格# tasks/portrait_styles/config.yaml inputs: image: input/ref.jpg prompts: - prompt: - {{ base_prompt }}, {{ style }}, {{ quality }} negative_prompt: {{ negative_prompt }} variables: base_prompt: a young woman, studio lighting negative_prompt: deformed, blurry, bad anatomy style: [cyberpunk, oil painting, anime cel-shading, pencil sketch, photorealistic] quality: masterpiece, best quality, 8k执行wb run --task portrait_styles时WorkBuddy 会自动展开为 5 条独立 prompt 请求每条都带唯一prompt_id和完整元数据。关键在于所有变量都在 YAML 内定义不侵入 workflow JSON。这意味着你可以用同一个 workflow 文件比如flux_dev_v2.json通过切换 config.yaml 中的style列表驱动完全不同的视觉输出而 workflow 本身无需任何修改。我实测过变量嵌套深度达 4 层的复杂模板如{{ subjects[loop.index0].name }} in {{ locations[loop.index1].setting }} with {{ objects[loop.index2].material }}WorkBuddy 解析稳定生成 prompt 数量精确可控。但要注意一个硬性约束Jinja2 模板中禁止使用import、exec等危险指令WorkBuddy 启动时会做静态语法扫描发现即报错退出——这是为安全做的主动限制不是 bug。2.3 第三层输入资产编排Asset Pipeline当项目进入中期输入不再是一张图而是一组结构化资产参考图、Mask 图、Depth 图、Pose 关键点 JSON、甚至 Lora 权重文件。WorkBuddy 通过assets字段建立资产依赖关系# tasks/product_shot/config.yaml assets: - name: main_image type: image path: input/products/{{ sku }}.jpg - name: mask type: image path: input/masks/{{ sku }}_mask.png required: false # 可选资产 - name: pose type: json path: input/poses/{{ sku }}.json required: true workflows: - name: product_composite file: workflows/composite_v3.json inputs: image: {{ assets.main_image }} mask: {{ assets.mask }} pose: {{ assets.pose }}执行时WorkBuddy 会扫描input/products/下所有 JPG 文件提取文件名作为sku变量对每个sku检查input/masks/下是否存在对应 mask 文件不存在则跳过因required: false加载input/poses/下的 JSON验证其是否符合预设 schema如必须含keypoints数组将资产路径注入 workflow 的 input 字段生成最终 prompt。这套机制让我们把“产品图合成”项目从人工筛选匹配升级为全自动资产流水线。过去每周要花 8 小时核对 200 SKU 的文件完整性现在wb validate --task product_shot一条命令3 秒内给出缺失清单和格式错误详情。2.4 第四层分布式任务调度Cluster Mode当单机 ComfyUI 瓶颈显现如显存不足、CPU 编码拖慢、长时间任务阻塞 UIWorkBuddy 支持无缝切换到集群模式。你只需部署多个 ComfyUI 实例可跨机器、跨 GPU 型号并在主控机配置cluster.yamlnodes: - name: rtx4090_a url: http://192.168.1.10:8188 gpu: NVIDIA RTX 4090 tags: [high_mem, fast] - name: a100_b url: http://192.168.1.11:8188 gpu: NVIDIA A100 80GB tags: [large_model, stable] - name: v100_c url: http://192.168.1.12:8188 gpu: NVIDIA V100 tags: [legacy, low_cost] rules: - when: task.name upscale_4x and task.input_size 2000 assign_to: [a100_b] - when: task.name text_to_image and sdxl in task.workflow assign_to: [rtx4090_a, a100_b] - default: [v100_c]调度器基于 Python 的ast.literal_eval安全解析规则表达式实时评估任务特征名称、输入尺寸、workflow 内容、GPU 需求标记动态分配到最优节点。我们实测过 12 节点集群混合 4090/A100/V100千图任务总耗时比单机降低 67%且 GPU 利用率曲线平滑无尖峰——因为 WorkBuddy 会主动避开正在执行长任务的节点优先选择空闲率 70% 的实例。这四层不是理论模型而是我们团队踩坑三年沉淀的操作手册。跳过任何一层都会在后续放大问题。比如没做第一层 capture第二层模板注入可能因 workflow 版本不一致导致崩溃没建第三层 asset pipeline第四层集群调度就会因路径不统一而大量失败。流水线不是堆砌功能而是逐层夯实确定性。3. WorkBuddy 的“流水线”到底流什么解剖它的五大核心数据流很多人以为 WorkBuddy 的流水线就是“输入图→出图→存盘”这条直线。实际上它内部构建了五条并行、可审计、可干预的数据流。理解这些流才能真正掌控整条流水线而不是当个按钮工人。3.1 Prompt 流从文本到可执行指令的精准翻译这是最底层、最关键的流。WorkBuddy 不直接操作 ComfyUI 的节点图而是把所有业务逻辑转化为标准 prompt JSON。它的 prompt 构建分三阶段阶段一模板编译YAML 中的prompt字段经 Jinja2 渲染后得到纯文本 prompt。WorkBuddy 会在此阶段做三项校验长度截断自动截断超过 1500 字符的部分ComfyUI 默认限制并在日志中标记TRUNCATED: 237 chars敏感词过滤内置 127 个常见违规词库如nsfw,nude,blood匹配时触发--safe-mode警告可配置为阻断语法高亮对()、[]、:等权重符号做括号匹配检查避免((red))写成((red)导致解析失败。阶段二Workflow 注入将渲染后的 prompt 文本注入到 workflow JSON 的指定节点。WorkBuddy 通过node_id定位而非节点名称名称易重复。例如{ 6: { class_type: CLIPTextEncode, inputs: { clip: [11, 1], text: A cat sitting on a windowsill... } } }WorkBuddy 会找到node_id: 6将text字段替换为新 prompt。如果 workflow 中存在多个 CLIPTextEncode 节点它会按inputs.text的存在性智能识别——这是比“按名称查找”更鲁棒的方案。阶段三执行体组装最终生成的/prompt请求体是完整的 JSON 对象包含prompt: workflow JSON已注入 promptextra_data: 包含client_id、prompt_id、frontend_node_id等元信息number: 任务序号用于排序ref: 自定义引用字段如project_id: P2024-05会写入 history 记录。实操心得我们曾遇到一批任务在 history 中显示status: success但 output 为空。排查发现是extra_data.client_id未随任务更新导致 ComfyUI 将响应发给了旧客户端。WorkBuddy v0.8.2 起强制为每个任务生成唯一client_id并缓存于本地 SQLite彻底解决此问题。建议所有用户升级至此版本以上。3.2 Asset 流资产生命周期的全链路追踪WorkBuddy 把输入资产视为一等公民赋予其完整生命周期管理资产状态触发条件WorkBuddy 行为审计方式pending任务创建资产路径存在计算 MD5 校验和记录文件大小、修改时间wb asset list --state pendingvalidating任务开始执行前调用预设 validator如 OpenCV 读图、JSON Schema 校验日志输出VALIDATOR_PASS: mask_alpha_channelready校验通过复制资产到临时目录/tmp/wb_assets/xxx/避免原文件被修改ls /tmp/wb_assets/可见隔离副本used任务执行中将临时路径注入 workflow执行完成后保留 24 小时wb asset info --id xxx查看使用记录archived任务成功且archive: true移动到archives/目录按YYYY-MM-DD/{task_name}/归档find archives/ -name *sku123*这个设计解决了两个高频痛点一是多人协作时有人误删/覆盖输入图二是长期运行任务中原始资产被外部程序修改。WorkBuddy 的ready状态确保了执行环境的纯净性而archived状态则提供了法律级可追溯性——所有交付图都能反向查到所用资产的确切版本。3.3 History 流执行过程的不可篡改日志ComfyUI 的/history接口只返回 JSON缺乏结构化查询能力。WorkBuddy 在本地 SQLite 中构建了增强型 history 表CREATE TABLE history ( id TEXT PRIMARY KEY, -- ComfyUI 的 prompt_id task_name TEXT, -- WorkBuddy 任务名 status TEXT CHECK(status IN (success,failed,cancelled)), start_time DATETIME, end_time DATETIME, duration_ms INTEGER, gpu_util_avg REAL, -- 采集自 nvidia-smi gpu_mem_used_mb INTEGER, input_hash TEXT, -- 输入图 MD5 prompt_hash TEXT, -- prompt 文本 SHA256 workflow_hash TEXT, -- workflow JSON SHA256 output_files TEXT, -- JSON array of filenames error_log TEXT );关键创新点在于gpu_util_avg和gpu_mem_used_mb。WorkBuddy 在任务执行期间每 2 秒调用nvidia-smi --query-gpuutilization.gpu,used.memory --formatcsv,noheader,nounits取平均值写入。这让我们能精准回答“为什么这张图生成慢”——不是代码问题而是 GPU 利用率仅 35%说明 workflow 中存在 CPU 瓶颈如 ControlNet 预处理器或“为什么批量失败”——显存峰值达 23.8GB超出 24GB 卡的临界点。注意nvidia-smi采集需sudo权限。WorkBuddy 默认以非 root 用户运行因此提供两种方案① 将用户加入video组sudo usermod -aG video $USER② 配置monitor_gpu: false关闭采集。我们推荐方案①因为 GPU 数据对性能调优至关重要。3.4 Output 流结构化产物的智能归档WorkBuddy 的输出不是简单复制文件而是基于规则的智能归档outputs: - name: final_image type: image path: output/{{ task_name }}/{{ input_name }}_{{ prompt_hash[:6] }}_{{ seed }} format: png quality: 100 - name: metadata type: json path: output/{{ task_name }}/{{ input_name }}_meta include: [prompt, workflow, execution_info, gpu_stats]它会自动创建多级目录如output/portrait_v1/ref_img_abc123_123456789对 PNG 输出应用pngcrush优化体积减少 12~18%默认启用生成_meta.json包含完整 prompt、workflow 片段、执行耗时、GPU 统计若path中含{{ input_name }}会自动从输入文件名提取支持ref.jpg,ref.png,ref.webp若format: webp自动调用cwebp命令行需提前安装。我们曾用此机制支撑一个电商图库项目要求所有输出图必须带 ICC 色彩配置文件。WorkBuddy 的outputs支持icc_profile: sRGB_v4.icc参数自动嵌入到 PNG/WebP 中省去后期批量处理步骤。3.5 Control 流人工干预的标准化接口真正的流水线必须支持“人在环路”。WorkBuddy 提供三类控制接口① 任务级中断wb cancel --id prompt_id发送DELETE /prompt/id到 ComfyUI立即终止执行。不同于 ComfyUI 原生的queue清空它精准到单个任务。② 队列级调度wb queue pause/wb queue resume控制全局执行队列。暂停时WorkBuddy 会持续轮询/queue但不再提交新任务已提交任务继续运行。③ 工作流级热替换wb workflow update --task portrait_v1 --file new_workflow.json。它不会重启 ComfyUI而是将新 workflow JSON 注入下一次任务实现零停机升级。这三条控制流让流水线不再是黑盒。你可以随时介入、调整、修复而所有操作均记录在control_log表中包含操作者who: admin、时间、影响范围。这才是工业级流水线应有的可控性。4. 从零搭建你的第一条流水线手把手实战含避坑清单现在我们来亲手搭建一条真实可用的流水线。目标对input/characters/下的 10 张角色立绘批量生成 3 种不同背景城市、森林、太空共 30 张图。整个过程严格遵循前文四层模型我会标注每一步背后的原理和常见陷阱。4.1 环境准备最小可行依赖WorkBuddy 是纯 Python 工具但依赖项需精确匹配# 创建隔离环境强烈推荐 python3 -m venv wb_env source wb_env/bin/activate # Linux/macOS # wb_env\Scripts\activate # Windows # 安装核心依赖注意版本 pip install comfy-cli0.2.0 # ComfyUI 官方 CLI用于管理实例 pip install workbuddy0.8.5 # 当前最稳版本v0.8.6 有 workflow 注入 bug pip install jinja23.1.2 # 模板引擎 pip install pydantic2.0.0 # 数据验证 pip install psutil5.9.0 # 系统监控GPU 采集必需避坑清单 #1不要用pip install workbuddy安装最新版。v0.8.6 在处理含KSampler (Advanced)节点的 workflow 时会错误覆盖add_noise参数导致所有图噪点异常。v0.8.5 已修复且经过我们 3 个月线上验证。务必锁定版本。4.2 ComfyUI 实例初始化确保底层稳定WorkBuddy 不负责启动 ComfyUI但要求其处于标准状态# 使用 comfy-cli 管理比手动 git clone 更可靠 comfy install --nvidia --cuda-version 12.1 comfy manager install --url https://github.com/ltdrdata/ComfyUI-Manager/releases/download/latest/custom-node-list.json # 安装必要节点Impact Pack用于 face detection、ControlNet Preprocessors用于背景生成 comfy node install https://github.com/ltdrdata/ComfyUI-Impact-Pack comfy node install https://github.com/Fannovel16/comfy_controlnet_preprocessors启动时必须添加关键参数comfy start --listen 127.0.0.1 --port 8188 --enable-cors-header * --gpu-only--listen 127.0.0.1限制仅本地访问避免安全风险--enable-cors-header *WorkBuddy 需要跨域请求否则/prompt调用失败--gpu-only强制禁用 CPU 推理防止后台任务拖慢流水线。避坑清单 #2ComfyUI 启动后务必访问http://127.0.0.1:8188/view?modegraph确认所有节点尤其是 ControlNet显示绿色“Ready”。曾有案例因 Impact Pack 未正确安装节点呈灰色但 WorkBuddy 仍会提交任务导致 history 中全是error: Node not found。4.3 单图 Capture固化第一个原子单元在 ComfyUI WebUI 中加载input/characters/hero1.png构建一个标准 SDXL workflowLoad Checkpoint → CLIPTextEncode (positive/negative) → KSampler → VAEDecode → SaveImage在 SaveImage 节点设置filename_prefix: capture_test点击 Queue等待完成。然后执行 capturewb capture --name char_base --desc SDXL character base workflowWorkBuddy 会生成tasks/char_base/目录。此时检查prompt.json确认inputs.image字段指向input/characters/hero1.png这是 capture 时的绝对路径需改为相对路径手动编辑prompt.json将input/characters/hero1.png替换为{{ inputs.image }}同时在config.yaml中添加inputs: image: input/characters/hero1.png避坑清单 #3Capture 生成的 prompt.json 中路径是绝对路径如/home/user/comfy/input/...。WorkBuddy 在集群模式下无法复现。必须手动改为 Jinja2 变量这是必做步骤无自动化方案。4.4 构建批量配置从单图到多图创建tasks/char_background/config.yaml# 继承基础 workflow workflow: ../char_base/workflow.json # 定义输入资产 inputs: image: input/characters/{{ filename }} # 定义参数变量 prompts: - prompt: - {{ base_prompt }}, background: {{ bg_style }}, {{ quality }} negative_prompt: {{ negative_prompt }} variables: base_prompt: a heroic fantasy character, full body, detailed armor negative_prompt: deformed, blurry, bad anatomy, text, signature bg_style: [cyberpunk city at night, ancient forest with mist, deep space nebula] quality: masterpiece, best quality, 8k, sharp focus filename: [hero1.png, hero2.png, hero3.png, hero4.png, hero5.png, hero6.png, hero7.png, hero8.png, hero9.png, hero10.png] # 输出规则 outputs: - name: final_image type: png path: output/char_bg/{{ filename | replace(.png, ) }}_{{ bg_style | replace( , _) | truncate(10, end) }}_{{ seed }} quality: 100关键点解析workflow: ../char_base/workflow.json复用已 capture 的 workflow保证稳定性filename列表显式列出 10 个文件避免glob模糊匹配导致顺序混乱{{ bg_style | replace( , _) | truncate(10, end) }}Jinja2 过滤器链将cyberpunk city at night转为cyberpunk_c确保文件名合法。4.5 执行与监控观察流水线真实运转执行命令wb run --task char_background --verbose--verbose会输出详细日志包括每个任务的 prompt_id、输入路径、渲染后的 prompt 文本/prompt请求的 HTTP 状态码和响应时间GPU 利用率实时采样每 2 秒一行任务完成后的 output 文件路径。你会看到类似输出[INFO] Task char_background started (30 total) [INFO] Submitting task 1/30: hero1.png cyberpunk city at night [DEBUG] POST http://127.0.0.1:8188/prompt - 200 (124ms) [INFO] Polling for prompt_id: abc123... (timeout: 300s) [INFO] GPU Util: 82% | Mem: 18.2GB/24GB [INFO] Task completed: output/char_bg/hero1_cyberpunk_c_123456789.png避坑清单 #4首次运行若卡在Polling for prompt_id大概率是 ComfyUI 的/history接口未返回数据。检查 ComfyUI 日志常见原因是--enable-cors-header未生效。解决方案在 ComfyUI 启动命令后加--extra-model-paths /path/to/models并确认custom_nodes目录权限为755。4.6 结果验证与故障定位流水线健康的体检报告任务完成后运行健康检查# 检查所有任务状态 wb report --task char_background # 查看失败任务详情 wb report --task char_background --status failed # 验证输出文件完整性 wb validate --task char_background --check outputswb report会生成 HTML 报告包含任务成功率饼图每张图的生成耗时柱状图GPU 利用率热力图按时间轴失败任务的完整 error_log。我们曾用此报告发现一个隐蔽问题hero7.png的生成耗时是其他图的 3 倍。深入error_log发现ControlNet preprocessor failed: CUDA out of memory。根源是hero7.png分辨率高达 4096x6144而 workflow 中的TilePreprocessor未设置tile_size。解决方案在config.yaml中为该文件单独设置tile_size: 512。这就是 WorkBuddy 流水线的核心价值问题不再“凭感觉”而是“有数据”修复不再“靠猜”而是“看日志”。5. 进阶实战把流水线嵌入你的工作流CI/CD、Webhook、API当基础流水线跑通下一步是让它真正融入你的生产环境。WorkBuddy 提供了三类企业级集成能力我们以实际项目为例说明。5.1 CI/CD 自动化Git Push 触发批量出图我们团队用 GitHub Actions 实现“设计稿提交→自动出图→PR 预览”闭环。关键配置.github/workflows/comfy-ci.ymlname: ComfyUI Auto-Render on: push: paths: - input/characters/** - workflows/char_base.json jobs: render: runs-on: ubuntu-22.04 steps: - uses: actions/checkoutv4 - name: Setup Python uses: actions/setup-pythonv4 with: python-version: 3.10 - name: Install WorkBuddy run: | pip install workbuddy0.8.5 pip install psutil - name: Start ComfyUI run: | # 启动 ComfyUI 后台服务 nohup comfy start --listen 127.0.0.1 --port 8188 --enable-cors-header * /dev/null 21 sleep 30 # 等待启动 - name: Run WorkBuddy run: | wb run --task char_background --config tasks/char_background/config.yaml - name: Upload Outputs uses: actions/upload-artifactv3 with: name: rendered-images path: output/char_bg/每次设计师提交新角色图到input/characters/GitHub Actions 自动拉取代码、启动 ComfyUI、执行流水线并将 30 张图打包为 artifact。PR 页面直接展示预览图评审效率提升 5 倍。注意Actions 中nohup启动 ComfyUI 是权宜之计。生产环境应使用 systemd 或 Docker。我们已封装好docker-compose.yml包含 ComfyUI WorkBuddy Nginx用于 artifact 下载可私信索取。5.2 Webhook 集成外部系统触发流水线客户管理系统CRM需要为 VIP 客户实时生成专属海报。我们在 CRM 后端添加 Webhook# CRM 伪代码 def on_vip_order_created(order):