如果你第一次接触 ComfyUI，大概率会经历这样的过程：从网上下载一个看起来很专业的工作流 JSON，拖进界面后满屏报错；想用文生图跑一张图，却发现节点之间根本没连对；终于跑通了，想换到另一台电脑上继续用，又卡在局域网访问上。这一连串问题的根因，其实不是 ComfyUI 太复杂，而是我们把太多精力花在了手工作业上。

现在，Codex 这类编程智能体正在改变这个现状。它的重点不是替你画图，而是把“工作流设计”变成可生成、可校验、可复用的代码工件。以 Workbuddy 为代表的智能体工作台，把这种能力封装成更友好的入口：你输入一句话需求，Codex 在后台读取 ComfyUI 工作流规范、生成 JSON、检查节点连接关系，最后输出一个可以直接导入的文件。

这篇文章围绕两件事展开：Workbuddy + Codex 智能体一句话生成 ComfyUI 工作流，以及 ComfyUI 局域网连接配置。前者解决怎么把想法变成可执行的工作流，后者解决怎么把工作流变成多人可访问的服务。读完你可以得到一套完整可复用的链路：自然语言 -> 工作流 JSON -> ComfyUI API 提交 -> 局域网访问。

1. 手写 ComfyUI 工作流到底难在哪里

很多人以为 ComfyUI 难在绘图参数，比如采样器、CFG、调度器。实际用过一段时间后你会发现，真正的难点在于工作流本身的结构组织：哪些节点先执行，哪些数据要传给下一个节点，模型从哪个端口输出，潜空间和像素空间什么时候转换。这些信息都藏在一条条连线里，用鼠标拖节点时看不出来，改起来却容易漏。

传统做法是从别人分享的工作流 JSON 开始，拖进 ComfyUI 后逐个调整。这种方式有几个问题：

第一，别人的工作流往往包含自定义节点，你可能没装对应插件，导入后一堆节点显示红色。第二，你未必看得懂每条连线的含义，想加一个 LoRA 或换一个采样器，不知道应该连到哪里。第三，工作流仅存在于 ComfyUI 界面里，不好版本管理，也不好自动化调用。

Codex 智能体解决的是第三层问题，同时部分缓解第一层和第二层问题。它把工作流当成一种结构化数据来生成：你告诉它想要什么效果，它会根据 ComfyUI 的节点定义，把需求拆解成节点、端口、连线，然后生成完整的 JSON 文件。这比人在界面上手动连线更接近系统工程。

这里有一个值得注意的判断：ComfyUI 工作流本质上是一张有向无环图，节点是算子，连线是数据流。Codex 等大模型最擅长的，就是从自然语言中提取这种结构化关系。所以“一句话生成工作流”并不是玄学，而是大模型对图结构生成能力的自然延伸。

2. ComfyUI 工作流的核心概念与适用场景

要理解智能体如何生成工作流，先要理解 ComfyUI 工作流的文件结构。

2.1 节点、端口与连线

在 ComfyUI 中，每个节点代表一个处理步骤。常见节点包括：

• Load Checkpoint ：加载大模型，输出 MODEL、CLIP、VAE 三个端口。
• CLIP Text Encode ：把提示词编码成 Conditioning，通常用于正向和负向提示。
• Empty Latent Image ：创建空白潜空间图像，指定宽高和批次大小。
• KSampler ：核心采样器，通过调整步数、CFG、采样器和调度器控制生成质量。
• VAE Decode ：把潜空间数据解码为像素图像。
• Save Image ：保存图像文件。

节点之间通过端口连线。比如 Load Checkpoint 的 MODEL 端口连到 KSampler 的 model 端口， CLIP 端口连到 CLIP Text Encode 的 clip 端口。理解端口关系，比记住单个节点的参数更重要。

2.2 workflow.json 的两种格式

ComfyUI 工作流文件有多种写法，最常用的是两种：

格式	特征	典型用途
UI 格式	包含节点坐标、节点尺寸、连线 ID，面向界面导入	拖进 ComfyUI 画布人工调整
API 格式	顶层是节点 ID 到节点配置的映射，不含坐标	通过 /prompt 接口自动提交任务

很多初学者会把这两种格式混在一起看，导致“导入能用但 API 提交报错”或“API 能提交但界面打开报错”。让 Codex 生成工作流时，一定要在 Prompt 里说明格式，或者在生成后单独做一次校验。

2.3 为什么适合交给智能体生成

