Chi cucina per molte persone impara presto una regola che non sta nei libri di ricette: sul piano di lavoro deve esserci solo quello che serve adesso. Il resto sta negli scaffali, e sul frigorifero c’è un foglio con scritto dove si trova cosa. Un piano ingombro non rende il cuoco più informato, lo rende più lento, e prima o poi gli fa prendere il sale al posto dello zucchero. E le ricette che riescono vengono ricopiate su un quaderno, così la volta dopo non si riparte da zero.
È, quasi alla lettera, la tesi di GenericAgent: A Token-Efficient Self-Evolving LLM Agent via Contextual Information Density Maximization, depositato su arXiv il 18 aprile 2026 (2604.17091). Lo firma l’Advantage AI Agent Lab, un laboratorio congiunto fra l’Università Fudan e l’azienda Shenzhen Aquaintelling Technology; il progetto è guidato da Jiaqing Liang e Yanghua Xiao. Il sistema è open source, su github.com/lsdefine/GenericAgent.
Il problema: il contesto che si riempie da solo
Un agente che lavora a lungo accumula. Le descrizioni degli strumenti, i ricordi recuperati, l’output grezzo di ogni comando, le pagine web con tutto il loro HTML: ogni passo aggiunge testo, e il testo resta. Gli autori richiamano tre fenomeni noti. Un modello trova meno bene ciò che sta a metà di un contesto lungo; il materiale irrilevante non resta inerte ma distrae; e la lunghezza di contesto che un modello usa davvero è molto più corta di quella dichiarata. Messi insieme, dicono che oltre una certa soglia aggiungere contesto non migliora le decisioni e può peggiorarle.
Da qui il principio che dà il titolo al lavoro: massimizzare la densità di informazione del contesto, cioè quanta informazione utile alla decisione corrente c’è per ogni token. Il paper la scompone in due requisiti in tensione fra loro, la completezza (tutto ciò che serve deve esserci) e la concisione (niente di ciò che non serve), più un vincolo secondario di naturalezza: un riassunto troppo telegrafico o un formato artificiale il modello rischia di leggerlo peggio. La tensione, notano, non sparirebbe nemmeno con una finestra infinita: includere di più aiuta la completezza e danneggia la concisione, riassumere fa il contrario.
Perché un contesto più lungo non è un contesto migliore, e che cosa vuol dire progettare quello che il modello vede a ogni passo: il context engineering è il tema di un capitolo del libro, e qui lo si dà per noto.
Quattro scelte per un contesto sotto i 30.000 token
Nove strumenti. GenericAgent ne espone nove in tutto: leggere, scrivere e correggere file, eseguire codice Python o Bash, scansionare una pagina web ed eseguirvi JavaScript, due per la memoria e uno per chiedere all’utente. Per confronto, gli autori contano nel codice di Claude Code 53 strumenti predefiniti (20 di base e 33 condizionali) e in OpenClaw 18 fabbriche di strumenti. L’argomento è doppio: ogni strumento in più occupa prompt a ogni turno e allarga lo spazio delle azioni fra cui il modello deve scegliere. Anche i singoli strumenti sono disegnati per risparmiare: la correzione di un file fallisce se il testo da sostituire non compare o compare più di una volta, la scansione web clona la pagina, scarta gli elementi nascosti o coperti e, secondo gli autori, costa un ordine di grandezza meno del DOM grezzo.
Una memoria a quattro strati, di cui nel contesto entra di default solo il primo, con una breve mappa delle regole (figura). L1 è un indice: puntatori brevi, parole chiave, pochi vincoli rigidi. L2 contiene fatti verificati e stabili, L3 le procedure operative (le SOP, standard operating procedures) con i casi di errore e i rimedi, L4 l’archivio grezzo delle sessioni, che serve a ricostruire e verificare, non a essere letto a ogni passo. La regola d’ingresso è «No Execution, No Memory»: in L2 e L3 finisce solo ciò che un’esecuzione riuscita ha confermato, mai un’ipotesi o un ramo fallito. L’indice resta piccolo perché registra soltanto che un certo tipo di conoscenza esiste; a recuperarlo ci pensa il modello, con una chiamata a uno strumento.
L’auto-evoluzione è il nome, un po’ generoso, di un processo concreto: il modello non cambia, cambia l’ambiente informativo in cui lavora. A un traguardo raggiunto o dopo un errore recuperato, l’agente distilla la traccia in una SOP testuale; se la procedura si ripete, diventa uno script. Gli errori seguono una scala in tre gradini: prima una correzione locale, poi un cambio di strategia o una ricerca di informazioni mancanti, infine la richiesta di aiuto a una persona.
Il taglio del contesto, infine, lavora a quattro livelli. L’output di ogni strumento viene troncato tenendo inizio e fine (10.000 caratteri per il codice eseguito, per esempio). Circa ogni cinque turni una passata comprime i messaggi vecchi, lasciando intatti gli ultimi dieci. Quando la storia supera il budget si espellono i messaggi più vecchi finché non si scende sotto il 60 per cento. E dopo ogni chiamata a uno strumento viene riattaccata un’«ancora» con i riassunti di una riga degli ultimi venti turni e le informazioni chiave del compito. Non potendo contare i token con precisione, il sistema usa i caratteri:
$$C_H = \sum_{m \in H} \mathrm{len}(m) \;>\; B = \alpha \cdot W_{\text{token}}, \qquad \alpha \approx 3 \text{ caratteri per token}$$
dove $H$ è la storia della conversazione; per cinese, giapponese e coreano, avvertono gli autori, la stima sottovaluta i token e il contesto rischia di traboccare.
Il giro ragiona-agisci-osserva, gli strumenti descritti come schema JSON, la differenza fra memoria di lavoro e memoria a lungo termine: il ciclo dell’agente è costruito da capo nel libro.
I numeri
Sul confronto principale gli autori definiscono un’efficienza come accuratezza per milione di token consumati. Su Lifelong AgentBench, compiti in sequenza con dipendenze fra l’uno e l’altro, con Claude Sonnet 4.6 come modello per tutti: GenericAgent risolve il 100 per cento con 241.000 token, Claude Code il 75 con 814.000, OpenClaw il 70 con 1,45 milioni. Su SOP-Bench GenericAgent e OpenClaw arrivano entrambi al 100 per cento, ma fra le configurazioni con Sonnet è Claude Code, all’85, a spendere meno e ad avere l’efficienza migliore; e con MiniMax M2.7 OpenClaw supera GenericAgent, 95 a 90, spendendo però il triplo. Su RealFin, flussi di lavoro finanziari, GenericAgent fa 65 contro il 60 di Claude Code con Opus 4.6 e di Codex con GPT-5.4, il 55 di Claude Code con Sonnet e il 35 di OpenClaw.
Su cinque compiti lunghi e realistici (generare documenti, scrivere query SQL, decidere un acquisto cercando sul web) GenericAgent e Claude Code riescono entrambi in tutti e cinque, ma il primo usa 188.829 token contro 537.413, e 11 richieste al modello in media contro 32,6. Dopo l’installazione delle stesse 20 skill e un uso intensivo che il paper non quantifica, un semplice «Hello» costa a GenericAgent un prompt di 2.298 token; a Claude Code 22.821, a Codex 23.932, a OpenClaw 43.321.
La parte più interessante riguarda la memoria. In un’ablazione su un sottoinsieme di SOP-Bench, senza memoria il tasso di successo è del 13,9 per cento; con l’intera procedura originale, 575 token, sale al 52,4; con una versione condensata di 165 token arriva al 66,5, esattamente come una versione arricchita di definizioni e contesto che ne costa 288. Qui le spiegazioni in più non servono, e la procedura completa fa peggio del suo riassunto. Sulla memoria dei fatti a lungo termine (LoCoMo, un sottoinsieme) GenericAgent supera Mem0 e A-MEM in tutte e quattro le categorie senza usare né embedding né un database vettoriale.
E poi la ripetizione. Nove esecuzioni di una ricerca su GitHub, ogni volta su un’istanza nuova: dal primo al nono giro i token scendono da 222.203 a 23.010, le chiamate al modello da 32 a 5 (figura). Il guadagno, secondo gli autori, viene soprattutto dall’eliminazione di interi cicli di ragionamento, non da risposte più corte. Su otto compiti web ripetuti tre volte, le esecuzioni successive costano fra il 61 e il 92,4 per cento meno della prima; OpenClaw, nello stesso esperimento, non converge. Sulla navigazione web, con Claude Opus 4.6 per entrambi, GenericAgent batte OpenClaw su tutti e tre i banchi di prova, e su BrowseComp-ZH, ricerca a più salti nel web cinese, lo triplica: 0,60 contro 0,20, con circa un terzo dei token.
Che cosa va preso con cautela
I campioni sono piccoli: cinque compiti lunghi, dieci di BrowseComp-ZH, dodici di WebCanvas estratti a caso, accuratezze che si muovono a scatti di cinque punti. Non ci sono intervalli di confidenza, e non è chiaro quante esecuzioni stiano dietro ogni cella. Il 100 per cento contro il 75 su Lifelong AgentBench è un distacco netto; il 65 contro il 60 su RealFin, su numeri così, non lo è. Le configurazioni dei sistemi concorrenti le hanno scelte gli autori, che sono anche gli autori di GenericAgent, e su un sottoinsieme dei compiti web il giudizio è di un modello. L’auto-evoluzione è misurata sull’efficienza di compiti strutturalmente simili, non su quanto l’agente diventi capace di cose nuove.
L’unico elenco di limiti scritto dagli autori riguarda l’esplorazione autonoma: un tetto di trenta turni per compito, un meccanismo di adattamento dei pesi ancora senza dati di lungo periodo, un registro degli errori e un albero delle skill che richiedono cura manuale. E la sezione di discussione, lo scrivono loro, raccoglie osservazioni «distillate dalla pratica» più che da ablazioni controllate. Da leggere con questa avvertenza due affermazioni forti. Che meno token significhi migliori prestazioni: è una correlazione fra sistemi diversi, non un meccanismo dimostrato. E che «i permessi definiscono il tetto delle capacità», con la conclusione che restringere il perimetro d’azione produce un agente «sicuro ma inutile»: una posizione legittima, ma che va tenuta presente se si pensa di far girare sulla propria macchina un agente che esegue codice e, nell’esplorazione autonoma, si riattiva da solo ogni sei minuti (il paper assicura che lì i file restano in una cartella temporanea e segreti e codice sorgente sono vietati).
Perché conta adesso
Da un anno la corsa degli agenti si misura in finestre di contesto più grandi, cataloghi di strumenti più lunghi, memorie che ricordano tutto. GenericAgent è un argomento nella direzione opposta: circa 3.300 righe nel nucleo del codice, 92 per il ciclo principale, contro le circa 530.000 che gli autori contano in OpenClaw, e un budget di contesto volutamente piccolo. I singoli ingredienti non sono nuovi: la memoria a strati ricorda MemGPT, le skill verificate Voyager, la compattazione del contesto è pratica corrente nei prodotti commerciali. Il contributo è averli legati a un unico criterio di progetto e aver mostrato, con numeri ancora da replicare, che il criterio regge. Per chi costruisce agenti la morale è concreta: prima di aggiungere uno strumento o un ricordo, chiedersi che cosa toglie dal piano di lavoro.
I commenti sono riservati agli iscritti.
Accedi per commentare