OpenClaw 接入 gpt-image-2 生图记:不是配上了就等于能用了

很多人写“接入教程”时，喜欢一句话轻轻带过：把 gpt-image-2 配进 OpenClaw，就能生图了。

可真到自己上手，事情往往没这么轻巧。

这次我把整个过程做成了一套漫画，因为它最值得讲的，不是某一行配置怎么写，而是一个很容易被忽略的事实：

模型接入，和工具链真正可用，是两回事。

一开始看配置，确实很像已经通了。

• models.providers
  
   里挂上了 gpt-image-2
• imageModel
  
   指过去了
• imageGenerationModel
  
   也指过去了

从“声明层”看，这模型已经在 OpenClaw 里有名有姓。

但问题也恰恰藏在这一步：

写进配置，不代表上层工具已经真的会用。

真正一调用，错误就来了。

一边是：

• No image-generation provider registered

另一边又冒出：

• openai/gpt-image-2: fetch failed

这时候如果只是盯着一条报错改，很容易越改越乱。

因为它其实不是一个问题，而是两层问题叠在一起。

后来真正有用的办法，不是继续“猜”，而是把链路拆开查。

先问两个问题：

1）模型有没有接入？

看：

• provider 在不在
• baseUrl
  
   对不对
• apiKey
  
   对不对
• imageModel
  
   / imageGenerationModel 指向谁

2）工具链会不会真把它当成生图后端？

看：

• image_generate
  
   是否识别这类 provider
• 生图时到底有没有走到正确接口
• 是配置没生效，还是工具根本不认

这一步最大的收获是：

等排查到一定程度，思路就很清楚了：

如果 OpenClaw 内置的 image_generate 这层暂时没完全打通，就不要死磕。

先绕过封装，直接调用代理暴露出来的底层接口：

• /v1/images/generations
• /v1/images/edits

当然，这条路也不是一帆风顺。

中间遇到过：

• 401 Invalid API key
• 域名网关 502 Bad gateway
• 上游模型偶发 stream disconnected before completion

但好处是，一旦链路拆清楚，就知道该修哪一层，而不是在一团雾里乱撞。

结果优先时，先把图做出来；教程优先时，再回头补齐原生链路。

最后真正有效的，不是某一条神奇命令，而是一套稳定的处理顺序：

1. 先实测
   
   ：拿最小样本验证到底能不能生
2. 再分层
   
   ：配置层、工具层、网络层、上游层分别看
3. 内置不通就绕过
   
   ：直接走代理底层接口
4. 结果优先
   
   ：先把图做出来，再修漂亮的抽象封装
5. 域名和 IP 并存时先体检
   
   ：哪条稳就先用哪条

这套方法后来真的把图做出来了。

而这，才是“接入教程”里真正值钱的部分：

不是告诉你“能用”，而是告诉你“不顺时该怎么活着走出来”。

如果你也在折腾 OpenClaw 接入 gpt-image-2，希望这篇漫画能帮你少走一点弯路。

记住一句就够：

如果下次再报错，就别从头发愁了。

按这套来：

实测 → 分层排障 → 直连代理 → 成功出图。