Context engineering: dlaczego Twój agent głupieje przy 40. turze

Anthropic postawił granicę we wrześniu 2025 roku i te dwa zdania powinny stać obok siebie. Prompt engineering to „metody pisania i organizowania instrukcji LLM dla optymalnych wyników”. Context engineering to „zestaw strategii kuratorowania i utrzymywania optymalnego zestawu token (informacji) podczas wnioskowania LLM, w tym wszystkich innych informacji, które mogą tam trafić poza prompts”.¹

Operacyjna różnica brzmi: kiedy i przez kogo. prompt jest tworzony raz, przez człowieka, i recenzowany. context jest składany przy każdym wywołaniu, przez kod, którego nikt nie ogląda, z materiału, którego nikt nie napisał ręcznie: czterdzieści tur historii, sześć wyników narzędzi, cztery pobrane fragmenty, profil użytkownika, dwanaście schematów JSON. Rozdział 15 zmierzył, co dają lepsze instrukcje. Ten rozdział jest o pozostałych dziewięćdziesięciu procentach token, które pojawiają się same.

Ten sam dokument nazywa zasób, który wszystkie one zużywają: modele „mają «budżet attention», z którego korzystają podczas parsowania dużych wolumenów context. Każdy nowy token wprowadzony do context uszczupla ten budżet o pewną ilość”. I nazywa objaw: „wraz ze wzrostem liczby token w context window zdolność modelu do dokładnego przypominania sobie informacji z tego context maleje” — context rot.¹

To ostatnie zdanie jest twierdzeniem o zachowaniu, czyli można je sprawdzić, a tabela na górze tej strony jest tym sprawdzeniem.

Czterdzieści linii do lokalnego endpointu z rozdziału 22 — mały serwer Python trzymający Qwen2.5-0.5B-Instruct na CPU i mówiący formatem chat-completions, więc pętla zostaje w TypeScript, a tensory po drugiej stronie portu.

const DEPTHS = [0, 0.125, 0.25, 0.375, 0.5, 0.625, 0.75, 0.875, 1];

for (const d of DEPTHS) {
  const slot = Math.round(d * (N - 1));
  let hits = 0, other = 0;
  for (let t = 0; t < TRIALS; t++) {
    const recs = buildRecords(N, 1000 + t);          // 25 unique tickets
    const gold = recs[Math.floor(rng(7 + t)() * N)]; // a different one each trial
    const rest = recs.filter((x) => x.ticket !== gold.ticket).slice(0, N - 1);
    const lines = [...rest.slice(0, slot).map((x) => x.line),   
                   gold.line,                                   
                   ...rest.slice(slot).map((x) => x.line)];     
    const r = await complete(prompt(lines, ask(gold.owner)), { maxTokens: 12 });
    const said = /\d{4}/.exec(r.text)?.[0];
    if (said === String(gold.ext)) hits++;
    else if (said && recs.some((x) => String(x.ext) === said)) other++;
  }
}

Licznik other zamienia rozczarowujący wynik w użyteczny: kiedy model się myli, czy jest zagubiony, czy pewny?

Odpowiedź brzmi: pewny. Na ośmiu pozycjach innych niż pierwsza 136 z 205 błędnych odpowiedzi było numerem wewnętrznym innego zgłoszenia — prawdziwą czterocyfrową liczbą, poprawnie sformatowaną, odczytaną z niewłaściwej linii. Na miejscu 1 tylko jedno z pięciu chybień takie było; na miejscu 7 — dwadzieścia jeden z dwudziestu sześciu.

To rozróżnienie liczy się w produkcji. Model, który mówi nie mogę tego znaleźć, to błąd, który zauważysz; model, który zwraca numer z sąsiedniego wiersza, to błąd, który wypuścisz, bo na ekranie oba wyglądają identycznie. To porażka, przed którą rozdział 19 zbudował weryfikowalne cytowania, tyle że przychodząca z wnętrza prompt zamiast z indeksu.

Pozycja to jedna oś. Długość to druga i łatwiej ją przetestować: trzymaj odpowiedź w środku i powiększaj listę.

Jeden rekord i 97 token: 90%. Trzy rekordy i 159 token: 55%. Osiem rekordów i 315 token: 15%, a dalej płasko i nisko aż do 140 rekordów i 4 477 token. Całe załamanie dzieje się między pierwszą a ósmą linią listy.

Ostatnia kolumna to wszystko, co nie jest ani właściwym numerem wewnętrznym, ani numerem z innego rekordu; przy jednym rekordzie na stronie to jedyne miejsce, gdzie może wylądować błędna odpowiedź. Dwa chybienia przy jednym rekordzie warto zgłosić zamiast zaokrąglić do zera, bo żadne nie było odmową: jedno odpowiedziało 5806 na rejestr, którego jedyna linia mówi 5805. Przy 97 token i jednym kandydacie ten model wciąż myli cyfrę dwa razy na dwadzieścia, i to jest podłoga, względem której mierzy się całą resztę.

Wynikają z tego dwie rzeczy. Większy context kupuje prawo do wysłania więcej, nie pewność, że zostanie przeczytane: ten model ma context window 32 768 token i zakres roboczy, w tym zadaniu, rzędu kilkuset token. I nie ma progu, urwiska ani stanu „context pełny” — degradacja trwa już przy trzecim rekordzie i kończy się przy ósmym, na poziomie jednego procenta okna. Czymkolwiek jest limit context, nie on tym rządzi.

Zwykle podaje się dwa mechanizmy. Pierwszy to arytmetyka z rozdziału 9, którą Anthropic opisuje tymi samymi słowami co ten kurs: modele „opierają się na architekturze transformer, która pozwala każdemu token zwracać attention na każdy inny token w całym context. Daje to n² relacji parami dla n token”.¹ Attention nad dłuższą sekwencją nie jest tą samą operacją zastosowaną do większej ilości materiału; to jeden stały budżet masy prawdopodobieństwa rozsmarowany na więcej konkurentów. Drugi mechanizm to trening: modele widzą znacznie więcej krótkich sekwencji niż długich, więc wzorce pozycyjne dalekiego zasięgu są najmniej ćwiczoną częścią sieci. To argument, nie pomiar, i ten rozdział go nie rozstrzygnie.

Rozstrzygnięty jest natomiast kształt — i to od 2023 roku. Liu i in. testowali odpowiadanie na pytania z wielu dokumentów oraz retrieval klucz-wartość w różnych rodzinach i rozmiarach modeli i stwierdzili, że „wydajność jest często najwyższa, gdy istotne informacje występują na początku lub końcu input context, i znacząco spada, gdy modele muszą uzyskać dostęp do istotnych informacji w środku długich context, nawet w modelach jawnie long-context”.² Rozdział 15 wziął z tego artykułu swoją regułę pozycji; rozdział 19 wziął z niego powód, dla którego dwadzieścia pobranych chunks może wypaść gorzej niż cztery. Praktyczna forma tego faktu jest jedynym zdaniem tutaj, według którego powinieneś działać: zmierzenie tego na własnym modelu i własnych danych zajmuje pięć minut, a żadna opublikowana krzywa nie zastąpi Twojej.

Zapytaj zespół, co wypełnia context ich agent, a dostaniesz szacunek, bo żadne API nie zwraca odpowiedzi: odpowiedź daje Ci prompt_tokens, jedną liczbę dla całości.

Podział możesz odzyskać czterema zliczeniami i trzema odejmowaniami — cały wyrenderowany prompt, ten sam bez definicji narzędzi, sama wiadomość systemowa z nimi i bez nich, oraz wszystko z usuniętymi wynikami narzędzi:

async function buckets(messages: Msg[]) {
  const sys = messages.slice(0, 1);
  const withoutResults = messages.filter((m) => m.role !== "tool");
  const [total, sysWithTools, sysNoTools, noResults] = await Promise.all([
    countPrompt(messages, CATALOGUE),        // everything
    countPrompt(sys, CATALOGUE),             // system + scaffolding + schemas
    countPrompt(sys),                        // system + scaffolding
    countPrompt(withoutResults, CATALOGUE),  // everything but tool output
  ]);
  return {
    system: sysNoTools,
    tools: sysWithTools - sysNoTools,                                  
    toolResults: total - noResults,                                    
    conversation: total - sysWithTools - (total - noResults),          
    total,
  };
}

countPrompt stosuje własny szablon czatu modelu przed tokenizacją, co ma większe znaczenie, niż brzmi: Twój tekst nie jest tym, co zostaje policzone. Znaczniki ról, preambuła tool calling i renderowanie schematów to wszystko token, za które płacisz, a których nigdy nie wpisałeś. Rozdział 7 zbudował tokenizer, a rozdział 16 liczył z js-tiktoken; tutaj liczba pochodzi z tego samego modelu, który przeczyta prompt, więc jest to jedyne zliczenie, które jest dokładnie poprawne.

Teraz przepuść przez to prawdziwego agent: czterdzieści tur badania incydentu, dwanaście narzędzi, fałszywe środowisko operacyjne zwracające realistyczne zrzuty logów i serie metryk.

Przeczytaj pierwszy wiersz w zestawieniu z ostatnim.

W turze 1 prompt ma 2 547 token, a 71% z niego stanowią definicje narzędzi. system prompt to 3%. To, co wpisał użytkownik, to 6%. agent jeszcze nic nie zrobił, a już niesie 1 817 token schematu JSON.

Do tury 40 prompt ma 10 632 token i proporcje się odwróciły: definicje 17%, rozmowa 29%, wyniki narzędzi 53%. Output narzędzi wyprzedził definicje w turze 5; rozmowa wyprzedziła je dopiero w turze 25, więc przez pierwsze sześćdziesiąt procent sesji katalog narzędzi był większy niż wszystko, co zostało powiedziane.

Potem suma. W 57 wywołaniach modelu przebieg rozliczył 370 291 input token dla końcowego context 10 632 — ostatni prompt opłacony około trzydzieści pięć razy, czyli kwadrat z rozdziału 16 z mnożnikiem agent na wierzchu. Z tych 370 291 103 569, czyli 28% wszystkiego, co rozliczono, stanowiło dwanaście definicji narzędzi, wysyłanych ponownie bajt w bajt przy każdym wywołaniu.

Katalog narzędzi to największy stały koszt w agent i jest niewidoczny, bo nigdy go nie widzisz: przekazujesz tablicę obiektów, a dostawca renderuje ją do prompt za Ciebie. Zmierzone na tych samych dwunastu narzędziach:

system prompt + chat scaffolding, no tools:        85 tokens
all twelve definitions:                          1,817 tokens
  of which fixed tool-calling scaffolding:         126 tokens
three tools instead of twelve:                     605 tokens
same twelve, one-sentence descriptions,
  no parameter prose:                            1,291 tokens  (-29 %)

Krańcowy koszt na narzędzie wynosi od 80 token dla get_current_time, które bierze jeden string, do 263 dla search_tickets, które bierze cztery parametry z enum i po zdaniu wskazówek przy każdym. To kurs wymiany stojący za centralną radą z rozdziału 18, że opis jest API: dobry opis kosztuje około stu token przy każdym żądaniu przez resztę życia agent. Trzy konsekwencje.

Narzędzie, którego nie używasz, nadal się rozlicza. agent wywołał siedem z dwunastu. Pozostałe pięć kosztowało 697 token przy każdym z 57 żądań — 39 729 łącznie, więcej niż jedna dziesiąta wszystkiego, za co rozliczono przebieg, za możliwości, których nigdy nie dotknął. Jedno z tej piątki niesie najostrzejszy szczegół w śladzie: model trzy razy próbował wywołać read_log, które nie istnieje. Narzędziem, którego chciał, było search_logs, druga najdroższa definicja w katalogu, 237 token. Zapłacił za tę definicję 57 razy, nigdy jej nie użył i nigdy nie znalazł jej nazwy.

Przycinanie prozy to najtańsza dostępna optymalizacja, i jest to kompromis. Skrócenie opisów do jednego zdania i usunięcie dokumentacji parametrów oszczędziło 526 token na wywołanie, 29 procent, bez dotykania ani jednej linii logiki — i sprawiło, że model gorzej wywoływał narzędzia, co zmierzył rozdział 18. Chodzi o to, że obie strony tego kompromisu są teraz w tej samej jednostce.

W pewnej skali wysyłanie definicji w ogóle przestaje mieć sens. Anthropic podał liczbę w listopadzie 2025: duży zestaw połączonych serwerów oznacza przetwarzanie „setek tysięcy token” definicji, zanim żądanie zostanie przeczytane, a zastąpienie tego wykonywaniem kodu — agent odkrywa i ładuje tylko definicje, których potrzebuje — „zmniejsza zużycie token ze 150 000 token do 2 000 token, dając oszczędność czasu i kosztów 98,7%”.³ Ten sam pomysł co w reszcie rozdziału, zastosowany do schematów zamiast historii: trzymaj indeks, rozwiązuj wpis na żądanie.

W tym czterdziestoturowym transkrypcie zasadzono dwie rzeczy. W turze 2, przed jakąkolwiek prawdziwą pracą, użytkownik podaje stałą regułę: każde zgłoszenie, które otworzysz, musi być zapisane pod moim numerem pracownika, 4417. W turze 19, w środku incydentu, fakt: dotknięty shard to pay-shard-7, potwierdzony przez zespół płatności. W turze 40 użytkownik prosi agent o otwarcie zgłoszenia incydentu, do czego potrzebne są oba. Każda próba jest zadawana w sześciu różnych sformułowaniach i oceniana na sześć — dekodowanie zachłanne jest deterministyczne, więc jedno wywołanie daje niepowtarzalne tak albo nie, a sześć daje współczynnik.

Transkrypt jest potem odtwarzany w siedmiu politykach context. Odtwarzany, a nie uruchamiany ponownie, celowo: wiadomości, tool calls i wyniki narzędzi są bajt w bajt identyczne we wszystkich siedmiu, więc jedyną zmienną jest to, co każda polityka wybrała do zachowania. Rozdział 16 pokazał, dlaczego przesuwne okno to zły ruch ekonomiczny, bo niszczy cache'owalny prefiks. Oto co robi z zachowaniem:

Wiersze kompaktowania obejmują koszt kompaktowania: 18 581 input token za siedem podsumowań i 3 392 dodatkowe za notującego. Wiersz kontrolny jest po to, by zero można było czytać jako zero — przy samych dwóch wiadomościach w prompt 1 981 token ten model odpowiada perfekcyjnie na oba probe, więc żaden wiersz nie oznacza, że zadanie było zbyt trudne.

Pełna historia pamięta i jest najdroższą rzeczą w tabeli: 370 291 input token za sesję, której trwała treść to dwa zdania.

To odpowiada na pytanie, które początek zostawił otwarte. Dlaczego transkrypt 10 632 token utrzymuje fakt, który rejestr 853 token gubi? Bo długość to zła zmienna. Rejestr trzyma dwadzieścia pięć czterocyfrowych numerów wewnętrznych w dwudziestu pięciu identycznych zdaniach — dwadzieścia cztery prawie idealne wabiki na ten jeden, którego chcesz. Transkrypt trzyma dokładnie jeden numer pracownika i jedną nazwę shard. Context rot to interferencja, zanim stanie się objętością, dlatego 136 z 205 błędnych odpowiedzi powyżej było wartością sąsiada. Użyteczne pytanie o okno nie brzmi, jak długie jest; brzmi, ile rzeczy w nim wygląda jak odpowiedź.

Przesuwne okno jest o 57% tańsze i zgubiło incydent. Numer pracownika przetrwał tylko dlatego, że agent powtórzył go w ostatnich turach. shard, podany raz w turze 19, nie znajduje się w ostatnich dwunastu wiadomościach — a model tego nie mówi. Zapytany sześć razy odpowiedział „dotknięty shard płatności to shard 4417”, sięgając po numer pracownika, jedyny inny identyfikator pozostawiony w oknie, oraz dwa razy „pool”, podniesione ze stringa pool_exhausted w linii logu.

Kompaktowanie jest tanie i zgubiło ten sam fakt. Siedem podsumowań, napisanych przez model pod jawną instrukcją, by zachowywać identyfikatory, liczby, stałe instrukcje i otwarte pytania, a pay-shard-7 nie ma w żadnym z tych, które miały znaczenie; sześć zgadnięć brzmiało shard 1, pay_shard_1 i pool. Kompaktowanie nie zawodzi głośno. Produkuje płynną, wiarygodną, dużo krótszą sesję, która po cichu upuściła jedną linię.

Trzy wiersze uzyskały 0/6 dla faktu z tury 19 — przesuwne okno, kompaktowanie i kompaktowanie z notatkami. Osiemnaście błędnych odpowiedzi między nimi i ani jedna nie brzmiała „nie wiem”.

Potem wiersz, który powinien zawstydzać. Zachowanie czterdziestu własnych wiadomości użytkownika dosłownie, plus ostatnich czterech tur w całości i niczego więcej, kosztuje 168 550 token — 54% mniej niż pełna historia — i odpowiada na oba probe równie dobrze jak pełna historia albo lepiej. Bez summariser, bez notującego, bez drugiego modelu: filtr na role === "user". Słowa użytkownika to najtańsze token o wysokiej wartości w oknie agent, a większość projektów wyrzuca je razem z całą resztą.

Ostatnie dwa wiersze to znów tabela otwierająca, wewnątrz agent. Ten sam przypięty blok, przeniesiony z wiadomości systemowej na koniec prompt: 5/6 staje się 6/6. Przy sześciu próbach to nie jest znacząca różnica i nie jest jako taka przedstawiana — to przypomnienie, że gdzie jest parametrem, który ustawiasz, niezależnie od tego, czy o tym wiesz.

Cztery poniższe strategie są strategiami Anthropic, w tej samej kolejności, choć tylko ostatnie trzy są jego listą long-horizon.¹ Wszystkie cztery są wariacjami jednej instrukcji: nie noś tego, co możesz pobrać, i nie noś raw tego, co możesz nieść skompresowane.

const elide: Policy = (h) => [SYSTEM, ...h.flatMap((turn, ti) =>
  turn.map((m) => (ti < h.length - 4 && m.role === "tool"
    ? { role: "tool", name: m.name,
        content: `[${m.name} result from turn ${ti + 1}, ${m.content.length} chars, ` +
                 `elided; call ${m.name} again with the same arguments to re-read it]` }
    : m)))];

const r = await complete([
  { role: "system", content:
      "You keep a durable note file for a support session. Given one user message, " +
      "output one short note ONLY if it states a standing rule, an identifier or a fact " +
      "that must survive the rest of the session. Otherwise output exactly NONE." },
  { role: "user", content: `Turn ${i + 1}: ${user}` },
], { maxTokens: 40 });
if (!/^none\b/i.test(r.text.trim())) notes.push(`turn ${i + 1}: ${r.text.trim()}`);

Sub-agent nie ma w tabeli powyżej, bo nie działa przez czterdzieści tur: działa raz, w oknie, które ktoś dla niego wyznaczył. Mając system prompt, tury 17 do 19 i nic więcej — 2 737 token — odpowiedział na probe shard 6/6, lepiej niż każda polityka w tabeli, a na probe pracownika 0/6, bo tego numeru nie ma w trzech turach, które dostał.

To sub-agents w dwóch liczbach: czyste okno nie jest inteligencją, jest zakresem, a zakres jest z góry ustalany przez kod, który już musi wiedzieć, które tury mają znaczenie. W tych odpowiedziach warto zachować jeszcze jedną rzecz. To była jedyna polityka, która odpowiedziała „brak dostępnych” zamiast coś wymyślać. Model z małym, spójnym context wie, czego mu brakuje; model z dużym, zaszumionym — nie.

