Kompaktowanie kontekstu staje się celem treningowym

Każda długa sesja agenta kończy się tak samo. Kontekst się zapełnia, uruchamia się podsumowanie, a praca toczy się dalej na skompresowanej pamięci tego, co było wcześniej. W Claude Code wyzwalaczem jest /compact albo automatyczny przebieg uruchamiany w miarę zbliżania się do limitu okna. Operatorzy traktują ten moment jako tarcie, którym trzeba zarządzać: chronić stan, który się liczy, mieć nadzieję, że podsumowanie go zachowa, i iść dalej. Zbiór najnowszych badań mówi, że ten instynkt wkrótce się zestarzeje. Kompaktowanie przechodzi od łatki stosowanej podczas inferencji, którą trzeba obchodzić inżyniersko, do celu treningowego, który model optymalizuje bezpośrednio. Gdy model jest nagradzany za wytwarzanie trajektorii przetrwających własną kompresję, zarządzanie kontekstem przestaje być pracą polegającą na nadzorowaniu, a zaczyna być właściwością, którą się selekcjonuje. {.answer-block}

TL;DR

• Dziś kompaktowanie kontekstu żyje na etapie inferencji. Sama firma Anthropic ujmuje je jako technikę inżynierii kontekstu: podsumować rozmowę zbliżającą się do limitu okna i zainicjować ją ponownie z podsumowania.² Otaczający je zestaw narzędzi czasu wykonania — /compact, automatyczne kompaktowanie, edycja kontekstu, narzędzie pamięci — wszystkie opakowują model, który nie wie, że jest kompaktowany.³⁴
• CompactionRL trenuje model, by oczekiwał kompaktowania. Wspólnie optymalizuje wykonanie zadania i generowanie podsumowań za pomocą uczenia ze wzmocnieniem, dzięki czemu agent uczy się ze skompaktowanych trajektorii, zamiast być przez nie przerywany.¹
• Liczby są prawdziwe. Na GLM-4.5-Air osiąga 66,8% Pass@1 na SWE-bench Verified, co daje wzrost o 7,0 punktu, oraz 24,5% na Terminal-Bench 2.0.¹ Te benchmarki są przedmiotem sporów i aktualne, a nie zabawkowe.⁸⁹
• To nie jest jedna praca. Memory-R1 trenuje operacje pamięci ADD/UPDATE/DELETE za pomocą RL; MemAct traktuje kuratelę kontekstu jako działania podejmowane przez politykę i optymalizuje je od początku do końca.⁶⁷ Trzy niezależne zespoły sięgnęły po ten sam ruch.
• Wniosek dla operatora obowiązuje tak czy inaczej. Warto traktować szew kompaktowania jako powierzchnię projektową, a nie przypadek: zdecydować, co żyje w trwałej pamięci, a co w kontekście ulotnym, strzec granicy za pomocą hooka PreCompact i zacząć odczytywać wytrenowaną kompetencję kompaktowania modelu jako pozycję w specyfikacji, a nie przypis.⁵

Łatka, którą wszyscy już zarządzają

Kontekst jest zasobem skończonym, a każdy operator prowadzący długie sesje nauczył się go racjonować. Własne teksty inżynierskie Anthropic precyzyjnie nazywają ten tryb awarii: w miarę wzrostu liczby tokenów pogarsza się odzyskiwanie informacji — regres, który nazywają gniciem kontekstu (context rot).² Ten sam wpis definiuje środek zaradczy prostymi słowami. Kompaktowanie to praktyka polegająca na wzięciu rozmowy zbliżającej się do limitu okna kontekstu, podsumowaniu jej zawartości i ponownym zainicjowaniu nowego okna kontekstu z podsumowania.²

Warto przeczytać tę definicję ponownie i zauważyć, gdzie odbywa się praca. Odbywa się ona wokół modelu, na etapie inferencji, za sprawą maszynerii, w której model nie uczestniczy. Claude Code czyni tę maszynerię konkretną. Polecenie /compact zwalnia kontekst, podsumowując dotychczasową rozmowę, a można przekazać instrukcje ukierunkowujące, by sterować tym, co podsumowanie zachowa.⁴ Automatyczne kompaktowanie uruchamia ten sam przebieg samoczynnie, gdy kontekst zbliża się do limitu; jest domyślnie włączone poprzez ustawienie autoCompactEnabled, a efektywne okno, względem którego się wyzwala, ustawia się za pomocą CLAUDE_CODE_AUTO_COMPACT_WINDOW albo wyłącza za pomocą DISABLE_AUTO_COMPACT.⁴ Po stronie platformy edycja kontekstu automatycznie usuwa nieaktualne wywołania narzędzi i ich wyniki w miarę zbliżania się do limitów tokenów, a oparte na plikach narzędzie pamięci pozwala modelowi przechowywać informacje całkowicie poza oknem.³

To dobre narzędzia. Anthropic podaje, że sama edycja kontekstu poprawiła ocenę agenta o długim horyzoncie o 29%, a połączenie jej z narzędziem pamięci zmniejszyło zużycie tokenów o 84% w przebiegu liczącym sto tur.³ Rzecz nie w tym, że podejście czasu wykonania jest słabe. Rzecz w tym, co ono zakłada. Każda z tych technik zarządza kontekstem jako zewnętrzną właściwością sesji, stosowaną wobec modelu, który był trenowany na nieskompaktowanych trajektoriach i spotyka kompaktowanie dopiero we wdrożeniu. Model wytwarza długą trajektorię tak, jak robił to zawsze. Coś innego decyduje, kiedy podsumować, co zachować i jak wznowić. Model budzi się następnie wewnątrz skompresowanego kontekstu, którego nie był autorem i którego nigdy nie nauczono go oczekiwać.

Ta luka — między tym, jak model był trenowany, a tym, jak jest uruchamiany — to właśnie szew, który zamykają nowe badania.

Co CompactionRL faktycznie zmienia

CompactionRL, autorstwa zespołu GLM w Zhipu, wychodzi od tego samego sformułowania problemu i odwraca rozwiązanie. Zamiast doczepiać kompaktowanie do inferencji, czyni je częścią tego, do czego model jest trenowany. Metoda wspólnie optymalizuje wykonanie zadania i generowanie podsumowań, wykorzystując normalizację straty na poziomie tokenów oraz uogólnione szacowanie przewagi między trajektoriami (cross-trajectory generalized advantage estimation), aby agent mógł uczyć się ze skompaktowanych trajektorii o długim horyzoncie, zamiast być przez nie wykolejany.¹

Po odarciu z maszynerii przesunięcie łatwo wyrazić. W podejściu czasu wykonania mechanizm podsumowujący znajduje się poza polityką, a model toleruje wszystko, co ten wytworzy. W CompactionRL podsumowanie jest generowane przez tę samą politykę, która wykonuje zadanie, i obie są nagradzane razem. Model jest trenowany, by pisać podsumowania, na których może działać, i by dobrze działać na podsumowaniach, które sam napisał. Kompaktowanie przestaje być przerwaniem, a staje się ruchem, który agent przećwiczył.

Wyniki lądują na aktualnych benchmarkach. Zbudowany na otwartym modelu GLM-4.5-Air, CompactionRL osiąga 66,8% Pass@1 na SWE-bench Verified, co daje bezwzględny wzrost o 7,0 punktu, oraz 24,5% na Terminal-Bench 2.0.¹ Na mniejszym GLM-4.7-Flash dodaje 5,5 i 6,8 punktu na obu benchmarkach.¹ Oba benchmarki są prawdziwe i trudne: SWE-bench Verified to zweryfikowany przez ludzi podzbiór 500 zgłoszeń do rozwiązywania rzeczywistych problemów z GitHuba, a Terminal-Bench 2.0 to 89 zweryfikowanych przez ludzi zadań wiersza poleceń, w których czołowe agenty wciąż uzyskują wynik poniżej dwóch trzecich.⁸⁹ SWE-bench Verified wart jest zastrzeżenia, ponieważ OpenAI publicznie się od niego wycofało na początku 2026 roku z powodu wad testów i skażenia danych, więc warto traktować go jako najczęściej cytowany benchmark kodowania agentowego, a nie jako nienaruszalny.⁸ Wzrosty przetrwają to zastrzeżenie, ponieważ są to różnice wewnątrz tego samego modelu: ten sam model bazowy, wytrenowany do kompaktowania, pokonuje samego siebie.

Najbardziej wymowna linijka w pracy nie jest benchmarkiem. CompactionRL jest wdrożone w potoku uczenia ze wzmocnieniem do trenowania kolejnego otwartego modelu GLM.¹ Kompaktowanie przeszło od czegoś, co się robi modelowi, do czegoś, z czego model jest budowany.

Nie jednorazowy przypadek

Jedna praca to wynik. Trzy niezależne zespoły sięgające po ten sam ruch to kierunek. Obok CompactionRL dwie inne prace z 2025 roku traktują zarządzanie kontekstem jako coś, co należy trenować, a nie coś, co należy opakować.

Memory-R1 wyposaża agenta w menedżera pamięci, który uczy się ustrukturyzowanych operacji — ADD, UPDATE, DELETE i NOOP — poprzez uczenie ze wzmocnieniem, dzięki czemu decyzja o tym, co zapamiętać, a co odrzucić, staje się wyuczoną polityką, a nie sztywną heurystyką.⁶ Osiąga swoje wyniki przy zaledwie 152 przykładach treningowych, co sugeruje, że ta zdolność jest bliższa utajonej niż kosztownej.⁶ MemAct posuwa się dalej w ramy, o które chodzi w tym eseju. Formułuje zarządzanie kontekstem jako operacje edycji w miejscu — usuwanie i wstawianie — i wspólnie optymalizuje zachowanie informacji oraz wydajność zadania poprzez kompleksowe uczenie ze wzmocnieniem.⁷ Pamięć jako działanie, mówiąc ich słowami: kuratela kontekstu roboczego nie jest krokiem wstępnego przetwarzania, jest częścią polityki.

Czytane razem, te trzy prace opisują jedną migrację. Zestaw narzędzi czasu wykonania — edycja kontekstu, pamięć zewnętrzna, zaplanowane podsumowywanie — jest bieżącą odpowiedzią na skończone okno. Podejście z etapu treningu czyni te same zachowania immanentnymi dla modelu, wyuczonymi względem nagrody, która naprawdę się liczy, czyli ukończenia zadania. Gdy ta sama idea pojawia się w operacjach pamięci, w edycji kontekstu i w kompaktowaniu trajektorii w ciągu jednego roku, poszczególne prace znaczą mniej niż wspólny im wektor.

Co to oznacza dla tego, jak dziś się buduje

Nic z tego nie trafi jutro do harnessa, a uczciwe pytanie operatora brzmi: co robić, zanim to nadejdzie. Odpowiedź nie brzmi: czekać. Ta migracja na nowo wycenia pracę, którą już wykonuje się wokół kontekstu, a kilka ruchów pozwala przygotować się na wersję, która nadchodzi.

Warto traktować granicę kompaktowania jako powierzchnię projektową. Obecnie większość operatorów odkrywa swoje zachowanie kompaktowania przez przypadek, spostrzegając po fakcie, że podsumowanie odrzuciło decyzję z trzeciej tury. Warto uczynić to celowym. Należy z góry zdecydować, co należy do trwałej pamięci przetrwającej każdy reset — reguły, konwencje projektu, kontrakt zadania — a co jest kontekstem ulotnym, który podsumowanie może skompresować. W Claude Code warstwą trwałą są pliki CLAUDE.md i pliki reguł, które przeładowują się po kompaktowaniu poprzez zdarzenie InstructionsLoaded, oraz oparty na plikach magazyn pamięci dla stanu, który musi przetrwać dłużej niż okno.³⁵ Wszystko inne jest do wzięcia dla mechanizmu podsumowującego.

