OpenClaw 2026.9.8 是哪天发布的，现在用 npm 装到的是哪一版？

GitHub 发布页上 v2026.9.8 的发布时间是 2026 年 10 月 3 日 03:21（UTC），标着 Latest。截至 2026 年 10 月 7 日，npm 的 latest 标签指向 2026.9.8，beta 指向 2026.10.1-beta.1，extended-stable 指向 2026.8.35。不指定标签安装时，装到的是 latest 对应的 2026.9.8。

想用 GPT-6.1 Sol，升到 OpenClaw 2026.9.8 就可以了吗？

还不完整。GPT-6.1 Sol 的支持在 9.8 里没有做完，相关改动（#161400、#163132）只是为它做准备。要用这个模型，等后续版本的发布说明里出现支持完成的说法再升。

两个 OpenClaw 实例指向同一个数据目录，升到 2026.9.8 以后会怎样？

直接启动或在容器里启动时，9.8 会阻止两份 OpenClaw 同时使用同一份已存数据。需要同时跑两份的，给它们各配一个数据目录。

OpenClaw 文档站 v2026.9.8 发布说明页的开头，左侧版本列表里 v2026.9.8 带 Latest 标记，右侧正文是版本概述段落和 Web UI 小节 — OpenClaw 文档站的 2026.9.8 发布说明页，截于 2026-10

版本 · 升级

OpenClaw 2026.9.8 更新了什么，升级失败怎么处理

钳叔 · 龙虾AI 编辑部 · 发布于 2026-10-07 · 更新于 2026-10-07

2026.9.8 在 10 月 3 日（UTC）发布，官方发布说明开头列的是：修掉 agent 之间丢回复的问题，降低同时跑很多个 Codex agent 时的内存占用，处理更新失败和 Windows 上的启动问题。

让一个 agent 去找另一个 agent 帮忙的、Windows 上打不开已存会话的、同一台机器挂着很多个 Codex agent 的，这版的修复直接用得上，可以升。Windows 上更新被文件占用卡过的也可以升，只是重试这项修复要到装上 9.8 之后的下一次更新才生效。从 9.7 升上来停在 activating 的，先看下面「停在 activating」一节，分清执行更新的是旧版更新器还是 9.8 的。

有两类安装多看一步再动：自己写过工作流、靠 REPLY_SKIP 或 ANNOUNCE_SKIP 压掉回复的，这两个标记在 9.8 里不再隐藏回复，升之前把返回结果怎么处理、要不要后续消息写进工作流；状态目录放在 FUSE 挂载上的（报告里是映射进 Docker 容器的 NAS 目录），#163179 的修复合并得比 9.8 晚，先留在现在装着的版本。还没升的，动手之前做一份备份，再跑一次 openclaw update --dry-run，确认目标版本是 2026.9.8；已经失败过一次的先别跑预演，原因见「停在 activating」一节。

OpenClaw 2026.9.8 更新了哪些内容

下表挑的是和日常使用关系最直接的条目，括号里是 PR 编号：

改动	发布说明的说法	和谁有关
agent 之间的回复	一个 agent 向另一个求助，结果只回给请求方一次；`REPLY_SKIP`、`ANNOUNCE_SKIP` 不再隐藏回复	配了多个 agent、让它们互相委派的
重载或唤醒之后发不出回复（#163504）	频道在重载或电脑唤醒后显示已连接，却发不出回复；这个问题是在 Matrix 上报告的	笔记本合盖再打开后频道没反应的
更新修复（#162959）	修复一次更新时，保留你允许并启用的插件；重新跑一遍 Doctor 可以完成挂起的升级确认，并清掉已完成事项的警告	上一次更新没走完的
Windows 更新（#163074）	Windows 短暂报告安装文件被占用时，更新器会重试；仍然换不掉，就把已安装的包留在原处	Windows 上的 Gateway
通过 npm 更新（#163481）	同一份安装有两条不同路径时也能处理，包括 npm 已删掉旧文件、新文件还没放好的那一刻	用 npm 安装的
启动	直接启动或在容器里启动时，阻止两份 OpenClaw 同时使用同一份已存数据；Windows 启动不再卡在路径过长的缓存目录上	直接启动或用容器跑、两份指向同一数据目录的；Windows 用户
Windows 上的已存会话（#162931）	修复了让 Windows 用户打不开已存会话、也准备不了定时 agent 任务的一个错误	Windows 用户
Codex 内存占用	跑很多个原生 Codex agent 时重复占用的内存变少：某个 agent 的会话列表要用到时才启动对应的后台进程，设置兼容时共用	一台机器挂多个 Codex agent 的
更新后的浏览器标签页（#163478）	更新期间一直开着自带网页界面的标签页，可以继续用旧文件加载视图；旧文件只临时保留，开得久的标签页仍可能要刷新一次	常开 Control UI 的

