OpenClaw provider 配置指南：OpenAI、Anthropic、OpenRouter 到底怎么接

很多人第一次配 OpenClaw 的 provider，最大的误区不是不会填 API Key，而是把选模型和接 provider 当成了一回事。实际上，OpenClaw 官方的模型文档写得很清楚：正确顺序是先完成 provider 认证，再把默认模型设置成 provider/model。也就是说，provider 是入口，模型是挂在入口后面的具体选择。如果这两步混了，后面就很容易出现明明写了模型，为什么还是不能用的问题。

这篇文章就只解决一件事：OpenClaw 里最常用的三条路——OpenAI、Anthropic、OpenRouter，到底该怎么接。我会按小白最容易听懂的方式来讲：先讲三家的本质区别，再讲最稳的配置方法，最后讲出问题时该怎么查。你看完以后，至少会清楚三件事：我该选哪一家、我该怎么接、我接不上时先查哪里。

本文侧重点：OpenAI、Anthropic、OpenRouter 三家 provider 的接入方式、认证差异、环境变量配置与默认模型设置。如果你尚未完成 OpenClaw 基础安装，请先阅读 OpenClaw 安装失败怎么办？从环境到权限的完整排查；如果遇到模型配置报错，请参考 OpenClaw 模型配置常见报错汇总：model not allowed、No API key found 到底怎么解决？。

一、先说结论：三家 provider 没有绝对谁最好，只有谁更适合你

如果你想先要一个最直白的答案，我给你一句话：

• OpenAI 更适合想直接走 OpenAI 官方 API，或者已经在用 ChatGPT/Codex 订阅的人
• Anthropic 更适合你本来就想用 Claude，或者你已经在主机上登录过 Claude CLI
• OpenRouter 更适合你不想被单一厂商锁死，想用一个 API Key 去切很多模型的人

OpenClaw 官方的 provider 目录和 quickstart 也基本是这个思路：先选 provider，再做认证，然后把默认模型设成 provider/model。在这套体系里，OpenAI、Anthropic、OpenRouter 都属于主流首发入口，但它们的接法和适用场景并不完全一样。

所以，你后面千万不要纠结成一句谁更强。更该问的是：我现在更需要的是官方直连、Claude 生态，还是一个能灵活换模型的统一入口？

二、OpenClaw 配 provider 的正确顺序，不是先改配置文件

很多新手一上来就想直接手改 ~/.openclaw/openclaw.json。不是不能改，但官方其实已经给了更稳的路线：优先用 onboarding。

官方模型文档和 provider quickstart 都写得很清楚，推荐路径是：

1. 先认证 provider，通常用 openclaw onboard
2. 再把默认模型设成 provider/model

最通用的命令就是：

openclaw onboard

如果你不想手工管理环境变量，官方认证文档也明确说了：onboarding 可以把 API Key 存成 daemon 可用的配置，适合长期运行的 Gateway。

当然，OpenClaw 也支持手改配置。官方配置文档写明了，主配置文件是：

而且 Gateway 会监控这个文件并自动热加载。不过官方也提醒：配置是严格校验的，未知字段、类型不对、值非法，都会让 Gateway 拒绝启动。对小白来说，这就是为什么我更建议你先走 onboarding，而不是第一步就自己乱改 JSON。

三、OpenAI 怎么接：其实有两条路，不要混了

在 OpenClaw 里，OpenAI 严格说不止一条路，而是两条：

