تفوّق nullClaw المبني على Zig على OpenClaw في الذاكرة وزمن البدء في اختبارات محلية لوكلاء AI

NullClaw — بيئة تشغيل وكيل على Zig كملف ثنائي واحد — يُظهر أن وكيل AI محلي لا يتعين عليه أن يجر معه مجموعة ثقيلة. في الاختبارات المقارنة مع OpenClaw، كان المشروع ينطلق بشكل أسرع ويستهلك رتبة عظيمة أقل من الذاكرة، خاصة في المهام المتوازية.

لماذا Zig هنا

الفكرة الرئيسية للمقالة ليست الإعلان عن NullClaw كفائز مطلق بين جميع منصات الوكلاء. يقارن المؤلف بينها وبين OpenClaw فقط في سيناريوهات محلية قصيرة: أوامر الخدمة، تشغيل وكيل واحد، مهمة برمجية صغيرة ودفعة من التشغيلات المتوازية. على خلفية هذا، يصبح واضحاً مدى تكلفة وكيل AI نموذجي كعملية اليوم.

تحتوي معظم هذه الأنظمة على Node.js وPython والتبعيات والخدمات الخلفية وطبقة البوابة تحت الغطاء. يقدم NullClaw نهجاً مختلفاً: بيئة تشغيل مضغوطة بأقصى حد بدون حمل غير ضروري.

وبالتالي اختيار Zig. اللغة مطلوبة هنا ليس من أجل الموضة، بل من أجل صراحة الهندسة: ملف ثنائي واحد، تحكم صريح في الذاكرة، عدم وجود بيئة تشغيل مُدارة ثقيلة وبنايات أكثر فهماً. في build.

zig يلاحظ المؤلف بشكل منفصل مفاتيح compile-time للقنوات ومحركات الذاكرة، مما يعني أن البناء يمكن تخصيصه لسيناريو محدد. هذا مهم ليس فقط لسرعة البدء، بل أيضاً للنشر الذاتي والنشر على الحافة، حيث يصبح كل ميجابايت إضافي وكل تبعية بسرعة مشكلة عملية.

الأرقام بدون ضوضاء

تم أخذ القياسات على Mac mini M4 مع 16 GB من RAM و macOS arm64. استخدم كلا المشروعين نفس النموذج عبر OpenRouter، وتم حساب المقاييس عبر سلسلة من التشغيلات: بشكل منفصل للعمليات "الطازجة"، بشكل منفصل لسيناريوهات warm، بشكل منفصل لـ coding-runs والمهام المتوازية. يفصل المؤلف عن قصد بين الحمل الكامل للبيئة التشغيلية وكمون الشبكة للنموذج، لأنه في الحالة الأخيرة حتى بيئة تشغيل خفيفة جداً تصطدم بـ round-trip الخارجي.

• أمر --help: NullClaw — 0,002 ثانية وحوالي 1,9 MB RSS، OpenClaw — 0,621 ثانية وحوالي 308 MB
• short agent-run: 2,55 ثانية وحوالي 7,7 MB مقابل 3,37 ثانية وحوالي 567 MB
• small coding-run: 4,86 ثانية وحوالي 7,7 MB مقابل 6,64 ثانية وحوالي 572 MB
• 10 مهام برمجية متوازية: 9,3 ثانية وحوالي 54 MB RSS إجمالي مقابل 13,14 ثانية وحوالي 523 MB

الفرق الأقوى مرئي بدقة في الذاكرة. من حيث السرعة، NullClaw غالباً ما يكون أسرع، لكن ليس دائماً بشكل دراماتيكي، لأن بعض السيناريوهات محدودة برد النموذج عبر الشبكة. في الوقت نفسه، في التشغيلات القصيرة والمتوازية، يبقى OpenClaw باستمرار على مستوى مئات الميجابايت، بينما NullClaw — على مستوى واحد أو عشرات الميجابايت. للاستخدام المحلي، هذا يعني تشغيلات متعددة الوكلاء أرخص وحملاً أكثر قابلية للتنبؤ وأقل احتكاكاً عند الانتقال بين الأجهزة.

المعنى العملي للمقارنة

توفر المقالة أيضاً مثالاً أكثر إيحاءً من الجداول الجافة: مشروع ClawWatch للساعات الذكية. يستخدم NullClaw كملف ثنائي ARM ثابت مع تطبيق التعرف على الكلام في وضع عدم الاتصال Vosk و TTS مدمج، ويمكنه التعامل مع بعض الطلبات دون استدعاء النموذج. هنا، تتوقف الإحكام عن أن تكون مجرد تحسين ممتع. بالنسبة لجهاز به حد ذاكرة صارم، يحدد الفرق بين بضعة ميجابايت ومئات الميجابايت ما إذا كان من الممكن بالفعل دمج الوكيل في المنتج، وليس فقط تشغيله على محمول المطور.

"على ساعة ذكية، الفرق بين 'بضعة ميجابايت' و 'مئات الميجابايت' هو سؤال

'هل يناسب هذا بالكامل؟'."

يلاحظ المؤلف بشكل منفصل أنه لا توجد أيضاً سحر مع حجم الملف الثنائي هنا. في README لـ ReleaseSmall، يتم المطالبة بـ 678 KB، لكن القطع الأثرية للإصدار المنشورة أكبر بكثير: حوالي 3,9 MB لـ macOS arm64 و 3,1 MB لـ Linux arm64، مع بناء محلي يعطي حوالي 2,6 MB. لكن الاستنتاج الرئيسي لا يتغير: قيمة NullClaw لا تكمن في الرقم الرئيسي من README، بل في مزيج من الإقلاع السريع و RSS المنخفض وسطح وظيفي ضيق يسهل التحكم فيه من منظور التشغيل والأمان.

ما يعني هذا

يعيد NullClaw محادثة حول وكلاء AI إلى سؤال مرتكز على الأرض: كم يجب أن تكلف تشغيل عملية واحدة؟ إذا انتقلت بنية الوكيل نحو edge و self-hosted والمهام المتوازية على نطاق واسع، فستفوز بيئات التشغيل التي توفر الذاكرة والتي تبدأ بدون توقف ولا تجر معها نصف خادم من التبعيات.