Memory - Système de gestion de la mémoire

Cet article présente le mécanisme de gestion de la mémoire Managed Auto-Memory (mémoire automatique gérée) de Qwen Code, ses déclencheurs et ses détails d’implémentation.

Table des matières

1. Vue d’ensemble
2. Structure de stockage
3. Types de mémoire
4. Format des entrées mémoire
5. Cycle de vie principal
6. Extract — Extraction
7. Dream — Intégration
8. Recall — Rappel
9. Forget — Oubli
10. Reconstruction de l’index
11. Télémétrie

Vue d’ensemble

Managed Auto-Memory est un système de mémoire persistante qui accumule, intègre et récupère automatiquement les connaissances pertinentes de l’utilisateur au cours des sessions de dialogue avec l’IA. Il maintient le cycle de vie de la mémoire via quatre opérations principales :

Structure de stockage

Disposition des répertoires

~/.qwen/                                      ← Répertoire de base global (par défaut)
└── projects/
    └── <sanitized-git-root>/                 ← Identifiant du projet (basé sur la racine Git)
        ├── meta.json                         ← Métadonnées (horodatages d'extraction/intégration, état)
        ├── extract-cursor.json               ← Curseur d'extraction (décalage de dialogue déjà traité)
        ├── consolidation.lock                ← Verrou d'exclusion mutuelle pour le processus Dream
        └── memory/                           ← Répertoire principal de la mémoire
            ├── MEMORY.md                     ← Fichier d'index (généré automatiquement, récapitule toutes les entrées)
            ├── user.md                       ← Mémoire des préférences utilisateur (exemple)
            ├── feedback.md                   ← Mémoire des règles de feedback (exemple)
            ├── project/
            │   └── milestone.md              ← Mémoire de projet (supporte les sous-répertoires)
            └── reference/
                └── grafana.md                ← Mémoire de ressources externes

Variables d’environnement pour surcharge :

• QWEN_CODE_MEMORY_BASE_DIR : remplace le répertoire de base global
• QWEN_CODE_MEMORY_LOCAL=1 : utilise le chemin local .qwen/memory/ dans le projet

Description des fichiers clés

Types de mémoire

Le système prend en charge quatre types de mémoire intégrés, chacun correspondant à une dimension d’information différente :

Ce qui ne doit pas être stocké en mémoire : conventions de code, historique Git, solutions de débogage, état de tâches temporaires, contenus déjà présents dans QWEN.md/AGENTS.md.

Format des entrées mémoire

Chaque fichier thématique utilise le format YAML frontmatter + Markdown body :

---
name: Nom de la mémoire
description: Description en une phrase (pour juger de la pertinence lors du rappel, être précis)
type: user|feedback|project|reference
---
 
Contenu principal de la mémoire (ligne de résumé)
 
Why: Raison sous-jacente (permet à l'IA de comprendre les cas limites sans appliquer aveuglément la règle)
How to apply: Scénarios d'application et mode d'emploi

Pour les types feedback et project, il est fortement recommandé de renseigner Why et How to apply afin que la mémoire soit correctement appliquée même dans les cas limites.

Cycle de vie principal

Extract — Extraction

Déclenchement

Chaque fois que l’IA termine un tour de réponse, déclenché automatiquement par scheduleAutoMemoryExtract (non bloquant en arrière-plan).

Logique d’ordonnancement (extractScheduler.ts)

Explication des raisons de saut :

Processus d’extraction principal (extract.ts)

Note : La porte isUnderMemoryPressure se trouve dans MemoryManager.runExtract(), pas dans ce flux. Lorsque le moniteur signale une pression hard/critique, MemoryManager saute l’appel d’extraction et n’avance pas le curseur.

Curseur d’extraction :

• Champ : { sessionId, processedOffset, updatedAt }
• Avant l’extraction, lire la progression actuelle via readExtractCursor, puis utiliser history.slice(processedOffset) pour ne traiter que la partie non lue.
• Après chaque extraction, mettre à jour processedOffset avec la longueur actuelle de l’historique (params.history.length).
• Lors du changement de session (sessionId différent), reprendre à l’offset 0.
• Note : On ne construit plus le texte de transcription via buildTranscriptMessages / loadUnprocessedTranscriptSlice – hasNewUserMessages est déterminé par history.slice(startOffset).some(m => m.role === 'user' && partToString(m.parts).trim().length > 0), en ne traitant que la tranche non lue légèrement, l’historique complet n’est plus traité.

Règles de filtrage des patches :

• Longueur du résumé < 12 caractères → abandon
• Résumé se terminant par ? → abandon (phrase interrogative)
• Contient des mots-clés temporaires (today/now/currently/temporary etc.) → abandon
• Même combinaison topic:summary → dédoublonnage

Dream — Intégration

Déclenchement

Chaque fois que l’IA termine un tour de réponse, déclenché automatiquement par scheduleManagedAutoMemoryDream (non bloquant en arrière-plan). Mais protégé par plusieurs conditions de contrôle, il est généralement ignoré.

Contrôle d’ordonnancement (dreamScheduler.ts)

Paramètres de contrôle :

Mécanisme de verrou :

• Le fichier lock se trouve à <project-state-dir>/consolidation.lock
• Le contenu est le PID du processus qui le détient.
• Lors de la vérification : si le processus PID n’existe plus (échec de kill(pid, 0)) ou si le lock est vieux de plus d’1 heure → considéré comme obsolète, effacé automatiquement.

Processus d’exécution de l’intégration (dream.ts)

Logique de dédoublonnage mécanique :

1. Pour chaque fichier de sujet : dédoublonner par summary.toLowerCase(), fusionner les champs why/howToApply
2. Réordonner par ordre alphabétique de summary
3. Entre fichiers : les entrées avec la même combinaison type:summary sont fusionnées dans le premier fichier découvert, supprimer les fichiers dupliqués.

Recall — Rappel

Déclenchement

Avant chaque tour de traitement de la requête utilisateur par l’IA, resolveRelevantAutoMemoryPromptForQuery est automatiquement déclenché pour injecter les souvenirs pertinents dans le prompt système.

Processus de rappel (recall.ts)

Règles de notation (heuristique) :

Mots-clés caractéristiques par type :

• user : user, preference, background, role, terse
• feedback : feedback, rule, avoid, style, summary
• project : project, goal, incident, deadline, release
• reference : reference, dashboard, ticket, docs, link

Règles de construction du prompt :

• Au maximum 5 documents injectés (MAX_RELEVANT_DOCS)
• Chaque corps de document est tronqué à 1200 caractères (MAX_DOC_BODY_CHARS)
• En cas de troncature, un message est ajouté : “NOTE: Relevant memory truncated for prompt budget.”
• Inclut l’information de fraîcheur du document (basée sur mtime du fichier)

Forget — Oubli

Déclenchement

Déclenché par la commande manuelle /forget <query> de l’utilisateur.

Processus d’oubli (forget.ts)

Conception des ID d’entrée :

• Fichier à entrée unique (cas courant) : relativePath (ex. feedback/no-summary.md)
• Fichier à entrées multiples : relativePath:index (ex. feedback/style.md:2)
• Utilisation d’ID stables pour permettre au modèle de localiser précisément une entrée sans affecter les autres entrées du même fichier.

Reconstruire l’index

MEMORY.md est l’index de navigation de tous les fichiers thématiques. Il est reconstruit après chaque Extract ou Dream via rebuildManagedAutoMemoryIndex :

- [User Preferences](user/preferences.md) — L’utilisateur est un ingénieur Go senior, découvre React pour la première fois
- [Feedback Rules](feedback/style.md) — Garder les réponses concises, pas de résumé final
- [Project Milestone](project/milestone.md) — Fenêtre de gel avant la ramification pour la release mobile

Limites de l’index :

• Maximum 150 caractères par ligne (tronqué avec … si dépassé)
• Maximum 200 lignes
• Taille totale maximale 25 000 octets

Télémétrie intégrée

Le système intègre trois catégories d’événements de télémétrie pour surveiller les performances et l’efficacité des opérations mémoire :

Télémétrie Extract

Télémétrie Dream

Télémétrie Recall

Index des fichiers sources