Hermes Agent avec Ollama : mémoire, outils et limites

#Ce qu'est Hermes Agent

Hermes Agent (dépôt NousResearch/hermes-agent) est un agent autonome en ligne de commande, doté d'une interface TUI, d'une passerelle de messagerie (Telegram, Discord, Slack, WhatsApp, Signal) et d'un système de compétences qui se créent et s'améliorent avec l'usage. Il ne remplace pas Hermes 4, qui est un modèle de langage : Hermes Agent est le logiciel qui orchestre les appels d'outils, la mémoire et le terminal, quel que soit le modèle branché derrière.

Le dépôt tourne à un rythme soutenu : la version taguée v2026.9.24 (Hermes Agent v0.21.5), publiée le 24 septembre 2026, regroupe plusieurs centaines de correctifs depuis la version précédente. Le projet est publié sous licence MIT par Nous Research, ce qui autorise un usage professionnel sans redevance, y compris pour un déploiement modifié.

L'agent tourne dans un seul processus passerelle capable de servir plusieurs canaux à la fois : terminal local, Telegram, Discord, Slack, WhatsApp et Signal partagent la même mémoire et le même historique de conversation. C'est ce qui permet de démarrer une tâche depuis son poste de travail puis de la suivre depuis un téléphone, sans dupliquer la configuration du modèle ni de la mémoire d'un canal à l'autre.

#Brancher Ollama en local

Hermes Agent route les fournisseurs OpenAI-compatibles auto-hébergés (Ollama, vLLM, llama.cpp) sous leur propre nom de provider. La documentation officielle est explicite sur le format attendu : un base_url pointant vers le serveur, et une clé d'API vide qui sert de simple espace réservé.

auxiliary:
  compression:
    provider: ollama
    model: qwen3.6:27b-q4_k_m
    base_url: http://127.0.0.1:11434

Une base_url réduite à un simple host:port (sans /v1) reçoit automatiquement le suffixe attendu par l'API OpenAI-compatible : inutile de l'ajouter à la main. Ce même mécanisme fonctionne pour vLLM et llama.cpp en changeant seulement le nom du provider et le port.

Ce même bloc de configuration peut cibler des rôles différents : le modèle de conversation principal, le modèle de compression de contexte, ou le modèle utilisé pour générer un titre de session. Chacun peut pointer vers un provider distinct — par exemple un modèle Ollama local pour la conversation, et un modèle cloud plus rapide réservé aux tâches auxiliaires — ce qui permet de garder la confidentialité sur l'essentiel des échanges tout en évitant qu'un petit modèle local ne ralentisse les tâches secondaires.

#Quel modèle pour l'appel d'outils

Hermes Agent expose plus de 40 outils (terminal, fichiers, navigateur, mémoire, cron) que le modèle doit invoquer via des appels structurés, pas par une simple description en texte. Un modèle Ollama qui n'a pas été entraîné pour le tool-calling — ou une quantification trop agressive du même modèle — répond souvent par une explication au lieu de déclencher l'appel.

Modèle de conversation principal

Privilégiez une variante Ollama explicitement listée comme compatible outils (balise tools sur ollama.com/library) plutôt qu'un modèle générique de chat.

Modèle auxiliaire (titres, compression)

Peut rester léger : Hermes Agent l'appelle après la réponse du tour principal sur un provider local à un seul emplacement, pas en parallèle, pour éviter qu'un serveur mono-slot ne mélange les deux requêtes.

Format d'identifiant

Un provider nommé peut préfixer le modèle, par ex. ollama-local/qwen3.6:27b-q4_k_m ; ce préfixe s'applique aussi quand seule la requête brute (sans préfixe) arrive au serveur.

Un fait à surveiller de près : sur un provider local personnalisé, l'appel du modèle de titre est envoyé après l'arrivée de la réponse du tour, pas en même temps qu'elle. Sur un serveur local à un seul créneau de traitement, cela évite qu'une requête de titre en JSON structuré ne vienne interrompre la génération de la réponse elle-même — un détail d'ordonnancement rarement documenté ailleurs.

#Mémoire : ce qui persiste vraiment

La mémoire de Hermes Agent repose sur des fichiers texte simples, lisibles et modifiables directement : MEMORY.md et USER.md dans le répertoire de profil. Le modèle décide, via un outil dédié, ce qu'il vaut la peine d'y écrire — préférences, faits durables, procédures apprises.

cat ~/.hermes/memories/MEMORY.md
cat ~/.hermes/memories/USER.md

Le point faible documenté par le projet lui-même : un petit modèle local peut annoncer « c'est enregistré » sans avoir réellement appelé l'outil d'écriture. La documentation officielle recommande, pour un modèle local de moins d'environ 30 milliards de paramètres ou à l'appel d'outils peu fiable, de demander explicitement l'usage de l'outil mémoire puis de vérifier le fichier — plutôt que de multiplier les instructions dans le prompt.

#Sécurité : huit couches, pas un mur

Nous Research documente un modèle de sécurité à huit couches : autorisation des utilisateurs, approbation humaine des commandes dangereuses, garde-fous sur l'écriture de fichiers, isolation par conteneur (Docker, Singularity, Modal), filtrage des identifiants transmis aux serveurs MCP, détection d'injection de prompt dans les fichiers de contexte, isolation entre sessions et validation des chemins de travail des outils terminal.

L'approbation des commandes dangereuses se règle via approvals.mode dans le fichier de configuration, avec trois régimes disponibles : automatique, manuel ou intelligent (le mode par défaut recommandé, qui approuve les actions à faible risque et bloque les autres pour validation).

#Limites d'un petit modèle local pour cet agent

