An Empirical Study of Coordination Mode as the First-Class Citizen in From-Scratch Multi-Agent Coding
تقدم هذه الورقة MSEval، وهو معيار مرجعي صارم للبرمجة متعددة الوكلاء من الصفر، يستخدم مشاريع واقعية كاملة البنية وإطار تقييم آلي لإثبات أن الهيكل التنظيمي يؤثر بشكل كبير على مقايضات السرعة والتكلفة والجودة، وغالبًا ما يضاهي في أهميته قدرة النموذج نفسه.
المؤلفون الأصليون:Yanyu Ren, Yunfeng Bai, Xizheng Wang, Li Chen, Dan Li
تخيل عالماً لا يكون فيه بناء البرمجيات وظيفة منعزلة لمبرمج عبقري واحد، بل موقع بناء صاخب تديره مجموعة من العمال الرقميين. هذا هو مجال الأنظمة متعددة الوكلاء (Multi-Agent Systems)، حيث لا يكتفي الذكاء الاصطنا-عي بكتابة سطر واحد من الكود، بل يتعاون لبناء تطبيقات كاملة من الصال إلى الصفر. فكر في الأمر كأنها مجموعة من الأصدقاء يحاولون بناء بيت فوق شجرة: قد يقوم أحدهم بتصميم المخططات، والآخر يقطع الخشب، والثالث يدهن الجدران. لكن هنا تكمن المشكلة: إذا لم يتحدثوا مع بعضهم البعض، أو إذا تشاجروا حول من يملك المطرقة، فقد ينتهي الأمر ببيت الشجرة مائلاً، أو غير مكتمل، أو ينهار تماماً. لفترة طويلة، اختبر العلماء هذه الفرق من الذكاء الاصطناعي عبر سؤال: "هل يمكن لوكيل واحد إصلاح لعبة مكسورة؟" لكن العالم الحقيقي أكثر تعقيداً؛ فهو يسأل: "هل يمكن لفريق كامل بناء ناطحة سحاب، والتعامل مع الخلافات، والانتهاء في الوقت المحدد دون نفاذ المال؟" هذا هو السؤال الكبير الذي يعالجه الباحثون الآن: كيف نقيس ما إذا كان فريق من وكلاء الذكاء الاصطنا-عي يمكنه العمل معاً بالفعل لإنشاء برمجيات حقيقية، بدلاً من مجرد التظاهر بذلك؟
إليك MSEval، وهو "صالة ألعاب رياضية" جديدة لاختبار فرق الذكاء الاصطنا-عي، أنشأها باحثون من جامعة تسينغوا ومختبر زونغ غوان تشون. بدلاً من إعطاء فرق الذكاء الاصطنا-عي مخططاً جاهزاً يحدد كل مسمار بدقة، يقدم لهم MSEval فكرة عامة — مثل ورقة واجب مدرسي — ويراقبهم وهم يبنون تطبيق ويب متكامل من الصفر. أجرى الباحثون تجربة ضخمة شملت 100 سيناريو مختلف، مزجت بين 10 مشاريع من العالم الحقيقي (مثل منصة تعليم بالبث المباشر أو تطبيق مراسلة فورية) و10 طرق مختلفة لتنظيم فريق الذكاء الاصطنا-عي. عملت بعض الفرق مثل خط تجميع صارم، حيث يتم تمرير العمل عبر سلسلة؛ بينما عملت فرق أخرى مثل سرب النحل، تلتقط المهام كما تراه مناسباً؛ وبعضها كان لديه "مدير" ذكاء اصطنا-عي يراقب الجميع، بينما سمحت فرق أخرى للوكلاء بالتنافس ضد بعضهم البعض.
لم يكتف الفريق بمراقبة ما إذا كان التطبيق النهائي يعمل فحسب؛ بل قاموا بقياس كل شيء. تتبعوا الوقت المستغرق (وقت الجدار)، والتكلفة بالعملة الرقمية (التوكنز)، وعدد المرات التي اضطر فيها الذكاء الاصطنا-عي لإصلاح أخطائه. استخدموا مصححاً آلياً خاصاً يسمى TAgent، والذي يعمل كمساعد تدريس صارم للغاية. لا يكتفي TAgent بقراءة الكود فحسب؛ بل يزور الموقع الإلكتروني الحي فعلياً، وينقر على الأزرار، ويتأكد من عمل تسجيل الدخول، ويفحص الكود بحثاً عن الثغرات الأمنية الخفية. ثم يقدم ملاحظات محددة للفريق، مثل: "ميزة الدردرة الخاصة بك تعمل، لكنك نسيت حفظ الرسائل"، مما يسمح للفريق بالمحاولة مرة أخرى.
كانت النتائج مثيرة للانتباه. وجدت الدراسة أن طريقة تنظيم الفريق تهم بقدر أهمية ذكاء نماذج الذكاء الاصطنا-عي نفسها. في الواقع، تغيير "توبولوجيا" الفريق (هيكلهم التنظيمي) يمكن أن يغير النتيجة النهائية بأكثر من 30 نقطة ويضاعف الوقت اللازم للانتهاء. على سبيل المثال، غالباً ما أنتجت خطوط الأنابيب المنظمة، حيث يسلم الوكلاء العمل في مراحل واضحة، أعلى جودة من النتائج وبسرعة أكبر. وفي المقابل، فإن الفرق ذات الإشراف الإداري الثقيل أو "التعشية" الفوضوية غالباً ما تتعثر، وتضيع الوقت والمال في النقاشات أو تكرار العمل. ومن المثير للاهتمام أن الباحثين اكتشفوا أن مجرد امتلاك نماذج ذكاء اصطنا-عي أكثر قوة لا يضمن النجاح؛ فنموذج أقل قوة قليًلاً مع هيكل فريق أفضل غالباً ما يتفوق على نموذج فائق الذكاء مع فريق مشتت.
كما كشفت الورقة البحثية أن فرق الذكاء الاصطنا-عي هذه نادراً ما "تنهار" تماماً. بدلاً من ذلك، غالباً ما تبني نظاماً يعمل ولكنه غير مكتمل. لم تكن حالات الفشل الأكثر شيوعاً هي الأخطاء الكارثية، بل كانت ميزات مفقودة أو فجوات منطقية — مثل باب يفتح ولكنه لا يُقفل. تشير الدراسة إلى أنه لكي تكون فرق الذكاء الاصطنا-عي مفيدة حقاً في المستقبل، نحتاج إلى معاملة أسلوب تعاونها كأداة مرنة. لا ينبغي لنا فقط اختيار الذكاء الاصطنا-ئي "الأذكى" والأمل في الأفضل؛ بل نحتاج إلى تصميم كيفية تواصلهم، ومن يملك أي جزء من المشروع، ومتى يجب التوقف والإصلاح. يثبت MSEval أنه في سباق بناء البرمجيات، ليس "السر الخفي" هو الذكاء الخام فحسب؛ بل هو فن التنسيق.
ملخص تقني: دراسة تجريبية لاعتبار نمط التنسيق كعنصر أساسي في البرمجة متعددة الوكلاء من الصفر
بيان المشكلة
تعاني التقييمات الحالية لأنظمة البرمجة متعددة الوكلاء من ثلاثة عيوب رئيسية:
البيئات الاصطناعية: تعتمد الاختبارات المرجعية الحالية غالبًا على مهام مصطنعة تتجاهل القيود العملية مثل الوقت والتكاليف المالية.
الخلط بين الاستدلال والتواصل: تفشل كثيرًا في التمييز بين قدرات الاستدلال للوكيل وكفاءة بروتوكولات التواصل الخاصة به.
المقاييس السطحية: تكافئ التقييمات غالبًا المخرجات النهائية أو "نجاح المحاولة الأولى" فقط، متجاهلة العملية التكرارية لتقسيم العمل، والنشر، والتحسين بناءً على التغذية الراجعة الملموسة.
علاوة على ذلك، بينما تقدمت وكلاء البرمجة في الخطوط الأمامية من تركيب الدوال إلى العمل على مستوى المستودعات (repositories)، لا تزال معظم الاختبارات المرجعية تقيم سلوكيات الإصلاح لوكيل واحد. إنها لا تقيس كيف يتعاون فريق من الوكلاء لبناء نظام كامل من الببنية التحتية (full-stack) من الصفر، وإدارة عمليات التسليم (handoffs)، والوصول إلى حل تحت ميزانية محددة من الوقت والرموز (tokens). الاختبارات المرجعية متعددة الوكلاء الحالية (مثل AgentsNet و CloudDevBench) غالبًا ما تكون مجردة للغاية، ومنفصلة عن التكامل المستمر/النشر المستمر (CI/CD)، أو تعتمد على واجهات برمجة تطبيقات (APIs) محددة مسبقًا مما يقلل من طبيعة المهام "من الصفر".
المنهجية: إطار عمل MSEval
يقدم المؤلفون MSEval، وهو اختبار مرجعي مصمم للتقييم الكمي لـ "برمجة الأجواء" (vibe coding) متعددة الوكلاء في مهام برمجية واقعية. يستند إطار العمل إلى بيئة هندسة برمجيات جامعية حيث تقوم فرق من 3 إلى 4 مطورين ببناء مشاريع كاملة البنية بشكل تكراري.
المكونات الأساسية
مجموعة البيانات (10 مشاريع واقعية):
تم اختيارها من مشاريع التخرج الجامعية (من 2018 إلى الوقت الحاضر).
تغطي 10 مجالات: المراسلة في الوقت الفعلي، إدارة الأصول المؤسسية، التعهيد الجماعي، تتبع المتطلبات، معالجة الصور، التجارة الإلكترونية، تحليلات المبدعين، التحكم في الوصول القائم على الأدوار (RBAC)، البحث الإخباري، والتدريس المباشر عبر الإنترنت.
تم تفكيك كل مشروع إلى 6-8 وحدات (modules) و30-45 بندًا موزونًا، يتم تطبيعها إلى مقياس تقييم حتمي من 100 نقطة.
محرك التنفيذ: LegoGent:
بيئة تشغيل تقوم بإنشاء أنماط تعاون ذات تزامن محدود.
الآلية: يعمل الوكلاء بالتزامن في مساحة عمل مشتركة. تقوم حلقة مزامنة دورية (كل 4 دقائق) بجمع لقطات التقدم وبثها. كما يدعم صندوق البريد النشط الأسئلة الموجهة بين الأقراء خلال فترات ما بين المزامنة.
النشر: يتم تجهيز المستودعات المولدة عبر خط أنابيب CI/CD أصيل (GitLab + SonarQube) باستخدام XDeploy. ويُعامل فشل النشر كمخرج مُقاس، وليس مجرد عدم اكتمال الكود.
الأنماط: ينفذ 10 طوبولوجيات تعاون متميزة، تشمل:
فرق الميزات (Feature Squads): التوازي حسب الوحدة المواجهة للمستخدم.
متخصصو الطبقات (Layer Specialists): التوازي حسب طبقات الواجهة الأمامية/الخلفية، مع التزامن عند عقود الـ API.
العملية: يقوم بتحليل وثائق المتطلبات إلى فحوصات موزونة. ويكتشف سطح التنفيذ (واجهة المستخدم، API، الكود) قبل البدء بالفحص.
تدفقات التقييم:
واجهة المستخدم (UI): يستخدم Playwright لتشغيل المواقع الحية، وفحص أشجار الوصول (accessibility trees) و DOM.
الـ API: يفحص OpenAPI/Swagger أو يعيد بناء المسارات من ملفات المصدر.
الكود: يتحقق من القيود الداخلية (مثل تشفير كلمة المرور) عبر فحص النماذج اللغوية الكبيرة (LLM).
التغذية الراجعة: يولد أدلة على مستوى البند (حالة UI، استجابة API، موقع الكود) بدلاً من درجة عددية فقط، مما يسمح بأجندات إصلاح مرتبة في الجولات اللاحقة.
التوازي: يستخدم رسمًا بيئيًا للمهام (DAG) وبرمجة صحيحة لتقليل زمن التنفيذ (makespan) وتكرار إعداد الحالة لواجهات المستخدم.
التصميم التجريبي:
الشبكة: 10 مشاريع × 10 أنماط تعاون = 100 تكوين.
التكرارات: ما يصل إلى 3 جولات تحسين (بناء ← نشر ← تقييم ← تغذية راجعة).
المقاييس: درجة الاكتمال الوظيفي (0–100)، زمن الانتظار الفعلي (wall-clock latency)، التكلفة بالدولار الأمريكي، واستخدام الرموز (التي تم تخزينها مسبقًا والجديدة).
المساهمات الرئيسية
الاختبار المرجعي MSEval: شبكة من 100 حالة لتقييم البرمجة متعددة الوكلاء عبر مشاريع واقعية وأنماط تعاون متنوعة، مع إصدار جميع المواصفات والكود ونصوص التحليل.
بيئة تشغيل LegoGent: بيئة تشغيل متعددة الوكلاء مدفوعة بالنشاط، تتميز بتزامن محدود، ورسائل صريحة بين الأقراء، والتحقق من نشر CI/CD.
الدراسة التجريبية: تحليل شامل يوضح أن الطوبولوجيا التنظيمية هي المحدد الرئيسي للمقايضة بين السرعة والتكلفة والجودة، وغالبًا ما تضاهي تأثير قدرة النموذج.
النتائج
قيمت الدراسة نماذج متعددة (Claude Opus 4.8, GPT-5.5, DeepSeek v4 Flash/Pro, GLM-5.2, Qwen3.6-Flash) عبر الأنماط العشرة.
الطوبولوجيا مقابل قدرة النموذج: تؤثر الطوبولوجيا التنظيمية بشكل كبير على الأداء. بالنسبة لنفس المهام والنماذج، أدى تغيير الطوبولوجيا إلى تغيير الدرجات بأكثر من 30 نقطة ومضاعفة وقت الانتظار في بعض الحالات.
خطوط الأنابيب المنظمة: حققت أسرع تقارب بجودة عالية.
الإشراف الثقيل (PM): أدى غالبًا إلى تدهور الأداء بسبب الاختناقات.
المصدر المفتوح/العدائي: أظهر مكاسب كبيرة في الجولات المتأخرة لكنه بدأ بدرجات أولية أقل.
أداء النماذج:
Claude Opus 4.8: حقق أعلى الدرجات (مثلاً 97 في نظام IM) ولكن بتكلفة عالية (654 دولارًا) ووقت طويل (110 دقائق).
GPT-5.5: حقق درجات مقاربة (96) بتكلفة أقل بكثير (138 دولارًا) ووقت أقل (74 دقيقة).
GLM-5.2: وصل إلى أعلى متوسط درجة عبر الشبكة الكاملة ولكنه كان الأبطأ والأعلى تكلفة.
DeepSeek v4 Pro: شكل خط أساس قوي مع أداء مستقر عبر الأنماط.
ديناميكيات التحسين:
أظهرت 82.0% من الانتقالات بين الجولات تحسنًا في الدرجات؛ و94.7% من التشغيلات أنهت الجولة الثالثة بدرجة أعلى من الجولة الأولى.
التراجع (Regression): نمط فشل متميز حيث يؤدي إصلاح متطلب واحد إلى كسر متطلب آخر (مثلاً، شهدت تشغيلات إشراف PM في أنظمة IM انخفاضًا في الدرجات من 80.9 إلى 66.0 في الجولة الثالثة).
تصنيف الفشل:
النقص الوظيفي: هيمن على حالات الفشل (56% من الفحوصات)، وتحديدًا الميزات المفقودة (23.8%) والمنطق غير المكتمل/الحالات الحدية (32.2%).
تسلسل المتطلبات المسبقة: تسببت إخفاقات المصادقة أو الأذونات (23% من حالات الفشل) في جعل الفحوصات اللاحقة غير قابلة للاختبار، مما يسلط الضوء على هشاشة عقود تعدد الوكلاء.
مشكلات التكامل: كانت مشكلات الأمن والنقل (8.5%) متكررة بسبب تحديات التكامل مع CI/CD، وليس بالضرورة بسبب أخطاء برمجية.
الأهمية والادعاءات
يزعم البحث أن نمط التنسيق هو "عنصر أساسي" في البرمجة متعددة الوكلاء، مما يعني أن الطوبولوجيا التنظيمية لا تقل أهمية عن اختيار النموذج الأساسي.
مقايضات قابلة للقياس: يضع MSEval معيارًا صارمًا لقياس المقايضة بين السرعة والتكلفة والجودة، كاشفًا أن "التوازي" لا يقلل دائمًا الوقت أو التكلفة؛ بل يمكن أن يخلق سياقات مكررة وتضاربات في الدمج إذا لم يُدر بواسطة طوبولوجيا واضحة.
ما وراء لوحات الصدارة: ينقل هذا الاختبار المرجعي التركيز من "أفضل منتج" واحد إلى دورة تسليم البرمجيات بأكملها، مما يجعل تأثير سياسات التعاون (مثل: من يملك المخرجات، وكيف تتم عمليات التسليم) أمرًا قابلًا للقياس.
الآثار العملية: تشير النتائج إلى أن أنظمة الوكلاء المستقبلية يجب أن تعامل نمط التعاون، واختيار النموذج، وسياسات التوقف كقرارات وقت التشغيل (runtime decisions) وليست إعدادات افتراضية ثابتة. "النموذج الأفضل" ليس متفوقًا عالميًا؛ بل يعتمد الخيار الأمثل على الطوبोलॉजी المحددة وقيود الميزانية.
يخلص المؤلفون إلى أنه بينما يمكن للنماذج اللغوية الكبيرة الحديثة بناء برمجيات ضخمة، فإن نجاحها يتشكل بقوة من خلال التنسيق، ويجب أن تتطور طرق التقييم الحالية لاستيعاب هذه الديناميكيات النظامية.