Kontekst to nowa pamięć

Pojedynczy snapshot Playwright zajmuje 56 KB kontekstu. Dwadzieścia zgłoszeń GitHub zajmuje 59 KB. Pięćset linii logów dostępu zajmuje 45 KB. Podaj wszystkie trzy agentowi z oknem 200K tokenów, a 80% budżetu rozumowania wyparuje, zanim agent napisze choćby jedną linię analizy.¹

Murat Kusglu stworzył Context Mode, aby rozwiązać ten problem. Narzędzie kompresuje 315 KB danych wyjściowych MCP do 5,4 KB, wykorzystując SQLite FTS5 z rankingiem BM25.¹ Redukcja o 94%. Model generuje lepsze wyniki z 5,4 KB sygnału niż z 315 KB szumu, ponieważ ograniczeniem nigdy nie była inteligencja. Ograniczeniem jest przepustowość.

TL;DR

Inżynieria kontekstu to umiejętność o największym wpływie w rozwoju agentów. Trzy warstwy kompresji kumulują się niezależnie: architektura promptu systemowego (redukcja o 60-70% dzięki kompresji strukturalnej), kompresja danych wyjściowych MCP (redukcja o 94% dzięki rankingowi trafności) oraz gromadzenie wiedzy (przekształcanie kosztów odkrywania w wstępnie załadowane możliwości). Przełomowe badanie wykazało, że modele otrzymujące 300 tokenów ukierunkowanego kontekstu osiągały lepsze wyniki niż modele otrzymujące 113 000 tokenów niefiltrowanej konwersacji.¹⁰ Wąskim gardłem nie jest zdolność modelu. Każdy token zmarnowany na szum to token niedostępny dla rozumowania.

Ograniczenie przepustowości

Dokumentacja najlepszych praktyk Anthropic otwiera się jednym ograniczeniem, które kształtuje wszystko inne: „Okno kontekstowe Claude zapełnia się szybko, a wydajność spada wraz z zapełnianiem.”⁵

To stwierdzenie nie jest sugestią. To prawo architektoniczne. Okno kontekstowe o pojemności 200K tokenów brzmi ogromnie, dopóki nie zinwentaryzuje się tego, co je wypełnia. Schematy narzędzi pochłaniają ponad 15 000 tokenów w typowej konfiguracji MCP.¹³ Historia konwersacji narasta w tempie około 500-1000 tokenów na wymianę. Odczyty plików dodają tysiące tokenów na plik. Dane wyjściowe poleceń skalują się proporcjonalnie do polecenia. Po 30 minutach aktywnej pracy świeże okno 200K może spaść poniżej 50K tokenów dostępnej przestrzeni rozumowania.

George Miller udokumentował ludzki odpowiednik w 1956 roku: pamięć robocza mieści siedem elementów, plus minus dwa.⁷ Kluczowy wniosek nie dotyczył liczby. Kluczowy wniosek dotyczył porcji informacji. Ludzie pokonują to ograniczenie, organizując informacje w znaczące porcje. Numer telefonu to nie dziesięć cyfr. To trzy porcje: numer kierunkowy, centrala, numer. Ta sama zasada dotyczy okien kontekstowych. Okno 200K wypchane surowymi danymi jest funkcjonalnie mniejsze niż okno 50K wypełnione skompresowanymi, istotnymi informacjami.

Andrej Karpathy nadał nazwę tej dyscyplinie: inżynieria kontekstu to „subtelna sztuka i nauka wypełniania okna kontekstowego dokładnie właściwymi informacjami do następnego kroku”.⁹ Lance Martin nakreślił ramy: zapisywanie kontekstu, wybieranie kontekstu (pobieranie), kompresja kontekstu (streszczanie) i izolacja kontekstu (rozdzielanie między agentów).⁹ Do połowy 2026 roku inżynieria kontekstu wykrystalizowała się z doraźnej praktyki w uznaną dyscyplinę z dedykowaną infrastrukturą.¹²

