Chiosa
IT
Software & Code

REM gestisce tempi e dettagli della memoria per gli agenti di coding

REM: What to Store, When to Recall, What to Forget in Experience Memory for Coding Agents · arXiv:2610.27377

4 min
Aggiornato
REM manages the memory lifecycle in three stages around the agent’s think-act loop. Left: the write path consolidates each completed trajectory into a phase-structured document (localize…
REM manages the memory lifecycle in three stages around the agent’s think-act loop. Left: the write path consolidates each completed trajectory into a phase-structured document (localize, understand, fix pattern, verify); the extraction fields come from a domain module…Figure 1 · REM: What to Store, When to Recall, What to Forget in Experience Memory for Coding Agents · Xinyi Lisa Chen et al. · CC BY 4.0

In parole semplici

Gli agenti di coding possono consultare registrazioni di lavori precedenti, ma una registrazione può essere troppo lunga o arrivare nel momento sbagliato per essere utile. Questo articolo presenta REM, un metodo che organizza ogni esecuzione passata in una breve guida e mostra le modifiche dettagliate solo dopo che l’agente fallisce il primo controllo.

Su 99 attività di bug fixing, REM ha risolto una quota maggiore di attività rispetto all’assenza di memoria in ciascuna delle tre esecuzioni. La differenza non è risultata statisticamente significativa nel test appaiato: è un’evidenza promettente per questo insieme di test, non una garanzia.

La ricerca

Quando un agente recupera una soluzione passata pertinente, come può evitare di distrarsi con troppi dettagli o con consigli che arrivano nel momento sbagliato? Le necessità dell’agente cambiano durante l’attività, mentre un sistema di recupero da solo non può osservare come procede il lavoro.

REM organizza le esecuzioni di coding passate in brevi guide e mostra le modifiche dettagliate solo dopo un controllo fallito, gestendo la memoria mentre l’agente lavora.

Gli autori hanno confrontato REM con l’assenza di memoria su 99 attività di bug fixing in repository, ripetendo tre volte ciascuna condizione con Claude Sonnet 4.5. Un’attività era considerata risolta quando la patch inviata superava i test del benchmark.

REM ha risolto in media il 27.6% delle attività, contro il 24.9% senza memoria, e ha risolto più attività in ogni replica.

REM ha usato anche meno token ponderati per costo per attività. Tuttavia, la differenza nel tasso di risoluzione non è risultata statisticamente significativa nel confronto appaiato.

Gli autori considerano quindi la direzione coerente osservata nelle diverse esecuzioni un’evidenza del possibile beneficio del ciclo di vita della memoria in questo contesto, non un miglioramento conclusivo della risoluzione.

Il principale confronto sui tassi di risoluzione non è risultato statisticamente significativo in un test appaiato, e la valutazione su cinque modelli prevedeva una sola esecuzione per modello.

I risultati riguardano un test set di bug fixing su un singolo repository e un insieme fisso di esecuzioni precedenti, non una memoria che si accumula attraverso esecuzioni ripetute.

Cosa mostrano le prove

  • Il recupero è solo il primo passo

    Reusable Experience Memory (REM) è un framework per agenti di coding che gestisce quali esperienze precedenti conservare, quando richiamarle e quando dimenticarle. La domanda è perché recuperare un’esecuzione correlata possa comunque non essere utile: le tracce grezze contengono percorsi abbandonati, mentre le necessità dell’agente che le riceve cambiano durante il lavoro. REM integra le decisioni sulla memoria nel ciclo di lavoro dell’agente.

  • Guida e dettagli separati

    REM trasforma ogni esecuzione di coding completata in un documento sintetico, organizzato per individuare un difetto, capirlo, correggerlo e verificare la correzione. Il documento viene recuperato all’inizio dell’attività successiva.

    Una registrazione dettagliata dell’implementazione della stessa esecuzione resta nascosta fino alla prima validazione fallita dell’agente, poi viene rimossa dopo una sola visualizzazione. In questo modo, la guida resta disponibile mentre i dettagli, più costosi, vengono mostrati in risposta a un segnale di difficoltà.

  • Risultato sulle attività, con cautela

    Gli autori hanno valutato REM su 99 attività di bug fixing in repository con Claude Sonnet 4.5, ripetendo tre volte sia la condizione REM sia quella senza memoria. Un’attività era considerata risolta se i test del benchmark venivano superati dalla patch dell’agente; un’esecuzione senza una patch applicabile era considerata non risolta.

    In media, REM ha risolto il 27.6% delle attività, contro il 24.9% senza memoria, e in ogni replica ha risolto più attività. Il confronto appaiato non è risultato statisticamente significativo (p=0.22).

  • La forma della memoria conta

    Per verificare se bastasse la pertinenza, gli autori hanno fornito riassunti e tracce grezze dell’esecuzione correlata identificata dal benchmark. Nei test, queste forme di riferimento non hanno aumentato il tasso di risoluzione rispetto all’assenza di memoria, mentre un documento organizzato per fasi, ricavato dalla stessa esecuzione identificata, ha risolto 26 delle 99 attività in una singola esecuzione.

    Un’analisi degli identificatori ha inoltre rilevato che quelli del documento REM comparivano più spesso nel testo degli agenti e negli input inviati agli strumenti rispetto a quelli dei riassunti o delle tracce grezze di riferimento, anche se la loro presenza non dimostra che siano stati usati in modo significativo.

  • La memoria dipende dall’agente

    Mantenendo invariato il documento recuperato, variare il momento in cui veniva mostrata la registrazione dettagliata e rimuoverla o meno non ha prodotto differenze appaiate statisticamente significative. Il solo documento ha ottenuto un risultato vicino a quello di REM completo.

    Tra cinque modelli di agente, il documento organizzato per fasi non ha ridotto la risoluzione nei tre con tassi senza aiuti pari o inferiori al 31.3%, mentre l’ha ridotta nei due sopra il 47%; ogni modello è stato eseguito una sola volta.

    Le evidenze indicano quindi che la forma della memoria e l’agente che la riceve possono essere rilevanti, ma non chiariscono quanto siano ampi o stabili questi effetti.

Dettagli

Paper successivoUn controllo nel controller può fermare comandi basati su uno stato non aggiornato