Inżynieria kontekstu dla agentów AI działających w długim horyzoncie

Łącznie analiza Arize, artykuł arXiv o przepełnieniu okna kontekstu, wyjaśnienie produkcyjne Redis oraz porównanie inżynierii warstwy sterującej Atlan wskazują na praktyczną zmianę w projektowaniu agentów. Długotrwale działający agenci są oceniani coraz mniej przez pryzmat wielkości okna kontekstu modelu, a coraz bardziej przez warstwę kontroli wokół niego. Arize konkretyzuje tę zmianę. Wymienia wdrożone narzędzia agentowe oraz systemy pamięci/warstwy sterującej, w tym Pi, OpenClaw, Claude Code i Letta, jako przykłady inżynierii kontekstu na poziomie warstwy sterującej oraz opisuje interaktywny symulator pokazujący, jak zapełnia się okno o pojemności 200 tys. tokenów.

Publiczne szczegóły dostępne w cytowanych źródłach są nierówne. Arize podaje konkretne liczby implementacyjne dla Pi, OpenClaw, Claude Code i Letta. Artykuł badawczy o rozwiązywaniu przepełnienia okna kontekstu w agentach AI przedstawia bardziej ogólny mechanizm obsługi wyników narzędzi, które mogą przekroczyć dowolne praktyczne okno. Wyjaśnienie Redis dotyczące przepełnienia okna kontekstu podsumowuje symptomy produkcyjne: twarde błędy API, cichą degradację jakości, kumulowanie się wyników narzędzi i rosnące opóźnienia wraz ze wzrostem promptów. Porównanie inżynierii promptów, kontekstu i warstwy sterującej Atlan dostarcza użytecznej metafory stosu: inżynieria promptów kształtuje komunikat, inżynieria kontekstu kształtuje to, co widzi model, a inżynieria warstwy sterującej kształtuje całe środowisko agenta.

Ważną wiadomością nie jest to, że okna kontekstu są za małe. Twórcy już to wiedzą. Bardziej użyteczne jest to, że cytowane systemy agentowe zbiegają się wokół czterech mechanizmów warstwy sterującej, które utrzymują pracę przy życiu, gdy transkrypt przestaje być bezpiecznym źródłem prawdy.

Płytki agent czyta pliki, wywołuje narzędzia, dopisuje wynik i ma nadzieję, że model sobie poradzi. Agent projektowany od warstwy sterującej blokuje lub przekształca duże wejścia, zanim dotrą do modelu.

Czytelniejszy sposób interpretacji pierwszego zestawu limitów wygląda tak:

• Pi: odczyty plików zatrzymują się na 2 000 liniach lub 50 KB, zależnie od tego, co nastąpi wcześniej. Zwrócona treść zawiera wskazówkę kontynuacji, która mówi modelowi, jaki zakres linii został pokazany i jak kontynuować za pomocą offset oraz limit. OpenClaw dziedziczy to zachowanie, a następnie dodaje osobne limity: pliki startowe są ograniczone do 12 000 znaków na plik i 60 000 znaków łącznie. Wyniki narzędzi otrzymują kolejny budżet: 16 000 znaków lub 30% okna kontekstu, zależnie od tego, która wartość jest mniejsza.

Claude Code używa projektu z dwiema bramkami. Według Arize sprawdza limit 256 KB w bajtach przed otwarciem pliku, a następnie po odczycie liczy tokeny wyniku względem budżetu 25 000 tokenów. Nawet w przypadku plików poniżej limitu domyślnie zwraca 2 000 linii od początku i obcina linie dłuższe niż 2 000 znaków. Jeśli model ponownie czyta ten sam zakres pliku, a plik się nie zmienił, Claude Code może zwrócić zaślepkę zamiast powtarzać pełną treść.

To nie jest tylko optymalizacja. To zmienia tryb awarii. Zamiast pozwolić, by jeden duży odczyt wyparł zadanie, warstwa sterująca zamienia „przeczytaj wszystko” na „przeczytaj kontrolowany wycinek”. Jeśli model potrzebuje więcej, może o to poprosić. Dla twórców projektujących warstwy sterujące agentów od zera to pierwsza linia obrony: nigdy nie pozwól, by surowe dane zewnętrzne domyślnie stały się transkryptem.

Kolejny wzorzec polega na traktowaniu kontekstu jak widocznego obszaru, a nie magazynu.