Warto strzec szwu hookiem, a nie nadzieją. Claude Code udostępnia hook PreCompact, który uruchamia się przed kompaktowaniem i może nim sterować lub je zablokować, oraz hook PostCompact do porządkowania po nim.⁵ Jeśli pewna klasa stanu nigdy nie może zostać usunięta przez podsumowanie, to hook PreCompact jest miejscem, w którym egzekwuje się to deterministycznie, zamiast ufać, że instrukcja ukierunkowująca zostanie uszanowana. Dyscyplina jest ta sama, która czyni hooki właściwym narzędziem do wszystkiego, co zawsze musi się wykonać: przenosi się gwarancję z promptu do kodu.

Warto zacząć odczytywać wytrenowaną kompetencję kompaktowania jako pozycję w specyfikacji. W miarę dojrzewania kierunku CompactionRL modele będą się różnić nie tylko rozmiarem okna kontekstu, lecz także tym, jak dobrze zostały wytrenowane do pracy w kompresji. Rozmiar okna był przez dwa lata liczbą z nagłówka — porównaniem 200K kontra 1M, które zakotwicza każdą kartę modelu. Ta liczba już wkrótce podzieli scenę z liczbą cichszą: z tym, jak łagodnie model degraduje się, gdy musi podsumować sam siebie. Oceniając model do pracy o długim horyzoncie, warto postawić przed nim naprawdę długie zadanie — takie, które wymusza co najmniej jedno kompaktowanie — i obserwować, co przetrwa. To zachowanie staje się właściwością wartą selekcjonowania.

Warto tak strukturyzować długą pracę, by szwy padały w czystych miejscach. Model wytrenowany do kompaktowania i tak kompaktuje lepiej w poprzek ukończonego podzadania niż w poprzek napisanego do połowy. Zanim trening wszędzie nadgoni, większość korzyści uzyskuje się za darmo, kształtując pracę tak, aby naturalne punkty kontrolne — przechodzący test, zatwierdzona zmiana, zamknięte podzadanie — pokrywały się z miejscami, w których kompaktowanie prawdopodobnie się uruchomi. To i tak dobre projektowanie harnessa, a jednocześnie dokładnie ta struktura, której wytrenowane modele uczą się oczekiwać.

Stanowisko

Rozmiar okna kontekstu przestaje być ograniczeniem definiującym architekturę harnessa. Przez dwa lata rozmowa o projekcie zaczynała się od budżetu tokenów: ile się zmieści, co usunąć, kiedy podsumować. To ujęcie traktuje model jako stałe naczynie, a kontekst jako zasób, który wlewa się ostrożnie. Kierunek CompactionRL rozpuszcza to naczynie. Gdy model jest trenowany, by zarządzać własną kompresją, okno przestaje być twardą ścianą, wobec której się inżynieruje, a staje się miękkim gradientem, po którym model nauczono schodzić.

Zestaw narzędzi czasu wykonania nie znika. Edycja kontekstu, narzędzia pamięci i ręczne /compact pozostają właściwymi elementami sterowania dla tych części zarządzania kontekstem, które naprawdę należą do operatora: które fakty są miarodajne, które pliki są źródłem prawdy, czym zadanie właściwie jest. Migracja jest węższa i ciekawsza niż pełna automatyzacja. Przenosi mechaniczną połowę zarządzania kontekstem — instalację podsumuj-i-wznów — do modelu, a połowę redakcyjną — decydowanie, co się liczy — pozostawia operatorowi. Inżynieria kontekstu rozdziela się na to, czym zajmuje się model, i to, co wciąż należy do operatora, a granica między nimi to nowe miejsce, w którym mieszka dobre projektowanie harnessa.

Sygnał jest już w pracy o CompactionRL. Kompaktowanie zasłużyło na miejsce w potoku treningowym czołowego modelu, obok sygnałów nagrody za kodowanie i rozumowanie. Zdolności, które docierają do pętli treningowej, zwykle jej nie opuszczają. Operatorzy, którzy wygrają nadchodzący rok, to ci, którzy przestają traktować kompaktowanie jako przypadek do przetrwania, a zaczynają traktować je jako kontrakt do zaprojektowania.

Kluczowe wnioski