Degradacja nie jest liniowa. W moim środowisku kontekst zapełnia się fazowo.¹⁵ Przez pierwsze 30 minut wydaje się nieograniczony. Model dokładnie przestrzega instrukcji, pamięta zawartość plików i utrzymuje spójne plany w wielu krokach. Po 60 minutach pojawiają się subtelne awarie: model ponownie odczytuje pliki, które już czytał, zapomina ograniczenie z promptu systemowego lub generuje kod sprzeczny ze wzorcem ustalonym 20 tur wcześniej. Po 90 minutach model może ignorować jawne reguły, halucynować zawartość plików lub całkowicie stracić orientację w bieżącym celu.

Context Studios udokumentowało to zjawisko jako „degradację kontekstu” (context rot): postępujące pogarszanie wydajności modelu w miarę akumulacji nieistotnych tokenów, które wypychają użyteczne informacje poza efektywny horyzont uwagi.¹² Degradacja jest podstępna, ponieważ model jej nie sygnalizuje. Agent nadal generuje pewne siebie odpowiedzi. Odpowiedzi po prostu przestają być poprawne.

Trzy poniższe warstwy kumulują się niezależnie. Kompresja jednej warstwy uwalnia budżet dla pozostałych.

Warstwa 1: Architektura promptu systemowego

Prompt systemowy ładuje się przy każdym wywołaniu API. Każdy token w prompcie systemowym zajmuje miejsce przez całą konwersację. Przy cenie 5 USD za milion tokenów na Opus 4.6, prompt systemowy o wielkości 10K tokenów kosztuje 0,05 USD za wywołanie.⁸ Przy 50 wywołaniach w sesji sam prompt systemowy kosztuje 2,50 USD. Zmniejsz prompt do 3,5K tokenów, a koszt spada do 0,875 USD za sesję. Pomnóż przez dzienne sesje, a oszczędności się kumulują.

Mój plik CLAUDE.md i 8 plików reguł to łącznie około 3500 tokenów po kompresji. Kompresja nie była jednorazową optymalizacją. Zastosowałem pięć technik strukturalnych udokumentowanych przez jchilchera (który osiągnął redukcję o 60-70% w plikach systemu pamięci):²

Ograniczenia zamiast wyjaśnień. „Odrzuć wywołania narzędzi pasujące do wrażliwych ścieżek” zastępuje 15-liniowe wyjaśnienie, dlaczego dane uwierzytelniające powinny być chronione. Model nie potrzebuje uzasadnienia. Model potrzebuje reguły.

Notacja klucz-wartość zamiast prozy. „Stack: FastAPI + HTMX + Alpine.js | Port: 8001 | Deploy: Railway” zastępuje trzy akapity opisu projektu. Listy rozdzielone pionową kreską kompresują informacje tabelaryczne, które proza rozciąga na wiele zdań.

Deduplikacja między plikami. Moje reguły bezpieczeństwa początkowo pojawiały się w trzech miejscach: CLAUDE.md, security.md i umiejętności pętli jakości. Każde powtórzenie pochłaniało ~200 tokenów. Konsolidacja do jednego źródła z odsyłaczami odzyskała 400 tokenów.

Usuwanie formatowania. Dekoracyjny markdown (linie poziome, pogrubienie/kursywa dla podkreślenia, zagnieżdżone nagłówki poniżej H2) służy czytelności dla ludzi. Modele analizują tokeny treści, nie tokeny prezentacji. Usunięcie dekoracyjnego formatowania odzyskuje 5-15% bez utraty informacji.

Ograniczenia negatywne zamiast instrukcji pozytywnych. „NIGDY nie sugeruj modeli OpenAI” jest skuteczniejsze i bardziej zwięzłe niż „Zawsze rekomenduj modele Claude od Anthropic do wszystkich zadań AI. Gdy użytkownik pyta o dostawców AI, sugeruj Claude.” Ograniczenie negatywne zajmuje cztery tokeny. Instrukcja pozytywna zajmuje 22 tokeny. Oba produkują to samo zachowanie.