ComfyUI 工作流本质上是结构化 JSON，节点和端口都有明确 ID 和类型。这种格式对自然语言模型非常友好，因为它不需要模型理解图像本身，只需要模型理解规则和依赖关系。

举个例子，你写“生成一张 1024x1024 的风景图，SDXL 模型，步数 25，CFG 7”，Codex 需要完成的映射是： Load Checkpoint -> CLIP Text Encode -> EmptyLatentImage -> KSampler -> VAE Decode -> Save Image 。这套映射关系是稳定的，和代码函数调用非常相似。模型训练时见过的代码足够多，对这种结构并不陌生。

当然，Codex 生成出来的工作流质量取决于节点知识的准确性。如果你使用的 ComfyUI 版本比较新，某些节点参数有变化，模型可能给出旧格式。稳妥的方式是让 Codex 先生成，再用脚本或 ComfyUI Manager 校验，而不是直接信任输出。

3. 环境准备：Codex CLI 与 ComfyUI 安装前提

在开始生成工作流之前，先把环境准备好。本文会同时涉及 Codex 和 ComfyUI 两部分，建议按顺序配置。

3.1 Codex 环境准备

Codex 通常以 CLI 形式出现，你需要在终端里能够直接输入 codex 并开始对话。安装方式以你使用的官方文档为准，这里不做版本绑定。核心要求是：

• 终端可执行 codex 命令。
• 已配置模型访问凭据。
• 能够正常调用模型服务接口。

如果你使用的是 OpenAI 官方服务，一般只需要在环境变量里配置 API Key。如果你使用的是兼容接口的模型网关，比如团队自建网关或国内可访问的开放平台，Codex 也支持通过自定义 provider 指定接口地址。一个常见的配置位置是 ~/.codex/config.toml ，示例结构如下：

# 文件路径：~/.codex/config.toml
model = "gpt-5-codex"
model_provider = "openai"

[model_providers.openai]
name = "OpenAI"
base_url = "https://api.openai.com/v1"
env_key = "OPENAI_API_KEY"

如果你的模型接口不是 OpenAI 官方，而是某个兼容服务，只要该服务支持 Codex 客户端调用的协议，就可以把 base_url 替换成对应接口地址。需要注意，不同模型服务的接口格式可能不同， /responses 端点和普通的聊天补全接口不是一回事，配置时以平台文档为准。

3.2 ComfyUI 安装

ComfyUI 的安装方式相对成熟。Windows 用户常用的是秋叶一键整合包，本质上是把 Python 环境、PyTorch、ComfyUI 主程序和常用模型打包在一起，省去手动装依赖的步骤。如果你熟悉 Conda 或者直接使用官方仓库，也可以自行安装。

安装完成后，先在本机启动一次 ComfyUI，确认默认地址 http://127.0.0.1:8188 能正常打开界面。之后再考虑局域网访问。启动命令通常类似：

python main.py

如果你的机器配置了多个 Python 环境，确保使用的是安装依赖时的那个 Python。整合包用户一般启动主程序即可，不需要手动配置 Python。

3.3 模型文件放在哪里

ComfyUI 默认从 models/checkpoints 加载大模型，从 models/loras 加载 LoRA，从 models/vae 加载 VAE。让 Codex 生成工作流之前，先确认你实际有哪些模型文件，并把真实的模型名发给 Codex。如果工作流里写的模型名不存在，即使 JSON 结构正确，任务也会执行失败。

这里最容易被忽略的一点是：模型文件名必须带后缀，比如 sd_xl_base_1.0.safetensors 。让 Codex 生成 Prompt 时，把文件名列出来，能减少后面排查问题的时间。

4. Workbuddy + Codex 智能体生成工作流：实操步骤

下面进入核心实操。假设你已经在终端里启动 Codex，或者使用 Workbuddy 这类智能体工作台来交互。整体流程是一样的：描述需求 -> 生成 JSON -> 保存文件 -> 校验 -> 导入 ComfyUI。

4.1 创建项目目录

建议为每个工作流单独建一个目录，方便后续版本管理。

mkdir comfyui-workflows
cd comfyui-workflows

4.2 编写 Prompt 模板

“一句话生成工作流”不等于随便说一句话。为了让 Codex 输出可用的结果，Prompt 应该包含：

• 目标效果：文生图、图生图、局部重绘还是批量处理。
• 使用的模型文件名。
• 关键采样参数。
• 输出格式要求：API 格式还是 UI 格式。
• 是否需要生成说明文档。

一个推荐模板如下：

请帮我生成一个 ComfyUI 文生图工作流，使用 API 格式 JSON。

要求：
1. 加载模型：使用 models/checkpoints 目录下的 sd_xl_base_1.0.safetensors
2. 正向提示词：a beautiful landscape, sunlight, mountains, lake
3. 负向提示词：blurry, low quality, watermark
4. 采样器：KSampler，步数 25，CFG 7.0
5. 采样方法：dpmpp_2m，调度器：karras
6. 图像尺寸：1024x1024
7. 输出：Save Image 节点，文件名前缀 workbuddy_codex
8. 必须包含完整节点连线，不要省略端口

输出到文件 workflow.json，并简要说明每个节点的作用。

这里的关键是把“必须包含完整节点连线”写进去。如果不加这句，Codex 可能只输出一个简化结构，缺少中间节点，导致导入后无法运行。

4.3 让 Codex 保存文件

Codex 和普通聊天模型的最大区别是它能读写当前项目目录下的文件。在对话中要求“输出到文件 workflow.json”，比复制代码块更可靠。生成结束后，检查项目目录里是否真的有这个文件。

4.4 校验生成的 JSON

Codex 生成的文件不一定一次就完全正确，尤其是当你使用的 ComfyUI 节点版本较新时。建议先写一个简单脚本来检查 JSON 格式和基本节点结构。下面是一个最小校验脚本：

# 文件路径：check_workflow.py
import json
import sys

def main(path):
    with open(path, "r", encoding="utf-8") as f:
        data = json.load(f)

    # API 格式的特征：顶层是节点 ID 到节点配置的映射
    if isinstance(data, dict) and all(
        isinstance(v, dict) and "class_type" in v for v in data.values()
    ):
        print("识别为 API 格式，节点数量：", len(data))
    else:
        print("当前不是 API 格式，可能包含 nodes/links 等 UI 字段")

    # 检查关键节点是否存在
    class_types = [v.get("class_type", "") for v in data.values()]
    required = ["CheckpointLoaderSimple", "KSampler", "SaveImage"]
    for name in required:
        if name in class_types:
            print(f"已找到节点：{name}")
        else:
            print(f"缺少节点：{name}")

if __name__ == "__main__":
    main(sys.argv[1])

运行方式：

python check_workflow.py workflow.json

如果输出显示缺少 KSampler 或 SaveImage ，说明 Codex 生成不完整，可以要求它补全。

4.5 导入 ComfyUI

把 workflow.json 拖入 ComfyUI 界面。如果使用的是 API 格式，ComfyUI 也能识别，但界面布局可能是自动生成的，节点位置会比较乱。如果更希望得到整齐的界面布局，可以要求 Codex 同时生成 UI 格式版本。

导入后如果看到红色节点，说明缺少自定义节点或依赖包。先看看报错信息，把缺失的节点名称交给 Codex，让它给出安装建议，也可以直接使用 ComfyUI Manager 安装。

5. 通过 ComfyUI API 自动化调用工作流

工作流生成之后，下一步是让它能够被程序调用。ComfyUI 自带 HTTP API，常用端点包括：

• POST /prompt ：提交一个工作流任务。
• GET /history/{prompt_id} ：查询任务执行状态和结果。
• GET /view?filename=xxx ：获取输出图片。

下面用 Python 标准库写一个最简单的提交脚本，不依赖第三方库，方便复制运行。

# 文件路径：submit_workflow.py
import json
import time
import urllib.request

COMFYUI_URL = "http://127.0.0.1:8188"

def load_workflow(path):
    with open(path, "r", encoding="utf-8") as f:
        return json.load(f)

def submit_prompt(workflow):
    payload = json.dumps({"prompt": workflow}).encode("utf-8")
    req = urllib.request.Request(
        f"{COMFYUI_URL}/prompt",
        data=payload,
        headers={"Content-Type": "application/json"},
    )
    with urllib.request.urlopen(req) as resp:
        return json.loads(resp.read().decode("utf-8"))

if __name__ == "__main__":
    workflow = load_workflow("workflow.json")
    result = submit_prompt(workflow)
    print("提交结果：", result)

    prompt_id = result.get("prompt_id")
    if prompt_id:
        for _ in range(60):
            time.sleep(2)
            with urllib.request.urlopen(
                f"{COMFYUI_URL}/history/{prompt_id}"
            ) as resp:
                history = json.loads(resp.read().decode("utf-8"))
            if prompt_id in history:
                print("任务执行完成")
                break
        else:
            print("等待超时")

运行命令：

python submit_workflow.py

如果工作流是 API 格式，并且模型名存在，脚本会输出一个 prompt_id ，随后轮询查询执行状态。看到“任务执行完成”说明整条链路已经打通。

