EvoWeb يختبر وكلاء البرمجة عبر 320 طلبًا متتاليًا على 32 تطبيق ويب

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

كيف صُمم المعيار

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

وطريقة الفحص غير معتادة أيضًا. فبعد كل طلب يفتح وكيل ويب متعدد الوسائط النسخة الوسيطة من التطبيق ويختبرها في متصفح حي. ويقيّم ثلاثة أمور:

• هل تعمل الوظيفة المطلوبة للتو؛
• هل تتكامل مع الوظائف الناتجة عن الطلبات السابقة؛
• هل تعطّل شيء مما نُفّذ سابقًا.

والبند الثالث مهم: ففي هذا الإعداد لا تختبئ الانحدارات (regressions) خلف اختبار نهائي، بل تظهر في كل خطوة.

الموثوقية بدلًا من نقطة التوقف

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

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

اختبر المؤلفون نماذج frontier مفتوحة ومغلقة. وقد ميّز EvoWeb بينها بوضوح من حيث النتائج، بينما يواجه كثير من المعايير الحالية صعوبة في ذلك تحديدًا، إذ تتقارب نتائج الرائدين في نطاق ضيق. وكان التكامل عبر الطلبات أصعب مكوّن.

خلص التحليل إلى استنتاجين:

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

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

كيف تستخدم النتائج عمليًا

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

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