وكيل n8n تلقّى 200 OK، لكن العميل رأى دردشة فارغة: تحليل «خلل الصمت»

عقد خضراء، و200 OK من Meta، ودردشة فارغة أمام العميلة. هكذا يبدو ثاني «خلل صمت» في وكيل ذكاء اصطناعي مبني على n8n، وهو موضوع تحليل جديد نُشر على Habr. هذه ثاني حكاية من هذا النوع لدى المؤلف، وتوضح صياغتها الأمر الأهم: ظنّ النظام أنه أنجز مهمته، بينما بقي الإنسان بلا رد. الإعلان قصير، لذلك نعرض أدناه ما ورد فيه فقط، إضافة إلى الآليات العامة التي تتسبب في مثل هذه الحالات في وكلاء المراسلة.

Что известно из разбора

المعلومات الواردة في الإعلان قليلة، لكنها دالّة. أنهى workflow على n8n عمله دون أخطاء، وتحولت كل عقدة إلى اللون الأخضر. وأعاد طلب API الخاص بـ Meta الحالة 200 OK. ومع ذلك لم تر المستخدمة رد الوكيل، وكانت الدردشة فارغة. لا يحدد الإعلان القناة المستخدمة تحديدًا، ولا النقطة في السلسلة التي اختفى عندها النص. تبقى التفاصيل في النسخة الكاملة من المقال على Habr.

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

Где обычно прячется тишина

لهذا العَرَض عدة أسباب شائعة. لا يُعرف أيٌّ منها حدث في هذه الحالة، لكنها جميعًا تعطي الصورة نفسها: «كل شيء أخضر ولا يوجد رد».

• الرمز 200 يعني الاستلام، لا التسليم. عادةً ما تقبل واجهات API الخاصة بتطبيقات المراسلة الرسالة في طابور، ثم تُبلغ بمصير التسليم لاحقًا عبر webhooks منفصلة لحالات التسليم.
• مخرجات نموذج فارغة أو تالفة. قد يعيد LLM سلسلة فارغة أو JSON مبتورًا أو علامة خدمية بدل النص. وهي بالنسبة إلى n8n بيانات صالحة، فتعمل عقدة الإرسال بشكل طبيعي.
• قيود المنصة. لدى تطبيقات المراسلة نوافذ للرد، ومتطلبات للقوالب، وقواعد للإشراف على المحتوى. قد تُقبل الرسالة دون أن تُعرض للمستخدم.
• حقل خاطئ في التعبير. إذا كانت عقدة الإرسال تأخذ النص من مسار غير موجود في البيانات، فسيضع n8n قيمة فارغة دون أي خطأ.
• تعارضات التزامن والتكرار. قد تؤدي webhooks المكررة وعمليات التشغيل المتوازية وذاكرة الحوار المشتركة إلى محو الرد قبل إرساله.

يجمع هذه الأسباب كلها قاسم واحد: يُقاس النجاح من جهة البنية التحتية، لا من جهة الإنسان.

Как ловить такие баги

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

ثانيًا: عدم اعتبار 200 OK نهاية المطاف. ينبغي حفظ حالات التسليم القادمة من webhooks ومطابقتها مع الرسائل الصادرة عبر المعرّف. وتتحول أي رسالة لا يصلها تأكيد «تم التسليم» خلال مدة محددة إلى حادثة.

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

رابعًا: إعداد Error Workflow في n8n مع fallback مستقل. إذا صمت الوكيل، يتلقى العميل رسالة قصيرة: «استلمنا رسالتك وسنرد في أقرب وقت»، ويتلقى المشغّل إشعارًا يتضمن سياق الحوار.

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

تُظهر القصة المنشورة على Habr بوضوح درسًا عامًا في تشغيل الوكلاء: تُقاس الموثوقية بما رآه المستخدم، لا بما عرضته لوحة مراقبة المُنسِّق (orchestrator).