- 发布性能扫描： 从
v2026.5.28回溯到稳定版v2026.4.23的 GitHub Releases，使用OpenClaw Performance工作流、profile=smoke、mock-provider 线路。大多数标签行只有一个样本；v2026.5.27和v2026.5.28行使用最新的重复 3 次发布分支产物。 - 更早的 4 月上下文： 已发布的
clawgrit-reportsmock-provider 基线，范围从v2026.4.1到v2026.5.2，仅用于避免把 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。
稳定代理回合
冷启动快 5.1 倍
v2026.4.14：9.8sv2026.5.28：1.9s
已发布包
17.9MB tarball最新稳定包，低于 3 月份 43.3MB 的包大小峰值。
最新稳定安装
361.7MiB 全新安装将嵌套的 OpenClaw 依赖树从
2026.5.22
shrinkwrap-introduction 峰值显著压缩，不过在本地安装审计中仍
保留着一个更小的 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
mock-provider 运行的 v2026.4.14（重复 3 次；那次运行仅因未输出诊断
时间线而失败，因此冷启动、热启动和 RSS 中位数仍可
作为粗略尺度使用）。请将其视为叙述背景，而非发布门禁
统计。
在 5 月的扫描范围内，最新的发布分支行相较于
v2026.5.2 有了显著变化：
与上一稳定版相比：
安装占用
npm 包大小
2026.5.12 是变更日志中可见的插件拆分里程碑：Amazon Bedrock、Bedrock Mantle、Slack、OpenShell sandbox、Anthropic Vertex、Matrix 和 WhatsApp 从核心依赖路径中移出，因此它们的依赖锥体会随这些插件一起安装，而不是每次核心安装都一并安装。
Kova 代理回合摘要
4 月的稳定线包含两个不同的故事。4 月上旬虽慢，但仍可识别。4 月下旬则变成了回归悬崖。v2026.5.2 是 mock-provider 线路首次跌入 3-5 秒区间，并在给定扫描中开始稳定通过的位置。
更早的已发布上下文：
给定扫描：
源探针
由于这些源代码树当时还没有所需的探针入口点，17 个成功的旧 ref 的源探针被跳过了。这些 ref 仍然存在 agent-turn 指标。 代表性的源探针数据点：
尽管 agent-turn 这条线仍然通过了，表格中仍然可以看到
v2026.5.22 的 CLI health 峰值。排查有针对性的 CLI 或网关回归时，请保留源探针。
安装体积审计
依赖样本使用每月一个稳定版，再加上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，但在本地 fresh-install 审计中不再安装任何 @napi-rs/canvas 包。
已发布 tarball 的检查验证了这个边界：
关键区别在于：问题并不在 shrinkwrap 本身。
v2026.5.28 仍然包含根 shrinkwrap。问题在于包的形态导致 npm 物化出一个很大的嵌套 OpenClaw 依赖树，以及全部 12 个 @napi-rs/canvas 平台包。v2026.5.28 中嵌套树更小了，而且 canvas 平台分发也 აღარ在本地审计中落地。
有关当前依赖审查和包策略，请参见
dependency locking。
供应链解读
依赖数量不仅是安装体积指标，也是运维安全指标。每个包都会扩大维护者、tarball、传递性更新、可选原生二进制文件以及安装时行为的信任面，运维人员必须信任这些内容。 清理方向是：- 将沉重且可选的能力放在默认核心安装之外
- 让插件包负责其运行时依赖图
- 避免在 Gateway 启动期间进行运行时包管理器修复
- 在不导致所有平台原生包物化的前提下保持确定性安装
- 在包接受和度量路径中保持禁用安装脚本
- 在发布前捕获嵌套依赖树和原生可选依赖爆炸