Hermes Agent 接入 DeepAI API 中转站：自定义端点多模型被锁定怎么排查

Hermes Agent 通过自定义 OpenAI-compatible endpoint 接入 DeepAI API 中转站时，最自然的做法是把 Base URL 指向 https://api.deepai.wang/v1，再从中转站暴露的模型列表里选择具体模型。但如果 hermes model 第一次选完后就再也切不动模型，问题很可能不在 DeepAI 路由，而在 Hermes 本地配置缓存。

Hermes Agent 接入 DeepAI API 中转站时自定义 OpenAI 兼容端点多模型被锁定的排查流程 — 多模型 API 中转站需要客户端每次重新探测或展示模型列表；如果本地保存的 `custom_providers[].model` 触发提前返回，就会锁定到第一次选择的模型。

GitHub Issue 背景：hermes model 总是回到第一次选择的模型

这个问题来自 Hermes Agent Issue #6862。用户配置了一个自定义 OpenAI-compatible endpoint，后端可以是 OpenRouter、vLLM 集群，或任何同时提供多个模型的 API 网关。第一次运行 hermes model 时选择模型 A，一切正常；第二次再进入同一个 provider 时，Hermes 直接提示已经切换到模型 A，不再展示模型列表，因此无法切到模型 B 或模型 C。

Issue 中给出的根因很明确：hermes_cli/main.py 里的 _model_flow_named_custom() 会检查 custom_providers 条目里是否已经保存了 model 字段。如果存在，就直接激活并 return，不会重新请求 endpoint，也不会显示模型选择菜单。

if saved_model:
    _save_model_choice(saved_model)
    print(f"Switched to: {saved_model}")
    return  # no endpoint probe, no model menu

为什么这对 DeepAI API 中转站用户很重要

API 中转站的价值之一，就是把多个模型统一暴露到一个 OpenAI-compatible Base URL 下。比如同一个 https://api.deepai.wang/v1 后面可以按模型 ID 路由到不同供应商、不同上下文窗口、不同价格档位或不同用途模型。Hermes 如果只记住第一次选择的 model，就会让多模型路由能力在客户端侧被“短路”。

这类问题的表现通常是：DeepAI 中转站后台明明有多个模型，/v1/models 也能返回多个可用模型，但 Hermes CLI 每次都直接使用旧模型。你在网关侧怎么调整模型列表，都不会让 Hermes 自动弹出选择菜单。

推荐配置：Base URL 只写到 /v1

自定义 provider 的基础配置应保持简洁：

custom_providers:
  - name: "DeepAI"
    base_url: "https://api.deepai.wang/v1"
    api_key: "YOUR_DEEPAI_API_KEY"

如果你希望每次都能从中转站模型列表中选择，不建议长期在 provider 配置里写死 model。模型可以作为“当前选择”保存，但不应该阻止重新探测 endpoint 和展示菜单。

排查步骤：确认是不是本地 model 字段锁住了

在 DeepAI API 中转站后台确认至少有两个可用模型，并记录准确 model ID。
用 curl 或其他客户端请求 https://api.deepai.wang/v1/models，确认模型列表能返回。
运行 hermes model，选择自定义 provider，观察是否直接提示切换到旧模型。
检查 Hermes 配置文件中的 custom_providers[].model 是否已经写入第一次选择的模型。
临时移除该 model 字段或重新添加 provider，再运行 hermes model 验证模型菜单是否恢复。

如果移除保存的模型后菜单恢复，说明 DeepAI API 中转站连接和模型列表本身没有问题，真正的问题是客户端提前返回逻辑。

正确的产品行为应该是什么

Issue #6862 的期望行为也很适合所有多模型客户端参考：即使已经保存了当前模型，hermes model 仍应重新探测 endpoint，并展示模型选择菜单；当前模型可以标记为 (current)。如果 endpoint 探测失败，再回退到保存的模型，并允许用户手动输入一个模型名。

这种设计对 API 中转站更友好，因为网关侧模型列表可能经常变化：新增低价模型、下线旧模型、替换供应商、按团队权限开放不同模型。客户端每次都能探测列表，才能真实反映中转站的路由状态。

DeepAI 中转站侧应该看哪些日志

有没有请求 /v1/models：如果切换模型时完全没有 models 请求，说明客户端可能走了本地缓存。
实际 chat 请求的 model：确认 Hermes 发送的 model 是否还是第一次保存的模型。
模型 ID 是否精确匹配：不要混用展示名、别名和真实路由 ID。
网关是否返回多模型列表：如果 /v1/models 只有一个模型，问题就在网关配置或权限上。

常见误区

反复改网关路由：客户端已经锁住本地 model 时，网关列表变化不会自动触发菜单。
把 Base URL 写成具体接口：Base URL 应到 /v1，这样客户端才能访问 /models 和 /chat/completions。
只看聊天是否成功：聊天成功只能说明当前保存的模型可用，不代表模型切换功能可用。
把 model 当成固定 provider 属性：对多模型中转站来说，provider 是入口，model 是每次调用或当前选择，不应该永久阻断选择流程。

适合站长的多模型接入建议

如果你运营 DeepAI API 中转站，并希望 Hermes Agent、OpenClaw、Cline、Dify、n8n 等客户端都能稳定使用多模型，建议在文档里明确三件事：Base URL 统一写 https://api.deepai.wang/v1；模型 ID 以后台列表为准；客户端如果出现“模型切换不生效”，先检查本地配置里是否保存了旧模型。

同时，后台日志最好能展示 /v1/models 请求、chat 请求中的 model 字段、路由后的真实供应商和状态码。这样用户能快速判断问题发生在客户端缓存、模型列表权限，还是实际模型服务。

参考资料

总结

Hermes Agent 接入 DeepAI API 中转站时，如果自定义 OpenAI-compatible endpoint 明明有多个模型，却总是锁定第一次选择的模型，优先检查 custom_providers[].model 是否触发了本地提前返回。移除或刷新已保存模型，让 hermes model 重新探测 /v1/models，通常就能恢复模型选择菜单。对多模型 API 中转站来说，客户端不要把 provider 和 model 绑死，才能真正发挥统一路由和灵活切换的价值。