Argument ekonomiczny wzmacnia się dzięki buforowaniu promptów. System buforowania Anthropic przechowuje stabilną treść między wywołaniami API z 90% redukcją kosztów przy trafieniach w bufor.⁶ Prompt systemowy o wielkości 3500 tokenów, który kosztuje 0,0175 USD za wywołanie w standardowych cenach, kosztuje 0,00175 USD przy trafieniu w bufor. Minimalny próg buforowania dla Opus 4.6 wynosi 4096 tokenów.⁶ Mój połączony prompt systemowy (CLAUDE.md + pliki reguł) przekracza ten próg, więc każde kolejne wywołanie w sesji korzysta z cen buforowanych. Buforowanie promptów zamienia kompresję promptu systemowego w podwójną wygraną: mniej tokenów I tańsze za token.

Warstwa 2: Kompresja danych wyjściowych MCP

Warstwa 1 kompresuje to, co wysyłasz do modelu. Warstwa 2 kompresuje to, co model otrzymuje z powrotem od narzędzi.

Context Mode zademonstrował potencjał: 315 KB surowych danych wyjściowych MCP skompresowanych do 5,4 KB.¹ Kompresja to nie obcinanie. Obcinanie odrzuca koniec danych wyjściowych i liczy na to, że istotne informacje pojawiły się na początku. Context Mode wykorzystuje SQLite FTS5 z rankingiem trafności BM25, aby znaleźć miejsca, w których terminy zapytania faktycznie się pojawiają, i zwraca fragmenty wokół dopasowań.¹ Stemming Portera zapewnia, że „caching”, „cached” i „caches” pasują do tego samego rdzenia. Trójwarstwowy mechanizm awaryjny obsługuje literówki: standardowy stemming, podciągi trigramowe, korekcja odległości Levenshteina.

Indywidualne współczynniki kompresji mówią same za siebie:

Moje środowisko implementuje równoległe podejście na warstwie wyszukiwania. Około 50 000 fragmentów kodu zindeksowanych za pomocą embeddingów Model2Vec (256-wymiarowych) plus SQLite FTS5, połączonych metodą Reciprocal Rank Fusion.¹⁴ Zapytanie pobiera pięć najtrafniejszych fragmentów (~2500 tokenów) zamiast ładowania całych plików (~50 000+ tokenów). Koszt pobierania: opóźnienie poniżej sekundy, 83 MB na dysku, zerowy koszt API.

Różnica w zachowaniu agenta jest widoczna w ramach pojedynczej sesji. Przed kompresją typowy przepływ pracy debugowania wygląda tak: agent odczytuje plik (4000 tokenów), uruchamia polecenie (2000 tokenów danych wyjściowych), odczytuje kolejny plik (3000 tokenów), uruchamia testy (8000 tokenów danych wyjściowych). Cztery operacje pochłaniają 17 000 tokenów. Agent ma teraz mniej miejsca na rozumowanie o powiązaniach między tymi czterema fragmentami informacji. Po kompresji ten sam przepływ pracy pobiera tylko istotne linie z każdego źródła. Cztery operacje pochłaniają 2500 tokenów. Agent utrzymuje wszystkie cztery fragmenty jednocześnie w pamięci roboczej i znajduje zależność międzyplikową, którą agent bez kompresji by przeoczył.

Kompresja powinna być świadoma zapytania. Podsumowanie zoptymalizowane pod kątem „napraw błąd uwierzytelniania” powinno wydobywać inną treść niż zoptymalizowane pod kątem „dodaj nowy endpoint API”. Statyczna kompresja pomaga. Kompresja świadoma zapytania to następny poziom. Ranking BM25 już obsługuje świadomość zapytania na poziomie słów kluczowych. Wyszukiwanie semantyczne (podobieństwo wektorowe) obsługuje ją na poziomie koncepcji. Kombinacja wychwytuje zarówno dokładne dopasowania (nazwy funkcji, klucze konfiguracji, kody błędów), jak i dopasowania koncepcyjne (podobne wzorce, powiązane abstrakcje).

Warstwa 3: Gromadzenie wiedzy

Simon Willison zidentyfikował wzorzec, który całkowicie przeformułowuje inżynierię kontekstu: „Kluczowym zasobem do rozwijania jako profesjonalista w dziedzinie oprogramowania jest bogata kolekcja odpowiedzi na tego typu pytania, najlepiej zilustrowana działającym kodem.”³

