Hermes Agent vs OpenClaw : deux paris architecturaux

Deux projets, même niche

Les deux occupent la même niche : un agent persistant, self-hosted, model-agnostic, branché sur les applications de messagerie courantes (Telegram, Discord, Slack, WhatsApp, etc.), capable d'exécuter des outils sur la machine hôte et de conserver un état d'une session à l'autre. Tous deux sont sous licence MIT, populaires, et changent presque chaque jour. Hermes sait migrer une installation OpenClaw, et OpenClaw importe désormais la mémoire de Hermes : la concurrence est explicite, dans les deux sens.

Quelques repères, relevés le 25 octobre 2026.

Au-delà des chiffres, ce qui sépare les deux projets, c'est leur centre de gravité. Le reste (mémoire, skills, sécurité, identité) découle de ce choix initial.

Un control plane, ou une boucle d'agent

Ce ne sont pas deux variantes d'un même thème. Leurs architectures ont des priorités opposées, et c'est le point à retenir avant le reste.

OpenClaw est un Gateway qui héberge un agent. Un daemon Node.js long-running concentre toutes les responsabilités : bridges vers les messageries (Baileys pour WhatsApp, grammY pour Telegram, etc.), command queue, session manager, exécution des outils, authentification, sandboxing, hooks, scheduler cron. Le runtime d'agent (interne depuis fin mai 2026, dérivé de Pi) est un module parmi d'autres, exposé par WebSocket, et des plugins permettent de le remplacer par d'autres harnesses. Tout transite donc par le Gateway, qui fonctionne en single-writer par session. À la lecture du code, cette architecture donne un contrôle fin sur le routage et l'isolation, au prix d'une complexité concentrée dans le control plane.

Hermes est un agent qui expose des interfaces. La classe AIAgent est le moteur d'orchestration synchrone, et les autres composants gravitent autour : le gateway de messagerie n'est qu'un adaptateur, le cron n'est qu'un déclencheur, l'ACP (Agent Client Protocol, pour les éditeurs) n'est qu'une surface. Le même AIAgent alimente CLI, gateway, cron et batch. La complexité réside dans la boucle d'agent elle-même : son cycle « do, learn, improve » est le sujet du projet, pas une fonctionnalité parmi d'autres.

gateway qui héberge un agent · agent qui expose ses interfaces

Le reste se déduit de là. OpenClaw garde plus de profondeur côté surface, avec ses Nodes qui pilotent caméras, écrans et localisation d'appareils (sans équivalent côté Hermes) et un sandboxing granulaire à plusieurs backends. Hermes a commencé par les mécanismes d'apprentissage (revue des skills en arrière-plan, curator, projet d'évolution offline), qu'OpenClaw a repris depuis à sa façon. Le nombre de messageries ne départage plus les deux : la doc d'OpenClaw recense une trentaine de canaux, celle de Hermes 28 plateformes. Aucun n'est supérieur dans l'absolu, ils résolvent des problèmes différents avec les mêmes briques.

Deux philosophies orthogonales

C'est là que les choix divergent le plus, et c'est ce qui façonne le comportement de l'agent d'une session à l'autre. Les deux empilent des couches, avec des priorités opposées.

OpenClaw : le workspace markdown comme source de vérité

L'agent OpenClaw vit dans un workspace, un répertoire markdown versionnable avec git, où chaque fichier a sa place.

Ces fichiers sont relus au démarrage de chaque session et tronqués pour tenir dans le budget de prompt (bootstrapMaxChars, 20 000 caractères par fichier, et bootstrapTotalMaxChars, 60 000 au total ; USER.md a son propre plafond de 4 000). MEMORY.md n'est chargé qu'en session privée principale, jamais en groupe. Les logs memory/YYYY-MM-DD.md ne sont plus injectés à chaque tour : ils sont indexés pour memory_search et rechargés lors d'un /new.

Par-dessus, un slot mémoire accueille un seul moteur à la fois. L'issue #60572, qui proposait plusieurs slots, a été fermée sans suite en octobre 2026 ; des couches additionnelles comme le wiki cohabitent avec ce moteur unique. Les options :

Le pattern le plus intéressant est le pre-compaction memory flush. Quand la session approche de la limite de contexte, un silent agentic turn se déclenche, qui rappelle au modèle d'écrire les notes durables dans memory/YYYY-MM-DD.md avant que l'auto-compaction ne réécrive l'historique. Le modèle répond NO_REPLY (sentinelle filtrée du payload sortant), et cette turn n'est jamais visible côté utilisateur.

Hermes : la mémoire à trois niveaux (plus une quatrième cachée)

Hermes décrit sa mémoire en trois couches. À la lecture du code, ce sont plutôt trois mécanismes indépendants, mis à jour à des rythmes différents, plus un quatrième.

Tier 1 · la mémoire gelée (~/.hermes/memories/MEMORY.md et USER.md). Deux petits fichiers markdown, plafonnés par défaut à 2 200 et 1 375 caractères (~800 et ~500 tokens, défauts de la config officielle). MEMORY.md stocke les faits, USER.md le modèle de l'utilisateur. Les deux sont curés par l'agent lui-même.

C'est le frozen-snapshot pattern, choisi pour préserver le prompt caching (« prompt caching is sacred », dit l'AGENTS.md du projet). Une modification de la mémoire ne prend effet qu'à la session suivante. Sur les messageries, un chat forme une seule session continue qui survit aux redémarrages, et il faut un /new pour recharger la mémoire. Chez Anthropic, un token lu en cache coûte dix fois moins cher : invalider le préfixe à chaque tour ferait exploser la facture.

