数据采集时间：2026-10-19 06:00（Asia/Shanghai）。本文全部数据来自 npm registry 官方元数据接口 GET https://registry.npmjs.org/openclaw（本次响应体 20,006,079 字节，versions 字段 279 条，time.modified = 2026-10-18T21:16:43.895Z）以及 GitHub 官方 Releases API GET /repos/openclaw/openclaw/releases（分页取全 266 条 Release，入口见 openclaw 官方 Releases 页面）与仓库 Tags 页面。凡本文无法从公开接口直接证实的事项，一律标注 UNKNOWN，不做推测性补全。
如果你写过 npm install -g openclaw，有一个现象你多半遇到过：想回退到某个”上一个稳定版本”，翻遍 npm 页面也找不到你以为存在的版本号。
以 7 月线为例。这条线上 npm 上真实存在的稳定版本只有四个：2026.7.1、2026.7.33、2026.7.34、2026.7.35。中间的 .2 到 .32——整整 31 个版本号——在 registry 里从来就不存在。
这不是数据丢失，也不是你记错了。这是 OpenClaw 官方 LTS 线（官方称 extended-stable）的一种刻意设计，但官方文档里从来没有解释过它。下面我们把 npm registry 和 GitHub Releases 两边的数据对齐，还原这套编号规则，以及它给使用者造成的三个真实后果。
一、先看全貌：279 个版本里，稳定版只占 35.5%
先把基数摆清楚。我们解析了 registry 的完整 versions 字段：
| 维度 | 数值 | 口径 |
|---|---|---|
| 发布版本总数 | 279 | registry versions 字段全量 |
| 稳定版本（stable） | 99 | 不含 beta / alpha / rc / next 后缀 |
| 预发布版本（prerelease） | 180 | 其余全部 |
| 预发布占比 | 64.5% | 180 / 279 |
| 首个版本 | 0.0.1 | 2026-01-29T11:08:12.101Z |
| 废弃（deprecated）版本 | 1 | 2026.5.19-alpha.1 |
| 当前 dist-tags | 3 | latest / extended-stable / beta |
预发布版本是稳定版的 1.82 倍（180 : 99）。这个比例本身就说明一件事：这个项目的发布管道主要由预发布驱动，稳定版是从预发布线里”晋升”出来的，而不是独立开发的另一条线。
理解这一点，是理解后面版本号跳空的前提。
二、核心发现：每条 LTS 线的版本号都从个位数跳到 33
我们对全部 99 个稳定版本做了逐条解析，发现一个规律极其整齐。以 2026.9.x 线为例，npm 上真实存在的稳定版本只有十个：.1、.2、.3、.4、.5、.6、.7、.8、.9，然后直接跳到 .33。
同样的模式在所有 LTS 线上重复出现：
| 月份线 | 最后一个常规号 | 首个 extended-stable 号 | 中间留空的版本号数 |
|---|---|---|---|
| 2026.6 | .11 | .33 | 21 个 |
| 2026.7 | .1 | .33 | 31 个 |
| 2026.8 | .2 | .33 | 30 个 |
| 2026.9 | .9 | .33 | 23 个 |
四条线的跳空终点全部是 33。这不是巧合——这是官方给 LTS 线预留的编号段。
注意 2026.1 和 2026.3 这两条线也有高补丁号版本（.30 和 .31），但它们并不属于 extended-stable 线，下文会单独说明。
三、这批高编号版本到底是什么：官方原文这么说
我们拉取了 GitHub 官方 Releases API 的全部 266 条 Release，逐条检查正文。其中恰好 8 条正文里出现了 extended-stable 这个词，且这 8 条的版本号正是：2026.6.33、2026.6.34、2026.6.35、2026.7.35、2026.8.33、2026.8.34、2026.8.35、2026.9.33。
最新一条 v2026.9.33 的 Release 正文第一句原文是：
This is a gateway-only
extended-stablerelease, which is our current equivalent to LTS.
“gateway-only”和”our current equivalent to LTS”这两个措辞很关键：官方自己承认这就是 LTS，只是改了名字。而 npm 上的 dist-tags 也确实有一个 extended-stable 标签，当前指向 2026.9.33。
于是我们有了明确的对应关系：.33 起的编号段 = extended-stable 线 = 官方当前的 LTS 等价线。
四、三个真实后果
后果一：npm install openclaw@7.2 这类命令会直接失败
因为 2026.7.2 从未发布过，npm 会返回 ETARGET 错误。真正的问题在于，这批跳空号看起来太像真实存在的版本号。一个正常的补丁版本号会让人本能地相信”我记错了，但应该存在”。而实际上 7.2 到 7.32 这 31 个版本号是永久空缺的，不会随时间被补上——因为 LTS 线的预留段从 .33 起跳。
如果你在某个教程、issue 回复或旧脚本里看到 openclaw@2026.8.10，那这个版本号在这个包里从来不存在过。
后果二：两个版本存在但从未被官方 Release 记录
这是本次核查里最值得注意的发现。
我们把 npm registry 与 GitHub Releases 逐条比对，发现 2026.7.33 和 2026.7.34 这两个版本在 npm 上真实存在并可安装，但 GitHub 上没有对应的 Release 页面。
它们的元数据如下：
| 版本 | npm 发布时间 (UTC) | GitHub Release | Release 正文含 extended-stable |
|---|---|---|---|
| 2026.7.33 | 2026-09-18T05:10:01Z | 无 | — |
| 2026.7.34 | 2026-09-20T02:52:05Z | 无 | — |
| 2026.7.35 | 2026-09-21T12:16:02Z | 有 | 是 |
三个版本的体积几乎完全一致（83.8 MB，文件数 8618 / 8618 / 8617），依赖数相同（56），engines.node 也相同。从产物看，它们属于同一个系列。
也就是说，7 月这条 LTS 线的第一版（.33）和第二版（.34）被推到了 npm 上，却没有留下任何官方 Release 公告。只有第三版 .35 才有完整的 Release 页面和 extended-stable 说明。
我们进一步确认了这两个版本对应的 git tag 在仓库里是存在的（refs/tags/v2026.7.33 指向 3184a84ddf0a，refs/tags/v2026.7.34 指向 0847c47f4451），所以不是从未构建，只是发布公告这一环缺失。
为什么缺失、是有意为之还是流程遗漏，官方没有任何说明，标记为 UNKNOWN。
对使用者的影响很直接：如果你按 Release 页面来了解 LTS 线更新了什么，你看到的只有 .35 开始的记录，.33 和 .34 这两版发生了什么，只能从包体积和文件数的细微差异去猜——注意 .35 的文件数比 .33/.34 少了 1 个。
后果三：npm 上线时间与官方公告时间存在最大 17.8 天的落差
我们把 extended-stable 线 8 个版本的 npm 发布时间与 GitHub Release 发布时间做了逐条对齐：
| 版本 | npm 发布时间 (UTC) | GitHub Release (UTC) | 落差 |
|---|---|---|---|
| 2026.6.33 | 2026-07-21 11:25 | 2026-08-08 07:16 | +17.8 天 |
| 2026.6.34 | 2026-08-04 21:14 | 2026-08-08 07:22 | +3.4 天 |
| 2026.6.35 | 2026-09-10 04:51 | 2026-09-10 06:39 | +1.8 小时 |
| 2026.7.35 | 2026-09-21 12:16 | 2026-09-21 13:14 | +1.0 小时 |
| 2026.8.33 | 2026-09-28 22:37 | 2026-09-29 03:12 | +4.6 小时 |
| 2026.8.34 | 2026-10-01 20:28 | 2026-10-02 00:12 | +3.7 小时 |
| 2026.8.35 | 2026-10-02 13:20 | 2026-10-02 14:06 | +0.8 小时 |
| 2026.9.33 | 2026-10-15 10:05 | 2026-10-15 10:39 | +0.6 小时 |
规律很清楚：越近的版本，落差越小。从最初的 17.8 天收敛到最近的 35 分钟。
如果只看 6.33 这一条，会得出”官方 LTS 公告滞后近三周”的结论；但把 8 条数据放在一起看，更合理的解释是 LTS 线的公告流程在 6 月底到 9 月之间被逐步理顺了。这是一个观察到的趋势，不是官方确认的说法。
五、那么 1.30 和 3.31 是什么？
一个自然的疑问是：既然 .33 是 LTS 线的起点，为什么 2026.1.30 和 2026.3.31 也存在高编号版本？
我们逐条检查了这两条的 Release 正文，均不含 extended-stable 字样。2026.1.30（2026-01-31 发布）的正文开头是常规的 “### Changes” 清单，2026.3.31（2026-03-31 发布）的正文开头是常规的 “### Breaking” 清单。
时间上，2026.6.33 是第一条 extended-stable 发布（npm 上 2026-07-21），而 1.30 和 3.31 都早于它。所以高编号 ≠ extended-stable 在 OpenClaw 这里并不成立于全部历史版本。
我们推测（标记为推测，非官方说明）：.33 这一预留段的做法是从 2026 年 6 月才开始启用的 LTS 编号约定，1.30 和 3.31 属于该约定之前的常规补丁号递增，没有预留段概念。
六、给使用者的实用建议
基于以上核查，如果你要长期部署 OpenClaw，以下几点是直接可用的：
- 不要把版本号当成连续序列去猜。 需要某个具体版本时，先用
npm view openclaw versions --json拉全量列表确认存在，再执行安装。 - 锁版本时用 extended-stable 标签而不是手写号。
npm install -g openclaw@extended-stable会指向当前 2026.9.33，这是官方当前明示的 LTS 等价线。npm 官方文档也说明，dist-tag 是一个可移动的版本引用，适合用作安装时指向版本的依据。 - 查 LTS 线更新内容时，npm 页面比 GitHub Release 更全。 因为 2026.7.33 / 7.34 这两版根本没有 Release 公告，只在 npm 上留有记录。
- 2026.1.30 / 2026.3.31 不是 LTS。 别因为编号高就把它们当成稳定线。
七、结论
OpenClaw 的 LTS 线改名叫 extended-stable 之后，采用了一套从 33 起跳的预留编号段：每条 LTS 线的常规补丁号停在个位数，然后直接跳到 .33 / .34 / .35。8 个 extended-stable 版本全部落在这个区间，且它们的 GitHub Release 正文都明确写着”our current equivalent to LTS”。
这套规则带来三个实测后果：31 个版本号的永久空缺会让 npm install openclaw@7.2 这类命令直接报错；2026.7.33 与 2026.7.34 在 npm 上真实存在却从未留下官方 Release 公告；npm 上线与官方公告之间的时间落差从最初的 17.8 天收敛到最近的 35 分钟。
需要说明的是，官方从未在任何公开文档中解释过这套编号规则。以上结论全部由 npm registry 与 GitHub Releases 的公开接口逐字段核对得出；.33 预留段的具体设计意图、7.33/7.34 缺失 Release 公告的原因，官方均未说明，本文不做推测性补全。
数据来源与复核方式
- npm registry 元数据：npm 官方 registry 接口
GET https://registry.npmjs.org/openclaw，采集于 2026-10-19 06:00（Asia/Shanghai），响应体 20,006,079 字节，versions字段 279 条。可在 npmjs.com/package/openclaw 对照版本列表 - GitHub Releases：openclaw 官方 Releases 页面，经 API 分页取全 266 条；逐条检索正文中的
extended-stable关键字，命中 8 条 - GitHub Tags：仓库 Tags 页面，用于核对 v2026.7.33 / v2026.7.34 两个 tag 的存在性
- npm dist-tag 定义：npm 官方文档 npm-dist-tag
所有版本号、发布时间、体积、文件数、依赖数均可按上述接口逐条复核。