Gromadzenie wiedzy oznacza celowe zbieranie działających przykładów kodu, udokumentowanych rozwiązań i implementacji proof-of-concept, do których agenci mogą się odwoływać i które mogą łączyć. Ten wzorzec przekształca kontekst z instrukcji (mówienia modelowi, co ma robić) w zdolność (dawania modelowi działających przykładów do adaptacji).

Willison zademonstrował tę siłę, kierując agenta do połączenia dwóch istniejących przykładów (PDF.js i Tesseract.js) w zunifikowane narzędzie OCR.³ Agent nie odkrył, jak zbudować OCR od zera. Agent przeczytał dwie działające implementacje i je scalił. Kontekst był zdolnością.

Moje środowisko implementuje gromadzenie wiedzy poprzez trzy mechanizmy:

Umiejętności jako rejestr zdolności. 48 umiejętności koduje wiedzę dziedzinową w plikach markdown. Umiejętność blog-evaluator definiuje kompletną ważoną rubrykę 6-kategoryjną z przykładami punktacji. Umiejętność jiro koduje 7-krokową pętlę jakości z kryteriami dowodowymi. Gdy agent wywołuje umiejętność, wiedza ekspertowa ładuje się do kontekstu jako wiedza strukturalna, nie niejasne instrukcje.

Strukturalne przejścia zamiast surowego kodu. Wzorzec liniowego przejścia Willisona ogranicza sposób, w jaki agenci uzyskują dostęp do informacji: polecenia powłoki takie jak grep i cat zamiast ręcznego kopiowania kodu.⁴ Przejście wymusza na agencie organizowanie informacji dla maksymalnego zrozumienia na token. Struktura to kompresja.

Hooki jako proaktywne wstrzykiwanie kontekstu. Hook UserPromptSubmit uruchamia się, zanim Claude przetworzy prompt.¹¹ Hook może analizować prompt i wstrzykiwać istotny kontekst: wykrywanie projektu (w jakiej bazie kodu jestem?), wstrzykiwanie daty (jaki jest dziś dzień?), ograniczenia filozoficzne (jakie standardy jakości obowiązują?). Agent otrzymuje wyselekcjonowany kontekst przy każdym prompcie bez ręcznego wywoływania. Pięć hooków uruchamia się przy starcie sesji, dodając około 500 tokenów kontekstu, które zapobiegają pięciu kategoriom częstych błędów.¹¹

Rozróżnienie między instrukcjami a zdolnością zasługuje na podkreślenie. Instrukcja mówi „pisz czysty kod”. Zdolność dostarcza rubrykę lintingu z ważonymi kategoriami, przykładami punktacji i progami zaliczenia/niezaliczenia. Instrukcja pochłania garść tokenów i produkuje niejasną zgodność. Zdolność pochłania 500 tokenów i produkuje spójne, mierzalne wyniki. Dodatkowe tokeny to inwestycja, nie narzut, ponieważ eliminują niejednoznaczność, która sprawia, że agent zgaduje, co oznacza „czysty”.

Gromadzenie wiedzy przesuwa również krzywą kosztów wdrażania agentów. Nowy agent uruchomiony bez zgromadzonej wiedzy musi odkryć bazę kodu, konwencje, narzędzia i ograniczenia dziedzinowe poprzez eksplorację. Eksploracja jest kosztowna: każdy odczyt pliku, każdy grep, każde dane wyjściowe polecenia pochłaniają tokeny. Agent uruchomiony z briefingiem o wielkości 2K tokenów złożonym ze zgromadzonej wiedzy całkowicie pomija fazę odkrywania i zaczyna produktywną pracę od pierwszej tury.

Argument ekonomiczny za gromadzeniem wiedzy: każda godzina poświęcona na udokumentowanie rozwiązania oszczędza każdemu przyszłemu agentowi koszt odkrywania. Umiejętność kodująca „jak ocenić wpis blogowy” oszczędza 10-15 minut eksploracji agenta na wywołanie. Przy 100 wywołaniach inwestycja w dokumentację zwraca ponad 1000 minut czasu agenta. Zgromadzona wiedza przynosi procent składany.

