Inżynieria kontekstu dla agentów działających przez długi czas: baza danych wektorowych, pamięć KV cache, Claude Code

Napisano wiele na temat tego, czym jest inżynieria kontekstu. Znacznie mniej tekstów dotyczy pytania, z którym boryka się praktyk w codziennej pracy: jak powinien być zaprojektowany pipeline kontekstu dla agenta działającego przez 200 kroków? Okno o pojemności miliona tokenów wydaje się wystarczające, jednak badanie Chromy z 2025 roku przeprowadzone na 18 modelach najnowszej generacji wykazało, że jakość zaczyna spadać, gdy okno jest wypełnione w 50 do 70 procent. Poniżej znajduje się plan działania w tym zakresie, skierowany do osób tworzących agenty do użycia w produkcji. Omawia on powody degradacji długich kontekstów, model pamięci zapożyczony z architektury komputerów, cztery wzorce zarządzania kontekstem, aspekty ekonomiczne pamięci typu KV cache, różnice między trzema dobrze znanymi produktami oraz ścieżkę decyzyjną opartą na wskaźnikach.

Agent bez zaprojektowanej pamięci cierpi na amnezję

Załóżmy agenta, który prawidłowo wykonywał kroki od 1 do 40. W kroku 41 wydaje się zapominać o celu i zaczyna powtarzać decyzje, które już podjął. Rzadko jest to błąd logiczny – chodzi tu o degradację kontekstu, mierzalny spadek jakości odpowiedzi wraz ze wzrostem długości danych wejściowych. Im więcej informacji otrzymuje model, tym więcej w rzeczywistości traci.

Badania przeprowadzone przez Zylos AI w 2026 roku wskazują na to samo: podwojenie czasu trwania zadania ma zwiększyć szansę na niepowodzenie czterokrotnie, a jakość pracy agentów pogarsza się po około 35 minutach pracy nad tym samym zadaniem. Wymieniony wcześniej wynik badań Chroma pokazał, że każdy z 18 modeli tracił na jakości wraz ze wzrostem ilości kontekstu. Benchmark NoLiMa (ICML 2025) pokazał jeszcze gorsze wyniki – już przy 32K tokenach 11 z 13 modeli osiągało wyniki poniżej połowy swoich bazowych wartości, mimo że deklarowały możliwość obsługi 128K lub więcej tokenów, a GPT-4o spadł z 99,3% na 69,7%.

Dlaczego degradacja jest wbudowana

Transformer attention porównuje każdy token z każdym innym tokenem. Podwojenie długości tekstu powoduje zatem około czterokrotny wzrost obciążenia obliczeniowego, a nie dwukrotny. Przy 200 tysiącach tokenów oznacza to około 40 miliardów par uwagi na warstwę. Umieszczanie wszystkiego w kontekście po prostu nie jest skalowalne dla agenta pracującego przez setki kroków.

Drugim efektem jest „utrata informacji w środku”. Modele najlepiej radzą sobie z początkiem i końcem długiego kontekstu, tracąc precyzję w jego środkowej części, więc kluczowe informacje tam ukryte mogą być niemal niewidoczne. Co ciekawe, tekst spójny i dobrze zorganizowany, ale nieistotny, bardziej obniża dokładność niż te same zdania przetasowane losowo. Semantyczna podobieństwo wśród szumu utrudnia znalezienie prawdziwego sygnału.

Podana wielkość okna jest również myląca. Model, który może obsłużyć milion tokenów, nie zapewnia miliona tokenów rzeczywistej pojemności.

Lęk przed kontekstem

Użytkownicy zauważyli, a Anthropic to potwierdził, jeszcze jedną osobliwość: Claude Sonnet 4.5 miał tendencję do zakończania zadań zbyt wcześnie, gdy zbliżał się do limitu kontekstu. Zjawisko to nazywa się lękiem przed kontekstem. Model zachowuje się tak, jakby kończyła mu się pamięć RAM, i rezygnuje, zanim faktycznie wyczerpią się jego zasoby.

Ponieważ degradacji nie da się uniknąć, architektura agenta musi sobie z nią radzić. W inżynierii systemów istnieje długo znana analogia, która w tym przypadku jest pomocna.

