掉线丢消息,OpenClaw 4.12 这次全修了

如果你用 OpenClaw 处理长任务，或者接了多个消息渠道，你大概遇到过这类情况：

任务跑到一半掉了，没有报错，就是不动了。或者某个渠道莫名其妙断了，重启之后又好了，不知道为什么。

v2026.4.12-beta.1 集中修了这类问题。下面逐一说。

WebSocket 在长任务中自己断开

这个问题发生在用 Web UI 或 webchat 跑长时间任务的用户身上。

任务还在跑，但 WebSocket 连接突然断了。原因不是网络，是心跳超时——服务器发的 tick 广播被标记成了"可丢弃"，当客户端处理速度稍慢时，tick 就被自动丢弃，心跳计数超时，客户端自己断开。

修法：tick 广播现在标记为不可丢弃。无论客户端多慢，心跳不会被抛弃，连接也不会因为心跳超时而断开。

这个问题是有提交记录可查的，PR #65256，感谢两位社区贡献者发现并定位。

这个问题出现在用 cron 跑隔离 Agent 任务的场景里。

你给 cron 任务指定了特定的 workspace 路径和 heartbeat 配置，任务开跑没问题，但 gateway 一旦热重载（不是重启，是热重载），后续的 cron 任务就忘了这些配置，用默认值跑，结果往往是找错文件、回错渠道。

修法：isolated-agent 的配置现在在运行时重载后会保留，不会被热重载快照清空。

另外，cron 任务还有一个连带的问题：每次运行完，transcript 路径没有正确持久化，下次运行会追加到旧的 session 文件里。这个也一起修了。

这个问题发生在 Discord gateway 频繁重连的场景（比如 bot 掉线重连、网络抖动）。

重连时，旧的 heartbeat 计时器没有被清掉，新旧两个计时器同时触发，产生冲突，导致进程直接崩溃，在途的消息全部丢失。

修法：重连之前，现在会强制清理所有旧的 heartbeat 计时器，不留僵尸 callback。

这个问题发生在集成了 iMessage 的用户身上。

OpenClaw 启动时，watch.subscribe 偶尔会失败（原因是本地 iMessage 传输层短暂不可用）。以前遇到这种情况，整个 iMessage 频道监听器直接被干掉，需要手动重启。

修法：现在会对短暂失败进行重试，成功后再初始化监听器；同时对日志输出做了清理，不会把原始 imsg RPC payload 直接打到日志里。

WhatsApp 的集成一直有个隐患：登录恢复、重连、出站消息发送，这些操作可能在不同的代码路径里各自维护连接引用，导致实际活跃的 socket 和某些路径持有的引用对不上。

表现为：有时候消息发不出去，或者断线了但系统以为还连着。

修法：连接所有权现在统一集中管理，所有路径都从同一个地方拿 live socket，不再各自持有副本。

Dreaming 模块在某些条件下，会对同一个 heartbeat 事件触发多次处理。

具体表现：Dreaming 开始运行的频率比预期高，日志里看到同一任务被重复触发，记忆整理产生重复条目。

修法：现在每个 managed heartbeat 事件只会被消费一次，加了显式的去重逻辑。

Dreaming 做完梦会生成 narrative transcript 文件，用于记录本次的记忆整理过程。这些文件用完之后应该被清理掉。

但在之前，有两类情况会导致清理失败：

修法：

这个 beta 版本的稳定性修复没有一个是"可选的"——每一个都对应一类真实用户遇到的问题。

如果你在用 OpenClaw 跑长时间任务、多渠道集成、或者定时 cron 任务，这个版本值得关注。特别是 WebSocket 断联和 Gateway cron 配置丢失这两个，是影响日常使用体验最明显的两个问题。