سير عمل مراجعة الشيفرة متعدد الوكلاء: مراجعان وكاتب نهائي واحد
أواجه باستمرار القيد نفسه عند استخدام عدة جلسات لبرمجة AI. من واقع تجربتي، تعثر الجلسات المتوازية على مسارات شيفرة مختلفة، لكن خلافاتها تبقى حبيسة سلاسل محادثات منفصلة. فأصبح أنا ناقل الرسائل، أنسخ مراجعة إلى جلسة أخرى وأقرر أي نموذج فهم الملف.
التصميم الأفضل هو سير عمل لمراجعة الشيفرة متعدد الوكلاء بثلاثة أدوار متميزة. تتفحص جلستان من جلسات AI الإصدار نفسه من الملف بشكل مستقل. وتتبادلان النتائج وتتحديان أدلة كل منهما. ثم تتلقى جلسة ثالثة سجل القرار، وتكتب تصحيحًا واحدًا، وتشغّل الفحوصات.
تعامل مع الملف على أنه مُدخل مشترك وغير قابل للتغيير أثناء المراجعة. امنح جلسة واحدة صلاحية الكتابة عندما تصل المراجعة إلى توافق.
يختلف هذا عن حلقة مراجعة الشيفرة الهجينة باستخدام AI→ الحالية لديّ، حيث يكتب نموذج واحد ويراجع نموذج ثانٍ كل إصلاح. تمنح تلك الحلقة المراجع استقلالية مفيدة بالفعل. أما التجربة التالية فتؤخر الكتابة: تراجع الجلستان الأوليان أولًا، ولا تبدأ جلسة ثالثة البرمجة إلا بعد أن ينتج خلافهما سجل قرار.
هذا النمط قريب بالفعل مما تدعمه أدوات الوكلاء الحالية. توصي وثائق الوكلاء الفرعيين في Codex من OpenAI بالوكلاء المتوازيين للاستكشاف كثيف القراءة، والاختبارات، والفرز، والمراجعة، مع التحذير من أن سير العمل المتوازي كثيف الكتابة ينشئ تعارضات وأعباء تنسيق. والعنصر المفقود هو طبقة نقاش وتركيب من الدرجة الأولى بين المراجعين والكاتب.
لماذا يحتاج سير عمل مراجعة الشيفرة متعدد الوكلاء إلى كاتب واحد؟
يمنحك التحليل المتوازي فرضيات مختلفة عن أسباب الفشل من دون إنشاء تصحيحات متعددة متنافسة.
يمكن لمراجع أن يتتبع السلوك والثوابت. ويمكن للآخر البحث عن مشكلات أمنية، أو حالات تسابق، أو اختبارات مفقودة، أو انتهاكات لعقد API. يبدأ كلاهما من commit SHA والمهمة نفسيهما، لكنهما يتلقيان موجزَي مراجعة مختلفين. ويقلل هذا الفصل احتمال أن تتبع الجلستان الفكرة الأولى نفسها.
تصف Anthropic نمطًا إنتاجيًا ذا صلة في بناء الوكلاء الفعّالين: إذ يمكن لعدة استدعاءات للنموذج مراجعة الشيفرة من وجهات نظر مختلفة، بينما يفوض سير عمل المنسق-العامل المهام ويركب النتائج. كما تنصح Anthropic الفرق بإضافة التعقيد الوكيلي فقط عندما يحسن النتائج المقاسة. فثلاث جلسات تكلف رموزًا ووقتًا أكثر من جلسة واحدة، ولذلك يحتاج سير العمل إلى سبب لوجوده.
نادراً ما يكون التعديل المتزامن هو ذلك السبب. فإذا عدّل وكيلان نسخة العمل نفسها، فعلى النظام حل مشكلة السياق القديم، والمقاطع المتداخلة، والافتراضات المطبقة جزئيًا. ويوفر Git بدائية أكثر أمانًا بالفعل: إذ تتيح أشجار العمل المرتبطة للجلسات المنفصلة استخدام حالة `HEAD` والفهرس المعزولة مع مشاركة سجل المستودع نفسه.
قد يستخدم المراجعون أشجار العمل لإجراء التجارب، لكن يجب أن يمتلك المدمج التصحيح المرشح وحده.
ما الذي تملكه كل جلسة من جلسات AI؟
| الجلسة | الوصول | المخرج المطلوب | ما يجب ألا تفعله |
|---|---|---|---|
| --- | --- | --- | --- |
| المراجع A | لقطة للقراءة فقط | مخاطر السلوك، والثوابت المكسورة، ومراجع الأسطر، والاختبارات المقترحة | تعديل الفرع النهائي |
| المراجع B | لقطة للقراءة فقط | الأمان، والتزامن، والحالات الطرفية، والأمثلة المضادة | نسخ استنتاج المراجع A من دون دليل |
| المدمج | صلاحية كتابة حصرية | تصحيح مقبول، ونتائج مرفوضة مع الأسباب، ونتائج الاختبارات، والفروقات النهائية | إعادة الكتابة خارج النطاق المتفق عليه |
الوكيل الثالث ليس أذكى تلقائيًا. تأتي ميزته من الملكية. فهو يتلقى أدلة محددة النطاق، ويجعل حل التعارض صريحًا، وينتج فرقًا واحدًا قابلًا للتدقيق.
كما أنني سأبقي المراجعين غير مطلعين على المرور الأول لبعضهما. فقد وجدت دراسة مضبوطة لنقاش متعدد الوكلاء أن ضغط الأغلبية قد يقمع التصحيح المستقل. ويمكن للتواصل المبكر أن يحول مراجعين اثنين إلى رأي واحد مكرر. يجب أن تأتي النتائج المستقلة أولًا؛ ويبدأ النقاش بعد أن يلتزم كلاهما بأدلته الأولية.
كيف ينبغي للمراجعين مناقشة ملف واحد؟
تُعد المحادثة الحرة مفيدة للبشر، لكن سير عمل البرمجة يحتاج إلى سجل موجز للنتائج. يجب أن يحمل كل ادعاء أدلة كافية ليتحقق منها المدمج من دون إعادة تشغيل سلسلة أفكار خاصة.
{ "id": "F-03", "revision": "8a31f2c", "file": "src/auth/session.ts", "lines": "84-103", "claim": "A refresh failure can leave the previous session active", "evidence": "The error branch returns before clearSession()", "risk": "stale authorization state", "proposed_test": "refresh 401 clears the active session", "confidence": "high", "status": "disputed" }
يمكن للمراجع الثاني قبول النتيجة، أو دحضها بحجة تستند إلى إمكانية الوصول إلى الشيفرة، أو تضييق نطاقها. ويحافظ السجل على الموقفين. فالاتفاق وحده لا يثبت الصحة، ولا ينبغي لفقرة واثقة أن تتغلب على اختبار قابل لإعادة الإنتاج.
تتحرك بروتوكولات الوكلاء في هذا الاتجاه. إذ يصوغ بروتوكول Agent2Agent من Google التعاون من خلال المهام، والرسائل، والحالة، والآثار. ولا يحتاج نظام برمجة محلي إلى البروتوكول الكامل ليستعير العقد: استخدم رسائل مكتوبة، ومعرّفات ثابتة، وحالة صريحة، وآثارًا دائمة بدلًا من نص غير منظم.
تقوم وصلة مراجعة الأقران باستخدام AI لديّ→ بالفعل بتغليف فرق، وأسئلة تركيز، وحكم منظم لنموذج ثانٍ. ويحتاج سير العمل ذي الجلسات الثلاث إلى الطبقة التالية: حزمتَي مراجعة يمكنهما الإشارة إلى معرّفات النتائج نفسها، والاعتراض عليها، وحلها قبل أن يتلقاها الكاتب.
ما الذي يجب أن يتلقاه الكاتب قبل التعديل؟
يجب ألا يتلقى المدمج سجلَي محادثة طويلين. بل يحتاج إلى حزمة تسليم صغيرة:
يعيد الكاتب بعد ذلك قراءة الملف الحالي ويقارن إصداره بحزمة التسليم. ويؤدي عدم التطابق إلى إيقاف الكتابة. ويمنع هذا الفحص الواحد مراجعة صحيحة لملف الأمس من التحول إلى تصحيح معطوب على شيفرة اليوم.
وهنا أيضًا يجب أن تصبح الصلاحيات حتمية. لقد دافعت عن صلاحيات حتمية لوكلاء AI→ لأن مطالبة مثل «عدّل هذا الملف فقط» أضعف من سياسة أدوات تجعل كل مسار آخر للقراءة فقط. وفي هذا سير العمل، ينبغي لنموذج الصلاحيات أن يفرض فصل الأدوار: لا يستطيع المراجعون الكتابة، ولا يستطيع المدمج توسيع النطاق من دون قرار جديد.
هل يحسن النقاش تصحيحات البرمجيات؟
تدعم الأدلة هذا الاتجاه، لكنها لا تثبت أن على كل فريق استخدام مراجعين اثنين وكاتب واحد بالضبط.
توضح تحسين الدقة والاستدلال في نماذج اللغة من خلال النقاش متعدد الوكلاء أن عدة نسخ من النموذج يمكنها اقتراح الإجابات وانتقادها وتحسينها عبر جولات متعددة، مما يحسن النتائج في مهام الاستدلال والدقة الواقعية الواردة في الورقة. ولم تختبر تلك التجارب تعارضات Git أو طلبات الدمج الإنتاجية.
ظهر مثال برمجي أقرب في المسودة الأولية لعام 2025 SWE-Debate. إذ تناقش وكلاؤها آثارًا متنافسة لتحديد موضع الخلل، وتوحد خطة إصلاح، ثم تمرر تلك الخطة إلى وكيل منفصل لتوليد التصحيح. وتذكر الورقة حل 207 مهام من أصل 500 في SWE-bench Verified، أي 41.4%، مقارنةً بـ 38.8% لأقوى خطوط الأساس المدرجة لديها. ويختلف المعيار والبنية عن سير العمل الذي أقترحه، لكن الفصل دال: تحليل متنوع أولًا، ثم مرحلة تعديل واحدة.
الخطوة التالية الصادقة هي إجراء تقييم مضبوط صغير على طلبات دمج حقيقية. قارن بين وكيل برمجة واحد وسير العمل ذي الجلسات الثلاث عبر 10 إلى 20 خطأ. وقِس النتائج الصحيحة، والإيجابيات الكاذبة، وتعارضات الدمج، والوقت اللازم للوصول إلى تصحيح مقبول، والتراجعات التي اكتُشفت بعد المسودة الأولى. فزيادة رسائل الوكلاء ليست مقياس نجاح.
كيف ينتج الكاتب تصحيحًا واحدًا قابلًا للتدقيق؟
ينبغي للمدمج اتباع حلقة ضيقة:
يجب أن تفحص المراجعة الأخيرة التصحيح، لا أن تعيد بدء نقاش التصميم. ويجيب كل مراجع عن سؤالين: هل نفذ الكاتب القرار المقبول؟ وهل أدخل التصحيح خطرًا جديدًا؟
يستخدم تطبيق Codex الحالي من OpenAI بالفعل سلاسل محادثة وأشجار عمل منفصلة حتى تتمكن الوكلاء من العمل بالتوازي من دون لمس حالة Git المحلية نفسها، كما يتيح للمطورين فحص كل فرق والتعليق عليه. ويوضح إعلان تطبيق Codex أن طبقة العزل موجودة. ومن شأن سجل نتائج مشترك ودور مدمج صريح أن يحولا المهام المتوازية إلى غرفة مراجعة منسقة.
ما الإخفاقات التي تبقى؟
يزيل الكاتب الواحد سباقات التعديل، لكنه لا يزيل خطأ النموذج.
قد يشترك مراجعان في النقطة العمياء نفسها، خصوصًا عند استخدام النموذج والمطالبة والسياق نفسها. وقد يختار المدمج الحجة الأكثر إقناعًا بدلًا من الصحيحة. وقد تحتوي تعليقات المستودع على تعليمات غير موثوقة. كما قد تفوّت مجموعة اختبارات ناجحة السلوك الذي يعتمد عليه المستخدمون.
يحتاج سير العمل إلى وسائل حماية:
ولا يزال استنتاجي السابق بعد 21.54 مليار رمز من نشاط وكلاء البرمجة→ قائمًا: النظام المحيط بالنموذج هو الذي يقرر ما إذا كان المزيد من الذكاء سيتحول إلى عمل مفيد أو إلى تنظيف أسرع.
متى يستحق سير العمل ذي الجلسات الثلاث؟
استخدمه عندما يكون التصحيح الخاطئ مكلفًا أو عندما تحتمل الشيفرة أكثر من تفسير معقول: المصادقة، والصلاحيات، والمدفوعات، وعمليات الترحيل، والتزامن، وواجهات API العامة، وإصلاحات الحوادث. وقد يساعد أيضًا عندما يطلب مهندس أول عادةً من متخصصين اثنين مراجعة منطقتي خطر مختلفتين.
تجاوزه في التنسيق، والملفات المولدة، وإعادة التسمية البسيطة، والتغييرات التي تملك معيار اختبار واضحًا. وجدت فرق الوكلاء متعددة الوكلاء لدى Anthropic أن تعقيد التنسيق ينمو بسرعة، وأن نظام البحث الإنتاجي يعتمد على تفويض واضح ووكيل قائد يركب النتائج المتخصصة. وتحتاج البرمجة إلى الانضباط نفسه، مع تسامح أقل مع الكتابات الغامضة.
أريد من وكلاء البرمجة أن يناقشوا الأدلة قبل أن يكسب أحدهم المؤشر. ينبغي لجلسَتين أن تتفحصا الملف نفسه، وتختلفا علنًا، وتتركا سجل قرار واحدًا. وينبغي لثالثة أن تكتب التصحيح المرشح وتثبت صحته مقابل المستودع.
ولا يزال ذلك المرشح يحتاج إلى الاختبارات، ومراجعة الفرق، وقرار إصدار بشري. يمكن لثلاث جلسات من AI أن تحسن الطريق إلى التصحيح؛ لكنها لا تحول التصحيح إلى حقيقة.
الأسئلة الشائعة
هل يستطيع وكيلان من AI تعديل الملف نفسه في الوقت نفسه؟
يمكنهما ذلك، لكن الكتابات المشتركة تنشئ سياقًا قديمًا وتعديلات متعارضة. دع كلا الوكيلين يحللان الإصدار نفسه في وضع القراءة فقط، أو اعزل التجارب في أشجار عمل منفصلة، ثم امنح مدمجًا واحدًا صلاحية كتابة حصرية على الفرع النهائي.
هل ينبغي أن يستخدم المراجعان النموذج نفسه؟
يمكنهما ذلك، لكن اختلاف المطالبات أو الأدوار أو عائلات النماذج قد يقلل النقاط العمياء المترابطة. ولا يضمن التنوع الصحة، لذلك يظل سير العمل بحاجة إلى الأدلة والاختبارات.
ماذا يحدث عندما يختلف المراجعون؟
سجّل الموقفين في سجل النتائج. ينبغي للمدمج إعادة إنتاج الادعاء، أو تشغيل الاختبار المقترح، أو وضع علامة «غير محسوم» على المسألة لإحالتها إلى إنسان. ويُعد التصويت بالأغلبية بديلًا ضعيفًا عن الأدلة القابلة للتحقق.
هل تحل جلسة AI الثالثة محل مراجعة الشيفرة البشرية؟
لا. تتولى الجلسة الثالثة التركيب والكتابة المرشحة. ولا يزال على الإنسان أن يقرر ما إذا كان التصحيح يلائم النظام الأوسع، وهدف المنتج، ومخاطر الإصدار.
هل يستطيع سير العمل هذا التعامل مع تغييرات عبر عدة ملفات؟
نعم. ثبّت كل ملف تمت مراجعته على إصدار المستودع نفسه، وعيّن ملكية واضحة، وحافظ على فرع دمج واحد. ويمكن للمراجعين العمل عبر أشجار عمل معزولة، بينما يظل المدمج الجلسة الوحيدة التي تجمع التصحيح النهائي.