وكلاء البرمجة ينهون مهامهم قبل إتمامها: كيف يفكك معمار «دي رياكت» معضلة الثقة؟

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

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

نتائج الاختبارات المعيارية التي أجراها الفريق على منصتي «غايا» و«إس دبليو إي بينش فيريفايد» كشفت عن نمط تقني بالغ الدلالة. لم تكن الفائدة الكبرى من نصيب النماذج الرائدة وفائقة التكلفة، بل تركزت في النماذج الأقل قدرة؛ إذ حقق نموذج «كيوين 3 كودر 480 بي» قفزة بلغت بين 6.5 و7.0 نقاط في مقياس الدقة من المحاولة الأولى، وسجل نموذج «كلود سونيت 4.5» تحسنًا تراوح بين 4.2 و5.2 نقاط. في المقابل، تضاءلت تلك المكاسب مع نموذج «كلود أوبوس 4.5»، حيث بقيت نسب النجاح قريبة من المعمار التقليدي، لكن مع فارق حاسم تمثل في إنتاج مسارات عمل مكتملة الأدلة ومطابقة للقيود البرمجية الصارمة، ما يعني أن النظام فضّل التريث والتدقيق على حساب الإنهاء المتسرع.

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

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