Pi i Claude Code udostępniają paginację przez offset i limit. OpenClaw w niektórych miejscach dodaje obcinanie początku/końca, zachowując początek i koniec, gdy środek ma mniejsze znaczenie. Arize podaje, że OpenClaw używa podziału 75% początku / 25% końca dla zbyt dużych plików startowych i może zachować zarówno początek, jak i koniec wyników narzędzi, gdy koniec wygląda na ważny, na przykład zawiera błędy, zamykające nawiasy klamrowe JSON lub słowa kluczowe przypominające podsumowanie.

Letta idzie dalej, utrzymując pliki poza promptem. Przesłane pliki są parsowane, dzielone na fragmenty i osadzane w magazynie wektorowym, co daje agentowi bezpośredni podgląd, dokładne wyszukiwanie i wyszukiwanie semantyczne. Gdy plik jest otwarty w kontekście, Letta pokazuje zarządzany widok, którego rozmiar skaluje się wraz z kontekstem modelu: 5 000 znaków dla kontekstu 8K, 15 000 dla 32K, 25 000 dla 128K i 40 000 dla 200K+. Liczba jednocześnie otwartych plików także się skaluje: od 3 dla małych modeli do 15 dla bardzo dużych, z polityką LRU usuwającą najrzadziej ostatnio używane pliki.

To ta sama idea projektowa, która stoi za produkcyjnym RAG: nie upychaj całego korpusu w prompcie; pobierz część, która ma znaczenie. Różnica polega na tym, że warstwy sterujące agentów muszą robić to ciągle, w plikach, wynikach narzędzi, pamięci i planach pośrednich. To samo ograniczenie dotyczy systemów RAG: pobieranie nie polega tylko na trafności, lecz także na zachowaniu wystarczającego budżetu kontekstu na właściwy krok rozumowania.

Redis zwraca uwagę na powiązaną kwestię: większe okna kontekstu nie usuwają potrzeby zarządzania kontekstem. Prompty systemowe, pobrane dokumenty, historia rozmowy i wyniki narzędzi konkurują o tę samą przestrzeń. Nawet zanim zostanie osiągnięty twardy limit, modele mogą tracić jakość, gdy istotne informacje zostają pogrzebane w długich wejściach.

Przepełnienie to oczywista awaria. Utrata celu jest cichsza. Agent wciąż ma miejsce, aby odpowiedzieć, ale zapomina pierwotny cel, pomija ograniczenie albo zaczyna optymalizować lokalne podzadanie.

Właśnie tu znaczenie ma kompakcja. Źle wykonana, zastępuje chaotyczną, ale wierną historię schludną, lecz stratną opowieścią. Dobrze wykonana, zachowuje stan zadania, ostatnią pracę, elementy oczekujące i integralność wywołań narzędzi.

Arize podaje, że Pi uruchamia kompakcję, gdy szacowana liczba tokenów kontekstu przekracza okno kontekstu minus tokeny rezerwowe, z domyślną rezerwą 16 384 tokenów. Zachowuje mniej więcej ostatnie 20 000 tokenów i streszcza starszą treść do syntetycznej wiadomości użytkownika dodanej przed zachowanym ogonem. Unika też cięcia par wywołanie narzędzia/wynik narzędzia.

OpenClaw dodaje bardziej agresywną politykę historii. Gdy historia przekracza 50% okna kontekstu, dzieli wiadomości na fragmenty o równej masie tokenów, usuwa najstarszy fragment, streszcza usuniętą treść przez etapowe, wieloprzebiegowe podsumowywanie i naprawia parowanie wywołań narzędzi z wynikami. Wykonuje też flush przed kompakcją: cicha tura agentowa daje agentowi szansę zapisania stanu do plików pamięci, zanim historia zniknie. Osobno przycina wyniki narzędzi w pamięci za pomocą zachowania soft-trim i hard-clear w pamięci podręcznej z TTL 5 minut.

Claude Code kompaktuje blisko końca okna. Arize podaje, że wyzwalaczem jest efektywne okno kontekstu minus bufor 13 000 tokenów, co umieszcza kompakcję około 167K tokenów dla modelu z kontekstem 200K. Jego prompt podsumowujący prosi o uporządkowane sekcje obejmujące główne żądanie, pojęcia techniczne, pliki i kod, błędy i poprawki, rozwiązywanie problemów, wiadomości użytkownika, zadania oczekujące, bieżącą pracę i następny krok. Po kompakcji może ponownie dołączyć do 5 niedawno czytanych plików w ramach budżetu tokenów.

