OpenClaw 两件表象骗了我很久的事

OpenClaw 两件表象骗了我很久的事

排查 OpenClaw 的问题，有时候最难受的不是问题本身，而是表象和实际原因之间有条明显的缝——你盯着上面那层东西找了很久，才发现根本就跑错了地方。遇到两件这样的事，记下来。

一、飞书里的 "API rate limit reached"，本质是账单问题

有一天切换了默认模型，下午飞书开始收到 OpenClaw 的告警：

⚠️ API rate limit reached. Please try again later.

第一反应是频率出了问题——换了模型，调用量没变，不太对。先查了 openclaw.json 里的 rate limit 配置，没有问题；又看了调用时序，间隔正常，没有密集请求。

然后去查原始日志：

/var/folders/7f/.../T/openclaw-501/openclaw-2026-03-20.log
rawErrorPreview: "You exceeded your current quota, please check your plan and billing details..."

原来和请求频率没有关系。OpenClaw 把来自 OpenAI 的各种错误统一包装成一个固定文案发到飞书，不管原因是限流、账单超限还是账号欠费，对外都是同一句话。日志层才有原始错误字符串。

这件事本身不算大，但背后还叠了一个认知问题。

当时我有 ChatGPT Pro 会员，以为订了 Pro 等于 API 也能正常用。实际上两套体系完全独立：ChatGPT Pro 订阅费用走 OpenAI 的消费者产品，不会分配到 API 侧的额度。在 OpenAI Platform 那边，如果没有单独的付费方式或预充值，API Key 调用就直接 exceed quota，不管 Pro 会员的状态是什么。

这种设计的逻辑其实说得通——两套产品用途不同、计费粒度不同——但没有明显的地方会提示你它们是分开的。如果你用 API Key 的第一种方式就是通过 OpenClaw，飞书上的告警信息又从来不分这两种情况，大概率会在"是不是频率太高了"这个方向绕一会儿。

最快的定位方式：不是看 OpenClaw 配置，而是直接看 gateway.err.log 里的 rawErrorPreview。

---

二、本地 gemini 能用，openclaw 里选 Gemini CLI OAuth 会 400

想在 OpenClaw 里加 Gemini 作为备用模型。本地的 gemini 命令已经登录，能正常对话。进 openclaw configure --section model，选了"Gemini CLI OAuth"，结果是：

loadCodeAssist failed: 400 Bad Request

以为是 OAuth 回调拦截被墙了，或者是本地 gemini 版本问题，又或者是 OpenClaw 的 OAuth 流有 bug。折腾了一阵，换了几次网络环境，还是 400。

后来看日志才理解这件事的结构：OpenClaw 的"Gemini CLI OAuth"这条路走的是 Google Code Assist 接口，它针对的是云端开发环境集成，需要对应的 Google Cloud 权限和项目绑定。本地 gemini CLI 用的是 AI Studio 的接入方式，后端不同、鉴权体系不同——虽然 OAuth 流程看起来一样，但目标服务不一样。

即使本地 gemini 命令完全正常，也不保证 OpenClaw 的这条 OAuth 路能通。

正确方式是在 openclaw configure 里选"Google Gemini API key"（而不是"Gemini CLI OAuth"）。从 AI Studio 生成一个 API Key，填进去，几秒能配好。

---

两件事放在一起，模式有点像：都是中间层拦截了真实信息，对外给出了一个让人往错误方向思考的说法。
飞书告警里统一的"rate limit"，让你去查频率问题；"Gemini CLI OAuth"这个名字，让你以为本地能用 openclaw 就能用。实际原因根本不在这里。

排查 OpenClaw 的问题，有时候直接看日志比看 UI 反馈有用。gateway.err.log 里有原始 provider 错误，比飞书消息信息密度高得多。