Approche de l'amélioration autonome de la mémoire dans les agents d'IA locaux

Architecture de mémoire pour les agents d'IA persistants

Un développeur sur r/LocalLLaMA a partagé son approche pour créer des agents d'IA qui ne répètent pas les erreurs entre les sessions. Le problème central abordé est que chaque session recommence à zéro, avec des fenêtres de contexte qui se réinitialisent et des corrections qui sont perdues entre les sessions.

Implémentation de la mémoire

Le système utilise le markdown comme source de vérité au lieu d'une base de données. MEMORY.md est modifiable par l'humain - supprimez une ligne dans vim et l'agent l'oublie. SQLite et FAISS (HNSW, 768-dim) sont des caches dérivés qui peuvent être reconstruits à partir du markdown à tout moment. Cela permet aux utilisateurs de versionner la mémoire de leur agent avec git.

Évaluation d'épisodes et apprentissage de règles

Chaque exécution obtient un score +1/-1 et est sauvegardée comme un épisode. Pour des tâches similaires futures, les épisodes pertinents sont extraits dans le contexte. Lorsque la même signature d'erreur (SHA256 du nom de l'outil + erreur normalisée) apparaît deux fois en 7 jours, un apprenant de règles génère une règle de prévention en une ligne.

Les règles commencent avec une confiance de 0,40 et nécessitent 0,60 pour être réellement injectées dans les invites futures. Le succès augmente la confiance de +0,03, l'échec la réduit de -0,05. Les règles qui n'aident pas finissent par disparaître.

Système d'augmentation de la confiance

Au lieu de configurer les niveaux de permission à l'avance, l'agent suit les modèles d'approbation. 5 approbations à un taux de 90%+ = promotion automatique. Un retour en arrière = rétrogradation. Il y a un mode ombre pour l'audit.

Décomposition des tâches et sécurité

Les objectifs complexes deviennent un DAG (Graphe Acyclique Orienté). Les dépendances circulaires sont détectées via un tri topologique, les échecs se propagent aux dépendants via DFS (Recherche en Profondeur). Une porte de vérification contrôle 18 exigences (R01-R18) - l'agent a-t-il réellement lu les fichiers, écrit les changements, vérifié les résultats, resté dans l'espace de travail ?

Les fonctionnalités de sécurité incluent 43 modèles de risque bash, une analyse à double passage (brut + décodé), une conception à défaillance fermée (crash du Gardien = refus), et une profondeur d'écriture minimale de 3 pour empêcher rm -rf /.

Le développeur cherche des retours sur le fait que la décroissance de confiance des règles semble correcte et si l'asymétrie +0,03/-0,05 est optimale. Il se demande également s'il existe de meilleures alternatives à HNSW pour cette échelle (typiquement <10k épisodes).