حصل OpenClaw على إعادة تنفيذ بـGo: ملف ثنائي واحد بحجم 35 ميغابايت بدلًا من 800 ميغابايت من الاعتماديات

تلقى OpenClaw، الذي حصل على حوالي 180 ألف نجمة على GitHub، إعادة تنفيذ مستقلة في Go. يعد المشروع الجديد المسمى GoClaw بالقضاء على نقاط الضعف الرئيسية في إصدار Node.js: التبعيات الثقيلة والوقت التشغيلي غير الضروري والنشر المعقد على الخوادم محدودة الموارد.

لماذا يكون GoClaw ضروريًا

الشكوى الرئيسية حول OpenClaw لا تتعلق بالوظائف، بل بالتعبئة. لتشغيل المشروع الأصلي، تحتاج إلى Node.js و npm والمستودع نفسه وتثبيت مجموعة كبيرة من التبعيات التي قد تصل إلى 500-800 ميجابايت. في الواقع العملي، يعني هذا أوقات بدء بطيئة وتضاربات في الإصدارات ومشاكل مع الوحدات الأصلية والمزيد من نقاط الفشل إذا كان يجب نشر الخدمة بسرعة على VPS أو كمبيوتر صغير أو Raspberry Pi.

يحل GoClaw هذه المشكلة بالطريقة الأكثر مباشرة: بدلاً من نظام بيئي من الوقت التشغيلي و node_modules، يحصل المستخدم على ملف تنفيذي واحد مترجم بشكل ثابت بحجم حوالي 35 ميجابايت. يمكن ببساطة تحميله ومنحه صلاحيات التنفيذ واستخدامه على الفور. بالنسبة للأدوات التي يجب أن تعمل في الخلفية 24/7 وتنتظر الرسائل من Telegram و Discord أو قنوات أخرى، يقلل هذا التنسيق بشكل كبير من حاجز الدخول ويبسط الدعم.

كيفية تنظيم المشروع

من المهم ملاحظة أن GoClaw ليس fork أو غلاف رقيق للأصل، بل نسخة مكتوبة من الصفر كبوابة وكيل ذكي متعدد الوكلاء. يتصل المشروع بتطبيقات المراسلة ويمكنه العمل مع عدة موفري LLM ويستفيد من التزامن المدمج في Go. في المقالة، يتم عرض هذا كأساس أكثر طبيعية للسيناريوهات مع الوكلاء، حيث توجد طلبات متوازية كثيرة وانتظار الردود من API والتنسيق بين الأدوار.

• ملف تنفيذي واحد بحجم حوالي 35 ميجابايت
• دعم 11+ موفري LLM
• التشغيل عبر 5 قنوات اتصال، بما فيها Telegram و Discord
• نظام متعدد الوكلاء مع التفويض والتنسيق
• لوحة Kanban لإدارة مهام الوكلاء

تم بناء البنية نفسها حول عدة وكلاء متخصصين. أحدهما مسؤول عن تصميم الحل، والآخر يكتب الكود، والثالث يفحص الاختبارات، والرابع يتعامل مع المراجعات. يتم تحليل المهام عالية المستوى تلقائيًا ويتم توزيع المراحل على لوحة Kanban الداخلية. بالنسبة لـ Go، يبدو هذا السيناريو طبيعيًا: تسمح goroutines والقنوات بإدارة سلاسل متوازية عديدة دون تعقيد غير ضروري، بينما في Node.js يرتبط كل هذا عادة بحلقة الأحداث والوعود.

حيث تكون المزايا والقيود

على جانب GoClaw ليس فقط الإحكام بل أيضًا الاقتصاد التشغيلي. تذكر المادة انخفاضًا بمعامل 3-5 في استهلاك الذاكرة مقارنة بإصدار Node.js مع وظائف قابلة للمقارنة. هذا مهم بشكل خاص بالنسبة لمثيلات VPS الرخيصة التي تحتوي على 512 ميجابايت أو 1 غيغابايت من ذاكرة الوصول العشوائي، حيث يستهلك كل عملية تعمل باستمرار الموارد بسرعة. تستفيد الحاوية أيضًا: يمكن بناء صورة تطبيق Go من الملف التنفيذي تقريبًا، بينما تجلب خدمة Node.js عادة قاعدة أثقل وكل دليل التبعيات.

لكن لهذا الانتقال ثمن. OpenClaw قوي ليس فقط في الكود بل في نظام بيئي ناضج: لديه مجتمع كبير و 180 ألف+ نجمة وملحقات مستقرة والمهارات والتكاملات. GoClaw لا يزال صغيرًا، مع عدد أقل من المستخدمين والتحقق من الإنتاج أقل. لا توجد توافق تقريبًا بين الأنظمة البيئية: لا يمكن ببساطة نقل المهارات الموجودة من OpenClaw.

لذلك يعتمد الاختيار على المهمة: إذا كنت بحاجة إلى خدمة بسيطة للعمل في الخلفية، فإن إصدار Go منطقي؛ إذا كانت الملحقات والتخصيص والمجتمع مهمة، فإن الأصل لا يزال أقوى بشكل ملحوظ.

ما يعنيه هذا

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