跳轉到主要內容
此頁面記錄 2026 年 5 月 OpenClaw 效能、套件大小、相依項與 shrinkwrap 清理背後的證據。它是公開部落格文章的技術配套資料。 這裡合併了兩項稽核:
  • 發布效能掃描:v2026.5.28 回溯到 stable v2026.4.23 的 GitHub Releases,使用 OpenClaw Performance 工作流程、 profile=smoke、模擬提供者通道。大多數標籤列是一個樣本; v2026.5.27v2026.5.28 列使用最新的 repeat-3 發布分支 成品。
  • 較早的四月脈絡: 已發布的 clawgrit-reports 模擬提供者 基準線,涵蓋 v2026.4.1v2026.5.2,僅用於避免將 四月下旬壞掉的發布版視為公開效能基準線。
  • 安裝足跡掃描: 以全新的 npm install --ignore-scripts 安裝 到臨時套件中,使用 du -sk node_modules 取得大小,並走訪 node_modules 取得套件實例數。
  • npm 套件大小掃描: 對已發布版本執行 npm pack openclaw@<version> --dry-run --json, 記錄壓縮 tarball 大小、解壓後大小與檔案數。
主要效能掃描對每個標籤使用一個煙霧測試樣本,但 v2026.5.27v2026.5.28 列使用最新的 repeat-3 發布分支成品。較早的四月脈絡使用來自 clawgrit-reports 的已發布 repeat-3 中位數。請將這些數字視為趨勢證據與 回歸追查訊號,而不是發布門檻統計資料。

快照

效能涵蓋範圍:77 個請求的發布版74 個有成品支撐的資料點, 以及 3 個無法取得的 CI 執行。最新測得的 stable 點:v2026.5.28

穩定版代理回合

冷啟回合快 5.1 倍
  • v2026.4.14: 9.8s
  • v2026.5.28: 1.9s

已發布套件

17.9MB tarball最新 stable 套件,低於三月 43.3MB 的套件大小高峰。

最新 stable 安裝

361.7MiB 全新安裝v2026.5.28 大幅削減巢狀 OpenClaw 相依樹,但本機安裝稽核中 仍保留較小的 259.7MiB 巢狀樹。

相依圖

300 個已安裝套件最新 stable 發布版,在停用腳本的全新安裝中,以唯一套件名稱/版本根計量。

安裝足跡時間線

每月高點

645 個相依項2026.2.26 是此樣本中的每月相依項數量高點。

導入 shrinkwrap

1,020.6MB 安裝2026.5.22 新增根 shrinkwrap,並暴露套件形狀問題: 911.8MB 落在巢狀 openclaw/node_modules 底下。

最新 stable

361.7MiB 安裝2026.5.28 相較 2026.5.27 將全新安裝大小削減 52.8%,但仍 安裝 259.7MiB 的巢狀 OpenClaw 樹。

相依圖

300 個套件根2026.5.28 安裝的唯一套件名稱/版本根比 2026.5.27 少 71 個。
shrinkwrap 本身並不是問題。糟糕的套件形狀才是。 v2026.5.28 仍隨附 shrinkwrap,但巢狀相依樹小得多, 且本機稽核中已不再有全平台 canvas 扇出。

5.28 有哪些變更

v2026.5.27v2026.5.28 之間的清理縮減了預設安裝圖,而不是移除功能本身。

Root default graph

唯一套件名稱/版本根節點從 371 降至 300。套件執行個體從 372 降至 301

Nested tree

在同一次本機安裝稽核中,巢狀 openclaw/node_modules656.1MiB 降至 259.7MiB

Native optional cones

全平台 @napi-rs/canvas 原生套件錐不再進入預設安裝。

Supply-chain surface

預設套件較少,代表預設需要信任的 tarball、維護者、原生二進位檔、安裝期間行為,以及傳遞更新路徑都更少。

主要數字

