Skip to main content
Questa pagina raccoglie le evidenze alla base dell’intervento di maggio 2026 su prestazioni, dimensioni del pacchetto, dipendenze e pulizia dello shrinkwrap di OpenClaw. È il complemento tecnico al post pubblico del blog. Qui sono combinati due audit:
  • Analisi delle prestazioni delle release: GitHub Releases da v2026.5.28 fino alla versione stabile v2026.4.23, usando il workflow OpenClaw Performance, profile=smoke e il percorso del provider simulato. La maggior parte delle righe dei tag usa un singolo campione; le righe v2026.5.27 e v2026.5.28 usano gli artefatti più recenti con 3 ripetizioni del ramo di release.
  • Contesto precedente di aprile: baseline pubblicate del provider simulato in clawgrit-reports da v2026.4.1 a v2026.5.2, usate esclusivamente per evitare di considerare le release difettose di fine aprile come baseline pubblica delle prestazioni.
  • Analisi dell’ingombro dell’installazione: installazioni pulite tramite npm install --ignore-scripts in pacchetti temporanei, con du -sk node_modules per le dimensioni e una scansione di node_modules per il conteggio delle istanze dei pacchetti.
  • Analisi delle dimensioni del pacchetto npm: npm pack openclaw@<version> --dry-run --json per le release pubblicate, registrando le dimensioni del tarball compresso, le dimensioni dopo l’estrazione e il numero di file.
L’analisi principale delle prestazioni usa un campione smoke per tag, eccetto le righe v2026.5.27 e v2026.5.28, che usano gli artefatti più recenti con 3 ripetizioni del ramo di release. Il contesto precedente di aprile usa le mediane pubblicate di 3 ripetizioni da clawgrit-reports. Considera i numeri come evidenza delle tendenze e segnale per la ricerca di regressioni, non come statistiche per i criteri di rilascio.
Copertura delle prestazioni: 77 release richieste, 74 punti supportati da artefatti e 3 esecuzioni CI non disponibili. Ultimo punto stabile misurato: v2026.5.28.

Turno stabile dell'agente

Turno a freddo 5,1 volte più veloce
  • v2026.4.14: 9,8 s
  • v2026.5.28: 1,9 s

Pacchetto pubblicato

Tarball da 17,9 MBUltimo pacchetto stabile, in calo rispetto al picco di marzo di 43,3 MB.

Ultima installazione stabile

Installazione pulita da 361,7 MiBRiduce nettamente l’albero annidato delle dipendenze di OpenClaw rispetto al picco dovuto all’introduzione dello shrinkwrap in 2026.5.22, sebbene nell’audit dell’installazione locale rimanga ancora un albero annidato più piccolo da 259,7 MiB.

Grafo delle dipendenze

300 pacchetti installatiMisurati come radici univoche per nome/versione del pacchetto in un’installazione pulita con gli script disabilitati; 71 radici in meno rispetto alla precedente release stabile.

​
Cosa è cambiato nella versione 5.28

La pulizia tra v2026.5.27 e v2026.5.28 ha ridotto il grafo dell’installazione predefinita, anziché rimuovere le funzionalità stesse.

Grafo radice predefinito

Le radici univoche per nome/versione del pacchetto sono scese da 371 a 300. Le istanze dei pacchetti sono scese da 372 a 301.

Albero annidato

Il percorso annidato openclaw/node_modules è sceso da 656,1 MiB a 259,7 MiB nello stesso audit dell’installazione locale.

Coni nativi opzionali

Il cono dei pacchetti nativi multipiattaforma di @napi-rs/canvas non viene più incluso nell’installazione predefinita.

Superficie della catena di fornitura

Meno pacchetti predefiniti significano meno tarball, manutentori, binari nativi, comportamenti in fase di installazione e percorsi di aggiornamento transitivi da considerare attendibili per impostazione predefinita.
Lo shrinkwrap non era di per sé il problema. Lo era la struttura inadeguata del pacchetto. v2026.5.28 include ancora lo shrinkwrap, ma l’albero annidato delle dipendenze è molto più piccolo e nell’audit locale è stata eliminata la distribuzione multipiattaforma di canvas.

​
Dati principali