Model to procesor, kontekst to pamięć RAM, a baza wektorowa to dysk

W połowie 2025 roku Andrej Karpathy opowiedział się za „inżynierią kontekstu” zamiast „inżynierią promptów”, określając ją jako delikatne sztukę i naukę wypełniania okna właściwymi informacjami potrzebnymi do następnego kroku. Nie wymyślał żadnego modnego terminu – wskazywał na zmianę perspektywy: LLM to procesor, okno kontekstu to pamięć RAM, a inżynier budujący agenta pełni rolę systemu operacyjnego.

Ta analogia doskonale sprawdza się w praktyce. Kompresja przypomina zbieranie śmieci, iniekcja stanu przypomina sekwencję uruchamiania, podagenty przypominają izolację procesów, a plik taki jak CLAUDE.md to konfiguracja ładowana podczas startu. Zmienia się jednak punkt uwagi: mniej wysiłku wkłada się w sformułowanie promptu, a więcej w to, co i kiedy zostanie załadowane do pamięci.

Hierarchia pamięci dla agentów

Agent ma hierarchię podobnie jak komputer, przy czym każdy poziom kompromituje szybkość w zamian za pojemność:

• Pamięć robocza w kontekście. Brak dodatkowego opóźnienia, od 200K do 1M tokenów. Dorównuje rejestrom i pamięci podręcznej L1: jest najszybsza, najdroższa i najbardziej ograniczona.
• Pamięć podręczna KV. Poniżej 10 ms. Porównywalna z pamięcią podręczną L2 lub L3, przechowuje matryce uwagi obliczone z góry dla wcześniejszych tokenów i zachowywane między zapytaniami.
• Baza danych wektorowych lub wyszukiwanie semantyczne. Około 5 do 50 ms oraz miliony wpisów, odpowiednik pamięci RAM. Podane wartości obejmują około 0,34 ms na zapytanie przy lokalnym uruchamianiu FAISS oraz 7 ms p99 dla Pinecone.
• System plików lub notatki. Powyżej 100 ms bez rzeczywistego ograniczenia wielkości, podobnie jak dysk.
• Przechowywanie archiwalne. Czas odczytu wynoszący sekundy, porównywalny z przechowywaniem sieciowym lub zapasowym.

Każda decyzja dotycząca miejsca przechowywania informacji to kompromis pomiędzy kosztem, opóźnieniem a pojemnością. Wybór niewłaściwej warstwy skutkuje albo wysokim rachunkiem, albo agentem, który zapomina. Praca z 2023 roku z serii MemGPT, często cytowana, sformalizowała tę koncepcję pod nazwą „zarządzanie wirtualnym kontekstem”, opierając się na sposobie, w jaki systemy operacyjne zarządzają pamięcią warstwową. Kontynuacją tego podejścia jest dziś framework Letta.

Jeśli kontekstem jest pamięć RAM agenta, to jakie wzorce są używane do jego zarządzania w rzeczywistym systemie i jak ze sobą współgrają?

Cztery wzorce: zapisywanie, wybieranie, kompresowanie, izolacja

Inżynieria kontekstu opiera się na czterech podstawowych wzorcach. Nie są to alternatywy do wyboru – stanowią uzupełniające się elementy jednego kompleksowego projektu, a każdy agent produkcyjny ostatecznie wykorzystuje wszystkie cztery.

Zapisywanie: umieszczenie stanu poza oknem

Pisanie oznacza zewnętrzną reprezentację stanu. Agent przechowuje notatki w pliku takim jak todo.md, NOTES.md lub progress.md i odczytuje je ponownie w późniejszych krokach. Manus jest znany z „recytacji listy zadań”: agent ciągle przepisuje swoją listę zadań na samym końcu kontekstu, aby uwaga modelu była skierowana na ogólny plan. To celowe kierowanie uwagą, które przeciwdziała efektowi zagubienia się w środku procesu.

Claude Opus 4 w eksperymencie z grą Pokémon, jak donoszono, utrzymywał dokładne notatki przez tysiące kroków gry, obejmujące poziomy postaci, mapy i strategie, bez żadnych wyraźnych instrukcji dotyczących strukturyzacji pamięci.