1. OpenAI API key 路线，也就是直接走 OpenAI Platform
2. OpenAI Codex / ChatGPT OAuth 路线，也就是 openai-codex/*

这一步很多人最容易混淆。因为你看到的都像 OpenAI，但它们在 OpenClaw 里的 provider id 不一样，适用场景也不一样。

1）直接 API 路线：适合你有 OpenAI Platform API Key

官方 OpenAI provider 页写得很明确：Option A 是 OpenAI API key (OpenAI Platform)，适合 direct API access 和按量计费。最简单的 CLI 配法是：

openclaw onboard --auth-choice openai-api-key
# 或
openclaw onboard --openai-api-key YOUR_API_KEY

配置示例里，默认模型写法是：

{
  "env": { "OPENAI_API_KEY": "sk-..." },
  "agents": { "defaults": { "model": { "primary": "openai/gpt-5.4" } } }
}

官方当前文档还特别提醒：直接 OpenAI API 路径可用的是 gpt-5.4 和 gpt-5.4-pro；gpt-5.3-codex-spark 不走这条直连 API 路线，OpenClaw 会把它视为 Codex-only。

这段话翻译成人话就是：如果你拿的是 OpenAI 官方 API Key，就优先用 openai/...，不要把它和 Codex 订阅路线混在一起。

2）Codex/ChatGPT 路线：适合你有 ChatGPT/Codex 订阅或已登录 Codex CLI

官方 OpenAI provider 页把 Option B 写得也很清楚：如果你想用 ChatGPT/Codex 的订阅访问，而不是 API key，就走 openai-codex。

对应命令是：

openclaw onboard --auth-choice openai-codex
# 或
openclaw models auth login --provider openai-codex

默认模型写法会变成：

{
  "agents": { "defaults": { "model": { "primary": "openai-codex/gpt-5.4" } } }
}

官方 onboarding 文档还说明，如果你机器上已经有 ~/.codex/auth.json，onboarding 可以直接复用现有 Codex CLI 登录。

这一点非常适合已经在终端里用 Codex 的人。因为你不用再额外维护一套 OpenClaw 专属登录，OpenClaw 会尽量复用现有的 Codex 登录状态。

OpenAI 这条线最容易踩的坑

最容易踩的坑就是：

• 你拿着 API Key，却去配 openai-codex/...
• 你本来想走订阅/OAuth，却写成了 openai/...
• 你把 Spark 当成了普通 OpenAI API 模型来用

所以你只要记住一句就行：OpenAI API Key 用 openai/...；ChatGPT/Codex 订阅用 openai-codex/...

四、Anthropic 怎么接：最稳的是 API Key，但 Claude CLI 也能复用

Anthropic 在 OpenClaw 里的路线，比很多人想象中更灵活。

官方 Anthropic provider 文档写得很明确：OpenClaw 既支持 Anthropic API key，也支持 Claude CLI reuse。而且官方当前说明里还特别提到，OpenClaw 现在把 Claude CLI 复用视为被允许的集成方式；但如果你的 Gateway 是长期运行的服务器主机，Anthropic API key 仍然是最清晰、最可预测的生产路径。

1）API Key 路线：最适合生产和长期运行

官方给出的 CLI 配法是：

openclaw onboard
# 选择：Anthropic API key

# 或非交互
openclaw onboard --anthropic-api-key YOUR_API_KEY

配置示例是：

{
  "env": { "ANTHROPIC_API_KEY": "sk-ant-..." },
  "agents": { "defaults": { "model": { "primary": "anthropic/claude-opus-4-6" } } }
}

也就是说，如果你想要最清楚的计费路径、最容易长期跑 Gateway 的方式，Anthropic API Key 是官方更推荐的生产做法。

2）Claude CLI 路线：适合你本机已经在用 Claude Code / Claude CLI

Anthropic provider 文档里还有一条很多人会很喜欢的路：如果你主机上已经登录过 Claude CLI，OpenClaw 可以直接复用这套登录。官方甚至写得很直白：如果 Claude CLI reuse 在主机上可用，那它现在是可支持的路径。

这条路线最适合两类人：

• 你平时本来就在本机用 Claude CLI
• 你不想额外再维护一套单独的 OpenClaw API Key 流程

但我还是要说一句最实在的话：如果你是长期运行的 Gateway 主机，Anthropic API Key 仍然更稳。

Anthropic 这条线最容易踩的坑

Anthropic 最大的坑不是不会接，而是：

• 把本机临时 CLI 登录误当成长期服务器可依赖方案
• 以为本机能用 Claude CLI，daemon 模式下 Gateway 也一定能吃到
• 多 Agent 场景里忘了 Anthropic 认证是按 Agent 状态隔离管理的

所以 Anthropic 这条线最稳的判断标准其实很简单：

| 场景 | 推荐方式 | |------|---------| | 个人机器自己玩 | Claude CLI 复用很方便 | | 长期在线、稳定生产 | Anthropic API Key 更可预测 |

五、OpenRouter 怎么接：最适合一个入口切很多模型的人

OpenRouter 在 OpenClaw 里的定位非常清楚。官方 provider 页直接写了：OpenRouter 提供一个统一 API，用单一 endpoint 和 API key 路由到很多模型；它是 OpenAI-compatible 的。

这句话的真正含义是：如果你不想被一家模型绑死，或者你想更灵活地切换底层模型，OpenRouter 是非常顺手的入口。

官方给出的配置步骤非常简单：

openclaw onboard --auth-choice openrouter-api-key

而且它在 onboarding 里默认会把模型先设成：

如果你后面想切到更具体的模型，可以再执行：

openclaw models set openrouter/provider/model

这两个动作都在官方 OpenRouter provider 文档里写得非常明确。

OpenRouter 最适合什么人

我给你说得最直白一点：

• 你想先跑起来，不想一上来就在厂商里做死选择
• 你想一个 API Key 管很多模型
• 你后面可能会频繁做模型切换、对比、fallback

那 OpenRouter 往往很省脑。

OpenRouter 最大的优点

不是更高级，而是灵活。你不需要为每次试模型都换整套 provider 认证路径，这对新站长、测试党、折腾型用户特别友好。

OpenRouter 最容易踩的坑

它最容易出现的问题其实也很典型：

• 以为 onboarding 设了 openrouter/auto 就永远不用管模型
• 以为所有模型都适合工具调用
• 以为 OpenRouter 有 key，系统里别的 provider 就自动都能用

这里你一定要记住：OpenRouter 是一个统一入口，不是给其它 provider 自动补认证。你走的是 OpenRouter 这条链，就把模型、fallback、成本控制都按 OpenRouter 路线来理解。

六、环境变量到底该放哪：这是最容易把人搞崩的一步

很多 provider 接不上，根本不是 provider 文档没看懂，而是密钥放错地方了。

OpenClaw 官方认证文档写得非常清楚：对于长期运行的 Gateway，API Key 一般是最可预测的方案；而且如果 Gateway 是通过 systemd 或 launchd 跑的，官方明确建议把 key 放到：

因为 daemon 更容易从这里读到环境变量。官方给出的推荐方式甚至直接是：

cat >> ~/.openclaw/.env <<'EOF'
PROVIDER_API_KEY=...
EOF

然后重启 Gateway，再执行：

openclaw models status
openclaw doctor

去确认它有没有真的读到。

这也是为什么很多人会遇到这种诡异情况：我在当前终端 export 了变量，我自己在这个 shell 里觉得一切正常，但 OpenClaw 一跑就说没有认证。

原因很简单：真正跑的是 Gateway daemon，不是你当前这个 shell。

所以，给你一个最稳的结论：

| 场景 | 环境变量放置位置 | |------|----------------| | 临时测试 | 当前 shell export 也可以 | | 长期运行 | 优先放 ~/.openclaw/.env |

七、默认模型怎么写，才不容易把自己绕进去

OpenClaw 的模型文档和 provider quickstart 都强调了一件事：默认模型的核心配置在：

如果你还要设置后备模型，则是：

官方的 quick model policy 也给了非常实用的建议：

• primary 设成你当前能用的最新、最强主力模型
• fallbacks 用来承接成本、延迟或低优先级任务
• 工具调用场景尽量别选太弱的模型

这一步翻译成小白能听懂的话就是：不要一开始就想全都要。先配一个你最确定能跑通的主模型，再慢慢加 fallback。

最简单的三个示例

OpenAI API 路线

{
  "env": { "OPENAI_API_KEY": "sk-..." },
  "agents": { "defaults": { "model": { "primary": "openai/gpt-5.4" } } }
}

Anthropic API 路线

{
  "env": { "ANTHROPIC_API_KEY": "sk-ant-..." },
  "agents": { "defaults": { "model": { "primary": "anthropic/claude-opus-4-6" } } }
}

OpenRouter 路线

先走 onboarding，默认就是：

后面再按需要改成更具体的 openrouter/provider/model。

八、接完以后别猜，直接查：最实用的命令是 openclaw models status

这一点很关键。

官方 models CLI 文档写得很清楚：openclaw models status 会显示：

• 当前解析后的 default / fallbacks
• auth 概况
• 某些 provider 还能显示 usage window 和 quota snapshot

如果你加上：

openclaw models status --probe

它会对已配置 provider 跑真实认证探测。官方也特别提醒了：--probe 是真实请求，会消耗 tokens，还可能触发 rate limit。

所以最实用的排查顺序就是：

openclaw status
openclaw gateway status
openclaw models status
openclaw models status --probe
openclaw doctor

官方 FAQ 也把 openclaw status、openclaw gateway status 放在前 60 秒如果东西坏了先做什么的首位。如果排查过程中遇到复杂报错，建议参考 OpenClaw 常见报错总表：安装、模型、审批、权限一次看懂。

九、最容易踩的三类大坑

坑一：把 provider 认证和模型选择混为一谈

你以为写了 primary 就算接好了。其实没有认证，模型名写得再漂亮也没用。

OpenClaw 的正确顺序永远是：先 auth，再设 model。

坑二：把当前 shell 的环境变量，当成 daemon 永久环境

这会导致我明明有 key，为什么 OpenClaw 还说没有的经典事故。

长期运行的 Gateway，优先把 key 放进 ~/.openclaw/.env。

坑三：OpenAI、OpenAI Codex、Anthropic CLI、OpenRouter 这些路径混着用

这是最容易让配置逻辑变乱的一种情况。你应该先决定你到底走哪条路径，再去配：

| Provider 路线 | 模型前缀 | |--------------|---------| | OpenAI API | openai/... | | OpenAI Codex / ChatGPT OAuth | openai-codex/... | | Anthropic API | anthropic/... | | OpenRouter | openrouter/... |

十、到底该怎么选：我给你最简单的决策建议

如果你现在还是纠结到底先接哪家，我给你一个最省脑的版本：

你想最稳、最清晰

先接 Anthropic API Key 或 OpenAI API Key。

这两条都属于直连官方、路径清楚的思路。对于长期 Gateway，API Key 也是官方更推荐、更可预测的方式。

你本来就在用 ChatGPT/Codex

那就考虑 openai-codex。

尤其你本机已经有 Codex CLI 登录时，OpenClaw 能直接复用，体验会更顺。

你想灵活换模型、少绑死

先接 OpenRouter。

它最适合先跑起来，再慢慢细分的人。

你本来就在用 Claude CLI

个人本机使用可以直接考虑 Anthropic + Claude CLI reuse；但长期在线生产环境，还是更建议 Anthropic API Key。

结语：Provider 配置最怕的不是复杂，而是路线没想清楚

很多人一上来就想：先把 OpenAI 配一点，再把 Anthropic 也挂上，OpenRouter 也先来一个，反正多多益善。

结果不是更强，而是更乱。

OpenClaw 官方文档其实已经把最稳的思路给你了：先选一个 provider，完成认证，再设默认模型。能跑通以后，再谈 fallback、切模型、多 provider。

所以，真正的建议不是全都接，而是：先把一条路走通。

你先把一条 provider 链路真正配通，再看 models status、再看 --probe、再决定要不要扩第二条。这比一开始就把自己绕进三套认证体系里，强太多了。

延伸阅读

• OpenClaw 安装失败怎么办？从环境到权限的完整排查 - 解决基础安装和环境问题
• OpenClaw 模型配置常见报错汇总：model not allowed、No API key found 到底怎么解决？ - 针对性解决模型配置报错
• OpenClaw 常见报错总表：安装、模型、审批、权限一次看懂 - 全面排查各类报错
• OpenClaw 多 Agent 通信失败怎么办？消息路由、角色配置与上下文隔离排查 - 多 Agent 场景配置指南