Wrzuciłeś modelowi wszystko, co masz.
I właśnie dlatego przestał trafiać.
Jest taki moment przy budowie pierwszego agenta, w którym wydaje się, że problem rozwiąże więcej kontekstu. Agent się myli? Dodaj mu całą historię rozmowy. Dalej się myli? Dorzuć dokumentację. Wciąż? Wklej surowy wynik z trzech wywołań API, niech ma komplet.
I w pewnym momencie agent zaczyna być gorszy, nie lepszy. Gubi rzeczy, które wcześniej łapał. Odpowiada nie na to pytanie. A rachunek za tokeny rośnie z każdą iteracją.
To nie jest awaria. To jest dokładnie to, co się dzieje, gdy traktujesz okno kontekstu jak worek, do którego można wkładać bez końca. Okno nie jest workiem. Jest budżetem. Ten wpis jest o tym, jak ten budżet działa — i dlaczego „dosypać kontekstu” to najczęstszy sposób, w jaki psuje się agenta.
To rozwinięcie jednej z zasad z pillara o context engineeringu: każdy token, który dodajesz, czemuś służy albo coś psuje.
Okno kontekstu to budżet, nie worek
Okno kontekstu to maksymalna ilość tekstu — liczona w tokenach — którą model może mieć „przed oczami” w jednym wywołaniu. Wszystko, co agent ma uwzględnić, musi się w tym oknie zmieścić: instrukcja systemowa, historia kroków, wyniki narzędzi, pobrane dane, przykłady, no i samo zadanie.
Token to nie słowo. To kawałek słowa — z grubsza fragment o długości kilku znaków. Polski tekst to orientacyjnie półtora do dwóch tokenów na słowo. Nie musisz liczyć tego ręcznie, ale musisz mieć w głowie jedną rzecz: okno jest skończone, a Ty cały czas nim gospodarujesz, świadomie albo nie.
I tu jest pułapka, która łapie większość ludzi: duże okno (setki tysięcy tokenów w nowych modelach) sprawia wrażenie, że budżet jest nieograniczony. Nie jest. Po pierwsze, duży budżet wcale nie znaczy, że warto go wypełnić — o tym za chwilę. Po drugie, każdy token, który włożysz, płacisz. W pętli agenta — wielokrotnie.
Context rot — dlaczego model gubi się w nadmiarze
Gdyby model czytał okno tak jak Ty czytasz ten akapit — równo, z uwagą, od początku do końca — nadmiar kontekstu byłby co najwyżej droższy, ale nie gorszy. Problem w tym, że model tak nie czyta.
Im więcej wrzucisz do okna, tym bardziej rozmywa się uwaga modelu. Istotne zdanie przestaje wyróżniać się z tła, bo tło urosło. Zjawisko, w którym informacja w środku długiego okna jest obsługiwana gorzej niż ta na początku i na końcu, ma swoją nazwę — lost in the middle. A ogólniejsza obserwacja, że jakość odpowiedzi spada wraz z puchnięciem kontekstu, bywa nazywana context rot: kontekst „gnije”, im więcej go upychasz.
Konkretnie. Agent obsługi dostaje przy każdym kroku całą 40-wiadomościową historię rozmowy, pełną kartę produktu i surowy JSON z dwóch zapytań do API. Pytanie klienta — to jedno zdanie, które realnie ma znaczenie — ląduje gdzieś w połowie tego wszystkiego. Model je „widzi”, ale nie waży go tak, jak powinien, bo tonie między tysiącem tokenów, których przy tym kroku nie potrzebował. Efekt: odpowiedź obok tematu. Nie dlatego, że model jest słaby. Dlatego, że utopiłeś sygnał w szumie.
Dobry agent to nie ten, który ma wszystko. To ten, który przy danym kroku widzi dokładnie to, co istotne — i mało poza tym.
Budżet płaci się dwa razy
Nadmiar kontekstu kosztuje na dwa sposoby i oba są wymierne.
Jakość. To, co opisaliśmy wyżej — im więcej szumu w oknie, tym gorzej model trafia. Pierwsza cena jest niewidoczna na fakturze, ale widać ją w wynikach.
Pieniądze i czas. Tu robi się policzalnie. Płacisz za tokeny na wejściu przy każdym wywołaniu modelu. A agent, w przeciwieństwie do chatbota, woła model wielokrotnie — pętla obraca się tyle razy, ile trzeba do skończenia zadania. Jeśli wpychasz pełną historię i pełen kontekst przy każdym obrocie, mnożysz ten koszt przez liczbę iteracji. Do tego dochodzi latencja: dłuższe okno to wolniejsza odpowiedź, przy każdym kroku.
Jak szybko to eskaluje w realnym wdrożeniu i jak to kontrolować przez token cost, model routing i obserwowalność — rozkłada na liczby wpis o tym, ile kosztuje agent w produkcji. Konkluzja dla nas jest prosta: rozdęty kontekst to nie „na wszelki wypadek”. To podwójny rachunek — gorszy wynik i wyższy koszt jednocześnie.
Jak gospodarować oknem w praktyce
Trzy nawyki, które zmieniają agenta z „karmionego wszystkim” na „karmionego tym, co trzeba”.
Pytaj o każdy blok: po co on tu jest przy tym kroku. Zanim coś trafi do okna, miej odpowiedź, czemu model tego potrzebuje teraz. Jeśli nie umiesz jej podać — to kandydat do wycięcia. Pełna dokumentacja produktu przy kroku „rozpoznaj intencję klienta” nie służy niczemu poza zapchaniem budżetu.
Streszczaj historię, zamiast ją przeciągać. Najszybciej puchnącą warstwą okna jest zwykle historia kroków. Nie wlecz jej w całości przez całą pętlę — kompresuj starsze fragmenty do streszczenia, a w pełnej formie trzymaj tylko to, co świeże i istotne. To bezpośrednio zależy od tego, jak zaprojektujesz pamięć agenta — i jej cztery typy. (Samej kompakcji przy długich przebiegach poświęcimy osobny wpis tej kategorii.)
Pobieraj zamiast trzymać. Dane, które są potrzebne tylko czasem, nie muszą siedzieć w oknie na stałe. Pobieraj je w momencie, w którym krok ich wymaga — to różnica między „wszystko z góry” a podejściem just-in-time, o którym osobno w tej kategorii.
W n8n widać to namacalnie. Jeśli w węźle z modelem podpinasz pod wejście całą poprzednią konwersację plus wszystkie pola z poprzednich węzłów „bo może się przyda”, budujesz sobie context rot ręcznie. Świadomy wybór — które pola, które fragmenty historii, w jakiej formie — to jest ten moment, w którym przestajesz pisać prompt, a zaczynasz projektować kontekst.
Co z tego wynika
Większe okno nie jest zaproszeniem, żeby je wypełnić. To margines, którym masz gospodarować, nie limit do wykorzystania.
Zasada, którą warto zabrać: agent jest tak dobry, jak budżet, który mu rozplanujesz. Nie ten, który ma najwięcej w oknie, wygrywa — wygrywa ten, który w oknie ma właściwe rzeczy, we właściwej formie, we właściwym momencie. Reszta tej kategorii to po prostu konkretne sposoby, jak ten budżet rozplanować: jakie warstwy do okna wpuścić, jak je formatować, kiedy pobierać, a kiedy streszczać.
Pojęcia ze słownika: Okno kontekstu · Budżet tokenów · Context rot · Lost in the middle · Kompakcja kontekstu · Just-in-time retrieval
