Od inżynierii promptów do inżynierii kontekstu: pisanie, selekcja, kompresja, izolacja
Kurs z inżynierii kontekstu dla agentów AI: dlaczego inżynieria promptów jest niewystarczająca, jak wypełnia się okno kontekstowe, cztery strategie, RAG dla narzędzi, Claude Code.
Każdy, kto budował agenta, prawdopodobnie widział ten sam wzorzec. Przez pierwsze kilka kroków zachowuje się dobrze: wybiera sensowne narzędzia, rozumuje jasno i trzyma się zadania. Mniej więcej na kroku 15 lub 20 staje się nieudolny – zapomina, o co prosił się go, używa narzędzi nieodpowiednich do tego zadania lub zaczyna dostarczać słabe wyniki.
Zwykle pierwszą podejrzaną przyczyną jest model. Częściej winowajcą jest to, co pokazuje się modelowi. Decydowanie o tym, co trafi przed model, w jakiej formie i w którym momencie, nazywa się inżynierią kontekstu, a dla twórców agentów staje się jedną z najcenniejszych umiejętności.
Poniższe sekcje omawiają, czym jest inżynieria kontekstu i dlaczego agenci jej potrzebują, cztery strategie, które stanowią podstawę niemal każdej techniki, cztery sposoby, w jakie może wystąpić błąd w kontekście, konkretne porady dotyczące promptów systemowych i definicji narzędzi, stopniowy proces pracy, który łączy te strategie, oraz to, jak Claude Code, Manus, ChatGPT Agent i Google’s Agent Development Kit radzą sobie z tym zadaniem.
Od inżynierii promptów do inżynierii kontekstu w oknie kontekstowym
Inżynieria promptów to sztuka pisania dobrych instrukcji dla modeli językowych: jasnego sformułowania zadań, dostarczania przykładów oraz przydzielania ról. W przypadku rozmowy składającej się z jednego pytania i odpowiedzi to często wystarcza.
Agenci zmieniają obraz sytuacji. Agent nie odpowiada od razu – przegląda dane, wywołuje API, pisze kod i uruchamia polecenia, krok po kroku, czasem przez dziesiątki kroków, bez udziału człowieka. Każdy krok generuje wynik, który trafia do kontekstu modelu, który ma określoną wielkość.
Inżynieria kontekstu polega zatem na projektowaniu całego systemu informacyjnego wokół modelu. Obejmuje to komendy systemowe, definicje narzędzi, wyniki wcześniejszych wywołań narzędzi, historię rozmów i wiele innych elementów na każdym kroku. Zespół inżynieryjny Anthropic definiuje kontekst jako zbiór tokenów uwzględnianych podczas pobierania danych z modelu, a inżynierię kontekstu jako optymalizację tego, na ile te tokeny są przydatne do osiągnięcia zamierzonego rezultatu. Mówiąc prościej, agent powinien mieć dostęp do właściwych informacji, w odpowiednim formacie, we właściwym czasie.
Anthropic przedstawia to również jako naturalny następny etap po inżynierii promptów. Wszystko, co dotyczy tworzenia promptów, nadal ma zastosowanie (jasne instrukcje, dobre przykłady, ustrukturyzowane formatowanie), a na to dodatkowo nakłada się kolejna warstwa: narzędzia, dane zewnętrzne, historia wiadomości, pamięć oraz stan dynamiczny. Inżynieria promptów staje się wtedy jej podzbiorem.
Czas ma znaczenie. Gartner przewiduje, że do końca 2026 roku 40% aplikacji korporacyjnych będzie zawierać agenty AI dostosowane do konkretnych zadań, co oznacza wzrost z niecałych 5% w 2025 roku. Te agenty zastępują statyczne prompty i sztywne procesy pobierania danych dynamicznym systemem, w którym każde wezwanie narzędzia, pobrany dokument oraz podjęta decyzja trafiają do okna, które wypełnia się materiałem, o który użytkownik nigdy bezpośrednio nie prosił. Zespoły, które nauczą się tym zarządzać, zazwyczaj tworzą agenty, które pozostają niezawodne, ponieważ przestają obwiniać model za problemy wynikające z jego danych wejściowych.
Okno kontekstowe jako pamięć robocza
LangChain proponuje przydatną analogię. Traktuj LLM jak nowy rodzaj systemu operacyjnego: model jest procesorem, który wykonuje obliczenia, a okno kontekstowe to pamięć RAM, czyli pamięć robocza przechowująca wszystko, co model może obecnie zobaczyć. Tak jak komputer zwalnia, gdy pamięć RAM się wypełnia, tak rozumowanie agenta pogarsza się, gdy jego okno kontekstowe staje się zbyt przepełnione.
Ten efekt ma nazwę – degeneracja kontekstu. Chroma przetestowało osiemnaście nowoczesnych modeli, w tym GPT-4.1, Claude 4, Gemini 2.5 i Qwen3, i stwierdziło, że każdy z nich wykazuje gorsze wyniki wraz ze wzrostem długości danych wejściowych, nawet znacznie poniżej deklarowanego limitu. Model z oknem kontekstowym na 200 tysięcy tokenów może wykazywać realną degradację już przy 50 tysiącach tokenów. Nie ma tu nagłego spadku, tylko stopniowy wzrost. Własne opracowania inżynieryjne firmy Anthropic dochodzą do tego samego wniosku i traktują tę degradację jako gradient.
Powód leży w sposobie działania transformatorów. Każdy token zwraca uwagę na każdy inny token, co tworzy n-kwadrat par wzajemnych relacji. W miarę powiększania się okna, zdolność modelu do śledzenia ich wszystkich jest rozproszona, co przypomina proszenie kogoś o przechowywanie w głowie coraz większej ilości elementów. W pewnym momencie coś zostaje pominięte.
Drugim dobrze zbadanym efektem jest „zagubienie się pośrodku”. Grupa badawcza pod kierownictwem Liu odkryła, że uwaga ma kształt litery U. Materiał znajdujący się na początku kontekstu jest dobrze pamiętany, materiał na końcu również, natomiast materiał pośrodku zostaje pominięty – dokładność spada o ponad trzydzieści punktów procentowych, gdy odpowiedni fragment przenosi się z początku na środek. Wyobraź sobie agenta, którego początkowe instrukcje znajdują się pod pięćdziesięcioma tysiącami tokenów wyników działania narzędzi. Te instrukcje faktycznie znikają.
Praktycy opracowali pewne zasady przybliżone. Użytkownicy Claude Code donoszą, że jakość wyników zaczyna spadać mniej więcej w momencie, gdy zajmuje się ona od 40 do 60 procent dostępnej przestrzeni, znacznie przed osiągnięciem jakiegokolwiek sztywnego limitu.
Co konkuruje o przestrzeń
Siedem rodzajów informacji walczy o miejsce w kontekście agenta:
- Wskazówka systemu, która stanowi tożsamość agenta: zasady zachowania, strukturę sterowania oraz wskazówki dotyczące różnych typów zadań. W przypadku agenta jest to znacznie więcej niż zwykła linijka „pomocny asystent” i może określać sposób funkcjonowania całego systemu.
- Definicje narzędzi. Każde narzędzie, którego może użyć agent, wymaga schematu opisującego jego funkcjonowanie, przyjmowane parametry oraz okoliczności jego użycia.
- Wyniki narzędzi. Każde wezwanie dodaje swój wynik. Pobrana strona internetowa może zawierać od pięciu do dziesięciu tysięcy tokenów, a sytuacja jest podobna przy odczytywaniu plików.
Cztery podstawowe strategie, z przykładami RAG i Claude Code
W warunkach ograniczonego, zmniejszającego się okna czasowego pojawiają się pytania o to, co może wejść, co pozostanie na zewnątrz, a co zostanie wykluczone. Powszechnie stosowany framework LangChain dzieli każdą technikę projektowania kontekstu na cztery kategorie: zapisywanie, selekcja, kompresja i izolacja. Gdy już je poznasz, niemal każda technika, na którą natrafisz, będzie należeć do jednej z nich.
Zapisywanie
Agenty zapominają. Gdy cały kontekst zostanie skompresowany, informacje znikają, a jeśli agent nie zapisał ich gdzie indziej, są stracone. Zapisywanie oznacza dostarczenie agentowi sposobów na przechowywanie informacji poza oknem czasowym. Przyjmuje ono trzy powszechne formy.
Scratchpady to narzędzie do notowania, którego agent może używać w trakcie wykonywania zadania, aby zapisywać tymczasowe ustalenia, decyzje oraz rzeczy, których będzie potrzebował później. Anthropic stworzył narzędzie „think”, które daje Claude’owi dedykowane miejsce do przemyśleń nad problemem, a w teście benchmark tau-bench poprawiło jego wydajność o aż 54% w niektórych zadaniach.
Pliki z regułami pełnią rolę trwałej pamięci proceduralnej. Użytkownicy Claude Code znają plik CLAUDE.md. Pliki te są ładowane na początku każdej sesji jako stałe wytyczne, obejmujące architekturę projektu, konwencje, sposoby uruchamiania testów oraz kwestie, na które należy zwrócić uwagę, dzięki czemu podstawy nigdy nie są zapomniane.
Wydobywanie pamięci umożliwia agentowi przechowywanie faktów, preferencji oraz nabytych wzorców w systemie opartym na plikach i korzystanie z nich w późniejszych sesjach, całkowicie poza oknem interfejsu.
Wybierz
Notatki są przydatne tylko wtedy, gdy odpowiednie informacje pojawiają się we właściwym momencie. Wybór oznacza dostarczenie agentowi tego, czego potrzebuje na danym etapie, a nie wszystkiego, co mógłby wykorzystać. Agent posiadający dziesiątki narzędzi, dużą bazę wiedzy oraz kilka sesji z historią nie może przetworzyć tego wszystkiego jednocześnie, więc ktoś musi zdecydować, co jest istotne, a prawdziwe pytanie brzmi, kto dokonuje tej decyzji.
W klasycznym RAG decyzję podejmuje system – pojawia się pytanie, pobierane są dokumenty i wstawiane do promptu, a model nie ma żadnego wpływu. W agentic RAG to sam agent wybiera, co ma wyszukać, jakie narzędzia użyć, jak udoskonalić zapytania oraz kiedy ma już wystarczająco informacji. Proces pozyskiwania danych staje się iteracyjny, co jest odpowiednie, ponieważ istotność informacji zmienia się na każdym etapie długiego zadania, a tylko agent wie, czego potrzebuje dalej.
Zarówno LangChain, jak i Pinecone wyróżniają trzy rodzaje pamięci, z których można czerpać. Pamięć epizodyczna to w zasadzie przykłady z niewielką liczbą przypadków pokazujące, jak radzono sobie z podobną sytuacją w przeszłości. Pamięć semantyczna to zbiór faktów, których agent się nauczył lub o których mu powiedziano. Pamięć proceduralna to stałe instrukcje behawioralne, takie jak wspomniane powyżej pliki z regułami. Dobrze zaprojektowany agent korzysta ze wszystkich trzech rodzajów pamięci w zależności od kroku, który wykonuje.
Narzędzia powodują największe problemy z wyborem. Przy ponad czterdziestu narzędziach w kontekście może znajdować się około dziesięciu tysięcy tokenów definicji, zanim rozpocznie się jakakolwiek praca. A jak pokazuje sekcja o błędach poniżej, zbyt wiele narzędzi nie tylko marnuje przestrzeń, ale także aktywnie dezorientuje model.
Rozwiązaniem jest zastosowanie RAG do samych opisów narzędzi, przeprowadzając wyszukiwanie semantyczne, które wyświetla tylko te nieliczne narzędzia, których może potrzebować aktualny krok. Artykuł zatytułowany RAG-MCP przeprowadził testy w tym zakresie i stwierdził, że dokładność wyboru narzędzi wzrosła z około 14% do 43%, czyli ponad trzykrotnie, podczas gdy liczba tokenów w promptach zmniejszyła się o mniej więcej połowę.
Ogólna rada firmy Anthropic polega na hybrydowym podejściu. W celu przyspieszenia należy z góry załadować niewielką ilość niezbędnego materiału, np. plik CLAUDE.md, a agent ma pobrać resztę dokładnie w odpowiednim momencie. W praktyce oznacza to, że agent przechowuje lżejsze referencje, takie jak ścieżki plików, zapytania i linki, a ciężkie treści otwiera tylko wtedy, gdy tego wymaga dany krok. Zładowanie najważniejszych elementów z góry i pobieranie reszty na żądanie pozwala utrzymać lekki interfejs, nie pozostawiając agenta bez informacji.
Kompresja
Nawet przy dobrej selekcji okno nadal się wypełnia. Wyobraź sobie agenta, który wykonał dwadzieścia wywołań narzędzi. Przenosi on osiemdziesiąt tysięcy tokenów wyników, historii oraz śladów rozumowania, z których większość została już wykorzystana. Ten stary materiał nadal zajmuje miejsce, osłabia uwagę oraz zwiększa koszty i opóźnienia. To ponownie problem zepsucia kontekstu, a kompresja radzi mu sobie poprzez redukcję tokenów przy jednoczesnym zachowaniu istotnych informacji. Można to zrobić w trzech etapach.
Zanim informacje trafią do kontekstu. Dzielenie na fragmenty pozwala rozbić duże dokumenty na mniejsze, spójne części, a ponowna klasyfikacja sprawia, że tylko najlepsze fragmenty trafiają do okna. Wyniki narzędzi mogą być również podsumowywane w czasie rzeczywistym, zanim dołączą do głównego kontekstu.
Podczas gdy agent pracuje. Powszechną techniką jest streszczanie rozmowy: aktualizowane po każdej wymianie informacji streszczenie zapewnia zwięzły zapis wszystkiego, co dotychczas nastąpiło. Popularnym hybrydowym rozwiązaniem jest przechowywanie ostatnich dziesięciu wiadomości dosłownie, ponieważ mogą być one nadal potrzebne, natomiast wszystko starsze jest streszczane. Inną opcją jest proste usuwanie wiadomości według sztywno zdefiniowanych zasad – usuwa się stare wiadomości, gdy przekroczony zostanie określony próg objętości. Claude Code posiada funkcję automatycznego kompresowania, która streszczająca całą historię rozmowy, gdy pojemność okna osiągnie 95%. To zabezpieczenie. W idealnym przypadku kompresja odbywa się z wyprzedzeniem, a nie w momencie wystąpienia sytuacji awaryjnej.
Gdy agent już coś wykorzystał. Najprostszym rozwiązaniem jest usunięcie wyników narzędzia. Jeśli narzędzie wykonało piętnaście kroków wstecz, a agent już podjął działania na podstawie tych wyników, surowy tekst może zostać usunięty. Strona internetowa pobrana dawno temu może zostać zastąpiona jednozdaniowym streszczeniem lub całkowicie usunięta.
Izolacja
Izolacja jest tym, co sprawia, że systemy wielu agentów są użyteczne. Załóżmy, że jeden agent zajmuje się badaniami, planowaniem, programowaniem, testowaniem i debugowaniem w ramach jednej długiej rozmowy. Jego kontekst się wypełni, ale większym problemem jest zanieczyszczenie. Zapytania do plików z fazy badań nadal istnieją, gdy rozpoczyna się implementacja, a te stare materiały stanowią teraz szum, rozpraszający model w momencie, gdy musi napisać czysty kod.
Rozwiązaniem jest przydzielenie oddzielnych częściom pracy osobnych okien kontekstowych.
Oczywistym rozwiązaniem są podagenty. Rodzic przekazuje konkretne zadanie, na przykład znalezienie wszystkich plików związanych z uwierzytelnianiem, podagentowi, który pracuje w osobnym oknie. Po zakończeniu pracy podagent zwraca jedynie streszczenie, a całe skomplikowane wyszukiwanie pozostaje w jego obrębie, nie zakłócając pracy rodzica.
Inną variantą jest izolacja schematu stanu, jak to zaimplementowano w LangGraph. Stan agenta jest zaprojektowany tak, aby różne pola przechowywały różne rodzaje kontekstu, a model widzi tylko te pola, które są istotne dla bieżącego kroku. Wyniki narzędzi mogą znajdować się w polu niewidocznym dla modelu, dopóki coś specjalnie je nie wyświetli. To precyzyjna kontrola bez konieczności uruchamiania dodatkowych agentów.
Krótko mówiąc, strategie to zapisywanie, wybieranie, kompresowanie i izolacja, a wszystko, co następuje, stosuje jedną lub więcej z nich.
Jak agenty zawodzą
Tryby awarii pokazują, czego należy unikać. W połowie 2025 roku Drew Breunig napisał wpływową serię w dwóch częściach, w której opisał cztery odrębne sposoby, w jakie agenci przestają funkcjonować wraz ze wzrostem złożoności otoczenia, w którym działają.
Zatrucie kontekstem. Halucynacja lub błąd trafia do kontekstu i jest następnie wielokrotnie odwoływany. Być może narzędzie zwróciło błędne dane, albo agent wyciągnął błędne wnioski pięć kroków temu. Błąd pozostaje teraz w kontekście, a agent buduje na nim dalej, a ponieważ agenci iterują nad własnymi wynikami, każdy błędny krok pogłębia sytuację. Rozwiązaniem jest przycinanie: aktywne usuwanie przestarzałych lub sprzecznych informacji wraz z pojawianiem się nowych szczegółów, weryfikacja wyników narzędzi (szczególnie tych z zewnętrznych źródeł) przed ich dodaniem do kontekstu oraz kompresowanie nieudanych prób po tym, jak agent otrząśnie się z błędu, aby dziesięć kroków bezowocnego debugowania nie pozostawało, gdy liczy się już tylko rozwiązanie. Jeśli zostaną one pozostawione, te porzucone próby nadal będą kusić model, by wracał do metod, które już zawiodły.
Rozpraszanie uwagi przez kontekst. Przy bardzo długim kontekście model zaczyna zbyt mocno polegać na najnowszych wydarzeniach, a zbyt mało na tym, czego nauczył się podczas treningu. Przestaje tworzyć coś nowego i powtarza wzorce, które niedawno widział, powtarzając wcześniejsze działania zamiast opracowywać nowy plan. Rozwiązanie to jest takie samo jak ogólna rada: podsumowuj i agresywnie eliminuj niepotrzebne elementy, nawet jeśli zakres danych jest ogromny.
Zamieszanie w kontekście. Model przetwarza zbędny treść, co obniża jakość odpowiedzi. Klasycznym przykładem jest zamieszanie co do dostępnych narzędzi. W badaniu benchmarkowym użyto skwantyzowanego modelu Llama 3.1 8B na bazie testów GeoEngine. Przy czterdziestu sześciu dostępnych narzędziach model nie funkcjonował prawidłowo, mimo że ilość kontekstu była w pełni w granicach jego możliwości. Gdy natomiast dostępnych było tylko dziewiętnaście narzędzi, model działał poprawnie. Narzędzia mieściły się w dostępnych ograniczeniach, ale było ich zbyt wiele, by model mógł sprawnie o nich myśleć. Rozwiązaniem jest dynamiczne zarządzanie narzędziami – należy ograniczyć je do tych, które pasują do aktualnego etapu działania agenta, przy użyciu mechanizmu wyszukiwania w stylu RAG-MCP do wybierania odpowiednich narzędzi na każdym kroku.
Konflikt kontekstu. Nowe informacje zebrane podczas wykonywania zadania są sprzeczne z tym, co już znajduje się w kontekście. Komenda systemu może mówić jedno, podczas gdy pobrany dokument podaje coś innego. Agent nie potrafi ich pogodzić i zachowuje się niespójnie – czasem kieruje się jednym źródłem, czasem drugim, a czasami robi coś, co nie odpowiada żadnemu z nich. Rozwiązaniem jest jasne ustalenie hierarchii autorytetów: komenda systemu ma pierwszeństwo przed pobranymi faktami, a pobrane fakty przed historią rozmowy. Przed włączeniem nowych informacji należy je zweryfikować pod kątem tego, co już istnieje, a także używać ustrukturyzowanych sekcji, takich jak tagi XML lub wyraźne nagłówki, aby model mógł określić, skąd pochodzi każda informacja i w jakim stopniu może jej ufać.
Dobrą wiadomością jest to, że określenie przyczyny błędu zazwyczaj wskazuje na odpowiednią strategię. Problem zatrucia rozwiązuje się poprzez kompresję i przycinanie danych, rozproszenie uwagi – również poprzez kompresję, zamieszanie – poprzez selekcję, a konflikty – poprzez uporządkowane pisanie i selekcję. Wszystko sprowadza się do pisania, selekcji, kompresji i izolacji.
Wskazówki systemowe dla agentów
Formułowanie zapytań do agenta znacznie różni się od formułowania zapytań do chatbota. Zapytanie do chatbota przede wszystkim ustala ton: być przyjaznym, trzymać się krótko. Zapytanie do agenta określa jego architekturę. Opisuje ono przepływ sterowania, czyli sposób radzenia sobie z różnymi rodzajami zadań, jakie narzędzia pasują do jakich sytuacji, co robić po błędzie oraz jakie obowiązują ograniczenia bezpieczeństwa. Przypomina bardziej opis stanowiska pracy dla autonomicznego pracownika.
Anthropic mówi o pisaniu w odpowiedniej „wysokości”, czyli w takim stopniu precyzyjnym, by być użytecznym, a jednocześnie wystarczająco ogólnym, by model mógł działać elastycznie. Istnieje coś w rodzaju strefy Goldilocks. Zbyt sztywne zasady są kruche – wyobraźmy sobie regułę nakazującą używanie narzędzia X za każdym razem, gdy użytkownik wspomina o fakturowaniu, prosi o zwrot pieniędzy, a kwota przekracza sto dolarów. Taka reguła zawodzi przy każdym nietypowym przypadku, którego nikt nie przewidział. Zbyt ogólne zasady są równie złe – fraza „Bądź pomocny i używaj odpowiednich narzędzi” nie daje agentowi żadnych wskazówek, ponieważ nie wie, które narzędzia nadają się do jakich zadań i nie może podejmować decyzji bez konkretnych sygnałów. Optymalny stan to taki, w którym zasady są na tyle konkretne, by kierować autonomicznym zachowaniem modelu, a na tyle swobodne, by mógł on korzystać z własnego osądu w nowych sytuacjach. Należy myśleć o silnych heurystykach, a nie o sztywnych regułach.
Pomagają kilka praktycznych nawyków:
- Proszę o dostarczenie struktury zapytania, wykorzystującej tagi XML lub nagłówki markdown, które oddzielają informacje tła, instrukcje oraz wskazówki dotyczące narzędzi.
- Rozpocznij od minimalnego rozwiązania i iteruj w obliczu błędów. Uruchom agenta na rzeczywistych zadaniach, sprawdź, gdzie on zawodzi, i dodaj instrukcje skierowane właśnie na te konkretne problemy, zamiast próbować z góry przewidzieć każdy skrajny przypadek.
- Minimalizm nie jest tym samym co krótkość. Prompty dla złożonych procesów mogą zawierać tysiące tokenów, co nie stanowi problemu, pod warunkiem że każdy token ma uzasadnione znaczenie.
- Wykorzystuj przykłady typu few-shot. Pokazanie zróżnicowanych, wzorcowych przypadków prawidłowego wyboru narzędzia, rozsądnego rozumowania oraz prawidłowej realizacji w kilku krokach jest skuteczniejsze niż opisywanie każdej zasady słowami.
Definicje narzędzi
Każde narzędzie dostępne do wywołania wymaga schematu opisującego jego przeznaczenie, parametry oraz sytuacje, w których należy je używać. Dobra definicja jest samodzielna, odporna na błędy i jasno określa instrukcje, a jej kosztem jest przestrzeń kontekstowa.
W środowisku produkcyjnym narzędzia są coraz częściej łączone za pośrednictwem MCP, czyli Model Context Protocol – standardowego sposobu umożliwiającego agentom dostęp do zewnętrznych narzędzi i danych. Jeden serwer MCP dla GitHuba, drugi dla bazy danych, trzeci dla systemu plików – wszystkie one udostępniają narzędzia przez jednolitą interfejs. Problem polega na tym, że podłączanie narzędzi staje się tak proste, że można to robić w nadmiarze. Gdy podłączonych jest cztery lub pięć serwerów, definicje mogą zawierać tysiące tokenów jeszcze przed wykonaniem pierwszego kroku.
Standardową zaleceniem jest stworzenie minimalnego, funkcjonalnego zestawu narzędzi. Gdy agent rzeczywiście potrzebuje wielu narzędzi, sprawdzają się dwa podejścia.
Pierwszy przykład pochodzi od Manus, platformy dla agentów produkcyjnych. Zalecają oni unikanie dodawania i usuwania narzędzi w trakcie rozmowy z powodu, o którym wielu twórców nie wie – chodzi o cache KV. Gdy tokeny trafiają do modelu LLM, model oblicza dla każdego z nich reprezentacje typu klucz-wartość, co jest kosztowne, dlatego dostawcy przechowują je w cache. Jeśli początek kontekstu (prefiks) jest identyczny pomiędzy różnymi wywołaniami, dostawca ponownie wykorzystuje zapisane dane i przetwarza tylko nowe tokeny na końcu, co jest szybsze i tańsze.
Jeśli zmienisz kolejność lub edytujesz wczesną część kontekstu pomiędzy wywołaniami, cache staje się nieważny, więc wszystko musi zostać ponownie obliczone. W przypadku Claude Sonnet tokeny z cache kosztują trzydzieści centów za milion, podczas gdy te bez cache kosztują trzy dolary za milion – to dziesięciokrotna różnica. Agent wykonujący trzydzieści lub czterdzieści wywołań na zadanie szybko to odczuje.
Dlatego Manus preferuje maskowanie narzędzi zamiast ich usuwania. Każda definicja pozostaje w zapisanym prefiksie, ale niektóre narzędzia są oznaczone jako niedostępne w obecnej fazie. Definicje te pozostają w celu stabilności pamięci podręcznej, chociaż agent wie, że nie powinien ich używać, a spójne prefiksy nazewne pomagają mu rozróżniać kategorie narzędzi.
Drugim podejściem jest selekcja oparta na RAG, o której mowa wcześniej: pobieranie tylko tych narzędzi, które są istotne dla bieżącego kroku, co, jak pokazał artykuł RAG-MCP, zwiększyło dokładność ponad trzykrotnie przy jednoczesnym zmniejszeniu użycia tokenów o połowę. Obie metody uzupełniają się wzajemnie – maskowanie nadaje się do umiarkowanie dużego zestawu narzędzi, natomiast pobieranie – do bardzo dużego.
Pod obydwoma tymi elementami leży jedna podstawowa zasada. Treść stabilna znajduje się na górze kontekstu: prompt systemu, definicje narzędzi oraz wszystko to, co nie zmienia się pomiędzy kolejnymi etapami. Treść dynamiczna (historia, bieżący krok, stan agenta) znajduje się na dole.
Stopniowy proces pracy łączący wszystko
Zasady te obowiązują zarówno w przypadku gotowego asystenta do programowania, jak i agenta stworzonego na zamówienie. Jedydna różnica polega na tym, czy sam strukturyzujesz proces pracy, czy budujesz agenta, który to za Ciebie zrobi.
Dex Horthy, dyrektor generalny HumanLayer, wygłosił prelekcję na AI Engineer Code Summit, w której opisał metodę, która w przystępny sposób ilustruje to wszystko. Jego zespół rzekomo użył jej, aby w ciągu jednej siedmiogodzinnej sesji dodać około trzydziestu pięciu tysięcy linii kodu do dużego repozytorium w języku Rust. Nazywa tę metodę Frequent Intentional Compaction. Praca jest celowo podzielona na etapy – każdy etap tworzy skompresowany produkt, np. ustrukturyzowany podsumowanie w formacie markdown, a każdy nowy etap rozpoczyna się w nowym oknie zawierającym wyłącznie ten produkt. Celem jest celowe utrzymanie objętości tekstu na poziomie około 40 do 60 procent przestrzeni dostępnej w oknie.
Pierwsza faza – badania. Zanim zostanie napisany jakikolwiek kod, agent bada bazę kodu: czyta pliki, śledzi przepływy danych i mapuje architekturę istotną dla zadania. Podagenty wykonują surowe wyszukiwania i analizy, dzięki czemu wszystkie wyniki grep oraz treści plików pozostają w ich oknach i nigdy nie wpływają na okno nadrzędnego agenta. To właśnie jest izolacja. Wynikiem tej fazy jest plik z badaniami – kompaktowy dokument w formacie markdown zawierający ścieżki plików, sygnatury funkcji, istniejące wzorce oraz potencjalne problemy. To już etap pisania, ponieważ ustalenia są przechowywane poza oknem. Następnie kontekst jest resetowany. Surowe badania mogły zajmować od 60 do 80 procent przestrzeni w oknie, podczas gdy plik z wynikami zmniejsza tę ilość do około 15–20 procent. To właśnie jest kompresja.
Druga faza – planowanie. Otwiera się zupełnie nowe okno zawierające jedynie plik z danymi badawczymi oraz opis problemu, a agent wykorzystuje tę czystą bazę do opracowania szczegółowego planu wdrożenia. To również najlepsze miejsce na przegląd przez człowieka. Błąd logiczny wykryty w tym etapie jest łatwy do naprawienia, dlatego każdy, kto tworzy własnego agenta, powinien umieścić w tym miejscu punkt kontrolny z udziałem człowieka.
Trzecia faza – wdrożenie. Kolejne nowe okno zawiera wyłącznie plan, a agent realizuje go krok po kroku. W przypadku zadań wymagających kilku cykli kompresji plik progress.md rejestruje to, co zostało zakończone, a co pozostaje, co oznacza kolejne zapisanie danych.
Jakaś wersja tego procesu występuje w większości systemów produkcyjnych.
Jak prawdziwe produkty radzą sobie z kontekstem
Claude Code. Agent do programowania w wierszu poleceń firmy Anthropic należy do najlepiej udokumentowanych przykładów. Wykorzystuje hybrydowy mechanizm wyszukiwania: pliki CLAUDE.md są wczytywane na początku każdej sesji, aby zapewnić podstawowy kontekst, natomiast narzędzia takie jak glob i grep służą do eksploracji bazy kodu w momencie potrzeby. Nie tworzy uprzedniego indeksu wszystkich danych, lecz eksploruje je na żądanie. Funkcja automatycznej kompresji aktywuje się przy 95% wykorzystania zasobów i zachowuje decyzje architektoniczne oraz pięć najczęściej używanych plików. Może tworzyć podagenty z czystymi środowiskami do realizacji złożonych zadań, a narzędzie pamięci przechowuje informacje między sesjami. Podstawową zasadą jest robienie najprostszej rzeczy, która działa, poleganie na tym, że model sam wie, czego potrzebuje, oraz dostarczanie mu narzędzi do tego, by to znaleźć.
Manus. To podejście wymagające większej infrastruktury, które ma sens w przypadku agenta uniwersalnego obsługującego setki tysięcy użytkowników, gdzie ważna jest efektywność w dużych skali. Jego charakterystyczną cechą jest uporządkowanie z uwzględnieniem pamięci cache KV, zapewniające stabilność prefiksu na przestrzeni kolejnych ruchów w celu maksymalnego ponownego wykorzystania cache oraz maskowanie narzędzi zamiast ich usuwania. Proces kompresji obserwacji przetwarza każdy wynik narzędzia zanim trafi on do kontekstu agenta. Trwała lista zadań śledzi stan, a system plików pełni rolę pamięci zapasowej dla wyrzuconego kontekstu.
ChatGPT Agent. Agent firmy OpenAI, który wywodzi się z Operator, różni się pod względem architektury od obu tych rozwiązań. Opierając się na modelu Computer-Using Agent, obiera podejście oparte przede wszystkim na interfejsie graficznym. Zamiast wywoływać narzędzia za pomocą tekstu, steruje wizualnym przeglądarką, a zrzuty ekranu trafiają do kontekstu jako zdjęcia, nad którymi model analizuje informacje wraz z historią wcześniejszych zrzutów ekranu i wykonywanych działań. W związku z tym zmienia się również charakter wyzwań. Tokeny wizualne są kosztowne, dlatego agent musi starannie decydować, ile zrzutów ekranu zachować. OpenAI wykorzystuje uczenie wzmacniające do znajdowania skutecznych strategii korzystania z narzędzi, trenując je na tysiącach maszyn wirtualnych, zamiast ręcznie określać, kiedy użyć danego narzędzia. Deep Research i Operator dzielą się stanem, co umożliwia płynną przejścia pomiędzy przeglądaniem, analizą tekstu a wykonywaniem kodu. W porównaniu z skupionym na kodzie, opartym na narzędziach tekstowych i posiadającym duże okno Claude Code, ten narzędzie ma charakter wizualny i jest uniwersalne. Obie wersje wymagają projektowania kontekstu, choć przy różnych problemach i rozwiązaniach.
Google's Agent Development Kit. ADK przyjmuje najbardziej zasadniczą postawę architektoniczną, opierając się na trzech zasadach projektowania kontekstu dla agentów. Należy oddzielić przechowywanie od prezentacji, ponieważ trwały stan nie jest tym samym, co to, co pojawia się w danej wywołaniu API. Należy używać wyraźnych transformacji, czyli nazwanych, uporządkowanych procesorów, które przekształcają kontekst w testowalnych, komponowalnych krokach, zamiast używać ad hoc łączenia ciągów znaków. Domyślnie należy ograniczyć zakres kontekstu, tak aby każde wywołanie modelu widziało tylko to, co jest absolutnie konieczne, a nic nie trafiało do kontekstu, chyba że zostało to wyraźnie dodane. W rezultacie montaż kontekstu jest traktowany jako proces z wyraźnymi etapami, a nie jako prompt, do którego ciągle coś dodaje się później.
Wspólny proces przetwarzania kontekstu
Przyglądając się tym platformom, przy każdej turze agenta pojawia się ta sama struktura:
- Zbieranie kandydatów: dane wejściowe użytkownika, historia, wyniki narzędzi, pobraane dokumenty oraz stan agenta.
- Wybór tego, co jest istotne dla danego kroku, w ramach dostępnego budżetu tokenów.
- Kompresja poprzez streszczanie, skracanie lub przestructuryzowanie wybranych danych, aby zmieściły się w limicie.
- Układanie wszystkich elementów w sposób umożliwiający ponowne użycie w pamięci KV – najpierw treści stałe, a na końcu dynamiczne.
- Tworzenie ostatecznego kontekstu i wykonywanie żądania.
W tej dziedzinie rozwój postępuje szybko i wciąż jest wiele do nauczenia, więc najlepszym sposobem na poprawę jest eksperymentowanie: tworzenie nowych rozwiązań, obserwowanie, gdzie występują błędy, i ich korygowanie.
Literatura pokrewna
- Inżynieria kontekstu dla aplikacji opartych na LLM: ustrukturyzowane wyniki, narzędzia i ograniczenia agentów: Jak celowo przygotowywać dane wejściowe dla modeli: selekcja kontekstu, szablony zapytań, schematy JSON, ograniczona dekodacja, wywoływanie narzędzi, pętle agentów oraz ograniczona autonomia.
- Strategie dzielenia na fragmenty w RAG produkcyjnym: o rozmiarze stałym, semantycznym oraz typie rodzic-dziecko: Praktyczny przegląd strategii dzielenia na fragmenty w RAG – od podziału o rozmiarze stałym i rekurencyjnym po rozwiązania typu rodzic-dziecko, propozycje, późne dzielenie na fragmenty, RAPTOR, tabele, kod oraz testy wydajności.