كيف يحدث هذا مع OpenClaw وكيف يمكنك إصلاحه... روبوتي يخرج باستمرار نتائج أدوات متكررة ضخمة، ويقوم بعمل تنفيذي مكثف ويدخل في حلقات تصحيح في الجلسة المشتركة التي يشارك فيها مديرو اللعبة، ويبقى عالقا لمدة 10 دقائق حتى ينتهي الوقت أو تنهار البوابة وتعيد التشغيل. هذا يسبب فقدان الرسائل، وبوت غير مستجيب، وانهيار OOM عدة مرات في الساعة. حتى عندما أجعل البوت يفوض، يقوم الوكلاء الفرعيون بتفريغ النتائج في نافذة السياق. طلبت من كودكس التحقيق ووجد: • 56 نتيجة أداة ≥150 ألف شخصية مدمجة بالفعل في تاريخ الجلسة الحالي • التقليم لا يعمل على مسار النموذج الأساسي لدينا (Codex/OpenAI Oauth) • لا يوجد تطبيق لوقت التشغيل لمنع تفريغ الأدوات الضخم في السياق • صيانة الجلسة تنظف بعد الضرر، لكنها لا تمنعه أنا متأكد تقريبا أن سلوك OpenClaw الافتراضي لا يجب أن يضع نتائج أداة 200 ألف حرف في النص. هناك شيء في إعدادي المحدد يبدو إما تعطيل حماية أو تخطي القطع للحصول على نتائج الأدوات... بما أنني أستخدم مخلب بدون فقدان، يسمح له بالنمو بشكل أسوأ: ملف جلسة بحجم 81 ميجابايت، و31.6 ميجابايت هو مجرد نص 😬 نتيجة أداة أداة 169 تعطي أكثر من 50 ألف شخصية. واحدة منها 285 ألف شخصية (من sessions_list). هناك منطق تقليم يقوم بقص نتائج الأدوات من رسائل السياق. البناء السياق المصنع لكن النماذج يجب أن تكون "cache-ttl" يبدو أن مقدمي الخدمة المؤهلين هم فقط: الأنثروبي مونشوت زاي بالنسبة لي، يخبرني روبوتي أن رمز التقليم يرفض التفعيل على مزودي الخدمة غير الأنثروبيك. أنا أستخدم openai-codex 5.3 كثيرا، لذا عندما يتم ضبط التقليم، يكون الكود موجودا، لكنه لا يفعل بصمت أبدا. تستخدم واجهة OpenAI Responses API الضغط على جانب الخادم وOpenClaw تتيح ذلك تلقائيا لنماذج OpenAI المباشرة حتى تتولى OpenAI التعامل مع الضغط من جانبها. لكنني أستخدم openai-codex/*، وليس openai/*. مسار كودكس OAuth يمر بوقت تشغيل مختلف (يبدو أن pi-ai)، وليس واجهة برمجة تطبيقات الاستجابات. إذا: • تقليم كاش-ttl > الأنثروبي فقط • ضغط OpenAI على جانب الخادم > واجهة برمجة تطبيقات OpenAI مباشرة فقط • LCM/مخلب بدون فقدان > لا يحذف نتائج الأدوات القديمة حسب علمي الروبوت الخاص بي يصر على أن مسار OpenAI-codex لا يحصل على أي من مسارين التقليم. لذا بقيت مع بوت يعتمد كثيرا على وظيفة الاقتطاع الطارئ OversizedToolResultsInSession كملاذ أخير للاسترداد الزائد دون تقليم وقائي أو ضمانات. نظرا لأن LCM/المخلب بدون فقدان لا يمتلك أداة إدارة نتائج خاصة به، فإنه يرث نصوص ضخمة وكبيرة الحجم ويضطر للعمل بجد إضافي لتلخيص عقد DAG. ليس لدي صيانة للجلسة وجلسات طويلة، لذلك لا يوجد شيء يحد النص مع مرور الوقت مما يؤدي إلى: 4,707 نتائج أدوات تتراكم إلى الأبد في ملف بسعة 81 ميجابايت، دون وجود آلية تشغيل تقوم بتنظيفها فعليا. عندما يبدأ الروبوت في تصحيح الأخطاء، يبدأ في التجميع وإرسال نصوص ضخمة إلى الجلسة الرئيسية، ثم يعلق في تلك الحلقة ويموت ثم يضطر لتكرار ذلك، مما يزيد المشكلة سوءا. أنا في حيرة من أمري حول كيفية التعامل مع هذه المشكلة، فهي متعددة الطبقات.

@quinnzeda لكن قد تكون على حق... قد أضطر لأخذ أسبوع راحة قبل تجربة هذا.