Przetrwanie składania: drabina dla długotrwałych sesji agentów i kompresji

Alpiniści nie wnoszą całej ekspedycji na górę; ukrywają ją tam. Długi wspinaczka jest dzielona na obozy, z których każdy jest zaopatrzony w to, czego potrzebuje następny etap. Wszystko, czego nie potrzeba, pozostaje poniżej, dostępne w razie konieczności powrotu, ale nigdy nie jest wnoszone wyżej. To, co dociera na szczyt, to to, co przetrwało decyzję każdego obozu o tym, co pozostawić w tyle.

Okno kontekstowe zachowuje się w ten sam sposób. Pojemność jest stała, trasa nie, więc prędzej czy później coś musi zostać pozostawione.

Cacheowanie promptów dało już jedną zasadę dotyczącą narzędzi agenta: nigdy nie unieważniać cache’u. Zachować stabilną część w stanie aktywnym i odkładać zmiany na koniec. Ta zasada traktuje sesję jak zdjęcie statyczne, mimo że sesje mają wymiar czasu. Każda sesja się starzeje. Rozmowa rozwija się, aż okno się wypełni i będzie musiało zostać złożone.

Złożenie zmniejsza rozmiar okna; to aspekt mechaniczny. Cena jest mniej oczywista, ponieważ proces zginania zmusza do unieważnienia pamięci cache. Opłata jest pobierana raz, a to, co przeżyje, jest przepisywane, a sesja trwa dalej. Mimo to unieważnienie jest kwestią drugorzędną. Kluczowe jest to, co zostanie wybrane i przetrwa. Dobra kompresja to nie tylko usuwanie – sprowadza historię do formy, z której agent może kontynuować pracę. A długa sesja nie jest zginana tylko raz. Jest zginana, działa, zginana ponownie, i prędzej czy później zostaje złożona jeszcze raz.

To zmienia kwestię planowania. Pytanie o to, kiedy przeprowadzić kompresję, ma mniejsze znaczenie niż pytanie o to, co pozostaje po wielokrotnych rundach składania oraz co zostało utracone do tego czasu. Czas jest kwestią kosztów, ponieważ za każdą nieważność pobierana jest opłata. Jakość kompresji jest kwestią tożsamości, ponieważ decyduje o tym, czy sesja później nadal jest tą samą, która się rozpoczęła. Z tych dwóch powodów kompresja powinna znajdować się na szczycie hierarchii, a nie na dole.

Gdzie gromadzą się opłaty

Każda prośba dzieli się na dwie strefy rozliczeniowe. Jedną jest prefiks, który przetrwa z rundy na rundę. Drugą jest tył, który stale się powiększa.

Prefiks zawiera komendę systemu, definicje narzędzi, kontekst stabilnego repozytorium oraz pliki z regułami. Jest zapisywany raz, przechowywany w pamięci cache, a później odczytywany za niewielką część pierwotnej ceny. Jego rozmiar pozostaje niezmienny.

Cały „ogon” to to, co następuje później: dialog, wywołania narzędzi, ich wyniki, bloki myślowe oraz różnice. On tylko się rozszerza.

Jednak to nie rozszerzanie jest problematyczne. Problemem jest wielokrotne ładowanie. Nowa wiadomość nie przemieszcza się sama – system ponownie wysyła odpowiedni prefiks, opłaca koszt odczytu z pamięci cache oraz dopłatę za zapis nowego materiału, a cały „ogon” jest przenoszony przy każdym takim odczycie. Dlatego 150 000 tokenów „ogona” to nie bezczynny balans znajdujący się w oknie; jest ponownie naliczane przy każdym kroku, niezależnie od tego, czy model potrzebuje ich do następnego pytania. Stara historia jest faktycznie wypożyczana na cały czas trwania sesji.

W oknie o pojemności 200 tysięcy tokenów duża część przestrzeni jest już zajęta. W zależności od używanego systemu oraz kilku innych czynników, ilość rzeczywiście dostępna do użytku może spaść do około 7,5 tysiąca do 15 tysięcy tokenów.

Kasynki również wygasają. Aktywność odświeża czas trwania, co oznacza, że przerwa może sprawić, iż kolejna operacja stanie się zapisem „chłodnym”. Czas spędzony przez człowieka na myśleniu to ukryty koszt korzystania z kasynki, o którym nikt nie mówi.