Wybór: pobieranie tylko w odpowiednim momencie

Wybór tego rozwiązania oznacza pobieranie kontekstu w momencie jego potrzeby, zamiast wcześniejszego ładowania go. CLAUDE.md pełni rolę statycznego źródła danych do wcześniejszego ładowania, podobnie jak dokument wprowadzający przekazywany nowemu pracownikowi już pierwszego dnia. Następnie agent bada bazę kodu za pomocą narzędzi takich jak grep i glob, pobierając tylko to, czego potrzebuje w danym kroku.

Podobno Claude Code przetestował bazy danych wektorowych, ale je odrzucił, ponieważ kod może ulec dezynchronizacji, a uprawnienia stają się skomplikowane. Cursor obrał inną drogę, stawiając na dynamiczne odkrywanie informacji poprzez indeksowanie semantyczne. Według doniesień test A/B pokazał 46,9% zmniejszenie liczby tokenów, gdy agent ładował narzędzia MCP na żądanie.

Kompresja: zmniejszenie objętości

Kompresja polega na zmniejszeniu objętości poprzez streszczanie lub skracanie treści. Proces kompaktacji polega na poproszeniu modelu LLM o streszczenie dotychczasowej rozmowy, co pozwala zwolnić miejsce w oknie interfejsu, zachowując przy tym najważniejsze informacje.

Claude Code rzekomo ostrzega, gdy pojemność osiąga około 80%, i automatycznie kompresuje dane przy poziomie około 95%, zachowując przy tym decyzje architektoniczne. Zbyt agresywna kompresja eliminuje subtelne, lecz kluczowe konteksty, przez co agent zaczyna ponownie badać obszary, które już przeanalizował. W praktyce kompresja 3 do 6 razy wydaje się optymalnym rozwiązaniem dla zadań produkcyjnych. Badania akademickie wskazują na znacznie wyższe wskaźniki (LLMLingua podaje 20 razy z stratą dokładności wynoszącą zaledwie 1,5 punktu w przypadku GSM8K), ale zastosowania produkcyjne wymagają wyższej wierności przekazu.

Izolacja: separacja za pomocą podagentów

Izolacja oznacza trzymanie kontekstów oddzielnie. Specjalistyczny agent dziecięcy pracuje we własnym oknie kontekstowym i przekazuje skondensowany wynik swojemu rodzicowi. Może przetworzyć 10 tysięcy tokenów lub więcej, ale zwraca jedynie streszczenie liczące od 1 do 2 tysięcy tokenów, co jest znacznie mniej niż to, co mogłoby zostać zgromadzone w przypadku wspólnego kontekstu. Manus stosuje zasadę zapożytą z języka Go: nie komunikuj się poprzez dzielenie się pamięcią, dziel się pamięcią poprzez komunikację.

Kluczowe nie jest to, który wzorzec wybrać, ale jak je łączyć i kiedy każdy z nich powinien zostać uruchomiony. Pisanie w połączeniu z selekcją stanowi pierwszą linię obrony, natomiast kompresja w połączeniu z izolacją umożliwia skalowanie systemu.

Jedna z aspektów zarządzania kontekstem ma ogromny wpływ na koszty produkcji i jest często pomijana podczas projektowania.

Wskaźnik trafień w pamięci cache KV – liczba, która ma znaczenie

KV cache przechowuje macierze uwagi już obliczone dla wcześniejszych tokenów, dzięki czemu model nie musi ich ponownie obliczać dla każdego nowego tokena. Można to porównać do bazy danych, która z góry oblicza operacje łączenia dla często używanych prefiksów zapytań. W jednym pomiarze GPT-2 generowanie 200 tokenów zajęło 11,9 sekundy przy użyciu cache, a 56,2 sekundy bez niego, co daje przyspieszenie około 4,7 raza.

Dlaczego to zmienia zasady funkcjonowania agentów