Non usare le righe difettose di fine aprile come baseline pubbliche delle prestazioni. v2026.4.23 e v2026.4.29 sono utili come evidenza di regressione, ma le grandi variazioni nell’ordine di 14x descrivono principalmente il recupero da una serie di release problematica. Per la narrazione del blog, usa la baseline pubblicata all’inizio di aprile come riferimento di scala. La baseline è v2026.4.14 dell’esecuzione pubblicata con provider simulato in clawgrit-reports (3 ripetizioni; tale esecuzione non è riuscita soltanto perché non è stata generata la sequenza temporale diagnostica, quindi le mediane a freddo, a caldo e RSS restano comunque utili come indicazione approssimativa). Considerala come contesto narrativo, non come statistica per i criteri di rilascio. Nell’analisi di maggio, l’ultima riga del ramo di release è migliorata in modo sostanziale rispetto a v2026.5.2: Rispetto alla precedente release stabile:

​
Ingombro dell’installazione

​
Dimensioni del pacchetto npm

2026.5.12 è il traguardo visibile dell’estrazione dei Plugin nel changelog: Amazon Bedrock, Bedrock Mantle, Slack, sandbox OpenShell, Anthropic Vertex, Matrix e WhatsApp sono stati rimossi dal percorso delle dipendenze principali, in modo che i relativi coni di dipendenze vengano installati con tali Plugin anziché con ogni installazione del nucleo.

​
Riepilogo dei turni dell’agente Kova

La serie stabile di aprile contiene due storie diverse. L’inizio di aprile era lento, ma riconoscibile. La fine di aprile ha segnato un crollo dovuto a una regressione. v2026.5.2 è il punto in cui il percorso del provider simulato scende per la prima volta nell’intervallo di 3-5 secondi e inizia a riuscire con costanza nell’analisi fornita. Contesto pubblicato in precedenza: Analisi fornita:

​
Sonde del codice sorgente

Le sonde del codice sorgente sono state omesse per 17 riferimenti precedenti riusciti perché i relativi alberi del codice sorgente non disponevano ancora dei punti di ingresso richiesti per le sonde. Le metriche dei turni dell’agente esistono comunque per tali riferimenti. Punti rappresentativi delle sonde del codice sorgente: Il picco di integrità della CLI in v2026.5.22 è visibile in questa tabella, anche se il percorso dei turni dell’agente è comunque riuscito. Mantieni le sonde del codice sorgente quando analizzi regressioni mirate della CLI o del Gateway.

​
Audit dell’ingombro dell’installazione

I campioni delle dipendenze usano una release stabile per mese, oltre all’evento di introduzione dello shrinkwrap in 2026.5.22 e all’ultima release 2026.5.28.

​
Confine dello shrinkwrap

2026.5.20 è stato distribuito senza uno shrinkwrap radice e senza un grande albero di dipendenze OpenClaw annidato. 2026.5.22 ha introdotto lo shrinkwrap radice e installato 911.8MB nel percorso annidato openclaw/node_modules. 2026.5.28 mantiene lo shrinkwrap e installa ancora 259.7MiB nel percorso annidato openclaw/node_modules, ma non installa più alcun pacchetto @napi-rs/canvas nel controllo locale dell’installazione pulita. L’ispezione del tarball pubblicato verifica il confine: La distinzione importante: lo shrinkwrap in sé non è il problema. v2026.5.28 include ancora lo shrinkwrap radice. Il problema era la struttura del pacchetto che induceva npm a materializzare un grande albero di dipendenze OpenClaw annidato e tutti i 12 pacchetti di piattaforma @napi-rs/canvas. L’albero annidato è più piccolo in v2026.5.28 e la proliferazione multipiattaforma di Canvas non compare più nel controllo locale. Per una spiegazione in linguaggio semplice dello shrinkwrap e dei controlli dei pacchetti a livello di manutentore, consulta shrinkwrap npm.

​
Interpretazione della catena di fornitura

Il numero di dipendenze è una metrica di sicurezza operativa, non soltanto una metrica delle dimensioni di installazione. Ogni pacchetto amplia l’insieme di manutentori, tarball, aggiornamenti transitivi, binari nativi facoltativi e comportamenti durante l’installazione di cui gli operatori devono fidarsi. La direzione della razionalizzazione è:
  • mantenere le funzionalità pesanti e facoltative fuori dall’installazione predefinita del nucleo
  • fare in modo che i pacchetti dei Plugin siano responsabili del proprio grafo di dipendenze di runtime
  • evitare interventi correttivi del gestore di pacchetti durante l’avvio del Gateway
  • preservare installazioni deterministiche senza causare la materializzazione dei pacchetti nativi per tutte le piattaforme
  • mantenere disabilitati gli script di installazione nei percorsi di accettazione e misurazione dei pacchetti
  • rilevare gli alberi di dipendenze annidati e le esplosioni di dipendenze native facoltative prima della pubblicazione
Documentazione correlata: