Hermes / OpenClaw · 五步实测顺序

Hermes / OpenClaw 接入 MonkeyAI:先按五步顺序实测,再改配置

改 provider 配置前先验证 API。路由、凭据、配置文件、重启、最小请求——同一套顺序适用于 Hermes Agent、OpenClaw 以及任何 OpenAI 兼容网关。

为什么『安全顺序』值得照做?

直接结论:它把『接口失败』和『配置失败』分开。每一步只验证一层,验证通过再进下一步。如果带正确 Key 调 GET /v1/models 仍然失败,说明问题在 API 本身;这时改 provider 配置只会增加噪音。

本文所有五项检查都在 2026-08-08 对线上 monkeytheme.com 接口做了实测,分别使用无凭据、伪造 Bearer Key、伪造 x-api-key 三种方式触发。下文表格里的结果都是直接复制的原始响应。

第一步——先确认路由,再确认 Key

不带凭据的请求至少要到达网关的认证层。如果路由返回的是 HTML 或通用 404,说明客户端根本没有命中 OpenAI 兼容接口。

curl -sS https://monkeytheme.com/v1/models
# HTTP 401 —— {"code":"API_KEY_REQUIRED","message":"API key is required ..."}
curl -sS https://monkeytheme.com/models
# HTTP 404 —— nginx 默认 404 HTML(路径不对)

/v1/chat/completions、/v1/responses、/v1/messages、/v1/embeddings 四个端点在没有 Key 时都返回同样的 API_KEY_REQUIRED。这正好覆盖 Agent 客户端会主动调用的几类接口。

第二步——确认凭据被接受

伪造 Bearer Key 和伪造 Anthropic 风格的 x-api-key 都能到达认证层,但服务端返回的错误码不同,便于区分"无 Key / 错 Key / Key 来自另一套系统"。

探测HTTP错误码能确认什么
完全无凭据401API_KEY_REQUIRED路由可达,认证头解析逻辑正常
伪造 Bearer sk-xxx401INVALID_API_KEY服务端识别 Bearer 方案,并拒绝陌生 Key
伪造 x-api-key + anthropic-version401INVALID_API_KEYAnthropic 风格头也被接受,Claude Code 类客户端可走通这条认证路径
伪造 Bearer 调 /v1/messages401INVALID_API_KEYMessages 端点也走同一套凭据流程

这和 OpenAI 兼容客户端的预期一致:只要在 Authorization 里放 Bearer 头,就能到达认证层;服务端会明确告诉你 Key 不对,而不是悄悄拒绝。

第三步——Hermes Agent / OpenClaw 配置怎么写

Hermes Agent 官方文档描述了 custom_providers 配置:把一个 OpenAI 兼容的 Base URL 指向第三方网关。任何支持 OpenAI 兼容模式的 Agent 网关都可以使用相同的写法。

# ~/.hermes/config.yaml
model:
  default: gpt-5.4
  provider: monkeytheme
  base_url: https://monkeytheme.com/v1
  api_key: sk-***

custom_providers:
  - name: monkeytheme
    base_url: https://monkeytheme.com/v1
    api_key: sk-***
    models:
      - gpt-5.5
      - gpt-5.4

保存后重启 gateway 进程,让新的 custom_providers 生效。Hermes Agent 会缓存 OpenAI 客户端对象——换 Key 或新增 provider 会重建客户端,但长会话里模型列表变化往往需要重启或开新会话才能感知。

不要把 API Key 贴到聊天、截图或公开仓库里。上面的示例是 sk-***;请用 MonkeyAI 后台签发的真实 Key 替换。

第四步——挑一个后台真实展示的模型名

在改 provider 配置前,先确认模型名对当前账号可见。直接用线上 models 接口:

curl -sS https://monkeytheme.com/v1/models \
  -H "Authorization: Bearer sk-***" \
| python3 -c 'import json,sys; [print(x.get("id")) for x in json.load(sys.stdin).get("data", [])]'

把返回的 id 原样写到 models: 列表或当前模型字段。显示名、其他服务商的教程、凭记忆猜测的别名,都会让 model not found 在凭据和 Base URL 都正确的情况下仍然出现。

第五步——重启 + 跑一条最小请求

改完配置后,重启 gateway 或开新会话,然后跑一条最短的 completion 验证全链路:

curl -sS https://monkeytheme.com/v1/chat/completions \
  -H "Authorization: Bearer sk-***" \
  -H "Content-Type: application/json" \
  -d '{"model":"gpt-5.4","messages":[{"role":"user","content":"hi"}]}'

如果返回正常 completion,说明 provider 配置已经接通;如果还是 401,问题在 Key 或 Base URL 上,不在 Agent 的 provider 列表里。

本文明确不覆盖什么

相关教程与参考资料

常见问题

Hermes Agent 能把 monkeytheme.com 当作第三方 provider 吗?

可以。先用 /v1/models 探测通过,再在 custom_providers 里把它配置成 OpenAI 兼容 provider,使用 MonkeyAI 的 Base URL 和真实 API Key。

OpenClaw 走同一套配置吗?

可以,只要它的 provider 配置支持 OpenAI 兼容端点。同样按『路由 → Key → 配置 → 重启 → 跑一条请求』五步顺序。

可以直接改 provider 配置、再测接口吗?

不建议。如果直连 API 已经失败,再改 provider 配置只会增加噪音。先用同一 Key 测 /v1/models,再动 provider 配置。

为什么改完配置要重启?

Hermes Agent 与多数 OpenAI 兼容客户端都会缓存启动时构建的 OpenAI 客户端对象。重启或开新会话可以避免凭据、Base URL 或模型列表停留在旧状态。

只接受 Authorization: Bearer,还是 x-api-key 也行?

都能到达认证层。2026-08-08 的实测显示,对 /v1/messages 发伪造 x-api-key + anthropic-version 会得到 401 INVALID_API_KEY,行为与 Anthropic 协议客户端一致。

模型列表返回 HTML 或 404 怎么办?

说明请求进入了网站或 SPA 路由,而不是 API。检查最终 Base URL,确认路径是 /v1/models,并避免客户端重复拼接 /v1。