nullClaw المكتوب بلغة Zig يتفوق على OpenClaw في استهلاك الذاكرة وسرعة الإقلاع في اختبارات محلية لوكلاء الذكاء الاصطناعي
أظهر NullClaw، وهو بيئة تشغيل للوكلاء مكتوبة بلغة Zig وتأتي في ملف تنفيذي واحد، استهلاكًا أقل بكثير للذاكرة وإقلاعًا أسرع في مقارنة محلية مع OpenClaw. ففي اختبار الأمر --help استهلك نحو 1,9 ميغابايت مقابل 308 ميغابايت، وفي سيناريو 10 مهام برمجية متوازية بلغ استهلاكه الإجمالي نحو 54 ميغابايت مقابل 523 ميغابايت لدى OpenClaw. يرى كاتب المقال أن هذه النتائج لا تعني أن NullClaw هو الفائز المطلق بين منصات الوكلاء كلها. فالمقارنة اقتصرت على سيناريوهات محلية قصيرة: أوامر خدمية، وتشغيل واحد للوكيل، ومهمة برمجية صغيرة، ومجموعة تشغيلات متوازية. ويبقى الفارق الأكبر في الذاكرة، أما في الزمن فيتقدم NullClaw في الغالب دون فارق هائل، لأن جزءًا من السيناريوهات يحدده زمن استجابة النموذج عبر الشبكة.
معالج بواسطة الذكاء الاصطناعي من Habr AI؛ بتحرير Hamidun News
NullClaw، وهو بيئة تشغيل (runtime) للوكلاء مكتوبة بلغة Zig وتأتي في ملف تنفيذي واحد، يُظهر أن وكيل الذكاء الاصطناعي المحلي ليس مضطرًا إلى حمل حزمة برمجية ثقيلة. ففي اختبارات المقارنة مع OpenClaw، أقلع المشروع أسرع واستهلك ذاكرة أقل بمرتبة كاملة، وبخاصة في المهام المتوازية.
لماذا Zig هنا
ليست الفكرة الرئيسية في المقال إعلان NullClaw فائزًا مطلقًا بين جميع منصات الوكلاء. فالكاتب يقارنه بـ OpenClaw في سيناريوهات محلية قصيرة فقط: أوامر خدمية، وتشغيل واحد للوكيل (agent-run)، ومهمة برمجية (coding) صغيرة، ومجموعة تشغيلات متوازية. وعلى هذه الخلفية يتضح كم تبلغ كلفة وكيل الذكاء الاصطناعي العادي بوصفه عملية (process) اليوم. فمعظم هذه الأنظمة تعتمد في بنيتها على Node.js وPython وحزم من التبعيات وخدمات تعمل في الخلفية وطبقة gateway. أما NullClaw فيقترح نهجًا مختلفًا: بيئة تشغيل مدمجة قدر الإمكان دون عتاد إضافي.
ومن هنا جاء اختيار Zig. فاللغة هنا ليست استجابة لموضة، بل لأسباب هندسية: ملف تنفيذي واحد، وتحكم صريح بالذاكرة، وغياب بيئة تشغيل مُدارة (managed runtime) ثقيلة، وعملية بناء أوضح. ويشير الكاتب في ملف build.zig إلى مفاتيح تبديل في وقت الترجمة (compile-time) للقنوات ولمحركات الذاكرة (memory engines)، أي أن البناء يمكن تضييقه ليناسب سيناريو محددًا. وهذا مهم لا لسرعة الإقلاع فحسب، بل أيضًا لعمليات النشر المستضافة ذاتيًا (self-hosted) وعلى الأجهزة الطرفية (edge)، حيث يتحول كل ميغابايت زائد وكل تبعية إضافية سريعًا إلى مشكلة عملية.
أرقام بلا ضجيج
أُجريت القياسات على Mac mini M4 بذاكرة 16 غيغابايت ونظام macOS arm64. واستُخدم للمشروعين النموذج نفسه عبر OpenRouter، واحتُسبت المقاييس على سلاسل من التشغيلات: بشكل منفصل للعمليات «الجديدة»، وللسيناريوهات «الدافئة» (warm)، ولتشغيلات المهام البرمجية، وللمهام المتوازية. ويفصل الكاتب عمدًا بين العبء الصافي لبيئة التشغيل وزمن الاستجابة الشبكي للنموذج، لأنه في الحالة الثانية تصطدم حتى أخف بيئة تشغيل بزمن الرحلة الخارجية (round-trip).
- الأمر --help: NullClaw — 0,002 ثانية ونحو 1,9 ميغابايت RSS، وOpenClaw — 0,621 ثانية ونحو 308 ميغابايت
- تشغيل وكيل قصير (agent-run): 2,55 ثانية ونحو 7,7 ميغابايت مقابل 3,37 ثانية ونحو 567 ميغابايت
- مهمة برمجية صغيرة (coding-run): 4,86 ثانية ونحو 7,7 ميغابايت مقابل 6,64 ثانية ونحو 572 ميغابايت
- 10 مهام برمجية متوازية: 9,3 ثانية ونحو 54 ميغابايت من RSS الإجمالي مقابل 13,14 ثانية ونحو 523 ميغابايت
يظهر الفارق الأكبر في الذاكرة تحديدًا. أما في الزمن فغالبًا ما يكون NullClaw أسرع، لكن ليس دائمًا بفارق كبير، لأن جزءًا من السيناريوهات تحدّه استجابة النموذج عبر الشبكة. ومع ذلك، يبقى OpenClaw في التشغيلات القصيرة والمتوازية عند مستوى مئات الميغابايت باستمرار، بينما يبقى NullClaw عند مستوى آحاد أو عشرات الميغابايت. وبالنسبة للاستخدام المحلي، يعني ذلك تشغيلًا متعدد الوكلاء أقل كلفة، وحملًا أكثر قابلية للتنبؤ، واحتكاكًا أقل عند النقل بين الأجهزة.
المعنى العملي للمقارنة
يتضمن المقال مثالًا أكثر دلالة من الجداول الجافة: مشروع ClawWatch للساعات الذكية. فهو يستخدم NullClaw بوصفه ملفًا تنفيذيًا ثابتًا لمعمارية ARM، إلى جانب التعرف على الكلام دون اتصال عبر Vosk ومحرك TTS مدمج، ويمكنه معالجة بعض الطلبات دون الرجوع إلى النموذج. وهنا لا تعود الصغر مجرد تحسين مستحب. فبالنسبة لجهاز بحد صارم للذاكرة، يحدد الفارق بين بضعة ميغابايت ومئات الميغابايت ما إذا كان بالإمكان أصلًا تضمين الوكيل في المنتج، لا مجرد تشغيله على حاسوب المطوّر.
«على الساعة، الفارق بين "بضعة ميغابايت" و"مئات الميغابايت" هو سؤال:
"هل يمكن تضمين هذا أصلًا"».
ويشير الكاتب أيضًا إلى أنه لا سحر في حجم الملف التنفيذي. ففي README المخصص لـ ReleaseSmall يُعلن عن 678 كيلوبايت، لكن حزم الإصدارات المنشورة أكبر بوضوح: نحو 3,9 ميغابايت لـ macOS arm64 و3,1 ميغابايت لـ Linux arm64، بينما أعطى البناء المحلي نحو 2,6 ميغابايت. غير أن الخلاصة الرئيسية لا تتغير: فقيمة NullClaw ليست في الرقم القياسي الوارد في README، بل في الجمع بين إقلاع سريع وRSS صغير ونطاق وظيفي ضيق يسهل التحكم فيه من ناحيتي التشغيل والأمان.
ماذا يعني هذا
يعيد NullClaw الحديث عن وكلاء الذكاء الاصطناعي إلى سؤال واقعي: كم ينبغي أن يكلّف تشغيل عملية واحدة. وإذا اتجهت البنية التحتية للوكلاء نحو الأجهزة الطرفية والنشر المستضاف ذاتيًا والمهام المتوازية الواسعة، فسيكسب من بيئات التشغيل تلك التي توفر الذاكرة، وتقلع دون تأخير، ولا تجرّ وراءها نصف خادم من التبعيات.
Delegate Deep Research, Coding & Workflows to an AI Agent
Deploy autonomous multi-step execution with NomadNet Agent (agent.nomadnet.ai) — automated web research, data synthesis, code generation, and complex task orchestration.
أهم ما في عالم الذكاء الاصطناعي — مرة كل أسبوع
سبع قصص مهمة فعلاً هذا الأسبوع، مختارة بعناية. بلا ضجيج ولا بيانات صحفية.
تم! تحقق من بريدك للتأكيد.