OpenClaw 图片生成为什么经常不按照配置的模型走,讲讲原理.

这次和大家聊一个大多数朋友经常会遇到的一个问题，特别是在你配置了多个模型的情况下。

就是我们明明按照官方文档，在 imageGenerationModel 中配置了图片生成模型，比如：

{ "agents":{  "defaults":{   "imageGenerationModel": {    "primary": "XXX"   },  } }}

但是实际生成图片的时候，OpenClaw 经常不按照我们这个配置走，而是去用其他的模型来生成图片，还经常出现意外错误。

先说结论，imageGenerationModel 并不是 OpenClaw 图片模型的硬性配置，它只是一个默认兜底策略。

image_generate

要想了解 OpenClaw 图片生成的过程， 先要了解 image_generate 这个 tool ，它是 OpenClaw 的内置 tool 之一。 也就是模型通过 tool call 调用这个工具来生成图片。

我整体把这个 tool 的代码捋了一遍，把我得到的理解分享给大家，因为篇幅原因，不可能把所有细节和代码都给大家讲一遍，下面只说一些关键地方。

tool call 是大模型调用的一个标准概念，这里不展开讲它的背景知识了，假设你已经明白。如果不清楚可以搜索一下。

生成图片之前，OpenClaw 需要把 image_generate 这个 tool 的描述信息传给当前使用的模型。这就包含了 tool 的描述， 还有参数说明。

给大家看一下部分代码：

上面就是 image_generate 这个 tool 的部分参数定义， 这里边有 action， prompt， model 等。

action 参数可以选三个， generate, status ,list.

也就是说，我们使用的主模型， 完全知道这个 tool 怎么用。那么我们进一步看。

为什么配置经常无效

具体的代码链路很长，我没办法把所有的代码都贴给大家， 只把最后这个关键节点给大家看一下：

大家可以看到，resolveCapabilityModelCandidates 这个调用，就是选出备选的运行模型。 这里面有好几个传入的参数，包括：

• params.cfg.agents?.defaults?.imageGenerationModel : 这个是我们配置文件中写的配置。
• params.modelOverride: 这个是 tool call 直接传进来的 model 参数。
• listProviders: 其他已经配置的可用模型。

而这里面 params.modelOverride 是最高优先级的。 我们 JSON 文件的配置项 imageGenerationModel 并不是最高。

也就是说，如果我们的主模型用 tool call 调用 image_generate 生成图片的时候， 给他显示的传入了 model 参数，那么就肯定优先按照这个来走了。

主模型会传入 model 参数吗

为了避免歧义，这里先明确一下，下面说到主模型，就是我们日常用于接收聊天内容，处理 tool call 的那个主模型， 说到图片模型，就是专门用来生成图片的模型，说到 model 参数，基本也指的是这个图片模型，大家注意区分。

我的理解是，传入的概率很大。 而且 model 参数本身的描述中，就有几个图片模型字符串的示例，大家可以回看上面关于 tool 参数说明的截图。

另外，现在的主模型知识库，肯定都有可选的图片模型字符串。 还有，大家还记得前面说过，image_generate 这个 tool 本身还能用 action=list 的方式运行吗。

我们可以直接在 WebUI 上面输入这个聊天命令:

/tool image_generate action=list

这就相当于直接调用这个 tool ，并且传入 action 参数为 list。这个就会列出，你当前 OpenClaw 所有可用的生成图片模型。

我们能通过命令的方式调用这个 list， 主模型一样也能通过 tool call 的方式获取这个 list。 所以主模型是能精确知道我们当前 OpenClaw 实例上面所有可用的图片模型的列表。

既然主模型能知道这个列表，它就能在 tool call 的时候明确的传入 model 参数，来指定用哪一个图片模型。而现在代码的逻辑是， model 参数是优先级最高的，虽然这个参数本身是 Optional 的， 但是只要传入， 它就一定会覆盖我们的 agents.defaults.imageGenerationModel 配置。

这就是我们的 imageGenerationModel 经常不生效的原因。

这里边还有一个很绕的事实，是这样，拿 OpenAI 这个 Provider 举例子，它同时有语言模型和图片模型。并且它通用内置的 Plugin 一起注册进来。 如果你配置了它的 API Key，哪怕你觉得你只使用了它的语言模型，但是因为它的 API Key 是全平台通用的。 实际上你也等于把图片模型也配置好了。这不仅限于 OpenAI， 很多 Provider 都支持多种形式的模型。

你可以试一下，你哪怕没有明确配置过某个 Provider 的图片模型，只要你设置了这个 Provider 正确的 API Key ，那么 image_generate 的 list 中也会显示出来它的图片模型，并且能正常使用。

这些就是 OpenClaw 生成图片经常会使用预期之外模型的几个主要原因。

怎么解决

目前官方文档中给我们的配置选项，就只有 imageGenerationModel。 其实文档说的也不算特别精确，下面是官方文档关于这个的一个截图：

它这里说的就三个步骤， 配置 KEY， 然后写好 JSON 配置中的 imageGenerationModel， 然后直接提交提示词。

但实际上，以当前版本的机制来说， imageGenerationModel 这个配置， 你写了，大多数情况也不一定按照这个设置走，文档并没有把这个事情说清楚。

主模型一般来说更愿意直接给 tool call 传 model 参数。而且这个参数传递，完全是模型的运行结果。

Skill 明确声明

上面原理部分，就和大家聊到这里，很多细节实际上都没有展开。 如果需要具体了解 OpenClaw 这块的逻辑，最好的办法还是亲自去看它的代码。

我们接下来可以思考一些控制方法。 tool call 的 model 参数是阻挡我们 imageGenerationModel 这个配置生效的最主要原因，那么如果你真的希望模型的图片生成尽量使用确定的模型，就可以在生成图片的 skill 中加一些声明。

比如这样声明 skill：

## image_generate tool 使用规范调用这个工具生成图片的时候， 一定不要传入 model 参数， 否则会干扰配置。也不要使用 action=list 参数来获取模型列表。总之， 你只用 action=generate 并且不要传入 model 参数，用默认配置来生成图片。

但是上述 skill， 也只是给主模型的一个建议，让模型更大概率按照我们的要求运行，但并不能强制保证一定按照我们的要求来运行。 但是我们写好这个规则，肯定要比什么都不写的可控效果会好很多。这个skill 示例还有很多边界条件没有说清楚，比如如果失败怎么办， 要不要退回默认方案，如果没写清楚，主模型很可能又退回老路重试，这个大家就可以根据自己的情况完善了。

目前版本的 OpenClaw， 我并没有找到其他的方法，比如通过某个设置项来调整这个优先级， 来让 imageGenerationModel 作为最优先的配置。这可能也是 OpenClaw 的一个设计理念，但是主要问题就是，官方文档没有把这个事情说的很清楚。造成了理解的一个偏差。

但有一点确定的是，imageGenerationModel 作为配置项，并不是一个保证生效的东西。

这次就聊这么多，篇幅原因，很多细节聊到并不全面，不过这个逻辑链条应该算是帮大家梳理出来了，具体细节，还是以 OpenClaw 的源码为准，希望对你有帮助。