Workbuddy+Codex生成ComfyUI工作流：局域网配置与批量出图实践
以前搭 ComfyUI 工作流，最烦的不是画图本身，而是拼节点。加载模型要拖节点、连线、调参数，遇到 ControlNet、局部重绘、高清放大这些组合场景，面板里密密麻麻全是线。Workbuddy 这类工具出现之后，思路变了：把"我想要一个 SDXL 文生图工作流，输出到 out 目录"这样一句话丢给 Codex 智能体，由它生成工作流 JSON，再导入 ComfyUI 就能跑。这篇文章就是围绕这个组合展开：先说 Workbuddy + Codex 到底能做什么，再讲 ComfyUI 局域网连接怎么配置，最后给出一套从安装、测试到排查的完整流程。
如果你是 ComfyUI 新手、或者想在工作室/团队里多台电脑共用同一套工作流，这篇文章可以收藏备用。下面不聊太多底层原理，重点是把"能用"这条链路跑通，再讨论怎么稳定地用、批量地用、以及哪些地方最容易踩坑。
1. Workbuddy + Codex 核心能力速览
先把关键信息列出来，后续再逐个展开。
| 能力项 | 说明 |
|---|---|
| 项目类型 | AI 智能体驱动的 ComfyUI 工作流生成与管理工具 |
| 核心能力 | 通过自然语言描述生成 ComfyUI 工作流 JSON，也能用于工作流解读、修改和工作流协作 |
| 依赖组件 | Codex（OpenAI 编程智能体）、ComfyUI、对应的自定义节点和模型文件 |
| 对显卡的要求 | 生成工作流本身不直接吃显存；真正跑图时的显存消耗取决于 ComfyUI 中的模型和出图参数 |
| 支持的操作系统 | Windows / Linux / macOS 均具备落地条件，具体以项目文档为准 |
| 启动方式 | 命令行或脚本启动，具体安装与启动命令需按对应项目 README 执行 |
| 是否支持 API | ComfyUI 本身提供 API 接口，Codex 也可接入 API 完成自动化调用 |
| 是否支持批量任务 | 可以结合 ComfyUI 的队列机制批量出图，也适合接入外部自动化流程 |
| 局域网连接 | 通过 ComfyUI 的--listen 0.0.0.0参数暴露服务，其他设备在同一局域网内访问 |
| 适合场景 | 快速搭建工作流、团队共享工作流、ComfyUI 入门、批量出图、接口集成 |
从现有公开信息来看，Workbuddy 的价值不是替代 ComfyUI，而是把"工作流编写"这件事从手动拖节点变成自然语言描述。它本身定位更接近"智能体助手"或"工作流管理中间层"。
2. 适用场景与使用边界
2.1 适合谁用
第一类是刚接触 ComfyUI 的新手。很多人不是不会画图，而是面对一排节点不知道从哪下手。用自然语言描述需求，比如"做一个文生图工作流，使用 SDXL 模型，VAE 自动加载，输出到 out 目录"，Codex 智能体可以协助生成对应的工作流结构，省去翻文档和反复试错的时间。
第二类是需要频繁复用同一套工作流的人。设计师、AI 绘画博主、电商素材制作人员，通常会有几个固定模板：文生图、图生图、高清放大、局部重绘。这些模板一旦通过智能体生成并验证通过，之后每次只需要微调提示词和参数，效率提升非常明显。
第三类是需要在局域网内协作的团队。工作流存在一台电脑上，别人复制过去经常出现节点缺失、模型路径不对的问题。通过局域网连接方案，可以直接把 ComfyUI 服务暴露给同网段的同事，大家在浏览器里访问、测试、出图。
2.2 不适合什么场景
不要把 Workbuddy + Codex 当成"完全不需要了解 ComfyUI"的万能工具。工作流生成之后，节点之间的数据流关系、模型是否匹配、采样参数是否合理，仍然需要人工确认。尤其是复杂的 ControlNet 组合、自定义脚本节点、多段串联流程，智能体生成的 JSON 可能需要多次修正才能正常跑通。
也不适合对网络环境要求极高的离线场景。Codex 智能体需要访问对应服务才能完成推理，如果完全脱离网络，只能使用本地模型替代方案，具体兼容性要看 Workbuddy 是否支持自定义模型接口。
2.3 使用边界与合规提醒
使用这类"智能体生成工作流 + ComfyUI 局域网共享"方案时，有几个问题必须注意：
- 生成图片时，模型权重、训练素材、参考图的版权归属需要自己确认。
- 局域网开放服务时，建议只在可信网络内使用，不要直接暴露到公网。
- 如果涉及人脸、声音、特定人物形象，必须获得对应授权。
- Codex 等智能体会把提示词发送到对应 API 服务，敏感信息不要写进提示词。
3. 环境准备与前置条件
在安装 Workbuddy + Codex 之前，先把基础环境检查一遍，避免后面跑一半卡住。
3.1 操作系统与硬件
Windows 10/11、Linux 发行版、macOS 都能作为 ComfyUI 的运行环境。真正画图推荐 N 卡，使用 CUDA 加速；如果没有 N 卡，也可以用 CPU 推理，但速度会慢很多。要不要独立的 GPU，取决于你实际跑多大的模型。如果只是生成工作流、不做本地出图，集显也能凑合，但验证工作流最终还是要有一台能跑图的设备。
3.2 软件依赖清单
| 依赖项 | 说明 |
|---|---|
| Python | ComfyUI 通常要求 Python 3.10 及以上，推荐 3.10/3.11 |
| Git | 从 GitHub 拉取 ComfyUI 和 Codex 源码时使用 |
| Node.js / npm | 部分 Codex 安装方式依赖 npm 全局安装 |
| CUDA 驱动 | N 卡用户需要安装匹配的显卡驱动和 CUDA 环境，具体版本以 PyTorch 要求为准 |
| ComfyUI | 可以使用官方仓库或秋叶一键整合包 |
| Codex 访问凭证 | 调用 Codex 服务需要对应的 API Key 或登录态 |
| 局域网环境 | 多设备连接需要在同一网段，并放行对应端口 |
3.3 磁盘空间
ComfyUI 基础项目本身不大，但模型文件很占空间。SDXL 基础模型通常 6GB 到 7GB，其他专用模型动辄 2GB 到 5GB。建议至少预留 50GB 可用磁盘空间，方便后续下载多个模型。
3.4 端口与防火墙
ComfyUI 默认端口是 8188。局域网访问时，需要确认 Windows 防火墙或路由器没有拦截该端口。
4. 安装部署与启动方式
4.1 安装 ComfyUI
有两种常见方式，选一种即可。
方式一，使用秋叶一键整合包。这种方式适合 Windows 用户，尤其适合不想折腾 Python 环境的人。整合包把依赖、模型目录、启动脚本都整理好了，解压后按说明启动即可。热词里出现的"comfyui秋叶一键整合包""秋叶comfyui"指的就是这类方案。
方式二，使用官方仓库手动安装。
# 克隆 ComfyUI 仓库 git clone https://github.com/comfyanonymous/ComfyUI.git cd ComfyUI # 创建虚拟环境（推荐） python -m venv venv source venv/bin/activate # Windows 下执行 venv\Scripts\activate # 安装依赖 pip install -r requirements.txt手动安装的优势是环境更可控，升级版本方便；缺点是模型、自定义节点都要自己管理。
4.2 安装 Codex
Codex 的安装方式和版本更新比较频繁，这里不指定固定命令，给出通用思路：
# 如果使用 npm 方式安装，命令格式类似： # npm install -g @openai/codex # 如果你的环境是通过官方安装脚本安装，则从对应页面获取最新脚本安装完成后，需要配置访问凭证。通常是在终端执行登录命令，或者设置环境变量：
# 示例：把 API Key 写入环境变量，具体变量名以 Codex 文档为准 export CODEX_API_KEY="你的 Key"注意，Codex 的具体安装命令、环境变量名、登录方式会随版本变化，务必以官方 README 或对应文档为准。网络热词里出现的"codex安装""codex官网登录入口""codex接入deepseek"，核心都是在解决两个问题：Codex 装在哪、Codex 跑哪个模型服务。如果你计划接入 DeepSeek 等第三方模型服务，还需要在 Codex 配置里指定自定义 endpoint。
4.3 配置 Workbuddy 与 Codex 的连接
Workbuddy 作为上层工具，通常会通过配置文件或环境变量来告诉它"Codex 在哪里、用什么凭证访问"。通用步骤：
- 下载或克隆 Workbuddy 项目。
- 按 README 说明安装项目依赖。
- 配置 Codex 的访问地址和凭证。
- 启动 Workbuddy 服务或命令行交互界面。
# 伪代码示例，实际执行需按项目文档调整 cd workbuddy pip install -r requirements.txt python main.py --codex-endpoint http://127.0.0.1:1234 --output-dir ./workflows4.4 启动 ComfyUI 并开放局域网访问
ComfyUI 默认只监听127.0.0.1，意思是只有本机能访问。要想让局域网内其他设备访问，需要修改启动参数。
# 监听所有网络接口，允许局域网访问 python main.py --listen 0.0.0.0 --port 8188启动后，本机通过http://127.0.0.1:8188访问。同一局域网内的其他电脑，通过http://主机IP:8188访问，主机 IP 用ipconfig或ifconfig查看。
如果 Windows 防火墙弹窗，选择"允许访问"。也可以手动放行端口：
# 管理员权限运行 PowerShell 或 CMD netsh advfirewall firewall add rule name="ComfyUI Web" dir=in action=allow protocol=TCP localport=81884.5 验证安装是否成功
启动完成后，打开浏览器访问 ComfyUI 页面，看到节点面板说明 Web 服务正常。再把 Workbuddy 的测试工作流通过导入功能加载，如果节点能正常显示，说明整个链路已经通了。
5. 功能测试与效果验证
5.1 一句话生成工作流
这是整个方案的核心功能。测试方法：
- 启动 Workbuddy 和 Codex。
- 输入类似这样的自然语言描述："生成一个文生图工作流，使用 SDXL 模型，输出到 out 目录，默认采样步数 20 步。"
- 观察 Codex 是否生成工作流 JSON 文件。
- 把 JSON 导入 ComfyUI，检查节点是否齐全。
判断标准：ComfyUI 中所有节点都是正常颜色，没有红色报错；节点之间的连线完整；模型选择节点能找到对应模型文件。
常见失败原因：
- 工作流里用到了你没安装的模型，节点会显示缺失。
- 工作流里的自定义节点没有安装，ComfyUI 会提示"请安装缺失的包以使用此工作流"。
- Codex 返回的是 UI 格式而不是 API 格式，导入时可能出现兼容问题。
如果遇到红色节点，先在 ComfyUI 的 Manager 里安装缺失的自定义节点，再把模型文件放到models/checkpoints等对应目录。
5.2 文生图基础测试
工作流导入成功后，先做一次基础出图验证。在 ComfyUI 的正面提示词里输入：
a beautiful landscape, morning light, high detail保持默认采样器，点击"运行"。观察进度条、显存占用和最终输出图片。如果图片正常生成，说明工作流的数据流是通的。
5.3 修改工作流再生成
让 Workbuddy 对已有工作流做修改，比如"把采样步数从 20 改成 30""增加一个放大节点"。这一步验证智能体是否理解现有工作流的结构，而不仅仅是生成新的 JSON。测试时注意观察：修改后的工作流是否能直接导入 ComfyUI、是否保留原有节点参数。
5.4 局域网连接测试
在另一台电脑上，用浏览器访问http://主机IP:8188。测试点包括：
- 页面能否正常打开。
- 能否看到同一套工作流。
- 能否提交出图任务。
- 任务执行时，性能消耗是在服务端电脑上。
关键预期：局域网内访问的体验和本机基本一致，出图速度取决于服务器那台电脑的 GPU。如果另一台电脑打不开页面，先检查防火墙、监听地址和两台设备是否在同一网段。
6. 接口 API 调用与批量任务
ComfyUI 本身提供了 API 接口，这也是把工作流接到自动化流程里的关键。
6.1 ComfyUI API 地址
ComfyUI 默认提供/prompt接口，用来提交工作流执行任务。通过 API 可以绕过界面，直接由脚本提交任务，适合批量出图。
6.2 提交任务示例
以下代码是通用调用模板，实际使用时需要把prompt替换成从 ComfyUI 导出的 API 格式工作流。
import json import requests # 从本地文件读取 API 格式的工作流 JSON with open("workflow_api.json", "r", encoding="utf-8") as f: prompt_data = json.load(f) url = "http://127.0.0.1:8188/prompt" payload = { "prompt": prompt_data, "client_id": "local-test" } response = requests.post(url, json=payload, timeout=60) print(response.status_code) print(response.text)返回结果里如果能拿到prompt_id，说明任务提交成功，后续可以用这个 ID 查询任务状态。
6.3 cURL 示例
如果你更喜欢用命令验证接口，也可以使用 curl：
curl -X POST http://127.0.0.1:8188/prompt \ -H "Content-Type: application/json" \ -d @workflow_payload.json6.4 批量任务设计
批量出图的核心思路是：固定工作流，循环替换提示词和输出文件名。可以写一个 Python 脚本，把一组提示词逐条提交到 ComfyUI 队列。
import time import requests api_url = "http://127.0.0.1:8188/prompt" prompts = [ "a cat in the rain, cyberpunk style", "a mountain at sunset, oil painting style", "a robot reading a book, minimalist" ] for i, prompt in enumerate(prompts): workflow = { "3": { "class_type": "CLIPTextEncode", "inputs": { "text": prompt, "clip": ["4", 1] } } # 其他节点省略，需要从实际工作流的 API 格式中获取 } payload = {"prompt": workflow} resp = requests.post(api_url, json=payload, timeout=30) print(f"task {i}: {resp.status_code}") time.sleep(2) # 避免提交过快批次任务建议增加日志记录和失败重试逻辑。记录每个任务的 prompt_id，定时查询任务状态。如果有任务提交失败，检查原因后重试，不要无脑重复提交。
6.5 Workbuddy 与管理端结合
如果 Workbuddy 本身提供了 Web 管理界面或 API 网关，通常会把 Codex 生成的工作流文件和 ComfyUI 的任务队列打通。比如：在 Workbuddy 中保存一个工作流模板，通过脚本自动替换提示词并提交到 ComfyUI。这种模式下，工作流从"智能体生成"到"批量出图"可以形成完整链路。
7. 资源占用与性能观察
7.1 怎么观察资源占用
出图过程中，推荐用任务管理器或nvidia-smi查看 GPU 占用。Windows 下可以先打开任务管理器，切到"性能"标签页，看 GPU 的利用率、显存占用、温度。也可以命令行执行：
nvidia-smi -l 1这样每秒刷新一次，直接看到显存占用和 GPU 利用率。跑大图或者批量出图时，显存占用会比较明显；具体数字取决于模型大小、分辨率、批量数、采样步数，没法一概而论。
7.2 哪些操作最吃资源
一般来说，以下操作会明显增加资源消耗：
- 使用大模型，比如 SDXL 或更大规格的模型。
- 提高出图分辨率，比如从 512x512 提升到 1024x1024。
- 增大批量数，一次跑多张。
- 开启高清放大、ControlNet 等复杂节点。
7.3 降低占用的思路
如果显存不够用，可以调整优先级：
- 降低分辨率，先把构图验证跑通。
- 减少批量数，一次只出一张。
- 降低采样步数，对画质影响可控。
- 使用更轻量级的模型。
- 开启内存优化或低显存模式，具体路径以 ComfyUI 对应版本文档为准。
7.4 局域网模式下的性能分布
在局域网连接模式下，浏览器前端消耗几乎可以忽略。真正的算力消耗集中在运行 ComfyUI 服务的那台电脑上，因此建议：
- 服务器端使用性能较好的 GPU。
- 客户端只负责提交任务和查看结果。
- 如果多人同时使用，注意任务队列排队问题。
8. 常见问题与排查方法
| 问题现象 | 可能原因 | 排查方式 | 解决方案 |
|---|---|---|---|
| 启动后页面打不开 | 服务未启动或端口被占用 | 查看终端日志，检查端口占用 | 更换端口或重启服务 |
| 局域网内其他设备无法访问 | 未监听 0.0.0.0 或防火墙拦截 | 检查启动参数，检查防火墙规则 | 使用--listen 0.0.0.0，放行 8188 端口 |
| 工作流导入后节点红色 | 缺少自定义节点或模型文件 | 查看节点报错信息 | 用 ComfyUI Manager 安装缺失节点，补齐模型 |
| 出现"请安装缺失的包以使用此工作流"提示 | 工作流依赖的 Python 包未安装 | 根据提示在终端安装对应包 | 在 ComfyUI 的 Python 环境中执行安装命令 |
| Codex 调用失败 | 网络不通、API Key 错误、endpoint 配置错误 | 检查凭证、网络、日志 | 重新配置凭证，检查 endpoint 路径 |
报错cc switch local proxy failed while handling codex endpoint /responses | 本地代理切换异常或 endpoint 路径处理失败 | 检查代理配置和 endpoint 地址 | 修正代理和 endpoint 配置，确认路径以/responses结尾 |
| 显存不足，OOM 报错 | 模型 + 分辨率 + 批量数超出显存容量 | 观察nvidia-smi显存占用 | 降低分辨率、批量数，或换轻量模型 |
| 任务提交 API 返回 400 | 工作流 JSON 格式不对 | 检查 API 格式是否完整 | 从 ComfyUI 中使用 API 格式导出工作流 |
| 批量任务卡住 | 队列积压或脚本等待任务状态 | 查看 ComfyUI 队列页面和脚本日志 | 增加超时和重试逻辑 |
| 出图质量不稳定 | 提示词、采样器、步数设置不合适 | 对比不同参数的结果 | 固定一组验证过的参数，再尝试变化 |
上面这些排查思路，适用范围比较广。遇到具体问题，优先看终端日志，日志里通常会写明是模型缺失、路径错误还是网络问题。
9. 最佳实践与使用建议
9.1 第一次先小参数测试
不要一上来就生成一张 2048 分辨率的大图。先用 512x512、20 步、单张批量跑通整条链路，确认工作流没问题以后，再逐步提高参数。这样排查问题时，出问题的地方更少。
9.2 保留一套最小可运行配置
把你验证过能跑通的文生图工作流单独导出一份，作为最小可用配置。以后智能体生成的新工作流出问题时，可以直接对比这份模板，检查少了哪个节点、哪个参数不一致。
9.3 分目录管理文件
建议按下面的结构管理：
ComfyUI/ models/ checkpoints/ 模型主文件 loras/ Lora 模型 controlnet/ ControlNet 文件 output/ default/ 默认输出 test/ 测试输出 batch_20250101/ 批量任务输出 user/ workflows/ 保存的工作流文件把模型、输出、工作流分开存放，备份和迁移都方便。
9.4 批量任务要加日志和失败重试
批量出图不是把 100 张图一次性丢进去就完事。推荐把每次提交的提示词、prompt_id、任务状态、输出路径都记录下来。任务中途卡住或失败时，能快速定位是哪一张图、哪一步出的问题。
9.5 局域网访问注意安全
局域网开放 ComfyUI 服务，虽然比公网安全，但仍要注意：
- 不要在不可信网络中暴露服务。
- 用完及时关闭监听，或者只提供必要时间段的访问。
- 如果路由器支持端口隔离，可以防止设备之间相互探测。
- 不要轻易用 frp、内网穿透等方式把服务暴露到公网。
9.6 涉及人脸、声音、版权素材必须确认授权
使用 AI 绘画、数字人、声音克隆相关功能时，务必确认素材来源合法、肖像授权完整。工作流生成的内容如果用于商用，更要谨慎，避免侵权风险。
10. 总结与下一步
Workbuddy + Codex 这个组合，最值得尝试的点是把 ComfyUI 工作流的搭建门槛从"熟悉节点"变成了"会描述需求"。你不需要背每个节点的名字，只要能把需求表达清楚，智能体就能生成一套可导入的工作流，剩下的事情是在 ComfyUI 里验证和微调。
最先应该验证的功能是"一句话生成基础文生图工作流"。输入描述、生成 JSON、导入 ComfyUI、跑出一张图，这条链路如果通了，说明整体配置没有问题。
最容易踩的坑有两个：一是自定义节点缺失，工作流一导入就是一片红；二是局域网访问时忘记监听0.0.0.0和放行防火墙端口，导致其他设备打不开页面。前者靠补齐节点和模型解决，后者靠检查启动参数和防火墙规则解决。
后续可以继续扩展的方向包括：把 Codex 接入 DeepSeek 等第三方模型服务来降低调用成本；通过 ComfyUI API 把工作流接入自动化发布流程；把批量出图脚本做成定时任务，形成稳定的内容生产管线；甚至可以结合 Dify、Coze 等智能体平台，把"工作流生成 + 出图 + 内容分发"串成一条完整链路。建议先把基础链路跑通，再按实际需求逐步加功能。