# Agent Memory (mémoire de l’agent)

*Des notes que vous pouvez lire et modifier font la vérité. Les index sont un cache que vous pouvez jeter.*

> **Agent Memory** = **des notes que vous pouvez lire et modifier** + **des index que vous pouvez jeter à tout moment**. Chaque note cite ses sources ; les index (texte intégral, vectoriel, graphe, plan) ne sont que des dérivés des notes ; et les tâches de maintenance en arrière-plan ne font que **proposer** des modifications et ne réécrivent jamais le journal brut.

**AN-07** · Niveau de conformité : L2 Memory · Groupe : Connaissance

## Le problème

Les frameworks de mémoire mettent la mémoire dans des bases de données opaques : on ne peut ni l’inspecter, ni la comparer, ni la migrer, ni la corriger, la supprimer de façon fiable est difficile, et l’index et le modèle d’embedding sont verrouillés. Et la mémoire est elle-même une surface d’attaque : dans une [étude de 2026](https://arxiv.org/abs/2606.04329), l’empoisonnement de la mémoire persistante a atteint un taux de réussite moyen de l’attaque de 50,46 % sur deux agents, et [une autre étude](https://arxiv.org/abs/2607.05189) a utilisé un seul e-mail soigneusement conçu pour réussir contre des backends de mémoire à la fois en système de fichiers et vectoriels.

Par ailleurs, « quelle architecture de mémoire est la meilleure » est loin d’être tranché : les benchmarks se contredisent. Une conception qui ne parie sur aucun algorithme de récupération précis est celle qui peut survivre à trois ans de changements.

## Fonctionnement

- **Les notes sont la vérité.** Du Markdown avec frontmatter YAML : `kind` (épisodique, sémantique, procédural, préférence), `subject`, `sources`, `confidence`, `valid_from`, `valid_to`, `supersedes`, `origin`, `reviewed`.
- **Mettre à jour, ne pas écraser.** Un nouveau fait `supersedes` l’ancien ; le temps de validité et le temps d’enregistrement sont séparés, parce que les faits changent et que les benchmarks courants testent à peine cela.
- **Les index sont un cache.** BM25 (par exemple SQLite FTS5), vecteurs (plusieurs peuvent coexister) et graphe facultatif ; chaque dérivé porte sa **recette** et ses **entrées**. Changer de modèle d’embedding est un recalcul en arrière-plan, et l’ancien index est conservé jusqu’à ce que le nouveau réussisse les tests de rappel de référence.
- **Deux sortes de dérivation.** Les dérivations déterministes (découpage, BM25, embeddings d’un modèle fixe) sont reproductibles ; les dérivations génératives (résumés par LLM, faits extraits) ne peuvent qu’être « régénérées et comparées » : elles sont donc marquées `generated: true` et ne servent jamais d’unique copie.
- **Chemin d’écriture.** `nas_remember` écrit une note (avec ses sources) sur la branche courante, et la contamination est héritée. Une note issue d’une session de contamination `external` va en **quarantaine**, marquée non relue : elle peut être rappelée mais **n’est pas chargée automatiquement** et n’entre pas dans `MEMORY.md`.
- **Chemin de lecture.** `nas_recall` = recherche, candidats, une vue avec budget plus des pointeurs de preuve, et il montre la source et l’état de relecture de chaque note.
- **Tâches de maintenance** (la nuit ou au repos) : dédupliquer, consolider des épisodes en faits sémantiques, signaler les contradictions, retirer les faits périmés, reconstruire les index. Les tâches produisent des propositions sur une branche pour qu’une personne ou un agent les relise ; elles **ne suppriment jamais le journal brut** ; le « taux de regret » (la part des propositions qui sont annulées) est mesuré.
- **Tests de rappel de référence.** Pour chaque Home, un ensemble de paires « question, note attendue » qui s’exécutent automatiquement quand le modèle ou l’indexeur change.

## Commencer petit

- `memory/notes/*.md` avec frontmatter, et SQLite FTS5 pour la recherche.
- Faites passer dix questions de référence en CI.
- Les index vectoriels et les tâches de maintenance peuvent venir plus tard ; réussissez d’abord la « provenance » et « seules les notes relues se chargent automatiquement ».

## Esquisse d’interface

À titre d’illustration seulement. Les noms de champs peuvent changer avant la spécification v0.3.

*memory/notes/customer-acme.md*

```markdown
---
id: mem_4kq2
kind: semantic
subject: customer/acme
valid_from: 2026-10-02
valid_to: null
confidence: 0.8
origin: agent
reviewed: true
sources:
  - nas://home-box/agents/cleo/journal/2026-10-02.md@9f2c1de#L12-L18
supersedes: [mem_1xa9]
---
Acme renewed for 24 months; the champion moved from Dana to Luis.
```

## Ce que demande la spécification

- Les notes DOIVENT être lisibles sans la couche Memory (ce sont des fichiers ordinaires dans le Store).
- Chaque dérivé DOIT porter sa recette et ses entrées ; un index DOIT être jetable et reconstructible.
- Les notes écrites par une session contaminée NE DOIVENT PAS être chargées automatiquement avant d’avoir été relues.
- Un nouveau fait DOIT remplacer un ancien avec `supersedes` au lieu de l’écraser.
- Les tâches de maintenance DOIVENT travailler sur une branche et seulement proposer ; elles NE DOIVENT PAS supprimer le journal brut.
- Chaque Home DEVRAIT porter des tests de rappel de référence et les exécuter chaque fois que le modèle ou l’indexeur change.

## Ce qui est emprunté, et ce qui est nouveau

Tout ce qui précède relève de réflexions établies, et l’architecture de mémoire d’OpenClaw fait déjà des étiquettes de provenance, une quarantaine par niveau et la propagation de la contamination pendant la consolidation. **Ce qui est nouveau :** OpenClaw le fait **à l’intérieur d’un seul runtime** ; nous proposons de le faire **dans un stockage partagé** pour que tout runtime en profite, et de rétrograder l’index en cache jetable pour que l’algorithme de récupération puisse changer sans perdre la mémoire.

- [Letta Context Repositories](https://www.letta.com/blog/context-repositories/)
- [Letta: is a filesystem all you need?](https://www.letta.com/blog/benchmarking-ai-agent-memory/)
- [OpenClaw memory architecture](https://docs.openclaw.ai/concepts/memory-architecture)
- [Long-term memory security survey](https://arxiv.org/abs/2604.16548)
- [Graphiti](https://github.com/getzep/graphiti)
- [MemGPT](https://arxiv.org/abs/2310.08560)

## Limites assumées

- Les dérivés génératifs ne peuvent jamais être reproduits à l’identique.
- Une tâche de maintenance peut « durcir » une erreur en fait, c’est pourquoi elle ne fait que proposer et ne modifie jamais directement.
- Quelle architecture de mémoire est la meilleure reste une question non tranchée.

## Questions ouvertes

- Quand un agent doit-il écrire lui-même la mémoire, et quand une tâche de maintenance ?
- Quel est le critère de non-régression d’une version de modèle à l’autre ?

## Questions

### Pourquoi des fichiers plutôt qu’une base de données vectorielle ?

Les fichiers sont la vérité qu’on peut lire, modifier, comparer et emporter ; un index vectoriel est un cache dérivé qui peut coexister en plusieurs versions et être reconstruit à tout moment. Le benchmark de Letta a montré qu’un agent avec seulement `grep` et des outils de fichiers est compétitif, mais les benchmarks se contredisent : la conception ne parie donc pas sur un algorithme de récupération.

### Comment prévient-on l’empoisonnement de la mémoire ?

On ne peut pas garantir que rien de mauvais ne sera jamais écrit, mais on peut borner les conséquences : le contenu venu de l’extérieur porte l’étiquette `external` ; les notes écrites par une session contaminée vont en quarantaine et ne sont pas chargées automatiquement ; les fusions sont relues ; et quand quelque chose tourne mal, on peut suivre la chaîne de provenance jusqu’aux notes touchées et revenir en arrière.

### Dois-je migrer la mémoire quand je change de modèle d’embedding ?

Non. Les notes ne changent pas ; seuls les index sont recalculés en arrière-plan avec la nouvelle recette, et l’ancien index est conservé jusqu’à ce que le nouveau réussisse les tests de rappel de référence.

## Concepts liés

- [Budgeted Reads (lectures avec budget)](https://agentnas.com/fr/concepts/budgeted-reads/): Lire un fichier sous forme de plan, de section, de plage de lignes ou en entier, avec dégradation pour tenir dans le budget.
- [Cascade Forget (oubli en cascade)](https://agentnas.com/fr/concepts/cascade-forget/): Supprimer les dérivés en suivant le lignage, traiter l’historique selon la classe de rétention, et signaler ce qui n’a pas pu être fait.
- [Trust Labels (étiquettes de confiance)](https://agentnas.com/fr/concepts/trust-labels/): Deux petites étiquettes plus la contamination de session appliquent la Rule of Two.

---

URL canonique : https://agentnas.com/fr/concepts/agent-memory/
Mis à jour le: 2026-11-11 · Brouillon de spécification v0.2 · CC BY 4.0