هنا مربط الفرس. آلية الانتقال الاحتياطي في Hermes ليست "دائمة" للجلسة بأكملها. إنها تعمل لكل دورة محادثة (per-turn). هذا يعني أنه في كل مرة تكتب فيها سؤالاً جديداً (Turn جديد)، يقوم Hermes بالتالي:
طالما أن سبب المشكلة الأصلي في النموذج الرئيسي لم يُحل، ستستمر هذه الدورة في التكرار مع كل رسالة جديدة. أنت تشهد نظاماً يعمل بكفاءة وهو يحاول يائساً العودة لاختيارك الأول.
لحل المشكلة، يجب أن نبحث عن السبب الجذري في النموذج الرئيسي أو طريقة الاتصال به. بناءً على تفاصيل رسالتك، هناك احتمالان قويان:
لاحظ أن النموذج الاحتياطي يأتي عبر custom (مسار مخصص). هذا يثير الشك في أن كلاً من النموذجين الرئيسي والاحتياطي يعتمدان على نفس مزود الخدمة الخلفي (Gateway/Pool/API Key) الذي يواجه حالياً حظراً أو استنفاداً للحصة. في هذه الحالة، أنت تنتقل من نموذج محظور إلى... نموذج آخر محظور بشكل أساسي! لا نملك دليلاً قاطعاً على هذا من النص وحده، لكنه الاحتمال الأكثر ترجيحاً ويجب أن يكون أول ما تتحقق منه.
الخطأ الأساسي غالباً ما يكون HTTP 429 والذي يعني "طلبات كثيرة جداً". وثائق OpenClaw (التي قد تكون Hermes مبنية عليها أو تشابهها في المنطق) توضح أن هذا الخطأ لا يظهر فقط بسبب كثرة الأسئلة، بل قد يكون سببه:
HTTP 429: rate_limit_error: Extra usage is required for long context requests.بدلاً من الانتظار، إليك ما يجب أن تطلبه من مسؤول النظام لديك، أو تفعله بنفسك إن كنت تملك الصلاحية:
افحص ملف الإعدادات config.yaml:
fallback_providers لترى بالضبط إلى أين يذهب Hermes عند الفشل.شخّص الخطأ الحقيقي:
openclaw gateway probe لترى رسالة الخطأ الفعلية التي تأتي من المزود. هل هي 429 فعلاً؟ أم خطأ مصادقة؟عالج السبب الجذري:
~/.hermes/.env أو ~/.openclaw/.env ليتمكن النظام من قراءته تلقائياً.fallback_providers) لاستخدام مزود خدمة مختلف تماماً (مثلاً OpenRouter) بمفتاح API مختلف. هذا هو الحل الأمثل لضمان استمرارية الخدمة.ما تراه هو نظام Hermes وهو يعمل بأفضل صورة ممكنة في ظل الظروف الحالية، لكنه عالق في حلقة مفرغة لأن جوهر المشكلة لم يُعالج.
باختصار:
إذا أردت حلاً نهائياً لا يتكرر، يجب أن تصل إلى من يدير إعدادات Hermes لديك ليبدأ بفحص config.yaml وتشخيص الخطأ من جذوره هناك.