لماذا تظهر رسالة “switching to fallback” بشكل متكرر وكيف توقفها نهائياً

التشخيص: أين يكمن الخلل الحقيقي؟

لحل المشكلة، يجب أن نبحث عن السبب الجذري في النموذج الرئيسي أو طريقة الاتصال به. بناءً على تفاصيل رسالتك، هناك احتمالان قويان:

الاحتمال الأول: مشكلة في مجمع الموارد (Pool) أو المصادقة

لاحظ أن النموذج الاحتياطي يأتي عبر custom (مسار مخصص). هذا يثير الشك في أن كلاً من النموذجين الرئيسي والاحتياطي يعتمدان على نفس مزود الخدمة الخلفي (Gateway/Pool/API Key) الذي يواجه حالياً حظراً أو استنفاداً للحصة. في هذه الحالة، أنت تنتقل من نموذج محظور إلى... نموذج آخر محظور بشكل أساسي! لا نملك دليلاً قاطعاً على هذا من النص وحده، لكنه الاحتمال الأكثر ترجيحاً ويجب أن يكون أول ما تتحقق منه.

الاحتمال الثاني: أسباب فنية محددة لظهور خطأ 429

الخطأ الأساسي غالباً ما يكون

HTTP 429

• طلبات السياقات الطويلة (Long Context Requests): إذا كانت محادثتك طويلة جداً وتحتوي على سياق ضخم، فقد يرفضها المزود أو يفرض قيوداً أشد. الخطأ في هذه الحالة يكون:

  HTTP 429: rate_limit_error: Extra usage is required for long context requests

  .
• فشل المصادقة (Authentication Failures): قد يكون مفتاح API غير صالح أو منتهي الصلاحية، أو حتى موضوعاً في المكان الخطأ.
• مشاكل في التوافق (Compatibility): أحياناً تكون هناك مشكلة في طريقة إرسال البيانات بين Hermes والمزود.

دليل عملي لحل المشكلة خطوة بخطوة

بدلاً من الانتظار، إليك ما يجب أن تطلبه من مسؤول النظام لديك، أو تفعله بنفسك إن كنت تملك الصلاحية:

1. افحص ملف الإعدادات config.yaml:

   • ابحث عن إعدادات fallback_providers لترى بالضبط إلى أين يذهب Hermes عند الفشل.
   • ابحث عن إعدادات النموذج الرئيسي (Primary Model) لتحديد هويته.
   • الهدف: معرفة ما إذا كان كلاهما يستخدم نفس المزود أو البوابة (Gateway) أو مفتاح API (API Key).

2. شخّص الخطأ الحقيقي:

   • إذا كان لديك إمكانية الوصول لـ Gateway/OpenClaw، شغّل أمر الفحص والتقصي مثل

     openclaw gateway probe

     لترى رسالة الخطأ الفعلية التي تأتي من المزود. هل هي 429 فعلاً؟ أم خطأ مصادقة؟
   • دقق في السجلات (Logs) لرؤية الرسالة الكاملة للخطأ.

3. عالج السبب الجذري:

   • إذا كان 429 بسبب الحصة: انتظر حتى تعود الحصة، أو قم بترقية باقتك لدى مزود الخدمة.
   • إذا كان 429 بسبب السياقات الطويلة: ابدأ جلسة محادثة جديدة لتقليل حجم السياق.
   • إذا كان خطأ في المصادقة: تأكد من صحة مفتاح API ومن وضعه في المكان المخصص على الجهاز المضيف (host) الذي يشغّل Hermes/Gateway، وتذكر إعادة تشغيل الخدمة بعد أي تغيير. تفضل وثائق بعض الأنظمة وضع المفتاح في ~/.hermes/.env أو ~/.openclaw/.env ليتمكن النظام من قراءته تلقائياً.
   • إذا كانا يشتركان في نفس المزود المحظور: غيّر إعدادات النموذج الاحتياطي (fallback_providers) لاستخدام مزود خدمة مختلف تماماً (مثلاً OpenRouter) بمفتاح API مختلف. هذا هو الحل الأمثل لضمان استمرارية الخدمة.

الخلاصة

ما تراه هو نظام Hermes وهو يعمل بأفضل صورة ممكنة في ظل الظروف الحالية، لكنه عالق في حلقة مفرغة لأن جوهر المشكلة لم يُعالج.

باختصار:

• المشكلة: النموذج الرئيسي محظور مؤقتاً.
• سبب التكرار: آلية fallback التلقائية التي تحاول العودة للنموذج الرئيسي مع كل رسالة جديدة.
• الحل: توقف عن التركيز على رسالة "التبديل"، وابدأ بتشخيص وإصلاح سبب حظر النموذج الرئيسي (غالباً ما يكون قيود معدل بسبب حصة أو سياق طويل، أو خطأ في مفتاح API، أو اختناق في مزود خدمة مشترك).

إذا أردت حلاً نهائياً لا يتكرر، يجب أن تصل إلى من يدير إعدادات Hermes لديك ليبدأ بفحص config.yaml وتشخيص الخطأ من جذوره هناك.