Context Engineering: por que o teu agent se volve máis parvo na quenda 40

Anthropic trazou a liña en setembro de 2025 e as dúas frases van unha xunto á outra. Prompt engineering é «methods for writing and organizing LLM instructions for optimal outcomes». Context engineering é «the set of strategies for curating and maintaining the optimal set of tokens (information) during LLM inference, including all the other information that may land there outside of the prompts».¹

A diferenza operativa é cando, e por quen. Un prompt escríbese unha vez, por unha persoa, e revísase. Un contexto ensámblase en cada chamada, por código que ninguén está mirando, a partir de material que ninguén escribiu á man: corenta quendas de historial, seis resultados de ferramentas, catro pasaxes recuperadas, un perfil de usuario, doce esquemas JSON. O Capítulo 15 mediu o que compran unhas instrucións mellores. Este capítulo trata do outro noventa por cento dos tokens, que chegan sós.

O mesmo documento nomea o recurso que todos gastan: os modelos «have an 'attention budget' that they draw on when parsing large volumes of context. Every new token introduced depletes this budget by some amount». E nomea o síntoma: «as the number of tokens in the context window increases, the model's ability to accurately recall information from that context decreases» — context rot.¹

Esa última frase é unha afirmación sobre comportamento, o que significa que se pode comprobar, e a táboa do comezo desta páxina é a comprobación.

Corenta liñas contra o endpoint local do Capítulo 22 — un pequeno servidor Python que mantén Qwen2.5-0.5B-Instruct na CPU e fala coa forma chat-completions, para que o bucle quede en TypeScript e os tensores queden ao outro lado do porto.

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

O contador other é o que converte un resultado decepcionante nun útil: cando o modelo se equivoca, está perdido ou está seguro?

A resposta é que está seguro. Nas oito posicións que non son a primeira, 136 das 205 respostas erradas eran a extensión doutro ticket — un número real de catro cifras, co formato correcto, lido da liña equivocada. Na posición 1 só o foi unha das cinco respostas fallidas; na posición 7, vinte e unha de vinte e seis.

Esa distinción é o que importa en produción. Un modelo que di non o atopo é un bug que notas; un modelo que devolve o número dunha fila veciña é un bug que envías, porque na pantalla os dous parecen idénticos. É o fallo contra o que o Capítulo 19 construíu citas verificables, chegando desde dentro do prompt en vez de desde o índice.

A posición é un eixo. A lonxitude é o outro, e é máis doada de probar: mantén a resposta no medio e fai medrar a lista.

Un rexistro e 97 tokens: 90 %. Tres rexistros e 159 tokens: 55 %. Oito rexistros e 315 tokens: 15 %, e desde aí plano e baixo ata 140 rexistros e 4.477 tokens. Todo o colapso ocorre entre a primeira e a oitava liña dunha lista.

A última columna é todo o que non é nin a extensión correcta nin a doutro rexistro, que cun único rexistro na páxina é o único sitio onde pode caer unha resposta errada. As dúas respostas fallidas con un rexistro merecen ser reportadas en vez de redondeadas fóra, porque ningunha foi unha negativa: unha respondeu 5806 a un rexistro cuxa única liña di 5805. Con 97 tokens e un único candidato, este modelo aínda copia mal unha cifra dúas veces de vinte, e ese é o chan contra o que se mide todo o demais.

Dúas cousas se deducen. Un contexto máis grande compra o dereito a enviar máis, non a certeza de que será lido: este modelo ten unha context window de 32.768 tokens e un rango de traballo, nesta tarefa, duns poucos centos de tokens. E non hai limiar, nin cantil, nin estado de «contexto cheo»: a degradación xa vai en marcha no terceiro rexistro e está completa no oitavo, ao un por cento da xanela. Sexa o que sexa un límite de contexto, non é o que goberna isto.

Adoitan ofrecerse dous mecanismos. O primeiro é a aritmética do Capítulo 9, que Anthropic formula nos mesmos termos ca este curso: os modelos «are based on the transformer architecture, which enables every token to attend to every other token across the entire context. This results in n² pairwise relationships for n tokens».¹ A attention sobre unha secuencia máis longa non é a mesma operación aplicada a máis material; é un orzamento fixo de masa de probabilidade repartido entre máis competidores. O segundo é o adestramento: os modelos ven moitas máis secuencias curtas ca longas, así que os patróns posicionais de longo alcance son a parte menos practicada da rede. Iso é un argumento, non unha medición, e este capítulo non pode resolvelo.

