共计 6802 个字符，预计需要花费 18 分钟才能阅读完成。
之前写了两篇关于 [[OpenClaw]] 的文章，一篇介绍了 OpenClaw 是什么以及怎么部署，另一篇聊了它的 OpenClaw 核心文件。搭建起来之后，很多朋友问的第一个问题就是——我不想直接用 OpenAI 或者 Anthropic 的官方 API，能不能接第三方中转服务？答案当然是可以的，而且 OpenClaw 在这方面的设计非常灵活。我自己日常用的就是通过中转站来调用模型，一方面是价格更便宜，另一方面国内访问起来也更稳定。这篇文章就来详细聊一下，怎么在 OpenClaw 里面配置和使用第三方模型。
为什么要用第三方模型
在聊具体配置之前，先说说为什么需要折腾第三方模型。OpenClaw 默认支持的是 Anthropic Claude 和 OpenAI 的官方 API，对于大部分用户来说直接用官方的当然是最省心的。但在实际使用中，你可能会遇到几种情况让你想要接入第三方服务。首先是成本问题，如果你像我一样把 OpenClaw 当成日常工具高频使用，每天让它帮忙处理各种任务，那 API 调用费用累积起来是一笔不小的开支，而很多中转服务提供了更有竞争力的价格。其次是访问稳定性，特别是在国内网络环境下，直连 Anthropic 或 OpenAI 的 API 有时候会不太顺畅，通过一个部署在合适位置的中转服务可以大幅改善响应速度。最后还有一个很现实的需求——模型多样性，你可能想在不同任务场景下使用不同的模型，比如简单任务用便宜的小模型，复杂推理用 Claude Opus 或者 GPT-4.1，通过中转服务可以在一个入口管理多个模型。
配置第三方模型
理解了为什么之后，来看具体怎么做。OpenClaw 的第三方模型配置思路非常直觉，核心就是在配置文件中告诉它：你有一个新的模型提供商，它的地址在哪里、怎么认证、支持哪些模型。配置的关键只有四个字段 baseUrl，api，apiKey，models，理解了这四个字段基本上就搞定了。
假设你有一个典型的 OpenAI 协议兼容的中转服务，它的入口地址是类似 https://example.com/v1 这样的格式。我们需要在 openclaw.json 配置文件当中添加一个自定义 Provider，把中转服务的信息填进去，同时把默认模型指向这个新的 Provider。
{
agents: {
defaults: {
// 把主模型指到你中转的 provider/model
model: {
primary: "myproxy/gpt-4.1"
// 可选：fallbacks: ["openai/gpt-4.1-mini", "ollama/llama3.3"]
},
models: {
"myproxy/gpt-4.1": {}
}
}
},
models: {
// 推荐用 merge，避免覆盖内置的 OpenAI / Anthropic 等
mode: "merge",
providers: {
"myproxy": {
// 你的第三方转发服务地址（一般是 OpenAI 兼容的 /v1）
baseUrl: "https://llm-proxy.example.com/v1",
// 不建议明文写 key，最好用环境变量占位
apiKey: "${MY_PROXY_API_KEY}",
// 大多数转发站都是 OpenAI Chat Completions 协议
api: "openai-completions",
// 告诉 OpenClaw 这个 provider 底下有哪些模型可用
models: [
{
id: "gpt-4.1", // 这里必须是中转站要求的 model 字段
name: "Proxy GPT‑4.1"
},
{
id: "gpt-4.1-mini",
name: "Proxy GPT‑4.1 Mini"
}
]
}
}
}
}
这段配置看起来内容不少，但拆开来看每一部分都很好理解。我来逐个解释一下几个关键字段的含义和注意事项。
provider/model 这对字符串是 OpenClaw 里面引用模型的标准格式。上面配置里面的 myproxy 就是 provider 的名字，gpt-4.1 则是这个 provider 下面的具体模型。配置好之后，你可以在聊天界面里用 /model myproxy/gpt-4.1 命令来切换到这个模型，也可以通过 agents.defaults.model.primary: "myproxy/gpt-4.1" 把它设为所有会话的默认模型。这个命名规则非常清晰，即使你接入了好几个不同的中转服务，也不容易搞混。
baseUrl 填的是你中转服务暴露的 OpenAI 兼容端点，一般就是 .../v1 这个路径。需要注意的是不要漏掉末尾的 /v1，因为 OpenClaw 会在这个基础上拼接 /chat/completions 等路径来发送请求。如果你的中转服务用的是非标准端口或者有额外的路径前缀，确保在这里写完整。
apiKey 这个字段强烈推荐使用环境变量的方式来填写，也就是 "${ENV_NAME}" 这种写法。实际的 Key 放到 Shell 环境变量里面，比如 export MY_PROXY_API_KEY='sk-xxx'。这样做的好处是配置文件可以放心地提交到版本控制系统，不用担心泄露密钥。特别是如果你的 OpenClaw 是用 Docker 部署的，可以直接在 docker-compose.yml 的 environment 里面设置这些变量。
api 这个字段决定了 OpenClaw 用什么协议格式跟上游服务通信，后面会单独展开讲。大多数中转站用的都是 OpenAI 兼容的 Chat Completions 协议，所以填 "openai-completions" 就行。如果你的中转站对外暴露的是 /v1/chat/completions 这种 OpenAI 风格的接口，就填 "openai-completions"；如果是 /v1/messages 并且明确标注了 Anthropic 兼容，就填 "anthropic-messages"。
用 CLI 方式配置
除了手动编辑配置文件之外，OpenClaw 还提供了 CLI 命令来完成同样的配置，这对于不喜欢手动改 JSON 或者想在脚本里自动化配置的场景特别方便。
openclaw config set 'models.providers.myproxy' --json '{
"baseUrl": "https://llm-proxy.example.com/v1",
"apiKey": "${MY_PROXY_API_KEY}",
"api": "openai-completions",
"models": [
{ "id": "gpt-4.1", "name": "Proxy GPT‑4.1" },
{ "id": "gpt-4.1-mini", "name": "Proxy GPT‑4.1 Mini" }
]
}'
# 再把默认模型指到这个 provider
openclaw config set 'agents.defaults.model' --json '{
"primary": "myproxy/gpt-4.1"
}'
CLI 配置和手动编辑 JSON 文件的效果完全一样，只是方式不同。如果你管理着多台服务器上的 OpenClaw 实例，用 CLI 写成脚本批量配置会轻松很多。
验证配置
配置完成之后需要重启 Gateway 才能生效。重启之后可以用几个命令来验证配置是否正确。
openclaw gateway restart
# 查看这个 provider 是否被识别
openclaw models list --provider myproxy
# 做一次真实探测（会真的打到你的中转服务）
openclaw models status --probe
models list 命令会列出 OpenClaw 识别到的所有模型，你应该能在输出里看到刚刚配置的 myproxy/gpt-4.1 和 myproxy/gpt-4.1-mini。而 models status --probe 则会真正往中转服务发送一个测试请求，确认连通性没有问题。如果 probe 返回了错误，通常是 baseUrl 写错了、apiKey 无效，或者中转服务本身有问题，按照报错信息排查就行。
配置 Anthropic 协议
上面的例子用的是 OpenAI 兼容协议，但如果你的中转服务走的是 Anthropic 的原生协议呢？配置方式几乎一模一样，唯一的区别就是把 api 字段从 "openai-completions" 改成 "anthropic-messages"。
{
models: {
mode: "merge",
providers: {
"my-anthropic-proxy": {
baseUrl: "https://claude-proxy.example.com",
apiKey: "${CLAUDE_PROXY_KEY}",
api: "anthropic-messages",
models: [
{ id: "claude-3.7-opus", name: "Proxy Claude Opus 3.7" }
]
}
}
},
agents: {
defaults: {
model: {
primary: "my-anthropic-proxy/claude-3.7-opus"
}
}
}
}
就这么简单，api: "anthropic-messages" 一改，剩下的逻辑与 OpenAI 兼容中转完全一致。OpenClaw 会自动按照 Anthropic 的 Messages API 格式来构造请求和解析响应。
理解 api 字段的三种协议
这里配置的 api 字段实际上就是告诉 OpenClaw 用什么协议格式跟上游模型服务通信。OpenClaw 会根据你选择的协议类型，决定请求体的构造方式和响应的解析策略。目前支持三种协议，各有各的适用场景。
openai-completions 对应的是 OpenAI 兼容的 Chat Completion 风格，也就是大家最熟悉的 /v1/chat/completions 端点。它的典型请求字段包括 messages、model、temperature、tools（function calling）等。这个协议的最大优势是兼容性好，市面上绝大多数第三方中转网关都支持这个格式，包括 [[New API]]、[[sub2api]]、[[LiteLLM]] 等常见的转发工具。如果你不确定该选哪个协议，选 openai-completions 基本上不会出错。
openai-responses 是 OpenAI 推出的较新的 Responses API，对应 /v1/responses 端点。它统一了文本生成、多模态输入、工具调用以及结构化输出等能力，在新功能的支持上比传统的 Completions 更完整。但缺点也很明显——因为出来得比较晚，第三方中转服务对它的兼容度可能不如 Completions。除非你有明确的需求要用到 Responses API 的独有功能，否则一般不需要选这个。
anthropic-messages 对应的是 Anthropic Claude 的原生 API 格式，端点是 /v1/messages。典型字段包括 messages、max_tokens、system、tools、thinking 等。如果你用的就是 Claude 模型并且中转服务支持 Anthropic 格式的透传，选这个协议对 Claude 原生能力的支持是最好的，包括 extended thinking 等高级特性都能正常使用。
如果你用的中转服务是 [[New API]] 这类通用网关，端点通常都是 /v1/chat/completions，直接选 openai-completions 就对了。[[sub2api]] 也一样。如果是专门为 Claude 搭建的中转（比如 [[claude relay service]]），并且中转端明确说支持 Anthropic 格式，那就选 anthropic-messages 以获得最佳体验。
手动切换模型
配置好多个模型之后，日常使用中最常见的操作就是切换模型了。OpenClaw 提供了 /model 命令来实现手动切换，直接在聊天界面里输入就行，非常方便。
需要注意的是，/model 命令切换的是当前会话的模型，不会修改配置文件。也就是说，当你开启一个新会话或者 Gateway 重启之后，模型会自动回到配置文件中设置的默认值。这个设计其实挺合理的——你可以在某个特定对话中临时切换到一个更强的模型来处理复杂任务，处理完之后不影响其他对话继续使用默认的经济型模型。
还有一点需要了解的是，/model 命令只能切换到配置文件白名单中的模型。配置文件中有一个 models 字段专门控制这个白名单，只有列在其中的模型才能通过 /model 命令切换。这是一个安全设计，防止有人通过命令注入的方式让 OpenClaw 去访问未经授权的模型端点。
如果你配置了模型的别名，切换起来会更加方便。比如你可以给 my-anthropic-proxy/claude-3.7-opus 设一个简短的别名叫 opus，之后直接 /model opus 即可完成切换，不需要每次都敲那么长一串。
自动故障切换
除了手动切换，OpenClaw 还有一个非常实用的 fallback chains 功能，可以实现模型的自动故障切换。在配置文件当中，你可以为默认模型设置一个 fallback 数组，列出一系列备用模型。当主模型出了问题的时候——比如超时、认证失败或者触发了服务商的限流——OpenClaw 会自动按照 fallback 数组中的顺序依次尝试备用模型，整个过程不需要你手动干预。
这个功能在实际使用中非常重要。我自己的配置是主模型用 Gemini 3 Pro（因为性价比不错），但在 fallback 列表里放了 Codex、Opus、Sonnet 等几个不同供应商的模型。这样即使某一家的 API 抽风了，OpenClaw 也能无缝切换到备用模型继续工作，不会因为一个模型的故障而整个停摆。特别是当你把 OpenClaw 配置了定时任务（Heartbeat）来自动执行一些工作的时候，这种自动故障切换就更加关键了，毕竟你不可能 24 小时盯着它看。
我们甚至还可以直接让 OpenClaw 自己来帮忙编写 fallback 配置——在聊天里告诉它你想用哪些模型做备选，它会直接帮你生成配置并写入文件。
实际可用的第三方模型
说了这么多配置方法，最后聊聊有哪些实际可用的第三方模型和中转服务可以接入 OpenClaw。
EV API
EV API是我自己维护的大语言模型代理服务，目前支持 OpenAI、Anthropic Claude、Gemini 等主流的大语言模型。如果你不想自己折腾中转服务的搭建和维护，可以注册后直接付费使用，配置起来就是标准的 OpenAI 兼容协议，填好 baseUrl 和 apiKey 就能用。
nvidia 官方提供的免费模型
NVIDIA 的 Integrate API 平台上有一些免费可用的模型，比如 MiniMax 的模型。配置的时候用以下信息就行：
- baseUrl:
https://integrate.api.nvidia.com/v1 - api:
openai-completions - 模型 ID:
minimaxai/minimax-m2.1
免费这一点确实很香，但实话说响应速度不太理想，比较适合对延迟不敏感的场景，比如后台的定时分析任务。如果你的使用场景是实时对话，等待时间可能会让你有点焦躁。
常用中转服务一览
如果你想自建中转服务或者使用社区维护的方案，以下几个工具值得关注：
- [[New API]] —— 一个开源的 API 管理和分发面板，支持多种模型供应商的统一接入，社区活跃，功能完善
- [[claude relay service]] —— 专门为 Claude 模型设计的中转服务，支持 Anthropic 原生协议的透传
- [[sub2api]] —— 轻量级的订阅转 API 工具，适合将订阅制的模型服务转换成标准 API 格式
- [[CLIProxyAPI]] —— 一个命令行友好的 API 代理方案
- [[LiteLLM]] —— 一个 Python 写的统一 LLM API 代理，支持 100 多个模型供应商，可以将不同供应商的 API 统一成 OpenAI 兼容格式
这些工具各有侧重，你可以根据自己的需求和技术偏好来选择。如果只是想快速用起来，直接使用现成的中转服务是最省事的；如果你对隐私和控制权有更高的要求，自建中转服务会是更好的选择。
最后
OpenClaw 在第三方模型接入这件事上做得相当开放和灵活。四个核心字段（baseUrl、api、apiKey、models）就能搞定一个新的模型供应商，配合 merge 模式不会影响已有的内置供应商，再加上 fallback chains 的自动故障切换，基本上覆盖了日常使用中的各种场景。我自己目前的配置是同时接了三个不同的模型供应商，通过 fallback 链来保证可用性，日常主力用中转站的 Gemini 和 Claude 交替，遇到复杂任务再手动切到 Opus。这套配置跑了一段时间下来，体验还是非常稳定的。如果你也在用 OpenClaw，强烈建议花点时间把第三方模型配好，毕竟能用更便宜的价格获得同样的体验，何乐而不为呢。
