消息回错人、模型换不了?OpenClaw v2026.6.11 修复了 100+ 个可靠性问题

消息可靠性 · 通道修复 · 模型容错 · v2026.6.11 ——
OpenClaw 在本版把渠道投递与模型恢复的稳定性往前推了一大步。

OpenClaw：你的个人 AI 助理

OpenClaw 是一个自托管的个人 AI 助理，你把它装在自己的设备上（macOS /
Linux / Windows），通过 Telegram、WhatsApp、Discord、Slack、飞书、微信、
Matrix、Signal、iMessage、Mattermost、QQ 等 30 多个渠道与它交互。
它不只是聊天机器人——网关（Gateway）作为控制平面，支持多 Agent 编排、
技能市场、记忆 Wiki、定时任务与 Canvas 渲染。

截至 v2026.6.11，项目在 GitHub 上已获得 38 万 Star，采用 TypeScript
开发，运行在 Node 22.19+ 之上，可通过 npm / pnpm / Docker / Nix
等多种方式部署。它的核心理念是：网关是控制面，助理才是产品本身——
你在哪聊天，助理就在哪出现。

支持 50+ 个 Provider（OpenAI、Anthropic、Google、DeepSeek、Ollama、
LM Studio 等），超过 300 个模型种类。多 Agent 架构允许用户在同一个
网关上运行不同配置的角色，各自拥有独立的会话、记忆与工具集。

消息乱飞、回复重复，痛点在哪

用自托管 AI 助理久了，总有些「不太可靠」的时刻。

你通过 Telegram 问一个问题，助理回复了，但内容却出现在错误的聊天
窗口。或者它在 WhatsApp 群里回答了老半天，结果引用的是上周的旧消息。
更常见的是——回复突然消失，网关没报错，但消息就是没发出去；重启后
队列积压的消息又一股脑涌出来，对话上下文彻底错乱。

这些不是用户配置的问题，而是多通道投递引擎在并发、重连、超时等
边界条件下的积累性缺陷。二十多个渠道各有一套 API 行为——Telegram
的轮询与 Webhook 差异、Matrix 的 E2EE 内存泄露、Google Chat 的 DM
与 Space 路由歧义、iMessage 的延迟回显、WhatsApp 组群回话的引用漂移——
任何一个环节出错，用户感知的就是「助理又抽风了」。

模型层面也暗藏隐患：OpenRouter 的 DeepSeek V4 因前缀重复报模型找不到、
LM Studio 量化模型因后缀不匹配被拒绝、推理模型的内部思考泄露到回复中、
token 配额耗尽后 fallback 不触发、长期运行后 provider catalog 过大导致
内存暴涨。这类问题累积起来，用户对自托管助理的信任就会打折扣。
v2026.6.11 正是为收敛这类社区反馈而发布的一次地毯式修复。

本版能解决哪些实际问题

跨渠道消息不再串场。 旧版 Google Chat 的私聊消息有时被当成群聊
广播，本版修正了 DM 与 Space 的路由边界。Telegram 引用回复不再跳到
错误的会话，WhatsApp 群聊回复在重连后也不会引用到过期的助理消息。
iMessage 里延迟到达的链接预览与发送指令合并为同一轮对话，避免助理
自言自语。多条渠道连续发信时的重复回复问题也被修复——Telegram、
Discord、Slack 上不再出现回答出现两次的情况。

卡住的消息会自动恢复。 这是社区呼声最高的问题之一。以前 Telegram
消息在长任务或网关重启后会卡在队列里，只能人工进数据库清理。现在
系统能自动识别卡住的消息并恢复处理，后续消息不必等人工介入。Matrix
的 E2EE 网关在长期运行后不再因内存泄漏而崩溃——无限增长的缓冲区
现在加了上界检查，超限时主动报错而非持续吞内存。

模型选择与 fallback 更可靠。 MiniMax TTS 因音频格式不匹配而失败的
问题已解决；Gemini 模型通过 OpenAI 兼容接口执行 Cron 不再因空字段
被拒；LM Studio 的量化模型名后缀不再引发误匹配；OpenRouter 的
DeepSeek V4 短 ID 不再因重复前缀报 model_not_found。DeepSeek 风格
的推理模型在启用 /reasoning on 后，推理与最终回答正确分离，不再
混成一团。Cron 和 Agent 任务在主模型失败后能正确切换到备用模型，
即使是 LLM request failed 这类通用错误也会触发 fallback。Codex 配额
耗尽自动切 fallback，不再停在报错上。

大 catalog 不再拖垮网关。 OpenRouter、LM Studio 等返回超大 model
catalog 时，OpenClaw 会拒绝超限响应并报错，不再把整个响应全载入内存。
长期运行的 provider catalog 累积不再影响 /models 列表的响应速度。

会话与记忆不再莫名丢失。 WebChat 在休眠或网络断开后保持可见，
不消失。大历史会话列表不再卡死数秒。QMD 内存搜索超时后主动终止
后台进程，不浪费 CPU。大型工具输出不会卡住 /compact。Windows 用户
的 QMD 绝对路径（含盘符）不再被错误截断。会话内存总结不再包含 raw
token、tool call 块和占位符，摘要更干净。

运维体验提升。 Mattermost 原生斜杠命令 /oc_queue 可直接调整
队列模式、去抖延时与丢弃策略。openclaw memory status 正确显示 REM
阶段。网关日志恢复显示 provider、model 与请求耗时，排查问题不再需要
开 debug 级别。

为何这一版能做到更可靠

OpenClaw 的通道层本质上是一个多路消息总线：
每个渠道以插件形式注册到网关，通过统一的 send / reply /
progress 接口与 Agent 核心交互。本次修复集中在三个层级：

队列层。 所有渠道的消息先进入持久化 SQLite 队列，再逐条投递。
旧版队列在 K8s 环境下因环境变量过多导致数据库打开阻塞——本版优化了
初始化时序，并在单条消息超时后自动恢复后续投递，不再让一条消息卡住
整条通道。队列数据库在环境变量密集的场景下也能快速打开。

会话层。 每条消息的 routing key 由「来源渠道 + 会话 ID + 引用链」
三元组确定。本次修复了跨客户端切换时 routing key 的 UUID 漂移问题——
用户在 Telegram 和 WebChat 之间切换时，旧版可能把回复送错会话。
现在通过规范化会话键和跨设备路由缓存保证一致性。
同时，多条渠道连续发送场景下的重复投递检查（dedup）也被加固，
从 O(n²) 的全量比对改为带索引的碰撞检测。

模型容错层。 模型调用被封装为可重试单元，支持 fallback 链。
之前 LLM request failed 这类通用错误并未触发 fallback，本版将
配额耗尽、流超时、响应过大、模型未找到等更多场景纳入 fallback 条件，
并在重试时保留 fast-mode 等运行时设置，避免回退策略与当前会话的
行为不一致。provider catalog 的响应体大小增设了硬上限，防止
恶意或意外的大型响应耗尽内存。

总体而言，v2026.6.11 没有引入炫目的新功能。
但它修复了超过 100 项社区上报的边缘缺陷——对于每天依赖自托管助理
处理消息的用户来说，这比任何新功能都更值得立即更新。