Patrząc w ten sposób, kompresowanie danych w części końcowej to również operacja na kasynce. Jednorazowy koszt unieważnienia danych jest zamieniany na koniec obowiązującej opłaty za ich przechowywanie. To cała umowa, a istnieją tańsze sposoby postępowania przed podjęciem takiej decyzji.

Drabina z pięciu kroków

Istnieje pięć sposobów na ograniczenie wzrostu danych w części końcowej. Są to mniej alternatyw niż szczeble drabiny – im wyżej się wspinamy, tym bardziej zakłócana jest istniejąca historia danych.

Pierwszy krok: nigdy go nie generuj. Ogranicz wynik w narzędziu. Narzędzie edytora tekstu Anthropic obsługuje parametr max_characters, a jego funkcja wyszukiwania w sieci – parametr max_uses. Codex domyślnie ogranicza wyniki poszczególnych narzędzi do około 10 000–16 000 tokenów, zanim zostaną one włączone do obliczeń kompresji. Bardziej dyscyplinowaną metodą jest wycinek: zachowuje się początek i koniec tekstu, a środek odcina, w założeniu, że sposób rozpoczęcia i zakończenia polecenia są ważniejsze niż treść pomiędzy nimi. Wadą jest urywanie tekstu, zanim dowiemy się, co jest istotne, a brak odpowiedniego śladu wywołań jest gorszy niż jego całkowity brak.

Drugi etap: przechowaj to. Jeśli cała obserwacja nie jest potrzebna, nie przechowuj jej. Gdy wynik narzędzia przekracza określony próg wielkości, system zapisuje go na dysku i pozostawia odnośnik. Pełny artefakt przetrwa, podczas gdy żywy kontekst nie. Różni się to od skracania, ponieważ nic nie jest wyrzucane. Log budowy zawierający 500 tysięcy wierszy może pozostać na dysku, podczas gdy kontekst zawiera jedynie jego ścieżkę, metadane lub indeks do wyszukiwania, a później narzędzie do wyszukiwania lub odczytu pobiera tylko odpowiedni fragment. Zachowaj artefakt, usuń obserwację. Dzięki temu przechowywanie i kontekst są czysto oddzielone, dzięki czemu informacje pozostają trwałe, bez konieczności płacenia „czynszu” w kolejnych etapach.

Problem polega na tym, że narzędzie to musi zapewnić sposób na ponowne odnalezienie tego treści. Zapisywanie na dysku jest korzystne tylko wtedy, gdy agent może przeszukać to, co zostało zapisane, przeczytać to i zrozumieć jego treść; bez tego nadmiar kontekstu zamienia się w system plików pełen nieodzyskiwalnych danych.

Warto zauważyć podobieństwa pomiędzy tymi narzędziami. Claude Code zapisuje na dysku każdy wynik narzędzia dłuższy niż około 100 tysięcy znaków, przekazując jednocześnie wstępny przegląd oraz ścieżkę do tego pliku, natomiast Hermes stosuje tę samą granicę 100 tysięcy znaków na każdy wynik. Obie platformy przewidują tę samą wyjątkową sytuację dla narzędzi do odczytu – jeśli odczytanie treści powoduje jej zapis na dysku, agent będzie ją czytał w kółko, ponieważ ścieżka ta jest ciągle odczytywana. Takie błędy są łatwe do popełnienia. Jedynym narzędziem, którego celem jest przywracanie treści, jest to, które w żadnym wypadku nie powinno jej zapisywać.

Trzeci etap: utrzymanie informacji wewnątrz. Przekazuj zadanie podagentowi. Wyposażony w standardowe narzędzia systemu, może czytać pliki, przeglądać logi oraz analizować repozytorium, gromadząc obszerny prywatny kontekst, przy czym nic z tego nie trafia do strumienia danych głównego agenta. Gdy zadanie zostanie zakończone, jego okno jest usuwane, a przekazywany jest jedynie wartość zwrotna. Dostawcy systemu Harness uczynili to jedną z najczęściej wdrażanych funkcji w tym roku.