不要把四月下旬損壞的列當作公開效能基準。v2026.4.23v2026.4.29 是有用的迴歸證據,但大型 14x 風格的差異主要描述的是從不良發布線恢復的情況。 部落格敘事請使用四月較早發布的基準作為尺度:
指標四月較早基準v2026.5.28差異
冷代理回合9,819ms1,908ms降低 80.6%,快 5.1 倍
暖代理回合7,458ms1,870ms降低 74.9%,快 4.0 倍
代理峰值 RSS686.2MB581.0MB降低 15.3%
四月較早的基準是已發布 clawgrit-reports mock-provider 執行中的 v2026.4.14。該次執行使用 repeat 3,且僅因未發出診斷時間軸而失敗;冷、暖與 RSS 中位數仍可作為粗略尺度。請將其視為敘事背景,而不是發布門檻統計。 在五月掃描中,最新發布分支列相較 v2026.5.2 有實質進展:
指標v2026.5.2v2026.5.28差異
冷代理回合3,897ms1,908ms降低 51.0%
暖代理回合3,610ms1,870ms降低 48.2%
代理峰值 RSS613.7MB581.0MB降低 5.3%
相較前一個穩定版本:
指標v2026.5.27v2026.5.28差異
冷代理回合2,231ms1,908ms降低 14.5%
暖代理回合2,226ms1,870ms降低 16.0%
代理峰值 RSS649.0MB581.0MB降低 10.5%

安裝占用空間

指標基準v2026.5.28差異
2026.5.22 峰值起算的安裝大小1,020.6MB361.7MiB降低 64.6%
從最新發布 2026.5.27 起算的安裝大小767.1MiB361.7MiB降低 52.8%
從月內高點 2026.2.26 起算的相依項645300降低 53.5%
從最新發布 2026.5.27 起算的相依項371300降低 19.1%
2026.5.22 起算的巢狀 openclaw/node_modules911.8MB259.7MiB降低 71.5%
2026.5.27 起算的巢狀 openclaw/node_modules656.1MiB259.7MiB降低 60.4%

npm 套件大小

版本壓縮 tarball解開後套件檔案備註
2026.1.3012.8MB33.5MB4,607早期重新品牌化套件
2026.2.2623.6MB82.9MB10,125功能成長
2026.3.3143.3MB182.6MB21,037套件大小高點
2026.4.2922.9MB74.6MB9,309套件修剪已可見
2026.5.1223.4MB80.1MB12,035主要外部外掛拆分
2026.5.2217.2MB76.9MB12,386文件/資產已從套件排除
2026.5.2717.8MB79.0MB12,509前一個穩定套件
2026.5.2817.9MB81.0MB9,082最新穩定套件
2026.5.12 是變更記錄中可見的外掛抽離里程碑:Amazon Bedrock、Bedrock Mantle、Slack、OpenShell 沙箱、Anthropic Vertex、Matrix 和 WhatsApp 移出核心相依路徑,因此它們的相依錐會隨這些外掛安裝,而不是隨每個核心安裝一起安裝。

Kova 代理回合摘要

四月穩定線包含兩個不同故事。四月較早版本雖然慢,但仍可辨識。四月下旬則變成迴歸斷崖。v2026.5.2 是 mock-provider 路徑首次降到 3-5 秒範圍,並在提供的掃描中開始穩定通過的位置。 較早發布的背景:
發布Kova冷回合暖回合代理峰值 RSS
v2026.4.10失敗11,031ms7,962ms679.0MB
v2026.4.12失敗11,965ms8,289ms713.5MB
v2026.4.14失敗9,819ms7,458ms686.2MB
v2026.4.20失敗22,314ms18,811ms810.8MB
v2026.4.22失敗9,630ms7,459ms743.0MB
提供的掃描:
發布Kova冷回合暖回合代理峰值 RSS
v2026.4.23失敗47,847ms8,010ms1,082.7MB
v2026.4.24失敗48,264ms25,483ms996.0MB
v2026.4.25失敗81,080ms59,172ms1,113.9MB
v2026.4.26失敗76,771ms54,941ms1,140.8MB
v2026.4.27失敗60,902ms33,699ms1,156.0MB
v2026.4.29失敗94,031ms57,334ms3,613.7MB
v2026.5.2通過3,897ms3,610ms613.7MB
v2026.5.7通過3,923ms3,693ms654.1MB
v2026.5.12通過7,248ms6,629ms834.8MB
v2026.5.18通過3,301ms2,913ms630.3MB
v2026.5.20通過3,413ms2,952ms643.2MB
v2026.5.22通過4,494ms4,093ms654.3MB
v2026.5.26通過2,626ms2,282ms660.4MB
v2026.5.27-beta.1通過2,575ms2,217ms635.3MB
v2026.5.27通過2,231ms2,226ms649.0MB
v2026.5.28通過1,908ms1,870ms581.0MB

原始碼探測