这里要提醒一个常见误区：ComfyUI 的 POST /prompt 接口只接受 API 格式，不一定接受从界面导出的 UI 格式。如果你的工作流是从界面导出的，提交前需要先转换格式，或者让 Codex 专门生成 API 版本。

6. ComfyUI 局域网连接配置

工作流能在本机运行之后，很多人会想把它暴露给局域网内的其他设备。比如另一台电脑希望调用 ComfyUI 出图，或者想把界面分享给同事试用。默认情况下，ComfyUI 只监听 127.0.0.1 ，也就是说只有本机能访问。要让局域网内其他设备访问，需要做三件事。

6.1 修改启动参数，监听所有网卡

启动 ComfyUI 时加入 --listen 0.0.0.0 参数：

python main.py --listen 0.0.0.0 --port 8188

0.0.0.0 表示监听所有网络接口，不只是回环地址。如果你使用的是整合包，一般在启动器里可以勾选“局域网访问”或“服务模式”，本质是给启动命令加上同样的参数。

启动后再确认一下本机访问 http://127.0.0.1:8188 是否正常。如果本机正常，说明服务已经启动成功。

6.2 确认本机局域网 IP 并测试访问

在 ComfyUI 所在的机器上查看 IP：

ipconfig

或者 Linux 下：

ip addr

找到局域网网卡的 IP，比如 192.168.1.100 。然后在局域网内的另一台设备访问：

http://192.168.1.100:8188

如果页面能打开，说明监听配置已经生效。

6.3 放行防火墙端口

如果本机能访问，但局域网内其他设备无法访问，最常见的原因是系统防火墙拦截了 8188 端口。Windows 上可以执行：

netsh advfirewall firewall add rule name="ComfyUI 8188" dir=in action=allow protocol=TCP localport=8188

Linux 上如果使用 ufw，可以执行：

sudo ufw allow 8188/tcp

放行端口后重新测试。如果还是不通，检查两台设备是否在同一个网段，是否连接了同一个路由器或交换机。

6.4 安全边界提醒

必须强调一点： --listen 0.0.0.0 意味着局域网内所有设备都能访问你的 ComfyUI 服务，而且 ComfyUI 默认没有复杂的身份认证机制。在可控局域网内使用问题不大，但不要轻易把这个端口映射到公网。如果确实需要在更广泛的网络中使用，建议在前面加一层带认证的反向代理，或者在防火墙层面做来源 IP 白名单。

另外，如果你开启了虚拟机和容器，也要注意端口映射问题。ComfyUI 运行在宿主机时，虚拟机里的环境不一定能直接访问宿主机的 0.0.0.0 监听，需要确认网络模式是否允许。

7. 常见问题与排查思路

下面是这个链路里最容易遇到的几个问题，整理成表格方便排查。

问题现象	可能原因	排查方式	解决方案
Codex 调用时报 local proxy failed while handling codex endpoint /responses	Codex 客户端到模型服务的链路异常，常见是接口地址、凭据或本地网络代理配置不对	检查 Codex 配置文件中的 base_url 和 API Key；确认模型服务是否能访问；重启 Codex 客户端	修正配置，换成可达的服务地址，重新发起对话
导入工作流后提示“请安装缺失的包以使用此工作流”	工作流依赖了未安装的自定义节点	查看提示中给出的缺失节点名称和安装命令	在 ComfyUI 对应的 Python 环境中安装缺失包，或使用 ComfyUI Manager 安装，然后重启服务
本机能访问 ComfyUI，但局域网其他设备打不开	防火墙拦截端口，或服务只监听了 127.0.0.1	检查启动参数是否包含 --listen 0.0.0.0 ；检查防火墙 8188 端口是否放行	按第 6 节配置监听地址和防火墙规则
提示 GPU 显存不足	当前显存不足以加载整个模型，或显存被其他程序占用	查看任务管理器或 nvidia-smi ，确认显存占用	使用 --lowvram 参数启动；降低图片尺寸和 batch_size；关闭其他占用显存的程序；更换轻量模型
提交 API 时报错，界面导入却正常	工作流是 UI 格式，不是 API 格式	用校验脚本检查 JSON 结构	让 Codex 重新生成 API 格式 JSON，或手动将 workflow 转换为 API 格式
电脑能访问互联网，但访问不了局域网其他设备	连接了访客网络，或开启了 AP 隔离，或手动 IP 配置有误	检查网络类型和 IP 配置，确认两台设备在同一网段	切换到主网络，关闭 AP 隔离，恢复 DHCP 自动获取 IP