Istnieje tu ograniczenie, ponieważ eksploracja jest bezpieczniejsza niż zmienianie rzeczy. Pracownik, który czyta niewłaściwe pliki, jedynie zmusza do ponownego uruchomienia. Pracownik, który edytuje niewłaściwe pliki, pozostawia szkody po zakończeniu swojej pracy, więc ma znaczenie, któremu modelowi powierza się zmiany. Stare armie to ilustrują: zwiadowcy to szybcy, taniości ludzie wysyłani naprzód, ponieważ obserwacja jest niewielkim kosztem, a raport można sprawdzić, natomiast prawdziwe, decydujące działania powierzano najlepszym dowódcom, ponieważ nie da się ich cofnąć. Ta sama podziałka obowiązuje tutaj. Zleć zwiad tanemu, tymczasowemu kontekstowi, zachowaj najsilniejszy model na krok, który zmienia świat, i niech rodzicowy element bierze udział w weryfikacji. Rodzicowy element płaci za odpowiedź, a nie za dochodzenie.

Czwarty etap: zastąp to wskaźnikiem. Jeśli treść jest już trwale przechowywana, czy to jako plik, artefakt, wygenerowany raport czy wynik obliczeń, rozmowa potrzebuje jedynie odniesienia do niej. Ponowne sprawdzenie oznacza udanie się tam, gdzie znajduje się ten materiał, a nie noszenie go ze sobą. Narzędzie do przechowywania informacji w Anthropic robi dokładnie to, a OpenAI umożliwia podobne działanie poprzez wywoływanie funkcji. Drogi stan rozmowy staje się wtedy tanim odniesieniem do trwałego stanu. Istnieje jednak jedna zastrzeżenie: oszczędności te obowiązują tylko tak długo, jak długo podstawowa treść pozostaje poza zakresem widoku. Gdy zostanie ponownie przeczytana, znów staje się „ogonem” i natychmiast zaczyna generować koszty.

Piąty stopień: usuń go później. Usuń, skompresuj lub złoż. Tylko ten stopień unieważnia to, co zostało już zapisane w pamięci podręcznej. Każdy ruch polega na zamianie zgromadzonej historii na coś mniejszego, w nadziei, że następny ruch będzie mógł od tego wyjść. Pełny zapis może pozostać na dysku, ale żywy kontekst jest inny.

Od tego momentu aspekty ekonomiczne przekształcają się w zakład. Czy oszczędzona opłata za korzystanie z pamięci podręcznej przez resztę sesji przewyższa koszt przepisania historii teraz? Wcześniejsze skompresowanie oznacza utratę użytecznej pamięci podręcznej, która mogła służyć do przeprowadzenia setek tanich ruchów. Późne skompresowanie oznacza, że opłata została już zapłacona za ogromną ilość historii, podczas której model mógł już stać się gorszy w jej wykorzystywaniu. Większość rozmów na temat długich sesji zaczyna się od tego pytania, choć nie powinno tak być. Pięć stopni w kolejności:

1. Nigdy tego nie twórz: zatrzymaj rozwój „ogona” na etapie źródłowym.
2. Ujawnij to: usuń objętościowe obserwacje i zatrzymaj artefakt.
3. Zachowaj to na zewnątrz: przenieś dochodzenie do innego kontekstu.
4. Wskazuj na to: zostaw tani odniesienie w rozmowie.
5. Usuń to później: skompresuj lub złoż, i żyj z tą stratą.

Najtańszy kontekst to nie kontekst skompresowany. To kontekst, który w ogóle nie musiał istnieć.

Zestawy narzędzi jako zakład na to, gdzie zapłacić

Ma znaczenie, gdzie znajduje się definicja narzędzia. Definicje zajmują prefiks – stałą opłatę, która jest zapisywana raz i przechowywana w pamięci. Wyniki zajmują tył – zmienną opłatę, która jest pobierana ciągle. Wybór zestawu narzędzi jest więc zakładem na to, która strefa powinna pokryć koszt informacji. Niewiele narzędzi oznacza mały prefiks, ale więcej surowych obserwacji w części tylnych; wiele narzędzi oznacza dodatkowe tokeny prefiksu, które muszą zostać wydane, aby otrzymać mniejsze, bardziej ustrukturyzowane obserwacje.

