أفضل وكيل ذكاء اصطناعي حلّ 60% فقط من مهام DevOps السحابية، و80% من الإخفاقات سببها المنطق

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

هذا بالضبط ما كشفه CloudOpsBench، وهو معيار اختبار مفتوح جديد، أي مجموعة من المهام القياسية لمقارنة النماذج. فأفضل النماذج التي خضعت للاختبار، Claude Fable 5.1، حلّ 60% فقط من المهام، وحلّ GPT-6 Astra نسبة 53%.

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

ما الذي يختبره CloudOpsBench

أعدّ المعيار فريق بقيادة آنغ تشن من جامعة ميشيغان. وتتضمن النسخة 1.0 عدد 45 مهمة على AWS كتبها مهندسو DevOps ذوو خبرة. وتغطي المجموعة الأعمال المعتادة: إصلاح خدمة، وحذف موارد، وتقييد صلاحيات الوصول، وطرح تحديث، وإخراج مشروع من التشغيل.

تُنفَّذ كل مهمة بالطريقة نفسها في سحابة AWS الحقيقية وفي المحاكي. ويتيح المحاكي إجراء اختبارات قابلة للتكرار دون تعريض البنية التحتية الفعلية لأي خطر. نُشر المشروع على GitHub بترخيص Apache 2.0، وأُرفق به تحليل مفصّل للأخطاء. ومن المخطط إضافة امتدادات لـ GCP وAzure وOCI (Oracle Cloud Infrastructure).

أين يتعثر الوكلاء

حتى الأفضل بينها يخفق في جزء ملحوظ من المهام: فنسبة نجاح Claude Fable 5.1 هي 60%، ونسبة GPT-6 Astra هي 53%. ولم ينجح أي نموذج في حل جميع المهام. ووفق المؤلفين، يكمن عنق الزجاجة في معظم الحالات في الاستدلال تحديدًا.

وتندرج نحو 80% من الإخفاقات ضمن ثلاثة سيناريوهات:

• يُقدّر الوكيل حجم المهمة تقديرًا خاطئًا؛
• لا يفحص جميع الخدمات المرتبطة؛
• يتوقف قبل اكتمال العمل.

وهذه هي قصة وصول الموظف المفصول نفسها: الوكيل يعرف الأوامر، لكنه لا يتأكد من أن الصورة أُغلقت بالكامل.

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

ماذا نفعل عمليًا

الاستنتاجات التالية توصيات من عندنا، وليست من نتائج مؤلفي المعيار.

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

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

ثالثًا، اختبر على مهام قريبة من مهامك. وبما أن CloudOpsBench مفتوح ويعمل في محاكٍ، يمكن استخدامه لمقارنة النماذج أو صيغ الموجِّهات (prompts) دون المخاطرة بالسحابة الحقيقية.

القيود

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