我们前面讲了架构、链路、并发、安全，最后一篇工程向收官：
线上出问题时，到底怎么定位。

先建立排障思维

我自己常用一个四步法：

1. 先确认系统是不是“活着”（health/readiness）
2. 再确认是不是“忙死了”（队列/并发/长回合）
3. 再确认是不是“权限或配置错了”
4. 最后看渠道侧和网络侧异常

这个顺序能避免一上来就淹死在日志里。

常用观察入口

命令侧：

• openclaw status
• openclaw status --all
• openclaw health --json

日志侧：

• 关注gateway启动日志
• 关注队列等待日志
• 关注插件加载失败日志

配置侧：

• 重点看auth/channel/queue/session相关关键项

三类高频问题

1) “没回复”

优先排查：

• 渠道连接是否在线
• 消息是否被allowlist/mention策略拦截
• 会话是否卡在长回合

2) “回复乱序/像串台”

优先排查：

• queue mode是否合适
• session key是否按预期分离
• 是否有并发打满导致延迟堆积

3) “回复很慢”

优先排查：

• 模型响应时间
• 工具调用耗时
• 频繁流式更新导致渠道限流

建议保留的最小观测面

即使是个人部署，也建议至少保留：

• 启动阶段关键日志
• 关键命令的状态快照
• 最近会话问题样本（可脱敏）

这样排障时不会全靠“感觉”。

小结

排障能力本质是系统能力的一部分，不是运维附属品。
做到“快速定位 > 盲目重启”，你的OpenClaw系统才算真正进入可长期维护状态。

下一篇番外，我们换个视角：不用完整工程，自己用Python写一个仅CLI交互的迷你版，把核心思想亲手跑起来。

参考链接

• https://docs.openclaw.ai/logging
• https://docs.openclaw.ai/help/debugging