另外几条：Anthropic 的会话卡住，或者没等到后台命令、其他 agent、工作流的结果就结束，这类情况修了；改连接设置时，用户仍有访问权限的话，正在进行的工作可以做完，改登录方式仍然要重启；旧 Telegram 连接留下的文件，Doctor 确认是空的会挪进归档，非空或拿不准的留给你自己看；跑在 Bun 上时，格式特殊的超长日志里有密钥没被遮住，也修了。

截至 2026 年 10 月 7 日，npm 上三个标签的指向是：latest 为 2026.9.8，beta 为 2026.10.1-beta.1，extended-stable 为 2026.8.35。GitHub 发布页上 2026.10.1-beta.1 标着 Pre-release，日期是 10 月 5 日。在跑 Gateway 的机器上执行 openclaw update status，能看到当前版本和有没有可用更新。

9.8 的 GitHub 发布页在 Release verification 一节记着两条：Telegram 集成检查由发布负责人豁免、没有运行，安卓 APK 这一版跳过。频道主要靠 Telegram 的，升完在频道里发一条消息确认收发。

多个 agent 互相求助后回复变了，REPLY_SKIP 和 ANNOUNCE_SKIP 还能用吗

不能再拿它们压回复了。这一版 Messaging 一节有四点：

一个 agent 向另一个 agent 求助，结果回给请求方，只回一次。
在 OpenClaw 内部进行的工作必须返回结果，或者继续干下去，不允许悄悄结束。
自定义工作流要显式处理返回的结果，要后续消息的也得显式请求；REPLY_SKIP 和 ANNOUNCE_SKIP 不再隐藏回复。
Doctor 会更新旧设置，群聊里的静默保留。

「可以不说话」的范围，Web UI 小节（#163409）说得更直白：静默设置只适用于群聊，私聊和在 OpenClaw 内部发起的工作都要有回复。界面里 20 种已有语言的帮助文字也跟着改了，会说明 agent 在哪些地方可以保持沉默。

配置上对应的变化在 Doctor 配置迁移文档里：agents.defaults.silentReply.internal 和 surfaces.*.silentReply.internal 这两个键已经退役，Doctor 会把它们移除，因为只有外部频道的群组可以选择静默；silentReply.group 保留。配置里还带着退役键的，启动前先跑：

openclaw doctor --fix

这次修复走正常的配置备份和校验流程，更新过程中跑的 Doctor 也一样。

升完以后按自己的用法对一遍：

只在群里让 agent 少说话：旧设置由 Doctor 更新，群聊的静默保留。
在自己写的工作流里放了 REPLY_SKIP 或 ANNOUNCE_SKIP，指望被委派的 agent 干完不出声：升级后那条结果会回到请求方。怎么处理这条结果，得在工作流里显式写出来；需要后续消息的，也要显式请求。
以前委派出去的任务没有下文：这正是这版要修的，升完用一条委派任务试一次，看请求方有没有收到结果、是不是只收到一次。

多个 agent 怎么分工、怎么隔离，配置写法在《一台龙虾跑多个 agent：工作和私人分开怎么配》。

从 9.7 升 2026.9.8 停在 activating、报 managed-service-handoff-failed 怎么恢复

