Mémoire et skills dans Hermes Agent

Mémoire et skills dans Hermes Agent

Cette page fait partie du référence technique francophone consacré à Hermes Agent. Elle répond à l'intention de recherche : comprendre mémoire et skills.

Le contenu s'appuie sur la documentation officielle Hermes Agent associée à cette page. L'objectif n'est pas de remplacer la documentation de Nous Research, mais de fournir une lecture claire en français, structurée pour aller vite, avec un maillage logique vers les pages complémentaires du même site.

À retenir

• Sujet principal : hermes agent mémoire skills.
• Type de page : hub.
• Cluster : memoire-skills.
• Source canonique : documentation officielle Hermes Agent.
• Aucun lien vers l'autre domaine n'est utilisé dans cette page.

Comment utiliser cette section

Cette section regroupe les pages du cluster memoire-skills. Commencez par cette page si vous voulez comprendre le sujet dans son ensemble, puis ouvrez les guides détaillés selon votre contexte.

Chaque page interne contient des liens vers les prérequis, les pages voisines et les suites logiques. Le but est de créer un parcours utile, pas une liste brute de pages SEO.

Base officielle

Hermes Agent has bounded, curated memory that persists across sessions. This lets it remember your preferences, your projects, your environment, and things it has learned.

How It Works

Two files make up the agent's memory:

• File — Purpose — Char Limit
• MEMORY.md — Agent's personal notes — environment facts, conventions, things learned — 2,200 chars (~800 tokens)
• USER.md — User profile — your preferences, communication style, expectations — 1,375 chars (~500 tokens)

Both are stored in ~/.hermes/memories/ and are injected into the system prompt as a frozen snapshot at session start. The agent manages its own memory via the memory tool — it can add, replace, or remove entries.

Character limits keep memory focused. Memory does not auto-compact: when a

write would exceed the limit, the memory tool returns an error instead of

silently dropping entries. The agent then makes room itself — consolidating or

