实测Codex App通过第三方API调用gpt-image-2生图成功

背景

在 AI 编程助手生态中，Codex App 凭借其强大的代码生成与执行能力，成为开发者的重要工具。然而，原生服务往往受限于网络环境、API 调用成本或特定模型（如生图模型）的可用性。近期，一位来自 LINUX DO 社区的开发者进行了一次极具参考价值的实验：通过配置第三方 API 中转站，成功让 Codex App 调用非原生渠道的 gpt-image-2 模型进行图像生成。

此次实验的核心驱动力在于解决原生公益站或特定配置下 /imagegen 命令调用失败、卡顿的问题，并验证了 GPT-5.5 模型与 Codex App 在结合第三方中转服务时的协同效应。该实验不仅打通了从配置到生成的完整链路，还深入剖析了 Codex 内部 image_gen 技能的执行逻辑，为开发者在受限环境下扩展 AI 能力提供了切实可行的路径。

核心内容

本次实验主要围绕在 Windows 环境下，利用 Codex App 配合第三方 API 中转站，实现 gpt-image-2 模型的生图功能。整个过程涵盖了环境配置、技能逻辑解析、依赖安装及最终验证。

1. 环境配置与前置条件 实验基础环境为 Windows 系统，运行 Codex App。关键在于配置 ~\config.toml 文件，填入第三方 API 中转站的 base_url 和 api_key，并指定使用 gpt-5.5 作为主模型。此前，用户在使用其他公益站的 gpt-5.4 时，通过 /imagegen 命令生图会卡在调用技能后不动，而新的中转站同时提供了 gpt-5.5 和 gpt-image-2，这为实验提供了可能。

2. 深入解析 image_gen 技能逻辑 为了理解生图机制，用户要求 gpt-5.5 详细解析 /image gen 技能的内部结构，揭示了其两大顶层模式：

• 默认内置工具模式 (image_gen)：这是首选路径，用于普通图片生成、编辑及简单透明背景需求。此模式不需要 OPENAI_API_KEY，由 Codex 内部处理。
• Fallback CLI 模式 (scripts/image_gen.py)：这是备用路径。仅在用户明确要求使用 CLI/API/model 参数、需要 gpt-image-1.5 原生透明输出且用户确认、或内置工具无法处理复杂透明背景时启用。此路径需要 OPENAI_API_KEY。

技能逻辑强调，CLI 并非默认兜底，严禁为了控制尺寸、质量或路径而随意切换至 CLI。内置工具失败后也不应直接自动降级到 CLI，除非满足特定条件。

3. 执行流程与依赖补齐 用户首先在项目文件夹中创建了 image-gen-env.txt 配置文件，明确了第三方中转站的 base_url、api_key、image_model (设为 gpt-image-2) 以及输出路径 out-path。

随后，gpt-5.5 执行了一系列自动化操作：

• 依赖安装：自动安装 Python 的 openai SDK 到指定路径（如 D:\Programs\Python\Python314）。
• 环境变量设置：在进程环境中设置 OPENAI_API_KEY 和 OPENAI_BASE_URL，指向第三方中转站。
• Dry-run 验证：通过 image_gen.py 构造请求，验证了与 gpt-image-2 的连通性。
• 真实生图：调用 scripts/image_gen.py 脚本，指定 --model gpt-image-2 和输出路径，成功生成图片。

4. 验证结果与标准化流程 最终生成的图片位于 G:\screenshot/cli-fallback-gpt-image-2-test.png，经验证为 PNG 格式，RGB 色彩空间，尺寸 1254x1254，大小约 1.5MB。

基于此成功实验，用户总结了一套标准化的 CLI Fallback 操作流程：

1. 从 image-gen-env.txt 读取配置。
2. 设置当前进程的 OPENAI_API_KEY 和 OPENAI_BASE_URL 环境变量。
3. 调用脚本：C:\Users\Administrator.codex\skills.system\imagegen\scripts\image_gen.py。
4. 指定参数：--model gpt-image-2 及输出路径。
5. 生成后直接引用或展示结果。

同时，用户还生成了一个名为 /imagegen-preview 的新 Skill，旨在简化后续使用流程，只需配置好第三方 API 的 env 文件即可快速调用外部 image-2 模型。

关键要点

• 模型兼容性：GPT-5.5 与 Codex App 配合良好，能够准确解析并执行复杂的生图技能逻辑，解决了旧版本模型（如 gpt-5.4）在生图命令上的卡顿问题。
• 技能执行路径区分：Codex 的 image_gen 技能严格区分“内置工具”与“CLI Fallback”。内置模式无需 API Key，适合常规任务；CLI 模式需要 API Key，适用于需要特定模型（如 gpt-image-2）或高级控制的场景。
• 第三方 API 中转可行性：通过配置 OPENAI_BASE_URL 和 OPENAI_API_KEY，Codex 可以成功对接支持 OpenAI 兼容接口（特别是 /v1/images/generations）的第三方中转站。
• 依赖管理自动化：Codex 具备自动检测并安装 Python 依赖（如 openai SDK）的能力，降低了用户手动配置环境的门槛。
• 失败排查清单：实验明确了可能导致失败的关键因素，包括：第三方 API 不支持图像生成接口、模型列表中无目标模型、返回格式不兼容（非 b64_json）、环境变量未正确注入、API Key 无效或额度不足、以及 Python 环境缺失依赖。
• 文件保存策略：Codex 遵循严格的项目资产保存规则。若图片为项目资产，必须移动至 workspace 内；若仅为预览，可保留在默认目录并内联展示。文件名采用版本化命名（如 hero-v2.png）以避免覆盖。

意义与影响

此次实验的成功具有多重技术意义：

1. 突破模型限制：证明了通过第三方中转，用户可以在不拥有官方 API 权限的情况下，利用 Codex 调用前沿或特定的生图模型（如 gpt-image-2），极大地扩展了 AI 编程助手的能力边界。
2. 优化工作流：通过创建自定义 Skill（如 /imagegen-preview）和标准化配置流程，将原本复杂的 CLI 调用封装为便捷的操作，提升了开发者的使用效率。
3. 深化对 Codex 内部机制的理解：详细解析 image_gen 技能的逻辑，帮助开发者理解 AI 助手内部的决策路径（如何时使用内置工具，何时触发 CLI），有助于编写更精准的提示词和自定义技能。
4. 社区知识共享价值：该实验提供了详细的错误排查清单和成功配置模板，为遇到类似网络或模型调用问题的开发者提供了宝贵的参考案例，促进了 LINUX DO 等社区内的技术沉淀与共享。