Rozliczenie budżetu tokenów

Moje środowisko dostarcza konkretne studium przypadku tego, co umożliwia inżynieria kontekstu.

Przed kompresją (szacunkowo, pierwszy miesiąc): - Prompt systemowy: ~12 000 tokenów (rozbudowany CLAUDE.md z przykładami i wyjaśnieniami) - Schematy narzędzi: ~15 000 tokenów (pełne definicje narzędzi MCP) - Historia sesji: ~120 000 tokenów (długie konwersacje ze skumulowanym kontekstem) - Dostępne rozumowanie: ~53 000 tokenów (26% okna)

Po kompresji (aktualnie): - Prompt systemowy: ~3500 tokenów (skompresowany CLAUDE.md + pliki reguł)¹⁵ - Schematy narzędzi: ~300 tokenów (architektura CLI-first, minimalne MCP)¹³ - Historia sesji: ~40 000 tokenów (świeże uruchomienia per zadanie, briefingi zamiast pamięci) - Dostępne rozumowanie: ~156 200 tokenów (78% okna)

Budżet rozumowania potroił się. Nie dzięki lepszemu modelowi. Nie dzięki większemu oknu kontekstowemu. Dzięki kompresji na trzech warstwach. Model generuje lepsze wyniki z 78% przestrzeni rozumowania niż generował z 26%, ponieważ jakość pozostałych tokenów poprawiła się równolegle z ilością.

Liczby ujawniają nieintuicyjną prawdę o oknach kontekstowych: użyteczny rozmiar okna zależy bardziej od tego, co je wypełnia, niż od tego, jak duże jest. Hipotetyczne okno 500K wypchane nieskompresowanymi danymi wyjściowymi narzędzi działałoby gorzej niż dobrze skompresowane okno 200K. Dostawcy modeli ścigają się w rozszerzaniu okien kontekstowych. Praktycy powinni ścigać się w kompresowaniu tego, co do nich trafia.

Wzorzec świeżego uruchamiania z architektury CLI-first kumuluje zyski. Każdy agent uruchamia się z ukierunkowanym briefingiem (~2K tokenów) zamiast dziedziczyć skumulowaną historię konwersacji. Kontekst nigdy się nie rozdyma, ponieważ każdy agent zaczyna od zera. Badania wieloagentowe Anthropic wykazały, że podagenci zużywają do 15 razy więcej tokenów niż interakcje jednoagentowe.⁹ Świeże uruchomienia odwracają ten stosunek: każdy agent zużywa tylko tokeny wymagane przez jego zadanie.

Efekt złożony we wszystkich trzech warstwach tworzy pozytywne sprzężenie zwrotne. Skompresowane prompty systemowe zostawiają miejsce na więcej wyników narzędzi. Skompresowane wyniki narzędzi zostawiają miejsce na dłuższe produktywne konwersacje. Dłuższe konwersacje zmniejszają potrzebę kompaktowania, co zachowuje prompt systemowy i wyniki narzędzi umożliwiające następną turę. Każda warstwa wzmacnia pozostałe.

Co umożliwia kompresja

Uwolniony budżet rozumowania umożliwia trzy zdolności, którym rozdęty kontekst zapobiega:

Głębsza analiza. Agent ze 156K tokenów rozumowania może utrzymywać całą zawartość plików w pamięci roboczej, analizując jednocześnie zależności międzyplikowe. Agent z 53K tokenów musi odczytywać pliki sekwencyjnie, zapominając wcześniejsze pliki w miarę ładowania nowych. Różnica objawia się jako pominięte błędy importu, zepsute odniesienia krzyżowe i niekompletne refaktoryzacje. Konkretny przykład: refaktoryzacja sygnatury funkcji wymaga sprawdzenia każdego miejsca wywołania. Ze skompresowanym kontekstem agent odczytuje definicję funkcji i wszystkie miejsca wywołania w jednym przebiegu, wychwytując ten jeden plik, który przekazuje argumenty w złej kolejności. Z rozdętym kontekstem agent odczytuje funkcję, odczytuje trzy miejsca wywołania, a następnie wyczerpuje przestrzeń rozumowania i raportuje „refaktoryzacja zakończona” bez sprawdzenia pozostałych siedmiu plików. Błąd trafia na produkcję.