Un agent aussi riche en outils que Hermes Agent sollicite fortement la capacité de suivi d'instructions du modèle : mémoire, planification, appels d'outils enchaînés, et parfois sous-agents parallèles. Sur un modèle de 7 à 14 milliards de paramètres en quantification Q4_K_M, attendez-vous à des appels d'outils manqués, des confirmations sans exécution réelle, et une compression de contexte plus fréquente sur les longues sessions.

Rien de tout cela n'est propre à Hermes Agent : c'est la limite connue des petits modèles quantifiés face à des formats de sortie structurés. La réponse documentée par le projet n'est pas d'ajouter des instructions, mais d'utiliser un modèle plus solide au moins pour la phase de configuration initiale, une fois les entrées en mémoire posées, un modèle plus léger peut ensuite les relire sans problème puisqu'elles arrivent directement dans le prompt système.

Les sous-agents et les scripts Python qui appellent les outils par RPC — deux fonctions mises en avant par le projet pour paralléliser des tâches — reposent sur la même capacité de suivi d'instructions que l'appel d'outil simple. Un modèle qui peine déjà sur un appel isolé aura d'autant plus de mal à orchestrer plusieurs sous-agents sans mélanger leurs contextes respectifs : mieux vaut valider le comportement de base avant d'activer ces fonctionnalités avancées.

#Serveurs MCP : catalogue et permissions

Hermes Agent embarque un catalogue de serveurs MCP revus et fusionnés par l'équipe Nous Research (Linear, GitHub, Figma, Asana notamment), mais chaque serveur reste désactivé par défaut : il faut l'installer explicitement avant qu'il ne devienne accessible à l'agent. Une fois les identifiants renseignés, Hermes Agent interroge le serveur pour lister les outils qu'il expose et affiche une liste à cocher, ce qui évite d'activer d'un bloc toutes les capacités d'un serveur tiers encore mal connu.

Détail que peu de tutoriels mentionnent : pour les serveurs MCP en mode stdio, Hermes Agent ne transmet pas l'environnement shell complet du poste au sous-processus. Seules les variables explicitement déclarées dans la configuration du serveur, plus un socle minimal (PATH, HOME, USER, LANG, TERM, SHELL notamment), sont passées ; les autres variables d'environnement, y compris les clés d'API et jetons, sont filtrées. C'est ce mécanisme qui réduit le risque qu'un serveur MCP tiers mal audité aspire un secret présent dans le shell.

• Comprendre le protocole MCP

#Sous-agents : ce que la délégation permet

L'outil delegate_task permet à Hermes Agent de confier une tâche à un agent enfant : chaque sous-agent démarre sa propre conversation, avec sa propre session de terminal, et n'hérite que des outils déjà activés pour l'agent parent — il ne peut pas s'octroyer une capacité supplémentaire que le parent n'a pas lui-même. Seul le résumé final du sous-agent remonte dans le contexte de l'agent principal ; les appels d'outils intermédiaires n'y entrent jamais, ce qui limite la consommation de contexte sur les tâches longues et évite de polluer la conversation principale de détails d'exécution.

Par défaut, jusqu'à dix sous-agents peuvent tourner en parallèle — une limite configurable, sans plafond matériel imposé par le logiciel — mais la profondeur de délégation par défaut reste fixée à 1 : un sous-agent ne peut pas à son tour créer d'autres sous-agents tant que ce comportement n'est pas activé explicitement dans la configuration. Sur un modèle local de 7 à 14B, mieux vaut garder cette profondeur à 1 : chaque niveau supplémentaire de délégation multiplie le nombre d'appels d'outils à enchaîner correctement, exactement le point faible identifié plus haut pour les petits modèles quantifiés.

#Dépannage : symptômes, cause, correction

La plupart des blocages avec un endpoint Ollama local se résument à quatre familles de symptômes, chacune avec une cause identifiable dans la documentation officielle plutôt qu'une hypothèse à tâtons.

Hermes Agent détecte automatiquement les endpoints locaux et assouplit ses délais de lecture en conséquence, mais un contexte volumineux sur un modèle Ollama lent peut encore dépasser ce délai par défaut ; la documentation officielle recommande d'ajuster la variable HERMES_STREAM_READ_TIMEOUT plutôt que de réduire arbitrairement le contexte envoyé au modèle.

#Installer en pratique

1. 01
   Installer Hermes Agent

   Sur Linux, macOS ou WSL2 : curl -fsSL https://hermes-agent.nousresearch.com/install.sh | bash, puis recharger le shell et lancer hermes.
2. 02
   Préparer le modèle Ollama

   Vérifier qu'Ollama tourne sur le port 11434 et que le modèle choisi est annoncé compatible tool-calling avant de le déclarer comme provider.
3. 03
   Déclarer le provider local

   Utiliser hermes config set pour renseigner provider: ollama, le nom du modèle et le base_url http://127.0.0.1:11434, avec une clé d'API vide.
4. 04
   Tester un appel d'outil simple

   Demander une action vérifiable (lister un dossier, lire un fichier) et confirmer dans le terminal que l'outil s'est bien exécuté, pas seulement décrit.
5. 05
   Contrôler la mémoire

   Demander explicitement une mémorisation puis ouvrir MEMORY.md pour vérifier que l'entrée y figure avant de faire confiance à l'agent sur ce point.

• Faire tourner le modèle Hermes 4 en local
• Connecter des serveurs MCP à Ollama
• Agent IA : définitions et limites générales
• Source : dépôt GitHub officiel Hermes Agent
• Source : documentation de configuration des providers
• Source : documentation du modèle de sécurité