Tier 2 · la SessionDB (~/.hermes/state.db). Une base SQLite en mode WAL avec index plein-texte FTS5. Chaque tour de conversation passé y est stocké. L'agent l'interroge à la demande avec l'outil session_search. Depuis la v0.15.0 (mai 2026), cette recherche n'appelle plus de LLM : FTS5 renvoie directement les messages, en quelques dizaines de millisecondes. C'est la mémoire épisodique, « qu'a-t-on fait la dernière fois ».

Tier 3 · provider de mémoire enfichable. C'est un swap-in, pas une couche de plus : un seul provider est actif à la fois, via l'interface MemoryProvider. RetainDB et ByteRover sont intégrés ; Honcho, Mem0, Supermemory et d'autres viennent du catalogue de plugins. Ou rien, si fichiers et FTS5 suffisent.

Tier 4 · les skills comme mémoire procédurale. Hermes ne la nomme pas ainsi, mais c'en est une : ~/.hermes/skills/ stocke des SKILL.md qui encodent des procédures, pas des faits. Détails dans la section suivante.

prompt rechargé à chaque session · prompt gelé pendant la session

Ce que cela change concrètement

L'asymétrie est nette à la lecture du code et des plafonds. OpenClaw semble optimiser pour la lisibilité humaine et l'auditabilité : workspace en clair, git diff sur la mémoire, possibilité d'édition manuelle. Hermes semble optimiser pour le coût et la prévisibilité d'inférence : prompt cache-stable, mémoire active minimale, retrieval on-demand pour le reste. Aucun des deux projets ne formule ce compromis en ces termes, c'est mon interprétation. L'écart se réduit d'ailleurs : OpenClaw a ajouté une frontière de cache dans son prompt, avec un préfixe stable.

Hermes gagne en taux de cache, OpenClaw en transparence et en intervention manuelle.

Deux façons d'apprendre des procédures

Les deux projets respectent le format ouvert agentskills.io (SKILL.md avec frontmatter YAML), donc l'interopérabilité est possible côté schéma. En mai 2026, la différence tenait à leur provenance, écrites à la main chez OpenClaw, générées par l'agent chez Hermes. Depuis, les deux font les deux.

OpenClaw : des runbooks, puis un atelier. La résolution part du workspace, puis des skills du projet (.agents/skills) et de l'utilisateur, puis managed, Workshop et bundled. Le chargement est lazy : seule une métadonnée compacte (nom, description, chemin) entre dans le prompt, environ 97 caractères plus la longueur des champs par skill, et le modèle lit la SKILL.md quand la tâche correspond. Depuis Skill Workshop 2.0 (v2026.10.5), l'agent sauvegarde et corrige aussi ses propres skills. Une revue passe en arrière-plan toutes les 10 itérations du modèle, les skills inutilisées depuis 30 jours sont archivées, et chaque changement peut être annulé. C'est activé par défaut. L'écosystème communautaire reste énorme : environ 52 600 paquets (skills et plugins) sur ClawHub selon un recensement de juin 2026, dont quelque 5 300 skills retenues dans awesome-openclaw-skills.

