Context engineering: de ce agent devine mai slab la tura 40

Anthropic a tras linia în septembrie 2025, iar cele două propoziții trebuie așezate una lângă alta. Prompt engineering este „metode pentru scrierea și organizarea instrucțiunilor LLM pentru rezultate optime”. Context engineering este „setul de strategii pentru curatorierea și menținerea setului optim de token (informație) în timpul inferenței LLM, incluzând toate celelalte informații care pot ajunge acolo în afara prompturilor”.¹

Diferența operativă este când și de către cine. Un prompt este scris o dată, de o persoană, și revizuit. Un context este asamblat la fiecare apel, de cod la care nu se uită nimeni, din material pe care nimeni nu l-a scris de mână: patruzeci de ture de istoric, șase rezultate de instrumente, patru pasaje recuperate, un profil de utilizator, douăsprezece scheme JSON. Capitolul 15 a măsurat ce cumpără instrucțiunile mai bune. Acest capitol este despre celelalte nouăzeci la sută din token, care sosesc singuri.

Același document numește resursa pe care toate o cheltuie: modelele „au un «attention budget» din care trag când parsează volume mari de context. Fiecare token nou introdus epuizează o parte din acest buget”. Și numește simptomul: „pe măsură ce numărul de token din context window crește, capacitatea modelului de a-și aminti corect informații din acel context scade” — context rot.¹

Ultima propoziție este o afirmație despre comportament, ceea ce înseamnă că poate fi verificată, iar tabelul din partea de sus a acestei pagini este verificarea.

Patruzeci de linii către endpointul local din Capitolul 22 — un mic server Python care ține Qwen2.5-0.5B-Instruct pe CPU și vorbește forma chat-completions, astfel încât bucla rămâne TypeScript, iar tensorii rămân dincolo de port.

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++;
  }
}

Contorul other este ceea ce transformă un rezultat dezamăgitor într-unul util: când modelul greșește, este pierdut sau este încrezător?

Răspunsul este încrezător. Pe cele opt poziții care nu sunt prima, 136 dintre cele 205 răspunsuri greșite au fost extensia altui tichet — un număr real de patru cifre, formatat corect, citit de pe rândul greșit. La slotul 1, doar una dintre cele cinci ratări a fost așa; la slotul 7, douăzeci și una din douăzeci și șase au fost.

Această distincție este cea care contează în producție. Un model care spune nu îl pot găsi este un bug pe care îl observi; un model care returnează numărul unui rând vecin este un bug pe care îl livrezi, pentru că pe ecran cele două arată identic. Este eșecul împotriva căruia Capitolul 19 a construit citări verificabile, sosind din interiorul prompt în loc să vină din index.

Poziția este o axă. Lungimea este cealaltă și e mai ușor de testat: ține răspunsul la mijloc și crește lista.

O înregistrare și 97 de token: 90 %. Trei înregistrări și 159 de token: 55 %. Opt înregistrări și 315 token: 15 %, iar de acolo plat și jos până la 140 de înregistrări și 4.477 de token. Întreaga prăbușire se întâmplă între primul și al optulea rând al unei liste.

Ultima coloană este tot ce nu este nici extensia corectă, nici a altei înregistrări, ceea ce, cu o singură înregistrare pe pagină, este singurul loc unde poate ajunge un răspuns greșit. Cele două ratări la o înregistrare merită raportate, nu rotunjite, pentru că niciuna nu a fost un refuz: una a răspuns 5806 la un registru al cărui singur rând spune 5805. La 97 de token cu un singur candidat, acest model tot copiază greșit o cifră de două ori din douăzeci, iar acesta este pragul minim față de care se măsoară restul.

De aici urmează două lucruri. Un context mai mare cumpără dreptul de a trimite mai mult, nu certitudinea că va fi citit: acest model are o context window de 32.768 de token și un interval de lucru, pe această sarcină, de câteva sute de token. Și nu există prag, nu există prăpastie, nu există stare de „context plin” — degradarea este deja în curs la a treia înregistrare și completă până la a opta, la unu la sută din fereastră. Orice ar fi o limită de context, nu ea guvernează asta.

