最近这阵子，AI绘画圈子里讨论最多的组合，已经不再单纯是“生成一张图”了，而是“怎么让 AI 帮我把整套 ComfyUI 工作流搭起来”。标题里那个 Workbuddy，看着像一个独立产品，但拆开看，它的核心其实是三件事绑在一起：Codex 这个能写代码、能操作文件的智能体，ComfyUI 这种节点式工作流引擎，再加上让人头疼的局域网连接问题。

先说我的判断：Codex 这类智能体，确实把 ComfyUI 工作流的“生成成本”降了一个量级。以前拖半天节点才能接好的流程，现在一句话能给你一份 JSON。但别高兴太早——生成 JSON 不等于一键可跑。工作流里缺节点、模型路径不对、显存不够、局域网同事访问不到，这些问题一个都不会因为“用了智能体”而自动消失。甚至可以说，智能体越强，你越需要具备判断它输出是否靠谱的基本功。

这篇文章就把这三个环节拆开讲：Codex 怎么装、怎么让它生成 ComfyUI 工作流；生成之后加载报“缺失包”怎么处理；最后是本机跑通之后，怎么让局域网里的其他机器访问，以及最常踩的几个网络排查思路。文章尽量不写空话，给的是可以直接复制运行的命令和判断方法。

1. 这篇文章真正要解决的问题

如果你是 ComfyUI 玩家，下面几种场景你一定不陌生：

第一，搭工作流太费时间。文生图、图生图、局部重绘、批量处理，节点一多，连线一乱，整个画布就是一团线。改一个参数，要找半天节点在哪。

第二，别人分享的工作流，你下载下来一加载，满屏红色报错。要么提示“请安装缺失的包以使用此工作流”，要么提示“要安装缺失的节点，请先在你的 Python 环境中运行”。看到这句提示就头大。

第三，本机能正常打开 ComfyUI，但局域网里的另一台电脑访问不了。更诡异的是，那台电脑能上外网，却连不上局域网，连网关地址都 ping 不通。

第四，显卡明明还行，一跑工作流就提示 GPU 显存不足。在 5070 这类显卡上跑稍大的模型，表现尤为明显。

这篇文章不会只给你一句“用智能体生成工作流”的漂亮话，而是把从安装、生成、加载、运行到局域网访问的完整链路走一遍。你读完能获得三样东西：一套用 Codex 生成 ComfyUI 工作流的可操作流程；一份加载外部工作流时缺失节点的处理方法；一组从本机到局域网连接失败的排查命令和判断逻辑。

适合读这篇文章的读者，大致有三类：想让 AI 智能体帮自己搭 ComfyUI 工作流的 AI 绘画用户；在 Windows 上用秋叶一键整合包跑 ComfyUI、但遇到各种环境问题的开发者；以及准备在团队里共享 ComfyUI 服务、需要处理局域网访问和排障的运维型玩家。

2. Codex 智能体与 ComfyUI 工作流：它们是怎么结合起来的

2.1 Codex 不只是聊天工具，而是能动手干活的智能体

很多人第一次接触 Codex，以为它就是一个能回答代码问题的聊天窗口。实际上，Codex 更适合被理解为一个“命令行智能体”：它能读取项目里的文件，能修改代码，能执行命令，还能在完成一步之后继续下一步。

这意味着，你给它一个任务，它不只是给你建议，而是真的去操作。比如你可以让它“把这个 JSON 文件里除了文生图之外的所有节点删掉，重新连线，并保存到指定目录”。它做得到。

Codex 和 ComfyUI 工作流的结合点就在这里：ComfyUI 的工作流本质是一个 JSON 文件，里面的节点、参数、连线关系全部是结构化数据。而“生成、修改、校验结构化文本”，恰恰是代码智能体最擅长的事情。

与其把这说成“AI 会画工作了”，不如说它是“AI 会用代码的方式帮你组装节点”。一字之差，决定了你后续怎么用、怎么排查问题。

2.2 ComfyUI 工作流的本质是 JSON

ComfyUI 是一款基于节点图的 AI 绘画工具。你不需要写程序，而是把“加载模型”“文本编码”“采样器”“解码”“保存图片”这些节点拖到画布上，再一条一条连起来。每个节点负责一个具体步骤，节点的参数控制生成效果。

这套节点图保存到本地，就是一个 JSON 文件。工作流里有哪些节点、节点之间的连线是什么、每个节点的参数是多少，全都在这个 JSON 里。

