站点图标 高效码农

OpenClaw+GLM安装必坑指南：从乱码报错到成功跑通！避开权限、限流、API路径三大天坑

高效码农

从报错到跑通：OpenClaw + GLM 模型的完整避坑实录

核心问题：在 Windows 上安装并配置 OpenClaw Gateway，对接国产大模型 GLM，究竟会踩哪些坑？每一步该怎么解决？

这篇文章来自一次真实的排障过程。从 schtasks 报错乱码，到 PowerShell 脚本被拒，再到 Gateway 启动后仍然限流、配置路径写错——每一个问题都真实发生过。把这些过程完整记录下来，希望能帮后来者少走弯路。

一、第一道墙：安装时 schtasks 报错乱码

这个报错的本质是权限问题，乱码只是编码不匹配的表象。

运行 openclaw gateway install 时，终端可能出现类似下面这样的输出：

Gateway install failed: Error: schtasks create failed: ����: �ܾ����ʡ�

看到这串问号，很多人第一反应是”安装包坏了”或者”系统不支持”。其实不是。乱码的原因是：Windows 中文系统的命令行默认使用 GBK 编码输出错误信息，而 OpenClaw 用 UTF-8 读取，两者不匹配，中文错误信息就变成了乱码。

真正的错误是什么？

把编码统一后，错误信息是可读的。在 PowerShell 中执行：

chcp 65001

切换到 UTF-8 编码页后重新运行安装命令，就能看到真实的报错内容，通常是”拒绝访问”——即权限不足，无法创建 Windows 计划任务。

解决方法

以管理员身份重新运行安装：

  • 右键点击 PowerShell → 以管理员身份运行
  • 在管理员窗口中重新执行 openclaw gateway install

如果是公司内网的域控机器，计划任务的创建权限可能被组策略锁定，这种情况需要联系 IT 管理员开放对应权限。

“

反思：乱码从来不是真正的错误，它只是挡住了真正的错误。第一步永远是把信息读清楚，再做判断。

二、第二道墙：PowerShell 脚本执行策略限制

这是 Windows 默认的安全机制，解决方法简单，选对范围就好。

解决权限问题后，再次运行命令，可能遇到第二个报错：

openclaw : 无法加载文件 C:\nvm4w\nodejs\openclaw.ps1，
因为在此系统上禁止运行脚本。

完整错误信息中可以看到 PSSecurityException 和 UnauthorizedAccess。这是 Windows PowerShell 的执行策略（Execution Policy） 在生效——默认情况下，系统不允许运行未经签名的本地脚本。

三种解决方式对比

方式 命令 影响范围 推荐程度
当前用户永久生效 Set-ExecutionPolicy -Scope CurrentUser -ExecutionPolicy RemoteSigned 当前用户 ✅ 推荐
仅本次会话生效 Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass 当前窗口 ✅ 最安全
全局修改 Set-ExecutionPolicy -ExecutionPolicy Unrestricted 整台机器 ❌ 不建议

最推荐的方案是”本次会话”模式：

Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass
openclaw gateway install

关闭 PowerShell 窗口后自动恢复原始策略，对系统没有持久影响，也不会留下安全隐患。

验证当前策略

不确定自己的系统处于什么策略？运行：

Get-ExecutionPolicy -List

输出会列出 MachinePolicy、UserPolicy、Process、CurrentUser、LocalMachine 等多个层级，逐级查看即可。

三、Gateway 显示”已重启”，但实际没有运行

“Restarted Scheduled Task”只代表任务被触发，不等于进程真的在跑。

执行完安装后，OpenClaw 输出了：

Restarted Scheduled Task: OpenClaw Gateway

这条信息容易误导人，以为 Gateway 已经启动。实际上，计划任务被触发和进程真正运行是两回事——任务可能因为依赖项缺失、端口冲突或配置错误，在启动后立刻崩溃退出。

如何确认 Gateway 是否真的在运行

方法一：查询计划任务状态

schtasks /query /tn "OpenClaw*" /fo LIST /v

重点查看以下两个字段：

  • Status：应为 Running，而非 Ready 或 Unknown
  • Last Result：应为 0，非零值说明上次运行出错

方法二：检查进程是否存在

Get-Process | Where-Object { $_.Name -like "*openclaw*" -or $_.Name -like "*gateway*" }

如果没有任何输出，说明 Gateway 进程不存在，需要进一步查日志排查启动失败原因。

“

场景说明：在后续的 API 限流排查中，我们发现 Gateway 没有真正运行，导致每次调用都直接打到 GLM API，请求频率远超正常使用，这是触发限流的重要原因之一。先确认 Gateway 状态，再排查 API 问题，是正确的排查顺序。

