Vous avez déjà connu ce moment : la semaine dernière, vous avez dit à Hermes, en termes clairs, que ce projet se déploie avec le processus X. Cette semaine, il le redemande. Vous ouvrez son fichier de mémoire et vous le trouvez bourré de décisions temporaires vieilles de trois mois, de conclusions ensuite inversées et d’une poignée de doublons quasi identiques. Vous lui demandez de se souvenir de quelque chose, il accepte — et rien ne s’accroche.

Le pire dans une mémoire pleine, c’est que cela ne déclenche aucune erreur. La mémoire d’Hermes a une limite de caractères, et une fois le budget épuisé, les nouvelles écritures sont ignorées en silence. Le temps que vous le remarquiez, personne ne peut plus dire combien a été perdu. Le plugin communautaire hermes-dreaming (ajouté au catalogue officiel de plugins le 2026-10-04) existe exactement pour cela : une passe déterministe de consolidation de la mémoire chaque nuit.

La séparation qui le rend bon marché

Le choix de conception le plus instructif est la répartition du travail. Sur toute l’exécution nocturne, le script n’appelle jamais de LLM :

• un script Python en stdlib pure lit la mémoire que vous avez déjà (MEMORY.md / USER.md) plus les conversations réelles récentes ;
• le filtrage, la notation, l’appariement et la mise en quarantaine se font tous hors ligne ;
• l’agent n’est réveillé que lorsqu’une décision est réellement nécessaire, et il applique alors ces quelques changements via l’outil memory habituel.

La plupart des nuits, cela signifie que la passe est gratuite : rien à calculer, rien à modifier.

Comment il décide que quelque chose vaut la peine d’être mémorisé

Les preuves viennent des humains, à des jours distincts. Un fait ne compte que si des personnes le mentionnent à des jours différents. Les invites cron, les bannières de compaction, les URL, le contenu de chat non fiable et la propre sortie de l’agent ne corroborent jamais rien — ce qui tue le mode de défaillance où un agent mémorise tranquillement ses propres hallucinations.

La notation réutilise les pondérations d’OpenClaw : pertinence, fréquence, diversité, récence, consolidation et richesse, derrière une barrière de corroboration.

Chaque candidat est comparé à la mémoire existante : correspondances exactes, règles d’alias explicites et contenance après racinisation dans trois directions. Une distinction ici est vraiment astucieuse — un candidat qui reformule une entrée existante mais avec des nombres différents n’est pas écarté comme doublon. Il est signalé comme conflit, comme mise à jour possible, et porte l’entrée la plus proche, le fichier où elle vit et une ancre textuelle pour replace.

Le filtrage se fait avant que vous ne voyiez quoi que ce soit : les secrets et les injections de prompt sont mis en quarantaine, les événements datés expirent (formats de date russe, anglais et thaï), et les faits quasi identiques du magasin ne remontent qu’une fois.

Deux garde-fous : une porte de réveil et un garde-fou contre les pertes

• Une porte de réveil. Par une nuit calme, la tâche signale que l’agent n’est pas nécessaire et le modèle ne démarre jamais. Notamment, un fichier de mémoire proche de sa limite de caractères compte comme du travail — parce que la limite bloque les écritures en silence, rien d’autre ne le ferait jamais remonter.
• Un garde-fou contre les pertes. Si une grande part de la mémoire disparaît du jour au lendemain, le rapport suivant le dit explicitement.

Il tient aussi un journal dans memories/DREAMS.md avec la provenance de chaque candidat, de sorte que vous pouvez retracer l’origine d’une entrée.

L’installer

Prérequis : Hermes 0.21 ou plus récent, Python 3.9 ou plus récent, bibliothèque standard uniquement.

# 1. installez et activez le plugin
hermes plugins install itpartypattaya/hermes-dreaming
hermes plugins enable hermes-dreaming

La deuxième étape est le script d’installation. Vous ne pouvez pas l’ignorer : Hermes n’exécute les scripts cron que depuis ~/.hermes/scripts/ (un lien symbolique est refusé), le programme d’installation y copie donc les deux scripts de garde préalables.

python3 ~/.hermes/plugins/hermes-dreaming/skills/dreaming/scripts/install.py

Le programme d’installation copie les deux gardes, initialise ~/.hermes/dreaming.json à partir de l’exemple, fait un essai à blanc sur des copies jetables de l’état, et vérifie la source de faits et la version du cœur. Il est idempotent, et install.py --check vérifie sans rien modifier — exécutez-le après chaque mise à jour, car les copies sous scripts/ peuvent dériver par rapport à la compétence.

La troisième étape est la configuration, et c’est la partie que personne ne peut faire à votre place :

$EDITOR ~/.hermes/dreaming.json

Vous y renseignez le fuseau horaire, trusted_chat_ids, agent_names et fact_source. Notez que trusted_chat_ids est fermé par défaut (fail-closed) : tant que vous n’avez pas listé vos chats de groupe, aucun chat de groupe ne peut corroborer quoi que ce soit et le plugin ne fait délibérément rien. Si un chat de confiance est un forum, listez les fils qui ne sont pas de la conversation humaine — les alertes de l’agent lui-même, les ponts d’assistants, les cartes générées par la machine — sous excluded_threads.

Enfin, les tâches cron. Leur création passe par l’API Python d’Hermes (la CLI n’a pas d’option pour les ensembles d’outils, et le fichier des tâches est l’état vivant de l’ordonnanceur), faites donc d’abord un essai à blanc du plan :

~/.hermes/hermes-agent/venv/bin/python \
    ~/.hermes/plugins/hermes-dreaming/skills/dreaming/scripts/install_cron.py --deliver local --dry-run

Le plan vous convient ? Relancez-le sans --dry-run. Les tâches se lient au nom qualifié de la compétence du plugin, le plugin doit donc d’abord être activé ; les tâches existantes sont ignorées, et une tâche qui charge une autre compétence est signalée — --rebind la rattache.

Chaque candidat arrive à une conclusion

Ce qui fait que cela ressemble moins à un jouet et plus à un outil d’exploitation, c’est qu’il ne vous pose pas la même question pour toujours :

• un candidat est soit écrit en mémoire, soit mis sur la liste de rejet (un « obsolète » d’un humain le clôt définitivement, apparié par texte) ;
• les nouveaux faits, conflits et questions de déclin apparaissent au plus une fois tous les 14 jours ;
• une entrée qui a survécu à un tour « toujours pertinent ? » — conservée, ou réécrite sur place avec une nouvelle date — se repose pendant 90 jours ;
• les délais de récupération ne démarrent qu’une fois que l’agent a réellement répondu : une nuit qui a échoué à mi-parcours remontre les mêmes éléments ;
• au plus six changements aboutissent par nuit, et replace exige l’ancre textuelle fournie par le script.

Mises en garde

• Ce n’est pas un fournisseur de mémoire et il n’enregistre rien : il examine ce que la mémoire intégrée et le magasin holographique contiennent déjà, il complète donc les plugins de mémoire existants plutôt que de les remplacer ;
• les sources de faits peuvent être le magasin holographique, un export SQLite ou JSONL, ou aucune ;
• rien dans le paquet ne modifie le cœur d’Hermes — ce que vous exécutez est le code épinglé du catalogue.

Pour le reste du tableau de la mémoire, voir la migration vers le catalogue des fournisseurs de mémoire et la continuité de mémoire du cron ; la surface de commandes se trouve dans la référence hermes memory et le guide du catalogue de plugins.