Migrer ne veut pas seulement dire « ça démarre »
Hermes Agent vise clairement les utilisateurs OpenClaw ; Hermes Agent OpenClaw migration devient donc un vrai sujet d’exploitation. La question utile est de savoir si l’équipe garde ses garde-fous : secrets limités, runners isolés, revues humaines, journaux, limites de coût et rollback.
Hermes, par Nous Research, apporte mémoire persistante, skills, messageries, cron, subagents, MCP et plusieurs backends de terminal. Office Claws est séparé de Hermes et d’OpenClaw ; son rôle honnête est l’exploitation locale/VPS de workflows Codex avec contrôle desktop et revue explicite.
Ce qui change par rapport à OpenClaw
Hermes n’est pas un simple CLI de code. Sa documentation décrit un agent capable de créer et améliorer des skills, mémoriser entre sessions, travailler depuis de nombreux canaux, planifier des tâches, lancer des subagents et s’exécuter localement, dans Docker, via SSH ou sur des backends serverless.
| Zone | À vérifier avant migration |
|---|---|
| Installation | Qui installe, quel compte modèle est utilisé, desktop ou CLI |
| Runtime | Local, Docker, SSH, serverless ou VPS; lieu du code, des logs et secrets |
| Mémoire | Ce qui persiste, ce qui est rappelé, comment supprimer |
| Skills | Ce qui est importé, créé ou réutilisé, et qui relit |
| Cron | Les actions futures ont besoin d’un propriétaire et d’un chemin d’échec |
| Messagerie | Telegram, Discord, Slack ou email élargissent le périmètre |
| Subagents | Le parallèle exige branches isolées et discipline de merge |
| Providers | Plus de modèles signifie plus de politiques coût/données |
Checklist de migration sûre
- Inventorier prompts, skills, MCP, profils navigateur, tokens, webhooks, cron et tâches longues.
- Séparer le contexte descriptif du comportement exécutable.
- Tourner les secrets ou les remplacer par des jetons très limités.
- Choisir une frontière claire : conteneur, runner SSH ou VPS plutôt qu’un shell local ouvert.
- Recréer les gates : pas de push sur main ni de prod sans humain.
- Tester d’abord sur un dépôt sans risque.
- Documenter les mémoires, skills, gateways et plannings activés.
Ce qui se transfère proprement
Les conventions de dépôt, commandes de test, préférences de style, notes d’architecture et runbooks sont les plus sûrs. Les scripts shell, sessions navigateur, MCP en écriture, tokens de bots et anciens cron jobs doivent être recréés consciemment.
Avec Office Claws pour des opérations proches d’OpenClaw, gardez le modèle simple : runner neuf, une tâche, une branche, logs visibles, PR obligatoire et reset du runner. Ce schéma complète OpenClaw vs Codex, OpenClaw background tasks et les essais Hermes.
Architecture cible
- Expériences Hermes dans une sandbox, un conteneur, un runner SSH ou un VPS jetable.
- Changements de code uniquement sur branches de fonctionnalité.
- Secrets injectés par runner, jamais copiés depuis d’anciens workdirs.
- Gateways de messagerie limités au strict nécessaire.
- Cron avec propriétaire, dépôt, branche et action en cas d’échec.
- Office Claws ou un autre manager pour suivre runner, logs, coût et PR.
Recommandation
Ne copiez pas tout avant d’auditer. Déplacez le contexte, puis l’autorité exécutable, puis seulement les droits de production. Une bonne migration Hermes Agent OpenClaw est volontairement ennuyeuse : runner frais, secrets limités, une branche, une PR, aucun déploiement sans revue.
Sources et lectures liées
- Documentation Hermes Agent : https://hermes-agent.nousresearch.com/docs/
- Dépôt NousResearch/hermes-agent : https://github.com/NousResearch/hermes-agent
- OpenClaw vs Codex
- OpenClaw Desktop Manager
- OpenClaw Security Best Practices