Typowy agent produkcyjny ma stosunek wejścia do wyjścia na poziomie około 100 do 1, w porównaniu z około 1 do 1 u chatbotów. Ponowne obliczanie całego wejścia dominuje przy każdym wezwaniu. Prompt caching to mechanizm po stronie dostawcy, który przechowuje obliczone tokeny dla identycznych prefiksów pomiędzy zapytaniami, co sprawia, że odczyty są około dziesięć razy tańsze. Dla Claude Sonnet podane ceny wynoszą 0,30 dolara za milion tokenów przechowywanych w cache w porównaniu z 3,00 dolara za tokeny bez cache.

Zmiana projektu kontekstu wokół pamięci cache KV może skutecznie zmniejszyć miesięczny rachunek za API z 8000 dolarów do 800 dolarów, co jest zgodne z dziesięciokrotną zniżką na wykorzystanie pamięci cache oferowaną przez Anthropic. Yichao „Peak” Ji, współzałożyciel Manus, stwierdził, że dla agenta w użyciu nic nie jest ważniejsze niż częstotliwość dostępu do pamięci cache KV.

Trzy zasady utrzymywania pamięci cache w aktywności

• Stabilny prefiks. Różnica jednego tokena oznacza nieudany dostęp do pamięci cache. Błędem, na który zwraca uwagę Manus, jest umieszczanie daty i godziny na początku instrukcji systemowych – to pozwala modelowi podawać czas i niszczy wskaźnik skuteczności dostępu do pamięci cache.
• Kontekst do dodawania tylko. Można tylko dodawać elementy do kontekstu, nigdy edytować go retroaktywnie. Historia pozostaje niezmieniona, ponieważ każda zmiana powoduje nieudany dostęp do pamięci cache. Serializacja JSON musi również być deterministyczna, ponieważ liczy się kolejność kluczy.

Jasne punkty przerw w pamięci cache. Zaznacz w kontekście punkty, które wskazują dostawcy, gdzie należy zapisać prefiks do pamięci cache.

Istnieje również pułapka związana ze skalą, czasami nazywana „podatkiem MCP”. Załóżmy, że 10 do 15 narzędzi zawiera po 10K do 15K tokenów definicji. To oznacza od 100K do 225K tokenów nadmiarowych danych jeszcze przed tym, jak użytkownik cokolwiek wpisze. W przypadku 1000 programistów prowadzących po pięć sesji dziennie, szacunkowe obliczenia wskazują na wydatki na poziomie około 1,2 miliona dolarów rocznie wyłącznie na definicje narzędzi. Rozwiązaniem jest stopniowe ujawnianie informacji: ładowanie narzędzi w odpowiednim momencie zamiast wszystkich naraz.

Wskaźniki trafień do pamięci cache oraz cztery wzorce to teoria. Jak wyglądają one w systemach, które już borykały się z tym problemem w środowisku produkcyjnym?

Claude Code i dwa inne produkty, trzy filozofie

Claude Code, Cursor i Manus oferują trzy spójne, lecz różne rozwiązania tego samego problemu. Każde z nich wynika z własnego kontekstu produktu, a nie z nieznajomości alternatyw.

Claude Code: statyczne wczytywanie z wyprzedzeniem plus odczyty w momencie potrzeby

Claude Code od Anthropic ładuje plik CLAUDE.md na początku sesji jako dokument wprowadzający, a następnie przegląda kod bazowy za pomocą narzędzi glob i grep, bez użycia bazy danych wektorowych. Automatycznie kompresuje pliki do około 95% ich rozmiaru, zachowując przy tym decyzje architektoniczne. Połączenie narzędzia do zarządzania pamięcią z edycją kontekstu miało zapewnić 39% poprawy w porównaniu z bazowym rozwiązaniem.

Kwestia lęku przed kontekstem w wersji Sonnet 4.5 oznaczała, że model wymagał ponownego ustawiania kontekstu z zewnątrz. Według informacji Anthropic rozwiązało ten problem w późniejszych wersjach modelu, nie zmieniając architektury narzędzia.

Cursor: dwa poziomy i dynamiczne odkrywanie