四、GLM 模型报 API rate limit，问题出在哪里？

限流的根本原因通常有两个：Gateway 未运行导致重复直连，或者模型本身的配额不足。

Gateway 跑起来之前，OpenClaw 的每一次请求都会绕过本地代理，直接访问 GLM API。频繁的重试机制叠加高并发配置（配置中 maxConcurrent: 4，子 agent maxConcurrent: 8），很容易在短时间内触发平台的 RPM 限制。

错误信息如下：

error=⚠️ API rate limit reached. Please try again later.

排查顺序

  1. 先确认 Gateway 真的在运行（参见上一节）
  2. 检查 baseURL 是否正确
  3. 临时切换到限流更宽松的模型测试

五、配置文件里藏着一个隐蔽的路径错误

baseURL 多了一段 /coding/，这是最容易忽视、影响最大的配置错误。

初次配置生成的 config.json 中，baseUrl 字段是：

https://open.bigmodel.cn/api/coding/paas/v4

而正确的标准路径应该是：

https://open.bigmodel.cn/api/paas/v4

中间多了 /coding/ 这一段。这可能是 OpenClaw 配置向导在特定环境下生成的非标路径，或者是历史版本遗留。错误的 URL 不一定直接返回 404，而是可能被服务端路由到一个限流更严格的接口，或者返回格式异常的响应，导致客户端反复重试，进一步加剧限流。

修正配置

打开 OpenClaw 的 config.json，找到 models.providers.zai 节点，将 baseUrl 改为：

"baseUrl": "https://open.bigmodel.cn/api/paas/v4"

修正后的完整 provider 配置示例：

"zai": {
  "baseUrl": "https://open.bigmodel.cn/api/paas/v4",
  "api": "openai-completions",
  "models": [
    {
      "id": "glm-4.7-flashx",
      "name": "GLM-4.7 FlashX",
      "reasoning": true,
      "input": ["text"],
      "contextWindow": 204800,
      "maxTokens": 131072
    }
  ]
}

“

反思：配置路径的问题在早期很难被发现，因为它不会直接报”路径不存在”，而是以其他形式（限流、超时、响应异常）表现出来。遇到 API 问题时，把 baseURL 纳入排查清单是一个好习惯。

六、模型选择：GLM-5 与 GLM-4.7 系列的差异

如果 GLM-5 持续限流，先切换到 GLM-4.7 FlashX 验证配置是否正确。

配置文件中包含四个模型：

模型 ID 名称 适用场景
glm-5 GLM-5 旗舰推理，配额限制严格
glm-4.7 GLM-4.7 通用推理，中等配额
glm-4.7-flash GLM-4.7 Flash 快速响应，适合高频调用
glm-4.7-flashx GLM-4.7 FlashX 最宽松限流，适合调试验证

在排查限流问题时，先用 FlashX 验证整条链路是否通畅，是最有效率的做法。如果 FlashX 能正常响应，说明配置和网络都没问题，限流是 GLM-5 配额不足导致的；如果 FlashX 也限流，则需要去智谱控制台确认账户状态。

临时切换主模型

修改 agents.defaults.model.primary 字段：

"model": {
  "primary": "zai/glm-4.7-flashx"
}

验证通过后，再根据实际需求切回 GLM-5 或其他模型。

七、并发配置与限流的关系

高并发配置是把双刃剑，在账户配额有限的情况下会显著加剧限流。

当前配置中：

"maxConcurrent": 4,
"subagents": {
  "maxConcurrent": 8
}

主 agent 最多 4 个并发，子 agent 最多 8 个。这意味着理论上同一时刻可以有 12 个请求同时发送到 GLM API。对于免费账户或低配套餐，这个并发量很容易触发 RPM（每分钟请求数）限制。

在 Gateway 稳定运行、API 配额明确之前，建议将并发调低：

"maxConcurrent": 1,
"subagents": {
  "maxConcurrent": 2
}

稳定后再根据实际配额逐步调高。

八、Gateway 的本地鉴权配置

Gateway 使用 token 模式进行本地鉴权，token 在配置文件中明文存储，需注意文件权限。

配置文件中的 gateway 节点：

"gateway": {
  "mode": "local",
  "auth": {
    "mode": "token",
    "token": "2e8e1c7ac18d0e5299aee47f2a642985aa50a3f159c2bab9"
  }
}

Gateway 运行在本地模式（mode: local），使用固定 token 进行鉴权。这个 token 是明文写在配置文件中的，如果是多用户共享的开发机，需要确保该配置文件的读取权限做了限制，避免 token 泄露被滥用。