所以，当 Codex 说“我给你生成一个工作流”，它真正生成的是一份 JSON。你可以直接把它保存到 ComfyUI 的工作流目录里，然后在界面上加载。

2.3 “一句话生成工作流”的现实边界

这里必须泼一盆冷水。

Codex 能生成可运行的工作流 JSON，这在简单场景下完全没有问题，比如基础的文生图、图生图、局部重绘。但“一句话生成”代表的是起点，不是终点。一份工作流能不能真正跑起来，还取决于：

• 你的模型文件是否存在、路径对不对；
• 你本地是否安装了工作流里引用的自定义节点；
• 你显卡的显存能不能撑住节点里配置的分辨率和 batch size；
• 模型格式是否匹配（比如你是 SD1.5 模型还是 SDXL/SD3 模型）；
• 你用的 ComfyUI 版本和自定义节点版本是否兼容。

所以，“一句话生成工作流”的真实价值，是把过去半小时的拖拽工作压缩成几十秒。代价是生成之后，你需要掌握加载、验证、补缺失节点、调显存这一套基本功。这也是后面几个章节要解决的问题。

3. 环境准备与前置条件

开始实操之前，先把环境说清楚。这篇文章的例子，默认在 Windows 上操作，但命令本身在 macOS 和 Linux 上也能对应找到。

3.1 安装 Codex

Codex 的官方安装方式以官方文档为准，最常见的做法是通过 npm 全局安装 CLI 工具。如果你电脑上有 Node.js 环境，在命令行执行：

npm install -g @openai/codex
codex --version

安装完成后，需要登录 OpenAI 账号才能使用：

codex login

登录之后，会进入命令行交互界面。你在里面输入自然语言任务，Codex 会读取当前目录下的文件、执行命令、生成代码。

有一点必须提前说明：Codex 是可以执行命令的智能体，所以不要在你不信任的目录里放敏感文件，也不要让它执行来源不明的脚本。这一点后面还会再强调。

如果你用的是非官方模型服务，比如想接入 DeepSeek 这类兼容接口的服务，需要在配置里指定接口地址和密钥。具体配置方法在第 8 章会单独讲，这里先不展开。

3.2 安装 ComfyUI

ComfyUI 的安装有两条主流路线，选择哪条取决于你的使用习惯。

路线一：官方手动安装。适合想自己控制环境、不依赖整合包的开发者。

git clone https://github.com/comfyanonymous/ComfyUI.git
cd ComfyUI
pip install -r requirements.txt
python main.py

这条路线干净，但要自己处理 Python 环境、CUDA 版本、依赖冲突。如果你对 Python 虚拟环境不熟悉，很容易在依赖上卡住。

路线二：秋叶一键整合包。这是目前 Windows 用户最多的方式。整合包把 Python 环境、PyTorch、ComfyUI 本体、常用模型管理工具、启动器全部打包在一起，解压就能用。

选择整合包有一个隐藏点：它自带的 Python 是内置的，一般放在整合包目录下的 python_embeded 或类似目录里。后面手动安装缺失依赖包时，就要使用这个内置的 Python，而不是你系统里的 Python。很多报错，都是因为用错了 Python 环境导致的，这一点非常值得留意。

对比维度	官方手动安装	秋叶一键整合包
上手难度	较高	较低
环境可控性	高	中
手动装依赖	直接用系统 Python 环境	需要定位内置 Python
排错难度	自己面对所有依赖	启动器已处理大部分
推荐人群	熟悉 Python 的开发者	纯 AI 绘画用户

3.3 确认显卡与 CUDA 环境

无论走哪条路线，都要先确认显卡能被识别。在命令行执行：

nvidia-smi

能看到显卡信息、驱动版本和显存占用，说明驱动正常。这里不用纠结驱动就一定是新的，只要能被 nvidia-smi 识别即可。

接着在 ComfyUI 所在 Python 环境里确认 PyTorch 能不能调用 GPU。如果用的是秋叶整合包，进入整合包目录后用内置 Python 执行：

import torch
print(torch.__version__)
print(torch.cuda.is_available())
print(torch.cuda.get_device_name(0))

如果 torch.cuda.is_available() 返回 True ，说明框架层面没问题。如果返回 False ，后面跑工作流大概率会极其卡顿或者直接失败，这时候要先解决 CUDA 版本问题，而不是急着生成工作流。

4. 用 Codex 生成 ComfyUI 工作流：完整流程拆解

4.1 第一步：定义清楚你想要的场景

用智能体生成工作流，最关键的不是智能体的能力，而是你的输入是否明确。很多人一句话生成翻车，是因为需求本身就是含糊的。

