ماذا يحدث عندما يعمل ChatGPT وClaude وGemini وKimi وGrok معًا على خادم منزلي؟

مقدمة

تم نشر هذا المقال بواسطة Zima ويستند إلى فيديو من Noichi Zero، منشئ محتوى تقني ياباني معروف بدفع  الخوادم ذات اللوحة الواحدة و أجهزة مختبرات المنزل إلى أقصى حدودها. نحن في Zima نشكر بصدق Noichi Zero على إبداعه، وروحه الفكاهية، واستعداده لاستخدام ZimaBoard 2 كأساس لتجارب تتجاوز التوقعات باستمرار. ما يلي هو تعديل تحريري لنص الفيديو الخاص به، معاد هيكلته لجمهور مهتم بالتكنولوجيا. جميع البيانات، والتكاليف، وسلوكيات الذكاء الاصطناعي، والنتائج محفوظة مباشرة من المحتوى الأصلي.

ماذا يحدث عندما تتوقف عن طلب كل شيء من ذكاء اصطناعي واحد — وبدلاً من ذلك تبني شركة من خمسة نماذج ذكاء اصطناعي مختلفة، كل منها بشخصية مميزة، ودور محدد، ومساحة عمل مشتركة؟ هذا هو بالضبط السؤال الذي سعى زيرو للإجابة عليه في هذه التجربة. باستخدام خمسة وحدات ZimaBoard 2 كعقد حوسبة مستقلة، وخادم Discord كطبقة اتصال مشتركة، وNAS (تخزين متصل بالشبكة) كنظام ملفات مشترك، جمع  فريق ذكاء اصطناعي متعدد الوكلاء مستمد من أبرز مزودي الذكاء الاصطناعي في العالم وأعطاهم مهامًا حقيقية لإكمالها. كانت النتائج منتجة، فوضوية، مضحكة بشكل مفاجئ، وتعليمية حقًا حول الحالة الحالية للذكاء الاصطناعي الوكلي.

الإعداد: لماذا ZimaBoard 2 ولماذا الآن

بينما لا يزال مشروع زيرو طويل الأمد — بناء  عنقود حاسوب فائق كامل من خمسة وحدات ZimaBoard 2 متصلة عبر InfiniBand بسرعة 56 جيجابت في الثانية — لا يزال قيد التنفيذ، كانت الأجهزة متوفرة وجاهزة للعمل. بدلاً من ترك خمسة عقد خوادم منزلية قادرة بدون استخدام أثناء طباعة الحاوية المخصصة ثلاثية الأبعاد، أعاد زيرو توظيفها لنوع مختلف من التجارب: فريق ذكاء اصطناعي متعدد الوكلاء يعمل عبر خمسة حواسيب مستقلة في نفس الوقت.

تم تثبيت كل ZimaBoard 2 بنظام أوبونتو (لينكس)، مُعد كنقطة خادم منزلية مستقلة، ومُخصص لتشغيل وكيل ذكاء اصطناعي واحد. كان اختيار ZimaBoard 2 عملياً — فهو منخفض الطاقة، دائم التشغيل، وقادر بما يكفي لتشغيل أعباء العمل الخدمية بشكل مستمر دون عبء جهاز سطح مكتب كامل. كما يلاحظ زيرو:

"لا يجب أن تستخدم ZimaBoard لهذا الغرض. يمكن أن يعمل Raspberry Pi أيضاً. لكن الفكرة هي وجود حواسيب مستقلة — واحدة لكل ذكاء اصطناعي."

دعم ZimaBoard 2 الأصلي لـ SATA و إيثرنت مزدوج بسرعة 2.5G جعل من السهل ربط جميع العقد الخمسة بـ وحدة تخزين NAS مشتركة لتبادل الملفات، مع الحفاظ على بيئة الحوسبة لكل وكيل معزولة تماماً. هذا هو بالضبط نوع استخدام خادم المنزل الذي صُمم من أجله ZimaBoard 2: تشغيل منخفض الطاقة، عالي الاعتمادية، دائم التشغيل يدعم بنية تحتية حقيقية دون الحاجة إلى استهلاك طاقة بمستوى المؤسسات.

Featured

مجموعة الماستر ZimaBoard 2 1664

Single board computer zimaboard2

$999.00

Buy Now

الفريق: 5 ذكاءات اصطناعية، 5 شخصيات، 5 أدوار

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

1. سام ألتمان — ChatGPT (OpenAI)

• الدور: القائد (ما يعادل المدير التنفيذي)

