Come succede questo con OpenClaw e come puoi eventualmente risolverlo… Il mio bot continua a generare risultati di strumenti massivi e ripetitivi, esegue un lavoro pesante e si blocca in loop di debug nella sessione condivisa in cui si trovano i miei DM e rimane bloccato per 10 minuti alla volta fino a quando non scade o il gateway si arresta e si riavvia. Questo causa messaggi persi, bot non responsivo e crash OOM più volte all'ora. Anche quando riesco a far delegare il bot, i subagenti scaricano risultati nella finestra di contesto. Ho fatto indagare codex e ha trovato: • 56 risultati di strumenti ≥150k caratteri già incorporati nella cronologia della sessione attuale • Il pruning non funziona sul nostro percorso principale del modello (Codex/OpenAI Oauth) • Nessuna applicazione runtime per fermare enormi scarichi di strumenti nel contesto • La manutenzione della sessione pulisce dopo il danno, non lo previene Sono abbastanza sicuro che il comportamento predefinito di OpenClaw non dovrebbe scaricare risultati di strumenti da 200k caratteri nella trascrizione. Qualcosa nella mia configurazione specifica deve disabilitare una salvaguardia o saltare la troncatura per i risultati degli strumenti… Poiché sto usando lossless-claw, è consentito crescere anche peggio: File di sessione di 81MB, 31.6MB è solo testo di risultati degli strumenti 😬 169 risultati di strumenti oltre 50k caratteri. Uno è di 285k caratteri (da sessions_list.) C'è una logica di pruning che riduce i risultati degli strumenti dai messaggi di contesto. buildContextPruningFactory Ma i modelli devono avere "cache-ttl" I fornitori idonei sono apparentemente solo: anthropic moonshot zai Per me, il mio bot mi dice che il codice di pruning si rifiuta di attivarsi su fornitori non-Anthropic. Sto usando openai-codex 5.3 molto, quindi quando il pruning è configurato, il codice esiste, semplicemente non si attiva silenziosamente. L'API delle risposte di OpenAI utilizza la compattazione lato server e OpenClaw abilita automaticamente questo per i modelli openai diretti, quindi OpenAI gestisce la compattazione dal loro lato. Ma io sono su openai-codex/*, non openai/*. Il percorso OAuth di Codex passa attraverso un runtime diverso (apparentemente pi-ai), non l'API delle Risposte. Quindi: • pruning cache-ttl > solo Anthropic • compattazione lato server OpenAI > solo API openai diretta • LCM/lossless-claw > non pota i vecchi risultati degli strumenti a mia conoscenza Il mio bot insiste che la corsia openai-codex non ottiene nessun percorso di pruning. Quindi mi ritrovo con un bot che si affida alla funzione di troncatura di emergenza truncateOversizedToolResultsInSession troppo spesso come recupero dell'overflow dell'ultima risorsa senza pruning preventivo / salvaguardie. Poiché LCM/lossless-claw non ha la propria gestione dei risultati degli strumenti, eredita enormi trascrizioni sovradimensionate e deve lavorare di più per riassumere per i nodi DAG. Non ho manutenzione della sessione e sessioni lunghe, quindi nulla limita la trascrizione nel tempo risultando in: 4.707 risultati di strumenti che si accumulano per sempre in un file di 81MB, senza alcun meccanismo runtime che li pulisca effettivamente. Quando il mio bot inizia a fare debug, inizia a cercare e scaricare enormi testi nella sessione principale, poi si blocca in quel loop e muore, poi deve farlo di nuovo, aggravando il problema. Non so come affrontare questo problema, è a più livelli.

@quinnzeda Ma potresti avere ragione... Potrei dover prendere una settimana di pausa però prima di provare questo.