Wzorzec jest jasny: kompakcja to nie „streszczenie czatu”. To tworzenie punktu kontrolnego. Długotrwale działający agent potrzebuje odpowiednika pliku zapisu: celu, ograniczeń, decyzji, otwartych uchwytów, najnowszych dowodów i następnej akcji.

Niektóre wyniki w ogóle nie powinny trafiać do okna kontekstu.

Artykuł arXiv konkretyzuje to na przykładzie przepływu pracy z zakresu nauki o materiałach. Jedno narzędzie generuje elektroniczną strukturę siatki dla cząsteczki: macierz 3D o wymiarach 128 × 128 × 128, łącznie 2 097 152 elementy float32. Taki wynik znacznie przekracza okno kontekstu powszechnie używanych LLM-ów. Ale kolejne narzędzie potrzebuje tej siatki jako wejścia.

Proponowane rozwiązanie polega na przechowywaniu dużych wartości poza kontekstem modelu i zwracaniu krótkich identyfikatorów, czyli wskaźników. Wrappery narzędzi sprawdzają wejścia, aby ustalić, czy są surowymi wartościami, czy ścieżkami pamięci. Wyniki, które są zbyt duże, są zapisywane w pamięci wykonawczej pod ścieżką, a późniejsze narzędzia mogą otrzymać wskaźnik i rozwiązać go wewnętrznie. Model operuje referencjami, a warstwa sterująca zachowuje kompletne dane. Według artykułu w jednym eksperymencie porównawczym, w którym obie metody zakończyły się sukcesem, podejście oparte na wskaźnikach zużyło około siedem razy mniej tokenów niż tradycyjny przepływ pracy.

To najczystszy rozdział między rozumowaniem a transportem danych. Model nie musi „widzieć” macierzy z 2 milionami elementów, aby przekazać ją innemu narzędziu. Musi wiedzieć, że macierz istnieje, co reprezentuje i która operacja powinna ją wykorzystać jako następna.

Ta sama logika działa poza tablicami naukowymi. Duże odpowiedzi JSON, PDF-y, logi, embeddingi, pliki multimedialne i eksporty baz danych często należą do magazynu, nie do promptu. W systemach zbudowanych wokół narzędzi MCP lub niestandardowych konektorów API przekazywanie wskaźników powinno być pierwszorzędną decyzją projektową, a nie łatą po pierwszym przepełnieniu.

Okno kontekstu o pojemności 200K tokenów wydaje się duże, dopóki agent nie zacznie działać. Prompt systemowy, definicje narzędzi, kilka pobranych dokumentów, odczyty plików, logi, ślady błędów i podsumowania mogą zużyć je szybciej, niż można się spodziewać. Praktyczne pytanie nie brzmi, jak duże okno wygląda na papierze, lecz jak szybko agenci wydają je w czasie wykonania. Wskazówki Redis dotyczące pamięci agentów prowadzą w stronę zewnętrznej, trwałej pamięci dla stanu, który powinien przetrwać między wywołaniami, a ujęcie inżynierii kontekstu Atlan oddziela lepsze prompty od lepszego składania kontekstu. Razem traktują okno kontekstu mniej jak magazyn, a bardziej jak ograniczony zestaw roboczy.

Głębsza lekcja jest taka, że okno kontekstu to deficytowy zasób czasu wykonania. Traktowanie go jak „pamięci” jest pomocne, ale tylko wtedy, gdy warstwa sterująca zachowuje się jak system operacyjny: alokuje, eksmituje, stronicuje, kompaktuje, deduplikuje i utrwala. Rozróżnienie warstw Atlan jest tu użyteczne. Inżynieria promptów nie naprawi czytnika plików, który wrzuca 80 000 nieistotnych tokenów do następnego wywołania. Inżynieria kontekstu może poprawić zestaw roboczy. Inżynieria warstwy sterującej decyduje, czy ten zestaw roboczy jest w ogóle chroniony.