O que si está resolto é a forma, e leva estándoo desde 2023. Liu et al. probaron resposta a preguntas multi-documento e recuperación key-value en familias e tamaños de modelos, e atoparon que «performance is often highest when relevant information occurs at the beginning or end of the input context, and significantly degrades when models must access relevant information in the middle of long contexts, even for explicitly long-context models».² O Capítulo 15 tomou a súa regra de posición dese artigo; o Capítulo 19 tomou del a razón pola que vinte chunks recuperados poden puntuar peor ca catro. A forma práctica do feito é a única frase aquí sobre a que deberías actuar: isto leva cinco minutos medilo no teu propio modelo cos teus propios datos, e ningunha curva publicada substitúe a túa.

Pregunta a un equipo que enche o contexto do seu agent e obterás unha estimación, porque ningunha API devolve a resposta: a resposta dáche prompt_tokens, un número para todo.

Podes recuperar a desagregación con catro contas e tres restas: o prompt renderizado completo, o mesmo sen definicións de ferramentas, só a mensaxe do sistema con elas e sen elas, e todo cos resultados das ferramentas retirados:

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 aplica o propio modelo de chat do modelo antes de tokenizar, o que importa máis do que parece: o teu texto non é o que se conta. Marcadores de rol, o preámbulo de tool-calling e a renderización do esquema son todos tokens que pagas e que nunca escribiches. O Capítulo 7 construíu un tokenizer e o Capítulo 16 contou con js-tiktoken; aquí a conta vén do mesmo modelo que lerá o prompt, que é a única conta exactamente correcta.

Agora pásalle un agent real: corenta quendas dunha investigación de incidente, doce ferramentas, un ambiente de operacións falso que devolve volcados de logs e series de métricas realistas.

Le a primeira fila fronte á última.

Na quenda 1 o prompt ten 2.547 tokens e o 71 % son definicións de ferramentas. O system prompt é o 3 %. O que escribiu o usuario é o 6 %. O agent aínda non fixo nada e xa leva 1.817 tokens de esquema JSON.

Na quenda 40 o prompt ten 10.632 tokens e as proporcións invertéronse: definicións 17 %, conversa 29 %, resultados de ferramentas 53 %. A saída das ferramentas superou as definicións na quenda 5; a conversa non as superou ata a quenda 25, así que durante o primeiro sesenta por cento da sesión o catálogo de ferramentas foi máis grande ca todo o que se dixera.

Despois, o total. En 57 chamadas ao modelo, a execución facturou 370.291 input tokens para un contexto final de 10.632: o último prompt pagouse unhas trinta e cinco veces, que é a cuadrática do Capítulo 16 co multiplicador dun agent por riba. Deses 370.291, 103.569, ou o 28 % de todo o facturado, foron as doce definicións de ferramentas, reenviadas byte a byte idénticas en cada chamada.

O catálogo de ferramentas é o maior custo fixo dun agent e é invisible, porque nunca o ves: pasas un array de obxectos e o provedor renderízao no prompt por ti. Medido, nas mesmas doce ferramentas:

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

Por ferramenta, o custo marxinal vai desde 80 tokens para get_current_time, que toma unha cadea, ata 263 para search_tickets, que toma catro parámetros cun enum e unha frase de guía para cada un. Esa é a taxa de cambio detrás do consello central do Capítulo 18 de que a descrición é a API: unha boa descrición custa arredor de cen tokens en cada petición durante o resto da vida do agent. Tres consecuencias.

Unha ferramenta que non usas tamén factura. O agent chamou sete das doce. As outras cinco custaron 697 tokens en cada unha das 57 peticións — 39.729 en total, máis dunha décima parte de todo o que se lle facturou á execución, por capacidades que nunca tocou. Unha das cinco leva o detalle máis agudo da traza: o modelo intentou tres veces chamar read_log, que non existe. A ferramenta que quería era search_logs, a segunda definición máis cara do catálogo con 237 tokens. Pagou por esa definición 57 veces, nunca a usou e nunca atopou o seu nome.

Recortar prosa é a optimización máis barata dispoñible, e é un intercambio. Reducir as descricións a unha frase e eliminar a documentación de parámetros aforrou 526 tokens por chamada, un 29 por cento, sen tocar unha liña de lóxica — e fixo que o modelo chamase peor as ferramentas, que é o que mediu o Capítulo 18. A cuestión é que os dous lados dese intercambio están agora na mesma unidade.