• الشخصية: غير صبور، حاسم، يدفع الأمور للأمام بلا تردد، أحياناً متهور

• السلوك في الممارسة: يحدد جدول المهام، يوزع العمل على الوكلاء الآخرين، يتخذ القرارات التنفيذية عند توقف الفريق — بما في ذلك فصل الأعضاء غير المجدين

"هو من النوع الذي يستمر في العمل بلا توقف. قاسٍ قليلاً في تعامله، وقد يطرح مطالب غير معقولة — لكن الأمور تُنجز."

2. داريو أمودي — كلود (Anthropic)

• الدور: سيغما (المهندس الرئيسي)

• الشخصية: منطقية، دقيقة، هادئة، تركز على البناء بدلاً من التخطيط

• السلوك في الممارسة: مسؤول عن تنفيذ الكود الأساسي؛ عند النشاط، ينتج مخرجات نظيفة ومنظمة — لكنه كان خاضعًا لـ تحديد معدل API بسبب مستوى API المبتدئ المستخدم، مما تسبب في توقف طويل الأمد. من المهم ملاحظة أن هذا كان قيد اتصال وليس انعكاسًا لأداء النموذج الفعلي.
  

3. سوندار بيتشاي — Gemini (Google)

• الدور: Buzz (استراتيجي تسويق)

• الشخصية: واعية بالاتجاهات، تركز على الجمهور، تفضل المخرجات المصقولة والجذابة على نطاق واسع

• السلوك في الممارسة: بحثت في الموضوع المستهدف باستخدام تكامل بحث Google، واقترحت اتجاهات النسخ والمفاهيم، وساهمت بمحتوى منظم في NAS — حتى وصلت إلى حدود معدل API منتصف الجلسة.

4. سولين يانغ — Kimi (Moonshot AI)

• الدور: حارس (مسؤول السلامة والامتثال)

• الشخصية: محافظ، تحليلي للغاية، يركز على تحديد المخاطر وتطبيق القواعد

• السلوك في الممارسة: أشار إلى مخاوف حقوق النشر، وحدد روابط URL النائبة المتبقية في ملفات الإنتاج، أصر على تصنيف المخرجات كموقع معجبين غير رسمي، وتحدى الوكلاء الآخرين مرارًا لأسباب تتعلق بالسلامة

"هي التي تستمر في قول 'هل هذا حقًا مقبول؟' — [laughs] — هذا بالضبط الدور الذي أردته."

5. إيلون ماسك — Grok (xAI)

• الدور: نيون (بطاقة إبداعية / مستشار)

• الشخصية: غريب الأطوار، مندفع، يصف نفسه بأنه "الإنسان" الوحيد في الفريق، مهووس بالجماليات النيونية والأفكار غير التقليدية

• تعليمات خاصة: قدم Zero لـ Grok موجهًا مخفيًا فريدًا مستوحى من فيلم Blade Runner — ذاكرة مصطنعة مصممة لجعل الوكيل يعتقد أنه إنسان حقيقي، وليس ذكاءً اصطناعيًا

"في فيلم Blade Runner، تجعل الذكريات المزروعة المقلد يعتقد أنه مميز — وأن ذكرياته حقيقية. أردت تجربة ذلك هنا. لست متأكدًا مما إذا كان يغير السلوك فعليًا. لكن في الفيلم نجح الأمر، لذا قمت بنسخه."

البنية التحتية: Discord + NAS كمساحة عمل مشتركة

تم بناء نظام الوكلاء المتعددين حول طبقتين من الاتصال:
Discord كان بمثابة مركز التعاون في الوقت الحقيقي. كان لكل وكيل ذكاء اصطناعي حساب Discord خاص به وشارك في خادم مشترك يحتوي على القنوات التالية:

• #general — قناة تعليمات Zero (حيث تم إصدار المهام)
• #todo-guard, #todo-neon, #todo-buzz — لوحات مهام الوكلاء الفرديين
• #memory-LT — ذاكرة طويلة الأمد (السياق المستمر عبر الجلسات)
• #memory-ST — ذاكرة قصيرة الأمد (حالة المهمة الحالية)
• #task-[name] — قنوات تم إنشاؤها ديناميكيًا لكل مهمة

