AOS-Bench: وكيلان بفارق 0.6 نقطة بينهما ينجزان 54% و68% من المهام نفسها

يتحول وكلاء البرمجة تدريجياً من منفذين لطلبات منفردة إلى مساعدين دائمين يُلقى عليهم تدفق من العمل: البناء ومعالجة البيانات وإصلاح الأخطاء في وقت واحد، وكل ذلك على جهاز واحد. أصدر فريق من خمسة مؤلفين بقيادة Erle Zhu معيار AOS-Bench، الذي يقيّم المنظومة الوكيلية بوصفها مديراً لهذا النوع من الأحمال تحديداً. النتيجة الرئيسية: النجاح في بيئة معزولة لا يتنبأ جيداً بالنجاح في التدفق المستمر. وعلى الأحمال الثقيلة، يفقد كل نظام من الأنظمة الخمسة المختبرة ما بين 13 و23 نقطة.

لماذا تعجز الاختبارات المعتادة عن رؤية قائمة الانتظار

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

يعمل AOS-Bench على النحو التالي: تصل المهام المختبَرة مع مرور الوقت، ويجب تسليمها ضمن قيود مشتركة على CPU والذاكرة. أما المهام نفسها حين تُنفَّذ واحدة تلو الأخرى، فتمثّل المرجع الخاص بكل نظام. ويكشف الفارق بين النتيجة المعزولة ونتيجة التدفق مقدار ما تخسره قدرة الوكيل بسبب الإدارة.

أين تضيع النقاط

اختبر المؤلفون خمسة أزواج من «النموذج–harness». وجاءت الصورة غير متجانسة:

• على الأحمال الثقيلة، يفقد كل نظام 13–23 نقطة قياساً بنجاحه في العزل؛
• على الأحمال المتوسطة، يبلغ التباين بين الأنظمة 11 نقطة في النجاح المعزول، لكنه يصل إلى 26 نقطة في نجاح التدفق؛
• نظامان بفارق 0.6 نقطة في العزل ينجزان 54% و68% من المهام نفسها؛
• مع الإرسال التسلسلي، تبقى 73% من مهام الحمل الثقيل دون أن يُشرع في العمل عليها؛
• التزامن الثابت بقيمة اثنين لا يتخلف عن أفضل سياسة يتولى الوكيل إدارتها بأكثر من 4 نقاط، سواء على الأحمال المتوسطة أو الثقيلة؛
• مع أي سياسة، يبقى متوسط استخدام CPU (الوسيط) أقل من 30% من الأنوية المخصصة، فيما المهام تنتظر دورها.

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

قائمة انتظار بسيطة في مواجهة مدير ذكي

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

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

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

والخلاصة العملية للفرق التي تنشر وكلاء برمجة دائمين: اختيار النظام بناءً على المعايير الفردية وحدها لا يكفي. ينبغي التحقق من سلوكه عند تعدد المهام المتوازية على جهاز حقيقي، ومراقبة نسبة المهام التي أُخذت فعلاً في العمل، واستخدام CPU أثناء الانتظار. وقبل بناء منظومة تنسيق معقدة، من المفيد مقارنتها بقائمة انتظار صارمة بخانتين: فبحسب بيانات AOS-Bench، يتبين أن هذا الخط المرجعي قوي بشكل مفاجئ. أما لمطوّري حزم التشغيل (harness)، فيحدد الاختبار نقطة تحسين بعينها: سياسة استلام المهام، حيث يضيع ما يصل إلى 73% من العمل المحتمل.

نُشرت النسخة الأولية (preprint) على arXiv في 23 أكتوبر 2026، وصدرت النسخة الثانية في 27 أكتوبر.