Hermes doctor 不提示 OpenRouter 缺 Key？API 中转站 Provider 凭证排查

如果你把 Hermes Agent 接到 OpenRouter、DeepAI API 中转站或其他 OpenAI Compatible API，最容易踩的坑之一就是：配置里选了 provider，但环境变量里没有对应 API Key。

Hermes Agent 最近关闭的一个 GitHub issue 就是这个场景：用户把 active provider 设置成 openrouter，但没有配置 OPENROUTER_API_KEY 或 OPENAI_API_KEY。运行 Hermes 时直接失败：

RuntimeError: No LLM provider configured

问题在于：hermes doctor 虽然在 API Connectivity 里提到 OpenRouter 没配置，但最终 summary 没有把“当前 active provider 不可用”当成阻塞问题提示出来。这个 issue 已经关闭，但它非常适合拿来讲 API 中转站用户最需要理解的一件事：诊断工具不能只列信息，必须告诉用户当前模型入口到底能不能用。

搜索意图：为什么这个问题有 SEO 价值

会搜这类问题的人，通常已经配置过 Hermes，但卡在最后一步：

Hermes No LLM provider configured 怎么办
hermes doctor OpenRouter API not configured
Hermes active provider missing API key
OpenAI Compatible API provider 配了但不能用
DeepAI API 中转站 Hermes API Key 怎么填
Hermes model.provider 和环境变量不匹配

这类搜索用户的转化价值很高，因为他们已经有明确的工具接入需求，只差一个稳定的 API 入口和排查路径。

问题复盘：active provider 可用性比“列表里显示”更重要

issue 里的复现逻辑很清楚：

1. 在配置文件里把 model.provider 设置为 openrouter； 2. 不设置 OPENROUTER_API_KEY 和 OPENAI_API_KEY； 3. 运行 Hermes； 4. Hermes 报 No LLM provider configured； 5. 运行 hermes doctor； 6. doctor 没有在最终 summary 中明确指出“当前 active provider 缺凭证”。

这类体验对用户很迷惑。

因为用户看到 doctor 输出时，通常不是想读一堆状态，而是想知道：

> 我现在为什么跑不起来？最该修哪一项？

如果 active provider 缺 Key，却没有被当成 blocking issue，诊断工具就失去了最关键的作用。

DeepAI API 中转站用户应该怎么理解 provider 和 Key

很多人把 DeepAI API 中转站接到各种 Agent 时，会混淆三个概念：

概念	作用	常见错误
Provider	客户端里选择的模型服务商或路由	配了 provider，但没配 Key
Base URL	API 请求入口	把 `/v1`、`/chat/completions`、`/messages` 混用
API Key	鉴权凭证	环境变量名不对、Key 过期、复制错
Model ID	具体模型名	用了控制台不存在的模型

DeepAI API 中转站能帮你统一 API 入口和 Key 管理，但客户端这边仍然要保证：

provider 指向正确；
Base URL 填的是 DeepAI 的兼容入口；
API Key 用的是 DeepAI 控制台生成的 Key；
model ID 以 DeepAI 控制台可用模型为准；
不要同时残留多个互相冲突的 provider 环境变量。

Hermes 接 DeepAI API 中转站的推荐排查顺序

如果你看到类似 No LLM provider configured，不要一上来就重装 Hermes。按这个顺序查更快。

1. 确认当前 active provider

先看 Hermes 当前选择的是哪个 provider：

hermes model

或者检查配置文件中的：

model:
  provider: xxx
  model: xxx

如果你以为自己在用 DeepAI，但配置里还是 openrouter、openai 或其他 provider，就会出现排查方向错位。

2. 确认环境变量是否真的存在

不要只看你“记得自己配过”，直接在当前 shell 里查：

echo $DEEPAI_API_KEY

如果你使用的是 OpenAI-compatible 方式，也可能是：

echo $OPENAI_API_KEY

关键是：Hermes 实际读取哪个变量，要和 provider 配置一致。

3. 确认 Base URL 不是空的

如果你是通过 DeepAI API 中转站接入，通常需要类似：

https://api.deepai.wang/v1

注意不要写成图片生成接口、不要写到具体 /chat/completions，也不要漏掉协议头 https://。

4. 用最小请求测试 Key

在复杂 Agent 之前，先用最小请求确认 Key 和模型可用。这样可以快速区分：

DeepAI Key 不可用；
模型名不对；
Hermes provider 配置不对；
Hermes 自己的 doctor 输出不够清晰。

5. 再运行 doctor

最后再运行：

hermes doctor

doctor 的输出应该被当成“辅助诊断”，而不是唯一真相。尤其当 runtime 报错和 doctor summary 不一致时，要优先相信 runtime 的直接错误。

API 中转站运营者可以从这个 issue 学到什么

这个 issue 对 DeepAI API 中转站运营很有启发。

用户最怕的不是“配置复杂”，而是：

错了但不知道错在哪；
诊断工具给了一堆信息但没有优先级；
active provider 明明不可用，却没有被标红；
Key、Base URL、Model ID 分别在哪错了说不清。

所以 API 中转站文档和控制台应该尽量做到：

1. 明确告诉用户当前应该填哪个 Base URL； 2. Key 创建后给出客户端示例； 3. 模型列表能复制准确 Model ID； 4. 错误码解释要区分 401、404、429、5xx； 5. 给 Hermes / Claude Code / Cline / Dify 等工具分别写配置示例。

这类内容比泛泛讲“支持多模型”更容易转化，因为用户正在配置，马上需要可复制的答案。

和 DeepAI API 中转站相关的自然 CTA

如果你正在用 Hermes，并且不想在 OpenRouter、OpenAI、Anthropic、本地模型之间反复切换 Key 和入口，可以把模型入口统一到 DeepAI API 中转站：

Base URL: https://api.deepai.wang/v1
API Key: 在 DeepAI 控制台创建
Model ID: 以 DeepAI 控制台显示为准

这样做的好处不是“永远不会报错”，而是：当 Hermes 报错时，你可以先在 DeepAI 控制台看请求有没有到达、状态码是什么、模型名是否正确，再回到 Hermes 侧排查 provider 和环境变量。

FAQ

Hermes 报 No LLM provider configured 是什么原因？

通常是当前 provider 没有可用凭证，或者配置里的 provider 与实际环境变量不匹配。例如选了 OpenRouter，但没有设置 OPENROUTER_API_KEY。

hermes doctor 没报 blocking issue，就代表配置没问题吗？

不一定。doctor 是辅助工具。如果 runtime 明确报错，应该优先排查 active provider、API Key、Base URL 和 model ID。

DeepAI API 中转站应该填哪个 Base URL？

常见 OpenAI-compatible 入口是：

https://api.deepai.wang/v1

具体以 DeepAI 控制台和当前文档为准。

可以把 DeepAI Key 填到 OPENAI_API_KEY 吗？

取决于客户端配置方式。如果客户端把 DeepAI 当 OpenAI-compatible provider 使用，可能会读取 OPENAI_API_KEY；如果你有自定义 provider，则建议使用更明确的环境变量和配置，避免混淆。

总结

Hermes 这个已关闭 issue 的价值在于，它把一个常见但容易忽略的问题暴露出来：诊断工具必须围绕 active provider 的可用性来判断，而不是只罗列连接状态。

对 DeepAI API 中转站用户来说，排查 Hermes 这类 Agent 时，不要只看“有没有 provider”，而要确认：provider、Base URL、API Key、Model ID 四件事是否同时匹配。

只要这四件事对齐，后续再排查模型能力、工具调用和上下文限制，效率会高很多。