Système de mémoire des agents Hermes : comment fonctionne réellement la mémoire persistante de l'IA

Vous connaissez la routine. Vous ouvrez une conversation avec un agent IA, vous lui expliquez votre projet, partagez vos préférences, obtenez des résultats, puis fermez l’onglet. La semaine suivante, en revenant, c’est comme parler à un étranger : tout le contexte a disparu, chaque préférence a été oubliée, le projet doit être réexpliqué à partir de zéro.

Ce n’est pas un bug. C’est ainsi que les grands modèles de langage (LLM) fonctionnent par conception. Ils sont sans état : chaque requête est indépendante, chaque réponse est générée à partir du prompt que vous envoyez à l’instant T, sans mémoire, sans historique et sans continuité au-delà des jetons présents dans la fenêtre de contexte actuelle.

Pour les interactions à tour unique, cela convient. Posez une question, obtenez une réponse, passez à la suite. Mais pour les agents — des systèmes censés agir sur plusieurs sessions, apprendre de leurs erreurs et évoluer avec vous — l’absence d’état constitue une limite architecturale majeure. C’est l’un des problèmes centraux non résolus des systèmes d’IA auto-hébergés.

L’industrie a tenté de résoudre ce problème. LangChain a ajouté des modules de mémoire. OpenAI a introduit des assistants avec des fils de discussion. Des frameworks comme Letta, Zep et Cognee ont construit des architectures entières autour d’une mémoire persistante. Databricks a publié des recherches sur « l’échelle de la mémoire » — l’idée que la performance de l’agent s’améliore avec l’expérience accumulée. Depuis 2024, des papiers de référence dédiés, des enquêtes sur la mémoire épisodique et un écosystème d’outils en croissance rapide ont émergé pour répondre à ce qui est de plus en plus reconnu comme l’un des problèmes centraux non résolus de l’IA agencée.

La plupart de ces approches partagent un problème commun : elles traitent la mémoire comme une après-pensée — une base de données à interroger, une fenêtre de contexte à bourrer, un système de récupération qui ajoute latence et bruit plutôt que clarté.

Hermes Agent adopte une approche fondamentalement différente. La mémoire n’est pas quelque chose que l’agent récupère quand il en a besoin. C’est quelque chose que l’agent est à tout moment — intégré au prompt système, curaté, borné et toujours actif. Il est assez petit pour être rapide, assez structuré pour être utile, et assez discipliné pour savoir quoi oublier.

Cet article explique exactement comment cela fonctionne — la couche spécifique à Hermes à l’intérieur du modèle inter-framework dans Systèmes de mémoire dans les assistants IA et la stack plus large dans Architecture des assistants IA. Pour les commandes d’activation et d’inspection (hermes memory, hermes dump, journalisation), associez-le avec la Fiche de référence CLI de Hermes Agent. Pour le côté complémentaire du « savoir à long terme » de Hermes — les procédures réutilisables dans SKILL.md plutôt que les fichiers de mémoire curatés — consultez Rédaction de compétences Hermes Agent — Structure et meilleures pratiques de SKILL.md.

Partie 1 : Le problème de la mémoire des agents IA

Pourquoi « Ajouter simplement du contexte » n’est pas scalable pour les agents

La solution évidente à l’IA sans état est d’ajouter du contexte. Joignez la conversation précédente. Incluez la documentation du projet. Envoyez l’historique entier.

Un moment, cela fonctionne. Vous avez une fenêtre de contexte de 128K. Vous pouvez y mettre beaucoup de texte.

Mais le contexte n’est pas la mémoire — il y a une différence réelle et importante entre les deux. Le contexte est tout ce qui vous est montré à l’instant présent ; la mémoire est ce que vous conservez activement et portez avec vous.

Le contexte n’a pas de curation. C’est un dump : à mesure qu’il grandit, le modèle doit traiter des milliers de jetons d’historique irrélévants pour trouver le seul fait dont il a besoin. Cela coûte des jetons et de l’argent, accroît la latence et finit par heurter le plafond.

La mémoire est curatée. C’est la distillation de l’expérience en quelque chose de compact et d’actionnable. Elle ne grandit pas indéfiniment — elle se consolide, se met à jour et oublie.

La mémoire humaine fonctionne de la même manière. Vous ne vous souvenez pas de chaque conversation que vous avez eue. Vous vous souvenez des parties importantes : avec qui vous parlez, ce qui leur importe, ce sur quoi vous êtes d’accord, ce que vous avez appris. Le reste est soit oublié, soit searchable lorsque vous en avez besoin.

