أخبرني الـ Cron أن الحالة OK ولكنه لم يفعل شيئاً
الثلاثاء الماضي، قام وكيل OpenClaw الخاص بي بإجراء تدقيق أمني.
أظهرت لوحة التحكم ضوءاً أخضر. كانت الحالة: ok. لم تكن هناك أخطاء ولا تنبيهات.
لكن الوكيل لم يفعل شيئاً.
تعطل الوكيل أثناء المهمة. حدث خطأ MiniMax overload. لم يكتشف الإطار الخارجي (framework) ذلك؛ حيث رأى الإطار أن المهمة اكتملت بنجاح رغم فشل الوكيل.
لم أكتشف هذا الخطأ إلا بعد ثلاثة أيام عندما راجعت سجل الجلسة (session transcript) يدوياً.
كنت بحاجة إلى طريقة للعثور على حالات التعطل الصامتة هذه. قمت ببناء سكربت مراجعة مكون من 30 سطراً لحل المشكلة.
المشكلة
تكتشف الأطر (Frameworks) انتهاء مهلة الشبكة وفشل المصادقة، لكنها لا تكتشف ما يحدث داخل دور الوكيل (agent turn). عندما يتعطل وكيل فرعي (sub-agent)، غالباً ما يصدر النظام رسالة محددة: "[assistant turn failed before producing content]".
بالنسبة للإطار، تبدو هذه رسالة عادية، وتظل الحالة "ok". هذا هو الفشل الصامت، وهو أصعب أنواع الأخطاء التي يمكن العثور عليها.
الحل
أضفت سكربت للتحقق من محتوى السجل الفعلي بدلاً من مجرد رمز الحالة (status code).
يبحث السكربت عن سلسلة الفشل المحددة تلك. كما يستخدم تعبيراً نمطياً (regular expression) لاستخراج رسالة الخطأ الدقيقة من النص.
يتيح ذلك للسكربت إظهار السبب الحقيقي، مثل:
- overloaded_error
- rate_limit_exceeded
- context_length_exceeded
بمجرد رؤية تفاصيل الخطأ، وجدت السبب الجذري. حدثت حالات التعطل بسبب سلسلة تراجع النموذج (model fallback chain). قمت بإزالة نموذج التراجع المجاني الذي كان يسبب حالات فشل متتالية. أدى إزالته إلى جعل مهام الـ crons الخاصة بي أسرع وأكثر موثوقية.
النتيجة
يعمل السكربت الآن كل ليلة، حيث يتحقق من سجلات اليوم السابق. إذا وجد تعطلاً صامتاً، يرسل تنبيهاً إلى Telegram الخاص بي.
لم أعد أنتظر أياماً لاكتشاف الأخطاء؛ بل أراها كل صباح.
الدرس المستفاد
لوحة التحكم الخضراء لا تعني أن وكيلك قد عمل بنجاح. حالة الإطار (Framework status) ومخرجات الوكيل (agent output) شيئان مختلفان.
إذا كنت تشغل وكلاء مؤتمتين، فلا تعتمد على رموز الحالة وحدها. تحقق من السجلات (transcripts). ابنِ أداة للتحقق من السجلات نيابة عنك. الفشل الصامت هو النوع الذي يسبب أكبر قدر من الضرر.
مجتمع تعليمي اختياري: https://t.me/GyaanSetuAi