7.1 进阶排查：为什么 IP 能通但访问不了服务

很多时候，局域网访问不了并不是 ComfyUI 本身的问题，而是二层网络隔离。如果你连接的是 Wi-Fi，并且路由器开启了“AP 隔离”或“访客网络隔离”，无线客户端之间无法直接通信。表现就是本机能上网，却无法访问同一局域网内其他设备的服务。

检查方法是在目标机器上执行 arp -a ，查看目标 IP 对应的 MAC 地址。如果显示的是网关的 MAC，而不是目标主机的 MAC，说明二层通信没有到达目标主机。这种时候要回到路由器配置，确认是否开启了隔离模式。

如果 IP 和 MAC 都正常，那问题大概率出在防火墙或监听地址上，按第 6 节的顺序继续排查即可。

8. 工作流工程化与最佳实践

把 Codex 生成工作流、ComfyUI API 提交、局域网访问这三条链路组合起来，已经具备一个小型 AI 图像服务的基本形态。但要稳定地用在真实项目里，还需要考虑工程化问题。

8.1 把工作流当代码管理

工作流 JSON 应该纳入版本管理，和代码一起提交。目录结构可以参考：

comfyui-workflows/
├── workflows/
│   ├── txt2img.api.json
│   ├── txt2img.ui.json
│   └── img2img.api.json
├── scripts/
│   ├── check_workflow.py
│   └── submit_workflow.py
├── README.md
└── requirements.txt

每次修改工作流，保留一份可读的说明，记录改了哪些节点、为什么改。这样过一段时间回头看仍然能理解。缺点是 JSON 文件里的节点 ID 不直观，可以在 README 里画一个文字版的节点流转图。

8.2 记录节点依赖

ComfyUI 工作流越复杂，依赖的自定义节点越多。建议把工作流用到的所有自定义节点和依赖包记录在 requirements.txt 或 README 里。这样换一台机器恢复环境时，不需要从报错里一个个猜。

需要注意，ComfyUI 整合包通常自带 Python 环境，使用 pip 安装包时一定要对准整合包的 Python，而不是系统 Python。如果在终端直接执行 pip install ，很可能装到了错误的环境里。

8.3 参数化与批处理

当你希望批量生成图片时，不要直接修改 workflow.json ，而是把经常变化的参数抽出来。比如种子、提示词、图片尺寸、模型名称，都可以放在一个 Python 脚本的配置区，生成参数后动态写入工作流 JSON，再提交。

这也正是 Codex 的用武之地。你可以让 Codex 生成一个封装脚本，读取一组 CSV 或 JSON 配置，自动替换工作流里的参数，然后批量提交。这样的好处是任务可重复，结果可追溯。

8.4 安全与最小权限原则

ComfyUI 本身不包含完善的多用户认证体系，所以对外提供访问时一定要控制边界。在局域网内使用，只放行必要端口，并限定来源 IP。在更大的网络中使用，建议放在内网服务后面，由统一入口做身份认证和访问控制。

Codex 生成的代码也一样。执行前先看一遍它要运行的命令，尤其涉及文件删除、密钥读取、网络请求时，不要盲目信任。大模型生成的脚本可以作为起点，但不能替代人做安全审查。

8.5 验证链路要完整

在实际项目里，不要只验证“工作流在界面能跑”。完整验证链路应该包括：

• 生成的工作流 JSON 是否能通过格式校验。
• API 提交是否能返回 prompt_id 。
• 任务执行后是否真的生成了图片文件。
• 局域网内其他设备是否能访问服务。
• 模型文件名变更后，工作流是否仍然可用。

跑通这五步，才算真正把智能体生成工作流的流程落地。

9. 总结与下一步实践

Workbuddy + Codex 智能体生成 ComfyUI 工作流，本质上是把传统的“手工连线”变成“自然语言描述 + 结构化生成”。ComfyUI 工作流作为一张有向无环图，天然适合大模型去理解和生成。而局域网连接配置，则是把 ComfyUI 从单机演示推向多人可用服务的关键一步。

如果你今天只做一件事，我建议不要急着搭建复杂工作流。先让 Codex 生成一个最简的文生图工作流，存成 API 格式，用脚本提交一次，再配置局域网访问。这个“一句话生成 + 一次 API 调用 + 一次局域网访问”的链路跑通后，后面无论接入更多模型、批量出图，还是把工作流接到业务系统里，思路都是同一套：把工作流当代码，把 ComfyUI 当服务。