Le paysage de la recherche

L’espace de la mémoire des agents IA a explosé depuis 2024, avec des suites de benchmarks dédiées, une littérature de recherche croissante et un écart de performance mesurable entre les différentes approches architecturales. Voici où en sont les choses.

Letta (anciennement MemGPT) était l’un des premiers frameworks à traiter la mémoire persistante comme une préoccupation de premier plan, atteignant 21,7K étoiles GitHub. Il utilise un modèle en trois niveaux inspiré des systèmes d’exploitation : mémoire centrale (petite, toujours dans le contexte), mémoire de rappel (historique de conversation searchable) et mémoire archivistique (stockage froid à long terme). L’intuition selon laquelle toute mémoire n’est pas égale était correcte. L’implémentation, cependant, exige que les agents fonctionnent entièrement à l’intérieur du runtime Letta — l’adopter signifie adopter toute la plateforme, pas seulement une couche de mémoire.

Zep / Graphiti se concentre sur la mémoire conversationnelle avec un suivi temporel des entités — les faits portent des fenêtres de validité afin que le graphe sache quand quelque chose était vrai. Il est performant pour les chatbots qui ont besoin de graphes de relations, moins adapté aux agents autonomes suivant les faits environnementaux et les conventions de projet.

Cognee est conçu pour l’extraction de connaissances à partir de documents et de données structurées, avec plus de 30 connecteurs d’ingestion et un backend de graphe de connaissances. Il excelle dans la connaissance institutionnelle et les pipelines RAG, mais est moins axé sur la mémoire personnelle de l’agent. Consultez Auto-hébergement de Cognee avec des LLM locaux pour un guide de configuration pratique.

Hindsight fait du rappel basé sur des graphes de connaissances avec des relations entre entités et un outil de synthèse reflect unique qui effectue une synthèse inter-mémoire — combinant plusieurs mémoires en nouvelles perspectives. Il figure parmi les meilleurs performeurs sur les benchmarks de mémoire des agents et est disponible en tant que fournisseur de mémoire pour Hermes Agent.

Mem0 gère l’extraction de mémoire côté serveur via l’analyse LLM, nécessitant une configuration minimale. Le papier de recherche Mem0, publié à ECAI 2025 (arXiv:2504.19413), a benchmarké dix approches distinctes de la mémoire IA et validé l’approche d’extraction sélective — stocker des faits discrets, dédoubler et récupérer uniquement ce qui est pertinent. Mem0 a grandi jusqu’à environ 48K étoiles GitHub et prend en charge 21 intégrations de frameworks. Le compromis est la dépendance au cloud et le coût.

La recherche sur l’échelle de la mémoire de Databricks a introduit le concept selon lequel la performance de l’agent s’améliore avec l’expérience accumulée. Leur architecture contient des prompts système, des actifs d’entreprise et des mémoires épisodiques/semantiques scopées au niveau organisation et utilisateur, validant l’idée que la qualité de la mémoire compte autant que la capacité du modèle.

Le fil conducteur à travers la plupart des frameworks est qu’ils traitent la mémoire comme un problème de récupération : stockez-le quelque part, interrogez-le quand nécessaire, injectez-le dans le contexte. Hermes fait l’inverse — la mémoire n’est pas récupérée à la demande, elle est injectée au démarrage de la session et toujours présente. Toujours active, toujours disponible, assez curatée pour rester utile.

Partie 2 : Architecture

Lisez cette partie de haut en bas — couches et rappel/stockage par tour d’abord, puis ce qui se trouve dans MEMORY.md et USER.md, puis comment attacher un fournisseur externe.

Deux couches

Hermes empile la mémoire en deux couches :

1. Intégrée — MEMORY.md et USER.md, basés sur des fichiers, toujours actifs. Plafonds durs de 2 200 caractères (notes de l’agent) et 1 375 caractères (profil utilisateur).
2. Un fournisseur externe (optionnel) — Honcho, OpenViking, Mem0, Hindsight, Holographic, RetainDB, ByteRover, Supermemory et pairs que vous activez via la configuration. Un seul backend externe fonctionne à la fois. Il ajoute la récupération et la rétention aux côtés des fichiers ; il ne les remplace pas.

Le modèle mental est additif — fichiers de base figés plus au plus un plugin. Les hooks de prefetch et de sync orchestrent la couche externe ; les deux fichiers restent injectés séparément comme partie du prompt système figé.

Flux runtime (prefetch et sync)

