🤖 AI

Context as an Environment: Programmatic Context Management for Long-Horizon Agents

Il documento introduce Scroll, un sistema di gestione del contesto programmatico che tratta le sessioni degli agenti come ambienti eseguibili con un registro degli eventi append-only e un kernel Python persistente, consentendo agli LLM di gestire dinamicamente lo stato a lungo termine attraverso il codice e raggiungendo prestazioni allo stato dell'arte nei benchmark a lungo contesto.

Autori originali: Yin Lin, Elaine Ang, Erkang Zhu, Bolin Ding, Jingren Zhou

Pubblicato 2026-08-25

📖 6 min di lettura🧠 Approfondimento

CC BY 4.0

Autori originali: Yin Lin, Elaine Ang, Erkang Zhu, Bolin Ding, Jingren Zhou

Articolo originale sotto licenza CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Questa è una spiegazione generata dall'IA dell'articolo qui sotto. Non è stata scritta né approvata dagli autori. Per precisione tecnica, consulta l'articolo originale. Leggi il disclaimer completo

Immagina una conversazione che non finisce mai. Stai parlando con un programma per computer molto intelligente, uno che può aiutarti a scrivere codice, pianificare viaggi complessi o ricercare argomenti profondi. All'inizio, la conversazione è facile. Il programma ricorda tutto ciò che hai detto negli ultimi minuti. Ma man mano che la conversazione si protrae per ore o giorni, la quantità di informazioni cresce. Alla fine, diventa troppo per il programma da contenere nella sua memoria immediata. Nel mondo dell'intelligenza artificiale, questa memoria immediata è chiamata finestra di contesto. È di dimensioni fisse, come una scrivania che può contenere solo un certo numero di fogli. Quando la pila di fogli diventa troppo alta, il programma deve scartarne alcuni per fare spazio ai nuovi.

Il problema è che il programma non sa quali fogli siano importanti finché non è troppo tardi. Se fai una domanda su qualcosa che hai menzionato tre giorni fa, il programma potrebbe aver già scartato quel foglio. Le soluzioni tradizionali cercano di risolvere questo problema cercando di riassumere i vecchi fogli in una breve nota o scegliendo alcuni fatti da tenere in un taccuino separato. Ma questi metodi sono rischiosi. Se il programma scarta un dettaglio specifico, come una data o un numero, quel dettaglio è perso per sempre. Non può essere recuperato. Per compiti che richiedono di guardare indietro a una lunga cronologia per trovare fatti esatti o per tracciare come una situazione sia cambiata nel tempo, perdere anche un singolo dettaglio può causare il fallimento del programma.

Un team di ricercatori ha proposto un modo diverso per gestire questa conversazione crescente. Chiamano il loro sistema Scroll. Invece di cercare di far entrare l'intera cronologia nella memoria immediata del programma, trattano la cronologia come un ambiente separato e permanente che il programma può visitare ogni volta che ne ha bisogno. Immagina un vasto archivio organizzato che siede proprio fuori dalla scrivania del programma. Il programma non legge l'intero archivio in una volta sola. Inveve, scrive una piccola istruzione, come una query di ricerca o un comando, per andare nell'archivio, trovare la pagina specifica di cui ha bisogno e portare solo quella pagina sulla scrivania.

Il cuore di questo sistema è un registro permanente di ogni singola interazione, chiamato Event Log (Registro degli Eventi). Questo registro è come un registratore che non si ferma mai, catturando ogni messaggio, ogni risultato di uno strumento e ogni decisione con estremo dettaglio. È conservato in sicurezza al di fuori della memoria immediata del programma, in modo che nulla vada perduto. Accanto a questo registro c'è uno spazio di lavoro persistente, una sorta di sandbox digitale dove il programma può conservare i suoi pensieri e i suoi calcoli attuali. Quando il programma ha bisogno di ricordare qualcosa dal passato, non si affida a un riassunto. Scrive un pezzo di codice per cercare nell'Event Log, trovare l'esatto momento che sta cercando e caricare quell'informazione nel suo spazio di lavoro.