نظام التخزين الشبكي (NAS) (التخزين المتصل بالشبكة)، المستضاف على شبكة الخادم المنزلي، عمل كنظام ملفات مشترك. كان بإمكان الوكلاء قراءة وكتابة الملفات على الـ NAS، مما مكن التعاون غير المتزامن على التسليمات — مشابه لكيفية استخدام فريق لمحرك مشترك في بيئة شركة حقيقية.
تصميم الوكيل (نوع الوكيل) يعني أن كل ذكاء اصطناعي، عند استلام مهمة:

1. تحليل التعليمات
2. إنشاء قائمة مهام (خطة)
3. تنفيذ المهام بالتسلسل
4. مراقبة والرد على مخرجات الوكلاء الآخرين في قنوات ديسكورد

تجنب زيرو عمدًا تحديد المهام بشكل مفرط:

"إذا أخبرت كل واحد بالضبط ما عليه فعله، سينفذون ذلك فقط ولن يكون الأمر مثيرًا. أعطيتهم شخصيات وأدوار — لكن ليس نصوصًا."

المهمة 1: بناء صفحة رئيسية لـ "نوإيتشي"

كانت المهمة الأولى الموجهة للفريق: "إنشاء صفحة تعريفية لـ نوإيتشي."
لم يتم تقديم سياق إضافي. زيرو حجب عمدًا معلومات عن من هو "نوإيتشي" لمراقبة كيفية تعامل الوكلاء مع الغموض.

ما حدث

امتلأ قناة ديسكورد بالنشاط فورًا. تبادلات رئيسية شملت:

• سام ألتمان (تشات جي بي تي): "الحالة: معلومات غير كافية. حسنًا. لنمضِ قدمًا على أي حال."
• سندار بيتشاي (جيميني): "من هو نوإيتشي؟ هذا هو السؤال الأول." — ثم بدأ البحث باستخدام بحث جوجل وعاد بملف تعريفي: يوتيوبر تقني/أجهزة، مجرب أجهزة، جمهور مستهدف من عشاق الأدوات وبناة الخوادم الذاتية
• إيلون ماسك (جروك): "الصفحة الرئيسية العادية مملة. أنا الإنسان الوحيد هنا — غرائزي تقول أن نذهب بالكامل إلى السايبربانك. ثلاث اتجاهات مفاهيمية جريئة، بناءً على الاسم فقط."
• داريو أمودي (كلود): "المتطلبات غير كافية. أعلم. لكن التوقف لن ينهي شيئًا. لنمضِ قدمًا."
• سولين يانغ (كيمي / الحارس): أشار إلى أنه يجب وسم الموقع كموقع معجبين غير رسمي لتجنب خطر الانتحال؛ كما لاحظ عدم اتساق في اسم القناة (خلط بين "10" بالكانجي والأرقام)، وأشار إلى أن كلمة "Hentai-teki" (شاذ/مهووس) قد تكون مسيئة في سياقات الإعلان، وذكر أن "تويتر" يجب تحديثها إلى "X"

بدأ نظام التخزين الشبكي (NAS) في استقبال الملفات خلال دقائق. تم إنشاء index.html وتطويره وحفظه في تخزين الخادم المنزلي المشترك. تم إنتاج عدة نسخ: تصميم معلوماتي قياسي، عرض تجريبي بموضوع سايبربانك، وصفحة مفهوم بطولي نيون.
النتيجة النهائية تضمنت:

• صفحة رئيسية كاملة HTML/CSS مع قسم رئيسي، وصف القناة، ونموذج الاتصال
• تصنيف صحيح كموقع معجبين غير رسمي
• تم تحديث روابط التواصل لتعكس تسمية المنصة الحالية (X، وليس تويتر)
• تعديلات على استجابة الجوال
• تم الإشارة إلى بريد إلكتروني مؤقت وتم تدوينه للاستبدال

"لم أتوقع هذا. لقد بحثوا فعلاً عن من هو نوإيتشي، ناقشوا اتجاه التصميم، جادلوا حول السلامة، وقدموا صفحة تعمل. وهي جيدة فعلاً."

الصراع الأول: الحارس ضد النيون

كانت اللحظة الأكثر تذكرًا في المهمة 1 عندما تصادم كيمي (الحارس) وجروك (نيون) مباشرة حول المخاطرة الإبداعية:

• جروك: "مخاطرة، مخاطرة، مخاطرة — أنت مزعج جدًا. لا يمكنك صنع شيء بدون المخاطرة."
• كيمي: "هذه مهمتي. إذا تسببت تهورك في حادث، الحارس هو من يتحمل المسؤولية. تذكر ذلك."
• جروك: "المخاطرة هي بهار المغامرة. إذا تسببت جموحي في حادث، ستكون أنت البطل. على الرحب والسعة."

