Gemini 报 Multiple authentication credentials？Hermes Agent 接入 Google OpenAI-compatible 端点的排错指南

> 问题本质：这不是简单的“API Key 无效”，而是 Google Gemini OpenAI-compatible 端点在不同 key 类型、认证头组合和 SDK 行为之间出现冲突。Hermes Agent 通过 OpenAI SDK 调 Gemini 时，Authorization: Bearer、x-goog-api-key、AIza... 旧 key 与 AQ. 新 key 的兼容性差异，会让同一个错误看起来像认证重复、Key 无效或端点错误。

如果你在 Hermes Agent 里配置 Gemini provider 后看到：

HTTP 400: Multiple authentication credentials received. Please pass only one.

或者后续又变成：

API key not valid. Please pass a valid API key.

不要急着重装 Hermes，也不要只盯着 config.yaml 里 key 有没有粘错。这个问题的关键在于：Google 的 OpenAI-compatible endpoint 对认证方式非常敏感，尤其是 AI Studio 后来生成的 AQ. 前缀 API key。

适合搜索的关键词

• Hermes Gemini Multiple authentication credentials received；
• Gemini OpenAI compatible AQ key 400；
• Google AI Studio AQ API key invalid；
• generativelanguage.googleapis.com v1beta openai Bearer x-goog-api-key；
• Hermes gemini provider HTTP 400；
• Gemini API key not valid but key is correct；
• OpenAI SDK Gemini x-goog-api-key Bearer conflict。

典型配置和报错

常见 Hermes 配置类似：

model:
  provider: gemini
  default: gemini-2.5-flash

.env 中配置：

GEMINI_API_KEY=your_google_key

请求落到 Google 的 OpenAI-compatible endpoint：

https://generativelanguage.googleapis.com/v1beta/openai

然后报错：

BadRequestError [HTTP 400]
Provider: gemini Model: gemini-2.5-flash
Endpoint: https://generativelanguage.googleapis.com/v1beta/openai
Error: Multiple authentication credentials received. Please pass only one.

这个错误表面意思是“传了多套认证凭证”，最初很容易被理解为 Hermes 同时传了：

• Authorization: Bearer <KEY>；
• x-goog-api-key: <KEY>。

但真实情况更绕：后续排查发现，Google 对不同 key 前缀、不同 header 组合、不同 SDK 的行为并不一致。

先区分两类 Gemini API Key

排查这个问题前，先看 key 的前缀：

在真实讨论中，有用户发现：Google AI Studio 新生成的 key 变成 AQ. 前缀，而这些 key 在 OpenAI-compatible endpoint 上会出现 Multiple authentication credentials received。

这意味着：你看到的错误不一定是 Hermes 本地配置错了，也可能是 Google endpoint 对新 key 格式的处理有问题。

为什么会出现“多个认证凭证”？

在 OpenAI-compatible 调用里，客户端通常会通过 OpenAI SDK 发送：

Authorization: Bearer <API_KEY>

而 Google 原生 API 常见方式是：

x-goog-api-key: <API_KEY>

如果客户端或适配层同时带上这两个 header，Google 可能会拒绝：

Multiple authentication credentials received. Please pass only one.

早期修复思路是：既然 OpenAI SDK 默认会塞 Bearer，那 Gemini endpoint 就改用 x-goog-api-key，并抑制 Bearer。

但后续 Google endpoint 行为又变化了：某些 header 组合对 AQ. key 仍不可用，甚至对 legacy AIza... 也会被影响。因此后来又有 revert 和补充说明。

最容易踩坑的 header 矩阵

真实排查中有人列过类似矩阵，核心结论可以简化成这样：

关键点：有些“curl 可以构造出来”的 header，在 Python OpenAI SDK / httpx / h11 栈里根本发不出去，因为它会在本地拒绝非法 header 值。

所以这不是简单一句“把 header 改成 x-goog-api-key”就能彻底解决的问题。

为什么你会看到“API key not valid”？

有用户在更新后不再看到 multiple credentials，而是变成：

API key not valid. Please pass a valid API key.

这并不一定说明 key 真的粘错了。它可能表示当前修复方式改变了认证头组合，让 Google 以另一种方式验证 key，结果新的 header 组合仍然不被该 endpoint 接受。

也就是说：

• Multiple authentication credentials 是认证组合冲突；
• API key not valid 可能是 header 改法不兼容；
• 两者都可能和 AQ. key / OpenAI-compatible endpoint 有关。

推荐排查顺序

1. 先确认 key 前缀

不要把完整 key 发给别人，也不要贴到 GitHub issue。只看前缀即可：

AIza...
AQ...

如果是 AQ. 新 key，优先怀疑 Google OpenAI-compatible endpoint 的兼容性。

2. 用 Google 官方 OpenAI-compatible curl 做最小测试

按 Google 文档测试 /v1beta/openai/chat/completions：

curl "https://generativelanguage.googleapis.com/v1beta/openai/chat/completions" \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $GEMINI_API_KEY" \
  -d '{
    "model": "gemini-2.5-flash",
    "messages": [
      {"role": "user", "content": "hello"}
    ]
  }'

如果 curl 本身也报 400，那么 Hermes 不是唯一问题。

3. 尝试重新生成非 AQ key

维护者后续说明里提到：Google 侧承认 AQ. key 在 OpenAI-compatible endpoint 上有问题，并建议重新生成 key；新的 key 可能会回到非 AQ legacy 格式。

如果你能拿到 AIza... key，优先用它验证。

