القاتل الصامت لعائد الاستثمار في الذكاء الاصطناعي الوكيل (Agentic AI)
حاويات Kubernetes تعمل بشكل سليم. زمن استجابة الـ API منخفض. مزود الـ LLM يظهر نسبة تشغيل تصل إلى 99.9%.
ومع ذلك، استهلك نظام القروض المؤتمت ميزانية الـ API الشهرية بالكامل في ثلاث ساعات فقط. علق وكيلان (two agents) في حلقة مفرغة.
هذه هي مفارقة "سليم ولكنه يهلوِس".
في البرمجيات التقليدية، يكون النظام إما يعمل أو متوقفاً. أما في الشبكة الوكيلية (agentic mesh)، فقد يبدو النظام سليماً ولكنه يفشل تماماً. إذا كنت تستخدم هندسة موثوقية المواقع (SRE) التقليدية للوكلاء، فأنت تراقب الإشارات الخاطئة. أنت تقيس نبض مريض ميت دماغياً من الناحية الوظيفية.
لماذا تفشل هندسة SRE التقليدية في منع الانهيار الوكيل؟
بُنيت هندسة SRE التقليدية للأنظمة الحتمية (deterministic systems). عندما تفشل الخدمة، فإنها تطلق خطأً. الأمر ثنائي (binary). لكن فشل الوكلاء مختلف؛ فالوكيل لا يتعطل، بل ينحرف (drifts). هو لا يتجاوز المهلة الزمنية (time out)، بل يهلوِس بمعامل (parameter) يتسبب في فشل صامت بعد عدة خطوات.
نحن نرى هذه الفجوة أثناء الانتقال من البوتات المنفردة إلى أنسجة الوكلاء للمؤسسات (enterprise agent fabrics). يبلغ فريق ما عن دقة بنسبة 95% في اختبار معياري (benchmark)، لكن النظام يفشل في بيئة الإنتاج. تقيس الاختبارات المعيارية ما إذا كان النموذج قادراً على الإجابة على سؤال، لكنها لا تقيس ما إذا كان النظام قادراً على الحفاظ على الحالة (state) عبر سير عمل مكون من 12 خطوة يتضمن أربعة وكلاء.
أنت بحاجة إلى هندسة موثوقية الوكلاء (Agent Reliability Engineering - ARE).
تدير SRE التقليدية الحالات الثنائية، بينما تدير ARE توزيعات الاحتمالات (probability distributions). إذا كنت تكتفي بتتبع وحدة المعالجة المركزية (CPU) والذاكرة، فأنت أعمى عن فشل الوكلاء.
الأخطاء في الأنظمة متعددة الوكلاء لا تتراكم فحسب، بل تتضاعف. ولأن الوكلاء يستخدمون مخرجات الوكلاء الآخرين كحقيقة مطلقة، فإن خطأً صغيراً في الخطوة الأولى يصبح كارثة بحلول الخطوة الخامسة.
تشمل أنماط الفشل الشائعة ما يلي:
- حلقات الوكلاء اللانهائية (Agentic infinite loops)
- انحراف الحالة (State drift)
- تسلسلات حقن الأوامر (Prompt injection cascades)
- هلوسة استدعاء الأدوات (Tool-call hallucinations)
مثال خطير: يستدعي وكيل أداة تحديث، فيبتكر معاملًا غير موجود. يتجاهل الـ API المعامل الإضافي ويعيد استجابة 200 OK. يعتقد الوكيل أنه نجح، لكن منطق العمل (business logic) فشل بصمت.
تركز ARE على حلقة "النية-الإجراء-النتيجة" (intent-action-outcome). أنت لا تراقب فقط ما إذا كان الوكيل قد استدعى أداة ما، بل تراقب ما إذا كان ذلك الاستدعاء قد طابق النية الأصلية وما إذا كانت النتيجة قد حققت الهدف.
يتولى دور مهندس موثوقية الوكلاء (ARE) المهام التالية:
- تحليل النية (Intent Analysis): اكتشاف متى ينحرف الوكيل عن الهدف.
- ضبط الحواجز الوقائية (Guardrail Tuning): تعديل القيود لإيقاف الحلقات المفرغة.
- رسم خرائط الموثوقية (Dependability Mapping): تحديد متى يجب على الوكيل تسليم المهمة إلى إنسان.
- بنية التدقيق (Audit Architecture): التقاط الاستدلال الداخلي وتغييرات الحالة.
توقف عن الحديث عن الدقة. ابدأ بالحديث عن موثوقية النظام (System Dependability).
يمكنك تبرير ذلك للمدير المالي (CFO) من خلال تحديد تكلفة التدخل البشري كمياً. في كل مرة يقوم فيها إنسان بإصلاح خطأ الوكيل، فإن ذلك يعد فشلاً في الموثوقية. اضرب تلك الساعات في رواتب الخبراء لديك، وستتضح تكلفة عدم الموثوقية.
استخدم ميزانيات الخطأ الوكيلية (Agentic Error Budgets). بالنسبة لملخص بريد إلكتروني بسيط، تكون ميزانية الخطأ لديك مرتفعة. أما بالنسبة لنظام يحول 10 ملايين دولار، فإن ميزانية الخطأ لديك هي صفر.
لا تعامل الذكاء الاصطناعي كميزة برمجية، بل عامله كمخاطرة نظامية. الفائزون في هذا العصر لن يمتلكوا أذكى النماذج، بل سيمتلكون الأنظمة الأكثر موثوقية.
مجتمع تعليمي اختياري: https://t.me/GyaanSetuAi