Retrieval pobierzesz na nowo.
Historię własnych kroków agent ma tylko raz.
W poprzednim wpisie ustaliliśmy, że wiedzę z zewnątrz najlepiej pobierać na żądanie — bo zawsze możesz sięgnąć po nią ponownie. Ale jest część kontekstu, która tej własności nie ma. To historia własnych kroków agenta: co zaplanował, co wywołał, co zwróciły narzędzia, co z tego wywnioskował. Tego nie pobierzesz z bazy. To istnieje tylko wtedy, gdy to zachowasz — i znika, gdy wypadnie z okna.
Przy krótkim zadaniu to nieproblem. Przy długim przebiegu — gdy pętla agenta obraca się kilkadziesiąt razy — ta historia puchnie, aż zaczyna rozsadzać okno. Ten wpis jest o tym, jak ją utrzymać w ryzach, nie tracąc wątku.
Dlaczego długi przebieg to osobny problem
Przypomnijmy mechanikę. Agent działa w pętli: percepcja → planowanie → akcja → ocena → i z powrotem. Przy każdym obrocie do okna dochodzi nowa warstwa — kolejny krok, kolejny wynik narzędzia, kolejny fragment rozumowania.
Dziesięć iteracji to jeszcze nic. Ale agent, który realizuje złożone zadanie — przeszukuje, porównuje, koryguje się, próbuje ponownie — potrafi zrobić ich pięćdziesiąt albo sto. I jeśli przy każdym obrocie wleczesz całą dotychczasową historię, okno rośnie liniowo z liczbą kroków. W końcu trafiasz w dwie ściany naraz, które znasz już z wpisu o budżecie okna: context rot (model gubi się w narastającym szumie własnej historii) i koszt (każdy obrót to coraz dłuższe, coraz droższe wejście).
To jest moment, w którym naiwne „trzymaj wszystko, na wszelki wypadek” przestaje działać. Trzeba zacząć kompresować.
Czym jest kompakcja
Kompakcja to zwięzłe zastępowanie starszej historii jej streszczeniem — tak, żeby agent zachował to, co istotne z przeszłości, nie nosząc ze sobą każdego słowa, które kiedykolwiek wyprodukował.
W praktyce okno historii zamienia się w dwa odcinki:
Świeże kroki — w pełnej formie. Ostatnie kilka iteracji agent widzi w całości, z detalem. Bo to na nich opiera następną decyzję.
Starsze kroki — skompresowane do streszczenia. Wszystko, co było wcześniej, zwija się w zwięzły zapis: co ustalono, co zrobiono, jaki jest stan. Bez pełnych przebiegów rozumowania, bez surowych dumpów z narzędzi.
Efekt: zamiast historii, która rośnie bez końca, masz przesuwane okno detalu (ostatnie kroki) na tle rosnącego wolno streszczenia (cała reszta). Agent dalej „wie, co się działo” — tylko nie nosi tego ze sobą dosłownie.
Co zachować, a co zwinąć
Kompakcja jest użyteczna dokładnie w tym stopniu, w jakim trafnie rozróżnia istotne od jednorazowego. Z grubsza:
Zachowaj w streszczeniu: decyzje i ich powody (co agent wybrał i dlaczego), ustalone fakty (czego się dowiedział), stan zadania (co zrobione, co zostało), błędy i ślepe ułki (żeby nie próbował drugi raz tego, co już nie wyszło).
Zwiń albo odetnij: pełne przebiegi rozumowania ze starych kroków (wniosek wystarczy, droga do niego już nie), surowe wyniki narzędzi (istotny był wynik, nie pięćdziesiąt pól JSON-a), powtórzenia (jeśli coś ustalono trzy razy, raz wystarczy).
Zasada jest taka sama jak w heurystyce z C2, tylko zastosowana w czasie: nie „co wpuścić do okna teraz”, ale „co z tego, co już było, jest dalej potrzebne”.
Kiedy kompaktować
Dwa podejścia, najczęściej łączone.
Po progu. Pilnujesz, ile budżetu okna zajmuje historia, i gdy zbliża się do ustalonego limitu — uruchamiasz kompakcję starszych kroków. Reaktywne, ale celne: kompresujesz dopiero, gdy realnie trzeba.
Co N kroków. Co ustaloną liczbę iteracji agent zwija najstarszy odcinek historii do streszczenia. Prostsze do wpięcia w przepływ, przewidywalne.
W obu wypadkach kluczowa jest jedna decyzja, którą znasz z wpisu o budżecie: ile detalu chcesz utrzymać „pod ręką” zanim zaczniesz kompresować. Za agresywna kompakcja gubi rzeczy, których agent jeszcze potrzebował. Za leniwa — wraca do context rot. To strojenie, nie ustawienie raz na zawsze.
Kompakcja a pamięć
Łatwo pomylić kompakcję z pamięcią agenta — bo obie dotyczą „tego, co agent wie z przeszłości”. Różnica jest czysta.
Pamięć to architektura: jakie typy informacji agent przechowuje, gdzie i jak długo — temat, który rozkładają cztery typy pamięci. Kompakcja to technika utrzymywania jednej z tych warstw — bieżącej, roboczej historii — w skończonym rozmiarze. Innymi słowy: pamięć mówi, co i gdzie agent trzyma; kompakcja mówi, jak nie pozwolić, by warstwa robocza urosła ponad budżet okna. Działają razem.
Jak to wygląda w n8n
Przy prostym przepływie z jednym wywołaniem modelu kompakcja Cię nie dotyczy — nie ma czego kompresować. Pojawia się, gdy budujesz przepływ z pętlą albo agenta, który iteruje, dopóki nie skończy.
Wtedy zamiast podpinać pod model całą narastającą historię z każdej rundy, wstawiasz krok pośredni, który streszczastarsze rundy do zwięzłego stanu — i to streszczenie, plus ostatnie pełne kroki, idzie do modelu w następnej iteracji. Trochę pracy więcej, ale przepływ przestaje puchnąć z każdą rundą i przestaje gubić wątek po kilkunastu obrotach.
Moment, w którym dodajesz ten krok streszczający, to moment, w którym przestajesz „przekazywać dane między węzłami”, a zaczynasz zarządzać tym, co agent pamięta o samym sobie.
Co z tego wynika
Retrieval rozwiązuje problem wiedzy z zewnątrz — pobierzesz ją, kiedy trzeba. Kompakcja rozwiązuje problem wiedzy od wewnątrz — historii, którą agent sam wytworzył i której nikt mu nie odda, jeśli ją zgubisz. W długim przebiegu to ona decyduje, czy po pięćdziesięciu krokach agent wciąż wie, co robi, czy tonie we własnym śladzie.
Zasada do zabrania: nie noś każdego kroku — noś jego wnioski. Mamy już dwie z trzech dynamicznych warstw okna obsłużone: skąd brać wiedzę (retrieval) i jak nie utonąć we własnej historii (kompakcja). Została trzecia, której dotknęliśmy mimochodem kilka razy: surowe wyniki narzędzi, które wracają do okna w formie nie do użytku. O tym, jak je formatować, żeby były kontekstem, a nie materiałem do przekopania — następny wpis tej kategorii.
Pojęcia ze słownika: Kompakcja kontekstu · Okno kontekstu · Context rot · Budżet tokenów · Just-in-time retrieval