Le rappel se produit avant que le modèle ne réponde ; la persistance se produit après le message de l’assistant. Dans le gestionnaire de mémoire de Hermes Agent, cela correspond à prefetch à l’entrée et sync à la sortie. Les noms ci-dessous correspondent à la surface d’implémentation (MemoryManager, prefetch / sync_turn / queue_prefetch par fournisseur).

Message utilisateur
    |
    v
MemoryManager.prefetch_all(query)        <-- phase de rappel
    |
    +-- provider.prefetch(query)        <-- chaque fournisseur externe cherche dans son stock
    |
    v
Contexte injecté dans le tour LLM
    |
    v
LLM répond (message assistant)
    |
    v
MemoryManager.sync_all(user, assistant)  <-- phase de stockage
    |
    +-- provider.sync_turn(user, assistant)
    +-- provider.queue_prefetch(user)    <-- recherche en arrière-plan pour le prochain tour

Les fichiers intégrés MEMORY.md et USER.md ne sont pas récupérés via prefetch_all — ils font déjà partie du prompt système figé. Les backends externes se branchent sur prefetch_all / sync_all ; queue_prefetch permet à un fournisseur de préchauffer la récupération pour le tour suivant sans bloquer la réponse actuelle.

Trois chemins vers la mémoire à long terme

1. Outil memory intégré. Le modèle appelle memory avec add, replace ou remove lorsque les instructions indiquent que quelque chose doit persister — faits durables, préférences, corrections, notes environnementales. target='user' maintient USER.md ; target='memory' maintient MEMORY.md. Exemple de forme : memory(action='add', target='user', content='…').

2. Rétention passive sur les fournisseurs externes. À chaque tour, le framework invoque le chemin de sync du fournisseur afin que la conversation puisse être chunkée, résumée ou extraite sans que le modèle ne nomme chaque fait. Le comportement diffère selon le backend — par exemple, Hindsight batche les tours et exécute une rétention structurée avec entités et relations ; Honcho envoie le dialogue à travers son pipeline dialectique ; les stacks style Mem0 et Supermemory extraient les faits passivement des tours.

3. Outils spécifiques aux fournisseurs. Lorsque le plugin les expose, des écritures explicites telles que honcho_conclude, hindsight_retain ou honcho_profile stockent des slices durables sur demande.

Rappel automatique versus outils des fournisseurs

La mémoire centrale n’a pas besoin d’un outil de lecture — elle est déjà dans le prompt. Les backends externes ajoutent soit une injection automatique depuis le prefetch (aucun appel d’outil de rappel séparé pour cette slice de contexte), soit des outils de récupération explicites (honcho_search, honcho_reasoning, honcho_context, hindsight_recall, hindsight_reflect, et pairs) lorsque le modèle a besoin d’une requête plus précise que le prefetch seul.

Modes de rappel (fournisseurs externes)

Les plugins prennent en charge un mode de rappel configurable (généralement recall_mode à côté de memory.provider dans la configuration) qui échange des jetons contre le contrôle.

Lorsqu’aucun fournisseur externe n’est défini (memory.provider vide ou non défini), seuls les fichiers intégrés et la recherche de session s’appliquent — aucun prefetch/sync depuis un plugin.

Chemins sur le disque et budgets

La mémoire intégrée de Hermes Agent réside dans deux fichiers.

• ~/.hermes/memories/MEMORY.md — Notes personnelles de l’agent (2 200 caractères, ~800 jetons)
• ~/.hermes/memories/USER.md — Profil utilisateur (1 375 caractères, ~500 jetons)

C’est toute la surface de mémoire persistante : deux fichiers, moins de 3 600 caractères au total, moins de 1 300 jetons. Cela semble délibérément petit parce que c’est le cas — et c’est exactement l’intention de conception.

MEMORY.md : Les notes de l’agent

C’est ici que l’agent stocke tout ce qu’il apprend sur son environnement, le projet, les outils, les conventions et les leçons apprises. Voici à quoi cela ressemble :

Le projet de l'utilisateur est un microservice Go à ~/code/gateway utilisant gRPC + PostgreSQL
Cette machine exécute Ubuntu 22.04, a Docker et kubectl installés
L'utilisateur préfère snake_case pour les noms de variables et évite camelCase

Ce ne sont pas des journaux. Ce sont des faits. Denses, déclaratifs, chargés d’informations. Pas de timestamps, pas de blabla, pas de « le 5 janvier, l’utilisateur m’a demandé de… »

USER.md : Le profil utilisateur

