绕了一上午我才搞懂 OpenClaw 为什么不回我消息本文基于一次真实的端到端排障经历。涉及的 IP、端口、API Key、requestId 等敏感信息已脱敏替换为占位符。一、0 故障爆发AI 助手突然变成 AI 静默“OpenClaw 用不了了。”下午两点钉钉群里有人我。紧接着 Web 管理端、命令行三个渠道同时传来消息——都是发出去没人回。直觉告诉我这是大故障。但直觉这种东西有时候是朋友有时候是坑。这次直觉是坑。实际根因是四个小 bug 叠在一起Web 端设备未配对 默认模型认证失败 上下文窗口过小 偶发限流。任何一个单拎出来都不致命但叠在一起就让 OpenClaw 看起来像完全死了。我花了一整个上午去定位和修复中间绕了不少路。这篇文章把整个过程还原出来——不仅讲怎么修更讲我是怎么走偏的、走偏后怎么拉回来的。希望未来某天你或者我自己在凌晨两点碰到类似情况能省下两个小时。二、第 1 误判把设备配对当成频道配对第一动作是查 Gateway 状态openclaw gateway status进程存活但Connectivity probe失败状态是pairing-pending。“pairing-pending”——我第一反应是去查pairing命令。当时挺自信的文档里说得很清楚pairing就是处理未配对设备的。跑openclaw pairing list回我一句Channel required. Use --channel channel我盯着屏幕看了三秒。“Channel required”我只是想列一下待配对设备为什么要我指定频道那一刻我才反应过来——OpenClaw 内部把设备和频道当成两回事。pairing是给消息频道钉钉、Telegram用的Web 管理端是 WebSocket 连接归devices管。命名差异很小但语义边界很清楚。切换到正确的命令openclaw devices list openclaw devices approverequest-id批准之后Web 端立刻活了。Connectivity probe从pairing-pending变成ok。小小一个命名差异让我绕了十分钟。三、第 2 误判以为只是临时抖动其实是认证失败钉钉那边还在报Something went wrong或者更具体的(2064) 服务集群负载较高。我以为是临时抖动等了五分钟。还在报错。又等了十分钟。还是不通。翻日志。openclaw logs--tail30看到一行关键错误LLM error authentication_error: invalid api key auth or provider access failed for provider-name.authentication_error我明明配过 API Key怎么会认证失败打开~/.openclaw/openclaw.json一眼扫过去两个 Provider。第一个https://api.official-domain/anthropic没有apiKey字段——我之前用官方服务的时候配过后来切到内网就把这块忘了没删干净。第二个http://内网IP:内网端口/v1apiKey 完整baseUrl 正确。我手动curl验证了一下内网服务curlhttp://内网IP:内网端口/v1/models\-HAuthorization: Bearer api-key返回正常模型列表——服务本身没问题。真相浮现OpenClaw 启动时默认选中了第一个 Provider也就是那个没配 key 的官方 Provider。第二个虽然能用但系统压根没去问它。四、绕路四十分钟CLI、JSON、删 Provider接下来发生的事情现在回想起来都觉得有点打脸。我花了大概四十分钟跟 CLI 和 JSON 配置文件死磕。尝试 1CLIopenclaw configsetmodels.defaultProviderprovider-b-id# Config validation failed: models: Invalid input→ 这个版本的 CLI不支持defaultProvider字段。尝试 2手动编辑 JSON在models对象里手动加defaultProvider字段。→ 重启 Gateway 直接报Invalid config服务起不来。紧急回滚备份。尝试 3删除无效 Provider A编辑配置文件把 Provider A 整个块删掉。→ Gateway 起来了但我也知道这操作太粗暴——万一以后想用官方服务就没了。我甚至开始认真考虑要不要自己改 OpenClaw 源码把 defaultProvider 字段加进去。现在回头看思路已经完全跑偏了。五、✅ 转折答案就在 Web UI 的下拉框里就在我准备动手改源码的时候眼睛扫过 Web 管理端的导航栏http://gateway-host:18789/openclaw/agents点进去。Model Selection → Primary model (default)下拉框里清清楚楚列着所有可用的 Provider。我选了 Provider B保存。钉钉和 Web 端立刻就通了。没有重启没有改配置没有动一行代码。那一刻我有点想笑。绕了一大圈最优解就在我每次打开都看过、但从来没点进去过的地方。为什么这是最优解Web UI 的模型选择是运行时配置优先级高于配置文件默认值。多个 Provider 可以共存显式指定即可避免冲突。零风险、实时生效、操作直观。万一选错下拉框再切一次就行比回滚备份安全多了。这次教训是工具的设计者早就把最安全的路径放在了离你最近的位置。绕远路只是因为你太相信自己的第一直觉。六、后续优化上下文窗口与限流主要故障修好之后还有两个非关键问题顺手处理了。6.1 上下文窗口过小跑长对话时OpenClaw 报错Auto-compaction could not recover this turn. Please use /new.查了一下openclaw.json里 Provider B 的模型配置contextWindow只配了 4000。短对话够用长对话就会触发 compaction 失败。应急/new清空会话。永久修复把contextWindow和maxTokens调大并加上compaction.reserveTokensFloor{models:{providers:[{id:provider-b-id,models:[{name:...,contextWindow:204800,maxTokens:131072}]}]},agents:{defaults:{compaction:{reserveTokensFloor:20000}}}}一个数字没配对前面的所有努力都可能白费。6.2 钉钉(2064)限流钉钉偶尔返回(2064) 当前服务集群负载较高。这个错误很容易误判为钉钉渠道故障。真相是内网 AI 服务商的频率限制跟 OpenClaw 和钉钉都没关系。对策稍后重试或者联系服务商升级配额。七、排查决策树思维导图文字版故障现象钉钉 / Web / CLI 均无回复 │ ├─ 第一步基础状态检查 │ └─ openclaw gateway status → pairing-pending ? │ ├─ 是 → 设备未配对 │ │ └─ openclaw devices list → openclaw devices approve request-id │ └─ 否 → 进入第二步 │ ├─ 第二步查看日志定位核心错误 │ └─ openclaw logs --tail 30 │ ├─ invalid api key / authentication_error → 模型认证失败 │ │ ├─ 优先Web UI 切换 Providerhttp://host:18789/openclaw/agents │ │ ├─ 兜底删除无效 Provider 或修正 apiKey │ │ └─ 最后修改配置文件 重启 Gateway │ ├─ contextWindow / compaction → 上下文超长 │ │ └─ /new 清空调大 contextWindow 和 reserveTokensFloor │ └─ blocked for inference → 账户受限 │ └─ 切换 Provider 或检查账户余额 │ ├─ 第三步消息渠道单独不响应 │ ├─ Web 端不响应 → 检查 devices 配对 │ ├─ 钉钉不响应 → openclaw pairing list --channel dingtalk │ └─ CLI 不响应 → openclaw chat --provider provider-b-id │ └─ 第四步偶发限流 (2064) └─ 稍后重试联系 AI 服务商升级配额八、标准操作流程SOP按优先级排序从最安全、最简单开始。 第一优先Web UI 切换模型适用场景多 Provider 共存其中一个无效需要显式指定可用模型。步骤访问http://gateway-host:18789/openclaw/agentsModel Selection→Primary model (default)下拉框选择可用的 Provider / 模型保存 → 立即生效为什么最优先运行时配置覆盖默认值零风险无需重启 Gateway。 第二优先处理配对 / 连接问题连接类型查看待批准批准命令Web 管理连接WebSocketopenclaw devices listopenclaw devices approve request-id消息频道钉钉 / Telegramopenclaw pairing list --channel channelopenclaw pairing approve --channel channel user-id 第三优先日志定位openclaw logs--tail30常见错误关键词与对策错误关键词原因对策invalid api key/authentication_errorAPI Key 无效或未配置1. Web UI 切换 Provider2. 更新配置文件apiKeypairing-pending设备 / 用户未批准devices approve或pairing approvecontextWindow/compaction上下文超长/new调大contextWindow和reserveTokensFloorblocked for inference账户受限切换 Provider 或检查余额第四优先修改配置文件最后手段操作前必做备份cp~/.openclaw/openclaw.json ~/.openclaw/openclaw.json.bak修改后必做openclaw config validate# 验证配置openclaw gateway restart# 重启生效第五优先处理钉钉限流(2064)这是AI 服务商限流不是 OpenClaw / 钉钉的问题。对策等待 1-5 分钟后重试降低并发联系服务商升级配额。九、关键经验教训Web UI 优先于 CLI— 多数配置尤其是模型选择可 Web 端覆盖更安全、更快捷。Provider 可以共存— 多个 Provider 不会冲突关键是显式指定可用的那个。日志是灯塔—openclaw logs --tail 30比任何猜测都有效所有关键错误都会在日志中显现。配对命令要分清—devices管 Web 连接pairing --channel管消息频道。上下文管理是长期健康的关键— 对于支持大上下文的模型务必调大contextWindow和reserveTokensFloor避免频繁出现 compaction 错误。(2064)不是钉钉的锅— 它是 AI 服务商限流的外显表现不要误判为钉钉渠道故障。最复杂的问题答案有时就在最简单的地方— Web UI 的下拉选择胜过 CLI 和 JSON。踩过的坑比读过的书更有价值。十、本次故障最终状态检查项状态Gateway 运行状态runningConnectivity probeokWeb 端消息回复✅ 正常钉钉消息回复✅ 正常命令行openclaw chat✅ 正常长对话上下文已调大阈值稳定运行钉钉(2064)限流偶发稍后重试可恢复我是magicCzc一个把 AIOps 当信仰的运维开发工程师。GitHubhttps://github.com/magicCzc