屏幕上的样子是：更新报告的标题为 Update failure: activating (2026.9.8)，原因码 managed-service-handoff-failed，失败的阶段列着 managed-service-update-handoff 和 activating，退出状态都是 unknown。这是 10 月 3 日开的 #164255 里的情况，报告环境是 macOS arm64、Node 26.8.1、npm 全局安装，更新是从 Control UI 发起的；报告的 OpenClaw version 一栏写着 2026.9.8，Before version 是 2026.9.7。

更新命令文档对这个原因码的解释是：托管更新里的子进程没有交回可用的结果。在停掉服务之前就被拒绝的更新，不会动到正在服务的 Gateway。

steipete 10 月 5 日在这条 issue 下回复，把情况分成两种。回复没有给分辨两种情况的命令，只说了报告人属于第二种。

第一种，执行更新的是旧版本自带的更新器。失败出在已装版本自带的那个更新器上，这一类问题后面的版本已经修了，旧更新器自己没法可靠地完成原地更新；Gateway 停在原来的版本，可以放心继续跑。往前走的办法是手动一步装到当前版本，再跑一遍 Doctor，让新版本迁移状态：

npm install -g openclaw@2026.9.8
openclaw doctor --fix
openclaw gateway restart

从 2026.9.8 起，后面的更新 openclaw update 自己能处理。

第二种，执行更新的已经是 2026.9.8。这一类交接失败在 main 分支上由 #164849 和 #164997 修掉，随 2026.9.9 发出；到那一版上执行 openclaw update repair，把挂起的恢复收掉。Gateway 眼下没在服务的，openclaw gateway restart 现在就能把它拉起来。issue 在 10 月 5 日按已完成关闭，npm 的 latest 还是 2026.9.8（三个标签的指向见上一节）。

撞上以后的顺序，我建议这样排：

先别重复执行更新。再跑一次更新或预演会盖掉最近一次的记录，先执行 openclaw update status --json，把 lastRun.origin.nextAction 和 lastRun.target 两个字段记下来。
Gateway 没在服务的，先执行 openclaw gateway restart。
属于第一种的：做一份备份，再执行上面三条命令。备份和回退的做法见《OpenClaw 升级、回滚与彻底卸载》。回复请报告人在手动安装或 Doctor 这一步失败时，把输出贴到 issue 里。
属于第二种的：等 2026.9.9 发布，装上以后执行 openclaw update repair。
分不清属于哪一种的：做完前两步先停下，拿 status 的输出对照 #164255 报告里的版本字段（上文已列）再决定。

其他原因码（doctor-failed、runtime-verification-failed 等）的处理办法在《OpenClaw 更新失败按 doctor-failed 等报错逐个处理》。

Windows 上更新 OpenClaw 报 EBUSY、EPERM，安装文件被占用

从旧版本往 9.8 升的那一次，9.8 加的文件占用重试还用不上：发布说明写的是，旧更新器没法在更新进行到一半时获得这项修复。这一次失败了，按更新命令文档处理，那里对 EACCES 和 EPERM 给的做法是：用 npm prefix -g 查出全局安装目录，换成当初安装的那个账户、在对这个目录有写权限的情况下执行更新。报的是文件被占用，建议先关掉占着安装目录的进程再重试。

装上 9.8 以后，再遇到这种情况更新器会自己重试。Windows 上正在使用的包被临时锁住时，更新器没法把它改名挪到备份位置；它会对 EPERM、EBUSY、EACCES 这三种错误做有上限的退避重试，一共 16 次，最多等 57.75 秒，每次重试记一条警告。重试完仍然改不了名，报错里会给出两个路径，已安装的包留在原处。

Windows 上 2026.9.4 需要恢复的：先备份，再按发布说明链到的更新命令文档里的恢复说明操作，使用原来的服务账户和安装设置。

这一版和 Windows 有关的另外两处：

启动时不再因为某个缓存目录的路径太长而卡住。
打不开已存会话、准备不了定时 agent 任务的那个错误修了（#162931）。

