Nota sull'ambito. Il Cryptohopper MCP è stateless per design — ogni chiamata allo strumento è indipendente e il server non mantiene nulla tra le richieste. La memoria risiede sul client o in uno storage che controlli. Questa guida parla di quel livello.
Prerequisiti
Un client MCP con una connessione Cryptohopper MCP funzionante. Vedi panoramica della configurazione.
Un posto dove conservare i dati. Può essere un file locale, un database SQLite, un blob JSON memorizzato nel cloud o uno strumento come Notion. Nessuna infrastruttura richiesta per iniziare.
Cosa si intende per "memoria"
Tre livelli, ognuno utile per motivi diversi:
Livello | Esempio | Posizione tipica |
Memoria di sessione | All'interno di una conversazione, il modello ricorda quello che hai detto in precedenza | La finestra di contesto del modello (integrata) |
Memoria cross-run | L'esecuzione dell'agente di oggi ricorda ciò che l'esecuzione della scorsa settimana ha osservato | File, database, Notion, ecc. |
Profilo utente | L'agente conosce la tua watchlist, lo scambio preferito, la preferenza di rischio | Come la memoria cross-run; caricata all'inizio della sessione |
La memoria di sessione è gratuita e automatica. La memoria cross-run e il profilo utente richiedono di impostare lo storage.
Configurazione — profilo utente
Scrivi un breve file markdown che ti descrive come utente crypto. Tienilo sotto una pagina:
Informazioni sull'utente
Opera principalmente su Binance.
Watchlist: BTC, ETH, SOL, AVAX, ARB, OP, LINK, AAVE, UNI.
Detiene spot; esegue bot grid su SOL e AVAX tramite Cryptohopper.
Si preoccupa del rischio di drawdown più che di perdere opportunità.
Non opera su futures.
Impostazioni predefinite
Exchange: Binance
Quote: USDT
Intervallo TA: 4h (200 barre)
Tolleranza rischio: moderata
Preferenze di prompting
Preferisce numeri concreti rispetto agli aggettivi.
Segnala la speculazione come tale.
Se un ticker è ambiguo, chiede piuttosto che indovinare.Caricalo all'inizio di ogni conversazione con l'agente. Due approcci:
Incolla manuale: la prima cosa in ogni sessione, incolla il file.
Integrato nel client: usa la funzione di memoria persistente del tuo client (progetti desktop di Claude, regole di Cursor, contesto di Zed) per iniettarlo automaticamente.
Mantieni il file piccolo. Qualsiasi cosa oltre ~300 righe diventa rumore che il modello salta. Il punto sono i vincoli, non un'autobiografia.
Versiona. Quando cambi la tua watchlist o le tue preferenze, effettua il commit della modifica a git (o alla cronologia di Notion). Il comportamento del tuo agente cambierà con il profilo; vorrai capire perché.
Configurazione — memoria cross-run (semplice)
La memoria cross-run più semplice è un singolo file markdown che l'agente legge all'inizio e a cui aggiunge alla fine:
Crea memory.md con uno scheletro:
Memoria dell'agente Osservazioni recenti (Aggiungi voci qui dopo ogni esecuzione.) Oggetti in sospeso da monitorare (Cose che l'agente ha segnalato per attenzione futura.) Decisioni passate (Decisioni notevoli e il loro ragionamento.)
All'inizio di ogni esecuzione dell'agente, inietta il contenuto del file:
[MEMORIA AGENTE] {contenuti di memory.md} [COMPITO] Compito di oggi: eseguire il digest giornaliero.Alla fine di ogni esecuzione, aggiungi nuove osservazioni. Chiedi all'agente di produrle esplicitamente:
Dopo aver completato il compito, scrivi 2-4 righe riassumendo tutto ciò che è degno di nota e che vale la pena ricordare per la prossima volta. Usa questo formato: [AAAA-MM-GG] {osservazione} Esempi: [2026-05-27] Volume SOL elevato per 3 giorni consecutivi; si mantiene in un intervallo di circa 83-87. [2026-05-27] Watchlist: segnalato LINK come tranquillo ma vale la pena controllarlo tra 7 giorni. Aggiungerò manualmente queste informazioni a memory.md.Controlla e pota periodicamente. Una volta alla settimana circa, ritaglia
memory.md— elimina le voci obsolete, consolida i modelli. Un file di memoria non gestito cresce indefinitamente e diventa rumore.
Configurazione — memoria cross-run (strutturata)
Per gli agenti che beneficiano di uno storico interrogabile, un piccolo database SQLite funziona bene. Suggerimento schema:
sql
CREATE TABLE observations (
id INTEGER PRIMARY KEY,
run_at TEXT NOT NULL, -- ISO-8601
agent_name TEXT NOT NULL, -- es. "daily-digest"
category TEXT, -- es. "volume-spike", "trend-change"
token TEXT, -- es. "SOL"
content TEXT NOT NULL, -- il testo dell'osservazione
metadata JSON -- eventuali campi strutturati
);
CREATE INDEX idx_run_at ON observations(run_at);
CREATE INDEX idx_agent_token ON observations(agent_name, token);
Questo ti permette di fare query come: "quali osservazioni abbiamo fatto su SOL negli ultimi 14 giorni?" — e fornire la risposta all'agente come contesto per l'esecuzione di oggi.
L'agente scrive in questa tabella tramite un piccolo helper Python:
python
def log_observation(agent_name: str, category: str,
token: str, content: str) -> None:
conn.execute(
"INSERT INTO observations (run_at, agent_name, category, token, content) "
"VALUES (?, ?, ?, ?, ?)",
(datetime.utcnow().isoformat(), agent_name, category, token, content),
)
conn.commit()
Usalo con parsimonia. La memoria strutturata vale l'impostazione solo se la interrogherai effettivamente; per un semplice digest, il file markdown è solitamente sufficiente.
Cosa ricordare, cosa no
Buoni candidati per la memoria:
"SOL è in trend laterale in una banda 83-87 da 5 giorni" — contesto di range che una singola candela giornaliera non mostrerà nell'esecuzione di domani.
"Abbiamo segnalato LINK per un'anomalia di volume ieri; seguiamo oggi."
"L'utente ha chiesto informazioni sui bot grid per AVAX il 2026-05-20; i parametri erano X, Y, Z."
Scarsi candidati per la memoria:
Dati di mercato grezzi. Cambiano — ripescali dal MCP invece di fidarti di una cache obsoleta.
Trascrizioni complete della conversazione. Il rapporto segnale/rumore è troppo basso.
Riassunti automatici di ogni esecuzione. Senza cura, diventano per lo più inutili.
Un buon test: "se elimino questa voce di memoria, l'agente si comporterà peggio la prossima settimana?" Se no, eliminala.
Risoluzione dei problemi
L'agente cita una memoria contraddetta dai dati attuali.
Questo è il rischio fondamentale del contesto in cache. L'agente "ricorda" che SOL era in trend ascendente, ma nel frattempo si è invertito. Soluzione: istruisci l'agente a verificare sempre le affermazioni della memoria rispetto ai dati MCP attuali prima di usarli come fatti. "Prima di fare affidamento su una voce di memoria, controlla i dati attuali e segnala se la memoria è obsoleta."
I file di memoria diventano ingestibilmente grandi.
Stai aggiungendo senza potare. Stabilisci una regola ferrea: una volta alla settimana, rivedi le voci della settimana precedente e elimina / unisci. Oppure ruota i file di memoria mensilmente (memory-2026-04.md, memory-2026-05.md).
L'agente ignora il blocco di memoria.
Il prompt non richiede all'agente di utilizzarlo. Sii esplicito: "esamina il blocco di memoria sopra prima di rispondere. Fai riferimento a voci specifiche dove pertinente. Se una voce contraddice dati freschi, segnalalo esplicitamente."
La memoria introduce risposte fiduciose ma errate.
L'agente sta trattando la memoria come autorevole. Inquadra la memoria come suggerimenti, non come verità: "la memoria contiene osservazioni passate; trattala come contesto, non come fatto. Verifica sempre rispetto ai dati attuali."
Vuoi che l'agente aggiorni la memoria senza il tuo intervento.
Possibile ma rischioso — la memoria in sola scrittura non monitorata accumula voci errate tanto velocemente quanto quelle buone. Se la automatizzi, accoppiala sempre con un passaggio di revisione settimanale. Non lasciare mai che la memoria cresca per un mese senza essere letta.
La memoria multi-agente si confonde.
Se più agenti condividono un file di memoria, usa il campo agent_name per creare namespace per le voci. Ogni agente legge solo le proprie voci, o legge il file intero ma sa quale agente ha scritto quale riga.
Il file del profilo utente diventa obsoleto. Le preferenze cambiano. Se noti che l'agente utilizza impostazioni predefinite come intervallo temporale o exchange che non usi più, aggiorna il profilo — non aggirarlo con override per prompt.