这页的重点不应该只是讲“国内网络环境怎么选 provider”，而是把真正能落地的接入方法写清楚。按照 OpenClaw 当前官方文档，和国内环境关系最密切、且已经有明确接入说明的 provider，主要可以先看这几条：
- MiniMax
- Moonshot AI（Kimi）
- Qwen
- 如果你想统一多家模型入口，也可以结合 OpenRouter
下面这页我只讲“具体怎么接”，不再停留在泛泛建议层。
先给你一个最实用的选择建议
如果你现在只是想先跑通一条国内更顺的模型路线，我建议这样选：
想最快用 API Key 跑通
优先看：
- Moonshot API
- MiniMax API
想走官方 OAuth / 免手动 API Key 风格
优先看：
- MiniMax OAuth
- Qwen OAuth
想要一条国内可用、同时偏“编程模型”的路线
优先看：
- Moonshot / Kimi
- MiniMax
- Qwen Coder
一、MiniMax 接入
MiniMax 是 OpenClaw 官方已经单独提供 provider 文档的一条正式路线，而且官方文档里还专门区分了国际端点和中国端点。
方式 A：MiniMax OAuth，官方推荐
如果你希望快速接入，不手动管理 API Key，官方推荐 MiniMax Coding Plan 的 OAuth 路线。
先启用内置插件并重启 Gateway：
openclaw plugins enable minimax-portal-auth
openclaw gateway restart
openclaw onboard --auth-choice minimax-portal
官方说明这里会提示你选择端点：
Global：国际用户，api.minimax.ioCN：中国用户，api.minimaxi.com
如果你就在国内使用，这一步通常应选 CN。
方式 B：MiniMax API Key
如果你更习惯 API Key，也可以走官方给出的 API 路线。
交互式做法：
openclaw configure
然后选择：
Model/authMiniMax M2.1
官方配置示例的核心结构是：
{
"env": { "MINIMAX_API_KEY": "sk-..." },
"agents": {
"defaults": {
"model": { "primary": "minimax/MiniMax-M2.1" }
}
},
"models": {
"mode": "merge",
"providers": {
"minimax": {
"baseUrl": "https://api.minimax.io/anthropic",
"apiKey": "${MINIMAX_API_KEY}",
"api": "anthropic-messages"
}
}
}
}
这里最关键的几项是：
- 环境变量名：
MINIMAX_API_KEY - provider 名：
minimax - 默认模型：
minimax/MiniMax-M2.1 - 推荐 API 类型：
anthropic-messages
MiniMax 什么时候值得优先选
适合：
- 你希望国内端点更顺
- 你想要官方已经单独适配过的 provider
- 你更偏向编程和复杂任务场景
二、Moonshot AI（Kimi）接入
Moonshot 在 OpenClaw 官方文档里是正式 provider，文档里也明确写了 Kimi 的模型命名和接入方式。
方式 A：Moonshot API
官方 onboarding 命令：
openclaw onboard --auth-choice moonshot-api-key
官方配置片段的核心结构是：
{
"env": { "MOONSHOT_API_KEY": "sk-..." },
"agents": {
"defaults": {
"model": { "primary": "moonshot/kimi-k2.5" }
}
}
}
这里最关键的是：
- 环境变量名：
MOONSHOT_API_KEY - 模型名前缀：
moonshot/... - 常见主模型：
moonshot/kimi-k2.5
官方文档当前给出的 Kimi K2 系列模型 ID 包括：
kimi-k2.5kimi-k2-0905-previewkimi-k2-turbo-previewkimi-k2-thinkingkimi-k2-thinking-turbo
中国端点怎么配
官方特别提到，如果你要用中国端点，可以使用：
https://api.moonshot.cn/v1
这对国内环境很重要，因为它直接关系到连通性和稳定性。
方式 B：Kimi Coding
官方还单独支持 Kimi Coding，它和 Moonshot API 是两条不同 provider 路线。
官方命令：
openclaw onboard --auth-choice kimi-code-api-key
官方配置思路：
{
"env": { "KIMI_API_KEY": "sk-..." },
"agents": {
"defaults": {
"model": { "primary": "kimi-coding/k2p5" }
}
}
}
这里一定要记住一个官方提醒：
moonshot/...和kimi-coding/...不是同一个 provider- Key 不可互换
- 端点也不同
Moonshot / Kimi 什么时候适合优先接
适合：
- 你在国内环境里希望走更顺的 API 路线
- 你想先快速跑通一个偏编程、偏通用的主模型
- 你已经在用 Kimi 生态
三、Qwen 接入
Qwen 在 OpenClaw 官方文档里走的是 OAuth 路线，而且重点是 Qwen Coder / Vision 这套 provider。
第一步：启用插件
官方命令：
openclaw plugins enable qwen-portal-auth
启用后，官方要求重启 Gateway。
第二步：登录并设为默认
官方命令：
openclaw models auth login --provider qwen-portal --set-default
这会执行 Qwen 设备码 OAuth 流程，并把 provider 写进你的模型配置中。
常见模型 ID
官方文档当前给出的模型 ID 包括：
qwen-portal/coder-modelqwen-portal/vision-model
切换模型示例：
openclaw models set qwen-portal/coder-model
Qwen 这条路线的特点
它更像：
- 通过官方 OAuth 登录
- 用 OpenClaw 内置的 provider 条目接入
而不是传统的“手动填 API Key + 手写模型路径”。
Qwen 什么时候值得优先接
适合：
- 你更想用 Qwen Coder
- 你想走 OAuth 设备码流程
- 你已经在用 Qwen Code CLI，想复用登录状态
官方文档还提到，如果你已经用 Qwen Code CLI 登录过，OpenClaw 可以从：
~/.qwen/oauth_creds.json
同步凭证，但你仍然需要一个 models.providers.qwen-portal 条目。
四、怎么验证这些 provider 是否真的接通
不管你接的是 MiniMax、Moonshot 还是 Qwen，建议都按这个顺序验证：
openclaw models status
openclaw status --deep
这两步主要确认：
- provider 认证是否真的成功
- 默认模型是否被系统识别
- 当前 provider 状态是否正常
如果这里都还不对，不要先去渠道里测试，否则会把模型问题和消息入口问题混在一起。
五、推荐的实际落地顺序
如果你现在就在国内环境里准备接模型，我建议按这个顺序：
- 先选一条最简单的主路线
- 先跑通一个主模型
- 用
openclaw models status验证 - 再决定是否接第二家 provider 做 fallback
具体到 provider 选择，可以简单理解成：
- 想直接 API Key：Moonshot / MiniMax
- 想官方 OAuth：MiniMax / Qwen
- 想减少 provider 管理复杂度：后续再考虑 OpenRouter
六、这页最重要的结论
/china-providers 不应该只是泛泛写“国内更适合哪些模型”，而是要落到具体接法上。按照当前官方文档，最值得先用的几条明确路径就是：
MiniMax OAuthMiniMax API KeyMoonshot APIKimi CodingQwen OAuth
如果你愿意，我下一步可以继续把这页再往前推进一层，直接补成“国内模型对比表 + 推荐默认模型 + fallback 组合建议”的完整版本。