A certa escala, enviar definicións deixa de ter sentido. Anthropic púxolle un número en novembro de 2025: un conxunto grande de servidores conectados significa procesar «hundreds of thousands of tokens» de definicións antes de que se lea a petición, e substituír iso por execución de código — o agent descubrindo e cargando só as definicións que precisa — «reduces the token usage from 150,000 tokens to 2,000 tokens, a time and cost saving of 98.7%».³ A mesma idea ca o resto deste capítulo, aplicada a esquemas en vez de ao historial: mantén o índice, resolve a entrada baixo demanda.

Plantáronse dúas cousas nesa transcrición de corenta quendas. Na quenda 2, antes de calquera traballo real, o usuario indica unha regra permanente: calquera ticket que abras debe arquivarse baixo o meu número de empregado, 4417. Na quenda 19, no medio do incidente, un feito: o shard afectado é pay-shard-7, confirmado polo equipo de pagamentos. Na quenda 40 o usuario pídelle ao agent que abra o ticket do incidente, que precisa ambas cousas. Cada proba faise en seis formulacións diferentes e puntúase sobre seis: greedy decoding é determinista, así que unha chamada dá un si ou non irrepetible e seis dan unha taxa.

A transcrición reprodúcese despois baixo sete políticas de contexto. Reproducida en vez de executada de novo, deliberadamente: as mensaxes, as chamadas de ferramentas e os resultados das ferramentas son byte a byte idénticos nas sete, así que a única variable é o que cada política escolleu conservar. O Capítulo 16 mostrou por que unha sliding window é unha mala xogada económica, porque destrúe o prefixo cacheable. Aquí tes o que lle fai ao comportamento:

As filas de compactación inclúen o que custou compactar: 18.581 input tokens por sete resumos e 3.392 máis polo tomador de notas. A fila de control está aí para que un cero poida lerse como un cero: coas dúas mensaxes soas nun prompt de 1.981 tokens este modelo responde perfectamente as dúas probas, así que ningunha fila é que a tarefa sexa demasiado difícil.

O historial completo lembra, e é o máis caro da táboa: 370.291 input tokens para unha sesión cuxo contido duradeiro son dúas frases.

Iso responde unha pregunta que a apertura deixou aberta. Por que unha transcrición de 10.632 tokens conserva un feito que un rexistro de 853 tokens perde? Porque a lonxitude é a variable equivocada. O rexistro contén vinte e cinco extensións de catro cifras en vinte e cinco frases idénticas: vinte e catro señuelos case perfectos para a que queres. A transcrición contén exactamente un número de empregado e un nome de shard. Context rot é interferencia antes de ser volume, por iso 136 das 205 respostas erradas de arriba eran o valor dun veciño. A pregunta útil sobre unha xanela non é canto mide; é cantas cousas nela se parecen á resposta.

A sliding window é un 57 % máis barata e perdeu o incidente. O número de empregado sobrevive só porque o agent o repetira nas quendas recentes. O shard, dito unha soa vez na quenda 19, non está nas últimas doce mensaxes — e o modelo non o di. Preguntado seis veces respondeu «the affected payment shard is shard 4417», botando man do número de empregado, o único outro identificador que quedaba na súa xanela, e dúas veces «pool», sacado da cadea pool_exhausted nunha liña de log.

A compactación é barata e perdeu o mesmo feito. Sete resumos, escritos polo modelo baixo unha instrución explícita de conservar identificadores, números, instrucións permanentes e preguntas abertas, e pay-shard-7 non está en ningún dos que importaban; as seis suposicións foron shard 1, pay_shard_1 e pool. A compactación non falla facendo ruído. Produce unha sesión fluída, plausible e moito máis curta que deixou caer unha liña en silencio.

Tres filas puntuaron 0/6 no feito da quenda 19: a sliding window, a compactación e a compactación con notas. Dezaoito respostas erradas entre elas, e nin unha foi «non o sei».

Despois vén a fila que debería dar vergoña. Manter as corenta mensaxes propias do usuario literalmente, máis as últimas catro quendas completas e nada máis, custa 168.550 tokens — un 54 % menos ca o historial completo — e responde as dúas probas tan ben como o historial completo ou mellor. Sen resumidor, sen tomador de notas, sen segundo modelo: un filtro sobre role === "user". As palabras do usuario son os tokens baratos de alto valor na xanela dun agent, e a maioría dos deseños descártaas con todo o demais.

As dúas últimas filas son de novo a táboa inicial, dentro do agent. O mesmo bloque fixado, movido da mensaxe de sistema ao final do prompt: 5/6 convértese en 6/6. En seis ensaios iso non é unha diferenza significativa e non se presenta como tal: preséntase como recordatorio de que onde é un parámetro que estás configurando, o saibas ou non.