不能只说“给我生成一个工作流”，而要说明：

• 任务类型：文生图、图生图、局部重绘，还是批量处理；
• 目标模型：本地有什么模型文件，是 SD1.5 还是 SDXL；
• 输出要求：保存为 ComfyUI 可以直接加载的 workflow JSON；
• 保存位置：保存到 ComfyUI 的哪个 workflows 目录。

比如，你可以从命令行启动 Codex，然后输入这样一段话：

你是 ComfyUI 工作流专家。请帮我生成一个基础文生图工作流。

要求：
1. 使用 SD1.5 或 SDXL 模型。
2. 节点包含：加载检查点模型（Load Checkpoint）、CLIP 文本编码（CLIP Text Encode）、空 Latent 图（Empty Latent Image）、KSampler 采样器、VAE 解码（VAE Decode）、保存图片（Save Image）。
3. 采样器参数设置为：steps=20，cfg=7，sampler_name=euler，scheduler=normal，seed 用动态值。
4. 输出为完整可用的 ComfyUI workflow JSON 格式。
5. 将结果保存到 ComfyUI/user/default/workflows/my_first_workflow.json
6. 不要省略节点，不要使用占位符以外的自定义节点。

这里的重点是“不要省略节点”和“不要使用占位符以外的自定义节点”。如果你不强调这两点，智能体很可能生成一个结构漂亮但依赖一堆你没装过的节点的“理想化工作流”。

4.2 第二步：检查并验证生成的 JSON

Codex 生成结果后，不要直接丢进 ComfyUI。先用 Python 验证一下 JSON 格式是否合法：

import json

with open("my_first_workflow.json", "r", encoding="utf-8") as f:
    data = json.load(f)
print("JSON 合法")
print("节点数量：", len(data.get("nodes", [])))

如果 JSON 解析失败，说明智能体生成的 JSON 有语法问题，让 Codex 重新修复，直到通过校验为止。

这里有一个非常实用的判断标准： 生成结果的质量，要看它是否使用了你本地真实存在的模型文件名，而不是随随便便写一个模型名。 你可以先打开工作流 JSON，搜索 .safetensors 或 .ckpt ，看里面的模型文件名是否和你 ComfyUI/models/checkpoints 目录下的文件一致。不一致的话，后面加载必然会报模型找不到。

4.3 第三步：把工作流保存到正确目录

ComfyUI 会在 user/default/workflows/ 目录下存放工作流文件。Codex 生成的 JSON 需要放到这个目录，刷新浏览器页面后，才能在 Workflow 菜单里看到。

假设你的 ComfyUI 在 D:\ComfyUI ，那么路径就是：

D:\ComfyUI\user\default\workflows\my_first_workflow.json

如果你用的是秋叶整合包，路径类似，只是外层目录名可能不同。不确定的话，在整合包目录下搜索 workflows 文件夹即可。

4.4 第四步：加载工作流

打开 ComfyUI 页面后，在 Workflow 菜单里选择 Open，找到 my_first_workflow.json 并加载。

如果一切正常，你会看到节点图铺满画布。如果界面上出现红色节点，说明有自定义节点缺失，这就进入了第 5 章的流程。

4.5 一个最小工作流的结构长什么样

为了让不熟悉 JSON 结构的读者有个概念，这里给一个工作流文件的骨架示例。实际使用时，数据会比这个复杂得多，但结构上是相近的：

{
  "last_node_id": 6,
  "last_link_id": 5,
  "nodes": [
    {
      "id": 1,
      "type": "CheckpointLoaderSimple",
      "pos": [50, 100],
      "size": [300, 100],
      "widgets_values": ["你的本地模型名.safetensors"]
    },
    {
      "id": 2,
      "type": "CLIPTextEncode",
      "pos": [400, 100],
      "widgets_values": ["a beautiful landscape"]
    },
    {
      "id": 4,
      "type": "KSampler",
      "pos": [750, 100],
      "widgets_values": [20, 7, "euler", "normal"]
    }
  ],
  "links": [
    [1, 1, 3, 1, "CLIP"],
    [2, 1, 4, 6, "CONDITIONING"]
  ]
}

这个骨架只是为了让你理解“节点”和“连线”在 JSON 里是怎么表达的，不要直接拿去运行。实际可运行的工作流，需要每个节点的完整参数、坐标、连线顺序全部正确。

5. 加载工作流时的“缺失节点”与“缺失包”处理

5.1 报错信息到底在说什么

