Première semaine avec Hermes Agent : hygiène de la mémoire, skills et approbation des outils

Le scénario d’échec d’une nouvelle installation Hermes est prévisible : activer tous les jeux d’outils, connecter un canal de messagerie très actif, laisser la mémoire se remplir de bruit, puis se demander pourquoi l’agent « a fait quelque chose d’étrange ». La première semaine doit volontairement rester sans surprise. Votre objectif est une passerelle fonctionnelle, une mémoire limitée et épurée, un seul skill qui prouve son utilité, des écritures de fichiers encadrées, ainsi qu’un terminal désactivé ou isolé avec des approbations et des règles de refus testées.

Ce guide suppose que vous savez déjà ce qu’est Hermes (/articles/hermes-agent-what-it-is). Utilisez le démarrage rapide et le guide d’installation officiels pour votre système d’exploitation. Les commandes et libellés d’interface évoluent ; vérifiez-les donc dans la documentation actuelle le jour de l’installation.

Le premier jour, ne connectez ni la messagerie de production, ni l’accès en écriture au CRM, ni un shell sans restrictions. Commencez en local ou avec un profil jetable, en privilégiant les outils en lecture seule. Désactivez les envois sortants et l’accès au shell, ou isolez le terminal et testez ses approbations et ses règles de refus avant de l’utiliser.

Jours 0-1 : installer, diagnostiquer et vérifier le fonctionnement

1. Installez Hermes par un parcours documenté, par exemple la CLI, Docker ou Desktop, en suivant le guide d’installation officiel.
2. Configurez un fournisseur de modèle que vous utilisez déjà ou un point de terminaison local compatible avec OpenAI. Hermes exige actuellement au moins 64 000 tokens de contexte pour utiliser un agent avec des outils. Confirmez la fenêtre de contexte et la configuration de l’appel d’outils sur le serveur de modèle, et pas seulement que son URL répond (documentation sur les fournisseurs).
3. Exécutez hermes doctor, puis examinez le résultat au lieu de considérer l’existence de la commande comme une preuve du fonctionnement de toutes les intégrations.
4. Ouvrez une seule session de discussion dans la CLI. Demandez une tâche inoffensive : résumer un README public que vous contrôlez ou rédiger un paragraphe. Confirmez les appels d’outils attendus et désactivez les autres.

Critères de réussite du premier jour : vous pouvez démarrer une session, obtenir une réponse du modèle configuré, confirmer au moins 64 000 tokens de contexte utilisable et dresser la liste des outils actifs. Vérifiez séparément les sockets d’écoute et les adresses de liaison. « Rien n’écoute publiquement » n’est vrai que si chaque passerelle, serveur API, webhook, tableau de bord et serveur de modèle activé est désactivé ou lié à l’interface privée ou de bouclage prévue.

Tenez un bref journal d’exploitation : méthode d’installation, point de terminaison du modèle, jeux d’outils actifs et caractère local ou non de la passerelle. En cas de problème après une mise à jour, ce journal peut vous faire gagner plusieurs heures.

Hygiène de la mémoire : ce qui appartient à USER.md et MEMORY.md

La mémoire intégrée de Hermes est limitée et soigneusement sélectionnée. La documentation sur la mémoire décrit les fichiers USER.md et MEMORY.md sous ~/.hermes/memories/. Ils sont injectés sous forme d’instantané figé au début de la session, et l’outil memory permet d’ajouter, remplacer et supprimer des éléments. Donnez à chaque agent exécuté simultanément son propre répertoire personnel ou profil Hermes ; deux processus d’agent ne doivent pas écrire dans le même répertoire. Les fournisseurs externes facultatifs recensés dans la documentation sur les fournisseurs de mémoire complètent la mémoire intégrée.

Mettez dans USER.md (identité stable et préférences) :

• La manière dont vous souhaitez être appelé et les langues utilisées au travail
• Le ton par défaut (direct, sans remplissage ; règles de mélange estonien/anglais si pertinent)
• Les outils et systèmes que vous utilisez, avec leur nom exact (Linear, Notion, abréviation de votre organisation GitHub)
• Les interdictions absolues (« ne jamais valider de commit », « ne jamais écrire aux clients », « demander avant d’utiliser le shell »)

Mettez dans MEMORY.md (faits de travail durables) :

• Les notes de structure de projet qui restent vraies pendant des mois
• Les particularités récurrentes des processus (« la base de préproduction est accessible en lecture seule depuis cet hôte »)
• Les définitions que l’agent confond régulièrement (niveaux de gravité, noms de produits)

Gardez hors des deux :