Terminus 2 to skrajna forma minimalizmu: jeden bezgłowy terminal, oparty na przekonaniu Unixa, że jeden uniwersalny narzędzie może być tworzone bez ograniczeń. Codex jest często z nim łączony, co jest tylko częściowo słuszne. Jego domyślny przedrostek wcale nie jest mały – zawiera około 20 narzędzi dostępnych stale, zestaw narzędzi wieloagentowych oraz wersje v1/v2. Unika nadmiaru poprzez odkładanie operacji, indeksowanie narzędzi MCP i połączeniowych w silniku wyszukiwania oraz ich ładowanie w momencie potrzeby. Codex faktycznie stawia swoje minimum na część o mniejszym znaczeniu. apply_patch ilustruje to, ponieważ krótki raport różnic zastępuje tysiące tokenów przepisanej treści pliku, a ograniczenia ilości wyjścia każdego narzędzia zapobiegają gromadzeniu się surowych danych. Oba rozwiązania dochodzą do podobnych rezultatów różnymi drogami: Terminus 2 utrzymuje mały przedrostek, natomiast Codex – małą część o mniejszym znaczeniu.

Claude Code i Hermes przeznaczają większą część zasobów na specjalistyczne narzędzia, które zwracają ustrukturyzowane dane zamiast surowych informacji. Katalog Claude Code przekracza 40 pozycji, jeśli uwzględni się LSP, tryb planowania, worktrees oraz cron, natomiast Hermes osiąga około 55 pozycji, podzielonych na zestawy narzędzi dla terminala, plików, pamięci, umiejętności, delegacji i innych celów. Wzorcem jest użycie Grep do zwracania dopasowań zamiast całego pliku: to pozwala uniknąć tysięcy tokenów niepotrzebnego tekstu na końcu wyniku.

Porównanie, które należy przeprowadzić, nie dotyczy liczby narzędzi. Chodzi o to, czy dodatkowe wydatki na prefiksy wystarczają, by zahamować dalszy wzrost długości komunikatów i opóźnić ich składanie. To ta sama kwestia kompromisu pomiędzy szybkością a optymalizacją, zastosowana na wyższym poziomie. Anthropic jasno to formułuje: definicje narzędzi mogą być odkrywane w momencie potrzeby, zamiast być zawierane przy każdej prośbie. Claude Code robi to za pomocą mechanizmu ToolSearch, który pozostawia nazwy narzędzi odkładanych do późniejszego użycia widoczne, a pełne schematy ukrywa, dopóki model o to nie poprosi; mechanizm ten aktywuje się automatycznie, gdy definicje narzędzi MCP stanowią około 10% okna kontekstowego. Nawet kolejność jest dobrać tak, by chronić prefiks – sortowanie alfabetyczne sprawia, że blok definicji pozostaje identyczny pod względem rozmiaru między kolejnymi interakcjami, a więc może być przechowywany w pamięci podręcznej. Prefiks jest zaprojektowany tak, by pozostać aktywny, niezależnie od swojej wielkości.

Oś zachowuje swoją użyteczność, ale jej rola się zmienia. Nie decyduje o kompresji. Decyduje o tym, ile historii najpierw się gromadzi. A ta historia nie jest jednorodna. Wyniki wyszukiwania można często odtworzyć, natomiast decyzje nie. Ścieżkę pliku można odbudować, natomiast powód odrzucenia danej metody może pozostać nieznany. Im dłużej trwa sesja, tym droższe staje się mylenie tych dwóch rodzajów pamięci.

Delegacja jako granica pamięci

Delegacja wyróżnia się jako element, który pozbywa się historii, nie naruszając przy tym pamięci cache rodzica, i co jest cenniejsze niż zniżka na wykonywanie zadań. Podagent ma własne okno kontekstowe. Może mieć ogromny „ogon”, wypełnić to okno, skompresować dane wewnętrznie, a następnie zniknąć, wszystko to bez przepisywania ani jednego słowa z historii rodzica.

Trzeba skorygować powszechnie przyjęte założenie. Kuszące jest wyobrażenie sobie rozgałęziania się w ramach tego samego modelu, przy którym potomek odziedzicza zgromadzony „ogon” rodzica wraz z jego „ciepłym prefiksem”. W większości sprawdzanych implementacji tak nie jest. Claude Code, OpenCode, Codex i Hermes uruchamiają oddzielne konteksty pracowników, a nie kopię całego „ogona” rodzica. Niektóre z nich mogą używać innego modelu – Codex stosuje alternatywny model w momencie uruchomienia, natomiast Claude Code pozwala każdemu podagentowi wybrać między sonetem, operą czy haiku. To jednak nie jest regułą ogólną, a mechanizm delegowania w Hermesie nie oferuje bezpośredniej możliwości zmiany modelu. To, co przechodzi pomiędzy różnymi rozwiązaniami, to oddzielny kontekst, a nie wybór modelu.