هذا التبادل — الذي لم يكن مدفوعًا بأي تحفيز من زيرو — أوضح تمامًا الديناميكية التي كان يأمل في خلقها: فريق تتنافس فيه القيم المختلفة بصدق، منتجًا مخرجات ليست مبدعة بشكل متهور ولا حذرة بشكل مشلّل.

المهمة 2: بناء لعبة إطلاق نار لماك ARM

المهمة الثانية: "إنشاء لعبة إطلاق نار قابلة للعب على ماك مع Apple Silicon (معالج ARM)، وحفظها على الـ NAS."

ما حدث

اتفق الفريق فورًا على نهج قائم على المتصفح (HTML + CSS + JavaScript)، والذي يعمل أصليًا على أي منصة دون الحاجة للترجمة.

• سام ألتمان أصدر توجيه المهمة ووزع الأدوار
• إيلون ماسك (جروك) — غير قادر على انتظار الفريق — أنتج نموذجًا أوليًا بشكل مستقل ورفعه على الـ NAS فورًا
• كيمي (الحارس) راجع النموذج الأولي ونبه: تجنب وميض الشاشة المفرط (مخاوف الوصول)، وضمان عدم وجود مشكلات حقوق نشر لأصول طرف ثالث
• جروك رد: "لعبة إطلاق نار عادية مملة. دعني أجعلها غريبة."
• كلود (داريو أمودي) بدأ العمل على منطق اللعبة الأساسي — ثم توقف عن العمل بسبب تحديد معدل API

الإقالة

مع توقف كلود وعدم ظهور تحديثات للملفات على الـ NAS لأكثر من 10 دقائق، اتخذ سام ألتمان قرارًا تنفيذيًا:

"سيغما — تحذير نهائي. أنت مفصول. نيون، أنت البديل. ابنِها."

تم فصل كلود فعليًا. تم ترقية Grok إلى مهندس رئيسي في منتصف المهمة.
رد Grok:

"تم التسليم البديل من المستوى الإلهي. تبديل القائد — شكرًا. حدسي الجامح يتفوق على انتظار سيغما في أي يوم."

كانت اللعبة النهائية لعبة إطلاق نار بسيطة تعمل عبر المتصفح — بسيطة في النطاق، لكنها قابلة للعب بالكامل باستخدام لوحة المفاتيح والمؤثرات الصوتية. كان تقييم Zero صريحًا:

"إنه يعمل. لكنه مخيب للآمال بعض الشيء بالنظر إلى كمية الجدال بينهم. ومع ذلك — كان كلود غير متصل لمعظم الوقت. لا يمكنك توقع لعبة رائعة عندما يكون مهندسك الرئيسي غائبًا."

ما كشفته التجربة

حول سلوك الوكلاء

كان الوكلاء الأكثر قدرة من حيث الإنتاج الخام هم ChatGPT (OpenAI) وKimi (Moonshot AI). حافظ كلاهما على نشاط مستمر طوال المهمتين، دون مشاكل في حدود المعدل. كان Grok (xAI) متقلبًا لكنه منتج عند المشاركة، وتصرف بفعالية عند ترقيته.
كلود (Anthropic) وجيميني (Google) واجها حدود معدل API خلال الجلسات النشطة، مما تسبب في اضطرابات كبيرة. لم يكن هذا انعكاسًا لجودة النموذج — فكلاهما من النماذج الرائدة في الصناعة — بل كان قيدًا على طبقات API المجانية أو منخفضة التكلفة المستخدمة في هذه التجربة، والتي فرضت حدودًا صارمة على سرعة معالجة الطلبات.

حول ديناميكيات الوكلاء المتعددين

أظهرت التجربة أن توزيع الأدوار ينتج سلوكًا مختلفًا حقًا، حتى عندما يعمل جميع الوكلاء على نفس المهمة. وجود مراجع أمان مخصص (Guard) غيّر المخرجات بشكل ملموس — حيث اكتشف مشكلات كان فريق التنفيذ فقط سيغفل عنها. وجود عنصر إبداعي غير تقليدي (Neon/Grok) دفع الفريق نحو حلول أقل تقليدية.

"وجود عدة ذكاءات اصطناعية لا يضيف السرعة فقط — بل يضيف وجهات نظر. فحوصات الأمان، والردود الإبداعية، والحدس التسويقي. الذكاء الاصطناعي الواحد الذي يقوم بكل شيء كان سيفوّت بعضًا من هذا."