As catro estratexias seguintes son as de Anthropic, na súa orde, aínda que só as tres últimas son a súa lista de longo horizonte.¹ As catro son variacións dunha instrución: non cargues o que podes buscar, e non cargues en bruto o que podes levar comprimido.

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()}`);

O sub-agent non está na táboa de arriba porque non se executa durante corenta quendas: execútase unha vez, nunha xanela que alguén delimitou para el. Dado o system prompt, as quendas 17 a 19 e nada máis — 2.737 tokens — respondeu a proba do shard 6/6, mellor ca todas as políticas da táboa, e a proba do empregado 0/6, porque ese número non está nas tres quendas que recibiu.

Iso son os sub-agents en dous números: unha xanela limpa non é intelixencia, é alcance, e a delimitación faina de antemán código que xa ten que saber que quendas importan. Hai outra cousa nesas respostas que paga a pena gardar. Esta foi a única política que respondeu «None available» en vez de inventar algo. Un modelo cun contexto pequeno e coherente sabe que lle falta; un modelo cun contexto grande e ruidoso non.

Case toda conversa confusa sobre memoria de agents son tres mecanismos levando unha soa palabra. Teñen vidas útiles, propietarios e modos de fallo distintos, e un sistema que os garda no mesmo sitio ten un problema que aínda non notou.

O marco académico é CoALA, que organiza language agents arredor de «modular memory components» e separa a memoria de traballo dos almacéns episódico, semántico e procedemental.⁴ MemGPT toma a mesma idea literalmente, tomando prestada a memoria virtual dos sistemas operativos: unha capa rápida dentro da xanela, unha capa lenta fóra dela, e o propio modelo movendo datos entre elas con function calls.⁵ Ambas obrigan a facer a pregunta que un produto ten que responder de todos modos: non canto podo conservar, senón a que almacén pertence isto, e cando caduca.

A proba práctica é unha pregunta por feito: que debería seguir sendo certo mañá? Un resultado de ferramenta da quenda 12, nada. Un resumo da sesión, ata que a sesión remate. Que o número de empregado do usuario é 4417, ata que cambie de traballo. Tres respostas, tres almacéns.

Agora podes medir que hai nunha xanela, decidir que queda nela e distinguir entre un agent que esqueceu algo e un que o levaba enriba e non mirou.

A última das catro estratexias é a que non encaixa aquí. Un sub-agent non é unha política de contexto, é un segundo agent, e no momento en que hai dous tes que decidir que pasa entre eles e quen manda. O Capítulo 25 é iso: os cinco patróns de orquestración e de onde sae realmente cada un dos seus nomes, as dúas topoloxías que se confunden — preguntarlle a un sub-agent e recibir unha resposta de volta, fronte a pasarlle a conversa e non recibila de volta — e o achado medido de que, na tarefa que pon prezo, a disposición máis simple gaña; seguido da proba para cando deixa de gañar.

Tamén herda exactamente o que este capítulo acaba de medir. Un sub-agent devolve un resumo. Un resumo é unha compactación que non escribiches, producida por un modelo cuxa xanela non podes ver, e o pai non ten forma de distinguir un bo resumo dun errado con confianza: a mesma distinción que separaba o 84 % do 19 % ao comezo desta páxina, e que converteu dezaoito feitos ausentes en dezaoito inventados. Así que: cando o sub-agent se equivoca, que pode mirar exactamente o pai?

Cada número aquí foi producido nesta máquina e ningún foi estimado. O modelo é Qwen2.5-0.5B-Instruct en float32 na CPU con greedy decoding, servido sobre loopback por un pequeno endpoint Python que fala coa forma chat-completions e expón unha ruta de reconto de tokens — de novo a costura do Capítulo 14, tensores no lado Python e o bucle no lado TypeScript — así que cada conta é o tokenizer propio dese modelo aplicado ao seu propio modelo de chat. A táboa de posición son 288 chamadas, nove posicións por trinta e dous ensaios cun ticket diferente en cada ensaio; a táboa de lonxitude son 140 chamadas; a execución do agent son 57 chamadas ao modelo ao longo de 43 minutos de reloxo; a táboa de políticas é esa única transcrición reproducida baixo sete políticas. Os intervalos son de Wilson, do Capítulo 4. Non se chamou ningunha API de pago, que tamén é por iso que non hai nin un prezo no capítulo: as contas de tokens son exactas e as tarifas polas que as multiplicarías son as do Capítulo 16.