最近在 Linux 机器上折腾 OpenClaw 接微信，踩到一个很烦的坑，记录一下。
问题现象一开始表现是这样的：
1. 纯文字聊天正常
2. 一发图片，bot 有时会回复一次
3. 之后继续发文字就不回了
4. 微信端有时直接显示：“暂无法连接 openclaw”
5. 服务器上看进程还在，但其实 gateway 已经不健康了
最开始我以为是：
- 微信插件掉线
- session 脏了
- 或者模型不支持图片
-
结果最后发现是多个问题叠在一起。
排查结果
先发现第一个问题：
默认模型当时用的是：
`xiaomi-coding/mimo-v2.5-pro`
这个模型是 text-only，不支持图片。
真正支持图片的是：
`xiaomi-coding/mimo-v2.5`
所以第一步先把默认模型切成了 `mimo-v2.5`。
但改完后，图片依然会把后续对话拖死。
继续查日志，后来终于抓到关键错误：
`Optional dependency sharp is required for image attachment processing`
`Cannot find package 'sharp'`
也就是说：
图片处理链路缺了 `sharp` 这个依赖。
另外，上游图片推理也偏慢，还叠加了 timeout 问题。
真正有效的修复
最后真正起作用的是这几步：
1. 安装 `sharp`
```bash
cd /root/.hermes/node/lib/node_modules/openclaw
npm install sharp
```
2. 把默认模型切成支持图片的：
`xiaomi-coding/mimo-v2.5`
3. 给 provider 调大 timeout
在 `~/.openclaw/openclaw.json` 里给 `xiaomi-coding` 加：
```json
"timeoutSeconds": 180
```
4. 确保微信 channel 配置显式挂回默认实例
5. 对默认 gateway 做一次真正的干净重启
为什么这个坑容易误判
因为当时会出现一种很迷惑的状态：
- `openclaw-gateway` 进程还在
- 端口也还在监听
- 但 `openclaw gateway status` 已经是：
`RPC probe: failed`
`gateway timeout after 10000ms`
也就是说：
“进程还活着” != “gateway 真的健康”
这也是为什么微信端会显示：
“暂无法连接 openclaw”
修好后的验证方式
我最后是这样测的：
1. 发一条纯文字
2. 发一张图片
3. 再发一条纯文字
连续测了两轮，已经恢复正常：
- 文字正常回复
- 图片能处理
- 图片之后还能继续聊
- 微信端不再出现“暂无法连接 openclaw”
踩坑总结
1. `mimo-v2.5-pro` 不支持图片，`mimo-v2.5` 才支持
2. OpenClaw 图片链路缺 `sharp` 会直接出问题
3. “进程活着”不代表 gateway 健康
4. 图片问题可能把整个 gateway 拖进 RPC timeout
5. 这种问题一定要同时看：
- 模型能力
- 图片依赖
- gateway probe 健康状态
- provider timeout
如果有人也在折腾 OpenClaw + 微信图片消息，希望这篇能帮你少踩几个坑。
2 个帖子 - 2 位参与者
来源: linux.do查看原文