AI & MCP
Gestire la finestra di contesto di un agente: budget, tagli e cache
Una finestra grande non è una strategia: serve un budget per voce, un ordine di taglio e un prefisso stabile per la cache. Ecco la ripartizione.
In sintesi
- Il budget si scrive prima: system, schemi, documenti, storico e risposta hanno tetti separati.
- Si tagliano prima gli output vecchi dei tool e i file riletti, poi si comprime lo storico.
- Un prefisso stabile rende la cache utile; una data in testa al system prompt la annulla.
La finestra di contesto si gestisce con un budget scritto per voce, un ordine di taglio deciso prima e un prefisso stabile che la cache possa riusare. Comprare una finestra più grande non è una strategia.
Il budget si scrive prima
| Voce | Token | Quota del budget | Cosa contiene |
|---|---|---|---|
| System prompt | 1.500 | 0,75% | ruolo, regole, formato di risposta |
| Schemi dei tool | 900 | 0,45% | nomi, descrizioni, input |
| File e documenti | 80.000 | 40% | solo i file toccati dal task |
| Storico dei passi | 30.000 | 15% | ultimi risultati e riassunto |
| Risposta riservata | 8.000 | 4% | spazio per l'output del modello |
| Margine | 79.600 | 39,8% | picchi e chiamate extra |
La tabella è una ripartizione di progetto su 200.000 token, non una misura: serve a decidere in anticipo cosa cede quando il task cresce. Senza tetti separati, il primo file grosso mangia lo spazio della risposta e il modello tronca l'output a metà.
Tagliare prima di comprimere
- Output vecchi dei tool: tieni l'ultimo risultato e il riassunto dei precedenti, non ogni JSON intermedio.
- File riletti: un diff è più economico del file intero quando la modifica è già nota.
- Log e test: le prime righe dell'errore bastano; diecimila righe raramente cambiano la prossima azione.
- Duplicati: lo stesso file citato in due passi va contato una volta sola.
L'ordine conta perché ogni voce ha un costo di ricostruzione diverso. Un output vecchio si può buttare senza perdere capacità di agire; un identificativo no. Il taglio va fatto sui dati che il modello non userà più, non sui dati che servono a spiegare perché è arrivato qui.
Comprimere tenendo gli identificativi
Quando il taglio non basta, lo storico diventa un blocco di stato: cosa è stato fatto, quali file sono stati toccati, quali comandi sono passati, cosa resta aperto. Gli identificativi esatti restano, le descrizioni lunghe no. Un riassunto che perde un percorso o un codice di errore costringe il modello a rifare il lavoro, e il risparmio di token si paga in passaggi.
La cache premia il prefisso stabile
La cache colpisce solo il prefisso identico: system prompt, schemi dei tool, istruzioni. Se il system prompt contiene la data corrente, l'elenco dei file in ordine casuale o l'identificativo del task, il prefisso cambia a ogni chiamata e lo sconto non arriva mai. Su deepseek-flash la differenza è di cinquanta volte sull'input, quindi l'ordine delle righe è una scelta economica.
Quanto pesano gli schemi
node -e "const bytes=3655,budget=200000,t=Math.round(bytes/4);console.log('tool schemas',t,'tokens',((100*t)/budget).toFixed(1)+'% of budget')"Il comando stampa tool schemas 914 tokens 0.5% of budget. Nove tool sono irrilevanti su 200.000 token; cinquanta tool con descrizioni lunghe cambiano la proporzione e vanno misurati con lo stesso conto. La stima a quattro caratteri per token serve a decidere, non a fatturare.
La limitazione
Nessuna ripartizione sopravvive a un task che cambia forma: un agente che legge un repository intero sposta tutto sui documenti, uno che corregge un test spende quasi tutto in output dei tool. La compressione perde dettagli che sembravano inutili, e la cache si rompe appena una riga in testa cambia. Il budget va rimisurato sul campo usage, non stimato a occhio.
Dove continuare
L'aritmetica dei prezzi per fascia è in contesto lungo: costi reali, l'ordine dei passi in orchestrare agenti multi-step, la scrittura del system prompt in prompt per agenti. Il catalogo che alimenta gli esempi è in 111.985 componenti e 1.556 blocchi; un record citabile è agent dock di dqnamo.
Domande frequenti
Meglio una finestra da 1M token o un contesto corto?
Il contesto corto vince quasi sempre sul costo: ogni passaggio ripaga l'intero prompt. Una finestra da 1M token serve quando il task richiede davvero un documento intero, non come sostituto della selezione dei file.
Quando conviene compattare lo storico?
Quando il prossimo passo rischia di superare il budget, non quando la finestra è piena. Meglio compattare al 70-80% del budget dichiarato, così resta spazio per una chiamata di tool e per la risposta.
Cosa taglio per primo?
Gli output vecchi dei tool, i log e i file riletti per intero. Sono dati che il modello ha già usato e che può ricostruire da un comando; gli identificativi e i codici di errore sono l'ultima cosa da togliere.
La compressione peggiora la qualità?
Può peggiorarla se perde percorsi, nomi di funzione o messaggi d'errore. Un buon riassunto conserva gli identificativi esatti e riassume solo le descrizioni: il modello deve poter continuare senza rileggere tutto.
Perché la cache non si attiva mai?
Perché il prefisso cambia. Una data, un elenco in ordine casuale o un identificativo nella prima riga invalidano la cache a ogni chiamata. Tieni stabile la testa del prompt e sposta i dati variabili in fondo.