Cursor (stworzony przez Anysphere) oddziela „kontekst intencji”, czyli to, o co prosi użytkownik, od „kontekstu stanu”, który przedstawia aktualny obraz plików, edycji i błędów. Domyślnie odczytuje jedynie pierwsze 250 wierszy każdego pliku – to świadoma decyzja mająca na celu oszczędność tokenów i pieniędzy.

Znacząca zmiana nastąpiła w styczniu 2026 roku. Cursor stwierdził, że w miarę rozwoju modeli w formie agentów lepsze okazało się dostarczanie mniej informacji na początku i pozwalanie agentowi samodzielnie pozyskiwać istotny kontekst. Wspomniany wcześniej test A/B pokazał 46,9% mniejszą ilość tokenów przy ładowaniu na żądanie.

Manus: spadek gradientowy poprzez próby i błędy

Manus opisuje swój podejście jako „stochastyczne schodzenie gradientem”, przy czym system plików pełni rolę ostatecznego kontekstu. Podobno od marca 2025 roku zrekonstruowano ich framework pięć razy. Podsumowanie Ji: inżynieria kontekstu okazała się czymś zupełnie nieprostym i stanowi naukę eksperymentalną.

Zespołowi przypisuje się sześć zasad:

• Najpierw umieść cache KV.
• Używaj narzędzi maskujących zamiast ich usuwania, aby zachować cache.
• Traktuj system plików jako nieograniczoną pamięć zewnętrzną.
• Recytuj listę zadań, aby skierować uwagę na ogólny plan.
• Zachowuj błędy w kontekście, ponieważ usunięcie awarii eliminuje dowody.
• Zmieniaj szablony serializacji, aby uniknąć pułapki kilku przykładów.

Czego uczy to porównanie

Żadna filozofia nie jest prawidłowa. Claude Code jest dostosowany do długich sesji programowania wymagających stabilności. Cursor skupia się na krótkich, wspomaganych sesjach, które dynamicznie reagują na kontekst edytora. Manus został stworzony dla w pełni autonomicznych agentów internetowych wykonywających 50 lub więcej wywołań narzędzi na zadanie. Pięć przeprojektowań w Manus pokazuje coś podstawowego: inżynieria kontekstu to dyscyplina empiryczna, a nie plan, który zostaje raz przygotowany i wdrożony. Każdy system produkcyjny przechodzi przez własne iteracje.

Latwo założyć, że większe okna pamięci rozwiążą problem, ponieważ milion tokenów powinien wystarczyć. Dane NoLiMa i Chroma szybko obalają to założenie. Claude 4 Sonnet wykazuje znacznie lepszą odporność na degradację kontekstu niż starsze modele, ale to wyjątek potwierdzający regułę, a nie dowód na to, że problem zniknął.

Te systemy i wzorce opisują to, co działa. Pozostaje już tylko przekształcenie ich w konkretne wybory projektowe dla danego agenta oraz sprawdzenie, czy projekt kontekstu spełnia swoją funkcję.

Schemat: co używać i co mierzyć

Artykuł z marca 2026 roku na temat architektury wieloagentowej w przedsiębiorstwach (arXiv:2603.09619, dotyczący przejścia od promptów do inżynierii kontekstu) przedstawia pięć kryteriów jakości kontekstu i przedstawia kontekst jako system operacyjny agenta:

• Relevancja. Czy informacja jest istotna dla obecnego kroku decyzyjnego? Nieistotny kontekst bezpośrednio przyczynia się do błędów.
• Wystarczalność. Czy agent ma wszystko, czego potrzebuje, bez konieczności domyślania się?
• Izolacja. Czy konteksty agentów są odpowiednio oddzielone, tak aby dane tenanta A nigdy nie wyciekły do tenanta B?
• Ekonomia. Czy kontekst stanowi najmniejszą możliwą zbiór tokenów o wysokiej wartości sygnałowej? Każdy niepotrzebny token zużywa budżet uwagi.
• Pochodzenie. Czy można prześledzić, skąd pochodzi każdy element kontekstu? To ma znaczenie przy debugowaniu.

Ścieżka decyzyjna