• Clés API, jetons, mots de passe, codes de récupération
• Tickets clients complets, notes RH, détails de santé, données de paiement
• Bruit éphémère (« j’essaie l’idée X aujourd’hui »)
• Transcriptions de chat entières collées comme « mémoire »

Traitez les fichiers de mémoire comme des espaces de stockage soumis aux mêmes règles qu’un lecteur partagé. Si vous ne laisseriez pas ce texte dans un canal Slack accessible à des prestataires, ne permettez pas à l’agent de le conserver. Préférez une référence telle que « voir la note Client-A-brief dans le coffre » au contenu intégral de la note dans MEMORY.md.

Revue hebdomadaire de la mémoire (15 minutes)

Chaque vendredi pendant le premier mois :

1. Ouvrez USER.md et MEMORY.md.
2. Supprimez tout ce qui est périmé ou trop spécifique.
3. Fusionnez les doublons.
4. Vérifiez qu’aucun secret n’y a été enregistré par erreur au moyen d’un outil.
5. Si vous avez activé un fournisseur de mémoire externe, utilisez ses fonctions documentées de recherche, d’exportation, de suppression et de conservation pour vérifier la présence de données client. Si les contrôles de suppression sont insuffisants, ne lui envoyez pas de données client.

La qualité de la mémoire exige un entretien opérationnel. Si vous le négligez, l’agent réutilisera avec assurance des faits obsolètes.

Skills : mettez-en un en service, pas douze

Les skills constituent une mémoire procédurale : un répertoire contenant SKILL.md et, éventuellement, des scripts et références chargés à la demande. La documentation officielle sur les skills couvre les skills intégrés, ceux du hub et ceux créés par l’agent. Traitez chaque skill externe comme du code et des instructions à vérifier, même lorsqu’un catalogue ou un scanner l’a contrôlé.

Règle pour la première semaine : créez un seul skill pour une tâche que vous effectuez déjà chaque semaine.

Exemple de plan de skill pour « brief ops hebdomadaire » :

# Skill: weekly-ops-brief

## When to use

User asks for the weekly ops brief or Monday status pack.

## Inputs required

- Date range
- Sources allowed (which channels/repos)
- Audience (internal only)

## Steps

1. List incidents and open P0/P1 items from the provided sources only.
2. Separate facts from inferences; mark inferences as [inference].
3. Draft under 400 words: What happened / What’s blocked / Decisions needed.
4. Do not send externally. Output markdown for human copy-paste.

## Stop rules

- If sources are missing, ask once, then produce a partial brief with gaps listed.
- Never invent metrics.

Enregistrez-le dans le répertoire des skills de Hermes en suivant la documentation actuelle. Appelez un skill installé avec /<skill-name>. La commande /skills sert à la gestion et à la vérification, et non à l’invocation générique (référence des commandes slash). N’activez pas dès le deuxième jour toute une place de marché de skills communautaires non vérifiés.

Les skills communautaires peuvent demander à l’agent d’exécuter des commandes shell ou d’appeler des API externes. Lisez SKILL.md comme un script shell trouvé sur Internet. Préférez les skills que vous avez écrits jusqu’à disposer d’un véritable processus de vérification.

Activez explicitement les contrôles d’écriture fournis en amont : skills.write_approval: true pour les skills générés et memory.write_approval: true pour les modifications de mémoire. Ces deux options valent false par défaut. Confirmez-les dans la référence de configuration actuelle, puis testez le refus d’une écriture et inspectez l’état en attente de vérification. Tout skill généré automatiquement reste un brouillon tant qu’une personne ne l’a pas examiné et accepté.

Limites des outils, approbations et isolation : le shell en dernier

Hermes fournit de vastes jeux d’outils, notamment pour le Web, le terminal, les fichiers, le navigateur et l’exécution de code. Configurez-les au moyen de l’interface documentée hermes tools et de la documentation sur les outils.

Posture d’outils recommandée pour la première semaine :

Hermes comporte trois couches de sécurité distinctes qu’il ne faut pas confondre. Les approbations de commandes dangereuses régissent les commandes de terminal signalées au moyen de approvals.mode ; manual demande une approbation pour les commandes signalées, pas pour toutes les commandes. approvals.deny bloque les motifs de commande configurés, même lorsque les vérifications d’approbation sont désactivées. Les écritures de fichiers par write_file et patch reposent sur les chemins protégés et sur l’option facultative HERMES_WRITE_SAFE_ROOT ; elles ne présentent pas de demande d’approbation d’écriture, et un terminal exécuté par le même utilisateur peut contourner cette protection de fichiers. Tirith est un scanner de contenu distinct, exécuté avant l’action, qui par défaut laisse passer le contenu (fail-open) s’il est indisponible. Utilisez Docker, Modal ou un autre bac à sable documenté lorsque l’agent doit être isolé de l’hôte (documentation de sécurité, documentation MCP).

