从报错到跑通：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 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.
排查顺序
-
先确认 Gateway 真的在运行（参见上一节） -
检查 baseURL 是否正确 -
临时切换到限流更宽松的模型测试
五、配置文件里藏着一个隐蔽的路径错误
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 验证配置是否正确。
配置文件中包含四个模型：
在排查限流问题时，先用 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 明文暴露
一页速览
常见问题 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 管理员申请开放脚本执行权限，或者由管理员在域策略层面做调整。