Dla krótkiego zadania, obejmującego około 20 kroków i bez zależności długoterminowych, wystarczy przesuwanie okna. Zachowaj ostatnie N rund wraz z instrukcjami systemowymi. Nie ma to dodatkowych kosztów, a implementacja jest najprostsza.

Dla długotrwałego zadania, gdzie decyzja podjęta na 5. kroku wpływa na 50. krok, użyj kompresji, która zachowuje decyzje architektoniczne. Ostrzeż przy około 80% pojemności i automatycznie skompresuj przy około 95%.

Dla niezależnych podzadań z ponad 10 narzędziami należy użyć podagentów, które zwracają streszczenia składające się z 1 tys. do 2 tys. tokenów, przy czym każdy z nich pracuje w oddzielnym oknie.

Dla wielu narzędzi, ale krótkich sesji należy ładować narzędzia w momencie potrzeby, zamiast wcześniej je wszystkie załadowywać. Stopniowe ujawnianie informacji eliminuje problem związany z obciążeniem MCP.

Co należy monitorować

Bez tych metryk architektura kontekstowa nie ma możliwości obserwacji:

• Tempo wzrostu liczby tokenów. Stabilny, monotoniczny wzrost oznacza brak strategii kompresji. Wzorzec falisty – wzrost, reset i ponowny wzrost – wskazuje na skuteczną kompresję.
• Wskaźnik trafień w pamięci cache KV. Wartość poniżej 50% sugeruje, że coś w prefiksie instrukcji systemowych ciągle się zmienia. Najpierw sprawdź daty i inne elementy dynamiczne.
• Heurystyka 35 minut. Agenci wydają się tracić efektywność po około 35 minutach wykonywania zadania, dlatego planując punkty kontrolne należy to wziąć pod uwagę.
• Amnezja po kompresji. Jeśli agent ponownie bada obszar, który już przebył, oznacza to, że kompresja była prawdopodobnie zbyt agresywna.

W przypadku projektowania takich systemów wyróżnia się jeden brak: nie istnieje standardowa miara informacji utraconych podczas kompresji. Błąd pojawia się później, a nie w momencie kompresji. Optymalny moment na kompresję pozostaje otwartym problemem – zbyt wczesne działanie marnuje dostępny czas, a zbyt późne powoduje problemy.

SWE-ContextBench (arXiv:2602.08316) potwierdza to, pokazując, że nieprzefiltrowane lub źle dobrane dane dostarczają ograniczonych, a nawet negatywnych korzyści. Więcej kontekstu nie zawsze jest lepsze, a zły kontekst może nawet szkodzić.

Zasady projektowania kontekstu dla agentów działających przez długi czas

Projektowanie pipeline'u kontekstowego to zupełnie inna kwestia niż pytanie o to, czym jest inżynieria kontekstu, i wynikają z tego kilka wniosków.

• Zepsucie kontekstu to właściwość fizyczna modeli typu transformer. Lepszy model tego nie naprawia; zarządza tym architektura pamięci.
• Model to procesor, kontekst to pamięć RAM, a inżynieria kontekstu to system operacyjny agenta, co przenosi dyskusję z lingwistyki na inżynierię systemów.
• Pisanie, selekcja, kompresja i izolacja to uzupełniające się elementy, a nie alternatywy, przy czym każdy agent produkcyjny wykorzystuje wszystkie cztery.
• Współczynnik trafień w pamięci cache KV to wskaźnik, na który należy zwracać uwagę, a jeden błąd w czasie oznaczenia w promptzie systemowym może zwiększyć miesięczny rachunek o dziesiątki tysięcy dolarów.
• Nie istnieje jedna prawidłowa filozofia, co pokazują Claude Code, Cursor i Manus.
• Dobra inżynieria kontekstu oznacza pięć kryteriów jakości wraz z mierzalnymi wskaźnikami, a nie intuicję.

Pierwszym praktycznym krokiem jest przyznanie kontekstowi pierwszeństwa podczas następnej oceny projektu agenta: gdzie przechowywany jest stan, jak obsługiwany jest cache KV, jaki jest próg kompresji oraz które podzadania trafiają do podagentów. Nie chodzi tu o drobne dostosowania wydajności – to fundament systemu, który faktycznie funkcjonuje.