GPT Image 2 API 与 Codex：先选对调用路线

要用 GPT Image 2，第一步不是复制某段代码，而是先确认这次工作属于哪条路线。直接生成图片或编辑已有图片，默认看 Images API；图片只是助手或 agent 流程里的一个工具步骤，才看 Responses 的 image_generation 工具；需要在仓库里批量生成封面、说明图、文档资产，可以把 Codex 当成可审阅的本地工作流；需要统一账单、备用接入或多模型网关时，第三方路线才有意义。

这几条路线共享同一个模型名感知，却不共享同一个实现面。把它们混在一起，最常见的结果是三类错误：把 gpt-image-2 填到 Responses 顶层 model 字段里，把 Codex 的订阅或 credit 误当成 OpenAI API key 计费，把第三方网关价格写成官方 OpenAI 价格。正确做法是先选路线，再写请求，再记录账单边界。

先用路线表决定从哪里开始

如果你只是想在后端拿到一张图，不需要先把问题做成 agent。直接调用 Images API，能最快验证密钥、项目、模型权限、尺寸、质量和输出处理。如果你正在做一个聊天助手，用户先描述需求、模型再决定是否生成图，Responses 才是自然的编排层。Codex 则更像写作、开发和内容生产时的工作台：它能把提示、素材、输出文件和审阅记录放进同一个仓库上下文里，但它不是公共 API 的同义词。

这张表的重点不是让你记住所有产品名，而是把“谁拥有这次请求”讲清楚。Images API 拥有直接图片任务，Responses 拥有助手式工具编排，Codex 拥有仓库内产物和审阅流程，网关拥有自己的商业接入。只要这个归属没错，后面的代码和成本解释就不会大幅跑偏。

直接生成和编辑，先走 Images API

GPT Image 2 的官方模型 ID 是 gpt-image-2。当你的需求是“给我生成一张图”或“拿这张参考图做修改”，最干净的起点就是 Images API。这个路线的好处是调用面窄：一个 endpoint、一个模型字段、明确的输入输出、明确的错误面。调通第一张图以后，你再讨论批量、质量、尺寸、输出格式、重试和存储，工程上会稳很多。

直接请求应该故意保持简单。先不要把透明背景、复杂多轮对话、代理式工具调用和网关回退塞进第一版。你要验证的是：项目是否有模型访问权限，组织是否需要验证，请求体是否被官方接口接受，输出是不是能被业务存储和回放。

ts
import OpenAI from "openai";

const client = new OpenAI({ apiKey: process.env.OPENAI_API_KEY });

const image = await client.images.generate({
  model: "gpt-image-2",
  prompt: "Create a clean product route diagram for a developer documentation page.",
  size: "1024x1024",
  quality: "medium"
});

编辑请求也属于同一类直接图片任务。只要核心工作是“用输入图片生成另一张图片”，先看 Images API 的 edit 路线，而不是因为文档里也有 Responses 工具就自动切换。Responses 的价值是编排，不是替代所有图片 endpoint。

上线前还要保留一个现实判断：GPT Image 系列可能需要组织验证。这个事实在中文读者场景里尤其重要，因为很多人会把“网上有人调通了”理解成“我的账号一定也能立刻调通”。更稳的写法是把账号准备、权限、项目、模型访问和账单面放进同一个检查清单。

Responses 适合助手流，不适合偷懒替换 endpoint

Responses 的 image_generation 工具适合另一类产品：用户不是点击“生成一张图片”按钮，而是在一个助手流程里描述目标、补充素材、让模型判断何时需要出图。这个时候，顶层模型负责理解上下文和调用工具，图片工具负责输出图像。这里的模型放置规则非常关键：顶层 model 应该是文本或多模态推理模型，图片生成作为工具出现；不要把 gpt-image-2 直接当成 Responses 的顶层模型。

这种路线的工程复杂度更高，但也有它的价值。你可以把图片生成和文本解释、文件检索、代码执行、用户确认、后续编辑放在同一个 response flow 里。对于客服、设计审稿、商品素材助手或内部运营工具，这种编排比单独图片 endpoint 更接近真实产品体验。

ts
const response = await client.responses.create({
  model: "gpt-5.4",
  input: "Draft a launch-card concept, then create one square image for it.",
  tools: [{ type: "image_generation", model: "gpt-image-2" }]
});

如果你的第一版产品只有一个图片按钮，这段结构反而可能增加不必要的排错面。你会同时面对 Responses 的输出结构、工具结果提取、图片二进制或 URL 保存、流式状态、失败重试和计费解释。除非你真的需要助手式上下文，先用 Images API 更容易把系统做稳。

Codex 是仓库资产工作流，不是公开 API 的别名

Codex 对这类主题很容易被误读。很多开发者看到“GPT Image 2 可以在 API 和 Codex 中使用”，会自然问：那是不是有一个叫 Codex GPT Image 2 API 的入口？更准确的答案是：Codex 是你在开发环境或内容仓库里调用模型能力、生成文件、接受审阅的工作流，它可以很适合生成文章封面、说明图、UI 草图、文档图板和测试素材，但这和你用 OpenAI API key 在后端计费不是同一个合同。

如果你的目标是给生产应用接入图片生成，Codex 不应该替代后端 API 路线。你仍然需要 Images API 或 Responses，仍然要记录模型、尺寸、质量、输出 ID、存储位置和重试策略。如果你的目标是为一个 repo 生成可审阅视觉资产，Codex 反而很合适，因为提示、原始输出、发布资产和正文引用可以留在同一个版本控制语境里。

