OpenClaw 2026.3.8 Google 模型全线 404：根因与最快止血方案

如果你刚升级到 OpenClaw 2026.3.8，然后发现所有使用 Google（Gemini）的 Agent 都开始报 404 NOT_FOUND，大概率踩到了“provider 前缀没有被剥离”的回归。

来源 Issue： openclaw/openclaw#41249

TL;DR（一句话版）

现象：Google 的 OpenAI 兼容接口返回 404，例如 models/google/gemini-2.5-pro is not found...
根因：OpenClaw 把 google/gemini-2.5-pro 整串当成 model id 发送；但 Google 只接受 gemini-2.5-pro。
最快止血：确保发往 Google 的请求里 model 不包含 google/ 前缀；否则就临时 pin/回退到已知可用版本。

到底坏在哪里（为什么“看起来像 Google 的锅”）

Issue 描述的典型配置（2026.3.3 正常，2026.3.8 失败）：

Google provider 使用 OpenAI 兼容端点：
- https://generativelanguage.googleapis.com/v1beta/openai/
Agent 选择模型用 provider-qualified 形式：
- google/gemini-2.5-pro

在 2026.3.8 中，OpenClaw 会把 google/gemini-2.5-pro 原样塞进请求的 model 字段。

Google 侧看到的是一个不存在的模型名，于是 404。

Issue 里给出了对照：

错误（2026.3.8 发送）：model: "google/gemini-2.5-pro" → 404
正确（Google 期望）：model: "gemini-2.5-pro" → 200

如何确认你遇到的是同一类问题

同时满足两点基本就可以定性：

OpenClaw 日志里能看到带前缀的 model：

agent model: google/gemini-2.5-pro

返回的错误是 Google 404，类似：

{
  "error": {
    "code": 404,
    "message": "models/google/gemini-2.5-pro is not found for API version v1main, or is not supported for generateContent.",
    "status": "NOT_FOUND"
  }
}

实用止血方案（按可控程度选一个）

方案 A：确保发给 Google 的 model id 是“无前缀”的

关键点只有一个：请求真正到 Google 的时候，model 必须是 gemini-2.5-pro（或你实际使用的 Gemini 模型 id），不能带 google/。

不同部署/配置方式可选路径不一样，常见做法有两类：

如果你的配置允许“provider 与 model 分开写”，就用：
- provider: google
- model: gemini-2.5-pro
如果你现在只能写一个字符串（很多人是这种），可以临时尝试直接把 Agent 的 model 改为：
- model: gemini-2.5-pro

（如果这样会导致 provider 无法判定或跑偏，请用方案 B。）

方案 B：临时 pin / 回退版本

如果你没法改配置结构或短期无法验证风险，最稳妥的止血是：

临时 pin/回退到 prefix stripping 正常的版本（Issue 提到 2026.3.3 可用）。

方案 C：先止住“定时任务刷屏”

Issue 还提到一个实际影响：心跳/定时任务每 30 分钟触发一次失败，导致日志被 404 刷屏。

短期建议：

临时停用受影响的 Agent 或 schedule
或把这些任务切换到非 Google provider，等上游修复后再切回

为什么这条值得单独发 News（而不是埋在 release notes）

这是典型的“高意图排障”搜索词驱动问题：

“OpenClaw Google 404”
“models/google/gemini-2.5-pro is not found”
“generativelanguage openai chat/completions 404”

用户不是来“看新闻”的，是来求解的：这类页面能带来更真实的自然流量和停留。

FAQ：线上事故里最先要做的三个判断

升级后所有 Google Agent 一起挂了，要先换 API key 吗？

通常不用。如果报错里还带着 models/google/gemini-... is not found，优先按“模型 id 拼错”处理，而不是按密钥失效处理。换 key 并不会去掉 google/ 前缀，只会浪费第一轮恢复窗口。

如果只有定时任务在报错，可以先等上游修吗？

前提是这些任务不关键。只要心跳、cron 或对外自动化还依赖 Gemini，就应该先停掉失败任务，或者临时切去非 Google provider，避免 404 持续刷日志、继续消耗信任。

这类问题最安全的回退边界是什么？

只要你还不能确认发往 Google 的请求已经改成“无前缀 model id”，就该回退到最后一个已知可用版本再恢复流量。真正安全的边界是“请求形态可验证”，不是“感觉系统差不多好了”。

FAQ：有经验的站长在宣布事故收口前，还会多看哪三件事

什么证据才算真的证明 workaround 已经止住这次故障？

真正的证明，不是某一次手动聊天侥幸成功，而是 发到 Google 的请求已经变成无前缀 model id，并且之前会失败的那条 Agent 或 schedule 再跑一遍时，不会再出现 models/google/gemini-... is not found。

为什么“日志安静下来了”本身不是可靠的恢复信号？

因为团队很可能先把最吵的 schedule 暂停了。日志变安静，只能说明故障路径可能被静音，不代表已经修好。更可靠的恢复信号，是拿同一条此前失败的 Google 工作流做一次刻意的端到端验证。

什么情况下，应该继续保留 workaround，而不是急着把升级重新放量？

只要你还不能证明所有关键的 Google 流量都走到了同一种正确请求形态，就不该急着全面放量。尤其当生产流量、cron 和客户自动化并不共用一条 model-routing 路径时，一次聊天成功远远不够。

上游需要怎么修

核心就是：对 provider/model 做一致的拆分处理，在调用特定 provider 的 API 时，传递 provider 真实期望的 model id（Google OpenAI 兼容端点期望无前缀）。

同时，Issue 也链接了旧版本类似问题，说明这块容易回归，值得加测试或 lint。

来源

Bug 报告： openclaw/openclaw#41249