Una guida pubblicata da MachineLearningMastery.com analizza sette errori ricorrenti nella progettazione di agenti AI che fanno lievitare il consumo di token, dal contesto che cresce senza limiti al JSON grezzo inserito così com'è nel prompt. Per ciascun errore la guida propone una correzione architetturale, utile a chiunque sviluppi o faccia manutenzione di sistemi basati su modelli linguistici.
In breve
- Il problema più diffuso è trattare la finestra di contesto come un archivio permanente, invece che come un payload temporaneo da inviare a ogni richiesta.
- I risultati grezzi di API esterne (JSON annidato, log verbosi) possono consumare migliaia di token inutili se non vengono ripuliti prima di entrare nel prompt.
- Interrogare interi file o documenti per rispondere a una domanda puntuale spreca token che un recupero mirato eviterebbe.
- Cicli di ragionamento senza limiti, schemi di strumenti statici e l'uso di modelli costosi per compiti semplici sono altre tre fonti di spreco.
- Una parte consistente del costo riguarda anche i token in uscita, spesso gonfiati da testo conversazionale non necessario attorno ai dati richiesti.
Perché un agente AI consuma più token del previsto?
Un agente AI consuma più token del previsto quando il suo contesto — cioè l'insieme di testo inviato al modello a ogni richiesta — accumula informazioni che non servono più al compito in corso. Secondo la guida, la distinzione chiave è tra contesto, il payload di token effettivamente inviato a ogni chiamata, e stato, la rappresentazione duratura dell'avanzamento dell'agente. Quando i due concetti vengono confusi, si finisce per "pagare" a ogni chiamata anche la lettura di dati che andrebbero conservati altrove, in un database o in una memoria persistente, e richiamati solo quando servono.
Questo errore di fondo spiega perché, in un sistema che funziona bene durante un weekend di prototipazione, i costi possano iniziare a salire in modo brusco una volta in produzione, man mano che le conversazioni si allungano.
Cosa succede quando il contesto diventa un archivio infinito?
Quando ogni messaggio, osservazione e risposta vengono semplicemente accodati al prompt, il contesto cresce turno dopo turno senza che nulla venga mai rimosso. La guida descrive questo pattern come "append-only trap": dopo una ventina di scambi, l'agente rilegge l'intera cronologia operativa a ogni richiesta, con un costo di attenzione che cresce in modo più che proporzionale e una latenza che aumenta di conseguenza.
Il rimedio indicato è una finestra di contesto scorrevole (sliding window) abbinata a una sintesi semantica progressiva: si passano al modello solo gli ultimi turni nella loro forma originale, mentre quelli più vecchi vengono compressi in un riassunto denso, e lo stato strutturale dell'agente viene spostato in un archivio deterministico come SQLite o Redis invece di essere reiniettato nel prompt. L'avvertenza è che la sintesi è per natura lossy: se l'agente ha bisogno di identificativi esatti, hash o frammenti di codice generati nei primi turni, la compressione rischia di "inventarli". Per questo conviene affiancare uno strumento di ricerca puntuale che recuperi le stringhe esatte quando la precisione è indispensabile. Questa architettura è indicata come impostazione predefinita per qualsiasi agente conversazionale di lunga durata o ciclo di ragionamento iterativo destinato a superare i cinque-dieci turni.
Perché il JSON grezzo delle API fa esplodere i costi?
Il JSON grezzo restituito dalle API esterne fa esplodere i costi perché è pensato per essere letto da macchine, non da un modello linguistico, e spesso contiene molti più dati di quelli realmente utili al ragionamento. Un singolo payload proveniente da un servizio come Stripe o da una risposta AWS verbosa può occupare migliaia di token, la maggior parte dei quali inutili per l'agente.
La correzione proposta è uno strato middleware inserito tra l'esecuzione dello strumento e l'inserimento nel contesto: questo livello elimina i valori nulli, filtra le chiavi non essenziali e trasforma il JSON annidato in YAML o Markdown strutturato, più compatto e più leggibile per il modello. Per i log, un passaggio di pre-elaborazione deterministico può rimuovere timestamp, identificativi di thread e informazioni ripetitive prima che il modello veda i dati. L'avvertenza è che un filtraggio troppo aggressivo può eliminare metadati necessari, come i cursori di paginazione: se l'agente deve scorrere un elenco di risultati, togliere per errore il campo che indica la pagina successiva blocca silenziosamente l'intero ciclo di recupero. Questa tecnica è utile ogni volta che si integrano API di terze parti che restituiscono payload verbosi.
Come evitare di leggere interi file o documenti per una sola domanda?
Si evita leggendo solo le porzioni di testo realmente pertinenti, invece di recuperare un intero file o documento quando serve una singola informazione. Negli agenti di coding e nei sistemi basati su recupero di documenti (RAG), un errore frequente è usare una ricerca testuale grezza e poi inserire nel contesto l'intero file trovato: se l'agente ha bisogno di una sola funzione, l'orchestratore può finire per recuperare un file di migliaia di righe.
La guida suggerisce un recupero strutturato e consapevole della sintassi (ad esempio tramite alberi di sintassi astratta, AST): durante l'indicizzazione il codice viene analizzato in un grafo di chiamate, e quando l'agente cerca una funzione l'orchestratore restituisce solo la firma, la documentazione e le dipendenze dirette — poche centinaia di token invece di un intero file. L'avvertenza è che questo tipo di recupero richiede pipeline di indicizzazione continue e asincrone: se l'indice rimane indietro rispetto al codice reale, l'agente ragiona con sicurezza su uno stato obsoleto, tentando di chiamare funzioni che non esistono più.
Quali altri errori fanno sprecare token agli agenti AI?
Oltre ai tre descritti sopra, la guida individua altri quattro pattern che incidono sui costi in modo spesso meno visibile ma altrettanto concreto.
| Errore | Effetto | Correzione proposta |
|---|---|---|
| Schemi degli strumenti sempre attivi | Con decine di strumenti registrati, il modello legge ogni volta migliaia di token di definizioni, molte irrilevanti per il compito in corso | Potatura degli strumenti in base allo stato operativo dell'agente, gestita da una macchina a stati finiti |
| Cicli di ragionamento senza limiti | Un tentativo fallito che si ripete indefinitamente può generare decine di migliaia di token in output, in genere fatturati a un tasso più alto di quelli in input | Un "interruttore" a livello di orchestratore, con numero massimo di tentativi e budget di token per azione |
| Prefissi di prompt non ottimizzati | Inserire variabili dinamiche (timestamp, ID utente) all'inizio del prompt impedisce ai provider di riutilizzare la cache dei prefissi già elaborati | Struttura del prompt a gradiente statico-dinamico: contenuti fissi in cima, variabili sempre dopo |
| Uso di modelli costosi per compiti semplici | Impiegare un modello di fascia alta per classificare intenti o estrarre dati semplici è sproporzionato rispetto al compito | Instradamento a cascata: un modello piccolo e veloce gestisce i compiti semplici, il modello avanzato interviene solo quando serve ragionamento complesso |
Vale la pena notare che alcune di queste correzioni sono in tensione tra loro: la potatura dinamica degli strumenti riduce i token ma interferisce con la cache dei prefissi, mentre massimizzare la cache richiede di mantenere visibili anche schemi non immediatamente rilevanti. La guida indica che il bilanciamento corretto dipende dalla dimensione del registro di strumenti, dal volume di richieste e dall'implementazione di caching del provider usato, e che l'unico modo affidabile per trovare il punto di equilibrio è osservare le tracce reali del sistema in produzione.
Esistono errori di spreco meno conosciuti?
Sì, la guida ne segnala due che non compaiono in molte checklist ma incidono comunque sui costi. Il primo riguarda i token in uscita: quando si chiede a un agente di estrarre dati strutturati, come un nome e un'email, senza imporre un formato di output vincolato, il modello tende a generare testo introduttivo prima dei valori veri e propri — un costo che si accumula su migliaia di chiamate. Usare modalità di output strutturato native dei provider, o schemi basati su strumenti, elimina questa categoria di spreco.
Il secondo riguarda l'iniezione ridondante di contesto: è frequente trovare la stessa informazione inserita più volte — una nel prompt di sistema, una come promemoria in un turno recente, una terza come conferma del risultato di uno strumento. Ogni copia costa token e, se una versione viene aggiornata mentre un'altra resta ferma, l'agente deve conciliare informazioni discordanti. Un controllo che garantisca a ogni fatto un solo punto di inserimento può ridurre il totale dei token in ingresso del 10-20%, senza perdita di qualità nelle risposte.
Domande frequenti
Lo spreco di token è solo un problema di costi? No: secondo la guida, un contesto sovraccarico si traduce anche in maggiore latenza di inferenza e in una superficie più ampia per errori di recupero e allucinazioni. Limitare il contesto al minimo necessario per il compito rende il comportamento dell'agente più prevedibile.
Qual è l'errore più diffuso tra quelli descritti? Trattare la finestra di contesto come un archivio permanente, accodando ogni messaggio e osservazione senza mai comprimerli o rimuoverli, è indicato come il pattern più diffuso e tra i più costosi nei sistemi di agenti in produzione.
Perché i token in output pesano di più di quelli in input? Perché, come segnalato nella guida, la maggior parte dei provider fattura i token generati in output a un tasso più alto rispetto a quelli ricevuti in input: un ciclo di ragionamento bloccato o un output non vincolato possono quindi incidere più del previsto sul costo complessivo.
Quando conviene usare un modello più piccolo invece di uno avanzato? Conviene nei sistemi con input prevedibili e ad alto volume, dove compiti strutturali come la classificazione di intenti o l'estrazione di dati semplici possono essere separati in modo netto dal ragionamento complesso, che resta riservato al modello di fascia più alta.
Fonti
- 7 Ways Your AI Agent Is Wasting Tokens (And What to Do Instead) - MachineLearningMastery.com, di Vinod Chugani, 30 ottobre 2026.
Se questi temi riguardano da vicino un progetto di automazione o un agente AI che la tua azienda sta valutando, puoi approfondire cosa significa progettare applicazioni AI su misura oppure raccontare la tua esigenza attraverso la pagina contatti di iNexus.