当你加载一个别人分享的工作流，或者 Codex 生成的工作流引用了本地没有的节点，ComfyUI 通常会弹出提示。常见的提示是：

请安装缺失的包以使用此工作流。
要安装缺失的节点，请先在你的 Python 环境中运行。

这句话其实分成两层意思：

第一层，工作流里引用了某个自定义节点类型，但你的 ComfyUI 里没有安装对应的插件或扩展。这个叫“缺失节点”。

第二层，即使节点插件装了，它可能还依赖额外的 Python 包。这个叫“缺失包”。

把这两件事分开，后面处理起来就清晰了。

5.2 优先使用 ComfyUI Manager

处理缺失节点，最推荐的做法是安装 ComfyUI Manager。它是 ComfyUI 的插件管理器，可以扫描工作流里缺失的节点，并在插件中心搜索安装。

安装 Manager 之后，加载工作流时它会直接提示“工作流缺少节点”，并列出缺失的节点 ID 和名称。你只需点击搜索，选择对应的插件仓库安装即可。大部分情况下，Manager 会在安装节点的同时处理掉它的 Python 依赖。

这不只是省事，更是安全考量：自己手动安装依赖时，如果不清楚来源，很可能会执行到有问题的安装命令。用 Manager 从官方插件源安装，风险会低很多。

5.3 手动安装缺失包的流程

有些场景下 Manager 也解决不了问题，比如节点已经安装，但报错说缺少某个 Python 包。这时候就必须手动安装。

安装之前，先明确你用的到底是哪个 Python 环境。这里最容易踩坑。

如果你用的是秋叶整合包，不要直接打开一个命令行跑 pip install xxx ——那大概率装到了系统 Python 里，ComfyUI 根本不会使用它。正确的做法是，进入整合包目录，找到它内置的 Python 可执行文件，一般是：

你的整合包目录/python_embeded/python.exe

然后在这个目录下打开终端，执行：

cd /d D:\你的整合包目录
python_embeded\python.exe -m pip install 包名

如果你用的是官方手动安装，并且已经创建了虚拟环境，先激活虚拟环境再安装：

# Windows
venv\Scripts\activate

# macOS / Linux
source venv/bin/activate

pip install 包名

安装完成后，重启 ComfyUI，再重新加载工作流。如果报错消失，说明问题解决。

5.4 一个重要提醒

包名 要替换成实际报错里指出的名字。不同版本、不同节点，依赖的包名不同。不要照着搜索引擎里的旧教程随便装一个大版本，很可能会把 ComfyUI 自己的依赖搞乱。

另外，凡是让你“复制安装命令到终端执行”的提示，一定要看清楚这个命令来自哪里。工作流本质上可以携带任意安装指令，恶意工作流可以通过这个提示诱导你安装不安全的包。安装之前，去 ComfyUI 官方讨论区或者插件项目的官方仓库确认，是必要的谨慎。

6. ComfyUI 局域网连接：从本机到局域网

6.1 默认情况下，ComfyUI 只允许本机访问

ComfyUI 默认启动时，监听的是 127.0.0.1 ，也就是只有你自己这台电脑能打开。你在浏览器里访问 http://127.0.0.1:8188 正常，但局域网里的其他电脑访问 http://你的IP:8188 必然失败。

想要让局域网里的其他设备访问，启动时要加上监听地址参数：

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

--listen 0.0.0.0 表示监听本机所有网络接口， --port 8188 是指定端口。如果你用官方手动安装，直接在 ComfyUI 目录下执行即可。

如果你用的是秋叶一键整合包，可以在启动器的高级设置或启动参数里找到类似“监听地址”的配置项，把地址改成 0.0.0.0 。不同版本整合包的界面不一样，但思路是一样的。

6.2 查看本机在局域网里的 IP

启动之前，先确认本机的局域网 IP。Windows 下执行：

ipconfig

找到当前网卡的 IPv4 地址，一般是 192.168.x.x 或 10.x.x.x 这种私有网段。这就是局域网里其他电脑访问你的地址。

6.3 放行防火墙端口

监听地址改好之后，还有一个常见的坑：防火墙。

Windows 下，如果防火墙默认拦截入站连接，即使监听地址正确，其他电脑也访问不到。需要给 8188 端口加一条入站规则。以管理员身份打开命令行执行：

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

如果是 Linux，最常见的做法是：

sudo ufw allow 8188/tcp

加完防火墙规则后，在另一台电脑的浏览器里访问 http://你的IP:8188 ，正常情况下就能看到 ComfyUI 界面了。