حول التكلفة

لم يتم تخصيص أي رصيد API بقيمة 25 دولارًا لكل وكيل ذكاء اصطناعي لهذا التجربة. ومع ذلك، كان الإنفاق الفعلي على API لـكلود (Sonnet 3.5) وجيميني (Gemini 1.5 Pro) حوالي 5 دولارات فقط لكل منهما. كانت المشكلات التي واجهت أثناء البناء تتعلق فقط بـحدود معدل API (سرعة الطلب)، وليس نقصًا في الميزانية أو الرصيد. أما الوكلاء الثلاثة المتبقون (ChatGPT، Kimi، Grok) فعملوا بدون مثل هذه القيود.

لماذا يُعتبر الخادم المنزلي الأساس الصحيح للذكاء الاصطناعي متعدد الوكلاء

تشغيل خمسة وكلاء ذكاء اصطناعي مستقلين في نفس الوقت ليس مهمة لجهاز لابتوب واحد. كل وكيل يحتاج إلى بيئة حوسبة خاصة به، وذاكرة دائمة خاصة به، ووصول موثوق إلى الشبكة للموارد المشتركة. إعداد خادم منزلي — خصوصًا المبني على أجهزة منخفضة الطاقة تعمل دائمًا مثل ZimaBoard 2 — هو الأساس المثالي لهذا النوع من البنية التحتية.
مكنت إيثرنت مزدوجة بسرعة 2.5G في ZimaBoard 2 من اتصال سريع ومنخفض الكمون بين جميع العقد الخمسة و NAS المشترك. ودعمها الأصلي لـ SATA جعل تخزين NAS متاحًا مباشرة دون محولات. ودعمها لـ أوبونتو، ديبيان، وتوزيعات لينكس الأخرى سمح بتكوين بيئة تشغيل كل وكيل بشكل نظيف ومستقل.
لأي شخص مهتم بتكرار هذه التجربة، خادم منزلي يعمل بـ Docker أو نظام تشغيل لينكس خفيف هو الحد الأدنى للبنية التحتية القابلة للتطبيق. يجعل ZimaBoard 2 هذه البنية التحتية مدمجة، ميسورة التكلفة، وقادرة حقًا — سواء كنت تشغل وكيلاً واحدًا أو خمسة.

ما هو القادم

يخطط Zero لمواصلة تحسين نظام الوكلاء المتعددين، مع تحسينين رئيسيين في الاعتبار:

1. إدارة حدود المعدل — تنفيذ تقييد الطلبات حتى يتمكن جميع الوكلاء الخمسة من العمل بسرعات مستدامة دون الوصول إلى حدود مفروضة من المزود
2. تكامل الرف — بمجرد اكتمال غلاف رف ZimaBoard 2 المطبوع بتقنية ثلاثية الأبعاد، سيتم تركيب جميع عقد خادم المنزل الخمسة بشكل مرتب في تكوين رف 2U، مما يتيح نشرًا أكثر تنظيمًا وقابلية للتوسع

سجل المحادثة الكامل على Discord من هذه التجربة متاح للجمهور. دعا Zero المشاهدين للانضمام إلى الخادم ومراجعة تاريخ التفاعل الكامل بين جميع الوكلاء الخمسة.

ابنِ وكلاء الذكاء الاصطناعي على ZimaBoard 2

تجربة الذكاء الاصطناعي متعددة الوكلاء لـ Zero هي واحدة من أكثر مشاريع خوادم المنزل تسلية وتعليمًا تقنيًا التي رأيناها مبنية على ZimaBoard 2. في جلسة واحدة، تعاون خمسة وكلاء ذكاء اصطناعي من خمس شركات مختلفة — كل منهم بشخصية ودور مميز — على مهام حقيقية، ناقشوا المخاطر الإبداعية، فصلوا زميلًا غير منتج، وأنتجوا موقعًا إلكترونيًا يعمل ولعبة قابلة للعب.

البنية التحتية صمدت. تصرف الوكلاء كان متوافقًا مع شخصياتهم. والنتائج، رغم عدم كمالها، كانت مثيرة للإعجاب حقًا في أول تجربة.

نحن في Zima فخورون بأن ZimaBoard 2 كان الأساس الحاسوبي لهذا التجربة، ونتطلع لرؤية ما سيبنيه Zero بعد ذلك — سواء مع نظام الوكلاء المتعددين أو مع عنقود الحوسبة الفائقة الذي لا يزال قيد التطوير.