• Kompaktowanie migruje z etapu inferencji na etap treningu. CompactionRL, Memory-R1 i MemAct niezależnie od siebie wykorzystują uczenie ze wzmocnieniem, by uczynić zarządzanie kontekstem zachowaniem wyuczonym, a nie zewnętrznym opakowaniem.¹⁶⁷
• Narzędzia czasu wykonania to bieżąca odpowiedź, a nie ostateczna. /compact, automatyczne kompaktowanie, edycja kontekstu i narzędzie pamięci zarządzają kontekstem wokół modelu, którego nie wytrenowano, by oczekiwał kompresji.³⁴
• Trwałą pamięć oddziela się od kontekstu ulotnego celowo. Reguły, konwencje i kontrakt zadania warto umieścić w warstwie przetrwającej reset; wszystko inne niech pozostanie kompresowalne.³⁵
• Granicę należy egzekwować hookiem PreCompact. Każdą gwarancję „nie-podsumowuj” warto przenieść z instrukcji ukierunkowującej do kodu deterministycznego.⁵
• Kompetencję kompaktowania warto odczytywać jako pozycję w specyfikacji. Kandydujący model należy przetestować na zadaniu dostatecznie długim, by wymusić kompaktowanie, i obserwować, co przetrwa. Rozmiar okna nie jest już jedyną liczbą, która się liczy.

FAQ

Czym jest kompaktowanie kontekstu?

Kompaktowanie to podsumowanie rozmowy zbliżającej się do limitu okna kontekstu i ponowne zainicjowanie nowego okna z podsumowania, tak by długo działający agent mógł kontynuować pracę poza punktem, w którym surowa historia przepełniłaby okno.² Wymienia dosłowną historię na skompresowaną reprezentację, która się mieści.

Czy Claude Code kompaktuje kontekst automatycznie?

Tak. Automatyczne kompaktowanie jest domyślnie włączone i uruchamia się, gdy kontekst zbliża się do limitu. Efektywnym oknem można sterować za pomocą CLAUDE_CODE_AUTO_COMPACT_WINDOW, wyłączyć je za pomocą DISABLE_AUTO_COMPACT lub wyzwolić przebieg ręcznie za pomocą /compact, opcjonalnie przekazując instrukcje ukierunkowujące dla podsumowania.⁴

Czym jest CompactionRL?

Metoda uczenia ze wzmocnieniem autorstwa zespołu GLM, która trenuje agenty o długim horyzoncie do pracy z kompaktowaniem, wspólnie optymalizując wykonanie zadania i generowanie podsumowań, dzięki czemu model uczy się ze skompaktowanych trajektorii. Poprawia GLM-4.5-Air o 7,0 punktu na SWE-bench Verified i jest wdrożona w potoku treningowym kolejnego modelu GLM.¹

Czy można wytrenować model do zarządzania własnym kontekstem?

To właśnie pokazują najnowsze badania. Memory-R1 trenuje jawne operacje pamięci za pomocą RL, MemAct traktuje edycję kontekstu jako działania polityki, a CompactionRL trenuje kompaktowanie trajektorii bezpośrednio. Wszystkie trzy czynią zarządzanie kontekstem immanentnym dla modelu, a nie dodatkiem czasu wykonania.¹⁶⁷

Czy wytrenowanie modelu do kompaktowania czyni okna kontekstu nieistotnymi?

Nie, ale zmienia to, co ta liczba oznacza. Większe okno wciąż pomaga, jednak model dobrze wytrenowany do kompaktowania potrafi zajść dalej w obrębie dowolnego okna niż taki, który spotyka kompaktowanie dopiero we wdrożeniu. Wytrenowana kompetencja kompaktowania staje się drugą osią obok surowego rozmiaru okna.

Co robić z kompaktowaniem kontekstu agenta już teraz?

Warto zaprojektować szew kompaktowania, zamiast go odkrywać. Należy zdecydować, co żyje w trwałej pamięci, a co w kontekście ulotnym, strzec granicy hookiem PreCompact, strukturyzować długie zadania tak, by kompaktowanie padało w poprzek ukończonych podzadań, oraz oceniać nowe modele na zadaniach dostatecznie długich, by wymusić podsumowanie.⁵

Źródła