17 個成功的較舊 ref 略過了原始碼探測,因為那些原始碼樹當時尚未具備所需的探測進入點。這些 ref 仍有代理回合指標。 代表性的原始碼探測點:
發布預設 readyz p5050 個外掛 readyz p50命令列介面健康 p50外掛最大 RSS
v2026.4.292,819ms2,618ms1,679ms389.0MB
v2026.5.22,324ms2,013ms1,384ms377.2MB
v2026.5.71,649ms1,540ms1,175ms387.6MB
v2026.5.181,942ms1,927ms607ms426.5MB
v2026.5.201,966ms1,987ms621ms455.0MB
v2026.5.222,081ms1,884ms5,095ms444.2MB
v2026.5.261,546ms1,634ms656ms400.4MB
v2026.5.27-beta.11,462ms1,548ms548ms394.0MB
v2026.5.271,491ms1,571ms553ms401.5MB
v2026.5.281,457ms1,474ms623ms386.1MB
即使 agent-turn 通道仍然通過,這張表仍可看出 v2026.5.22 命令列介面的健康狀態突增。調查特定命令列介面或閘道迴歸時,請保留來源探針。

安裝佔用稽核

相依性樣本每月使用一個穩定版本,外加 2026.5.22 shrinkwrap 引入事件,以及最新的 2026.5.28 版本。
PointInstalled depsFresh installOpenClaw packageNested openclaw/node_modulesRoot shrinkwrapCanvas install behavior
1 月 2026.1.30605438.4MB45.8MB2.4MB頂層 wrapper + darwin-arm64
2 月 2026.2.26645575.7MB110.1MB3.5MB頂層 wrapper + darwin-arm64
3 月 2026.3.31438584.1MB234.8MB0MB頂層 wrapper + darwin-arm64
4 月 2026.4.29392335.0MB97.4MB0MB未安裝任何項目
2026.5.224011,020.6MB1,020.4MB911.8MB巢狀:全部 12 個 @napi-rs/canvas 套件
5 月 2026.5.26371767.5MB767.4MB656.4MB巢狀:全部 12 個 @napi-rs/canvas 套件
2026.5.27371767.1MiB766.9MiB656.1MiB巢狀:全部 12 個 @napi-rs/canvas 套件
最新 2026.5.28300361.7MiB361.6MiB259.7MiB未安裝任何項目

Shrinkwrap 邊界

Shrinkwrap 之前

2026.5.20 沒有根 shrinkwrap,也沒有大型巢狀 OpenClaw 相依性樹。

已引入

2026.5.22 新增根 shrinkwrap,並在巢狀 openclaw/node_modules 下安裝 911.8MB。

最新穩定版

2026.5.28 保留 shrinkwrap,並且仍在巢狀 openclaw/node_modules 下安裝 259.7MiB。

Canvas 展開已修正

2026.5.28 在本機全新安裝稽核中,不再安裝任何 @napi-rs/canvas 套件。
已發布 tarball 檢查確認了這個邊界:
VersionPublished stable?Root npm-shrinkwrap.jsonNotes
2026.5.20shrinkwrap 之前最後一個穩定版本
2026.5.21不適用沒有穩定 npm 版本
2026.5.22已引入 shrinkwrap
2026.5.23不適用沒有穩定 npm 版本
2026.5.24不適用沒有穩定 npm 版本
2026.5.25不適用沒有穩定 npm 版本
2026.5.26巢狀相依性樹仍然存在
2026.5.27巢狀相依性樹仍然存在
2026.5.28巢狀相依性樹小很多
重要區別:shrinkwrap 本身不是問題v2026.5.28 仍然隨附根 shrinkwrap。問題在於套件形狀,導致 npm 具體化大型巢狀 OpenClaw 相依性樹,以及全部 12 個 @napi-rs/canvas 平台套件。v2026.5.28 中的巢狀樹較小,而且 canvas 平台展開不再出現在本機稽核中。 如需 shrinkwrap 與維護者層級套件檢查的白話說明,請參閱 npm shrinkwrap

供應鏈解讀

相依性數量是營運安全指標,不只是安裝大小指標。每個套件都會擴大維運者必須信任的維護者、tarball、傳遞更新、選用原生二進位檔,以及安裝時行為集合。 清理方向如下:
  • 將大型且選用的能力保留在預設核心安裝之外
  • 讓外掛套件擁有自己的執行階段相依性圖
  • 避免在閘道啟動期間進行執行階段套件管理器修復
  • 保留決定性的安裝,同時避免具體化所有平台的原生套件
  • 在套件驗收與量測路徑中保持停用安裝 script
  • 在發布前捕捉巢狀相依性樹與原生選用相依性爆量
相關文件: