Note sur le champ d'application. Le MCP de Cryptohopper est conçu pour être sans état – chaque appel d'outil est indépendant, et le serveur ne conserve rien entre les requêtes. La mémoire réside du côté client ou dans un stockage que vous contrôlez. Ce guide porte sur cette couche.
Prérequis
Un client MCP avec une connexion fonctionnelle au MCP de Cryptohopper. Voir aperçu de la configuration.
Un endroit pour stocker des données. Cela peut être un fichier local, une base de données SQLite, un blob JSON stocké dans le cloud, ou un outil comme Notion. Aucune infrastructure requise pour commencer.
Qu'est-ce qui compte comme "mémoire"
Trois couches, chacune utile pour différentes raisons :
Couche | Exemple | Emplacement typique |
Mémoire de session | Au sein d'une conversation, le modèle se souvient de ce que tu as dit précédemment | La fenêtre de contexte du modèle (intégrée) |
Mémoire inter-exécutions | L'exécution de l'agent d'aujourd'hui se souvient de ce que l'exécution de la semaine dernière a observé | Fichier, base de données, Notion, etc. |
Profil utilisateur | L'agent connaît ta liste de surveillance, ta plateforme préférée, ta tolérance au risque | Identique à la mémoire inter-exécutions ; chargée au début de la session |
La mémoire de session est gratuite et automatique. La mémoire inter-exécutions et le profil utilisateur nécessitent que tu mettes en place un stockage.
Configuration – profil utilisateur
Rédige un court fichier markdown te décrivant en tant qu'utilisateur de crypto. Garde-le en dessous d'une page :
À propos de l'utilisateur
Trade principalement sur Binance.
Liste de surveillance : BTC, ETH, SOL, AVAX, ARB, OP, LINK, AAVE, UNI.
Détient en spot ; utilise des bots grid sur SOL et AVAX via Cryptohopper.
Se soucie davantage du risque de drawdown que de manquer une hausse.
Ne trade pas de perpétuels.
Défauts
Échange : Binance
Quote : USDT
Horizon temporel TA : 4h (200 barres)
Tolérance au risque : modérée
Préférences de prompt
Préfère les chiffres concrets aux adjectifs.
Signale la spéculation comme telle.
Si un ticker est ambigu, demande plutôt que de deviner.Charge-le au début de chaque conversation avec l'agent. Deux approches :
Copier-coller manuel : la première chose à faire dans chaque session, colle le fichier.
Intégré au client : utilise la fonction de mémoire persistante de ton client (projets Claude desktop, règles Cursor, contexte Zed) pour l'injecter automatiquement.
Garde le fichier petit. Tout ce qui dépasse environ 300 lignes devient du bruit que le modèle ignore. L'objectif est de définir les contraintes, pas de faire une autobiographie.
Versionne-le. Lorsque tu modifies ta liste de surveillance ou tes préférences, commite la modification dans git (ou l'historique Notion). Le comportement de ton agent changera avec le profil ; tu voudras savoir pourquoi.
Configuration – mémoire inter-exécutions (simple)
La mémoire inter-exécutions la plus simple est un seul fichier markdown que l'agent lit au début et auquel il ajoute à la fin :
Crée memory.md avec un squelette :
Mémoire de l'agent Observations récentes (Ajoute des entrées ici après chaque exécution.) Éléments en attente à surveiller (Choses que l'agent a signalées pour une attention future.) Décisions passées (Décisions notables et leur raisonnement.)
Au début de chaque exécution de l'agent, injecte le contenu du fichier :
[MÉMOIRE DE L'AGENT] {contenu de memory.md} [TACHE] Tâche d'aujourd'hui : exécuter le résumé quotidien.À la fin de chaque exécution, ajoute les nouvelles observations. Demande à l'agent de les produire explicitement :
Après avoir terminé la tâche, écris 2-4 lignes résumant tout ce qui est notable et qui vaut la peine d'être retenu pour la prochaine fois. Utilise ce format : [AAAA-MM-JJ] {observation} Exemples : [2026-05-27] Volume de SOL élevé pendant 3 jours consécutifs ; se maintient dans une fourchette d'environ 83-87. [2026-05-27] Liste de surveillance : LINK signalé comme calme mais vaut la peine d'être vérifié dans 7 jours. Je vais ajouter ces éléments à memory.md manuellement.Vérifie et élague périodiquement. Environ une fois par semaine, nettoie
memory.md– supprime les entrées obsolètes, consolide les tendances. Un fichier mémoire non géré grandit indéfiniment et devient du bruit.
Configuration – mémoire inter-exécutions (structurée)
Pour les agents qui bénéficient d'un historique interrogeable, une petite base de données SQLite fonctionne bien. Suggérons un schéma :
sql
CREATE TABLE observations (
id INTEGER PRIMARY KEY,
run_at TEXT NOT NULL, -- ISO-8601
agent_name TEXT NOT NULL, -- par exemple, "daily-digest"
category TEXT, -- par exemple, "volume-spike", "trend-change"
token TEXT, -- par exemple, "SOL"
content TEXT NOT NULL, -- le texte de l'observation
metadata JSON -- tout champ structuré
);
CREATE INDEX idx_run_at ON observations(run_at);
CREATE INDEX idx_agent_token ON observations(agent_name, token);
Cela te permet de poser des requêtes comme : « quelles observations avons-nous faites sur SOL au cours des 14 derniers jours ? » – et de donner la réponse à l'agent comme contexte pour l'exécution d'aujourd'hui.
L'agent écrit dans cette table via une petite aide 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()
Utilise cela avec parcimonie. La mémoire structurée ne vaut la peine d'être mise en place que si tu vas effectivement l'interroger ; pour un simple résumé, le fichier markdown est généralement suffisant.
Quoi mémoriser, quoi ne pas mémoriser
Bons candidats à mémoriser :
"SOL a évolué latéralement dans une bande de 83-87 pendant 5 jours" – contexte de la fourchette qu'une seule bougie journalière ne montrera pas lors de l'exécution de demain.
"Nous avons signalé une anomalie de volume sur LINK hier ; suivre aujourd'hui."
"L'utilisateur a posé une question sur les bots grid pour AVAX le 2026-05-20 ; les paramètres étaient X, Y, Z."
Mauvais candidats à mémoriser :
Données brutes du marché. Elles changent – récupère-les à nouveau du MCP plutôt que de faire confiance à un cache obsolète.
Transcriptions complètes de conversations. Le rapport signal/bruit est trop bas.
Résumés automatiques de chaque exécution. Sans curation, ils deviennent largement inutiles.
Un bon test : "si je supprime cette entrée de mémoire, l'agent se comportera-t-il moins bien la semaine prochaine ?" Si non, supprime-la.
Dépannage
L'agent cite une mémoire contredite par les données actuelles.
C'est le risque fondamental du contexte mis en cache. L'agent "se souvient" que SOL était en hausse, mais il s'est depuis inversé. Solution : instruis l'agent de toujours vérifier les affirmations de mémoire par rapport aux données MCP actuelles avant de les utiliser comme faits. "Avant de te fier à une entrée de mémoire, vérifie les données actuelles et signale si la mémoire est obsolète."
Les fichiers de mémoire deviennent ingérables.
Tu ajoutes sans élaguer. Définis une règle stricte : une fois par semaine, examine les entrées de la semaine dernière et supprime/fusionne. Ou fais pivoter les fichiers de mémoire mensuellement (memory-2026-04.md, memory-2026-05.md).
L'agent ignore le bloc de mémoire.
Le prompt n'oblige pas l'agent à l'utiliser. Sois explicite : "examine le bloc de mémoire ci-dessus avant de répondre. Référence les entrées spécifiques si pertinent. Si une entrée contredit des données fraîches, signale-le explicitement."
La mémoire introduit des réponses confiantes mais erronées.
L'agent traite la mémoire comme faisant autorité. Présente la mémoire comme des indices, pas comme des vérités : "la mémoire contient des observations passées ; traite-la comme un contexte, pas comme un fait. Vérifie toujours par rapport aux données actuelles."
Tu veux que l'agent mette à jour la mémoire sans ton intervention.
Possible mais risqué – une mémoire en mode ajout sans surveillance accumule des entrées erronées aussi vite que des bonnes. Si tu l'automatises, associe-la toujours à une étape de revue hebdomadaire. Ne laisse jamais la mémoire s'accumuler pendant un mois sans être lue.
La mémoire multi-agents devient confuse.
Si plusieurs agents partagent un fichier mémoire, utilise le champ agent_name pour nommer les entrées. Chaque agent ne lit que ses propres entrées, ou lit le fichier complet mais sait quel agent a écrit quelle ligne.
Le fichier de profil utilisateur devient obsolète. Les préférences changent. Si tu remarques que l'agent utilise par défaut un intervalle de temps ou une plateforme que tu n'utilises plus, mets à jour le profil – ne contourne pas cela avec des substitutions par prompt.