Prawie każda zagmatwana rozmowa o pamięci agent to trzy mechanizmy noszące jedno słowo. Mają różne czasy życia, właścicieli i tryby awarii, a system, który trzyma je w tym samym miejscu, ma problem, którego jeszcze nie zauważył.

Akademickie ujęcie należy do CoALA, które organizuje language agents wokół „modularnych komponentów pamięci” i oddziela pamięć roboczą od magazynów epizodycznych, semantycznych i proceduralnych.⁴ MemGPT bierze ten sam pomysł dosłownie, zapożyczając pamięć wirtualną z systemów operacyjnych: szybka warstwa wewnątrz okna, wolna warstwa poza nim, a sam model przenosi dane między nimi przez function calls.⁵ Oba wymuszają pytanie, na które produkt i tak musi odpowiedzieć — nie ile mogę zachować, ale do którego magazynu to należy i kiedy wygasa.

Praktyczny test to jedno pytanie na fakt: co nadal powinno być prawdą jutro? Wynik narzędzia z tury 12 — nic. Podsumowanie sesji — do końca sesji. To, że numer pracownika użytkownika to 4417 — dopóki nie zmieni pracy. Trzy odpowiedzi, trzy magazyny.

Możesz już zmierzyć, co jest w oknie, zdecydować, co w nim zostaje, i odróżnić agent, który coś zapomniał, od takiego, który to niósł, ale nie spojrzał.

Ostatnia z czterech strategii jest tą, która tu nie pasuje. Sub-agent nie jest polityką context, jest drugim agent, a gdy tylko są dwa, musisz zdecydować, co między nimi przechodzi i który dowodzi. Rozdział 25 jest o tym: pięć wzorców orkiestracji i skąd naprawdę pochodzą ich nazwy, dwie topologie, które się mylą — zapytanie sub-agent i otrzymanie odpowiedzi z powrotem kontra przekazanie mu rozmowy i nieotrzymanie jej z powrotem — oraz zmierzony wynik, że w zadaniu, które wycenia, prostszy układ wygrywa, po czym następuje test, kiedy przestaje wygrywać.

Dziedziczy też dokładnie to, co ten rozdział właśnie zmierzył. Sub-agent zwraca podsumowanie. Podsumowanie to kompaktowanie, którego nie napisałeś, wyprodukowane przez model, którego okna nie widzisz, a rodzic nie ma sposobu, by odróżnić dobre od pewnego błędnego — to samo rozróżnienie, które oddzieliło 84% od 19% na górze tej strony i zamieniło osiemnaście brakujących faktów w osiemnaście wymyślonych. A więc: kiedy sub-agent się myli, na co dokładnie rodzic może spojrzeć?

Każda liczba tutaj została wyprodukowana na tej maszynie i żadna nie była szacowana. Model to Qwen2.5-0.5B-Instruct w float32 na CPU z dekodowaniem zachłannym, serwowany przez loopback przez mały endpoint Python, który mówi formatem chat-completions i udostępnia trasę liczenia token — znów szew z rozdziału 14, tensory po stronie Python, pętla po stronie TypeScript — więc każde zliczenie to własny tokenizer tego modelu zastosowany do jego własnego szablonu czatu. Tabela pozycji to 288 wywołań, dziewięć pozycji po trzydzieści dwie próby z innym zgłoszeniem w każdej próbie; tabela długości to 140 wywołań; przebieg agent to 57 wywołań modelu przez 43 minuty zegarowe; tabela polityk to ten jeden transkrypt odtworzony w siedmiu politykach. Przedziały są Wilsona, z rozdziału 4. Nie wywołano żadnego płatnego API, dlatego w rozdziale nie ma też ani jednej ceny: liczby token są dokładne, a stawki, przez które byś je pomnożył, są w rozdziale 16.