De obicei sunt oferite două mecanisme. Primul este aritmetica din Capitolul 9, pe care Anthropic o formulează în aceiași termeni ca acest curs: modelele „se bazează pe arhitectura transformer, care permite fiecărui token să attend la fiecare alt token din întregul context. Rezultatul este n² relații pereche pentru n token”.¹ Attention pe o secvență mai lungă nu este aceeași operație aplicată pe mai mult material; este un buget fix de masă de probabilitate, întins peste mai mulți competitori. Al doilea este antrenarea: modelele văd mult mai multe secvențe scurte decât lungi, deci tiparele poziționale pe distanțe lungi sunt partea cea mai puțin exersată a rețelei. Acesta este un argument, nu o măsurătoare, iar capitolul acesta nu îl poate tranșa.

Ce este tranșat este forma, și este tranșată din 2023. Liu et al. au testat răspunsul la întrebări multi-document și key-value retrieval pe familii și dimensiuni de modele și au constatat că „performanța este adesea cea mai ridicată când informația relevantă apare la începutul sau la sfârșitul contextului de intrare și se degradează semnificativ când modelele trebuie să acceseze informație relevantă din mijlocul contextelor lungi, chiar și pentru modele explicit long-context”.² Capitolul 15 și-a luat regula de poziție din acea lucrare; Capitolul 19 a luat de acolo motivul pentru care douăzeci de chunks recuperate pot avea scor mai prost decât patru. Forma practică a faptului este singura propoziție de aici după care ar trebui să acționezi: asta durează cinci minute de măsurat pe propriul model cu propriile date, iar nicio curbă publicată nu o înlocuiește pe a ta.

Întreabă o echipă ce umple contextul pentru agent și primești o estimare, pentru că niciun API nu returnează răspunsul: răspunsul îți dă prompt_tokens, un singur număr pentru toate.

Poți recupera defalcarea cu patru numărători și trei scăderi — întregul prompt randat, același fără definiții de instrumente, mesajul de sistem singur cu și fără ele și totul cu rezultatele instrumentelor eliminate:

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 aplică propriul template de chat al modelului înainte de tokenizare, ceea ce contează mai mult decât pare: textul tău nu este ce se numără. Marcatorii de rol, preambulul tool-calling și randarea schemei sunt toate token pentru care plătești și pe care nu i-ai tastat niciodată. Capitolul 7 a construit un tokenizer, iar Capitolul 16 a numărat cu js-tiktoken; aici numărătoarea vine de la același model care va citi prompt, care este singura numărătoare exact corectă.

Acum rulează un agent real prin asta: patruzeci de ture de investigare a unui incident, douăsprezece instrumente, un mediu operațional fals care returnează dumpuri de loguri și serii de metrici realiste.

Citește primul rând în raport cu ultimul.

La tura 1, prompt are 2.547 de token, iar 71 % din el sunt definiții de instrumente. system prompt este 3 %. Ce a tastat utilizatorul este 6 %. agent nu a făcut încă nimic și poartă deja 1.817 token de schemă JSON.

Până la tura 40, prompt are 10.632 de token, iar ponderile s-au inversat: definiții 17 %, conversație 29 %, rezultate de instrumente 53 %. Outputul instrumentelor a depășit definițiile la tura 5; conversația nu le-a depășit până la tura 25, așa că în primele șaizeci la sută ale sesiunii catalogul de instrumente a fost mai mare decât tot ce se spusese.

Apoi totalul. Pe 57 de apeluri de model, rularea a facturat 370.291 input token pentru un context final de 10.632 — ultimul prompt plătit de aproximativ treizeci și cinci de ori, adică pătraticul din Capitolul 16 cu multiplicatorul unui agent deasupra. Din acei 370.291, 103.569, sau 28 % din tot ce s-a facturat, au fost cele douăsprezece definiții de instrumente, retrimise byte-identic la fiecare apel.