removing entries in the same turn before retrying (see [What Happens When Memory

is Full](#what-happens-when-memory-is-full)). Note that replace is also bound

by the limit: swapping an entry for a longer one can still overflow, so the new

content must be shortened (or another entry removed) to fit.

How Memory Appears in the System Prompt

At the start of every session, memory entries are loaded from disk and rendered into the system prompt as a frozen block:

══════════════════════════════════════════════
MEMORY (your personal notes) [67% — 1,474/2,200 chars]
══════════════════════════════════════════════
User's project is a Rust web service at ~/code/myapi using Axum + SQLx
§
This machine runs Ubuntu 22.04, has Docker and Podman installed
§
User prefers concise responses, dislikes verbose explanations

The format includes:

• A header showing which store (MEMORY or USER PROFILE)
• Usage percentage and character counts so the agent knows capacity
• Individual entries separated by § (section sign) delimiters
• Entries can be multiline

Frozen snapshot pattern: The system prompt injection is captured once at session start and never changes mid-session. This is intentional — it preserves the LLM's prefix cache for performance. When the agent adds/removes memory entries during a session, the changes are persisted to disk immediately but won't appear in the system prompt until the next session starts. Tool responses always show the live state.

Memory Tool Actions

The agent uses the memory tool with these actions:

• add — Add a new memory entry
• replace — Replace an existing entry with updated content (uses substring matching via old_text)
• remove — Remove an entry that's no longer relevant (uses substring matching via old_text)

There is no read action — memory content is automatically injected into the system prompt at session start. The agent sees its memories as part of its conversation context.

Substring Matching

The replace and remove actions use short unique substring matching — you don't need the full entry text. The old_text parameter just needs to be a unique substring that identifies exactly one entry:

memory(action="replace", target="memory",
       old_text="dark mode",
       content="User prefers light mode in VS Code, dark mode in terminal")

If the substring matches multiple entries, an error is returned asking for a more specific match.

Two Targets Explained

memory — Agent's Personal Notes

For information the agent needs to remember about the environment, workflows, and lessons learned:

• Environment facts (OS, tools, project structure)
• Project conventions and configuration
• Tool quirks and workarounds discovered
• Completed task diary entries
• Skills and techniques that worked

user — User Profile

For information about the user's identity, preferences, and communication style:

• Name, role, timezone
• Communication preferences (concise vs detailed, format preferences)
• Pet peeves and things to avoid
• Workflow habits
• Technical skill level

What to Save vs Skip

Save These (Proactively)

The agent saves automatically — you don't need to ask. It saves when it learns:

• User preferences: "I prefer TypeScript over JavaScript" → save to user
• Environment facts: "This server runs Debian 12 with PostgreSQL 16" → save to memory
• Corrections: "Don't use sudo for Docker commands, user is in docker group" → save to memory
• Conventions: "Project uses tabs, 120-char line width, Google-style docstrings" → save to memory
• Completed work: "Migrated database from MySQL to PostgreSQL on 2026-01-15" → save to memory
• Explicit requests: "Remember that my API key rotation happens monthly" → save to memory

Skip These

• Trivial/obvious info: "User asked about Python" — too vague to be useful
• Easily re-discovered facts: "Python 3.12 supports f-string nesting" — can web search this
• Raw data dumps: Large code blocks, log files, data tables — too big for memory
• Session-specific ephemera: Temporary file paths, one-off debugging context
• Information already in context files: SOUL.md and AGENTS.md content

Capacity Management

Memory has strict character limits to keep system prompts bounded:

• Store — Limit — Typical entries
• memory — 2,200 chars — 8-15 entries
• user — 1,375 chars — 5-10 entries

What Happens When Memory is Full

When you try to add an entry that would exceed the limit, the tool returns an error:

{
  "success": false,
  "error": "Memory at 2,100/2,200 chars. Adding this entry (250 chars) would exceed the limit. Consolidate now: use 'replace' to merge overlapping entries into shorter ones or 'remove' stale or less important entries (see current_entries below), then retry this add — all in this turn.",
  "current_entries": ["..."],
  "usage": "2,100/2,200"
}

The agent should then:

1. Read the current entries (shown in the error response)
2. Identify entries that can be removed or consolidated
3. Use replace to merge related entries into shorter versions
4. Then add the new entry

Best practice: When memory is above 80% capacity (visible in the system prompt header), consolidate entries before adding new ones. For example, merge three separate "project uses X" entries into one comprehensive project description entry.

Practical Examples of Good Memory Entries

Compact, information-dense entries work best:

User runs macOS 14 Sonoma, uses Homebrew, has Docker Desktop and Podman. Shell: zsh with oh-my-zsh. Editor: VS Code with Vim keybindings.

Project ~/code/api uses Go 1.22, sqlc for DB queries, chi router. Run tests with 'make test'. CI via GitHub Actions.

The staging server (10.0.1.50) needs SSH port 2222, not 22. Key is at ~/.ssh/staging_ed25519.

User has a project.

On January 5th, 2026, the user asked me to look at their project which is
located at ~/code/api. I discovered it uses Go version 1.22 and...

Duplicate Prevention

The memory system automatically rejects exact duplicate entries. If you try to add content that already exists, it returns success with a "no duplicate added" message.

Security Scanning

Memory entries are scanned for injection and exfiltration patterns before being accepted, since they're injected into the system prompt. Content matching threat patterns (prompt injection, credential exfiltration, SSH backdoors) or containing invisible Unicode characters is blocked.

Session Search

Beyond MEMORY.md and USER.md, the agent can search its past conversations using the session_search tool:

• All CLI and messaging sessions are stored in SQLite (~/.hermes/state.db) with FTS5 full-text search
• Search queries return actual messages from the DB — no LLM summarization, no truncation
• The agent can find things it discussed weeks ago, even if they're not in its active memory
• The agent can also scroll forward/backward inside any session it finds

hermes sessions list    # Browse past sessions

See Session Search Tool for the three calling shapes (discovery / scroll / browse) and the response format.

session_search vs memory

• Feature — Persistent Memory — Session Search
• Capacity — ~1,300 tokens total — Unlimited (all sessions)
• Speed — Instant (in system prompt) — ~20ms FTS5 query, ~1ms scroll
• Cost — Token cost in every prompt — Free — no LLM calls
• Use case — Key facts always available — Finding specific past conversations
• Management — Manually curated by agent — Automatic — all sessions stored
• Token cost — Fixed per session (~1,300 tokens) — On-demand (searched when needed)

Memory is for critical

Points de vigilance

• Vérifiez toujours la version active de Hermes Agent avant d'appliquer une commande ou une configuration.
• Ne collez pas de clé API dans un chat public ou dans une page visible.
• Gardez les secrets dans les fichiers ou gestionnaires prévus pour cela.
• Si une fonctionnalité dépend d'un provider, d'un plugin ou d'une plateforme de messagerie, vérifiez que le composant est bien activé dans votre profil.
• Pour une installation de production, testez d'abord le flux complet sur une machine ou un profil isolé.

Exemple de parcours logique

1. Lire la page courante pour comprendre hermes agent mémoire skills.
2. Ouvrir le hub parent du cluster memoire-skills.
3. Passer ensuite aux pages complémentaires proposées dans « À lire ensuite ».
4. Revenir à la documentation officielle si vous avez besoin du détail exact ou d'une commande récemment modifiée.

FAQ rapide

Cette page remplace-t-elle la documentation officielle ?

Non. Elle sert de guide francophone structuré. Le lien vers la source officielle est disponible en bas de page.

Les commandes sont-elles garanties à jour ?

Elles sont basées sur la documentation officielle récupérée au moment de la génération. Pour un usage critique, vérifiez toujours la page officielle liée en bas.

Pourquoi autant de liens internes ?

Hermes Agent est un système modulaire. L'installation, les providers, les outils, la mémoire, les skills, la sécurité et les plateformes se répondent. Le maillage interne aide à suivre ce chemin sans tomber sur des pages orphelines.

Comment lire cette page efficacement

Commencez par identifier votre situation : installation locale, usage serveur, configuration d'un provider, connexion à une plateforme, automatisation ou usage développeur. Hermes Agent est modulaire : une fonctionnalité dépend souvent d'un autre bloc. Par exemple, une automatisation cron devient réellement utile quand le modèle, les outils et le canal de livraison sont déjà configurés.

Pour éviter les erreurs, avancez toujours dans cet ordre : vérifier le prérequis, appliquer la commande ou la configuration, relancer une session si nécessaire, puis tester avec une action simple. Si le résultat ne correspond pas à ce qui est attendu, revenez à la page officielle liée en bas et comparez la version de votre installation avec la documentation actuelle.

Bonnes pratiques

• Garder une configuration minimale tant que le premier test n'est pas validé.
• Ajouter les outils et plateformes progressivement.
• Séparer les profils si plusieurs usages doivent cohabiter.
• Documenter les procédures répétées dans des skills plutôt que dans de longs prompts.
• Vérifier les droits, tokens et scopes avant d'accuser le modèle ou Hermes Agent.
• Relancer la session après un changement de configuration important.

Erreurs fréquentes

La première erreur consiste à activer trop de choses trop tôt. Plus la configuration initiale est large, plus le diagnostic devient difficile. La deuxième erreur consiste à confondre un problème de provider avec un problème Hermes : si le modèle ne répond pas, vérifiez d'abord l'authentification, la clé API, le nom du modèle et le provider sélectionné. La troisième erreur consiste à oublier que certains changements ne s'appliquent qu'à une nouvelle session ou après redémarrage du gateway.

Suite recommandée

Après cette page, ouvrez les liens internes proposés dans la section « À lire ensuite ». Ils ont été choisis pour suivre une progression logique dans le même site, sans envoyer vers l'autre domaine.