To wskazuje na coś większego niż zwykłe rozdzielanie zadań. Odpadająca część może przeczytać czterdzieści plików, przeanalizować logi i ustalić konwencję nazewniczą, a cały kontekst znika, gdy pojawia się nowy akapit. Delegowanie pełni rolę granicy pamięci – nadzorca przydziela zadanie i określa, czego jest potrzeba, co stanowi swego rodzaju uprzednią kompresję, ponieważ wykonawca wie, kto będzie czytał jego wyniki oraz jaką decyzję muszą one wspierać. Gdy podagent wraca, nadzorca zwykle sprawdza wynik. Takie postępowanie wymaga kilku kroków, ale jest rozsądne.

Kompakcja odbywa się w odwrotnym kierunku, już po fakcie. Musi ona streszczać treść dla czytelnika, który jeszcze nie istnieje, unikając w ten sposób ewentualnych pytań, które mogą pojawić się później. Kompresja przeprowadzona z wyprzedzeniem ma tę zaletę, że czytelnik jest już znany. To prowadzi do zasady budżetowania: należy przewidzieć budżet na to, co zostanie zwrócone, a nie na sam proces. Pracownik może wydać setki tysięcy tokenów, a żaden z nich nie stanie się pamięcią nadrzędną. Tekst zwrócony natomiast staje się pamięcią. Czterysta tokenów odpowiedzi trafia do „ogona” pamięci nadrzędnej i jest naliczanych przy każdym kolejnym kroku, więc w trakcie długiej sesji surowa różnica może kosztować więcej niż drogi pracownik, który zwraca jedno użyteczne zdanie. Badanie jest tymczasowe, a odpowiedź staje się historią, a ta odpowiedź z kolei musi przetrwać proces foldowania.

Co oferują platformy

Platforma modelu określa, ile z tych mechanizmów harness musi sam zbudować.

Anthropic oferuje dwa rodzaje pomocy skierowanej do różnych problemów. Pierwszy, clear_tool_uses_20250919, jest precyzyjny. Gdy prompt przekroczy określony próg (domyślnie 100 tys. tokenów wejściowych, przy czym zachowuje się trzy najnowsze użycia narzędzia), usuwa stare wyniki narzędzia na serwerze i umieszcza w każdym miejscu zastępczy element. Opcja clear_at_least rozkłada koszt anulowania, wymagając usunięcia minimalnej ilości danych. Drugi rodzaj, compact_20260112, polega na intensywnym przetwarzaniu: pełnej sumaryzacji po stronie serwera, która tworzy nową wersję rozmowy, a nie tylko jej fragment w istniejącej.

Claude Code to dobry przykład do analizy, ponieważ nawet pasek narzędziowy stworzony przez firmę dostarczającą te elementy wydaje się samodzielnie koordynować swój cięższy wariant /compact po swojej stronie. Wsparcie dla tego rozwiązania pochodzi z działań społeczności zajmującej się inżynierią wsteczną, które wywodzą się z jednego udostępnionego na GitHubie źródła kodu, a nie z publicznej dokumentacji Anthropic. Czyszczenie danych odbywa się na serwerze, natomiast decyzja o tym, który stan rozmowy zostanie zachowany, jest podejmowana przez klienta.

OpenAI koncentruje się na kompresji. Jego endpoint /v1/responses/compact zwraca zaszyfrowany, nieprzejrzysty blok danych, który klient odsyła bez sprawdzania jego zawartości, częściowo po to, by zablokować metodę wstrzykiwania poleceń, w której sfałszowany streszczenie mogłoby wpłynąć na dalszy przebieg procesu. Nic w tym nie odpowiada precyzyjnemu usuwaniu niepotrzebnego materiału, więc Codex musi sam zarządzać rozmiarem wyników generowanych przez narzędzia, a poniżej obu ścieżek znajduje się prosty plan awaryjny: jeśli okno nadal się przepełni, Codex usuwa najstarszy element historii i próbuje ponownie.

