中国用户最稳的思路，通常不是先去找国外最强模型，而是先把一条 官方支持明确、中文效果稳定、网络更友好 的 provider 跑通。OpenClaw 当前官方文档里，对中国用户最值得优先看的路线主要有：Z.AI（GLM）、Qwen Portal、MiniMax、Moonshot AI（Kimi）、Qianfan，以及 provider catalog 里列出的 Volcengine / 豆包。
中国模型路线最容易写乱的地方，不是谁更强，而是要先区分官方内置 provider、Portal / 插件登录路线，以及兼容接口 / 自定义 provider。这一步分清楚，后面接入和排障就会顺很多。
先记住这条边界
- 有独立 provider 页面：优先按官方 onboarding / auth 路线接。
- 只有兼容接口或第三方中转：优先走 custom provider / OpenAI-compatible provider。
- 不要因为模型是中国厂商，就自动当成“OpenClaw 一定有内置 provider”。
最推荐优先看的 6 条中国路线
Z.AI（GLM）
这是当前最清晰、最适合拿来说明中国 provider 接法的一条路线。官方 provider 页面给了明确示例：你可以用 openclaw onboard --auth-choice zai-api-key 进入认证流程，模型命名示例是 zai/glm-5。
如果你的重点是代码、结构化输出和工具调用，这条路线很值得优先试。
Qwen Portal
Qwen 在 OpenClaw 官方文档里更接近“portal / OAuth 插件登录路线”，不是简单的“填一个通义 API Key 就完事”。当前官方页面给出的关键动作是：
openclaw plugins enable qwen-portal-authopenclaw gateway restartopenclaw models auth login --provider qwen-portal --set-default
如果你本来就有 Qwen 官方门户账号，这条路比自己拼接兼容 API 更稳。
MiniMax
MiniMax 官方页面同时覆盖了 API key 路线 和 portal / 插件路线。文档里给出的 portal 路线动作包括：
openclaw plugins enable minimax-portal-authopenclaw gateway restartopenclaw onboard --auth-choice minimax-portal
官方模型概念页还特别提到：MiniMax 在写作和整体“vibes”上往往更讨喜，这对内容生产类工作流很有参考价值。
Moonshot AI（Kimi）
Moonshot AI / Kimi 也有官方 provider 页面，但更适合你把它理解成一条“清晰可接的官方 provider 路线”，而不是所有教程里那种手写散装兼容配置。对中文长文、日常办公和摘要场景，这条路线很常见。
Qianfan
如果你原本想找“文心一言怎么接”，在 OpenClaw 官方文档体系里更应该先看 Qianfan。官方示例给出的 CLI 入口是 openclaw onboard --auth-choice qianfan-api-key。这也是为什么知识库里我更推荐写“Qianfan 路线”，而不是直接把“文心”写成另一个独立内置 provider。
Volcengine / 豆包
根据官方 provider catalog，Volcengine / 豆包已经在当前模型目录里占有明确位置。但不同版本下，具体认证入口是否单独露出，可能取决于你当前使用的 OpenClaw 版本和 provider catalog。更稳的写法是：先看 provider catalog 有没有现成入口；如果没有，就按兼容 endpoint 走 custom provider。
官方地址与 OpenClaw 接法速查
下面这张表把当前知识库里最常用的中国模型路线统一放在一起。你可以直接按 官网 / API 平台 / OpenClaw 接法 三步去核对，不用在多个页面来回跳。
| 平台 | 中文入口 | 英文 / 国际入口 | API / 控制台 / 文档 | OpenClaw 主流接法 | 一句话说明 |
|---|---|---|---|---|---|
| Z.AI / GLM | z.ai | 同站多语言入口 | platform.z.ai | 内置 provider。优先用 openclaw onboard --auth-choice zai-api-key，模型名通常写成 zai/glm-5。 |
当前最适合中国用户拿来先跑通的一条官方路线之一，代码、工具调用和中文综合表现都比较稳。 |
| Qwen / 通义千问 | chat.qwen.ai | qwen.ai | DashScope Console | 官方更推荐 Qwen Portal 登录路线。常见做法是启用 qwen-portal-auth 插件，再执行 openclaw models auth login --provider qwen-portal --set-default。 |
中文能力成熟，适合企业和阿里云生态用户；如果你本来就常用官方门户，这条线比自己拼兼容 API 更顺。 |
| MiniMax | minimaxi.com | minimax.io | platform.minimaxi.com | 官方支持 API Key 和 Portal 登录 两条线。Portal 路线常见步骤是启用 minimax-portal-auth 插件，再用 openclaw onboard --auth-choice minimax-portal。 |
写作、对话气质和内容生产体验常被提到，适合自媒体和运营类工作流。 |
| Moonshot AI / Kimi | kimi.com | moonshot.ai | platform.moonshot.cn | 内置 provider。优先在 onboarding 或 provider 认证流程里直接选 Moonshot AI，不要优先写成散装兼容接口。 | 中文长文、摘要、办公助手场景很常见，很多中国用户第一条 Kimi 路线就能把日常对话跑通。 |
| Qianfan / 文心千帆 | 百度智能云千帆 | 官方文档入口 | Baidu Console | 内置 provider。最稳的写法是按 Qianfan 路线做 API Key onboarding，例如 openclaw onboard --auth-choice qianfan-api-key。 |
如果你本来就在百度云生态里，直接走 Qianfan 会比把“文心”当成独立杂项 provider 更清楚。 |
| Volcengine / 豆包 | 火山引擎方舟 | Volcengine Ark | 官方文档 | 优先看当前版本 provider catalog 是否已有现成入口；如果没有，就按 OpenAI-compatible endpoint / custom provider 接入。 | 豆包在中国市场很热门，但在 OpenClaw 里要先区分“内置目录已支持”还是“兼容接口接入”。 |
| DeepSeek | deepseek.com | 同站多语言入口 | platform.deepseek.com | 当前更适合按 custom provider / OpenAI-compatible endpoint 走，不要先假设你手头版本一定有独立 DeepSeek provider 页面。 | 代码和推理讨论热度很高，很多人用第三方聚合站转接 DeepSeek，这时更要把“官方直连”和“中转接入”分清。 |
那 DeepSeek 怎么办
截至我这次校对的官方文档，OpenClaw 并没有像 Z.AI、Qwen Portal、MiniMax 这样给出一篇独立的 DeepSeek provider 页面。这不代表不能用，而是更适合按 OpenAI-compatible endpoint / custom provider 路线接。
同理，如果你用的是第三方聚合站、中转站、公司自建 MaaS 网关，也别硬套成“另一个内置 provider”，直接把它当成自定义 provider 会更清楚。
中国用户最常见的接法总结
- 官方内置 provider：Z.AI、Moonshot AI、Qianfan 这类，优先用 onboarding 或 provider auth 直接走。
- Portal / 插件登录路线：Qwen、MiniMax 这类，有官方门户登录路径时，优先按 portal auth，不要先退回到兼容 API。
- OpenAI-compatible / custom provider：豆包、DeepSeek、SiliconFlow、公司自建网关，默认按这一路理解最稳。
- 多家一起用：先把中文主模型设成
primary，再给它补一条 fallback，下一篇直接看 模型 fallback 与混合调用实践。
给中国用户的推荐顺序
- 只想最快跑通中文能力：优先试 Z.AI 或 Qwen Portal。
- 偏内容生产和日常写作：把 MiniMax 和 Moonshot AI 放进候选。
- 本来就在百度生态：优先走 Qianfan。
- 你要混合多家中国模型：后面直接补 模型 fallback 与混合调用实践。
最常见的 4 个坑
- 把所有中国模型都当成“API key 一填就好”。实际上有些 provider 是 portal / OAuth 插件路线。
- 把第三方中转站错写成官方 provider，后面排障会特别乱。
- 已经切了主模型，但忘了 allowlist，结果报
Model is not allowed。 - 只配 primary 不配 fallback，一旦单家波动，多渠道机器人会一起卡。
最小可行动作
- 先选一条官方 provider 路线完成认证。
- 再用
openclaw models set provider/model切默认主模型。 - 最后补一条 fallback，别把整个系统押在单家单 key 上。