Mémoire de l'agent

1. Vue d'ensemble du concept et problème systémique

Sans mémoire systémique, chaque exécution d'un agent autonome est totalement isolée (stateless). Le modèle est limité par la taille physique de sa fenêtre de contexte (Context Window Limit) et, à la fin de la session, il perd toutes les conclusions tirées, les erreurs corrigées ainsi que les préférences utilisateur.

Tenter de résoudre ce problème « en force » — en envoyant l'intégralité de l'historique avant chaque prompt — conduit à trois impasses critiques sur le plan de l'ingénierie :

1. Croissance exponentielle des coûts en tokens et augmentation de la latence (Time to First Token).
2. Dégradation de l'attention du modèle (Lost-in-the-Middle) : un contexte surchargé dilue le mécanisme Self-Attention, provoquant l'omission d'instructions critiques.
3. Absence d'apprentissage par l'erreur : l'agent retombe dans les mêmes bugs de la base de code qu'il avait déjà résolus lors de sessions précédentes.

L'architecture Agent Memory sépare la persistance de l'état en niveaux spécialisés, offrant à l'agent une mémoire à long terme avec une consommation minimale de tokens.

2. Taxonomie architecturale et modèle mental

Dans l'ingénierie agentique moderne, la mémoire est standardisée en quatre couches fonctionnelles :

• 1. Mémoire à court terme (Working / Scratchpad Memory) : Tampon opérationnel de l'itération courante (boucle ReAct). Elle stocke les pensées intermédiaires (thoughts), les arguments des appels aux outils (tool calls) et les réponses de l'environnement système. Elle ne vit que durant le cycle de vie de la tâche actuelle (en mémoire process ou via Redis).
• 2. Mémoire épisodique (Episodic Memory) : Chronique de l'expérience passée de l'agent : séquences d'actions, tentatives d'exécution de tâches, causes d'échec des tests et correctifs trouvés. Cela permet à l'agent de se souvenir : « J'ai déjà tenté cette migration avec cette méthode hier, et cela a causé un deadlock — je choisirai une autre voie ».
• 3. Mémoire sémantique (Semantic Memory) : Base de connaissances extraites, de faits et d'entités concernant le monde extérieur, l'utilisateur et le repository. Elle est implémentée sous forme de base de faits structurée (Knowledge Graph) ou de base de données vectorielle avec embeddings.
• 4. Mémoire procédurale (Procedural Memory) : La « mémoire musculaire » de l'agent : algorithmes, workflows figés, syntaxe des outils personnalisés, règles de formatage du code et instructions système (incluant les fichiers .agents/skills et .agents/rules du repository).

3. Pipeline technique et mécanique interne

Le cycle de vie de la mémoire d'un agent autonome est mis en œuvre via un pipeline en 4 étapes :

1. Extraction & Filtering (Extraction des faits) : Un parseur LLM léger en arrière-plan ou un extracteur heuristique analyse le dialogue terminé ou l'étape de l'outil. Il filtre le bruit communicationnel (« merci », « compris ») et isole des faits atomiques (Atomic Facts).
2. Hybrid Indexing (Indexation hybride) : Les entités obtenues sont enregistrées dans un stockage à double indexation : vecteurs denses (Dense Embeddings) pour la recherche sémantique + index BM25/full-text pour la correspondance exacte des identifiants, fonctions et constantes.
3. Context-Aware Retrieval (Sélection contextuelle) : Avant la génération de la réponse suivante, le classificateur calcule un score intégral de pertinence du souvenir selon la formule : Score = w1 * Relevance + w2 * Recency (décroissance exponentielle) + w3 * Importance (importance). Seuls les top-$K$ fragments les plus importants sont chargés dans le prompt de travail.
4. Memory Compaction & Consolidation (Compression et oubli) : Un processus périodique condense les anciennes chaînes épisodiques en conclusions de haut niveau (Recursive Summarization), libérant ainsi les ressources de la base de connaissances.

4. Scénarios d'ingénierie pratiques en production

01. Contexte personnalisé du développeur

L'agent capture et conserve automatiquement les règles spécifiques d'un développeur : par exemple, l'utilisation stricte de TypeScript, la gestion spécifique des erreurs via Result<T, E>, l'aversion pour any ou la préférence pour certaines bibliothèques d'état, évitant ainsi la nécessité de répéter ces consignes dans chaque chat.

02. Contexte architectural de la base de code

Conservation des décisions prises plusieurs semaines auparavant : « Pourquoi le module de facturation utilise une file Redis Streams plutôt qu'un appel HTTP direct ». L'agent consulte la mémoire sémantique du repository avant de proposer un refactoring risqué.

03. Synchronisation de l'état entre sous-agents

Dans les architectures Multi-Agent (par exemple, orchestrateur -> codeur -> testeur), une mémoire d'état partagée permet à l'agent-testeur de récupérer instantanément toutes les hypothèses de l'agent-architecte sans avoir à transmettre l'intégralité des logs bruts.

5. Pièges, erreurs courantes et sécurité

• Context Poisoning (Empoisonnement de la mémoire) : Si l'agent enregistre une hallucination comme une connaissance véridique, il reproduira cette erreur dans toutes les futures sessions. Protection : validation des faits via une étape de critique séparée (Verification Step) et possibilité explicite de supprimer les souvenirs erronés via l'UI/une commande.
• Retrieval Dilution (Dilution de l'attention) : Un seuil de similarité trop bas entraîne le chargement de dizaines de souvenirs non pertinents, qui évincent les instructions actuelles de l'utilisateur.
• Secret Leakage (Fuite de secrets) : Stockage de données sensibles (clés API, mots de passe issus des logs, tokens) dans la mémoire à long terme. Protection : couche obligatoire de sanitisation (Secret Redaction Regex/Détection d'entropie) au niveau du hook pre-save de la mémoire.