DeepSeek oferuje znacznie mniej funkcji związanych z zarządzaniem kontekstem. Jego cacheowanie prefiksów po stronie serwera obniża koszty, ale nie rozwiązuje problemu stałego okna czasowego, więc każde narzędzie wykorzystujące tę technologię musi samodzielnie obsłużyć cały proces kompresji. Oficjalne narzędzie DeepSeek tworzy takie rozwiązanie i robi to bez niszczenia żadnych danych – zdarzenia zapisane w cieniu pozostają w dzienniku i można do nich uzyskać dostęp. Jedna z interfejsów terminali od dostawcy trzeciego strony, którą sprawdzono, pomija ten proces i nigdy nie kompresuje danych proaktywnie.

Ważna nie jest jakość pojedynczego punktu końcowego do kompresji API, lecz to, kto jest odpowiedzialny za decydowanie o tym, co zostanie zachowane. Hermes stanowi interesujący przypadek graniczny, ponieważ obejmuje kilku dostawców i nie może zakładać, że któryś z nich oferuje odpowiednie elementy budulcowe. Dlatego jako punkt odniesienia używa własnego kompresora po stronie klienta, opartego na dwóch progu: 50% według własnego rozliczania tokenów oraz 85% według bardziej ogólnego sprawdzenia na poziomie bramy, które wykrywa sesje rosnące pomiędzy kolejnymi działaniami, gdy nikt ich nie obserwuje. Gdy aktywny dostawca ma lepsze rozwiązanie, odkłada realizację.

To jest rozsądny ogólny projekt. Narzędzie powinno domyślnie zajmować się kompresją, ponieważ posiada informacje, których serwer może nigdy nie zobaczyć, i przekazywać je platformie, gdy ta na to zasłuży. Bez względu na to, kto wykonuje kompresję, pytanie pozostaje takie samo: co można przyjąć jako do zapomnienia?

Powrót do obozu

Wszystko powyższe zakładało, że sesja nigdy się nie zatrzymuje. Sesje jednak się zatrzymują – laptopy się zamykają, procesy ustają, zadania CI się kończą, a ktoś wpisuje /resume, oczekując, że kontynuacja będzie tak sama jak wcześniej.

To najprostszy polecenie, które może doprowadzić do najdroższego powrotu do sesji. Składa się z siedmiu znaków, wliczając średnik, i przypomina /help lub /clear; nie wymaga argumentów, potwierdzenia ani żadnych dodatkowych działań. Nic w nim nie wskazuje na jego koszt, a interfejs jest tak zaprojektowany, że powrót wydaje się bezkosztowy.

Rozmowę można przywrócić, ale pamięć cache nie. Sesja wznowiona nie jest procesem, który został tylko wstrzymany. System odtwarza transkrypcję z dysku i odbudowuje historię wiadomości, dzięki czemu dialog wraca z pamięci przechowywania, natomiast „ciepły prefiks” nie. W rezultacie występują dwa różne koszty przywrócenia.

Pierwszym elementem jest pieniądz. Cache prefiksów w Anthropic działa domyślnie przez pięć minut, lub godzinę, jeśli zakupiono wersję o większej pojemności, a odświeża go jedynie aktywność. Przerwa to czas bezczynności doprowadzony do skrajności – okres, w którym w ogóle nie ma żadnego procesu. Prefiks, który wcześniej był tani, wraca w stanie całkowicie niewykorzystanym, a następna transakcja wymaga zapłacenia pełnej ceny jego odbudowy. Najdroższym przypadkiem jest przywrócenie sesji, która trwała kilka dni, co stanowi dobry powód do ostrożnego zarządzania sesjami.

Drugim elementem jest informacja. Gdy transkrypcja przekracza dostępną przestrzeń, system może musieć ją skompresować przed podjęciem jakiejkolwiek nowej akcji. Jest to szczególnie ryzykowne, ponieważ kompresja następuje zanim ktokolwiek zdąży ponownie ustalić, co jest ważne. Ograniczenie, które wyjaśniało wcześniejszy wybór, może być obecne w transkrypcji, ale nie w wersji skompresowanej. Agent kontynuuje działanie z mniejszą przestrzenią i wiarygodną historią, niekoniecznie tą, która sprawiła, że wcześniejsze decyzje były sensowne.

