Inżynieria kontekstu: prawdziwym wąskim gardłem twojego agenta jest okno kontekstu

Pod wieloma rozczarowaniami agentami leży ciche założenie: że jeśli agent zawodzi, potrzebujesz mądrzejszego modelu. Dla agentów działających długo to założenie zwykle jest błędne. Tym, co psuje się najpierw, nie jest inteligencja modelu — to okno kontekstu. A naprawą nie jest większe okno ani lepszy model. To projektowanie tego, co model widzi na każdym kroku. Ta dyscyplina ma już nazwę — inżynieria kontekstu — i po cichu staje się nośną umiejętnością ery agentowej.

Część przeciwna intuicji jest tu najciekawsza. Odruch to dać agentowi więcej kontekstu — pełną historię, każdy wynik narzędzia, całą rozmowę — w przekonaniu, że więcej informacji może tylko pomóc. Dane mówią coś przeciwnego. Więcej kontekstu, powyżej pewnego punktu, czyni agentów gorszymi.

Liczba, która powinna zmienić twoje zdanie

Badanie z 2026 roku, Less Context, Better Agents, poddało to czystej próbie. Badacze przepuścili agenta GPT-5 przez benchmark 50 zadań rozliczania wydatków — dokładnie taką pracę o długim horyzoncie i intensywną w narzędzia, gdzie kontekst szybko się piętrzy — pod różnymi politykami kontekstu.

Agent z pełną historią, trzymający każde wywołanie narzędzia i odpowiedź, uzyskał 71,0% kompletnego rozpisania. Spalił około 1,48 miliona tokenów i zajął 14,56 godziny. Agent, który zachował tylko pięć ostatnich wywołań narzędzi plus bieżące podsumowanie tego, co eksmitował, uzyskał 91,6% — i zrobił to na 553 000 tokenów w 5,79 godziny. To redukcja tokenów o 63,9% i o 60,2% mniej czasu zegarowego, przy jednoczesnym zyskaniu ponad dwudziestu punktów dokładności. Wynik utrzymał się, gdy zamienili GPT-5 na Claude Sonnet 4.5.

Przeczytaj to jeszcze raz, bo odwraca intuicję. Agent, który widział mniej, był dokładniejszy, radykalnie tańszy i znacznie szybszy. Pełna historia nie pomagała modelowi — topiła go.

Dlaczego więcej kontekstu czyni agentów gorszymi: „context rot”

Mechanizm za tym ma już branżową nazwę: context rot (gnicie kontekstu). W miarę jak rośnie liczba tokenów, efektywna pamięć modelu degraduje się — na długo zanim trafi na twardy limit kontekstu. Okno 200 tys. tokenów nie znaczy, że model niezawodnie wykorzystuje 200 tys. tokenów informacji. Na długo przed tym pułapem sygnał, którego potrzebuje, zostaje pogrzebany pod nagromadzonymi zrzutami narzędzi, nieaktualnymi krokami pośrednimi i ślepymi zaułkami, które już porzucił. Okno jest pełne rzeczy, a te rzeczy to w większości szum.

Dlatego agent działający długo degraduje się w trakcie sesji, nawet jeśli technicznie nigdy nie „wyczerpie” kontekstu. Każda rozwlekła odpowiedź narzędzia, którą dokleja, czyni następną decyzję nieco trudniejszą do ugruntowania w tym, co naprawdę się liczy. Zdolność nie spada z urwiska; eroduje, tura po turze. Im dłużej agent działa, tym bardziej gnicie się kumuluje — a działanie długie to dokładnie kierunek, w którym idzie całe pole.

Kontekst jako zarządzany zasób

Produktywne przeformułowanie to przestać traktować okno kontekstu jak bierny dziennik, do którego agent dopisuje, a zacząć traktować je jak rzadki, aktywnie zarządzany zasób — tak samo jak system operacyjny traktuje pamięć fizyczną. Ta analogia nie jest luźna: badania nad zarządzaniem kontekstem z 2026 roku czerpią wprost z klasycznego projektowania OS — teorii zbioru roboczego (working set), pamięci wirtualnej, stronicowania na żądanie — wprowadzając istotne informacje na żądanie, zamiast trzymać wszystko rezydentne. Uwaga modelu to RAM. Twoim zadaniem jest zarządca pamięci.

W praktyce inżynieria kontekstu zbiega się do garstki ruchów — pole streszcza je jako write, select, compress, isolate — a każdy z nich to dźwignia, którą kontrolujesz bez dotykania modelu:

