Conosci il meccanismo per aggiungere un "secondo cervello" a Codex in modo che il contesto rimanga anche se la conversazione viene interrotta? Il suo nome è Agentmemory. Ho riassunto tutto, dalla procedura di installazione e configurazione alle insidie più comuni. È una lettura obbligata per chi trova noioso dover spiegare sempre la stessa cosa e per chi non vuole sprecare token.
Ogni mattina, avvio Claude Code e digito "Continua da ieri", solo per sentirmi rispondere "Per favore, fornisci il contenuto della sessione precedente". È un fenomeno che capita quasi ogni giorno.
Nel momento in cui una sessione viene interrotta, il contesto del progetto viene resettato. Sebbene quanto scritto in CLAUDE.md venga letto, il "peso del contesto"—come le discussioni su un bug di tre giorni fa o le motivazioni alla base di una policy di progettazione decisa la settimana scorsa—scompare del tutto.
Uno sviluppatore ha scritto:
per impostazione predefinita, sul tuo computer vengono salvati solo 30 giorni della cronologia delle sessioni di Claude Code; devi impostare un periodo più lungo se vuoi avere memoria su tutte.
Il periodo di conservazione predefinito per la cronologia delle sessioni è di 30 giorni. Inoltre, ciò che viene salvato è solo un "record sotto forma di stringa", non un meccanismo che può essere richiamato come contesto.
Sostanzialmente è la stessa cosa sul lato Codex. Il contesto di GPT-5.5 è di 1 milione di token tramite API e di 400.000 in Codex CLI. La dimensione fisica sembra sufficiente, ma in pratica, la precisione inizia a diminuire intorno ai 200.000 token.
È qui che entra in gioco Agentmemory, che ha fatto notizia dopo aver superato le 4.000 Stelle. Lo uso intensamente da una settimana. Ecco la mia conclusione:
L'espressione "aggiungere memoria infinita" a Codex/Claude Code è per metà un'iperbole e per metà una verità.
In questo articolo, spiegherò come massimizzare la parte di "verità" e come evitare la parte di "iperbole" quando la incontri.
1. Perché Codex/Claude Code soffrono di "amnesia"?
Prima di parlare di Agentmemory, lasciami chiarire perché gli strumenti esistenti non sono sufficienti. Se saltiamo questo passaggio, si finisce solo con "ho aggiunto uno strumento di memoria comodo" e si perde l'essenza.
Anche se la finestra di contesto è grande, in pratica non può essere sfruttata appieno.
A partire da maggio 2026, le finestre di contesto dei modelli principali sono le seguenti:
● Claude Opus 4.7: 1 milione di token (espanso da 200.000)
● GPT-5.5: 1 milione di token (API) / 400.000 token come limite in Codex CLI
● Gemini 3.1 Pro: 1 milione di token
In termini di caratteri giapponesi, si tratta di circa 1,41 milioni di caratteri. È una capacità sufficiente per contenere non solo un libro, ma un'intera serie. A guardare i numeri, sembra che "tutto ci stia".
Tuttavia, Anthropic stessa ha scritto nel suo blog tecnico ufficiale:
All'aumentare del numero di token nella finestra di contesto, diminuisce la capacità del modello di richiamare accuratamente le informazioni da quel contesto.
La capacità fisica non equivale alla capacità di mantenere la precisione. L'esperienza dimostra che intorno ai 200.000-400.000 token, Claude inizia a "dimenticare ciò che ha appena detto". Questo è comunemente noto come degrado del contesto.
Il "crollo del pensiero" che si è verificato persino nel Claude Code ufficiale
Lascia che ti faccia un esempio reale. Il 23 aprile 2026, Anthropic ha pubblicato ufficialmente un'analisi post-mortem.
Un bug distribuito il 26 marzo faceva sì che la "funzione per cancellare i vecchi pensieri dopo 1 ora di inattività" si attivasse a ogni turno anche dopo aver ripreso una sessione.
Di conseguenza, la lunghezza mediana del pensiero visibile è cambiata come segue:
● Gennaio: 2.200 caratteri
● Marzo: 600 caratteri
Un crollo del 73%. Per circa un mese, il Claude Code ufficiale ha tagliato arbitrariamente il proprio contesto.
Questo è importante perché dimostra che il degrado del contesto non è solo un "errore dell'utente", ma può verificarsi anche a causa di circostanze dal lato del servizio. Non importa quanto pulitamente tu scriva CLAUDE.md, una singola regolazione di ottimizzazione dal lato dello strumento può trasformare "il contesto della settimana scorsa" in carta straccia.
Limiti delle soluzioni esistenti (CLAUDE.md / auto-memory)
Anthropic sta adottando misure. La funzionalità auto-memory di Claude Code è un meccanismo che ricorda ciò che è stato appreso tra le sessioni e lo richiama al riavvio. Il team di Claude Code lo ha annunciato a maggio.
Tuttavia, questo è strutturato per funzionare in tandem con la compattazione. Esegue un flusso interno di "compressione del contesto → spostamento delle informazioni importanti nella memoria", e l'IA decide "cosa mantenere" durante ogni compressione. Gli utenti non possono toccare questa logica decisionale.
Inoltre, l'auto-memory è esclusivo di Claude Code. Non esiste un'API per leggerlo da altri agenti come Codex, Cursor, Cline o Hermes. Per coloro che utilizzano più agenti, la situazione in cui devi "spiegare la stessa premessa tre volte" diventa la norma.
2. Cosa Rende Diverso Agentmemory
Ora passiamo all'argomento principale. Agentmemory (repo ufficiale: rohitg00/agentmemory) è un motore di memoria open-source che ha raggiunto 8.8k Stelle al 15 maggio 2026. È più che raddoppiato rispetto al report iniziale di "4.000+ Stelle". È concesso in licenza Apache 2.0, basato su TypeScript, e l'ultima release è la v0.9.12 (13 maggio). È completamente self-hosted con zero dati inviati a SaaS esterni.
Filosofia dello Sviluppatore
Lo sviluppatore principale Rohit Ghumare (@ghumare64) ha riassunto l'essenza di Agentmemory in una frase:
L'ho costruito 6 mesi fa con agentmemory: memoria persistente per agenti di codifica IA. Stessa idea centrale: smetti di ridefinire, inizia a compilare.
"Smetti di ridefinire, inizia a compilare." Questa è la differenza filosofica rispetto agli strumenti esistenti.
CLAUDE.md era un "input da ridefinire ogni volta". Struttura del progetto, convenzioni, decisioni passate. L'IA li rileggeva, re-interpretava e poi li dimenticava a ogni sessione. Agentmemory cambia tutto ciò sostituendo il "ciclo di ridefinizione" con un "livello di memoria compilata".
Architettura a 3 Livelli (Riepilogo dal README)
Secondo il README ufficiale, la struttura interna è divisa in tre fasi:
Il primo è Capture (Acquisizione). Utilizza 12 hook del ciclo di vita di Claude Code per acquisire i dati automaticamente, quindi non è necessario eseguire manualmente memory_save.
Il secondo è Pipeline (Pipeline). Organizza le osservazioni attraverso un flusso di deduplicazione → filtro privacy (rimozione automatica di chiavi API/PII) → compressione basata su IA.
Il terzo è Retrieval (Recupero). Fonde tre tipi di ricerca ibrida (BM25 / vettoriale / grafo) utilizzando RRF k=60. BM25 gestisce keyword stemmer ed espansione di sinonimi, il vettoriale gestisce la similarità coseno degli embedding densi, e il grafo gestisce la traversata del grafo di conoscenza. Fondendoli con Reciprocal Rank Fusion, se un metodo non trova qualcosa, l'altro lo recupera. I risultati vengono restituiti con dispersione tra le sessioni (massimo 3 per sessione), risolvendo il problema di ottenere risultati solo dalla stessa sessione.
Memoria a 4 livelli (Ispirata da Ebbinghaus)
Un altro aspetto interessante è il design che divide la memoria in quattro livelli che "crescono" nel tempo.
Il livello inferiore è Working (Lavoro), che è la memoria a breve termine come osservazioni grezze dell'esecuzione degli strumenti, log degli errori e cronologia dei comandi. Salendo al livello Episodic (Episodico), diventano riassunti di sessione di "cosa è successo". A livello Semantic (Semantico), si trasforma in "ciò che so", conoscenza estratta e modelli. Il livello superiore è Procedural (Procedurale), che consiste in flussi di lavoro e procedure su "come procedere".
I ricordi a cui si accede frequentemente vengono rafforzati, mentre quelli non referenziati decadono secondo la curva dell'oblio di Ebbinghaus. È un meccanismo modellato sulla struttura della memoria umana. Questa è la vera natura di "smetti di ridefinire e inizia a compilare".
Posizionamento Rispetto ai Concorrenti
Ad essere onesti, guardando solo le Stelle su GitHub, Agentmemory è ancora piccolo rispetto ai concorrenti.
● Mem0: 55,7k Stelle, livello di memoria per scopi generali, prima API/Cloud
● Letta (ex MemGPT): 22,7k Stelle, sistema operativo per agenti, gestione del contesto virtuale
● Agentmemory: 8,8k Stelle, specializzato per agenti di codifica, SQLite locale
Perde in un confronto numerico. Tuttavia, il punto di forza di Agentmemory è la sua specializzazione per agenti di codifica e il design disaccoppiato. Lo stesso Rohit ha scritto:
Se vuoi un'architettura di memoria estesa reale, cross-agente, portatile, non bloccata su un particolare agente, dai un'occhiata ad agentmemory. È progettato come un livello di memoria disaccoppiato che funziona su diversi harness.
Puoi connetterti a Cursor, Cline, Claude Code, Codex e Hermes usando la stessa memoria. Questa è la differenziazione da Mem0 e Letta. Mem0 è troppo generale e ha una debole acquisizione automatica per i contesti di codifica, mentre Letta è un sistema operativo per agenti, rendendo difficile estrarre solo il livello di memoria.
Agentmemory centra perfettamente il bersaglio della nicchia di "sviluppatori che utilizzano più agenti di codifica simultaneamente."
3. Avvio in 3 Minuti — Installazione e Configurazione Iniziale
Passiamo alla pratica. Il flusso di base è lo stesso per Mac, Linux e Windows, purché tu abbia un ambiente Node.js.
Passo 1: Avvia il Server di Memoria
Apri semplicemente un terminale ed esegui questo comando:
Avvia il server di memoria (tienilo in esecuzione)
npx @agentmemory/agentmemory
La prima volta ci vogliono 1-2 minuti per scaricare le dipendenze. Una volta completato con successo, un'API REST si avvierà su http://localhost:3111. Puoi verificarne lo stato con:
curl http://localhost:3111/agentmemory/health
→ {"status":"ok","version":"0.9.12"}
Si avvia anche un visualizzatore, quindi puoi visualizzare il contenuto della memoria aprendo http://localhost:3113 nel tuo browser.
Passo 2: Inserisci Dati Dimostrativi
È difficile visualizzare qualcosa con contenuti vuoti, quindi aggiungiamo dati di esempio.
Esegui in un terminale separato
npx @agentmemory/agentmemory demo
Questo scrive una cronologia di sessione fittizia in SQLite, rendendola osservabile nel visualizzatore.
Passo 3: Integrazione in Claude Code
Il modo più rapido dal lato di Claude Code è tramite il marketplace dei plugin.
Esegui all'interno di Claude Code
/plugin marketplace add rohitg00/agentmemory
/plugin install agentmemory
Questo registra automaticamente quanto segue:
● 12 hook (tutti i cicli di vita inclusi SessionStart / PostToolUse / Stop)
● 4 skill (recall / consolidate / export / governance)
● 51 strumenti MCP (AGENTMEMORY_TOOLS=all per tutto, l'impostazione predefinita è 15 strumenti core)
Passo 4: Integrazione in Codex CLI
Codex segue uno stile simile.
codex plugin marketplace add rohitg00/agentmemory
codex plugin install agentmemory
Per Codex, AGENTMEMORY_URL=http://localhost:3111 viene impostato automaticamente come variabile d'ambiente. Nota che Codex è più severo sulla sincronicità MCP rispetto a Claude Code, quindi darà errore immediatamente se il server è giù. Non dimenticare di tenerlo in esecuzione.
Passo 5: Collegamento a Cursor / Cline, ecc.
Per usarlo tramite Cursor, aggiungilo a ~/.cursor/mcp.json:
{
"mcpServers": {
"agentmemory": {
"command": "npx",
"args": ["-y", "@agentmemory/mcp"],
"env": { "AGENTMEMORY_URL": "http://localhost:3111" }
}
}
}
Cline, Hermes e altri editor compatibili con MCP si collegano con lo stesso schema. C'è una trappola: le impostazioni MCP di Cursor non vengono aggiornate semplicemente chiudendo e riaprendo; approfondirò questo aspetto nella sezione "5 Insidie".
Passo 6: Rituale di Health Check
Dopo la configurazione, ecco la checklist obbligatoria:
1. Connettività del server di memoria
curl http://localhost:3111/agentmemory/health
2. Controlla la versione di iii-engine (richiesta v0.11.2)
iii --version
3. Controlla la memoria nel visualizzatore
Se vedi osservazioni registrate nel visualizzatore, la configurazione è riuscita. Se Node.js è già installato, ci vogliono meno di 3 minuti.
4. Le 3 Azioni Fondamentali — Salva, Cerca, Auto-Compressione
L'utilizzo di Agentmemory può essere organizzato in tre azioni principali.
Azione 1: Salva (L'Acquisizione Automatica è l'Impostazione Predefinita)
In Mem0 o Letta, è normale salvare usando comandi manuali come memory_add(...). Agentmemory ha una filosofia diversa: acquisisce tutto automaticamente usando 12 hook.
Ad esempio, le seguenti osservazioni vengono registrate senza che tu faccia nulla:
● Comandi e output durante l'esecuzione dello strumento Bash (hook PostToolUse)
● Differenze prima e dopo la modifica dei file (hook PreToolUse / PostToolUse)
● Iniezione automatica della memoria correlata all'avvio della sessione (hook SessionStart)
● Compressione del riepilogo alla fine della sessione (hook Stop)
Il valore più grande è che l'"onere per l'utente di decidere cosa salvare" diventa zero. Mentre prima pensavamo "questo è importante, scriviamolo" o "cancelliamo questo" in CLAUDE.md, qui l'idea è di lasciare quella logica decisionale all'IA.
Puoi anche salvare manualmente. Chiamando memory_save tramite uno strumento MCP, puoi marcare esplicitamente "questo è importante". È più sicuro salvare manualmente le decisioni di progettazione critiche piuttosto che affidarsi esclusivamente all'acquisizione automatica.
Azione 2: Cerca (Ibrido a 3 Sistemi + RRF)
La ricerca viene effettuata tramite strumenti MCP o chiamando direttamente l'API REST. Ecco gli strumenti MCP rappresentativi:
● memory_recall — Recupera la memoria correlata usando il linguaggio naturale
● memory_smart_search — Versione completa della ricerca ibrida
● memory_sessions — Elenca per sessione
● memory_timeline — Ordina per tempo
● memory_relations — Attraversamento del grafo delle entità correlate
Se chiami direttamente l'API REST:
Cerca "correzione precedente relativa all'autenticazione Supabase"
curl -X POST http://localhost:3111/agentmemory/search \
-H "Content-Type: application/json" \
-d '{"query": "correzione autenticazione supabase", "limit": 5}'
I risultati restituiti sono una fusione di BM25 / vettoriale / grafo utilizzando RRF k=60. La latenza è inferiore a 20ms a P50 (veloce perché è SQLite locale).
La precisione nei benchmark ufficiali (LongMemEval-S, 500 domande, ICLR 2025) è la seguente:
● R@5: 95.2% (Probabilità che la risposta corretta sia tra i primi 5 candidati)
● R@10: 98.6%
● MRR: 88.2%
Nota che questa è "precisione di ricerca", non "precisione QA end-to-end". È la probabilità che la risposta corretta sia tra i candidati; se Claude la usi per rispondere correttamente è una questione separata. Non fare eccessivo affidamento confondendo le due cose.
Azione 3: Auto-Compressione (Crescita di 4 Livelli nel Tempo)
Ogni volta che l'hook Stop viene eseguito, tre fasi di compressione avvengono in ordine:
Primo, Working → Episodic comprime i log grezzi degli strumenti in riepiloghi di sessione. Successivamente, Episodic → Semantic estrae "modelli" e "conoscenza" da eventi di sessioni multiple. Infine, Semantic → Procedural consolida i passaggi ripetuti frequentemente in "flussi di lavoro".
Questo risolve automaticamente il problema di "salvare tutto e creare rumore nella ricerca". Il budget di token iniettato all'avvio della sessione è di 2.000 token per impostazione predefinita. Questo è progettato per ripristinare il "contesto precedente" in una forma necessaria e sufficiente.
5. Flusso di Lavoro per l'Utilizzo Combinato di Codex / Claude Code
Ora passiamo all'applicazione pratica. Per coloro che usano seriamente sia Codex che Claude Code, ecco tre schemi di flusso di lavoro.
Schema 1: Flusso Quotidiano per Sviluppo Individuale
Tenendo il server agentmemory in esecuzione, l'hook SessionStart si attiva quando Claude Code si avvia, iniettando automaticamente la memoria Episodic del giorno precedente. Anche senza dire "Continua da ieri", la conversazione inizia con Claude che ha già capito "Continuiamo la discussione sull'essere bloccati con Supabase RLS".
Durante la codifica, l'hook PostToolUse continua a scrivere comandi, output e differenze in SQLite. Quando la sessione viene chiusa, l'hook Stop comprime Working in Episodic. La mattina dopo, questo viene letto automaticamente, completando il ciclo.
Schema 2: Gestione di Progetti Multipli
Agentmemory può dividere la memoria in tre ambiti. L'ambito user (utente) è legato all'individuo, contenente "abitudini personali" come le preferenze delle convenzioni di codifica. L'ambito project (progetto) è gestito separatamente per ogni progetto, con file SQLite separati. L'ambito local (locale) rimane solo su quella macchina e non esce nemmeno in modalità di condivisione di team.
Modificando la variabile d'ambiente in AGENTMEMORY_PROJECT=foo-app quando si cambia progetto, viene referenziato un file SQLite diverso. Questo è incredibilmente efficace per le persone che gestiscono più progetti in parallelo. Il fenomeno per cui le decisioni di progettazione del Progetto A influenzano le discussioni per il Progetto B capitava spesso con CLAUDE.md. Con Agentmemory, sono fisicamente separati, quindi non c'è interferenza.
Schema 3: Condivisione di Team e Sviluppo Congiunto con Aziende Quotate
Attualmente co-sviluppiamo agenti IA con aziende quotate, e la modalità di condivisione del server MCP è sottilmente efficace in questo contesto. Impostando il flag collab=true, più istanze di Codex / Claude Code possono referenziare lo stesso server di memoria.
Lato server
AGENTMEMORY_COLLAB=true npx @agentmemory/agentmemory --bind 0.0.0.0
Referenziandolo tramite una VPN di team, più persone possono lavorare condividendo la "memoria dello stesso progetto". Tuttavia, il filtro privacy deve essere impostato rigorosamente. Se chiavi API o informazioni personali vengono mescolate, verranno condivise con tutto il team, quindi le impostazioni di esclusione in .agentmemoryignore sono obbligatorie. Ne parlerò nella sezione "Insidie".
Insidie Uniche dell'Utilizzo Combinato
Quando si passa da Codex a Claude Code sullo stesso progetto, la memoria è condivisa, ma la sintassi dei prompt è diversa. Il comando /plugin di Claude Code non funziona in Codex, e codex plugin install di Codex non funziona in Claude Code. Anche se è uno "strumento che funziona per entrambi", le impostazioni sono richieste individualmente. Molte persone si bloccano qui nella prima settimana.
6. Come Leggere i Benchmark — Tradurre i Numeri in "Esperienza Pratica"
Tradurrò i numeri ufficiali in sensazioni pratiche.
La Verità Dietro la "Riduzione del 92% dei Token"
La "riduzione del 92%" pubblicizzata in flash news e articoli Medium è su base di singola sessione.
● Operazione manuale convenzionale con CLAUDE.md: circa 22.000 token per sessione
● Tramite Agentmemory: circa 1.900 token per sessione
● Tasso di riduzione: circa 91-92%
I token di iniezione del contesto all'inizio di una sessione sono drasticamente ridotti. Su base annuale, i numeri cambiano, e la tabella Token Savings nel README dice:
● Operazione riassunta da LLM: circa 650.000 token / anno (circa $500 / anno)
● Agentmemory: circa 170.000 token / anno (circa $10 / anno)
In termini di token, si tratta di una riduzione di circa il 74%, ma in termini di costo, si tratta di una riduzione del 98%. Da $500 a $10. Il motivo della differenza è che Agentmemory viene eseguito su SQLite locale + embedding locali. A differenza di Mem0 o Letta, che eseguono la compressione basata su LLM ogni volta, il costo operativo è minimo.
Cosa Significa "LongMemEval-S R@5 95.2%"
LongMemEval-S è un benchmark di memoria a lungo termine rilasciato a ICLR 2025 (500 domande, circa 48 sessioni per domanda, circa 115.000 token di contesto). Confronto dei principali strumenti:
Strumento | R@5 |
|---|---|
Agentmemory | 95.2% |
Mem0 (Nuovo algoritmo, aprile 2026) | 94.8% |
Letta | 83.2% |
Cognee | 72.5% |
Zep | 71.0% |
Mem0 (Vecchio algoritmo) | 68.5% |
Mem0 si sta avvicinando con il suo nuovo algoritmo, quindi non è corretto parlare di "vittoria schiacciante" basandosi solo sui numeri. Tuttavia, dato che Agentmemory raggiunge il 95.2% in combinazione con un meccanismo di acquisizione automatica specializzato per agenti di codifica, la valutazione attuale è che si trova in un'ottima posizione per il trade-off "precisione vs. carico operativo".
Per ribadire, R@5 è la precisione di ricerca, non la probabilità che Claude o Codex diano alla fine la risposta corretta. Confondere questi aspetti porta a una sopravvalutazione.
Codex 400K vs Opus 4.7 1M: "Fisico vs. Pratico"
Osservando i numeri dei benchmark, ho notato un altro punto importante.
Claude Opus 4.7 ha espanso il suo contesto a 1 milione di token. Anche GPT-5.5 è a 1 milione di token tramite API. A guardare solo questo, sembra che "non abbiamo più bisogno di strumenti di memoria".
Tuttavia, Codex CLI è in realtà limitato a 400.000. Il limite fisico e il limite pratico sono disallineati. Inoltre, come ha scritto la stessa Anthropic, il degrado del contesto inizia a 200.000-400.000 token all'aumentare del contesto.
In altre parole, anche se la dimensione fisica aumenta, la necessità di un motore di memoria non diminuisce. Piuttosto, "come utilizzare efficientemente un'ampia finestra di contesto" è diventata una nuova sfida tecnica.
7. 5 Insidie — Mine Antipersona su Cui Sono Realmente Inciampato
Sarò onesto qui. Ecco 5 mine su cui sono inciampato mentre lo facevo funzionare realmente, che non compaiono nel README ufficiale o nei tweet degli influencer. Ho selezionato solo quelle riproducibili dalle Issues di GitHub.
Insidia 1: Mismatch di Versione di iii-engine v0.11.2
Subito dopo la configurazione, alcuni ricevono questo errore:
iii: comando non trovato
Oppure
Mismatch di versione: prevista v0.11.2, ottenuta v0.11.0
Agentmemory dipende internamente da un binario chiamato iii-engine, e la versione è bloccata sulla v0.11.2. Se un'altra versione è già installata, fallisce nella fase di avvio. La soluzione alternativa è recuperare la versione fissa dalle release per ogni sistema operativo.
macOS arm64
curl -fsSL https://github.com/iii-hq/iii/releases/download/iii/v0.11.2/iii-aarch64-apple-darwin.tar.gz \
chmod +x ~/.local/bin/iii
Linux x64
curl -fsSL https://github.com/iii-hq/iii/releases/download/iii/v0.11.2/iii-x86_64-unknown-linux-gnu.tar.gz \
Verifica
iii --version # Dovrebbe mostrare v0.11.2
Se salti questo passaggio, tutto il resto fallirà in seguito, quindi supera prima questo ostacolo.
Insidia 2: Issue #181 — Produzione Massiva di Sessioni Fantasma tramite Ciclo Infinito
Questa è seriamente pericolosa. Un bug fatale segnalato nella v0.9.1 in cui chiamare /summarize dall'hook Stop senza una chiave API impostata causa la generazione infinita di sessioni figlie.
Hook Stop → /summarize → Sessione figlia generata
↓
Anche l'hook Stop della sessione figlia si attiva → /summarize → Altre sessioni figlie
↓
(Ciclo infinito)
C'è una segnalazione nella Issue #181 di GitHub di circa 579 sessioni fantasma generate in pochi minuti. Ci sono tre soluzioni alternative:
Opzione 1: Disabilita la modalità agent-sdk (Consigliata)
export AGENTMEMORY_ALLOW_AGENT_SDK=false
Opzione 2: Forza un errore con una chiave API fittizia
export AGENTMEMORY_ANTHROPIC_API_KEY="fake-key"
Opzione 3: Imposta una chiave API reale
export AGENTMEMORY_ANTHROPIC_API_KEY="sk-ant-..."
Per uso in produzione, l'Opzione 1 o 3 è sicura. L'Opzione 2 è solo per il primo giorno in cui "vuoi solo farlo funzionare".
Insidia 3: Issue #159 — MCP e API REST in Esecuzione su KV Separati
Questo è un altro fenomeno che ti lascia perplesso se non lo conosci. La chiamata a uno strumento MCP (come memory_search) restituisce risultati vuoti ogni volta, mentre l'API REST (POST /agentmemory/search) trova risultati con gli stessi dati.
API REST: GET /agentmemory/sessions → 69 osservazioni
Strumento MCP: memory_sessions → [] (vuoto)
La causa è che il pacchetto @agentmemory/mcp e il server Agentmemory sono progettati per avere archivi KV completamente separati (Issue #159). MCP è "KV locale" e il server è "un altro KV", senza un percorso di comunicazione tra di loro. A maggio 2026, l'issue rimane aperta. Le soluzioni alternative sono:
● Opzione 1: Usa direttamente l'API REST (tramite curl o fetch invece degli strumenti MCP)
● Opzione 2: Disabilita temporaneamente l'hook /mcp ed esegui solo il server
Ci sono piani per risolvere questo in futuro, ma per ora, devi lavorare intorno a questa specifica.
Insidia 4: MCP Non Riflesso in Cursor / VSCode
Hai modificato ~/.cursor/mcp.json e riavviato Cursor, ma Agentmemory non appare in /mcp list. Questo accade non solo con Cursor, ma in generale con le app di Windows Store.
Chiudere con il pulsante "X" della GUI lascia in esecuzione il processo in background di WindowsApps per impostazione predefinita. Il vecchio processo continua a funzionare con le vecchie impostazioni in memoria. È richiesto un rituale di terminazione completa.
macOS
pkill -9 Cursor
Windows PowerShell (Esegui come amministratore)
Windows (Cerca "Gestione attività" e termina manualmente tutti i processi di Cursor)
Dopo la terminazione forzata, riavvia Cursor e /mcp list ora dovrebbe riflettere le modifiche.
Insidia 5: MCP di Cline che Si Inceppa sulle Richieste di Approvazione
Questo è un problema nella modalità di piano di Cline. Cline richiede l'approvazione dell'utente per l'esecuzione dello strumento ogni volta che un agente chiama uno strumento MCP come memory_recall. Se imposti alwaysAllow su true in ~/.config/Code/User/globalStorage/saoudrizwan.claude-dev/settings/cline_mcp_settings.json, la richiesta di approvazione scompare.
Tuttavia, questo vale solo per gli ambienti Cline. In Hermes, la richiesta di approvazione è disabilitata per impostazione predefinita, quindi è più fluido. Se usi Cline in produzione, questa impostazione è obbligatoria.
8. Riassunto: Iniziare da Qui
• Linea di partenza: npx @agentmemory/agentmemory + installa il plugin. Ci vogliono 3 minuti.
• Costo: circa $10/anno. Con SQLite locale, i costi operativi sono minimi.
• Primo ostacolo: Versione di iii-engine v0.11.2. Se non allinei questo, tutto il resto si blocca.
• Secondo ostacolo: MCP vs REST API su KV separati (Issue #159). Per ora, usa l'API REST.
• Scenario killer: Utilizzo simultaneo di agenti di codifica multipli come Codex, Claude Code e Cursor. La capacità di condividere la stessa memoria tra strumenti diversi è difficile da replicare.
• Da non perdere: Aggiungi collab=true se lavori in team. Ma il filtro privacy è obbligatorio.
• Non fraintendere: R@5 al 95.2% è la precisione del recupero. Non la precisione finale della risposta dell'agente.
• Non esagerare: Il contesto di 1 milione di token è grande, ma in pratica il degrado del contesto e i limiti di Codex CLI (400K) sono reali. La necessità di un motore di memoria non scompare.
E questa è la vera natura di "aumentare la memoria di Codex/Claude Code".
open /Applications/Cursor.app
Windows (PowerShell)
→ Riavvia
Se imposti "verifica dei processi residui" come prima mossa prima di dubitare del file di configurazione, risparmierai tempo qui.
Insidia 5: Osservazioni eliminate silenziosamente dal filtro privacy
Il fenomeno per cui "il server è in esecuzione, ma le osservazioni non appaiono nel visualizzatore" si verifica spesso anche nella prima settimana. Guardando i log, vedrai avvisi come questo:
[warn] observation dropped: private_tag detected
[warn] observation dropped: private_email detected
Questo è voluto, non un bug. Il filtro privacy di Agentmemory rileva automaticamente chiavi API, password, indirizzi email e PII, e scarta quelle osservazioni senza registrarle. È un'ottima funzionalità per la sicurezza, ma se non lo sai, penserai che "non funzioni". La strategia di convivenza è:
Escludi per file usando .agentmemoryignore
echo ".env" >> .agentmemoryignore
echo ".env.local" >> .agentmemoryignore
echo "*/.key" >> .agentmemoryignore
echo "*/password*" >> .agentmemoryignore
Soprattutto quando esegui codice sperimentale che include chiavi API nelle osservazioni, è sicuro posizionare questo file in anticipo.
8. Riepilogo — "Memoria infinita" non è solo espansione della finestra di contesto
Dopo aver usato Agentmemory intensamente per una settimana, questa è la sensazione che mi ha colpito di più: L'espressione "memoria infinita" non riguarda l'espansione fisica della finestra di contesto.
Anche se aumentasse a 1 milione di token, se la precisione cala a 200K, alla fine è inutile. Sento che la gara delle dimensioni fisiche è già finita. Invece, ciò che Agentmemory ti permette di ottenere è un cervello esterno semantico.
Mantieni la memoria strutturata al di fuori della sessione, non al suo interno. Richiama solo ciò che ti serve quando ti serve, e chiudila quando hai finito. Le cose che vale la pena ricordare crescono nel tempo, mentre quelle che possono essere dimenticate decadono silenziosamente. È la stessa struttura di come gli umani usano la memoria.
Il cambiamento che avviene nella mente di uno sviluppatore può essere descritto in una frase: il passaggio da "finisce quando la sessione viene interrotta" a "la memoria cresce tra le sessioni".
L'intero settore si sta muovendo in questa direzione. Il corso sulla memoria degli agenti di DeepLearning.AI, il messaggio di Mem0 di "rendere gli agenti senza stato con stato", il paper MemGPT "LLMs as Operating Systems"—alla fine, tutto questo riguarda la memoria esterna, e Agentmemory è una soluzione nel contesto degli agenti di codifica.
Che si tratti di Mem0, Letta o di una tua implementazione, per chi usa seriamente Codex / Claude Code, è attualmente lo strumento più veloce per provare la "sensazione di memoria infinita". Francamente, vale la pena installarlo.
9. Informazioni su questo account
A chi ha letto fin qui: questo account @Codestudiopjbk è gestito da tre utenti hardcore di Codex.
● Partecipazione a programmi di sviluppo per dottorandi e postdoc
● Vinto 300.000 yen in premi
● Attualmente co-sviluppo di agenti AI con aziende quotate in borsa
I nostri contenuti abituali includono:
● Esempi di implementazione con GPT-5.5 / OpenAI Codex
● Utilizzo di Codex, automazione CLI e tendenze di sviluppo
● Traduzione e verifica delle ultime informazioni su GPT-5.5 / Codex dall'estero
● Confronti pratici con Claude Code (basati su centinaia di ore di utilizzo)
● Insegnamenti dallo sviluppo congiunto con aziende quotate
Pubblichiamo quotidianamente l'intero processo per portare un prodotto funzionante al mondo, dalla filosofia di sviluppo al design, implementazione e miglioramento. Se sei interessato, seguici e dai un'occhiata. Ne varrà la pena.
Per consulenze relative allo sviluppo, contattaci in DM. Sentiti libero di contattarci per introduzione a Codex, progettazione di automazione o implementazione di agenti AI.
Riferimenti e citazioni
● [Rohit Ghumare (rohitg00/agentmemory)] (2026-05-13) Agentmemory v0.9.12 — Memory Engine for Coding Agents — Repository ufficiale, Apache-2.0, 8.8k Stelle, TypeScript
● [Rohit Ghumare] (2026-04) "Built this 6 months ago with agentmemory: persistent memory for AI coding agents" — Filosofia dello sviluppatore
● [GitHub Issue #181] Stop-hook → /summarize → agent-sdk infinite recursion — Fonte principale per Insidia 2
● [GitHub Issue #159] Standalone MCP tools don't proxy to running agentmemory server — Fonte principale per Insidia 3
● [Anthropic Engineering] Effective Context Engineering for AI Agents — Guida ufficiale sull'ingegneria del contesto
● [Anthropic] (2026-04-23) April 23 Postmortem — Prova sociale dell'incidente del collasso della lunghezza di pensiero di Claude Code
● [Mem0] Introducing Mem0 — Filosofia di Mem0 e citazione di Taranjeet Singh
● [Letta] Benchmarking AI Agent Memory — Fonte per i numeri di benchmark di Letta
● [Charles Packer et al.] (2023-10) MemGPT: Towards LLMs as Operating Systems — Paper sulla gestione del contesto virtuale, predecessore teorico di Agentmemory
● [DeepLearning.AI] Agent Memory: Building Memory-Aware Agents — Corso di Andrew Ng / Oracle