C’est ici que l’agent stocke tout ce qu’il sait sur vous.

L'utilisateur est un développeur full-stack à l'aise avec TypeScript, Go et Python.
L'utilisateur préfère snake_case pour les noms de variables et évite camelCase.
L'utilisateur utilise principalement Linux Ubuntu 22.04.
L'utilisateur déploie sur AWS en utilisant Terraform.

Identité, rôle, préférences, compétences techniques, style de communication, petites manies. Les choses qui font que l’agent vous répond différemment qu’à quiconque d’autre.

Le motif de l’instantané figé

Au démarrage de la session, les deux fichiers sont chargés depuis le disque et injectés comme un bloc figé dans le prompt système. Voici à quoi cela ressemble :

══════════════════════════════════════════════
MÉMOIRE (vos notes personnelles) [7% — 166/2 200 caractères]
══════════════════════════════════════════════
Le projet de l'utilisateur est un microservice Go à ~/code/gateway utilisant gRPC + PostgreSQL
§
Cette machine exécute Ubuntu 22.04, a Docker et kubectl installés
§
L'utilisateur préfère snake_case pour les noms de variables et évite camelCase
§

══════════════════════════════════════════════
PROFIL UTILISATEUR (qui est l'utilisateur) [8% — 110/1 375 caractères]
══════════════════════════════════════════════
L'utilisateur est un développeur full-stack à l'aise avec TypeScript, Go et Python.
§
L'utilisateur préfère snake_case pour les noms de variables et évite camelCase.
§

Le format utilise des en-têtes, des pourcentages d’utilisation, des comptes de caractères et des délimiteurs § (signe section). Les entrées peuvent être multilignes. Il est conçu pour être analysable par le modèle tout en restant lisible par l’homme.

Pourquoi figé ? Mise en cache des préfixes. Le prompt système est le même à chaque tour d’une session. En gardant la mémoire statique après le démarrage de la session, le modèle peut mettre en cache le calcul du préfixe et ne traiter que les parties variables — la conversation. C’est une optimisation de performance significative. Vous ne recalculerez pas l’attention sur les mêmes jetons de mémoire à chaque tour.

Les modifications apportées pendant une session persistent sur le disque immédiatement, mais n’apparaissent dans le prompt système qu’au démarrage de la session suivante. Les réponses aux outils montrent toujours l’état en direct, mais l’esprit du modèle ne change pas en cours de session. Cela empêche le modèle de courir après sa queue — mettre à jour la mémoire et réagir à sa propre mise à jour dans la même conversation.

Les limites de caractères comme fonctionnalité

2 200 caractères. 1 375 caractères. Ce ne sont pas des limites arbitraires. Ce sont des contraintes de conception qui forcent la curation.

Une mémoire illimitée est un fardeau. Elle encourage à tout y mettre, à jamais consolider et à finir par devenir du bruit. Une mémoire bornée force l’agent à être sélectif. Qu’est-ce qui est vraiment important ? De quoi aurai-je besoin à nouveau ? Quoi compresser sans perdre de sens ?

Lorsque la mémoire est pleine, l’agent ne rate pas silencieusement. Il reçoit une erreur avec les entrées actuelles et l’utilisation, puis suit un workflow :

1. Lire les entrées actuelles depuis la réponse d’erreur
2. Identifier les entrées supprimables ou consolidables
3. Utiliser replace pour fusionner les entrées connexes en versions plus courtes
4. Ajouter la nouvelle entrée

C’est ainsi que la mémoire reste utile. Ce n’est pas une base de données. C’est une collection curatée de faits qui comptent.

Sécurité : Numérisation d’injection de prompt

Chaque entrée de mémoire est scannée avant acceptation. Le système bloque les tentatives d’injection de prompt, l’exfiltration de credentials, les backdoors SSH et les caractères Unicode invisibles.

La mémoire est également dédoublonnée. Les entrées dupliquées exactes sont rejetées automatiquement. Cela empêche les adversaires d’essayer d’injecter du contenu malveillant via des soumissions répétées.

Fournisseurs de mémoire externe (activation et liens)

Au-delà des fichiers intégrés MEMORY.md et USER.md, Hermes Agent peut attacher un seul plugin de mémoire externe à la fois — Honcho, OpenViking, Mem0, Hindsight, Holographic, RetainDB, ByteRover ou Supermemory — pour une connaissance persistante et cross-session. Un seul fournisseur externe est actif à la fois ; les deux fichiers de base restent chargés à ses côtés (additif, pas de remplacement).

Activez et inspectez les fournisseurs avec hermes memory setup, hermes memory status et hermes memory off, ou définissez memory.provider et recall_mode dans ~/.hermes/config.yaml. Les modèles de credentials varient (par exemple HINDSIGHT_API_KEY, clés Honcho sous $HERMES_HOME/honcho.json) ; utilisez hermes memory setup pour le câblage interactif.

Forme YAML minimale intégrée uniquement :

memory:
  provider: ""
  memory_enabled: true
  user_profile_enabled: true

Exemple d’activation pour un backend (remplacez hindsight par honcho, mem0, supermemory ou autres que votre installation prend en charge) :

memory:
  provider: "hindsight"

Pour le tableau de comparaison complet, les notes sur les dépendances LLM et d’embedding, les détails par fournisseur et comment ces backends se rapportent à OpenClaw et autres stacks, consultez Fournisseurs de mémoire des agents comparés.

Pour le câblage spécifique au profil et les workflows de production, consultez Configuration de production de Hermes Agent. Le Hub Mémoire des Systèmes IA liste ce guide ainsi que les articles liés à Cognee et à la couche de connaissances.

Partie 3 : Quand la mémoire s’active — Déclencheurs & Décisions

La question la plus courante concernant la mémoire de Hermes Agent est quand elle sauvegarde réellement quelque chose.

La réponse est : constamment, mais sélectivement. L’agent gère sa propre mémoire via l’outil memory, et la décision de sauvegarder est pilotée par une combinaison de signaux explicites et de motifs implicites.

Déclencheurs d’écriture : Quand l’agent décide-t-il de sauvegarder ?

L’agent sauvegarde la mémoire de manière proactive. Il n’attend pas que vous demandiez. Voici ce qui le déclenche.

Corrections de l’utilisateur. Lorsque vous corrigez l’agent, c’est un signal pour se souvenir. « Ne fais plus ça. » « Utilise ça à la place. » « Souviens-toi de ça. » Ce sont des instructions explicites pour mettre à jour la mémoire.

Exemple : vous demandez à l’agent de configurer un environnement Python. Il suggère pip. Vous dites « J’utilise poetry pour tout. » L’agent sauvegarde : L'utilisateur préfère utiliser le gestionnaire de paquets 'poetry' pour tous les projets Python.

Préférences découvertes. L’agent observe des motifs et infère des préférences. Si vous utilisez constamment un certain outil, framework ou workflow, cela est sauvegardé.

Exemple : après avoir vu utiliser poetry plusieurs fois à travers différents projets, l’agent le sauvegarde comme préférence.

Faits environnementaux. Des choses sur la machine, le projet, les outils installés. Ceux-ci sont découverts par exploration et sauvegardés comme faits.

Exemple : l’agent vérifie ce qui est installé et sauvegarde : Cette machine exécute Ubuntu 22.04, a Docker et kubectl installés.

Conventions de projet. Comment le projet est structuré, quels outils il utilise, quels motifs il suit. Ceux-ci sont découverts par inspection de code et sauvegardés.

Exemple : Le projet de l'utilisateur est un microservice Go à ~/code/gateway utilisant gRPC + PostgreSQL.

Workflows complexes complétés. Après avoir complété une tâche qui a pris 5+ appels d’outils, l’agent envisage de sauvegarder l’approche comme une compétence ou au moins noter ce qui a fonctionné.

Particularités d’outils et contournements. Lorsque l’agent découvre quelque chose de non évident sur un outil, API ou système — une limitation, un contournement, une convention — il le sauvegarde.

Ce qui est sauté :

• Informations triviales ou évidentes
• Choses facilement redécouvertes
• Dumps de données brutes
• Éphémères spécifiques à la session
• Informations déjà dans les fichiers de contexte (SOUL.md, AGENTS.md)

Déclencheurs de lecture : Quand l’agent rappelle-t-il ?

La mémoire n’est pas récupérée — elle est toujours là. Mais il y a différents niveaux d’accès.

Début de session (automatique). MEMORY.md et USER.md sont injectés dans le prompt système. L’agent les a dès le premier jeton. Aucune requête nécessaire, aucune latence, aucun appel d’outil. C’est la mémoire centrale — toujours active.

session_search (sur demande). Lorsque l’agent a besoin de trouver quelque chose de conversations passées qui n’est pas dans la mémoire centrale, il utilise l’outil session_search. Cela interroge SQLite (~/.hermes/state.db) avec la recherche full-text FTS5 et le résumé Gemini Flash. Utilisez ceci lorsque la question ressemble à « nous avons discuté de ça avant » plutôt que « souviens-toi de ce fait pour toujours. »

Exemple : vous demandez « Avons-nous discuté du réseau Docker la semaine dernière ? » L’agent recherche l’historique de session et retourne un résumé de la conversation pertinente.

Outils de fournisseurs externes (lorsqu’ils sont configurés). Lorsqu’un fournisseur de mémoire externe est actif, le framework exécute également une étape de prefetch automatique avant chaque réponse (voir Partie 2). Des outils supplémentaires tels que honcho_search, hindsight_recall ou mem0_search sont destinés aux recherches ciblées lorsque l’agent choisit une récupération explicite — selon recall_mode, l’injection automatique, les outils, ou les deux peuvent être actifs.

L’arbre de décision

Voici comment l’agent pèse « est-ce que ça vaut la peine de se souvenir ? » :

Est-ce une correction ou une instruction explicite ?
  OUI → Sauvegarder en mémoire
  NON → Est-ce une préférence ou un motif ?
    OUI → Sauvegarder dans le profil utilisateur
    NON → Est-ce un fait environnemental ou une convention ?
      OUI → Sauvegarder en mémoire
      NON → Est-ce facilement redécouvrable ?
        OUI → Sauter
        NON → Est-ce spécifique à la session ?
          OUI → Sauter
          NON → Sauvegarder en mémoire

L’agent ne réfléchit pas trop à cela. Il sauvegarde de manière proactive, consolide quand c’est plein, et fait confiance aux limites de caractères pour garder les choses serrées.

Partie 4 : Mémoire interne versus Bases de connaissances externes

C’est ici que la confusion arrive souvent. Hermes Agent a une mémoire interne (MEMORY.md, USER.md, fournisseurs externes) et des bases de connaissances externes (LLM Wiki, Obsidian, Notion, ArXiv, système de fichiers), et ils servent des rôles complètement différents. Cela ressemble à la distinction entre les pipelines de génération augmentée par la récupération et la mémoire de travail de l’agent — la récupération externe est bonne pour les recherches de connaissances profondes, pas pour porter l’identité et les préférences. La mémoire interne est le cerveau de l’agent — toujours active, curatée, portée dans chaque session. Les bases de connaissances externes sont sa bibliothèque — d’immenses ressources de référence consultées sur demande.

La distinction

Mémoire interne (le cerveau) :

• Petite, persistante, injectée dans le prompt système
• Contient : préférences utilisateur, conventions de l’agent, leçons immédiates
• Toujours « en tête » pendant la conversation
• Curatée, bornée, activement gérée
• Exemples : MEMORY.md, USER.md, Honcho, Hindsight, Mem0

Bases de connaissances externes (la bibliothèque) :

• Vaste, référence uniquement, accédée sur demande
• Contient : documents, papiers, code, notes, bases de données
• Accédée via des outils lorsque nécessaire
• Pas « rappelée » — consultée
• Exemples : LLM Wiki, Obsidian, Notion, ArXiv, système de fichiers, GitHub

Comment ils se rapportent

L’agent accède aux bases externes via des outils lorsque nécessaire. Il ne les « rappelle » pas — il les consulte.

LLM Wiki (llm-wiki) : Base de connaissances Markdown interliée de Karpathy pour construire et interroger des connaissances de domaine. L’agent utilise la compétence llm-wiki pour lire, chercher et interroger. C’est une ressource de référence, pas une mémoire.

Obsidian : Coffres-forts de notes personnelles avec des liens bidirectionnels. L’agent utilise la compétence obsidian pour lire, chercher et créer des notes. Obsidian fait partie de l’écosystème plus large de la gestion des connaissances personnelles que Hermes peut exploiter comme ressource de bibliothèque.

Notion/Airtable : Bases de données structurées et wikis accédés via API. L’agent les interroge lorsque nécessaire.

ArXiv : Dépôts de papiers académiques. L’agent cherche et extrait des papiers lors de la recherche d’un sujet.

Système de fichiers : Code de projet, documentation, configurations. L’agent lit les fichiers lors du travail sur un projet.

Le motif de distillation

Voici l’idée clé : les insights critiques des bases externes peuvent être distillés dans la mémoire interne.

Exemple : l’agent lit un papier d’ArXiv sur l’échelle de la mémoire pour les agents IA. Il ne sauvegarde pas le papier entier en mémoire. Il sauvegarde la prise clé : Échelle de la mémoire : la performance de l'agent s'améliore avec l'expérience accumulée grâce à l'interaction utilisateur et au contexte métier stockés en mémoire.

La ressource externe est vaste. La mémoire interne est la distillation.

Quand utiliser lequel

Mémoire interne pour :

• « Qui aide-je ? »
• « Que préfèrent-ils ? »
• « Qu’avons-nous appris récemment ? »
• « Quelle est la configuration du projet ? »
• « Quels outils sont disponibles ? »

Bases de connaissances externes pour :

• « Quelle est la dernière recherche sur X ? »
• « Qu’y a-t-il dans la documentation de mon projet ? »
• « Qu’avons-nous discuté le mois dernier ? »
• « Quelle est l’API de ce service ? »
• « Quelle est la structure du code ? »

L’agent comprend la différence et utilise chacun de manière appropriée — il ne confond pas consulter un document avec rappeler quelque chose qu’il a appris sur vous et votre environnement.

Partie 5 : Comment ça marche réellement

Regardons la mécanique.

L’outil memory

L’agent gère la mémoire à travers un seul outil avec trois actions : add, replace, remove.

Il n’y a pas d’action read — le contenu de la mémoire est auto-injecté dans le prompt système. L’agent n’a pas besoin de le lire parce qu’il est toujours là.

add — Ajoute une nouvelle entrée.

memory(action="add", target="memory",
       content="L'utilisateur exécute macOS 14 Sonoma, utilise Homebrew, a Docker Desktop installé.")

replace — Remplace une entrée existante en utilisant la correspondance de sous-chaînes.

memory(action="replace", target="memory",
       old_text="mode sombre",
       content="L'utilisateur préfère le mode clair dans VS Code, le mode sombre dans le terminal")

remove — Supprime une entrée en utilisant la correspondance de sous-chaînes.

memory(action="remove", target="memory",
       old_text="fait temporaire du projet")

Correspondance de sous-chaînes

replace et remove utilisent de courtes sous-chaînes uniques via old_text. Vous n’avez pas besoin du texte complet de l’entrée. Cela rend les modifications chirurgicales possibles sans connaître le contenu exact.

Si une sous-chaîne correspond à plusieurs entrées, une erreur est retournée demandant une correspondance plus spécifique. L’agent affine alors sa requête.

Stores cibles : memory vs user

Le paramètre target détermine quel fichier est mis à jour.

• memory — Notes personnelles de l’agent. Faits environnementaux, conventions de projet, particularités d’outils, leçons apprises.
• user — Profil utilisateur. Identité, rôle, fuseau horaire, préférences de communication, petites manies, habitudes de workflow.

Gestion de la capacité

Lorsque la mémoire est >80% pleine, l’agent consolide. Il fusionne les entrées connexes, supprime les faits périmés et compresse l’information.

Les bonnes entrées de mémoire sont compactes et denses en informations :

L'utilisateur exécute macOS 14 Sonoma, utilise Homebrew, a Docker Desktop installé. Shell : zsh avec oh-my-zsh. Éditeur : Neovim avec le plugin Telescope.

Les mauvaises entrées de mémoire sont vagues ou verbeuses :

L'utilisateur a un projet.
Le 5 janvier 2026, l'utilisateur m'a demandé de regarder son projet qui est situé à ~/code/gateway et qui utilise Go avec gRPC et PostgreSQL pour la couche de base de données.

La première est dense et utile. La seconde est soit trop vague, soit trop verbeuse.

Recherche de session versus Mémoire persistante

session_search et la mémoire persistante servent des objectifs différents.

Règle générale : utilisez la mémoire pour les faits critiques qui devraient toujours être dans le contexte. Utilisez la recherche de session pour les recherches historiques.

Partie 6 : La philosophie

Pourquoi la mémoire bornée bat la mémoire illimitée

L’instinct est de rendre la mémoire aussi grande que possible. Stockez tout. Récupérez ce dont vous avez besoin.

La mémoire bornée fonctionne mieux. Voici pourquoi.

La curation force la qualité. Lorsque vous avez un espace limité, vous ne sauvegardez que ce qui compte. Vous compressez, consolidez et priorisez. Une mémoire illimitée encourage à tout y mettre et à jamais nettoyer.

La vitesse compte. 1 300 jetons dans le prompt système est rapide. 100 000 jetons récupérés depuis une base de données est lent. La mémoire devrait être instantanée, pas une requête.

Le bruit dégrade la performance. Plus de mémoire n’est pas une meilleure mémoire. C’est une mémoire plus bruyante. Le modèle doit distinguer le signal du bruit, et cela prend de l’attention — une attention qui devrait être dépensée sur la tâche réelle.

Oublier est une fonctionnalité. La mémoire humaine oublie. Ce n’est pas un bug — c’est comment nous priorisons. Les agents devraient oublier aussi. Tout ne mérite pas d’être rappelé.

Le problème de l’« oubli »

Les agents doivent désapprendre. Pas seulement oublier, mais activement supprimer l’information périmée.

Voici comment Hermes Agent le gère :

• Action remove : Supprimer les entrées qui ne sont plus pertinentes.
• Action replace : Mettre à jour les entrées avec de nouvelles informations.
• Pression de capacité : Lorsque la mémoire est pleine, l’agent consolide et supprime les anciennes entrées.
• Numérisation de sécurité : Bloque les entrées malveillantes ou corrompues.

Oublier n’est pas l’échec — c’est la maintenance. Un agent qui ne peut pas désapprendre finira par porter autant de bruit que de signal.

Échelle de la mémoire

Databricks a introduit le concept d’« échelle de la mémoire » : un agent avec des milliers d’utilisateurs performe-t-il mieux qu’un avec un seul utilisateur ?

Leur recherche suggère oui, mais avec des réserves. L’échelle de la mémoire nécessite :

1. Extraction de qualité : Toutes les interactions ne valent pas la peine d’être rappelées. L’agent doit extraire des insights, pas des journaux.
2. Récupération efficace : Les mémoires récupérées doivent être pertinentes. Le bruit dégrade la performance.
3. Généralisation : Les mémoires devraient être des motifs, pas des spécificités. « L’utilisateur préfère Python » s’échelle. « L’utilisateur a lancé la commande X au timestamp Y » ne s’échelle pas.

La mémoire bornée de Hermes Agent supporte naturellement l’échelle de la mémoire. En forçant la curation, elle s’assure que les mémoires sont généralisables, compactes et utiles.

Ce que cela signifie pour l’avenir

La mémoire devient la fossé concurrentielle dans l’IA agencée — pas le modèle lui-même, mais ce que le modèle porte entre les sessions. Deux agents avec des modèles sous-jacents identiques peuvent performer très différemment : l’un se souvient de vos préférences, de votre environnement et de vos erreurs passées ; l’autre démarre à froid chaque fois.

La question n’est plus si les agents devraient avoir une mémoire persistante. C’est réglé : ils doivent. La question ouverte est comment concevoir cette mémoire bien — quoi garder, quoi jeter, comment la rendre instantanée, et comment empêcher qu’elle ne devienne du bruit.

La réponse de Hermes Agent est de garder la mémoire petite, curatée et toujours active — pas une base de données que vous interrogez, mais un modèle de travail de l’utilisateur que l’agent porte avec lui dans chaque conversation.

Conclusion

Le système de mémoire de Hermes Agent est délibérément simple : deux fichiers, des limites de caractères fermes, aucun pipeline de récupération, aucune base de données vectorielle, et aucune latence par requête. Ce qui sonne comme une contrainte est tout le point.

Ça marche parce que ça traite la mémoire comme un cerveau fonctionne plutôt que comme une base de données — petite, curatée et toujours active. L’agent ne récupère pas la mémoire quand il en a besoin ; la mémoire est simplement toujours là, tissée dans le prompt système dès le premier jeton de chaque session.

Les fournisseurs de mémoire externe étendent ce système pour les utilisateurs qui en ont besoin : graphes de connaissances, support multi-agent, stockage auto-hébergé, fonctionnalités d’entreprise. Mais le noyau reste le même : borné, curaté, toujours disponible.

Et les bases de connaissances externes — LLM Wiki, Obsidian, Notion, ArXiv — servent un rôle différent. C’est la bibliothèque, pas le cerveau. L’agent les consulte, ne les rappelle pas. Les insights critiques sont distillés dans la mémoire interne ; le reste reste dans la bibliothèque.

C’est ainsi qu’un agent IA se souvient de vous. Pas en stockant tout, mais en se souvenant de ce qui compte.

Hermes Agent a été publié par Nous Research en février 2026 et a atteint plus de 64 000 étoiles GitHub d’ici avril 2026 (v0.9.0), avec 242+ contributeurs. Il est open-source et disponible à github.com/NousResearch/hermes-agent. Pour l’installation, la configuration et les guides de workflow, consultez l’aperçu de Hermes Agent.