Zmienia to także sposób, w jaki zespoły powinny oceniać agentów. Demo prompt nie wystarczy. Ocena w długim horyzoncie powinna obejmować rosnące transkrypty, powtarzane odczyty plików, duże wyniki narzędzi, nieudane wywołania narzędzi, wznowienia po kompakcji oraz zadania, w których poprawny następny krok zależy od wczesnego ograniczenia. Nasz przewodnik po inżynierii kontekstu dla agentów omawia wersję tego problemu po stronie modelu; warstwa sterująca jest miejscem, w którym staje się on operacyjny.

Po pierwsze, wprowadź budżety dla każdego źródła kontekstu. Pliki, wyniki narzędzi, pobrane fragmenty, wpisy pamięci i historia rozmowy powinny mieć osobne, jawne limity. Jeden globalny maksymalny licznik tokenów jest zbyt toporny.

Po drugie, spraw, aby obcinanie było użyteczne. Jeśli warstwa sterująca ucina treść, model powinien wiedzieć, jaki zakres zobaczył i jak poprosić o więcej. Ciche obcinanie jest gorsze niż odrzucenie, bo tworzy pewne siebie działanie na brakujących danych.

Po trzecie, kompaktuj wokół stanu, nie prozy. Podsumowania powinny zachowywać cel użytkownika, ograniczenia, decyzje, zadania oczekujące, dotknięte pliki, istotne wyniki narzędzi i bezpośredni następny krok. Pary wywołań narzędzi powinny pozostać nienaruszone.

Po czwarte, przenieś duże wartości poza prompt. Przechowuj je, nadawaj im nazwy i przekazuj wskaźniki przez narzędzia. To szczególnie ważne dla agentów, którzy wywołują API, przetwarzają dokumenty lub koordynują systemy wieloagentowe.

Na koniec testuj utratę celu osobno od przepełnienia. Agent może mieścić się pod twardym oknem i nadal dryfować. Właściwe pytanie brzmi nie tylko: „czy API zaakceptowało prompt?”. Brzmi: „czy następna akcja wciąż służy pierwotnemu zadaniu?”.

Poniższe podsumowanie zamienia te wzorce w krótką checklistę przed FAQ.

• Agenci działający w długim horyzoncie zawodzą zarówno przez przepełnienie kontekstu, jak i utratę celu, więc warstwa sterująca musi zarządzać czymś więcej niż długością promptu.
• Produkcyjne systemy agentowe stosują twarde budżety na pliki, wyniki narzędzi i historię, zanim surowe dane dotrą do modelu.
• Paginacja, wyszukiwanie i zarządzane widoki traktują kontekst jako ograniczony widoczny obszar, a nie trwały magazyn.
• Kompakcja działa najlepiej jako tworzenie punktu kontrolnego: zachowuje cele, ograniczenia, decyzje, oczekującą pracę i integralność wywołań narzędzi.
• Duże wyniki narzędzi często powinny trafiać do zewnętrznego magazynu, z krótkimi wskaźnikami przekazywanymi między narzędziami zamiast pełnych wartości w prompcie.

Ta sekcja odpowiada na praktyczne pytania stojące za inżynierią kontekstu dla agentów działających w długim horyzoncie: co się przepełnia, jak giną cele i które wzorce warstwy sterującej utrzymują pracę na właściwym torze.

Przepełnienie kontekstu występuje, gdy skumulowany prompt agenta, historia, pobrane dane, pliki i wyniki narzędzi przekraczają użyteczne okno kontekstu modelu albo obniżają jakość, zanim zostanie osiągnięty twardy limit.

Utrata celu występuje, gdy pierwotne zadanie wciąż znajduje się gdzieś w transkrypcie, ale nie kieruje już następną akcją agenta, często po długich historiach lub słabym podsumowaniu.

Ustawiają budżety dla poszczególnych źródeł, paginują odczyty plików, pobierają tylko istotne widoki, kompaktują historię wokół stanu, deduplikują powtarzane odczyty i przechowują duże wyniki poza promptem.

Wskaźniki pozwalają modelowi odwoływać się do dużych wartości przechowywanych w pamięci wykonawczej, takich jak macierze, logi czy PDF-y, podczas gdy narzędzia downstream rozwiązują pełne dane bez umieszczania ich w oknie kontekstu.

Nie. Większe okna pomagają, ale prompty systemowe, definicje narzędzi, pobrane dokumenty, logi i historia nadal konkurują o miejsce, a istotne informacje mogą zostać pogrzebane, zanim zostanie osiągnięty twardy limit.