记录一下那天晚上的排查过程。把 chat 里的 image_url 消息整段搬到 responses，input 里仍然写 {type:image_url, image_url:{url:…}}，接口 400，原文 Invalid value: ‘image_url’，报错里把整段 input 原样回显出来。
刚开始盯着「base64 必须带 data:image/png;base64, 前缀，裸串会被判无效」，折腾了半个多小时，排掉了。
原因不止一个，得分开看。responses 的多模态块类型叫 input_image，不叫 image_url。也可能是图片地址要放在顶层 image_url 字符串字段，不再是嵌套对象。
不容易想到的是，input 写成纯字符串时承载不了多模态内容块。
动手时先用纯文本确认新接口本身是通的
curl https://api.openai.com/v1/responses -H "Authorization: Bearer $OPENAI_API_KEY" -H "Content-Type: application/json" -d '{"model":"gpt-4o-mini","input":"hi"}'接着换成 input_image 结构发一张网络图
curl https://api.openai.com/v1/responses -H "Authorization: Bearer $OPENAI_API_KEY" -H "Content-Type: application/json" -d '{"model":"gpt-4o-mini","input":[{"role":"user","content":[{"type":"input_text","text":"图里是什么"},{"type":"input_image","image_url":"https://example.com/a.png"}]}]}'本地图转 base64 并拼上 MIME 前缀
python -c "import base64;print('data:image/png;base64,'+base64.b64encode(open('a.png','rb').read()).decode()[:60])"等前面都确认过，再把拼好的长串写进请求体文件再发送
curl https://api.openai.com/v1/responses -H "Authorization: Bearer $OPENAI_API_KEY" -H "Content-Type: application/json" -d @payload.json怎么算真的好了，看的是同一批现象。带图请求返回 200，output 里能描述出图片内容，尺寸和 OCR 结果与另一次用 chat 接口的识别一致，不再出现 Invalid value。
提醒一点。两种接口的内容块命名是两套体系，input_text 与 text、input_image 与 image_url 各管一边，混用时错的是名字而不是图片本身。监控比日志更早给出信号，事后回看经常能提前半小时发现异常。