AgentProofBench: باحثون في CMU يختبرون إمكانية إعادة استخدام مدقِّقات وكلاء الويب

قدّم باحثون من Carnegie Mellon University بقيادة Jingjie Ning معيار AgentProofBench لمدقِّقات وكلاء الويب. ويجيب المعيار عن سؤال عملي: هل يمكن كتابة قاعدة قبول النتيجة مرة واحدة، ثم استخدامها عند تغيّر المتطلبات وفي التنفيذ الفعلي؟ يغطي المعيار 97 مهمة و79 عائلة مهام وأربع خدمات ويب. وقد ولّد نموذجا DeepSeek Flash وDeepSeek Pro برامج المدقِّق.

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

إعادة الاستخدام أم إعادة البناء

يتعلق القياس الأول بمدى الصمود أمام تغيّر المتطلبات. فعلى 48 عائلة مهام طُبّق اختباران: complete-panel وdecision-replay. ويبيّن الاختباران ما إذا كان برنامج المدقِّق الأصلي يظل صالحًا عند تغيّر المتطلب، أم يجب كتابته من جديد.

• Flash: بقي 82 من أصل 96 برنامجًا أصليًا (نحو 85%).
• Pro: بقي 79 من أصل 96 (نحو 82%).
• يقع الفرق بين إعادة الاستخدام وإعادة البناء وفق مقياس BA لدى Flash ضمن المجال من −5,47 إلى 1,57 نقطة مئوية.
• أما لدى Pro فيمتد المجال نفسه من −10,16 إلى 0,00 نقطة مئوية.

يشمل مجال Flash الصفر، أي لا توجد في هذه البيانات خسارة ملحوظة من إعادة الاستخدام. أما لدى Pro فيصل الحد الأعلى إلى الصفر، بينما ينخفض الحد الأدنى إلى ما يقارب 10 نقاط. وفي أسوأ الأحوال تكلّف إعادة الاستخدام أكثر بوضوح، ويجعل المعيار هذه الكلفة قابلة للقياس.

أخطاء اللوحة مؤشرًا على التسليم

يتعلق القياس الثاني بالتنفيذ، ويستند إلى 22 عائلة. نظر المؤلفون في تعيينات البرامج التي تُسلَّم فيها الحالتان الابتدائيتان المحفوظتان بشكل صحيح، وبحثوا عمّا يميّز هذه الحالات عن غيرها. والفارق هو صحة اللوحة في حالة النشر.

• من بين 33 تعيينًا بلوحة خالية من الأخطاء، حقق 32 تسليمًا صحيحًا في الحالتين معًا.
• ومن بين 11 تعيينًا كانت لوحتها تحتوي على أخطاء، حدث ذلك في تعيين واحد فقط.
• جميع حالات التراجع في program-gate قياسًا إلى القواعد المرجعية، وجميع حالات حجب التسليم، وقعت ضمن مجموعة اللوحات التي تحتوي على أخطاء.

لا يمكن اعتبار الفارق 97% مقابل 9% على عيّنة صغيرة من 44 تعيينًا نهائيًا. لكنه يدل على أن فحص المدقِّق على لوحة اختبار قبل التشغيل يعطي إشارة عملية إلى ما إذا كان يمكن إدخال البرنامج في العمل.

خط الأساس لبوابات التحقق

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

ما الذي في الإصدار وكيف يُستخدم

نُشرت مع المعيار التعليمات وحالات البيئة وبرامج المدقِّق والقواعد المرجعية ومسارات الوكلاء. الشيفرة وصفحة المشروع متاحتان على GitHub وعلى ethanning.github.io/AgentProofBench. وسُجّلت النسخة التمهيدية باسم arXiv 2610.34634، وظهرت في القائمة اليومية Hugging Face Daily Papers.

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