background=true 模式调用生图模型, 异步生成图片。内容包含完整示例代码,并重点演示如何传入多张参考图片以及如何传入多份提示词文档。
1. 概述
生图通常需要 30 秒到 5 分钟。如果用同步方式调用,客户端必须一直保持 HTTP 连接等待,网络抖动或网关 超时都可能导致请求失败。background=true 模式把”等待完成”拆成三步:
- 高分辨率图片生成(耗时长)
- 客户端网络不稳定,需要避免长连接超时
- 批量提交、稍后统一取结果
兼容性:本服务完全兼容 OpenAI Responses API 的 background 语义。直接使用官方 OpenAI SDK, 只需把base_url指向本服务即可,responses.create / retrieve / cancel均可正常使用。
2. 前置条件
安装官方 SDK:
3. 请求结构说明
生图在 Responses API 中是一个 工具调用(tool),不是独立的模型端点。标准结构是:- 顶层
model:文本模型(负责理解 prompt 并决定调用生图工具) tools[]:包含一个image_generation工具,工具里的model才是图片模型tool_choice:强制走生图工具input:用户输入(文字 + 参考图片)
关于简写形式(实测不可用,请勿使用)
有一种”偷懒”写法:把图片模型直接放在顶层model、并在顶层写 size / output_format,不写 tools:
- 官方 OpenAI SDK 直接拒绝——
responses.create(size=...)会报unexpected keyword argument 'size',根本发不出去。 - 即便用裸 HTTP 绕过 SDK 发出去,服务端虽然接受并返回
queued,但任务随后会变成failed,上游报错400: Unsupported parameter: size(顶层size未被并入生图工具, 被原样转发给上游)。
结论:始终使用第 3 节开头的标准结构——顶层model填文本模型(如gpt-5.5),size/quality/output_format等参数放在tools[]里的image_generation工具内。 这是唯一经端到端验证可用的写法。
4. 快速开始(三步)
第 1 步:提交任务
第 2 步:轮询状态
第 3 步:取回图片
完成后output 中会包含一个或多个 image_generation_call,图片数据在 result 字段(base64):
5. 使用多个参考图片
参考图片通过input 里 content 数组中的多个 input_image 部分传入。 每张参考图是一个 input_image,image_url 填 base64 data URL,配 detail 控制参考精细度。 按你传入的顺序排列,数量不限,与文字提示放在同一个 user 消息里。
下面的写法对应项目内实际使用的参考脚本 base64 data URL,detail="high",单条 user 消息,background=True。
input_image的数量不限,按数组顺序传给模型。image_url可以用 base64 data URL(data:image/...;base64,...),也可以用 https 公网链接——两种都经端到端实测可用(见下)。- 参考图片与文字提示放在同一个 user 消息的
content数组里即可。
实测结论(已端到端验证):
- base64 data URL 多图:通过。3 张本地图编码后同条消息传入,成功生成图片。
- https 公网链接:通过。用一个公开可访问的 https 图片 URL 作参考图,约 54 秒成功生成图片。 注意链接必须是上游可公开访问的稳定 URL(会被原样转发给上游抓取)。
detail字段实测用的是high;其余取值(low/auto)未单独验证。
6. 使用多个提示词文档
当你有多份提示词(例如:角色设定文档、场景描述文档、风格指南文档),有两种传法, 两种都会被原样转发给模型。方式 A:同一条消息里放多个 input_text(推荐)
把每份文档作为一个独立的 input_text 部分,按逻辑顺序排列,最后再放参考图片:
方式 B:多条 user 消息
如果你想让文档在对话结构上彼此独立,也可以用多条消息:- 只要
input是结构化数组(如上两种写法),服务端会原样转发,不做改写。 - 给每份文档加一个清晰的小标题(如
【角色设定】)有助于模型区分文档边界。 - 文档与参考图片可以自由组合:在任意一条消息的
content里同时放input_text和input_image即可。
7. 完整示例:多参考图 + 多文档 + 轮询保存
8. 使用 curl 测试
9. 取消任务
retrieve 将返回 404。
10. 状态流转
11. 支持的图片尺寸
- 标准结构下,出图尺寸与请求
size精确一致(3072x1728、3840x2160 落地像素均吻合)。 注意:第 3 节那种”简写写法”会让size被上游忽略,尺寸不可控。 - 大尺寸的失败多为可重试的偶发错误,不一定是”尺寸不支持”。实测中见过两类: 传输层
INTERNAL_ERROR、上游server_error: You can retry。两者都建议重试后再判断。
12. 注意事项
- 结果有效期 15 分钟
- 生成完成后,结果在服务端保留 15 分钟,过期后再
retrieve返回 404。 - 建议尽快取走结果,不要拿到
completed后长时间不读取。
- 生成完成后,结果在服务端保留 15 分钟,过期后再
- 轮询频率
- 图片生成:每 10-15 秒轮询一次。
- 不要高频轮询(< 1 秒),会增加服务器负载。
- 取走即清除
- 一旦
retrieve返回了completed的完整结果,该结果映射会被删除; 请在同一次轮询里就把图片保存下来,不要依赖二次拉取。
- 一旦
- 单实例限制
- 取消(cancel)只对当前处理该任务的服务实例生效。
- 若服务重启,进行中的任务会丢失(映射 15 分钟后过期返回 404)。
- 多图 / 多文档务必用结构化
input数组- 传
input_image、多个input_text时,input必须是数组结构(见第 5、6 节)。 - 仅当
input是单条纯文本字符串时才适合用简写。
- 传
- 错误处理
- 提交(POST)返回非
queued状态,说明请求参数有问题。 - 轮询返回
failed时,查看error.message:常见原因有上游临时错误(可重试)、 不支持的尺寸、内容审核拒绝(moderation_blocked)。
- 提交(POST)返回非
- response_id 格式
- 形如
resp_+ 一串十六进制字符,请原样保存用于后续轮询 / 取消。
- 形如