Okno to nie jeden tekst.
To pięć warstw walczących o to samo miejsce.
W poprzednim wpisie ustaliliśmy, że okno kontekstu jest budżetem, nie workiem. Zostało pytanie, które każdy buduje sobie sam przy pierwszym agencie: skoro budżet jest skończony — co konkretnie do niego wpuścić?
Żeby na to odpowiedzieć, trzeba zobaczyć, że to, co model dostaje na wejściu, nie jest jednym blokiem. To kilka różnych źródeł sklejonych w jedno okno. Pillar wymienił je z nazwy — tu rozkładamy każde na części i dla każdego odpowiadamy na trzy pytania: trzymać na stałe, odciąć, czy pobrać dopiero gdy potrzebne. Bo na tym polega cała robota.
Pięć warstw okna
Wyobraź sobie okno jako stos. Od dołu, od fundamentu, do tego, co dosypujesz przy każdym kroku.
1. System prompt — fundament, ale tylko fundament
Najniższa warstwa: kim agent jest, co wolno, czego nie, jak ma się zachować. Siedzi w oknie cały czas, przy każdym obrocie pętli. I to jest jej zaleta i jej koszt naraz — to, co tu włożysz, płacisz w każdej iteracji.
Stąd zasada: system prompt ma być stabilny i zwięzły, nie magazynem wiedzy. Pokusa, żeby wkleić tu całą dokumentację „żeby agent zawsze miał”, jest dokładnie tym błędem, który tworzy context rot z C1. Wiedza, która zmienia się zależnie od kroku, nie należy do fundamentu — należy do warstw wyższych. Dlaczego system prompt to nie to samo co zwykłe pytanie i co naprawdę powinien zawierać, rozkłada osobny artykuł serii.
Decyzja: trzymać na stałe — ale chudo.
2. Pamięć — co agent wie z wcześniejszych kroków
Druga warstwa to historia: co agent już zrobił, co zwróciły poprzednie akcje, co ustalił w tej i w poprzednich sesjach. To zwykle najszybciej puchnąca część okna — i pierwsza, która wywołuje context rot, jeśli wleczesz ją w całości.
Klucz to rozróżnienie, które typy pamięci w ogóle trzymasz w oknie, a które poza nim. Świeże, istotne kroki — w pełnej formie. Starsze — skompresowane do streszczenia. Rzeczy trwałe, do których agent sięga rzadko — poza oknem, do pobrania na żądanie. To wszystko zależy od projektu pamięci, a cztery jej typy rozstrzygają, co gdzie ląduje.
Decyzja: trzymać selektywnie — świeże w pełni, stare streszczone, resztę pobierać.
3. Wyniki narzędzi — to, co wróciło z akcji
Gdy agent wywoła narzędzie — odpyta bazę, uderzy w API, zrobi request — wynik tej akcji wraca do okna, żeby model mógł na nim oprzeć następny krok. I tu jest pułapka, którą widać u każdego początkującego: surowy dump. Pełny JSON z pięćdziesięcioma polami, gdy istotne są trzy.
Surowy wynik narzędzia to nie kontekst — to materiał na kontekst. Zanim wróci do okna, warto go przyciąć i sformatować do tego, co krok faktycznie potrzebuje. (Temu poświęcimy osobny wpis tej kategorii — o formatowaniu wyników i structured output.)
Decyzja: wpuszczać przefiltrowane, nigdy surowe w całości.
4. Retrieval — dane pobrane na potrzebę kroku
Czwarta warstwa to wiedza, której agent nie ma „w sobie” ani w pamięci: dokumentacja, baza wiedzy, dane produktowe, polityki. Kuszące jest wepchnąć to wszystko do okna na start. Lepsze podejście jest odwrotne: pobierać dopiero wtedy, gdy konkretny krok tego wymaga — i tylko ten fragment, który jest istotny.
To jest serce różnicy „wszystko z góry” kontra just-in-time. Mechanikę pobierania rozkłada wpis o RAG; jak to przekłada się na zarządzanie oknem — osobny wpis tej kategorii o retrievalu jako składaniu kontekstu.
Decyzja: prawie zawsze pobierać na żądanie, nie trzymać.
5. Przykłady — wzorce, czego od modelu chcesz
Najwyższa warstwa: few-shot, czyli przykłady pokazujące modelowi pożądany format i styl odpowiedzi. Potrafią dramatycznie poprawić jakość — i równie dramatycznie zjeść budżet, jeśli wrzucisz ich pięć tam, gdzie wystarczy jeden.
Po samą głębię promptowania — jak dobierać przykłady, jak utrzymać powtarzalność — odsyłamy do promptujemy.pl, gdzie ten wątek prowadzimy jako działający PoC. Tu pytanie jest węższe: ile przykładów zmieści się w oknie obok czterech pozostałych warstw, nie wypychając rzeczy ważniejszych. (Sam dobór przykładów — w osobnym wpisie tej kategorii o few-shot.)
Decyzja: wpuszczać oszczędnie — tyle, ile realnie zmienia wynik.
Heurystyka: trzymać, odciąć, pobrać
Gdy nie wiesz, co zrobić z danym blokiem, zadaj trzy pytania po kolei:
Czy model potrzebuje tego przy każdym kroku? Jeśli tak — to fundament, trzymaj (ale chudo). Jeśli nie — idź dalej.
Czy potrzebuje tego teraz, przy tym kroku? Jeśli tak — wpuść, ale przefiltrowane do istoty. Jeśli nie — idź dalej.
Czy może potrzebować tego czasem? Jeśli tak — zostaw poza oknem i pobierz na żądanie. Jeśli odpowiedź na wszystkie trzy brzmi „raczej nie” — to nie jest kontekst, to szum. Odetnij.
Ta heurystyka jest cała. Reszta to wprawa.
Krótko dla twórców treści
Jeśli używasz LLM nie do agenta, tylko do generowania treści — opisów produktów, altów, wariantów nagłówków — te same warstwy działają, tylko w mniejszej skali. Twój „system prompt” to stała instrukcja o tonie i marce. Twój „retrieval” to dane konkretnego produktu, które wklejasz akurat do tego zadania. Twoje „przykłady” to dwa-trzy wzorcowe opisy pokazujące styl. Reguła jest identyczna: do okna trafia to, co istotne dla tego tekstu — nie cała baza wiedzy o firmie „na wszelki wypadek”. Mniej, ale celniej, daje lepszy i powtarzalny wynik.
Co z tego wynika
Okno agenta nie jest tekstem, który piszesz. Jest stosem, który komponujesz — pięć warstw rywalizujących o ten sam, skończony budżet z C1. Twoja robota to nie „napisać dobry prompt”, tylko przy każdym kroku rozstrzygnąć, które warstwy wchodzą, w jakiej formie i ile ich.
Mając już mapę warstw, kolejne wpisy tej kategorii schodzą po niej w dół: jak pobierać (retrieval), jak nie gubić wątku, gdy pamięć rośnie (kompakcja), jak formatować to, co wraca z narzędzi, i jak dobierać przykłady. Każdy z nich to po prostu jedna warstwa tego stosu, rozłożona na czynniki.
Pojęcia ze słownika: Okno kontekstu · System prompt vs user prompt · Few-shot · Just-in-time retrieval · Structured output · Grounding