Questo approccio cambia il modo in cui il programma pensa alla propria memoria. Inveve di indovinare cosa tenere, il programma decide cosa cercare nel momento in cui ne ha bisogno. Se il programma sta pianificando un viaggio e ha bisogno di ricordare una preferenza che l'utente ha menzionato settimane prima, scrive un comando per cercare quella specifica preferenza. Carica quindi le parole esatte usate dall'utente e le usa per prendere una decisione. Il programma porta nella propria visuale immediata solo l'informazione necessaria. Il resto della cronologia della conversazione rimane conservato in sicurezza nell'archivio, in attesa di essere recuperato se il programma ne avrà bisogno più tardi.

Per evitare che la visuale immediata si riempia troppo, il sistema ha un modo per eliminare le informazioni vecchie che non vengono utilizzate correntemente. Quando lo spazio di lavoro diventa affollato, il sistema sposta le parti più vecchie della conversazione nuovamente nell'archivio. Tuttavia, a differenza di altri sistemi che potrebbero eliminare o riassumere queste vecchie parti, Scroll le mantiene esattamente come sono. Crea una piccola mappa, un indice, che dice al programma esattamente dove sono conservate quelle vecchie parti nell'archivio. Se il programma in seguito si rende conto di aver bisogno di controllare una vecchia conversazione, può usare questa mappa per saltare direttamente nel punto giusto e recuperare il testo originale. Ciò assicura che il programma possa sempre tornare alla fonte, anche se l'informazione non è più nella sua visuale immediata.

I ricercatori hanno testato questo sistema su diverse sfide difficili progettate per vedere quanto bene un'intelligenza artificiale possa gestire lunghe conversazioni. In un test, il sistema doveva rispondere a domande basate su una cronologia di oltre un milione di parole di conversazione. In un altro, doveva agire come un agente che prende decisioni su un lungo periodo, usando strumenti per raccogliere informazioni e risolvere problemi. I risultati hanno mostrato che questo nuovo metodo è stato altamente efficace. In un test che misurava quanto bene il sistema potesse ricordare e ragionare su lunghe cronologie, ha ottenuto un punteggio del 94,8 percento. In un altro test che coinvolgeva dieci milioni di parole di cronologia, ha ottenuto il 73,1 percento, che è superiore a qualsiasi altro sistema precedentemente pubblicato. In un test in cui il sistema doveva gestire un ambiente in crescita mentre risolveva compiti complessi, ha raggiunto l'86,7 percento, superando di gran lunga i migliori risultati precedenti.

Il successo di questo sistema deriva dalla sua capacità di trattare la memoria come un compito di programmazione. Consentendo al programma di scrivere le proprie istruzioni per trovare e utilizzare le informazioni, il sistema sfrutta la crescente capacità del programma di scrivere codice. Non costringe il programma a comprimere la sua cronologia in un riassunto che potrebbe perdere dettagli importanti. Inveve, gli fornisce gli strumenti per accedere alla cronologia completa e non editata ogni volta che ne ha bisogno. I ricercatori hanno scoperto che questo metodo funziona bene attraverso diversi tipi di programmi potenti, suggerendo che la capacità di gestire la memoria a lungo termine attraverso il codice è una competenza generale che può essere appresa da vari sistemi.

Questo lavoro suggerisce un cambiamento nel modo in cui costruiamo gli agenti intelligenti. Piuttosto che cercare di rendere la memoria immediata del programma più grande o migliore nel riassumere, possiamo darle accesso a un registro permanente e ricercabile della sua stessa vita. Il programma impara a navigare in questo registro, decidendo cosa portare in avanti e cosa lasciare indietro. Questo mantiene la visuale immediata chiara e focalizzata, garantendo al contempo che l'intera verità del passato sia sempre disponibile. I ricercatori ritengono che questo approccio possa aiutare l'intelligenza artificiale a gestire compiti ancora più lunghi e complessi in futuro, permettendole di imparare da una storia molto più profonda senza perdere i dettagli che contano.