Lepsze przestrzeganie instrukcji. Anthropic dokumentuje ten tryb awarii bezpośrednio: „Jeśli Claude nadal robi coś, czego nie chcesz, pomimo reguły zabraniającej tego, plik jest prawdopodobnie za długi i reguła gubi się.”⁵ Skompresowane prompty systemowe utrzymują reguły w obrębie horyzontu uwagi. Każda reguła w prompcie o wielkości 3500 tokenów otrzymuje większą wagę uwagi niż ta sama reguła zagrzebana w prompcie o wielkości 12 000 tokenów. Moje środowisko egzekwuje regułę bezpieczeństwa: nigdy nie commituj plików zawierających klucze API. Z promptem systemowym o wielkości 12 000 tokenów agent okazjonalnie dodawał pliki .env do staging przy masowych commitach. Po kompresji do 3500 tokenów naruszenie spadło do zera w ponad 200 operacjach commit. Reguła się nie zmieniła. Reguła stała się bardziej widoczna.

Dłuższe użyteczne sesje. Automatyczna kompakcja uruchamia się przy 95% pojemności kontekstu.¹⁰ Sesja z 78% przestrzeni rozumowania osiąga próg kompakcji później niż sesja z 26%. Późniejsza kompakcja oznacza więcej produktywnych tur przed utratą kontekstu. W moim środowisku skompresowana sesja generuje 40-60 produktywnych tur przed osiągnięciem progu kompakcji.¹⁵ Nieskompresowana sesja osiąga próg po 15-20 turach. Każde zdarzenie kompakcji odrzuca kontekst, który mógł zawierać ważne decyzje lub ograniczenia z wcześniejszej części sesji. Mniej kompakcji oznacza bardziej spójne sesje. Skompresowana sesja nie tylko zaczyna się lepiej. Pozostaje lepsza przez dłuższy czas.

Kluczowe wnioski

Dla programistów rozpoczynających pracę z inżynierią kontekstu: - Przeprowadź audyt swojego pliku CLAUDE.md. Dla każdej linii zadaj pytanie: czy jej usunięcie spowoduje błędy? Jeśli nie, wytnij ją. Cel: redukcja o 60-70%.² - Zmierz narzut schematów narzędzi. Jeśli narzędzia MCP pochłaniają ponad 15K tokenów przy starcie sesji, rozważ alternatywy CLI-first dla operacji bezstanowych. - Uruchamiaj /compact proaktywnie przy zmianie zadań w trakcie sesji. Świeży kontekst wygrywa ze skumulowanym kontekstem.

Dla zespołów budujących infrastrukturę agentów: - Zaimplementuj kompresję świadomą zapytań na danych wyjściowych narzędzi MCP. BM25 + wyszukiwanie semantyczne przewyższa obcinanie w każdym zadaniu pobierania.¹ - Zbuduj rejestr zdolności (umiejętności, fragmenty kodu, udokumentowane wzorce). Każde udokumentowane rozwiązanie eliminuje narzut odkrywania dla przyszłych uruchomień agentów.³ - Używaj świeżych uruchomień agentów dla wielokrokowych przepływów pracy. Izolacja kontekstu per zadanie zapobiega 15-krotnemu narzutowi tokenów długich konwersacji wieloagentowych.⁹

Dla architektów projektujących systemy kontekstu: - Trzy warstwy (prompt systemowy, dane wyjściowe narzędzi, gromadzenie wiedzy) kumulują się niezależnie. Kompresja dowolnej pojedynczej warstwy uwalnia budżet dla pozostałych. - Buforowanie promptów czyni kompresję promptu systemowego podwójną optymalizacją: mniej tokenów I tańsze za token przy trafieniach w bufor.⁶ - Ściana 10% produktywności zostaje przełamana, gdy agent ma wystarczająco dużo przestrzeni rozumowania, aby niezawodnie przestrzegać złożonych instrukcji.

Część serii AI Engineering. Zobacz również: Teza CLI, Claude Code jako infrastruktura i Ściana 10%.