6.4 验证端口是否真的在监听

如果访问还是失败，先在本机确认端口是否真的在监听。Windows 下执行：

netstat -ano | findstr 8188

如果输出里出现 0.0.0.0:8188 或 :::8188 ，说明监听正常。如果只出现 127.0.0.1:8188 ，说明监听地址没有生效，重新检查启动参数。Linux 下对应命令是：

ss -lntp | grep 8188

6.5 安全提醒

这里必须强调：ComfyUI 本身默认没有用户认证。你把端口开放到局域网，意味着同网段的任何人都可以往这个地址提交任务、读取生成结果。

如果你的使用环境是公司内网、学校实验室，或者家里和陌生人共用路由器的场景，风险是真实存在的。

建议只在你信任的局域网内开放此功能。如果需要跨网络访问，不要直接把端口映射到公网，而应该放在可信内网环境中，通过带身份认证的反向代理或接入层来控制访问权限。

7. 局域网访问失败的典型原因与排查流程

7.1 最让人困惑的场景：能上外网，但连不上局域网

很多人遇到过这种情况：电脑的互联网访问一切正常，网页能开，视频能刷，但 ping 不通局域网里的其他设备，甚至连网关地址都不通。

先说结论：能上外网，说明这张网卡的基本配置大概率没问题。连不上局域网设备，问题通常出在链路隔离、路由选择或设备策略上，而不是“网络整体断了”。

最常见的原因有三个。

第一个，无线网络的 AP 隔离。很多路由器默认开启了这个功能，用来隔离同一 WiFi 下的设备互相访问。开启后，设备之间二层隔离，能上网，但互 ping 不通。如果你是用 WiFi 连接，优先去路由器后台检查一下是否有“隔离”或“AP 隔离”选项。

第二个，网卡配置了错误的静态 IP 或子网掩码。比如两台电脑 IP 不在同一网段，互相就无法直接通信。检查方法是，在两台电脑上分别执行 ipconfig /all ，对比 IP、子网掩码、网关是否属于同一规划。

第三个，主机防火墙。Windows 自带防火墙默认会阻止入站连接。如果你只是想被局域网访问，除了给 ComfyUI 放行端口，也可以临时关闭防火墙测试，确认就是防火墙问题之后，再精准添加规则。

7.2 网关 ping 不通，应该先查什么

如果你发现连网关地址都 ping 不通，先把问题缩小到“本机到路由器”这一段。

按这个顺序检查：

# 1. 查看本机 IP、网关配置
ipconfig /all

# 2. 查看网关
ipconfig | findstr "Default Gateway"

# 3. 测试网关连通性
ping 你的网关IP

网关 ping 不通，原因通常是：网线松动、WiFi 信号异常、网卡被禁用、IP 配置错误，或者路由器拒绝回应 ping（部分设备默认不开 ping 应答）。这时候不要急着查 ComfyUI，先解决最基础的链路问题。

7.3 目的 MAC 地址与实际主机对不上是怎么回事

搜索热词里有人提到：TCP 连接从局域网发起，私网地址对应源 MAC 地址没问题，但目的 MAC 地址不一定对应主机。

这句话有点绕，但解释清楚后并不复杂。

局域网通信在二层靠 MAC 地址转发，在三层靠 IP 地址路由。当你的电脑要访问另一台机器时，需要先通过 ARP 协议，把目标 IP 解析成目标 MAC 地址。执行：

arp -a

会看到 IP 和 MAC 的映射表。

正常情况下，目标 IP 对应的 MAC 应该是那台机器网卡的 MAC。但实际场景里会出现几种例外：

• 你访问的是网关，而网关设备启用了虚拟 MAC 或高可用方案，ARP 表里的 MAC 是虚拟地址，不一定对应某一块物理网卡；
• 局域网里有人手动绑定了静态 ARP，导致 IP 和 MAC 映射错误；
• 网络跨了三层设备，中间有交换机或路由器做了转发，导致你看到的 MAC 是下一跳设备的 MAC，而不是最终目标主机的 MAC。

如果访问不通，并且怀疑 ARP 有问题，可以先清理 ARP 缓存再重新解析：

arp -d

然后在另一台机器上 ping 一下目标 IP，让它重新发送 ARP 广播，刷新映射表，再回到原机器看 arp -a 的对应关系。

判断逻辑很简单： 如果目标 IP 和你在同一个网段，ARP 表里的 MAC 应该是它的真实网卡 MAC。如果不在同一个网段，ARP 表里的 MAC 是网关的 MAC，这是正常的，不要看到 MAC 对不上就认为被“劫持”了。

