الخلاف المتعمد يجعل مراجعة الكود أكثر فعالية في الفرق متعددة الوكلاء الكبيرة

لماذا تتعثر فرق الوكلاء المتعددين الكبيرة

عندما بدأت نماذج اللغة الكبيرة (LLM) تُستخدم على نطاق واسع في التطوير، سلكت العديد من الفرق مسارًا منطقيًا لكنه ليس دائمًا عمليًا: جمع أكبر عدد ممكن من "المتخصصين" الخوارزميين وتوزيع الأدوار عليهم. واحد يكتب الكود، وآخر يبحث عن الثغرات، وثالث يتحقق من السيناريوهات. المشكلة أن كل وكيل جديد يحقق فائدة أقل: ففي المهام على مستوى المستودع بأكمله، سرعان ما تفوق تكاليف التنسيق المكسب من "الأيدي الإضافية".

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

نقطة التوازن: الحد الأدنى من التعاون

انشغل Eric S. Qiu و Joyce Gill بالبحث عن الحل الوسط في عمل «Adversarial Review: Structured Disagreement for Grounded Agentic Code Review» (arXiv:2608.18167، فئتا cs.AI وcs.SE؛ قُدم في 16 أغسطس 2026، وقُبل في ICML 2026 Workshop on DL4C). فرضيتهما بسيطة: يمكن الحفاظ على بساطة البنية الفرعية للوكلاء، مع إضافة حد أدنى من التعاون إليها — عقدة واحدة حيث تتصادم آراء الوكلاء عمدًا.

وكانت النتيجة بروتوكول Adversarial Review (AR). يتعمد المؤلفون عدم بناء تسلسل هرمي معقد أو تكثير الأدوار. بدلاً من ذلك، يعمل ثلاثة مشاركين:

• الوكيل المبرمج يجهز التغييرات في الكود؛
• المراجع يقيّم مدى صحة هذه التغييرات؛
• الناقد لا يدقق في الكود، بل في المراجعة نفسها ويجد نقاط ضعفها.

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

ماذا أظهرت التجارب

تأثير الخلاف واضح في نتائج المعايير.

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

على SWE-PRBench كان الأمر أكثر إثارة للاهتمام. كشفت النسخة الساذجة من البروتوكول بشكل غير متوقع عن نمط فشل أطلق عليه المؤلفون اسم الإجماع الزائف: كان الوكلاء يتوصلون إلى رأي مشترك دون وجود أدلة كافية لدعمه. أي أنه حتى الخلاف المُصمم خصيصًا يمكن أن يتدهور إلى "أوافق الجميع" الشكلي. يُعالج هذا الأمر بتكرار واحد من التلقين (prompt)، حيث يُنص صراحةً على شرط المجادلة وتبرير الاختلاف — وبعد هذا التحسين، احتل الأسلوب المركز الأول في مقياس F1.

أخيرًا، على SWE-bench Verified حسّن AR مرة أخرى نتائج الأساليب الأساسية. هذا مهم لأن المهام على مستوى المستودع تمثل نطاقًا مختلفًا تمامًا من التعقيد مقارنة بالدوال المعزولة: فالتغييرات في وحدة واحدة قد تكسر عشرات الوحدات المجاورة.

الخلاصة: القوة لا تأتي من عدد الأصوات، بل من حق الاعتراض

يصل المؤلفون إلى استنتاج غير بديهي لكنه مؤكد بالتجربة: مراجعة الكود الفعالة لا تتطلب فريقًا كبيرًا ولا مخططات تواصل معقدة. يكفي أن يكون الخلاف:

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

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