九、完整排障流程回顾

把整个排障过程整理成一条清晰的操作线：

安装报乱码
  └→ 切换编码页（chcp 65001）查看真实错误
      └→ 权限不足 → 以管理员身份重新运行
          └→ 执行策略限制 → Set-ExecutionPolicy Bypass（Process 级别）
              └→ 安装成功，Gateway 显示"已重启"
                  └→ 确认 Gateway 真正运行（schtasks /query + Get-Process）
                      └→ API 限流
                          └→ 检查 baseURL（去掉多余的 /coding/）
                              └→ 临时换 glm-4.7-flashx 验证
                                  └→ 链路通畅，逐步切回目标模型

实用操作清单

在新环境部署 OpenClaw + GLM 时，按顺序执行以下检查：

  • [ ] 以管理员身份运行 PowerShell
  • [ ] 设置执行策略：Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass
  • [ ] 运行安装命令：openclaw gateway install
  • [ ] 验证 Gateway 进程：Get-Process | Where-Object { $_.Name -like "*openclaw*" }
  • [ ] 验证任务状态：schtasks /query /tn "OpenClaw*" /fo LIST /v，确认 Status=Running，Last Result=0
  • [ ] 检查 config.json 中 baseUrl 是否为 https://open.bigmodel.cn/api/paas/v4
  • [ ] 先用 glm-4.7-flashx 测试链路，确认通畅后再切换目标模型
  • [ ] 根据账户配额调整 maxConcurrent 和 subagents.maxConcurrent
  • [ ] 确认 config.json 文件权限，避免 token 明文暴露

一页速览

问题 原因 解决方案
安装报乱码 GBK/UTF-8 编码不匹配 chcp 65001 查看真实错误，通常是权限不足
schtasks 失败 非管理员运行 以管理员身份重新执行安装
脚本无法加载 PowerShell 执行策略限制 Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass
Gateway 显示重启但未运行 任务触发 ≠ 进程存在 Get-Process + schtasks /query 双重确认
API 限流 baseURL 错误 + Gateway 未运行 + 并发过高 修正路径、确认 Gateway、降低并发
baseURL 错误 配置向导生成了含 /coding/ 的非标路径 改为 https://open.bigmodel.cn/api/paas/v4
GLM-5 持续限流 配额不足 临时切换 glm-4.7-flashx 验证，再按需升级配额

常见问题 FAQ

Q1：安装时看到乱码，是系统不支持 OpenClaw 吗？

不是。乱码是 Windows 中文系统与程序编码不匹配的表现，在 PowerShell 中运行 chcp 65001 切换编码后，可以看到真实的错误信息，通常是权限问题。

Q2：执行策略改成 Bypass 安全吗？

使用 -Scope Process 参数时，修改只影响当前 PowerShell 窗口，关闭后自动恢复，不会对系统产生持久影响，是相对安全的临时方案。

Q3：OpenClaw 显示”Restarted Scheduled Task”，是不是就代表 Gateway 启动成功了？

不是。这条信息只说明计划任务被触发，进程是否真正运行需要通过 Get-Process 和 schtasks /query 两个命令来确认。

Q4：为什么 baseURL 多了 /coding/ 也不报 404，而是报限流？

这取决于服务端的路由策略。错误路径可能被路由到一个限制更严格的接口，返回的不是 404 而是正常的限流响应，因此客户端无法直接发现路径错误。

Q5：GLM-5 和 GLM-4.7 FlashX 在使用上有什么实质区别？

从配置文件来看，两者的 contextWindow 和 maxTokens 相同。GLM-5 是旗舰推理模型，配额限制更严格；GLM-4.7 FlashX 限流更宽松，适合在调试阶段验证配置和链路是否正常。

Q6：maxConcurrent 设置多少合适？

取决于账户的 RPM 配额。在不清楚配额上限的情况下，建议从 1 开始测试，确认稳定后再逐步提高。配置中主 agent 4、子 agent 8 的默认值，在低配额账户下很容易触发限流。

Q7：config.json 中的 Gateway token 需要保护吗？

需要。token 以明文形式存储在配置文件中，在多用户共享的机器上应设置文件的读取权限（如 Windows 文件权限或 ACL），防止其他用户读取并滥用该 token。

Q8：公司域控机器上，执行策略改不了怎么办？

域控锁定的执行策略无法通过 Set-ExecutionPolicy 修改，需要联系 IT 管理员申请开放脚本执行权限，或者由管理员在域策略层面做调整。

退出移动版