- **发布性能扫描：**使用
OpenClaw Performance工作流的profile=smoke模拟提供商通道，对从v2026.5.28向前追溯至稳定版v2026.4.23的 GitHub Releases 进行扫描。大多数标签行采用单次样本；v2026.5.27和v2026.5.28行采用最新的重复 3 次发布分支工件。 - **4 月早期背景：**从
v2026.4.1到v2026.5.2已发布的clawgrit-reports模拟提供商基线，仅用于避免将 4 月下旬存在问题的版本视为公开性能基线。 - **安装占用空间扫描：**在临时包中全新安装
npm install --ignore-scripts，使用du -sk node_modules测量大小，并通过node_modules遍历统计包实例数量。 - **npm 包大小扫描：**对已发布版本执行
npm pack openclaw@<version> --dry-run --json，记录压缩 tarball 大小、解包后大小和文件数量。
快照
性能覆盖范围：请求了 77 个版本、74 个有工件支持的数据点，以及 3 次不可用的 CI 运行。测得的最新稳定版数据点：v2026.5.28。
稳定版 Agent 轮次
冷启动轮次快 5.1 倍
v2026.4.14：9.8sv2026.5.28：1.9s
已发布包
17.9MB tarball最新稳定版包，低于 3 月 43.3MB 的包大小峰值。
最新稳定版安装
全新安装占用 361.7MiB与
2026.5.22 引入 shrinkwrap 时的峰值相比，嵌套 OpenClaw 依赖树显著缩小，但本地安装审计中仍有一棵较小的 259.7MiB 嵌套树。依赖关系图
安装了 300 个包在禁用脚本的全新安装中，以唯一的包名/版本根节点计量；比前一个稳定版少 71 个根节点。
5.28 中的变更
v2026.5.27 与 v2026.5.28 之间的清理缩减了默认安装依赖图，而非移除这些能力本身。
根级默认依赖图
唯一的包名/版本根节点从 371 降至 300。包实例从 372 降至 301。
嵌套树
在同一次本地安装审计中，嵌套
openclaw/node_modules 从 656.1MiB 降至 259.7MiB。原生可选依赖锥
全平台
@napi-rs/canvas 原生包依赖锥不再包含在默认安装中。供应链暴露面
默认包更少，意味着默认需要信任的 tarball、维护者、原生二进制文件、安装时行为和传递更新路径也更少。
核心数据
不要将 4 月下旬存在问题的行用作公开性能基线。v2026.4.23 和 v2026.4.29 是有用的回归证据，但 14x 式的大幅差异主要体现了从不良发布分支恢复后的变化。
博客叙事应使用 4 月早期已发布的基线来体现量级。该基线是已发布 clawgrit-reports 模拟提供商运行中的 v2026.4.14（重复 3 次；该运行失败的唯一原因是未生成诊断时间线，因此冷启动、热启动和 RSS 中位数仍可用于粗略体现量级）。应将其视为叙事背景，而不是发布门禁统计数据。
在 5 月扫描中，最新的发布分支行相较于
v2026.5.2 有了显著变化：
与前一个稳定版相比：
安装占用空间
npm 包大小
2026.5.12 是变更日志中显著的插件提取里程碑：Amazon Bedrock、Bedrock Mantle、Slack、OpenShell 沙箱、Anthropic Vertex、Matrix 和 WhatsApp 已移出核心依赖路径，因此它们的依赖锥会随相应插件安装，而不是随每次核心安装一并安装。
Kova Agent 轮次摘要
4 月稳定版分支包含两个截然不同的阶段。4 月早期速度较慢，但仍属正常范围。4 月下旬则出现了断崖式回归。从v2026.5.2 开始，模拟提供商通道首次降至 3-5s 范围，并开始在所提供的扫描中持续通过。
早期已发布背景：
所提供的扫描：
源码探针
17 个成功的较早引用跳过了源码探针，因为当时这些源码树尚未包含所需的探针入口点。这些引用仍有 Agent 轮次指标。 具有代表性的源码探针数据点：
尽管 Agent 轮次通道仍然通过，但此表中仍可看到
v2026.5.22 的 CLI 健康指标激增。排查特定 CLI 或 Gateway 网关回归时，请保留源码探针。
安装占用空间审计
依赖项样本每月选用一个稳定版本，另包括2026.5.22 shrinkwrap 引入事件和最新的 2026.5.28 版本。
Shrinkwrap 分界点
2026.5.20 发布时没有根 shrinkwrap，也没有庞大的嵌套 OpenClaw
依赖项树。2026.5.22 引入了根 shrinkwrap，并在嵌套的
openclaw/node_modules 下安装了 911.8MB。2026.5.28 保留了 shrinkwrap，并且仍在
嵌套的 openclaw/node_modules 下安装 259.7MiB，但在本地全新安装审计中不再安装
任何 @napi-rs/canvas 软件包。
对已发布 tarball 的检查验证了这一分界点：
需要特别区分的是：shrinkwrap 本身并不是问题。
v2026.5.28 仍然附带根 shrinkwrap。问题出在软件包结构上，
它导致 npm 实体化庞大的嵌套 OpenClaw 依赖项树以及全部 12 个
@napi-rs/canvas 平台软件包。v2026.5.28 中的嵌套树更小，
并且 Canvas 平台扇出不再出现在本地审计中。
有关 shrinkwrap 的通俗说明和维护者级别的软件包
检查，请参阅 npm shrinkwrap。
供应链解读
依赖项数量是一项运维安全指标，而不仅仅是安装大小 指标。每个软件包都会扩大操作员必须信任的维护者、tarball、传递性 更新、可选原生二进制文件和安装时行为的范围。 清理方向如下：- 将重量级和可选能力排除在默认核心安装之外
- 让插件软件包拥有自己的运行时依赖关系图
- 避免在 Gateway 网关启动期间进行运行时软件包管理器修复
- 在不导致所有平台原生软件包 实体化的情况下保持确定性安装
- 在软件包验收和测量路径中保持禁用安装脚本
- 在发布前发现嵌套依赖项树和原生可选依赖项 爆炸式增长