OpenClaw 2026.10.10 让我这台机器上的每轮聊天都出错了（11 轮全失败）。更新什么时候才能不再像赌博一样？

从 openclaw 还叫 moltbot 的时候，我就一直在用了。这六个多月里，我断断续续地活跃在这个 subreddit。更新已经有了一套固定流程：阅读发布说明、试运行、让更新程序独立运行，然后用脚本检查每个模型和每个连接，通常再借助一个外部模型把问题修好。大家都知道：这套流程的存在是有原因的。但今天连这都没用。今天早上，我从 2026.9.7 升级到了 2026.10.10。这个版本发布才大约七个小时，而且标记为 latest。- 迁移把我的 claude-cli 模型引用改写成了 anthropic 引用。有个智能体是我特意设成以 API 为主、Claude CLI 为备用的。更新后，它被固定到了 CLI，备用配置也没了。只能从更新前的配置里恢复。- 接着，我主聊天里的每一次智能体交互都失败了。11 次，全部失败。SQLite 工作线程有一个硬编码的 512 MB 堆内存上限，而我的主会话很大（约 12.7 万条对话记录事件，智能体数据库有 1 GB）。工作线程触及上限后，就会因 ERR_WORKER_OUT_OF_MEMORY 崩溃并重新启动，接着对数据库进行一次完整的完整性检查，在树莓派上耗时最长可达 28 秒。当时正在处理的内容就全没了。大约 50 分钟内，工作线程崩溃了 13 次。- 在 Telegram 里，表现出来的就是“智能体数据库执行准入已关闭”、“这次 Codex 会话在你的消息运行前发生了变化。请重新发送。”或者“OpenClaw 无法完成此请求”。已经生成的回复也始终没有送达。- 从 Codex 切换到 Claude 毫无作用。/new 也没用；会话 ID 还是原来的。昨天用 2026.9.7 时，同一个会话、同一个数据库：这些错误一次都没出现。最精彩的是：针对这一类完全相同的故障，早就已经有一个 issue（#185953，报告于 2026.10.7：无边界的对话记录读取导致这个 512 MB 的工作线程崩溃）。它被以“已在 main 分支实现”为由关闭了。但在 2026.10.10 上，这个问题依然存在。在仓库的 issue 中搜索“admission is closed”，能搜到 56 条结果。而且这也不是第一次了。六月那次更新后，我得先修复 Codex OAuth，才能做最基本的冒烟测试。上周，每一次 Codex 请求都报 403 错误：“Codex 无法验证此模型请求的所有者”，持续了大约 45 分钟，直到重启网关才解决。我曾在 Hermes 的猛烈攻势下维护 OC，也试着帮助其他用户熬过痛苦的更新，自己的问题更是修过无数次，但我想我终于到了受够了的地步。我以为稳定版就应该是稳定的？我知道这是开源项目，也知道大家投入了很多个人精力，但说实话，每次更新我们都会遇到这些问题，总被告知情况会好转，结果却越来越糟。如果有人关心，这是 issue 链接：https://github.com/openclaw/openclaw/issues/191847