DDDFXYqiming/Agent_Extensions

Gestion de la mémoire (version DSH)

Mémoire à long terme inter-sessions : index d'injection L1 (visible à chaque tour) + faits environnementaux L2 + expériences de tâches L3.

Déclencheurs

Lecture (quand consulter la mémoire)

• Au début d'une nouvelle tâche : si la tâche concerne l'environnement local, la configuration des outils, une stack technique spécifique ou des actions similaires déjà effectuées → d'abord memory_list pour voir ce qui est disponible, puis memory_read pour récupérer les entrées pertinentes
• En cas de difficulté / blocage : memory_read pour vérifier s'il existe une SOP pertinente (correspondance par mot-clé avec les noms de fichiers sops/ ou la section facts)
• Index mémoire dans le prompt du modèle : index L1 visible à chaque tour — lorsqu'un déclencheur pertinent est vu, il faut activement memory_read/memory_list pour obtenir les détails

Écriture (quand consolider la mémoire)

Lorsqu'une tâche (ou une étape) est terminée et qu'il existe des informations validées par une action réussie, appeler memory_write :

Ce qui peut être écrit (doit être accompagné d'une preuve evidence) :

• Faits spécifiques à l'environnement : chemins, configurations, paramètres mesurés, comportements des outils (→ entry_type: fact)
• Expériences de tâches complexes : points difficiles qui n'ont réussi qu'après plusieurs tentatives, prérequis cachés, étapes stables (→ entry_type: sop)
• Règles générales de limitation (→ peut aussi être écrit via memory_write sop ou directement suggéré pour maintenir [RULES])

Ce qui est interdit d'écrire (écrire polluerait la mémoire) :

• ❌ Informations sans preuve de validation (pas d'action, pas de mémoire)
• ❌ Connaissances inhérentes au modèle, déductions ou hypothèses non vérifiées
• ❌ États volatils : horodatages, PID, chemins temporaires, identifiants uniques
• ❌ Connaissances générales, logs, détails du processus de raisonnement

Synchronisation de l'index

• memory_write synchronise automatiquement l'index L1, aucune action manuelle n'est normalement nécessaire
• Après modification manuelle de facts.md / fichiers sops/ → memory_index pour reconstruire l'index
• Lorsque l'index dépasse 30 lignes : simplifier [RULES] (modifications au niveau des mots, interdiction de réécrire l'intégralité)

Structure de stockage

<home>/.dsh/memory/
├── memory_management_sop.md   Règles méta L0 (comment gérer la mémoire)
├── index.txt                  Index L1 (≤30 lignes : liste de présence L2/L3 + RULES)
├── facts.md                   Faits environnementaux L2 (## SECTION)
├── sops/*.md                  Expériences de tâches L3
└── file_access_stats.json     Statistiques de fréquence d'accès

Outils

Outil	Usage
memory_list	Lister toute la mémoire (facts + sops + nombre de lignes de l'index)
memory_read	Lire une mémoire spécifique (index / thème fact / nom de fichier sop)
memory_write	Écrire dans la mémoire (fact/sop, evidence obligatoire)
memory_index	Reconstruire la partie automatique de l'index L1

Principes

1. Validation par l'action : No Execution, No Memory. N'écrire que les informations validées par une action réussie.
2. Minimum suffisant : Le contenu doit être aussi court que possible ; ne mémoriser que les informations dont l'oubli entraînerait un coût élevé de réessai.
3. Ne pas supprimer ni modifier les faits validés : Ils peuvent être compressés ou déplacés, mais il est strictement interdit de les jeter.
4. Écriture proactive : L'écriture en mémoire est toujours initiée par le modèle ou l'utilisateur ; elle ne modifie jamais automatiquement la configuration ou n'installe pas de plugins.