• Compress (kompakcja + podsumowanie). Destyluj starsze tury do zwięzłych podsumowań, które zachowują decyzje, a odrzucają transkrypt. To ruch, który napędził wynik benchmarku powyżej: eksmituj surowe wywołania narzędzi, zachowaj bieżące podsumowanie. Tracisz dosłowny szum, a zachowujesz sygnał.
• Write (eksternalizacja stanu). Pozwól agentowi odciążyć plany, ustalenia i postęp do trwałego magazynu — brudnopisu, pliku postępu, historii git — zamiast nosić wszystko w oknie. Okno trzyma to, co potrzebne teraz; reszta żyje poza nim i jest wprowadzana z powrotem, gdy staje się istotna.
• Select (pobieranie na żądanie). Wciągaj tylko te konkretne pliki, dokumenty czy wcześniejsze wyniki, których potrzebuje bieżący krok, zamiast ładować z góry wszystko, czego agent mógłby użyć.
• Isolate (subagenty). Daj niezależnym podzadaniom własne, skupione okna kontekstu zamiast jednego rozdętego współdzielonego. To argument inżynierii kontekstu za wzorcem wieloagentowym, który omówiliśmy w orkiestrze agentów kodu: subagent, który zna tylko jeden plik, rozumuje lepiej niż taki żonglujący całą bazą kodu — częściowo dlatego, że jego okno nie gnije.

Przekraczanie wielu okien: harness do długiego działania

Najtrudniejszą wersją tego problemu jest agent, który musi pracować przez wiele okien kontekstu — zadanie zbyt duże, by w ogóle zmieścić się w jednej sesji. Inżynierskie wskazówki Anthropic z 2026 roku dotyczące harnessów do długiego działania są bez ogródek co do sedna trudności: „każda nowa sesja zaczyna się bez pamięci tego, co było wcześniej”. I równie bez ogródek, że sama kompakcja cię nie ratuje — nawet frontierowy model jak Opus 4.5 zawodzi w budowie aplikacji jakości produkcyjnej z wysokopoziomowych promptów, gdy ma jedynie skompresowane okno.

Ich odpowiedź jest architektoniczna i to czysta inżynieria kontekstu. Dwuczęściowy harness: agent inicjalizujący, który raz przygotowuje środowisko — plik postępu, ustrukturyzowaną listę funkcji z setkami pozycji oznaczonych jako przechodzące lub niezaliczone oraz init.sh do uruchomienia projektu — a potem agent kodujący, który co sesję czyta plik postępu i log git, wybiera jedną funkcję, implementuje ją, weryfikuje prawdziwym testem end-to-end, zatwierdza i zostawia czyste artefakty dla następnej sesji. Okno kontekstu resetuje się co sesję; stan utrzymuje się poza nim, w plikach, które następny agent wprowadza z powrotem. Stopniowy postęp, jedna funkcja naraz, z oknem celowo trzymanym szczupło.

To ten sam wgląd co benchmark, w większej skali: trwała pamięć nie żyje w oknie kontekstu. Żyje w artefaktach, które harness pielęgnuje wokół niego. Okno to pamięć robocza; pliki to dysk. Twierdziliśmy wcześniej, że harness jest produktem — zarządzanie kontekstem to ta część harness, która decyduje, czy agent działający długo pozostaje spójny, czy po cichu gnije, i to ona pozwala pętlom działać bez nadzoru, gdy śpisz, bez zbaczania z torów.

Dlaczego to umiejętność o najwyższej dźwigni i najniższym kapitale w całym stosie

Oto część, która najbardziej liczy się dla tego regionu, i jest to najostrzejsza wersja argumentu, który wciąż stawiamy. Inżynieria kontekstu nie wymaga żadnego GPU, żadnego kapitału ani żadnego frontierowego laboratorium — to niemal czysty osąd systemowy. Wynik benchmarku powyżej nie został wygrany przez wytrenowanie lepszego modelu. Został wygrany przez kogoś, kto starannie zdecydował, co model powinien, a czego nie powinien widzieć na każdym kroku. Ta decyzja to inżynieria, i to taka, która działa na laptopie.

Ten profil pasuje do programistów Azji Południowo-Wschodniej idealnie. Mały zespół w Phnom Penh albo Da Nang nie wytrenuje OpenAI lepiej i nie musi. Może jak najbardziej zaprojektować strategię kontekstu lepiej niż konkurent — a zwrot jest bezpośredni: 64% mniej tokenów to 64% mniej na rachunku za inferencję, a do tego wyższa dokładność. Inżynieria kontekstu zamienia staranne myślenie wprost na niższy koszt i lepsze wyniki, co jest najbardziej kapitałooszczędną dźwignią w całym stosie agentowym. To ta sama trwała, wolna od GPU zdolność, którą — jak wciąż twierdzimy — region powinien budować, i ona się kumuluje: każda domena — obiegi dokumentów khmerskich, lokalna zgodność, księgi spółdzielni rolniczej — potrzebuje własnej odpowiedzi na to, co agent powinien trzymać w pamięci roboczej, a tę odpowiedź da się zaprojektować tylko od wewnątrz problemu.

Frontierowe laboratorium wynajmie ci okno na milion tokenów. Czego nie potrafi, to zdecydować, co do niego należy. Ta decyzja — co model widzi, kiedy i co zostaje wystronicowane — jest pracą. I właśnie teraz jest to najbardziej niedoceniana robota inżynierska w AI.