Hermes : l'apprentissage comme sujet du projet. Les skills s'écrivent à la main, s'installent depuis le Skills Hub ou sont générées par l'agent. La boucle d'apprentissage est la plus ancienne et la plus réglable des deux :

C'est le sens du slogan « the agent that grows with you ». Après quelques semaines d'usage, le répertoire skills/ contient bel et bien des procédures que personne n'a rédigées.

Observé par la communauté : l'agent tend à l'auto-congratulation. Le même système qui auto-génère des skills peut écraser des customisations manuelles par des versions de moindre qualité, le modèle jugeant souvent avoir bien performé y compris quand ce n'est pas le cas. Les retours communautaires sur ce point sont nombreux et convergents (issues GitHub Hermes, threads royosherove, posts Akshay Pachaar), même si je n'ai pas vu de mesure quantitative publiée.

Nous Research propose une parade dans un repo à part, hermes-agent-self-evolution (absent de la doc principale, sans activité depuis juin 2026) : une pipeline DSPy + GEPA (Genetic-Pareto Prompt Evolution, dont le papier de référence est ICLR 2026 Oral) en offline. Au lieu de demander à l'agent une auto-évaluation, GEPA lit les execution traces pour identifier les causes d'échec, et propose des améliorations ciblées par recherche évolutionnaire. C'est une couche de plus à opérer.

Côté gestion, hermes curator pin <skill> protège une skill de l'archivage et de la suppression, tout en autorisant les patches. Recommandé sur les workflows critiques.

Les trois axes secondaires

Moins centraux que la mémoire et les skills, ils pèsent quand même dans le choix.

Identité

OpenClaw place SOUL.md dans le workspace. La personnalité de l'agent est attachée au projet qu'il habite. Le même OpenClaw lancé sur deux workspaces différents produit deux agents avec deux identités. C'est l'agent qui habite un répertoire.

