Revisione delle prestazioni del rilascio

Questa pagina raccoglie le prove alla base della pulizia di maggio 2026 di prestazioni, dimensione del pacchetto, dipendenze e shrinkwrap di OpenClaw. È il complemento tecnico al post pubblico del blog. Qui sono combinati due audit:

• Analisi delle prestazioni di release: GitHub Releases da v2026.5.28 fino alla stabile v2026.4.23, usando il workflow OpenClaw Performance, profile=smoke, corsia mock-provider. La maggior parte delle righe dei tag è un campione; le righe v2026.5.27 e v2026.5.28 usano gli ultimi artefatti repeat-3 del ramo di release.
• Contesto precedente di aprile: baseline mock-provider pubblicate in clawgrit-reports da v2026.4.1 a v2026.5.2, usate solo per evitare di trattare le release problematiche di fine aprile come baseline pubblica delle prestazioni.
• Analisi dell’impronta di installazione: installazioni fresche con npm install --ignore-scripts in pacchetti temporanei, con du -sk node_modules per la dimensione e una scansione di node_modules per i conteggi delle istanze di pacchetto.
• Analisi della dimensione del pacchetto npm: npm pack openclaw@<version> --dry-run --json per le release pubblicate, registrando la dimensione del tarball compresso, la dimensione decompressa e il conteggio dei file.

​

Istantanea

Copertura delle prestazioni: 77 release richieste, 74 punti basati su artefatti e 3 esecuzioni CI non disponibili. Ultimo punto stabile misurato: v2026.5.28.

​

Cronologia dell’impronta di installazione

​

Cosa è cambiato nella 5.28

La pulizia tra v2026.5.27 e v2026.5.28 ha ridotto il grafo dell’installazione predefinita invece di rimuovere le capacità stesse.

​

Numeri principali

Non usare le righe rotte di fine aprile come baseline pubbliche delle prestazioni. v2026.4.23 e v2026.4.29 sono utili come prova di regressione, ma i grandi delta in stile 14x descrivono soprattutto il recupero da una linea di release problematica. Per la narrazione del blog, usa come scala la baseline pubblicata di inizio aprile: La baseline di inizio aprile è v2026.4.14 dalla run mock-provider pubblicata in clawgrit-reports. Quella run usava repeat 3 ed è fallita solo perché la timeline diagnostica non è stata emessa; le mediane a freddo, a caldo e RSS restano utili come scala approssimativa. Considerala contesto narrativo, non una statistica da gate di release. All’interno dello sweep di maggio, l’ultima riga del branch di release si è spostata in modo materiale da v2026.5.2: Rispetto alla release stabile precedente:

​

Impronta dell’installazione

​

Dimensione del pacchetto npm

2026.5.12 è il milestone visibile dell’estrazione dei plugin nel changelog: Amazon Bedrock, Bedrock Mantle, Slack, OpenShell sandbox, Anthropic Vertex, Matrix e WhatsApp sono usciti dal percorso delle dipendenze core, così i loro coni di dipendenze vengono installati con quei plugin invece che con ogni installazione core.

​

Riepilogo dei turni agente Kova

La linea stabile di aprile contiene due storie diverse. L’inizio di aprile era lento ma riconoscibile. La fine di aprile è diventata un precipizio di regressione. v2026.5.2 è il punto in cui la lane mock-provider scende per la prima volta nell’intervallo 3-5s e inizia a passare in modo costante nello sweep fornito. Contesto pubblicato precedente: Sweep fornito:

​

Probe sorgente

Le probe sorgente sono state saltate per 17 ref precedenti riuscite perché quegli alberi sorgente non avevano ancora gli entry point di probe richiesti. Le metriche dei turni agente esistono comunque per quelle ref. Punti rappresentativi delle probe sorgente: Il picco di salute della CLI v2026.5.22 è visibile in questa tabella anche se la lane agent-turn è comunque passata. Conserva le sonde sorgente quando indaghi regressioni mirate della CLI o del Gateway.

​

Audit dell’impronta di installazione

I campioni delle dipendenze usano una release stabile per mese, più l’evento di introduzione dello shrinkwrap 2026.5.22 e l’ultima release 2026.5.28.

​

Confine dello shrinkwrap

L’ispezione dei tarball pubblicati verifica il confine: La distinzione importante: lo shrinkwrap in sé non è il problema. v2026.5.28 distribuisce ancora lo shrinkwrap root. Il problema era la forma del pacchetto che faceva materializzare a npm un grande albero annidato di dipendenze OpenClaw e tutti i 12 pacchetti di piattaforma @napi-rs/canvas. L’albero annidato è più piccolo in v2026.5.28 e il fanout delle piattaforme canvas non compare più nell’audit locale. Per una spiegazione in linguaggio semplice dello shrinkwrap e dei controlli dei pacchetti a livello di manutentore, consulta npm shrinkwrap.

​

Interpretazione della supply chain

Il conteggio delle dipendenze è una metrica di sicurezza operativa, non solo una metrica della dimensione di installazione. Ogni pacchetto espande l’insieme di manutentori, tarball, aggiornamenti transitivi, binari nativi opzionali e comportamenti in fase di installazione di cui gli operatori devono fidarsi. La direzione della pulizia è:

• mantenere le capacità pesanti e opzionali fuori dall’installazione core predefinita
• fare in modo che i pacchetti Plugin possiedano il proprio grafo di dipendenze di runtime
• evitare riparazioni del gestore pacchetti a runtime durante l’avvio del Gateway
• preservare installazioni deterministiche senza causare la materializzazione di pacchetti nativi per tutte le piattaforme
• mantenere gli script di installazione disabilitati nei percorsi di accettazione e misurazione dei pacchetti
• intercettare alberi di dipendenze annidati ed esplosioni di dipendenze opzionali native prima della pubblicazione

Documentazione correlata:

• Risoluzione delle dipendenze dei Plugin
• Inventario dei Plugin
• Validazione completa della release