Catalogul de instrumente este cel mai mare cost fix într-un agent și este invizibil, pentru că nu îl vezi niciodată: trimiți un array de obiecte, iar providerul îl randează în prompt pentru tine. Măsurat, pe aceleași douăsprezece instrumente:

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 %)

Per instrument, costul marginal merge de la 80 de token pentru get_current_time, care ia un string, până la 263 pentru search_tickets, care ia patru parametri cu un enum și câte o propoziție de îndrumare pentru fiecare. Acesta este cursul de schimb din spatele sfatului central al Capitolului 18 că descrierea este API: o descriere bună costă cam o sută de token la fiecare cerere pentru tot restul vieții agent. Trei consecințe.

Un instrument pe care nu îl folosești tot facturează. agent a apelat șapte dintre cele douăsprezece. Celelalte cinci au costat 697 de token la fiecare dintre cele 57 de cereri — 39.729 în total, mai mult de o zecime din tot ce s-a facturat pentru rulare, pentru capabilități pe care nu le-a atins niciodată. Unul dintre cele cinci poartă cel mai tăios detaliu din trace: modelul a încercat de trei ori să apeleze read_log, care nu există. Instrumentul pe care îl voia era search_logs, a doua cea mai scumpă definiție din catalog, la 237 de token. A plătit pentru acea definiție de 57 de ori, nu a folosit-o niciodată și nu i-a găsit niciodată numele.

Tăierea prozei este cea mai ieftină optimizare disponibilă și este un compromis. Reducerea descrierilor la o propoziție și eliminarea documentației parametrilor au economisit 526 de token per apel, 29 la sută, fără a atinge o linie de logică — și au făcut modelul să apeleze instrumentele mai prost, exact ce a măsurat Capitolul 18. Ideea este că ambele părți ale compromisului sunt acum în aceeași unitate.

La o anumită scară, trimiterea definițiilor nu mai are sens deloc. Anthropic a pus un număr pe asta în noiembrie 2025: un set mare de servere conectate înseamnă procesarea a „sute de mii de token” de definiții înainte ca cererea să fie citită, iar înlocuirea cu execuție de cod — agent descoperă și încarcă doar definițiile de care are nevoie — „reduce consumul de token de la 150.000 de token la 2.000 de token, o economie de timp și cost de 98,7 %”.³ Aceeași idee ca restul capitolului, aplicată schemelor în locul istoricului: păstrează indexul, rezolvă intrarea la cerere.

Două lucruri au fost plantate în acel transcript de patruzeci de ture. La tura 2, înainte de orice muncă reală, utilizatorul enunță o regulă permanentă: orice tichet deschizi trebuie depus sub numărul meu de angajat, 4417. La tura 19, în mijlocul incidentului, un fapt: shardul afectat este pay-shard-7, confirmat de echipa de plăți. La tura 40, utilizatorul îi cere agent să deschidă tichetul de incident, care are nevoie de ambele. Fiecare probă este cerută în șase formulări diferite și punctată din șase — decodarea greedy este deterministă, deci un apel dă un da sau nu irepetabil, iar șase dau o rată.

Transcriptul este apoi redat sub șapte politici de context. Redat, nu rulat din nou, deliberat: mesajele, tool calls și rezultatele instrumentelor sunt byte-identice în toate cele șapte, deci singura variabilă este ce a ales fiecare politică să păstreze. Capitolul 16 a arătat de ce o fereastră glisantă este o mișcare economică proastă, pentru că distruge prefixul cacheable. Iată ce face comportamentului:

Rândurile de compactare includ costul compactării: 18.581 input token pentru șapte rezumate și încă 3.392 pentru notetaker. Rândul de control este acolo ca un zero să poată fi citit ca zero — cu cele două mesaje singure într-un prompt de 1.981 de token, acest model răspunde perfect la ambele probe, deci niciun rând nu înseamnă că sarcina este prea grea.

Istoricul complet își amintește și este cel mai scump lucru din tabel: 370.291 input token pentru o sesiune al cărei conținut durabil este două propoziții.

Asta răspunde unei întrebări pe care deschiderea a lăsat-o deschisă. De ce un transcript de 10.632 de token ține un fapt pe care un registru de 853 de token îl pierde? Pentru că lungimea este variabila greșită. Registrul conține douăzeci și cinci de extensii de patru cifre în douăzeci și cinci de propoziții identice — douăzeci și patru de momeli aproape perfecte pentru cea pe care o vrei. Transcriptul conține exact un număr de angajat și un nume de shard. Context rot este interferență înainte să fie volum, motiv pentru care 136 dintre cele 205 răspunsuri greșite de sus au fost valoarea unui vecin. Întrebarea utilă despre o fereastră nu este cât de lungă e; este câte lucruri din ea arată ca răspunsul.

Fereastra glisantă este cu 57 % mai ieftină și a pierdut incidentul. Numărul de angajat supraviețuiește doar pentru că agent îl repetase în turele recente. Shardul, spus o singură dată la tura 19, nu este în ultimele douăsprezece mesaje — iar modelul nu spune asta. Întrebat de șase ori, a răspuns „shardul de plăți afectat este shard 4417”, întinzând mâna după numărul de angajat, singurul alt identificator rămas în fereastra lui, și de două ori „pool”, ridicat din stringul pool_exhausted dintr-o linie de log.

Compactarea este ieftină și a pierdut același fapt. Șapte rezumate, scrise de model sub o instrucțiune explicită de a păstra identificatori, numere, instrucțiuni permanente și întrebări deschise, iar pay-shard-7 nu este în niciunul dintre cele care contau; cele șase presupuneri au fost shard 1, pay_shard_1 și pool. Compactarea nu eșuează zgomotos. Produce o sesiune fluentă, plauzibilă, mult mai scurtă, care a scăpat în liniște un rând.

Trei rânduri au avut scor 0/6 la faptul din tura 19 — fereastra glisantă, compactarea și compactarea cu notițe. Optsprezece răspunsuri greșite între ele și niciunul nu a fost „nu știu”.

Apoi rândul care ar trebui să fie jenant. Păstrarea verbatim a celor patruzeci de mesaje proprii ale utilizatorului, plus ultimele patru ture complete și nimic altceva, costă 168.550 de token — cu 54 % mai puțin decât istoricul complet — și răspunde la ambele probe la fel de bine ca istoricul complet sau mai bine. Fără sumarizator, fără notetaker, fără al doilea model: un filtru pe role === "user". Cuvintele utilizatorului sunt cei mai ieftini token de mare valoare din fereastra unui agent, iar majoritatea designurilor îi aruncă împreună cu orice altceva.

Ultimele două rânduri sunt din nou tabelul de deschidere, în interiorul agent. Același bloc fixat, mutat din mesajul de sistem la sfârșitul prompt: 5/6 devine 6/6. Pe șase încercări, nu este o diferență semnificativă și nu este oferită ca atare — este oferită ca reamintire că unde este un parametru pe care îl setezi, fie că știi, fie că nu.

Cele patru strategii de mai jos sunt ale Anthropic, în ordinea lor, deși doar ultimele trei sunt lista lor de long-horizon.¹ Toate patru sunt variații ale unei singure instrucțiuni: nu căra ce poți fetch și nu căra raw ce poți căra comprimat.

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 nu este în tabelul de mai sus pentru că nu rulează patruzeci de ture: rulează o dată, într-o fereastră pe care cineva a delimitat-o pentru el. Dat fiind system prompt, turele 17 până la 19 și nimic altceva — 2.737 de token — a răspuns la proba shardului 6/6, mai bine decât orice politică din tabel, și la proba angajatului 0/6, pentru că acel număr nu este în cele trei ture care i-au fost date.

