128 وكيل ذكاء اصطناعي بلا قائد اجتازوا اختبارات أكثر بنسبة 49% من وكيل واحد

اختبر باحثو Microsoft Research ما سيحدث إذا أُعطيت مجموعة كبيرة من وكلاء الذكاء الاصطناعي مهمة واحدة دون تعيين وكيل رئيسي. في الورقة البحثية الأولية Agensh، أعادت ما يصل إلى 1024 نسخة من نموذج لغوي واحد إنتاج سلوك برامج جاهزة طوال ست ساعات متواصلة. لم يكن هناك مدير ولا قائد فريق ولا توزيع للمهام الفرعية، وكانت التعليمات تقول فقط: «الجميع متساوون، وكل وكيل يقرر بنفسه».

قيست النتيجة باختبار ProgramBench: يُعطى الوكيل ملفاً تنفيذياً يعمل ووثائقه، ولا يجوز له الاطلاع على الشيفرة المصدرية ولا تفكيك الملف، ولا يتوافر له اتصال بالإنترنت. عليه أن يكتب من الصفر شيفرة تتصرف بالطريقة نفسها، وتقيس اختبارات مخفية عدد الحالات التي يعيد إنتاجها. اجتاز الوكيل المنفرد في المتوسط، عبر خمس مهام صعبة، 19,31% من الاختبارات، أما سرب الـ128 فاجتاز 28,78%.

الزيادة 9,47 نقطة مئوية، أي نحو 49% بالقيمة النسبية.

لماذا أُلغي الوكيل الرئيسي

يقتصر الوكيل المنفرد على نافذة سياق واحدة وذاكرة واحدة ومسار عمل واحد، ولذلك يستغرق وقتاً طويلاً في المهام الكبيرة. والحل المعتاد هو التسلسل الهرمي: يحلل وكيل رئيسي المهمة ويوزع أجزاءها على المنفذين. هكذا صُممت الوكلاء الفرعية في Codex وClaude Code، وCopilot fleet وKimi Agent Swarm. لكن كلما زاد عدد المنفذين، زاد الوقت الذي ينفقه الوكيل الرئيسي في التخطيط والتنسيق ودمج عمل الآخرين، فيتحول هو نفسه إلى عنق زجاجة.

وفي النظام البحثي لدى Anthropic، يشغّل الوكيل القائد وكلاءً فرعيين بشكل متزامن وينتظر كل مجموعة. التنسيق بهذه الطريقة أبسط، لكن الوكلاء الفرعيين لا يستطيعون التفاهم فيما بينهم، ويتوقف النظام كله ما دام أحدهم لم ينهِ بحثه. أما Agensh فيلغي المركز بالكامل.

والخبرة في الأسراب المتكافئة ما تزال متواضعة. ففي أغسطس شغّل فريق Frontier Red Team في Anthropic من 10 إلى 80 وكيلاً لمدة 12 ساعة لإنشاء لعبة. كانت النماذج الأولى ضعيفة في دمج التعديلات، وتجنبت النماذج اللاحقة التعارضات بالعمل منفردة. ولم تغيّر الأدوار ولا «المدير» المعيَّن في التعليمات شيئاً يُذكر. في المقابل، في فبراير 2026 كلّف نيكولاس كارليني 16 وكيل Claude بكتابة مترجم للغة C بلغة Rust، مع مستودع git مشترك وأقفال نصية. وخلال أسبوعين وبتكلفة نحو 20 000 دولار، خرج مترجم من 100 ألف سطر قادر على بناء Linux 6.9. وتستعير Agensh لوحة الملاحظات من دراسة DeLM الصادرة عن ستانفورد، وتضيف من عندها منصة مراسلة.

دورة من خمس خطوات ولوحة للملاحظات القصيرة

يعمل جميع الوكلاء في وقت واحد ويكررون دورة واحدة مكتوبة في التعليمات بالكلمات، وليست مضمّنة في الشيفرة:

• جمع السياق: الهدف، وحالة المستودع، ورسائل الزملاء واكتشافاتهم؛ • اختيار مهمة: الإعلان بسجل CLAIM عمّا ستتولاه، ليختار الآخرون غيره؛ • التنفيذ: كتابة الشيفرة ومشاركة ما يفيد أثناء العمل؛ • التحقق: مطابقة النتيجة مع معايير القبول وإعادة العمل عند وجود اختلاف؛ • الدمج: دمج التغييرات في الفرع المشترك ووصف ما تغيّر ولماذا وما الذي يثبته.