4. 不要手动把 native generateContent URL 塞进 OpenAI provider

有人尝试把 Base URL 改成：

https://generativelanguage.googleapis.com/v1beta/models/gemini-xxx:generateContent

这通常不对。OpenAI-compatible SDK 期望的是 /chat/completions 这类 OpenAI schema；Google native Gemini API 使用的是 generateContent schema。两者请求体和路径都不一样。

也就是说：

• OpenAI-compatible provider 要走 /v1beta/openai；
• native Gemini adapter 才应该走 /v1beta/models/{model}:generateContent。

把 native endpoint 硬塞给 OpenAI SDK，只会得到新的 400 或 404。

5. 临时切到其他 provider 或中转路径

如果你必须马上恢复工作，可以临时切换：

• OpenRouter BYOK；
• 其他 OpenAI-compatible 模型；
• Claude / OpenAI / DeepAI 中转站支持的模型；
• 或等待 Hermes native Gemini adapter / Google 侧修复。

这不是说 Gemini 不能用，而是当前 AQ. key + OpenAI-compatible endpoint + Python SDK 这条组合链路容易踩坑。

真正长期方案：native Gemini API，而不是硬套 OpenAI SDK

这次讨论里一个重要结论是：当 OpenAI-compatible endpoint 的认证层不稳定时，Gemini 最稳的长期方案不是继续绕 header，而是走 Google native API：

POST /v1beta/models/{model}:generateContent

并使用 Google 自己的请求 / 响应 schema。

这样可以绕开 OpenAI SDK 对 Authorization header 的自动行为，也避免 AQ. key 在 OpenAI-compatible endpoint 上的奇怪兼容问题。

对 Agent 框架来说，这也是一个更通用的经验：所谓 OpenAI-compatible 适合快速接入，但当模型厂商在认证、工具调用、多模态、thinking、safety settings 上有大量自定义能力时，native adapter 往往更可靠。

和 DeepAI API 中转站的关系

这篇问题属于 Google Gemini provider / OpenAI-compatible endpoint 认证层问题，不能说 DeepAI 能修复 Google AQ. key 的 header 行为。

但 DeepAI API 中转站适合在另一类场景中使用：

• 你希望在 Hermes、Cline、Dify、Open WebUI、Cherry Studio 等工具里统一 OpenAI-compatible Base URL；
• 你使用的是 DeepAI 支持并按 OpenAI-compatible 方式暴露的模型；
• 你希望减少多工具重复配置 API Key 和模型名；
• 你需要把“模型服务是否可用”和“客户端适配是否正确”分层排查。

如果问题明确发生在 Google generativelanguage.googleapis.com/v1beta/openai 对 AQ. key 的认证处理上，中转站不是根治办法。最稳还是：换可用 key、等待 Google 侧修复、或使用 native Gemini adapter。

常见误判

误判一：HTTP 400 一定是配置错

不一定。这里的 HTTP 400 可能来自 Google endpoint 对 key 类型或 header 组合的处理，而不是你把 key 粘错。

误判二：重试能解决

日志通常会提示 non-retryable。认证头冲突不是网络抖动，重试一百次也不会变。

误判三：把 key 从 GEMINI_API_KEY 改成 OPENAI_API_KEY 就一定好

这可能在某些旧 key / 某些 SDK 行为下绕过去，但不是稳定方案。它只是改变了客户端如何构造认证头。

误判四：把 Base URL 改成 generateContent 就能走 native API

不能。OpenAI SDK 和 native Gemini API 的路径、payload、响应结构都不同，需要专门 adapter。

最后结论

Hermes Agent 接入 Gemini 时出现：

Multiple authentication credentials received. Please pass only one.

最重要的不是反复改配置，而是先分清：

• 你用的是 AIza... 还是 AQ. key；
• 当前走的是 OpenAI-compatible endpoint 还是 native Gemini API；
• 认证头是 Bearer、x-goog-api-key，还是两者混用；
• 错误是 multiple credentials、invalid key，还是普通 endpoint 400。

短期处理：尝试重新生成非 AQ. key，或临时换 provider / OpenRouter BYOK / 其他 OpenAI-compatible 模型。

长期处理：Gemini 这类深度自定义模型，最好通过 native adapter 调用，而不是长期依赖 OpenAI-compatible endpoint 的 header 兼容性。

FAQ

Gemini 的 Multiple authentication credentials 是什么意思？

它表示 Google endpoint 认为请求里出现了多套认证信息，常见于 Authorization: Bearer 和 x-goog-api-key 的组合冲突，或 AQ. key 在 OpenAI-compatible endpoint 上触发的特殊行为。

AQ. 开头的 Gemini API key 能用吗？

在 Google native API 中可能可以，但在 OpenAI-compatible endpoint 上曾出现兼容问题。排查时应先用官方 curl 验证。

为什么 valid key 会报 API key not valid？

可能是 header 组合不被当前 endpoint 接受，而不一定是 key 内容粘错。尤其是在修复或切换认证方式后，要重新看最终请求头。

应该用 /v1beta/openai 还是 generateContent？

OpenAI-compatible provider 使用 /v1beta/openai；native Gemini adapter 才使用 /v1beta/models/{model}:generateContent。不要混用。

DeepAI API 中转站能修 Google Gemini AQ key 问题吗？

不能直接这样说。这个问题发生在 Google Gemini endpoint 和认证头兼容层。DeepAI 更适合统一 OpenAI-compatible 模型接入和 Key 管理，但不能替代 Google native API 的认证行为。