J'ai testé à la fois Hermes et OpenClaw sur une installation d'agent Raspberry Pi auto-hébergée, et la version courte est simple : je préfère Hermes.
Ce n'est pas parce qu'OpenClaw est mauvais. OpenClaw est impressionnant, surtout si ce que vous voulez est un large assistant AI personnel qui peut se cacher derrière des canaux de messagerie et se sentir comme un assistant local-first. Selon la documentation d'OpenClaw, il est construit autour d'une passerelle multi-OS pour les agents AI à travers WhatsApp, Telegram, Discord, iMessage, et plus encore. C'est une idée forte.
Mais après avoir essayé les deux dans un environnement local réel, Hermes se sent plus proche de la façon dont je veux réellement faire fonctionner les agents : rôles séparés, compétences réutilisables, mémoire qui devient contexte opérationnel, et flux de travail en arrière-plan qui peuvent continuer à fonctionner sans devenir un assistant géant et désordonné.
Cette comparaison Hermes vs OpenClaw n'est pas un benchmark. C'est une note pratique tirée de l'utilisation des deux sur mon propre matériel.
Hermes vs OpenClaw en termes simples
De mon point de vue, OpenClaw est le plus fort en tant qu'assistant AI personnel axé sur la messagerie. Il vous donne une passerelle d'agent local, des fichiers de travail familiers, et un écosystème en pleine croissance autour des canaux, des sessions, des compétences, des surfaces web, des tâches cron, et des applications compagnon. Si votre question principale est "comment puis-je envoyer un message à un agent AI qui vit sur mon propre matériel ?", OpenClaw vous donne une réponse claire.
Hermes est différent. Selon le dépôt GitHub de l'agent Hermes, c'est un agent AI auto-améliorant avec une boucle d'apprentissage, des compétences, de la mémoire, de la messagerie, une intégration MCP, une planification cron, des fichiers de contexte, et un support de migration depuis OpenClaw. Ce langage correspond à la façon dont cela se ressent en pratique. Hermes ne concerne pas seulement la communication avec un assistant. Il s'agit de transformer un travail répétitif en un comportement réutilisable.
Cette différence compte plus que la liste des fonctionnalités.
Avec OpenClaw, j'avais l'impression de configurer un assistant puissant. Avec Hermes, j'avais l'impression de façonner une petite couche opérationnelle pour le travail.
Mon installation n'est plus une démo
Cela compte parce qu'une installation d'agent Raspberry Pi peut rapidement passer de "l'expérience intéressante" à "l'outil opérationnel toujours actif".
Une fois qu'un agent commence à aider avec la maintenance, la recherche, le contenu, les tâches administratives, ou les vérifications récurrentes, le problème change. La question n'est plus seulement de savoir si le modèle peut répondre. La question devient de savoir si le système a des limites claires.
C'est la partie qui m'intéresse. Je ne veux pas d'un agent avec accès à tout et une personnalité vague. Je veux des identités opérationnelles plus petites :
Hermes a rendu cette structure naturelle. Je peux façonner chaque rôle avec ses propres instructions, comportement de mémoire, outils, et position d'approbation. Un flux de travail à haut risque peut être conservateur et s'arrêter en cas d'incertitude. Un flux de travail de contenu peut être plus créatif. Un flux de travail de maintenance peut être direct et axé sur une liste de contrôle.
C'est plus proche des opérations réelles qu'un seul assistant qui essaie d'être tout.
La limite de profil est le produit
La chose la plus importante que j'ai apprise est que la qualité de l'agent ne dépend pas seulement du modèle. Cela dépend aussi de la limite autour du modèle.
Un assistant lié aux finances ne devrait pas se comporter comme un assistant de contenu. Un assistant de maintenance ne devrait pas se comporter comme un assistant de recherche. Un assistant de rédaction de mémoire ne devrait pas collecter des faits temporaires bruyants de manière décontractée. Chaque rôle a besoin d'un travail étroit, d'un ton clair, et d'un modèle de permission qui correspond au risque.
Hermes rend ce design ordinaire. Je peux séparer le travail avant que le modèle ne voie jamais la tâche.
C'est pourquoi Hermes vs OpenClaw n'est pas seulement une comparaison technique pour moi. C'est une comparaison de flux de travail.
Ce que j'ai aimé d'OpenClaw
OpenClaw a encore de réelles forces. Il est facile de comprendre pourquoi les gens sont enthousiastes à son sujet. Le projet est construit autour de l'idée d'un assistant local que vous pouvez contacter depuis différentes surfaces, et sa documentation couvre les sessions, les tâches cron, la sécurité, les surfaces web, les compétences, l'accès à distance, et les applications compagnon mobiles.
Le dépôt GitHub d'OpenClaw montre également l'échelle de l'écosystème. C'est un projet lourd en TypeScript avec beaucoup de dynamisme communautaire. Si votre objectif est d'expérimenter avec un assistant personnel qui communique via des applications de messagerie, OpenClaw est une option sérieuse.
J'aime aussi le modèle de personnalité basé sur les fichiers. Le modèle de travail d'OpenClaw utilise des fichiers familiers pour l'identité, les instructions, les outils, et le contexte utilisateur. C'est un bon modèle mental : l'agent a un foyer, un rôle, des notes locales, et de la mémoire.
Il y a quelque chose de propre là-dedans. C'est compréhensible. C'est facile à expliquer. Cela rend l'assistant moins jetable.
Mais pour mon cas d'utilisation, cela semblait encore plus comme une plateforme d'assistant général. Je pouvais le rendre utile, mais je devais pousser plus fort pour obtenir la même sensation de rôles opérationnels séparés.
Pourquoi Hermes s'adapte mieux
Hermes ressemble plus à un système d'exploitation d'agent pour les personnes qui souhaitent continuer à améliorer leurs flux de travail.
La plus grande différence pour moi est la façon dont Hermes prend en charge un travail persistant et ciblé.
Je ne veux pas d'un assistant qui se souvient de trivia aléatoires. Je veux un système qui se souvient de la façon dont le travail doit être fait : quel style utiliser, quand s'arrêter, ce qui nécessite une vérification, ce qui ne doit jamais être envoyé à l'extérieur sans approbation, et quels types de tâches appartiennent à quel rôle.
Ce type de mémoire est pratique. Il ne s'agit pas de rendre l'agent plus personnel. Il s'agit de rendre le travail répétitif moins fragile.
Hermes rend également la séparation des profils propre. Un flux de travail sensible peut avoir des règles strictes. Un flux de travail de recherche peut se concentrer sur les preuves. Un flux de travail de contenu peut se concentrer sur la structure et la clarté. Un flux de travail de maintenance peut se concentrer sur les vérifications, les journaux, et la récupération.
Pour moi, c'est là que Hermes gagne : pas dans une liste de fonctionnalités, mais dans la discipline opérationnelle.
L'angle Raspberry Pi
Faire fonctionner cela sur un Raspberry Pi change également ma façon de penser aux frameworks d'agents.
Un Pi est petit, bon marché, toujours allumé, et ennuyeux de la meilleure façon. Cela en fait un bon foyer pour les agents en arrière-plan. Mais cela impose également une discipline. Vous ne pouvez pas le traiter comme un poste de travail cloud infini. Vous avez besoin de processus clairs, de journaux, de profils, et de limites.
Hermes a été plus facile à mapper sur cette réalité. Je peux exécuter des flux de travail en arrière-plan ciblés, garder la mémoire ciblée, utiliser des routines planifiées, et connecter le système à un travail utile au lieu de simplement exécuter des expériences.
OpenClaw peut également fonctionner localement et a une ergonomie axée sur la messagerie forte. Mais ma préférence personnelle est Hermes parce qu'il se sent moins comme un assistant intelligent et plus comme une infrastructure que je peux continuer à façonner.
C'est aussi pourquoi je pense encore au travail d'agent précédent dont j'ai parlé dans Construire des agents AI qui fonctionnent réellement→. Le problème central n'est pas "un agent peut-il répondre ?" Le vrai problème est de savoir si le système peut continuer à fonctionner avec supervision, traçabilité, et limites utiles.
Où OpenClaw peut encore être le meilleur choix
Je ne dirais pas à tout le monde de choisir Hermes.
OpenClaw peut être un meilleur choix si vous voulez le chemin le plus rapide vers un assistant personnel avec lequel vous pouvez communiquer via des applications de messagerie. Cela peut également être mieux si vous souhaitez profiter de l'écosystème plus large, tester des intégrations communautaires, ou expérimenter avec une couche d'assistant plus orientée consommateur.
C'est précieux. Beaucoup de gens ne veulent pas concevoir des profils opérationnels. Ils veulent un assistant qui vit sur une boîte et répond depuis leur téléphone.
Pour cela, OpenClaw a du sens.
Hermes devient plus intéressant lorsque votre question passe de "puis-je envoyer un message à mon agent ?" à "puis-je construire plusieurs agents qui continuent à améliorer des flux de travail spécifiques ?"
Cette deuxième question est ma question.
Le point de la vie privée
Une chose que je ne voudrais pas ignorer avec l'un ou l'autre outil : les agents locaux sont puissants.
Une fois qu'un agent peut lire des fichiers, exécuter des commandes, utiliser des navigateurs, parler à des API, ou interagir avec des systèmes d'entreprise, il n'est plus seulement un chatbot. C'est une infrastructure avec des permissions. Cela signifie que les règles d'approbation, les profils ciblés, l'hygiène de la mémoire, et les valeurs par défaut conservatrices comptent.
Cela signifie également que vous devez faire attention à ce que vous publiez publiquement. Un article de blog peut parler d'architecture et de leçons sans exposer des noms d'hôtes, des chemins exacts, des noms de clients, des noms de profils, des jetons, des détails de flux de travail privés, ou quoi que ce soit qui aiderait quelqu'un à cartographier votre système réel.
C'est une autre raison pour laquelle je penche vers Hermes. Mon installation actuelle me pousse vers la séparation : rôles différents, emplois différents, mémoire différente, attentes différentes. Cela ne le rend pas automatiquement sûr, mais cela rend la sécurité plus facile à raisonner.
Une erreur dans un brouillon est une chose. Une erreur dans un flux de travail sensible est différente. L'installation de l'agent devrait le refléter.
C'est aussi pourquoi je reviens toujours à la même leçon du développement assisté par AI : la vitesse n'a d'importance que si le système reste révisable. J'en ai parlé d'un point de vue de codage dans Développement assisté par AI : 102 commits en 7 jours en tant que développeur solo→. La même logique s'applique ici.
Ma conclusion actuelle
Si quelqu'un me demandait lequel essayer en premier, je répondrais en fonction de ce qu'il veut.
S'il veut un large assistant personnel basé sur la messagerie avec un grand écosystème, OpenClaw vaut la peine d'être testé.
S'il veut un système plus structuré pour des agents spécifiques au travail, auto-hébergés et de longue durée, je commencerais par Hermes.
Pour ma propre installation Raspberry Pi, Hermes est le meilleur choix. Il correspond à la façon dont je construis réellement : rôles petits et ciblés, compétences réutilisables, mémoire persistante, routines planifiées, et limites opérationnelles claires.
OpenClaw m'a montré la forme des assistants AI locaux. Hermes se sent comme celui avec lequel je peux continuer à vivre.
C'est mon retour sur Hermes vs OpenClaw après avoir testé les deux : OpenClaw est excitant, mais Hermes s'adapte mieux à mon travail d'agent réel.