Politique d’approbation pratique pour la première semaine :

• Autoriser délibérément : inspection en lecture seule dans un répertoire de projet désigné, après avoir vérifié quels outils et chemins peuvent encore sortir de ce périmètre.
• Demander ou refuser : commandes de terminal signalées, telles que les suppressions destructrices, l’installation de paquets et les écritures distantes. Placez les interdictions permanentes, comme le force-push ou les motifs de type pipe-to-shell, dans approvals.deny ; une consigne en prose ne les impose pas.
• Ne jamais autoriser sans surveillance : déploiements de production, envois d’e-mails à des clients et actions sur les systèmes de paiement ou d’identité. Retirez ces outils et identifiants, ou isolez-les derrière un service distinct contrôlé par une personne.

Associez cela aux modèles d’intervention humaine de /articles/human-in-the-loop-design-patterns et à la sécurité des connexions de /articles/connecting-ai-safely.

Passerelle de messagerie : attendez que le parcours CLI soit parfaitement maîtrisé

Ne mettez pas Hermes sur un canal Slack/Telegram d’entreprise avant que :

1. Les fichiers de mémoire aient été vérifiés une première fois.
2. Un skill fonctionne dans la CLI.
3. Le terminal soit désactivé ou isolé, et son comportement d’approbation et de refus ait été testé.
4. Vous ayez testé la liste d’autorisation propre à la plateforme ou le parcours d’appariement des messages privés. La passerelle de messagerie refuse les utilisateurs inconnus par défaut, tandis que les périmètres de commande des administrateurs et des utilisateurs ordinaires doivent être vérifiés séparément (documentation sur la messagerie).

Un message privé à vous-même constitue un test raisonnable au quatrième jour. La connexion à un canal d’équipe public doit attendre au moins la deuxième semaine.

Sauvegardez avant de vous y attacher

La CLI officielle fournit hermes backup et hermes import. Une sauvegarde peut contenir .env, des éléments d’authentification, la configuration, des sessions et d’autres états sensibles ; protégez donc l’archive comme un magasin d’identifiants. Arrêtez la passerelle avant l’importation : hermes import écrase les fichiers du répertoire personnel Hermes cible. Avant de dépendre du profil, testez une importation dans un répertoire temporaire isolé et confirmez l’état attendu au lieu de supposer que l’archive est récupérable (référence de la CLI).

Exercice : liste de vérification de la première semaine

Imprimez ou copiez cette liste. N’élargissez pas l’accès aux outils tant que toutes les cases ne sont pas cochées.

• Installation et test de fonctionnement du modèle terminés ; au moins 64 000 tokens de contexte confirmés ; journal d’exploitation enregistré
• Interfaces d’écoute et adresses de liaison actives vérifiées ; aucune surface publique involontaire détectée
• USER.md contient uniquement des préférences et des interdictions absolues
• MEMORY.md reste volontairement limité (un budget initial de 20 faits durables constitue un seuil de vérification possible) ; aucun secret ni dépôt massif de données personnelles de clients
• Un skill personnalisé existe et a été appelé avec succès dans le périmètre volontairement limité de l’exercice
• Approbation de l’écriture des skills et de la mémoire activée, ou écritures correspondantes désactivées
• Racine sûre des fichiers, jeu d’outils du terminal, approvals.mode, règles de refus et bac à sable testés selon le cas
• Au moins une action interdite du terminal ou sur les fichiers a été refusée et vérifiée sur le disque
• Aucune intégration d’envoi ou d’écriture en production connectée
• Sauvegarde sensible effectuée ; passerelle arrêtée ; importation testée une fois dans un répertoire personnel Hermes temporaire
• Messagerie limitée à une interface de test privée, ou utilisation encore réservée à la CLI

À quoi ressemble « terminé » après sept jours

Après avoir terminé la liste, vous disposez d’un profil Hermes avec une mémoire épurée, une procédure vérifiée et des parcours de refus testés localement pour les écritures dans les dépôts et la messagerie. Ces contrôles réduisent le risque ; ils ne prouvent pas que l’agent ne peut pas exploiter une mauvaise configuration ni déclencher un appel d’outil dangereux. L’autonomie viendra plus tard, après la conservation de journaux opérationnels, des tests négatifs répétés et un deuxième skill ayant lui aussi passé la vérification. Cet article documente le plan de test ; ces contrôles n’ont pas été exécutés pour cette analyse.

Ensuite : exécutions pilotées par événements via webhooks (/articles/hermes-webhooks-for-event-driven-agents) et quand garder la plomberie dans n8n (/articles/hermes-vs-n8n-choose-by-job).