การกวาดตรวจประสิทธิภาพของรีลีส

หน้านี้บันทึกหลักฐานเบื้องหลังการล้างข้อมูลด้านประสิทธิภาพของ OpenClaw เดือนพฤษภาคม 2026, ขนาดแพ็กเกจ, dependency และ shrinkwrap เป็นคู่มือเชิงเทคนิคประกอบ บทความบล็อกสาธารณะ

มีการรวมการตรวจสอบสองชุดไว้ที่นี่:

• การกวาดตรวจประสิทธิภาพของรีลีส: GitHub Releases ตั้งแต่ v2026.5.28 ย้อนกลับไปถึง stable v2026.4.23 โดยใช้เวิร์กโฟลว์ OpenClaw Performance, profile=smoke, เลน mock-provider แถวของแท็กส่วนใหญ่เป็นตัวอย่างหนึ่งชุด; แถว v2026.5.27 และ v2026.5.28 ใช้อาร์ติแฟกต์ release-branch แบบ repeat-3 ล่าสุด
• บริบทช่วงต้นเดือนเมษายน: baseline mock-provider จาก clawgrit-reports ที่เผยแพร่แล้วตั้งแต่ v2026.4.1 ถึง v2026.5.2 ใช้เฉพาะเพื่อหลีกเลี่ยงการถือว่า รีลีสปลายเดือนเมษายนที่เสียเป็น baseline ประสิทธิภาพสาธารณะ
• การกวาดตรวจพื้นที่ติดตั้ง: การติดตั้งใหม่ด้วย npm install --ignore-scripts ลงในแพ็กเกจชั่วคราว โดยใช้ du -sk node_modules สำหรับขนาด และเดินสำรวจ node_modules เพื่อนับจำนวนอินสแตนซ์แพ็กเกจ
• การกวาดตรวจขนาดแพ็กเกจ npm: npm pack openclaw@<version> --dry-run --json สำหรับรีลีสที่เผยแพร่แล้ว โดยบันทึกขนาด tarball ที่บีบอัดแล้ว, ขนาดเมื่อแตกไฟล์ และ จำนวนไฟล์

ภาพรวม

ความครอบคลุมด้านประสิทธิภาพ: 77 รีลีสที่ขอ, 74 จุดที่มีอาร์ติแฟกต์รองรับ, และ 3 งาน CI ที่ไม่พร้อมใช้งาน จุดวัด stable ล่าสุด: v2026.5.28

ไทม์ไลน์พื้นที่ติดตั้ง

สิ่งที่เปลี่ยนใน 5.28

การเก็บกวาดระหว่าง v2026.5.27 และ v2026.5.28 ลดกราฟการติดตั้งค่าเริ่มต้น แทนที่จะลบความสามารถต่างๆ ออกไปเอง

ตัวเลขสำคัญ

อย่าใช้แถวที่เสียในช่วงปลายเดือนเมษายนเป็น baseline ประสิทธิภาพสาธารณะ v2026.4.23 และ v2026.4.29 เป็นหลักฐาน regression ที่มีประโยชน์ แต่ส่วนต่างขนาดใหญ่แบบ 14x ส่วนใหญ่อธิบายการฟื้นตัวจากสาย release ที่ไม่ดี

สำหรับ narrative ในบล็อก ให้ใช้ baseline ที่เผยแพร่ก่อนหน้าในเดือนเมษายนเป็นสเกล:

baseline ต้นเดือนเมษายนคือ v2026.4.14 จากการรัน mock-provider ของ clawgrit-reports ที่เผยแพร่แล้ว การรันนั้นใช้ repeat 3 และล้มเหลวเฉพาะเพราะ ไม่ได้ปล่อย diagnostic timeline ออกมา ค่ามัธยฐานของ cold, warm และ RSS ยังมีประโยชน์ในฐานะสเกลคร่าวๆ ให้ถือสิ่งนี้เป็นบริบท narrative ไม่ใช่ สถิติสำหรับ release gate

ภายใน sweep เดือนพฤษภาคม แถว release branch ล่าสุดขยับอย่างมีนัยสำคัญจาก v2026.5.2:

เทียบกับ stable release ก่อนหน้า:

ขนาดพื้นที่ติดตั้ง

ขนาดแพ็กเกจ npm