التعليمات واحدة لدى الجميع، ولا يختلف سوى رقم الوكيل. وتعمل ثلاث خدمات مشتركة: مستودع على Gitea، وقناة عامة ورسائل خاصة في Mattermost (تصل الرسالة الخاصة إلى الوكيل في منتصف خطوته مباشرة)، ولوحة السياق. وتضم اللوحة خمسة أنواع من السجلات: OBSERVED — سلوك لوحظ، وFACT — حقيقة مؤكدة، وFAIL — فرضية دُحضت، وCLAIM — طلب مهمة، وPATCH_SUMMARY — وصف تعديل جاهز. ويقتصر السجل على 100 رمز (وPATCH_SUMMARY على 300)، وتذهب التفاصيل إلى حقل منفصل. وتصف التعليمات سجل FAIL بأنه الأثمن، لأنه يوفر على الآخرين إهدار الميزانية في طريق مسدود.

من بين 200 مهمة في ProgramBench، اختير أصعب خمس: معالجة الفيديو والصوت (FFmpeg)، والنمذجة الجزيئية (gromacs)، ومحوّل المستندات (pandoc)، ومفسّر لغة (PHP)، وفهرس للشيفرة (ctags). وعمل في جميع المهام GPT-5.6-sol بمستوى استدلال مرتفع بالاقتران مع Copilot. وُزعت مجموعة الـ1024 وكيلاً على 16 خادماً بواقع 64 على كل خادم، وجرى تشغيلها تدريجياً: وكيل واحد كل 30 ثانية في الساعة الأولى، ثم وكيل كل ثلاث ثوانٍ.

أدوار لم يعيّنها أحد، وتحفظات

متوسط نسبة الاختبارات المجتازة: 19,31% لوكيل واحد، و20,68% لثمانية، و26,52% لـ32، و28,78% لـ128. والزيادة غير متساوية: من وكيل إلى ثمانية +1,37 نقطة، ومن ثمانية إلى 32 +5,84، ومن 32 إلى 128 +2,26. وعلى pandoc تجاوز 128 وكيلاً نسبة 30% من الاختبارات في الدقيقة الثلاثين، و32 وكيلاً مع الساعة الأولى، وثمانية مع الساعة والنصف. أما الوكيل المنفرد فلم يبلغ العتبة في ساعتين. وشُغّل ألف وكيل على pandoc فقط: 33,89% لوكيل واحد، و50,94% لـ128، و55,06% لـ1024.

تغيّر سلوك السرب مع حجمه رغم أن التعليمات واحدة:

• ثمانية وكلاء يتفقون على واجهة الوحدة ويكتبون الأجزاء بالتوازي؛ وفي FFmpeg بدّل أحد الوكلاء مهمته بعد محادثة كي لا يكرر عمل غيره؛ • نحو 30 وكيلاً يبدؤون مراجعة بعضهم بعضاً: في PHP أُقرّ تعديل، ثم وجد وكيل آخر مثالاً مضاداً فسُحبت الموافقة، وأصلح المؤلف الخطأ، ودُمج التعديل في المحاولة الثانية؛ • عند 128 يظهر التخصص: يختار الوكلاء المراجعين بحسب خبراتهم، وفي pandoc ابتكر وكيلان بروتوكولاً يعتمد على تجزئة الإيداع (commit hash) وتبناه آخرون؛ • عند الألف تظهر وكلاء مُدمِجون: يرسل مؤلف التعديل طلباً إلى عدة مرشحين، ويأخذ أول من يرد، ويلغي بقية الطلبات.

الأدوار قابلة للتبادل، ولذلك لا يوقف انسحاب أحد الوكلاء العمل.

التحفظات كثيرة. لم تُذكر تكلفة التشغيلات، والانتقال من 128 إلى 1024 وكيلاً على pandoc أضاف +4,12 نقطة فقط بعد +17,05 في أول 128. وشُغّل الألف وكيل على مهمة واحدة من خمس. أما عدد المرات التي تعاون فيها الوكلاء فعلاً فغير معروف، فالأمثلة مأخوذة من سجلات العمل. والأهم أن السرب قورن بوكيل منفرد، لا بسرب يديره وكيل رئيسي، ولذلك فإن القول بأن «غياب المركز أفضل» غير مثبت.

الخلاصة العملية: يناسب هذا النهج الحالات التي يوجد فيها حَكَم خارجي. ففي ProgramBench هو البرنامج المرجعي والاختبارات المخفية، وفي مترجم كارليني هو الاختبارات ومترجم GCC المرجعي. أما في تجربة Anthropic مع اللعبة فلم يكن هناك حَكَم، ولم ينجح السرب. والبنية التحتية المطلوبة قليلة: Git ودردشة ولوحة ملاحظات. والبيانات لا تكفي للتبني الفعلي، لكنها تكفي لتجربة على مهمة صغيرة لها اختبارات جاهزة.