Asta înseamnă sub-agents în două numere: o fereastră curată nu este inteligență, este scope, iar scoping este făcut în avans de cod care oricum trebuie să știe ce ture contează. Încă un lucru din acele răspunsuri merită păstrat. Aceasta a fost singura politică ce a răspuns „None available” în loc să inventeze ceva. Un model cu un context mic și coerent știe ce îi lipsește; un model cu unul mare și zgomotos nu știe.

Aproape orice conversație confuză despre memoria unui agent înseamnă trei mecanisme purtând același cuvânt. Au durate de viață, proprietari și moduri de eșec diferite, iar un sistem care le ține în același loc are o problemă pe care încă nu a observat-o.

Încadrarea academică este cea a CoALA, care organizează language agents în jurul „componentelor de memorie modulare” și separă working memory de stocurile episodice, semantice și procedurale.⁴ MemGPT ia aceeași idee literal, împrumutând memoria virtuală din sistemele de operare: un nivel rapid în interiorul ferestrei, un nivel lent în afara ei și modelul însuși mutând date între ele cu function calls.⁵ Ambele forțează întrebarea la care un produs trebuie oricum să răspundă — nu cât pot păstra, ci în ce store aparține asta și când expiră.

Testul practic este o întrebare per fapt: ce ar trebui să mai fie adevărat mâine? Un rezultat de instrument din tura 12, nimic. Un rezumat al sesiunii, până se termină sesiunea. Faptul că numărul de angajat al utilizatorului este 4417, până își schimbă jobul. Trei răspunsuri, trei store-uri.

Acum poți măsura ce este într-o fereastră, poți decide ce rămâne în ea și poți face diferența între un agent care a uitat ceva și unul care îl purta, dar nu s-a uitat.

Ultima dintre cele patru strategii este cea care nu încape aici. Un sub-agent nu este o politică de context, este un al doilea agent, iar în clipa în care sunt doi trebuie să decizi ce trece între ei și care conduce. Capitolul 25 este asta: cele cinci tipare de orchestrare și de unde vine de fapt fiecare dintre numele lor, cele două topologii care se confundă — a întreba un sub-agent și a primi un răspuns înapoi, versus a-i preda conversația și a nu o primi înapoi — și constatarea măsurată că, pe sarcina pe care o costează, aranjamentul mai simplu câștigă — urmată de testul pentru când încetează să câștige.

Moștenește și exact ce tocmai a măsurat acest capitol. Un sub-agent returnează un rezumat. Un rezumat este o compactare pe care nu ai scris-o, produsă de un model a cărui fereastră nu o poți vedea, iar părintele nu are cum să deosebească unul bun de unul greșit, dar încrezător — aceeași distincție care a separat 84 % de 19 % în partea de sus a acestei pagini și care a transformat optsprezece fapte lipsă în optsprezece invenții. Deci: când sub-agent greșește, la ce anume are voie părintele să se uite?

Fiecare număr de aici a fost produs pe această mașină și niciunul nu a fost estimat. Modelul este Qwen2.5-0.5B-Instruct în float32 pe CPU cu decodare greedy, servit peste loopback de un mic endpoint Python care vorbește forma chat-completions și expune o rută de token-count — din nou îmbinarea din Capitolul 14, tensorii pe partea Python și bucla pe partea TypeScript — deci fiecare numărătoare este tokenizerul propriu al acelui model aplicat propriului său template de chat. Tabelul de poziție are 288 de apeluri, nouă poziții ori treizeci și două de încercări cu un tichet diferit la fiecare încercare; tabelul de lungime are 140 de apeluri; rularea agent este 57 de apeluri de model peste 43 de minute de timp real; tabelul de politici este acel transcript redat sub șapte politici. Intervalele sunt Wilson, din Capitolul 4. Nu a fost apelat niciun API plătit, motiv pentru care nu există niciun preț în capitol: numerele de token sunt exacte, iar tarifele cu care le-ai înmulți sunt ale Capitolului 16.