7.4 端口连通性测试

网络链路通，不代表端口通。在客户端电脑上，要测试 8188 端口是否真的可以访问。

Windows 上推荐用 PowerShell 的 Test-NetConnection：

Test-NetConnection 192.168.x.x -Port 8188

如果 TcpTestSucceeded 返回 True ，说明端口可达。返回 False ，说明链路通但端口未开放，需要回到服务端检查监听地址和防火墙。

Linux 或者 macOS 下，可以用 nc：

nc -vz 192.168.x.x 8188

7.5 常见局域网访问问题汇总

问题现象	可能原因	排查方式	解决方案
本机能访问，其他电脑访问不了	启动时没有加 --listen 0.0.0.0	netstat -ano | findstr 8188 看监听地址	重新指定监听地址启动
访问被拒绝或超时	Windows 防火墙拦注入站	临时关闭防火墙测试	添加 8188 入站规则
能上网但 ping 不通局域网设备	AP 隔离	检查路由器无线隔离设置	关闭 AP 隔离或改用网线
网关 ping 不通	网卡/IP 配置错误	ipconfig /all 查看配置	改为自动获取 IP 或修正配置
ARP 表 MAC 异常	静态 ARP 或跨三层	arp -a 查看映射	arp -d 清理缓存重试
端口测试失败	监听地址或防火墙问题	Test-NetConnection	回到服务端查监听和防火墙

8. 常见运行时问题：显存不足、Codex 接口报错与模型接入

8.1 5070 显卡跑工作流提示 GPU 显存不足

热词里有一个高频问题：ComfyUI 在 5070 显卡上跑工作流，提示 GPU 显存不足。

首先明确一点：显存不足不一定代表显卡不行，更常见的是工作流配置超过了当前显卡的承载范围。比如你加载了一个较大的 SDXL 或 SD3 模型，又把分辨率开到 1024x1024，batch size 设为 4，再挂上一个占用显存的高精度 VAE，显存就会迅速打满。

排查要从几个方向入手。

先看显存到底被什么占用：

nvidia-smi

这个命令可以查看 GPU 显存总量、当前占用、占用显存的进程。如果发现其他进程占用了大量显存，先关掉。

然后是工作流侧优化。常用的手段包括：

• 降低生成分辨率，比如从 1024 降到 768 或 512；
• 降低 batch size，从 4 改到 1；
• 使用量化模型。比如 GGUF 格式的量化模型，能在显存有限的显卡上运行更大的模型；
• 关闭或替换高显存消耗的 VAE；
• 清理 ComfyUI 运行过程中残留的显存缓存。

ComfyUI 本身也有显存管理参数。如果你的显卡显存确实偏小，可以尝试启动时带上低显存模式：

python main.py --lowvram

如果显存用到极限还经常爆，也可以试试：

python main.py --novram

--novram 会强制 ComfyUI 尽可能少地占用显存，代价是速度更慢。它不是首选，但有时候能救命。具体参数以你所用 ComfyUI 版本的官方文档为准。

8.2 Codex 请求接口报错怎么处理

有用户反馈，Codex 在请求模型接口时报错，比如请求 /responses 接口时出现“本地请求转发失败”一类的问题。这类报错通常是本地配置的自定义请求转发服务没有正常工作，或者前后配置发生冲突。

处理思路如下。

第一，确认你是否配置了自定义接口地址。如果只是使用官方服务，其实不需要任何转发配置。直接在安装后运行 codex login 登录官方账号即可。

第二，检查环境变量里是否残留了自定义接口地址。命令行执行：

# Windows
set | findstr /i "OPENAI_ BASE_URL API_KEY"

# Linux / macOS
env | grep -i "OPENAI_"

如果发现 OPENAI_BASE_URL 这类变量指向了一个你不再使用的地址，就需要清掉。Windows 下执行：

set OPENAI_BASE_URL=

Linux / macOS 下执行：

unset OPENAI_BASE_URL

第三，如果确实需要接入非官方模型服务，比如想接 DeepSeek 这类兼容 OpenAI 接口的服务，做法是在配置里指定接口地址和密钥。常见的方式是通过环境变量指定：

# 示意配置，具体变量名以 Codex 官方文档为准
OPENAI_BASE_URL=https://api.deepseek.com/v1
OPENAI_API_KEY=你的密钥

配置完成后，先测试接口地址是否可用，再重新启动 Codex。这里要提醒