ماذا يحدث عندما يعمل 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

$949.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: بناء صفحة رئيسية لـ "نوإيتشي"

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

ما حدث

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

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

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

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

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

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

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

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

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

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

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

ما حدث

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

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

الإقالة

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

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

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

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

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

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

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

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

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

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

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

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

حول التكلفة

لم يتم تخصيص أي مبلغ 25 دولارًا لكل وكيل ذكاء اصطناعي في أرصدة API لهذا التجربة. ومع ذلك، كان الإنفاق الفعلي على 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 بعد ذلك — سواء مع نظام الوكلاء المتعددين أو مع عنقود الحوسبة الفائقة الذي لا يزال قيد التنفيذ.