Passe de performance de version

Cette page rassemble les preuves derrière le nettoyage de mai 2026 d’OpenClaw concernant les performances, la taille des paquets, les dépendances et le shrinkwrap. Elle est le complément technique de l’article de blog public. Deux audits sont combinés ici :

• Balayage des performances de publication : les GitHub Releases de v2026.5.28 en remontant jusqu’à la version stable v2026.4.23, avec le workflow OpenClaw Performance, profile=smoke, voie mock-provider. La plupart des lignes de tags correspondent à un seul échantillon ; les lignes v2026.5.27 et v2026.5.28 utilisent les derniers artefacts repeat-3 de la branche de publication.
• Contexte antérieur d’avril : lignes de base mock-provider publiées dans clawgrit-reports, de v2026.4.1 à v2026.5.2, utilisées uniquement pour éviter de traiter les publications défaillantes de fin avril comme la ligne de base publique des performances.
• Balayage de l’empreinte d’installation : installations fraîches avec npm install --ignore-scripts dans des paquets temporaires, avec du -sk node_modules pour la taille et un parcours de node_modules pour compter les instances de paquets.
• Balayage de la taille du paquet npm : npm pack openclaw@<version> --dry-run --json pour les publications publiées, en enregistrant la taille compressée de l’archive tar, la taille décompressée et le nombre de fichiers.

​

Instantané

Couverture des performances : 77 publications demandées, 74 points appuyés par des artefacts, et 3 exécutions CI indisponibles. Dernier point stable mesuré : v2026.5.28.

​

Chronologie de l’empreinte d’installation

​

Ce qui a changé dans la version 5.28

Le nettoyage entre v2026.5.27 et v2026.5.28 a réduit le graphe de l’installation par défaut au lieu de supprimer les capacités elles-mêmes.

​

Chiffres clés

N’utilisez pas les lignes cassées de fin avril comme références publiques de performance. v2026.4.23 et v2026.4.29 sont des preuves de régression utiles, mais les grands écarts de type 14x décrivent surtout la récupération après une mauvaise série de versions. Pour le récit de blog, utilisez la référence publiée plus tôt en avril comme échelle : La référence de début avril est v2026.4.14, issue de l’exécution clawgrit-reports publiée avec fournisseur simulé. Cette exécution utilisait la répétition 3 et a échoué uniquement parce que la chronologie de diagnostic n’a pas été émise ; les médianes à froid, à chaud et RSS restent utiles comme ordre de grandeur approximatif. Traitez cela comme du contexte narratif, et non comme une statistique de validation de publication. Dans le balayage de mai, la dernière ligne de branche de publication a évolué de manière significative depuis v2026.5.2 : Par rapport à la version stable précédente :

​

Empreinte d’installation

​

Taille du paquet npm

2026.5.12 est le jalon visible d’extraction de plugins dans le changelog : Amazon Bedrock, Bedrock Mantle, Slack, OpenShell sandbox, Anthropic Vertex, Matrix et WhatsApp ont quitté le chemin de dépendances du cœur afin que leurs cônes de dépendances s’installent avec ces plugins au lieu de chaque installation du cœur.

​

Résumé des tours d’agent Kova

La série stable d’avril contient deux histoires différentes. Le début avril était lent mais reconnaissable. La fin avril est devenue un précipice de régression. v2026.5.2 est le point où la voie avec fournisseur simulé descend pour la première fois dans la plage de 3 à 5 s et commence à réussir de façon constante dans le balayage fourni. Contexte publié antérieur : Balayage fourni :

​

Sondes source

Les sondes source ont été ignorées pour 17 anciennes références réussies, car ces arborescences source n’avaient pas encore les points d’entrée de sonde requis. Les métriques de tours d’agent existent toujours pour ces références. Points représentatifs de sonde source : Le pic d’état de santé de la CLI v2026.5.22 est visible dans ce tableau, même si la voie agent-turn réussissait toujours. Conservez les sondes source lors de l’investigation des régressions ciblées de la CLI ou du Gateway.

​

Audit de l’empreinte d’installation

Les échantillons de dépendances utilisent une version stable par mois, plus l’événement d’introduction du shrinkwrap 2026.5.22 et la dernière version 2026.5.28.

​

Limite du shrinkwrap

L’inspection des tarballs publiés vérifie la limite : La distinction importante : le shrinkwrap lui-même n’est pas le problème. v2026.5.28 fournit toujours un shrinkwrap racine. Le problème était la forme du paquet qui amenait npm à matérialiser un grand arbre de dépendances OpenClaw imbriqué et les 12 paquets de plateforme @napi-rs/canvas. L’arbre imbriqué est plus petit dans v2026.5.28, et l’éventail des plateformes Canvas n’apparaît plus dans l’audit local. Pour une explication en langage clair du shrinkwrap et des vérifications de paquet au niveau mainteneur, consultez shrinkwrap npm.

​

Interprétation de la chaîne d’approvisionnement

Le nombre de dépendances est une métrique de sécurité opérationnelle, pas seulement une métrique de taille d’installation. Chaque paquet élargit l’ensemble des mainteneurs, des tarballs, des mises à jour transitives, des binaires natifs optionnels et des comportements au moment de l’installation auxquels les opérateurs doivent faire confiance. La direction du nettoyage est la suivante :

• conserver les capacités lourdes et optionnelles hors de l’installation du cœur par défaut
• faire en sorte que les paquets de Plugin possèdent leur propre graphe de dépendances d’exécution
• éviter les réparations du gestionnaire de paquets à l’exécution pendant le démarrage du Gateway
• préserver des installations déterministes sans provoquer la matérialisation de paquets natifs pour toutes les plateformes
• garder les scripts d’installation désactivés dans les chemins d’acceptation et de mesure des paquets
• détecter les arbres de dépendances imbriqués et les explosions de dépendances optionnelles natives avant publication

Documentation connexe :

• Résolution des dépendances de Plugin
• Inventaire des Plugins
• Validation de version complète