AOS-Bench يختبر وكلاء الذكاء الاصطناعي: جودة الأداء تنخفض بين 13 و23 نقطة في المهام المتوازية

كيف صُمِّمت التجربة

انشغل فريق من الباحثين بسؤال عملي: إلى أي مدى يكون وكلاء الذكاء الاصطناعي القادرون على كتابة الشيفرة البرمجية وإدارة الحاسوب مستعدين للعمل، لا مع مهمة واحدة في كل مرة، بل مع تدفق من المهام — كما يحدث في الحياة الواقعية، حين يصل طلب لمعالجة بيانات بينما جارٍ بناء مشروع ما، ثم يصل طلب آخر لتصحيح خطأ برمجي. جميع الاختبارات القائمة لهذا النوع من الوكلاء (مثل Terminal-Bench أو OSWorld) تقيّم المهام كلًّا على حدة، لذا لم يقِس أحد من قبل قدرة الوكيل على معالجة عدة أمور في آن واحد في ظل موارد حاسوبية محدودة. ولهذا السبب، أُنشئ اختبار جديد باسم AOS-Bench يحاكي عمل الوكيل كنوع من "نظام تشغيل بلغة طبيعية"، يقرر بنفسه متى يبدأ بمهمة جديدة، وكيف يوزّع العمل بين المهام الفرعية، وكيف يتجنب تجاوز حدود المعالج والذاكرة المتاحة.

جرى اختبار خمسة توليفات من "النموذج + الغلاف الوكيلي": Claude Opus 5 و GPT-5.6-sol و DeepSeek-V4-Pro و GLM-5.3 و Kimi-K3. مُنح كل نظام حدًّا أقصى من 4 أنوية معالج و8 غيغابايت من الذاكرة — في حالة واحدة كانت المهام تصل بشكل منفرد تمامًا (وهذا هو المعيار المرجعي للأداء "الفردي")، وفي الحالة الأخرى كانت عدة مهام تصل تباعًا على فترات، على غرار بيئة العمل الحقيقية ("التدفق"). وجرى اختبار مستويين من الصعوبة: متوسط (10 مهام في كل تجربة) وشديد (20 مهمة).

ما أظهرته الأرقام

في ظل الحمل الشديد، فقد كل نظام من الأنظمة الخمسة ما بين 13 و23 نقطة مئوية من معدل الحلول الناجحة، مقارنة بما يحققه النظام نفسه على المهام ذاتها عند معالجتها بشكل منفرد. وكان Claude Opus 5 الأفضل أداءً: انخفض معدل النجاح من 75.5% على المهام المنفردة إلى 62.5% في حالة التدفق — أي أن النظام حافظ على نحو 83% من قدرته الأساسية على حل المهام. أما الأنظمة الأربعة الأخرى، فلم تحافظ إلا على 61-75% من مستواها الأساسي.

وفي ظل الحمل المتوسط، كانت النتائج أكثر دلالة: جودة أداء النظام في حل المهام المنفردة لا تكاد تُنبئ بجودة أدائه في التعامل مع تدفق المهام. حقق GPT-5.6-sol أعلى نتيجة على المهام المنفردة بنسبة 85.3%، لكنه فقد 14.5 نقطة في حالة التدفق. في حين أن Kimi-K3، الذي كان مستواه الأساسي أقل بـ11 نقطة، لم يفقد سوى 6.3 نقاط في التدفق. والمثال الأكثر وضوحًا: نظامان لا يختلف معدل نجاحهما على المهام المنفردة إلا بمقدار 0.6 نقطة (74.9% مقابل 74.3%)، لكنهما يحققان في التدفق 68.1% و53.9% — فرق يقارب 15 نقطة، لا ينبغي أن يكون موجودًا من الأساس.

لماذا يحدث هذا

السبب الرئيسي لا يرجع إلى ضعف الوكلاء في حل المهام نفسها. فقد قسّم الباحثون كل فقدان للنقاط حسب أسبابه، واكتشفوا أن الجزء الأكبر من الفارق في ظل الحمل الشديد (ما بين 16 و26 نقطة من أصل 16-23 لدى أربعة أنظمة) يرجع إلى مهام لم يشرع الوكيل فيها على الإطلاق، أو لم يُنهِها في الوقت المحدد، أو أنهاها بعد أن امتلأت الذاكرة. أما الأخطاء الفعلية في تنفيذ المهام التي شُرع فيها فلا تتجاوز خسارتها 1.3 نقطة. وبعبارة أبسط: الأنظمة لا تتعثر في حل المهام، بل في الشروع فيها في الوقت المناسب.

ومن الأمثلة الدالة بشكل خاص GLM-5.3 و DeepSeek-V4-Pro، اللذان توقفا في بعض التجارب عن أخذ مهام جديدة وبدآ العمل بشكل منفرد، تاركين 25% و48% من المهام الواردة، على التوالي، دون أي معالجة (في حين بلغت هذه النسبة 0% لدى Claude Opus 5). ومع ذلك، إذا قُدِّمت جميع المهام دفعة واحدة وبشكل قسري (دون قائمة انتظار تسلسلية)، تأخذ الأنظمة ثلاثة أرباع المهام في العمل — أي أن المشكلة لا تكمن في تعقيد المهام، بل في منطق تلقي العمل الجديد بالتحديد.

استنتاج غير متوقع بشأن الإدارة "الذكية"

قد يبدو الحل بديهيًا: تعليم الوكيل تخطيط التوازي بذكاء أكبر. لكن التجربة أظهرت العكس: قاعدة بسيطة للغاية — "تنفيذ مهمتين بالضبط في الوقت نفسه دون أي تحليل" — تقارب (بفرق لا يتجاوز 4 نقاط) أفضل الاستراتيجيات التي يقرر فيها الوكيل بنفسه ماذا ومتى يُشغِّل. وبصرف النظر عن استراتيجية الإدارة المتبعة، لا يُستخدم المعالج، أثناء انتظار المهام لدورها، بأكثر من 30% من الأنوية الأربعة المخصصة له — أي أن الموارد تبقى عاطلة حتى عندما يكون العمل متوفرًا بكثرة.

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