Hermes place SOUL.md dans HERMES_HOME (global à l'instance). La personnalité est une propriété de l'agent lui-même, pas du projet. C'est l'agent unique qui suit son utilisateur.

Pour des projets séparés, OpenClaw convient mieux. Pour un assistant unique, Hermes.

Sécurité

OpenClaw, 7 couches, philosophie operator-driven (la doc parle de défense en profondeur sans chiffrer ; le découpage en sept est ma lecture). Auth Gateway → device pairing & trust → channel allowlists → tool policy (allow/deny global et par-agent) → exec approvals → sandbox (off/non-main/all, workspace ro/rw/none ; Docker ou d'autres backends, désactivé par défaut) → send policy. Le system prompt inclut des guardrails advisory, mais l'enforcement réel passe par les couches techniques. La doc le dit clairement : c'est à l'opérateur de durcir l'installation.

Hermes, 8 couches, philosophie safer-by-default (la structuration en huit est celle de la doc officielle). User authorization (allowlists, DM pairing) → dangerous-command approval → file-write safety → container isolation → MCP credential filtering → context-file scanning (détection de prompt injection) → cross-session isolation → input sanitization. S'y ajoutent protections SSRF, blocklists de sites et filtrage des variables d'environnement. Depuis juillet 2026, les approbations sont en mode smart par défaut : un LLM auxiliaire approuve seul le risque faible et refuse seul le risque élevé.

Le débat est philosophique. OpenClaw suppose un opérateur compétent et lui laisse le contrôle. Hermes fait l'hypothèse inverse : brider par défaut, laisser l'utilisateur desserrer ce qui le gêne. À mon avis, pour un déploiement sur serveur exposé, Hermes part avec une longueur d'avance. Pour un assistant personnel sur localhost, OpenClaw offre plus de souplesse.

Automation

OpenClaw distingue heartbeat et cron. Le heartbeat est un tour périodique dans la session principale (30 min par défaut, 1 h avec une auth Anthropic par OAuth ou token). Depuis la v2026.8.1, c'est un job système et HEARTBEAT.md n'est plus lu. L'agent répond NO_REPLY s'il n'a rien à signaler, ou appelle l'outil heartbeat_respond pour notifier (HEARTBEAT_OK reste toléré). C'est fait pour « passe en revue mon contexte et préviens-moi seulement si quelque chose le mérite ». Le cron a plusieurs modes, dont une session isolée et fraîche à chaque run, adaptée aux jobs à heure fixe (push GitHub à 23 h, rapport quotidien à 8 h).

Hermes a d'abord eu un cron unique, avec entrée en langage naturel. L'utilisateur formule « tous les soirs à minuit, pousse les changements sur ce repo », et l'agent crée à la fois la skill et le cron job, sans crontab à éditer. Les sessions cron ne peuvent pas créer d'autres crons, un garde-fou contre l'emballement. Depuis août 2026, /heartbeat relance périodiquement la session courante quand elle est inactive, et /loop et /goal complètent les primitives.

Que veut-on faire grandir ?

Demander lequel est meilleur est aussi mal posé que MCP contre CLI. Les deux résolvent des problèmes différents avec les mêmes briques, et c'est ce qu'on veut faire grandir qui guide le choix : de l'infrastructure, ou des capacités.

Infrastructure d'agent, ou capacités de l'agent ?

Déployer Hermes là où la transparence de la mémoire, son édition manuelle et la traçabilité git priment, c'est subir le frozen-snapshot et perdre la lisibilité du workspace markdown. À l'inverse, choisir OpenClaw pour un serveur exposé, c'est accepter une sécurité à durcir soi-même.

Quelques signaux orientent clairement. Serveur exposé à plusieurs utilisateurs, surface d'attaque large, besoin de prévisibilité tour après tour : la posture safer-by-default et le cache stable de Hermes paient. Mémoire auditée, appareils physiques (caméras, écrans, localisation) pilotés par les Nodes, relecture de chaque procédure apprise : OpenClaw n'a pas d'équivalent. Si on hésite encore, la question qui tranche est presque toujours la même : préfère-t-on un opérateur qui durcit, ou un agent bridé par défaut ?

Si tu dois décider demain

Provenance des chiffres et claims

• Étoiles GitHub, versions, dates de release : relevées sur les repos publics le 25 octobre 2026. Ces chiffres bougent vite.
• ~52 600 paquets sur ClawHub, ~5 300 skills retenues : recensement Trent AI, juin 2026 (skills et plugins confondus) ; le repo VoltAgent/awesome-openclaw-skills annonce « 5300+ ». Le chiffre de 44 000 cité en mai venait d'un recensement introuvable aujourd'hui.
• Plafonds mémoire Hermes (2 200 / 1 375 chars) : défauts memory_char_limit / user_char_limit dans cli-config.yaml.example du repo public. Repérés initialement par Akshay Pachaar.
• bootstrapMaxChars 20 000 OpenClaw : défaut dans la config officielle, modifiable.
• Pipeline DSPy + GEPA : repo companion hermes-agent-self-evolution. Le papier GEPA (Genetic-Pareto Prompt Evolution) a été présenté en oral ICLR 2026.
• Failure mode d'auto-congratulation : observation communautaire récurrente (issues Hermes, deep-dive royosherove, posts Akshay Pachaar), pas de mesure quantitative publiée à ma connaissance.
• Issue OpenClaw #60572 « Multi-Slot Memory Architecture » : fermée le 22 octobre 2026 sans suite (not planned).
• Curator Hermes (intervalle 7 jours, stale à 14 jours, archive à 30, consolidation désactivée par défaut) : agent/curator.py dans le repo public.
• ~33 canaux OpenClaw / 28 plateformes Hermes : catalogue docs/channels d'OpenClaw et doc « Messaging » de Hermes (le README racine de Hermes en liste encore six), octobre 2026.
• Changements depuis mai : Skill Workshop 2.0 (OpenClaw v2026.10.5, docs/tools/skill-workshop.md) ; retrait de HEARTBEAT.md, TOOLS.md et QMD (OpenClaw v2026.8.1) ; runtime d'agent internalisé (OpenClaw, PR #85341, mai 2026) ; session_search sans LLM (Hermes v0.15.0) ; billet de la fondation OpenClaw (8 juillet 2026).

Méthodologie : les deux projets évoluent quasi-quotidiennement. Tout ce qui est marqué comme « inférence » dans cet article est ouvert à révision si un mainteneur précise ou contredit une lecture. Les claims marqués « fait » s'appuient sur le code ou la doc à la date de rédaction.