这里的边界会直接影响文章或产品文档的可信度。你可以说 Codex 是内容生产路线，可以说 Images API 是生产应用路线，可以说网关是商业接入路线；但不要把三者写成同一个“API”。这也是中文读者最需要的提醒，因为很多教程会把“能用”写成“应该这么接”，却没有说明账单和上线责任归谁。

成本解释要分成三张账单

GPT Image 2 的成本解释必须分层。第一层是 OpenAI API 官方价格，适用于你用 API key 调 Images API 或 Responses 的请求。第二层是 Codex 或 ChatGPT 计划里的 credit、限额和使用边界，适用于你在 Codex 工作流里生成仓库资产。第三层是第三方网关价格，适用于你通过网关做接入、统一支付、备用渠道或多模型路由。

把这三层混用，会让读者做出错误预算。例如，把某个网关的单次价格写成 OpenAI 官方价格，后续读者查账单时一定对不上；把 Codex credit 当成后端 API 调用额度，会让生产应用的成本估算失真；把官方低中高质量示例价格套到所有第三方路线，也会误导采购和工程负责人。

更可靠的写法是先声明价格归属，再给读者一个使用场景：官方 API 价格用于生产应用核算；Codex credit 用于仓库内资产生产；网关价格只用于这个网关自己的合同。需要网关时，可以把 laozhang.ai 放在“API 网关或统一接入”分支里，并把 docs.laozhang.ai 和 api.laozhang.ai 当成进一步查看接入文档的入口。不要在没有当前验证的情况下承诺不限速、不封号、固定成功率、退款或失败不扣费。

上线前记录这些字段

无论你选择哪条路线，生产系统都应该记录足够的信息，保证一次图片输出之后能解释、重试、复盘和控制成本。至少记录 route、模型 ID、质量、尺寸、输入图片数量、输出格式、请求 ID、输出 ID、存储路径、消耗、用户或项目、重试次数、错误码和账号准备状态。

另外要把功能边界写进产品逻辑。GPT Image 2 当前不支持透明背景，所以如果你的流程依赖 background: "transparent"，就不要让前端给用户一个必然失败的选项。对于流式或部分输出，也要明确前端如何展示中间状态、失败时是否保留已有产物、重试是否会产生新成本。

这一步看起来像运维细节，其实是内容和产品都必须承担的解释责任。只写“模型更强了”无法帮开发者上线；告诉他该选哪条路线、哪些字段要记录、哪些 claims 不能写死，才是真正能帮开发者上线的价值。

迁移时不要照搬 GPT Image 1.5 的旧判断

如果你之前已经有 GPT Image 1.5 或更早的图片接入，不要只把模型名替换成 gpt-image-2 就上线。先重新过一遍路线选择：旧系统是直接图片 endpoint，还是 Responses 工具流，还是 Codex 资产生产？然后重新检查参数、输出处理、透明背景、价格、组织验证和失败策略。

站内已有的 OpenAI 图片生成 API endpoint、OpenAI 图片编辑 API 和 OpenAI 图片生成 API cURL 更适合解释通用 endpoint 机制。这一篇只负责 GPT Image 2 的当前路线归属：同一个模型名可以出现在多个使用面里，但实现和账单必须分开。

迁移评审可以按三个问题收尾。第一，用户点击的是“生成图片”还是“让助手完成一个任务”？第二，输出是不是要进入生产存储、审计和计费？第三，文档里的价格、限额和功能支持是否都能在当前来源里找到。三个问题都回答清楚，再发布到生产环境。

常见问题

GPT Image 2 是否只能在 Codex 里用？

不是。Codex 是一条适合仓库资产和开发工作流的使用面，但直接生成和编辑图片仍然应该看 Images API。你要为产品后端接入图片生成时，不要把 Codex 当作公开 endpoint 的替代品。

Responses 里可以直接把 gpt-image-2 当顶层模型吗？

不应该。Responses 的自然结构是顶层使用文本或多模态推理模型，再通过 image_generation 工具请求图片。gpt-image-2 应该出现在图片工具或 Images API 的模型字段里，而不是把整个 Responses 请求变成图片模型请求。

官方 API 价格和 Codex credit 怎么分？

官方 API 价格用于你通过 OpenAI API key 调用 Images API 或 Responses 的请求。Codex credit 或计划边界用于你在 Codex 工作流里生成文件和视觉资产。第三方网关又是第三张账单，必须按网关自己的合同解释。

GPT Image 2 支持透明背景吗？

当前不支持。需要透明背景的产品流程要么改设计，要么把这项能力从 GPT Image 2 路线中排除，不能在前端或文档里把它写成可用选项。

什么时候才需要第三方网关？

当你需要统一接入、多模型路由、本地支付、备用路线或团队账单整合时，网关才可能有价值。如果官方 OpenAI API 已经满足访问、合规、成本和稳定性要求，官方路线通常更直接。

GPT Image 2 路线判断和普通 OpenAI 图片 endpoint 教程有什么区别？

普通 endpoint 教程回答“路径怎么调”。这篇回答“GPT Image 2 出现在 API、Responses、Codex 和网关时，哪一条路线拥有你的任务”。如果路线选错，代码看起来能跑，也可能在计费、权限或上线解释上出问题。