متى يَفشل وكيلُ AI في الإنتاج: سبعةُ أنماطٍ رصدتُها على ١٢ مشروعاً
الفشلُ في الوكلاءِ يَكاد يَكون متطابقاً عبرَ المشاريع. سبعةُ أنماطٍ — لو عرفتَها قبل النشر، تَوفِّر عليكَ شهراً من الأخطاء، وعميلاً غاضباً.
في تجربتي مع تشغيل وكلاءِ AI خلال العامِ الماضي — على مشاريعَ تجاريّةٍ وتجاربَ شخصيّةٍ تَجاوزت الاثني عشر — لاحظتُ نمطاً مزعجاً: الفشلُ يَكاد يَكون متطابقاً. الأخطاءُ تَتكرَّر بصياغاتٍ مختلفة، لكنّ العائلةَ ذاتها.
هذه السبعةُ هي أكثرُ ما رصدتُ. إن كنتَ تَبني وكيلاً، اقرأها قبل النشر. إن كان لديكَ وكيلٌ يَعمل، اقرأها لتَعرفَ ما الذي ستُصلحه قبل أن تَدفعَ ثمنَه عميلاً غاضباً.
١. الحلقةُ المفرغة (Infinite loop)
الأكثر شيوعاً، والأرخصُ في الإصلاح. الوكيلُ يَستدعي أداةً، يَفشل، يُحاول، يَفشل، يُحاول، حتى تَنتهي الـ tokens أو يَنتهي وقتُ المستخدم.
الحلّ: circuit breakers صارمة. ثلاثُ محاولاتٍ متتاليةٍ على نفسِ العمليّة = توقّفْ، اطلبْ تدخّلاً بشريّاً. ١٠ محاولاتٍ مجموعةً في الجلسة = اخرجْ كاملاً، انتظرْ الجلسةَ التالية. لا تَترك التحكّمَ للنموذج وحدَه.
٢. الثقةُ في الـ schema (Schema drift)
كتبتَ الكود لمّا كان الـ API يُرجِع {user: {...}}. الآن يُرجِع {data: {user: {...}}}. الوكيل يَقرأ response.user، يَجد undefined، يُكمل بافتراضاتٍ مختلَقَة.
الحلّ: validation عند كلِّ حدٍّ خارجيّ. zod أو pydantic أو ما شابه. لو الـ schema تَغيَّر، الوكيل يَعرف فوراً، لا بعد ساعة من المُخرَجاتِ المُختلَقَة.
٣. الهلوسةُ في الـ tool selection
عند إعطاء الوكيل ٢٠+ أداة، يَختار أحياناً أداةً غيرَ موجودة. يَكتب: book_flight(...) بينما الأداة المُسجَّلة flight_search. الـ tool dispatcher يُرجِع خطأً، الوكيل يُربك، يُحاول search_flight، خطأ آخر.
الحلّ: قلّلْ الأدوات لكلِّ مهمّة. الوكيلُ لا يَحتاج كلَّ أدواتِك دائماً. اختر له ٥-٧ أدواتٍ مرتبطةٍ بالمهمّة الحاليّة فقط. هذا يُسمّى dynamic tool selection.
٤. التأخّرُ السلبيّ (Silent latency creep)
في الإطلاق: متوسّط الاستجابة ٣ ثوان. بعد شهرين: ١٢ ثانية. لا أحدَ لاحظ، لا أحد بَحث.
السبب الشائع: الوكيلُ يَستدعي Web search في كلِّ سؤال — كانت أداةً اختياريّة، صارت رد فعلٍ افتراضيّاً. أو: السياقُ نمى من ٢KB إلى ٢٠KB لأنَّ memory injection تَراكَم.
الحلّ: logging كلِّ استدعاءِ أداة + قياس متوسّط الكَمون أسبوعيّاً. لو ارتفع >٢٠٪، تحقّقْ فوراً. الـ latency لا تَتدهور وحدها — هي عَرَضٌ لمشكلةٍ أعمق.
٥. الـ context poisoning
الوكيلُ يَحتفظ بسياقِ الجلسة. مستخدمٌ خَدَعَه (عن قصد أو عن غير قصد) بمعلومةٍ خاطئة في بداية الجلسة. باقي الجلسة تُبنى على افتراضٍ خاطئ.
أكثر تجلّياً: مستخدمٌ يَكتب في رسالة عابرة "اعمل دائماً افتراض أنّني في دبي". الوكيلُ يَعتمد ذلك في كلِّ الجلسة. عميل آخر، نفس الجلسة (حالة بائعة، مثلاً): يَنصح بمطعمٍ في دبي بينما العميل في الرياض.
الحلّ: memory layering. السياقُ المُعتَمد يَختلف عن السياقِ العابر. تَحقَّق دوريّاً من أنَّ الوكيلَ لا يَتذكَّر "حقائق" لم تُؤكِّدها أنتَ.
٦. تصعيدُ الأخطاء (Error escalation)
الوكيلُ يَصادف خطأً صغيراً، يَلتفّ حوله. ثمّ خطأً آخر، يُحاول حلّاً مبتكراً. ثلاثة أخطاء لاحقاً، الوكيلُ يَنفّذ سلوكاً غريباً تماماً يُحاول إصلاح كلِّ شيء.
في حالةٍ شخصيّة: وكيلٌ كان يَعمل على ملفّ، فَشل في الكتابة، فقرَّر "حذف الملفّ" ثمّ "إعادة إنشائه". الملفُّ القديمُ كان يَحوي عملاً لم يُحفَظ.
الحلّ: fail loud, fail early. الوكيلُ ليس مهندساً يَحلّ المشاكلَ بطريقتِه. هو منفِّذ مهمّةٍ محدَّدة. لو فَشل، يَتوقَّف ويُبلّغ. لا يُبدع.