Riepilogo Tecnico: Scroll – Gestione Contestuale Programmatica per Agenti a Lungo Orizzonte

1. Formulazione del Problema

I compiti a lungo orizzonte per gli agenti basati su Large Language Model (LLM) — come l'ingegneria del software a livello di repository o la ricerca web approfondita — generano cronologie di interazione che superano di gran lunga la finestra di contesto di un singolo modello. Le soluzioni esistenti si affidano principalmente alla compressione del contesto (troncare, riassumere o scartare segmenti obsoleti) o alla memoria esterna (estrarre fatti in un archivio separato). Entrambi gli approcci sono fondamentalmente lossy (con perdita di informazioni): si impegnano su quali informazioni preservare prima che le necessità future siano note. Di conseguenza, se un riassunto non riesce a catturare un dettaglio specifico o se un'estrazione manca di una sfumatura, quell'informazione diventa irrecuperabile, anche se il log grezzo esiste su disco. Questo limite impedisce agli agenti di eseguire confronti storici esatti o computazioni non triviali su eventi passati in cui l'informazione richiesta non è nota in anticipo.

2. Metodologia: Il Framework Scroll

Il documento introduce Scroll, un gestore di contesto che riformula la cronologia della sessione non come testo da serializzare nei prompt, ma come un Ambiente di Sessione Eseguibile. Questo ambiente consente all'agente di interagire programmaticamente con la propria cronologia.

Componenti Core

