Перевірка продуктивності релізу

Ця сторінка фіксує докази, що стоять за очищенням продуктивності, розміру пакета, залежностей і shrinkwrap OpenClaw у травні 2026 року. Це технічний супровід до публічної публікації в блозі.

Тут об’єднано два аудити:

• Перевірка продуктивності релізів: GitHub Releases від v2026.5.28 назад до стабільного v2026.4.23, з використанням workflow OpenClaw Performance, profile=smoke, lane mock-провайдера. Більшість рядків тегів мають один зразок; рядки v2026.5.27 і v2026.5.28 використовують найновіші repeat-3 артефакти гілки релізу.
• Попередній квітневий контекст: опубліковані базові значення mock-провайдера clawgrit-reports від v2026.4.1 до v2026.5.2, використані лише щоб не вважати зламані релізи кінця квітня публічною базою продуктивності.
• Перевірка розміру встановлення: свіжі встановлення 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.28

Очищення між v2026.5.27 і v2026.5.28 зменшило граф встановлення за замовчуванням замість того, щоб прибрати самі можливості.

Головні числа

Не використовуйте зламані рядки кінця квітня як публічні базові показники продуктивності. v2026.4.23 і v2026.4.29 корисні як докази регресії, але великі дельти у стилі 14x здебільшого описують відновлення після невдалої лінійки релізів.

Для наративу в блозі використовуйте ранішу квітневу опубліковану базову лінію як масштаб:

Раніша квітнева базова лінія — це v2026.4.14 з опублікованого запуску mock-provider clawgrit-reports. У цьому запуску використовувався repeat 3, і він зазнав невдачі лише тому, що діагностичну часову шкалу не було виведено; медіани холодного, теплого та RSS усе ще корисні як приблизний масштаб. Розглядайте це як наративний контекст, а не як статистику для релізного шлюзу.

У межах травневого проходу останній рядок релізної гілки суттєво зрушився від v2026.5.2:

Порівняно з попереднім стабільним релізом:

Обсяг встановлення

Розмір пакета npm

2026.5.12 — це помітна віха винесення plugin у changelog: Amazon Bedrock, Bedrock Mantle, Slack, OpenShell sandbox, Anthropic Vertex, Matrix і WhatsApp вийшли з шляху залежностей ядра, тож їхні конуси залежностей встановлюються разом із цими plugins, а не з кожним встановленням ядра.

Підсумок ходу агента Kova

Квітнева стабільна лінійка містить дві різні історії. Ранній квітень був повільним, але впізнаваним. Кінець квітня перетворився на регресійний обрив. v2026.5.2 — це місце, де лінія mock-provider уперше опускається в діапазон 3-5s і починає послідовно проходити у наданому проході.

Раніший опублікований контекст:

Наданий прохід:

Вихідні зонди

Вихідні зонди було пропущено для 17 успішних старіших refs, оскільки ті дерева вихідного коду ще не мали потрібних точок входу зондів. Метрики ходів агента для цих refs усе ще існують.

Репрезентативні точки вихідних зондів:

Сплеск справності CLI у v2026.5.22 видно в цій таблиці, хоча лінія agent-turn усе ще пройшла. Зберігайте вихідні зонди під час розслідування цільових регресій CLI або Gateway.

Аудит інсталяційного відбитка

Вибірки залежностей використовують по одному стабільному випуску на місяць, а також подію запровадження shrinkwrap у 2026.5.22 і найновіший випуск 2026.5.28.

Межа shrinkwrap

Перевірка опублікованого tarball підтверджує межу:

Важлива відмінність: сам shrinkwrap не є проблемою. v2026.5.28 усе ще постачається з кореневим shrinkwrap. Проблемою була форма пакета, через яку npm матеріалізував велике вкладене дерево залежностей OpenClaw і всі 12 платформних пакетів @napi-rs/canvas. У v2026.5.28 вкладене дерево менше, а розгортання платформ Canvas більше не потрапляє в локальний аудит.

Просте пояснення shrinkwrap і перевірок пакетів на рівні супровідників див. у npm shrinkwrap.

Інтерпретація ланцюга постачання

Кількість залежностей є метрикою операційної безпеки, а не лише метрикою розміру встановлення. Кожен пакет розширює набір супровідників, tarball, транзитивних оновлень, необов’язкових нативних бінарних файлів і поведінки під час встановлення, яким оператори мають довіряти.

Напрям очищення такий:

• тримати важкі й необов’язкові можливості поза стандартним встановленням ядра
• зробити так, щоб пакети Plugin володіли своїм графом runtime-залежностей
• уникати runtime-відновлення через менеджер пакетів під час запуску Gateway
• зберегти детерміновані встановлення без матеріалізації нативних пакетів для всіх платформ
• тримати скрипти встановлення вимкненими в шляхах приймання та вимірювання пакетів
• виявляти вкладені дерева залежностей і вибухове зростання нативних необов’язкових залежностей до публікації

Пов’язані документи:

• Розв’язання залежностей Plugin
• Інвентар Plugin
• Повна валідація випуску