2026.5.12 คือหมุดหมายการแยก Plugin ที่เห็นได้ใน changelog: Amazon Bedrock, Bedrock Mantle, Slack, OpenShell sandbox, Anthropic Vertex, Matrix และ WhatsApp ถูกย้ายออกจากเส้นทาง dependency หลัก เพื่อให้กรวย dependency ของสิ่งเหล่านั้นติดตั้งพร้อมกับ Plugin เหล่านั้น แทนที่จะติดตั้งกับทุกการติดตั้ง core

สรุปเทิร์นเอเจนต์ Kova

สาย stable เดือนเมษายนมีเรื่องราวสองแบบที่ต่างกัน ช่วงต้นเมษายนช้าแต่ยังพอจำแนกได้ ช่วงปลายเมษายนกลายเป็นหน้าผา regression v2026.5.2 คือจุดที่ lane ของ mock-provider ลดลงเข้าสู่ช่วง 3-5 วินาทีเป็นครั้งแรก และเริ่มผ่านอย่างสม่ำเสมอ ใน sweep ที่ให้มา

บริบทที่เผยแพร่ก่อนหน้า:

sweep ที่ให้มา:

source probe

source probe ถูกข้ามสำหรับ ref เก่าที่สำเร็จ 17 รายการ เพราะ source tree เหล่านั้น ยังไม่มี entry point ของ probe ที่จำเป็น เมตริกเทิร์นเอเจนต์ยังคงมีอยู่สำหรับ ref เหล่านั้น

จุด source-probe ที่เป็นตัวแทน:

ค่า spike ด้านสุขภาพของ CLI ใน v2026.5.22 มองเห็นได้ในตารางนี้ แม้ว่า lane agent-turn จะยังผ่านอยู่ก็ตาม ให้เก็บ source probes ไว้เมื่อสืบสวน regression เฉพาะจุดของ CLI หรือ gateway

การตรวจสอบ install footprint

ตัวอย่าง dependency ใช้ stable release หนึ่งรายการต่อเดือน รวมถึงเหตุการณ์ เริ่มนำ shrinkwrap มาใช้ใน 2026.5.22 และ release ล่าสุด 2026.5.28

ขอบเขตของ shrinkwrap

การตรวจสอบ tarball ที่เผยแพร่ยืนยันขอบเขตดังกล่าว:

ความแตกต่างสำคัญคือ: ตัว shrinkwrap เองไม่ใช่ปัญหา v2026.5.28 ยังคงส่งมาพร้อม shrinkwrap ระดับรูท ปัญหาคือรูปทรงของแพ็กเกจ ที่ทำให้ npm materialize dependency tree ของ OpenClaw แบบซ้อนขนาดใหญ่ และแพ็กเกจ แพลตฟอร์ม @napi-rs/canvas ทั้ง 12 รายการ tree แบบซ้อนเล็กลงใน v2026.5.28 และ fanout ของแพลตฟอร์ม canvas ไม่ปรากฏในการตรวจสอบในเครื่องอีกต่อไป

สำหรับคำอธิบาย shrinkwrap แบบภาษาทั่วไปและการตรวจสอบแพ็กเกจระดับ maintainer ดู npm shrinkwrap

การตีความด้าน supply-chain

จำนวน dependency เป็น metric ด้านความปลอดภัยเชิงปฏิบัติการ ไม่ใช่แค่ metric ด้านขนาดการติดตั้งเท่านั้น ทุกแพ็กเกจขยายชุดของ maintainer, tarball, transitive update, optional native binary และพฤติกรรมระหว่างการติดตั้งที่ operator ต้องไว้วางใจ

ทิศทางการ cleanup คือ:

• เก็บ capability ที่หนักและเป็น optional ไว้นอกการติดตั้ง core เริ่มต้น
• ให้แพ็กเกจ Plugin เป็นเจ้าของ runtime dependency graph ของตัวเอง
• หลีกเลี่ยงการซ่อมแซม package-manager ระหว่างการเริ่มต้น Gateway
• รักษาการติดตั้งแบบ deterministic โดยไม่ทำให้เกิดการ materialize แพ็กเกจ native ทุกแพลตฟอร์ม
• ปิดใช้งาน install script ในเส้นทาง package acceptance และ measurement
• ตรวจจับ dependency tree แบบซ้อนและการเพิ่มขึ้นอย่างมากของ native optional dependency ก่อนเผยแพร่

เอกสารที่เกี่ยวข้อง:

• การ resolve dependency ของ Plugin
• inventory ของ Plugin
• การตรวจสอบ release แบบเต็ม