Miten tämä tapahtuu OpenClawin kanssa ja miten sen voi mahdollisesti korjata... Bottini dumppaa jatkuvasti valtavia toistuvia työkalutuloksia, tekee raskasta johtamistyötä ja joutuu debug-silmukoihin yhteisessä sessiossa, jossa pelinjohtajani ovat, ja jää jumiin 10 minuutiksi kerrallaan, kunnes aikakatkaisu tai gateway kaatuu ja käynnistyy uudelleen. Tämä aiheuttaa viestien putoamisen, vastaamattoman botin ja OOM:n kaatumisen useita kertoja tunnissa. Vaikka saan botin delegoimaan, aliagentit dumppaavat tulokset konteksti-ikkunaan. Pyysin Codexia tutkimaan ja se löysi: • 56 työkalun tulosta ≥150 000 hahmoa, jotka on jo sisällytetty nykyiseen istuntohistoriaan • Karsinta ei toimi päämallipolullamme (Codex/OpenAI Oauth) • Ei ajonaikaista valvontaa, joka estäisi suuret työkalujen dumppaukset kontekstiin • Istunnon ylläpito siivoaa vaurioiden jälkeen, se ei estä sitä Olen melko varma, että oletus OpenClaw-toiminta ei saisi olla 200 000 hahmotyökalun tulosten lataamista transkriptiin. Jokin omassa kokoonpanossani täytyy olla joko suojamekanismin poistamista käytöstä tai työkalun tulosten katkaisun ohittamista... Koska käytän häviötöntä kynttä, se saa kasvaa vielä huonommin: 81MB istuntotiedosto, 31,6MB on vain työkalun tulosteksti 😬 169 työkalun tulosta yli 50 000 hahmoa. Yksi on 285 000 hahmoa (vuodesta sessions_list.) On olemassa karsintalogiikkaa, joka leikkaa työkalun tuloksia kontekstiviestien perusteella. buildContextPruningFactory Mutta mallien täytyy olla "cache-ttl" Kelpoiset palveluntarjoajat ovat ilmeisesti vain: Anthropic Moonshot zai Minulle bottini kertoo, että leikkauskoodi kieltäytyy aktivoitumasta ei-antropisilla palveluntarjoajilla. Käytän paljon openai-codex 5.3:a, joten kun karsinta on konfiguroitu, koodi on olemassa, mutta se ei koskaan aktivoidu. OpenAI Responses API käyttää palvelinpuolen tiivistämistä, ja OpenClaw mahdollistaa tämän automaattisesti suorille openai-malleille, jolloin OpenAI hoitaa tiivistämisen omalta puoleltaan. Mutta olen openai-codex/*:ssa, en openai/*:ssa. Codex OAuth -polku kulkee eri ajonaikaisen (ilmeisesti pi-ai) kautta, ei Responses API:n kautta. Joten: • cache-ttl-karsinta > vain anthropinen • OpenAI:n palvelinpuolen tiivistäminen > suora openai-rajapinta • LCM/lossless-claw > ei leikkaa vanhojen työkalujen tuloksia, tietääkseni Botini väittää, ettei openai-codex -kaista saa kumpaakaan leikkausreittiä. Joten minulle jää botti, joka luottaa hätäkatkaisutoimintoon truncateOversizedToolResultsInSession aivan liian usein viimeisenä keinona ylivuodon palautukseen ilman ennaltaehkäiseviä karsintaa tai turvatoimia. Koska LCM/lossless-clawilla ei ole omaa työkalutulosten hallintaa, se perii valtavat ylisuuret transkriptiot ja joutuu tekemään erityisen kovasti töitä tiivistääkseen DAG-solmuja. Minulla ei ole istuntojen ylläpitoa ja pitkiä istuntoja, joten mikään ei rajoita transkriptiota ajan myötä, mikä johtaa: 4 707 työkalun tulosta kasaantuu loputtomasti 81 Mt tiedostoon, eikä mikään ajonaikainen mekanismi oikeasti puhdista niitä. Kun bottini alkaa debuggata, se alkaa grepata ja syöttää valtavaa tekstiä pääsessioon, jää jumiin siihen silmukkaan ja kuolee ja joutuu tekemään sen uudelleen, mikä pahentaa ongelmaa. En tiedä, miten ratkaista tämä ongelma, se on monikerroksinen.

@quinnzeda Mutta saatat olla oikeassa... Saatan kuitenkin joutua pitämään viikon tauon ennen kuin kokeilen tätä.