OpenClaw GLM-5-Turbo 接入教程与自定义 Provider 配置

如果你想在 OpenClaw 里补一条更偏性价比、同时国内访问更顺的模型路线，GLM-5-Turbo 是很适合加进来的一个选择。

这篇不走“泛泛介绍模型”的写法，而是直接按 OpenClaw 现有自定义 provider 方式，把可落地配置写清楚。

先说结论#

把 GLM-5-Turbo 接进 OpenClaw，核心就 3 件事：

• 准备智谱 API Key
• 把 provider 配成智谱聊天接口地址
• 把默认模型指向 glm/glm-5-turbo

如果你已经配过 Kimi、OpenRouter 或 Ollama 的自定义 provider，这条路会很熟悉。

官方模型页里最值得先记住的 4 个信息#

按智谱官方 GLM-5-Turbo 模型页，现在最关键的信息可以先压缩成这几条：

• 模型 ID：glm-5-turbo
• 聊天接口：https://open.bigmodel.cn/api/paas/v4/chat/completions
• 上下文窗口：200K
• 最大输出：128K

官方页面还明确把它定位成更偏 OpenClaw / Agent 场景优化的模型，强调的能力点包括：

• 思考模式
• 流式输出
• Function Call
• 上下文缓存
• 结构化输出
• MCP

这也是为什么它很适合被放进 OpenClaw 里做一条长期保留的主模型路线，而不只是临时测试模型。

一、先准备 API Key#

先在智谱开放平台拿到 API Key，然后写进环境变量。

export ZHIPU_API_KEY="your-api-key"

如果你是通过启动脚本、.env 或系统服务注入环境变量，也可以继续沿用你当前的方式。关键是让 Gateway 进程能读到这个值。

二、在 OpenClaw 里增加 GLM Provider#

打开你的配置文件：

code ~/.openclaw/openclaw.json

把下面这段合并进去：

{
  "models": {
    "mode": "merge",
    "providers": {
      "glm": {
        "baseUrl": "https://open.bigmodel.cn/api/paas/v4",
        "apiKey": "${ZHIPU_API_KEY}",
        "api": "openai-completions",
        "models": [
          {
            "id": "glm-5-turbo",
            "name": "GLM-5-Turbo",
            "reasoning": true,
            "input": ["text"],
            "contextWindow": 200000,
            "maxTokens": 131072
          }
        ]
      }
    }
  },
  "agents": {
    "defaults": {
      "model": {
        "primary": "glm/glm-5-turbo"
      },
      "models": {
        "glm/glm-5-turbo": {}
      }
    }
  }
}

这段配置的意思其实很简单：

• provider 名我这里命名为 glm
• 智谱聊天接口根地址使用 https://open.bigmodel.cn/api/paas/v4
• 模型 ID 使用官方页面里的 glm-5-turbo
• OpenClaw 侧最终引用名就是 glm/glm-5-turbo

这里补一个很重要的对应关系：

• 官方 curl 示例请求地址是 .../chat/completions
• 在 OpenClaw 自定义 provider 里通常只写根地址 https://open.bigmodel.cn/api/paas/v4
• 具体的 /chat/completions 路径由 api: "openai-completions" 这层协议适配去完成

这一步是基于 OpenClaw 现有自定义 provider 写法做的映射判断，所以如果你后面排障，优先检查的是 provider 协议和根地址是否配对，而不是手动把完整请求路径硬塞进 baseUrl。

三、为什么这里用 openai-completions#

因为智谱这条接口本身走的是与 OpenAI Chat Completions 兼容的请求风格。

对 OpenClaw 来说，这种场景最稳的做法，就是像现有 Kimi 自定义 provider 一样，把 api 配成：

"api": "openai-completions"

这样排障边界会更清楚，也更符合站内已有教程的配置方式。

四、把官方 curl 请求翻译成 OpenClaw 配置思路#

智谱官方页面给出的基础调用，本质上表达的是下面几件事：

• 请求走聊天补全接口
• model 写 glm-5-turbo
• 可以开启 thinking
• 可以设置 max_tokens
• 可以设置 temperature
• 如果要实时输出，就把 stream 打开

如果你用最小可用思路接入 OpenClaw，先只保留：

• 正确的 API Key
• 正确的根地址
• 正确的模型 ID

先把基础链路跑通。

而像下面这些属于第二阶段再调的内容：

• 是否开启更强的思考模式
• 是否要做流式输出
• 输出长度上限
• 采样温度

这样做的好处是，一旦出错，你能先排除是认证问题、provider 协议问题，还是模型参数问题。

五、如果你想按官方参数进一步微调#

官方 curl 示例里最值得你记住的几个请求字段是：

{
  "model": "glm-5-turbo",
  "thinking": {
    "type": "enabled"
  },
  "max_tokens": 65536,
  "temperature": 1.0
}

另外，如果你想做流式响应，官方示例里就是额外加：

{
  "stream": true
}

这部分信息对 OpenClaw 用户的价值主要在两点：

1. 你知道这个模型本身支持这些能力，不是“只能最基础对话”
2. 你后面如果要做更细的 provider 参数适配，就知道应该优先往哪些字段上看

但第一次接入时，我仍然建议不要一开始就把所有高级参数一起塞进去。

六、改完以后要做的验证#

保存配置后，重启 Gateway：

openclaw gateway restart

然后先看模型状态：

openclaw models status
openclaw status --deep

你主要确认 3 件事：

• Gateway 已经读到新的 provider 配置
• 默认模型已经变成 glm/glm-5-turbo
• 不再报认证失败或模型未找到

如果你打算把它作为日常主模型，建议先跑一个最小可执行任务，再去接消息渠道，不要把“模型没配通”和“渠道没配通”混在一起。

七、常见问题#

1. 明明填了 Key，为什么还是不通

先检查：

• ZHIPU_API_KEY 是否真的进入了 Gateway 进程环境
• baseUrl 是否写成了 https://open.bigmodel.cn/api/paas/v4
• 默认模型是否写成 glm/glm-5-turbo

很多时候不是 Key 错了，而是模型名或接口根路径写偏了。

2. 为什么不是直接写 glm-5-turbo

因为在 OpenClaw 里，最终引用的是：

provider/model-id

所以你在 agent 默认模型里应该写：

glm/glm-5-turbo

而不是只写裸模型名。

3. 适不适合做“高性价比主模型”

如果你现在的目标是：

• 想控制调用成本
• 想在国内网络环境里更顺地跑通
• 想给 OpenClaw 增加一条通用主模型路线

那 GLM-5-Turbo 很值得作为一个长期保留的可选主模型。

4. 官方文档里写了 thinking、stream，是不是第一次接入就都要开

不建议。

这些字段说明模型支持这些能力，但第一次接入时，优先目标应该是：

• 先认证成功
• 先识别到模型
• 先跑通最小调用

等基础链路稳定了，再逐步加思考模式、流式响应和更细的输出参数，会更容易排障。

八、一个更稳的使用建议#

第一次接入 GLM-5-Turbo 时，不建议同时做下面这些事：

• 同时新增多个 provider
• 同时改 primary 和 fallback
• 同时改消息渠道
• 同时加一堆高级采样参数

最稳的顺序仍然是：

1. 先把 glm/glm-5-turbo 单独接通
2. 用状态命令验证 provider 正常
3. 跑通一个真实任务
4. 再考虑 fallback、多模型对比和渠道接入

这样出了问题，你会更容易判断到底是模型层、认证层还是 Gateway 层的问题。