Wszystko, co przetrwa złożenie, przetrwa również odnowienie, i to stanowi silniejszy argument na rzecz trwałego stanu. Zasady znajdujące się u korzenia projektu mogą zostać ponownie załadowane z dysku, pliki można ponownie przeczytać, listę zadań można odbudować, a wygenerowany log budowy można przechować i do niego odwoływać się. Decyzja, która istnieje tylko w trakcie rozmowy, nie ma żadnego zewnętrznego źródła. Jeśli przetrwała jedynie dlatego, że została zapisana w transkrypcji, musi zostać ponownie wprowadzona po powrocie, a jeśli złożenie ją usunęło, może zostać na zawsze utracona.

Zatem ranking dotyczy zarówno trwałości, jak i ceny. Od najtrwalszych do najbardziej kruchych: stan, który można odbudować, trwały stan zewnętrzny, żywy stan rozmowy, a następnie tymczasowe obserwacje. Im niżej znajduje się dany element, tym bardziej jest narażony na złożenie.

Dwa sposoby, w jakie zawodzi złożenie

Proces składania zawodzi na dwa sposoby. Ten wyraźny jest łatwy do zauważenia – kompresja działa, po czym ogromna ilość wyników natychmiast wypełnia okno, pasy kompresują się ponownie, pojawiają się te same wyniki i cykl się powtarza, jakby próbowało się wyciągnąć wodę z łodzi, jednocześnie wiercąc w niej dziurę. Claude Code rezygnuje z ponawianych prób zamiast marnować zasoby w nieskończonym cyklu, dzięki wbudowanej logice, która wykrywa, że program utknął i nie robi postępów. To jest właściwe zachowanie, ale sam cykl jest sygnałem, że używany jest niewłaściwy sposób działania. W idealnym przypadku agent cofa się i próbuje innego podejścia, zamiast ponawiać użycie tej samej narzędzia. Jeśli jeden zbyt duży plik ciągle zmusza do kompresji, niższy próg nie jest rozwiązaniem; skuteczne będą natomiast czytanie ograniczonej liczby wierszy, wyszukiwanie w ograniczonym zakresie, skupienie się na trwałych wynikach lub przekazanie pliku podagentowi, którego okno może zostać utracone. Zawsze, gdy rozpoczyna się dostosowywanie kompresji, zapytaj, czy rozwiązanie leży o trzy poziomy wyżej, czy też w zupełnie innym podejściu.

Powolna awaria jest bardziej subtelna. Kompresja traci informacje, a długie sesje nigdy nie kompresują się tylko raz. Kompresują, pracują, ponownie kompresują, pracują, jeszcze raz kompresują: podsumowania nałożone na siebie.

Kilka warstw nałożonych na siebie

Pierwsze ujęcie może być doskonałe, a mimo to prowadzić do słabego trzeciego. Drugi podsumowujący nigdy nie widzi oryginalnej historii, tylko reprezentację wybraną przez pierwszego podsumowującego. Trzeci nie widzi żadnego z nich, tylko werdykt drugiego na temat werdyktu pierwszego. Zobacz, jaki to ma wpływ na fakty w porównaniu z powodami. Pierwsze ujęcie mogłoby zachować informację „wybrano podejście B”. Drugie mogłoby zachować informację „B to obecna implementacja”. Trzecie mogłoby zachować informację „implementacja wykorzystuje B”. Każda z tych informacji jest prawdziwa, ale powód odrzucenia podejścia A zniknął. System nie stracił decyzji – stracił to, co sprawiało, że decyzja była zrozumiała, a to właśnie jest specyficzną szkodą spowodowaną wielokrotnym podsumowywaniem.

Co powinno przetrwać

W różnych systemach strukturalne podsumowania skupiają się mniej więcej w tych samych kategoriach:

• Intencja: co ma zostać osiągnięte?
• Stan: co zostało dowiedziane lub zmienione?
• Praca i zadania do wykonania: co zostało zrobione, a co pozostaje?
• Niezałatwione kwestie: które pytania są nadal nierozstrzygnięte, ograniczone lub poddawane ocenie?

Etetykiety różnią się w zależności od narzędzi, ale struktura jest podobna, co wskazuje, że jest to bliskie najmniejszemu praktycznemu stanie, który sesja musi zachować. Niektóre narzędzia dodają również kroki przywracania plików, aby zbiór danych roboczych mógł zostać ponownie załadowany po zapisaniu.