通过托管的 llama.cpp 跑本地模型的：缺少微软的依赖文件时，安装流程可以把它们补到本地模型服务旁边（#163093、#163128）；启动仍然失败，就重跑一遍 setup，或者手动配一个兼容的服务。

状态目录在 FUSE 挂载上，OpenClaw 更新报 doctor-failed、SQLite database cannot be snapshotted safely

10 月 2 日开的 #163179，环境是 Debian 12 的 Docker 容器，OPENCLAW_STATE_DIR 放在一个 FUSE 挂载上（映射进容器的 NAS 目录），从 2026.9.5 升 2026.9.7。停掉 Gateway、确认没有残留进程之后执行 openclaw update --yes --timeout 1800，更新在激活阶段的 Doctor 一步失败，原因码 doctor-failed，报错里有 SQLite database cannot be snapshotted safely 和 SQLite snapshot file changed while reading 两句。失败之后包回滚正常执行，装着的还是之前的版本。

steipete 在 10 月 3 日的回复里给了原因：更新器发布状态快照以后，会要求源文件的创建时间、ctime、mtime、大小、设备号和 inode 全部没变，而 FUSE 文件系统在内容没变的情况下也会报出 ctime、mtime 漂移，一份好的快照就这样被拒掉。修复是 #164123：时间戳漂移时重新计算哈希，内容一致就放行；inode、设备号或大小变了，或者完整性校验不过，仍然拒绝。修复随下一个版本发出。

#164123 合并于 10 月 3 日 07:46（UTC），2026.9.8 是同一天 03:21（UTC）发布的，这个修复不在 2026.9.8 里。状态目录放在 FUSE 挂载上的，先不升，留在现在装着的版本；等发布说明里出现 #164123，再看那一版对从旧版本升上来的安装怎么说。

Git 源码安装的 OpenClaw 更新到 2026.9.8 之后，70 多天前的旧会话被自动续上

这一条来自 #166300，10 月 6 日提交，报告写的是从 2026.9.7 更新到 2026.9.8 之后出的事。环境是 macOS 27.0 arm64 上的托管 Git 源码安装（原文为 Managed Git-source installation），Gateway 由 LaunchAgent 守护。现象是启动恢复自动续上了一个最后一轮人工消息和最终回复都在 70 多天前的会话：agent 又读了一次外部服务，在没有新用户输入的情况下往旧的 Telegram 话题里发了一条新回复。

报告人点名的触发改动是 PR #165733，合并于 10 月 6 日 17:54（UTC），比 npm 上 2026.9.8 的发布晚三天；报告里的构建标着 2026.9.8，后面跟的提交号就是这个 PR 的合并提交。截至 10 月 7 日 issue 仍未关闭，原因和影响范围还没有人回复确认。这份报告出在跟着 main 分支更新的源码安装上。用源码安装并且接了 Telegram 这类外部频道的，更新到 10 月 6 日之后的 main 之前，先到这个 issue 看有没有修复合并。

常见问题

OpenClaw 2026.9.8 是哪天发布的，现在用 npm 装到的是哪一版？: GitHub 发布页上 v2026.9.8 的发布时间是 2026 年 10 月 3 日 03:21（UTC），标着 Latest。截至 2026 年 10 月 7 日，npm 的 latest 标签指向 2026.9.8，beta 指向 2026.10.1-beta.1，extended-stable 指向 2026.8.35。不指定标签安装时，装到的是 latest 对应的 2026.9.8。
想用 GPT-6.1 Sol，升到 OpenClaw 2026.9.8 就可以了吗？: 还不完整。GPT-6.1 Sol 的支持在 9.8 里没有做完，相关改动（#161400、#163132）只是为它做准备。要用这个模型，等后续版本的发布说明里出现支持完成的说法再升。
两个 OpenClaw 实例指向同一个数据目录，升到 2026.9.8 以后会怎样？: 直接启动或在容器里启动时，9.8 会阻止两份 OpenClaw 同时使用同一份已存数据。需要同时跑两份的，给它们各配一个数据目录。