Log degli Eventi Append-Only ( $L_t$ ): Un registro durevole e di verità fondamentale di tutte le interazioni (messaggi dell'utente, risposte del modello, chiamate a strumenti, risultati). Ogni evento riceve un indirizzo di sequenza (seq) immutabile e monotonicamente crescente. Il log è memorizzato in SQLite, utilizzando BM25 per una ricerca full-text deterministica anziché gli embedding.
Storage Durabile ( $P_t$ ): I payload grezzi (ad esempio, output completi degli strumenti, artefatti) sono archiviati esternamente (JSON, file system) e referenziati dal Log degli Eventi tramite handle differiti. Ciò garantisce che il log rimanga leggero preservando al contempo l'intera fedeltà.
Kernel Python Persistente ( $V_t$ ): Un kernel Python in sandbox persiste attraverso le chiamate del modello. Mantiene un namespace tipizzato di variabili residenti (oggetti Python, DataFrame, handle differiti). Fondamentalmente, i calcoli intermedi e i risultati degli strumenti rimangono in questo kernel e non vengono serializzati nel prompt a meno che non venga esplicitamente richiesto.

Interfaccia Programmatica

Il modello costruisce il proprio contesto scrivendo codice eseguito all'interno del kernel persistente. L'interfaccia, esposta tramite un oggetto di capacità ms, suddivide la costruzione del contesto in quattro operazioni:

LOCATE: ms.search(query, k, ...) trova i record candidati nel Log degli Eventi tramite ricerca full-text e filtri strutturati, restituendo indirizzi seq stabili.
MATERIALIZE: ms.expand(seq) recupera turni o segmenti esatti e carica i payload esterni come oggetti Python.
COMPUTE: Il modello esegue filtraggio, join, aggregazione e derivazione utilizzando Python standard e interfacce di database consentite sulle variabili residenti.
EXPOSE: print(value) è l'unico meccanismo che attraversa il confine verso la vista di lavoro del modello. Solo le proiezioni esplicitamente stampate entrano nel contesto successivo del modello.

Evizione e Navigazione

Quando la vista di lavoro si avvicina al budget di token, Scroll impiega una procedura di evizione che rimuove i segmenti obsoleti dalla vista, ma mai dal Log degli eventi.

Recuperabilità: Gli eventi evitti rimangono intatti nel Log degli Eventi.
Indice di Evizione: Per evitare la necessità di ricerche nell'intero log, Scroll mantiene un indice a più livelli di "titoli" (task, stato, azione successiva) per i segmenti evitti. Questo indice permette all'agente di navigare direttamente nelle regioni evitte utilizzando ancoraggi di indirizzo, raggruppando le voci più vecchie in intervalli più ampi per mantenere una complessità $O(k \log k n)$ .

3. Contributi Chiave

Il documento presenta tre contributi primari:

Politica di Selezione Differita: A differenza dei metodi esistenti che fissano la mappa del contesto prima che le necessità future siano note, Scroll differisce la selezione della vista di lavoro al tempo della query. Il modello scrive un programma $\pi_t$ ad ogni step per decidere cosa richiamare, calcolare ed esporre.
Substrato di Contesto Eseguibile: L'implementazione di un kernel Python persistente e in sandbox combinato con un Log degli Eventi append-only. Questo sposta la gestione del contesto dall'elaborazione del testo alla programmazione, sfruttando le capacità di codifica dell'LLM per cercare, trasformare e materializzare lo stato.
Algoritmo di Navigazione Lossless: Un meccanismo di evizione che mantiene limitata la vista di lavoro senza perdere la cronologia. I segmenti evitti rimangono intatti e sono indicizzati tramite voci compatte ancorate all'indirizzo, permettendo all'agente di navigare direttamente nelle regioni evitte invece di cercare l'intero log.

4. Risultati Sperimentali

Gli autori hanno valutato Scroll utilizzando Qwen3.8-Max come backbone attraverso tre benchmark:

LongMemEvalS (Recupero della Memoria a Lungo Termine): Scroll ha raggiunto il 94,8% di accuratezza, performando in modo competitivo con i sistemi allo stato dell'arte.
BEAM10M (Cronologia di 10M di Token): Scroll ha raggiunto il 73,1%, superando il miglior sistema di memoria pubblicato di 5,1 punti. Eccelle notevolmente nelle categorie che richiedono prove storiche esatte, come l'aggiornamento della conoscenza (92,5%) e la risoluzione delle contraddizioni (88,1%), dove la summarizzazione lossy solitamente fallisce.
LOCA256K (Acting a Lungo Orizzonte): Scroll ha raggiunto l'86,7% di accuratezza. In confronto diretto con altre strategie di gestione del contesto utilizzando lo stesso backbone, Scroll ha dimostrato una stabilità superiore all'aumentare del contesto, con una riduzione di solo il 2,6% da 128K a 256K token, rispetto ai cali di circa il 21% per gli agenti di summarization e retrieval.

Gli studi di ablazione hanno confermato che il Log degli Eventi lossless è critico (la sua rimozione ha causato un calo a circa il 20% su BEAM10M), il kernel persistente migliora le prestazioni di 7,3 punti abilitando l'aggregazione in-kernel, e l'indice di evizione fornisce un guadagno di 1,8 punti facilitando la navigazione in cronologie frammentate.

Efficienza dei Costi: Scroll espone solo una piccola frazione del corpus al modello. Su BEAM10M, il conteggio mediano dei token di input era di circa 105K (circa l'1% del corpus), con i token di output di un ordine di grandezza inferiori.

5. Significato e Rivendicazioni

Il documento sostiene che Scroll cambia fondamentalmente la gestione del contesto da un problema di compressione a un compito di programmazione. Trattando la sessione come un ambiente eseguibile, l'agente eredita le crescenti capacità di codifica degli LLM per gestire dinamicamente il proprio contesto.

Gli autori sottolineano che Scroll non detta quale stato mantenere o come scrivere il codice di recupero; queste decisioni sono lasciate al modello. Questa flessibilità permette al sistema di scalare con le capacità del modello. Il documento suggerisce che le traiettorie di successo possono essere distillate dai modelli frontier verso modelli più piccoli tramite fine-tuning supervisionato, mantenendo fissi i meccanismi di contesto sottostanti.

Il lavoro postula che per compiti a lungo orizzonte che richiedono prove storiche esatte o computazioni complesse su eventi passati, il recupero lossless tramite accesso programmatico è superiore alla summarization pre-calcolata o ai sistemi di memoria fissi, poiché evita la perdita irreversibile di informazioni inerente ai paradigmi di compressione attuali.