My OpenClaw + Hermes Agent coexistence architecture — am I overthinking or missing obvious risks?
Je configure deux systèmes d'agents d'IA en parallèle sur ma machine Linux Mint : OpenClaw et Hermes Agent. Les deux sont déjà installés avec llama-swap fonctionnant en local. Je souhaite qu'ils coexistent en permanence, chacun gérant des rôles différents, partageant un espace de travail pour l'apprentissage mutuel et se surveillant mutuellement.
Voici ce que j'ai conçu :
Vue d'ensemble de l'architecture
/home/seb/openclaw-workspace/
├── shared-memory/
│ ├── agent-openclaw/ ← Write ONLY by OpenClaw
│ │ ├── daily-logs/
│ │ ├── decisions/
│ │ └── errors/
│ ├── agent-hermes/ ← Write ONLY by Hermes
│ │ ├── daily-logs/
│ │ ├── decisions/
│ │ └── errors/
│ ├── agent-shared/ ← Read-only for agents
│ │ ├── learnings/ ← Merged logs (sync script)
│ │ ├── projects/
│ │ └── decisions-archive/
│ └── sync-agent/ ← Sync scripts on host only
├── workspace/
├── projects/
└── logs/
├── monitor.log
└── cron//home/seb/openclaw-workspace/
├── shared-memory/
│ ├── agent-openclaw/ ← Write ONLY by OpenClaw
│ │ ├── daily-logs/
│ │ ├── decisions/
│ │ └── errors/
│ ├── agent-hermes/ ← Write ONLY by Hermes
│ │ ├── daily-logs/
│ │ ├── decisions/
│ │ └── errors/
│ ├── agent-shared/ ← Read-only for agents
│ │ ├── learnings/ ← Merged logs (sync script)
│ │ ├── projects/
│ │ └── decisions-archive/
│ └── sync-agent/ ← Sync scripts on host only
├── workspace/
├── projects/
└── logs/
├── monitor.log
└── cron/
Principe clé : Aucun accès au socket Docker pour aucun agent. La surveillance est effectuée exclusivement par le système Linux hôte via cron ; aucun conteneur n’a accès à /var/run/docker.sock.
Configuration OpenClaw (2 agents)
Agent de confiance (Planificateur + QA) :
- Outils :
read_file,write_file,list_directory,git,searxng_search,schedule_job - MCP : système de fichiers, recherche searxng, mémoire, tâches cron
- Navigation Web : ❌ interdite
- Accès en écriture :
/workspace
Agent sandbox (Exécuteur + Navigation) :
- Outils :
read_file,list_directory,searxng_search,web_browse - MCP : recherche searxng, mémoire, navigation web (Puppeteer)
- Accès en écriture : lecture seule sur
/workspace/researchuniquement
Espace de travail en mémoire partagée (apprentissage par pollinisation croisée)
/home/seb/openclaw-workspace/
├── shared-memory/
│ ├── agent-openclaw/ ← Écriture réservée à OpenClaw
│ │ ├── daily-logs/
│ │ ├── decisions/
│ │ └── errors/
│ ├── agent-hermes/ ← Écriture réservée à Hermes
│ │ ├── daily-logs/
│ │ ├── decisions/
│ │ └── errors/
│ ├── agent-shared/ ← Lecture seule Pour les agents
│ │ ├── Apprentissages/ ← Journaux fusionnés (script de synchronisation)
│ │ ├── Projets/
│ │ └── Archives des décisions/
│ └── Agent de synchronisation/ ← Scripts de synchronisation uniquement sur l'hôte
├── Espace de travail/
├── Projets/
└── Journaux/
├── monitor.log
└── cron/
Règle : Aucun verrouillage de fichiers basé sur flock. Les agents écrivent exclusivement dans leurs propres dossiers. Le script de synchronisation s'exécute en externe sur l'hôte, en fusionnant les données avec les horodatages et les suffixes .openclaw / .hermes .
Surveillance (Hôte uniquement — Pas de socket Docker)
repair-agent.sh: S'exécute toutes les 10 minutes via cron sur l'hôte Linux Mint- Vérifie si les conteneurs sont opérationnels → redémarrage automatique en cas d'arrêt
- Envoie des alertes Telegram (⚠️ pour un redémarrage, 🚨 pour une panne)
sync-shared-memory.sh: S'exécute toutes les heures via cron sur l'hôte- Fusionne les journaux quotidiens des deux agents dans
agent-shared/learnings/
Pourquoi pas de socket Docker ? Initialement, je comptais l'installer dans un conteneur Hermes pour l'autoréparation, mais j'ai réalisé que cela constituait une faille de sécurité critique. Si l'agent dysfonctionne ou subit une injection de commande, lui donner un accès Docker compromettrait gravement notre système de sécurité. Le moniteur reste sur l'hôte, en dehors des agents.
Phases de déploiement
Phase 1 (Semaines 1 et 2) : Installation parallèle
- Installer les deux systèmes en parallèle
- Configurer 2 bots Telegram distincts (un par agent)
- Tester la communication de base (pas d'automatisation pour l'instant)
Phase 2 (Semaines 3 et 4) : Supervision active
- Activer la réparation et la synchronisation via cron
- Tester les alertes en cas d'arrêt du conteneur et la réparation automatique
- L'espace de travail en mémoire partagée devient opérationnel
Phase 3 (Semaines 5 et suivantes) : Apprentissage croisé
- Pipeline d'apprentissage actif : les agents analysent les décisions et les erreurs des autres
- Le serveur MCP en mémoire fournit un espace de stockage vectoriel pour les connaissances à long terme
- Routage des tâches défini : OpenClaw = stratégique Hermes = Règle opérationnelle : Pas de verrouillage de fichiers basé sur Flock. Les agents écrivent exclusivement dans leurs propres dossiers. Le script de synchronisation s'exécute en externe sur l'hôte, fusionnant les fichiers avec les horodatages et les suffixes .openclaw / .hermes. Surveillance (Hôte uniquement — Pas de socket Docker) repair-agent.sh : S'exécute toutes les 10 minutes via cron sur l'hôte Linux Mint. Vérifie si les conteneurs sont opérationnels → redémarrage automatique en cas d'arrêt. Envoie des alertes Telegram (⚠️ pour un redémarrage, 🚨 pour une panne). sync-shared-memory.sh : S'exécute toutes les heures via cron sur l'hôte. Fusionne les journaux quotidiens des deux agents dans agent-shared/learnings/. Pourquoi pas de socket Docker ? J'avais initialement prévu de le monter dans un conteneur Hermes pour l'auto-réparation, mais j'ai réalisé que cela constituait une faille de sécurité critique. Si l'agent dysfonctionne ou subit une injection de commande, lui donner un accès Docker anéantirait la sécurité que nous avons mise en place. Le moniteur reste sur l'hôte, en dehors des agents. Phases de déploiement Phase 1 (Semaines 1-2) : Installation parallèle Installer les deux systèmes côte à côte Configurer 2 bots Telegram distincts (un par agent) Tester la communication de base, sans automatisation pour l'instant Phase 2 (Semaines 3-4) : Surveillance active Activer la réparation et la synchronisation basées sur cron Tester les alertes en cas d'arrêt du conteneur + réparation automatique L'espace de travail en mémoire partagée devient opérationnel Phase 3 (Semaines 5 et suivantes) : Apprentissage croisé Pipeline d'apprentissage actif — les agents lisent les décisions/erreurs des autres Le serveur MCP en mémoire fournit un stockage vectoriel pour les connaissances à long terme Routage des tâches défini : OpenClaw = stratégique, Hermes = opérationnel
Mes préoccupations spécifiques (Merci de me faire part de vos critiques)
- Est-ce que je surdimensionne ce système ? L'espace de travail en mémoire partagée avec les scripts de synchronisation me semble complexe. Existe-t-il une approche plus simple ? 2. La restriction de l'agent sandbox est-elle suffisante ? Limiter la navigation web à l'agent sandbox uniquement (lecture seule) est-il réellement sûr, ou devrais-je restreindre davantage les serveurs MCP auxquels chaque agent peut accéder ?
- Stratégie de verrouillage des fichiers : J'ai opté pour une séparation stricte des dossiers et un script de synchronisation plutôt que pour Flock (qui est coopératif). Est-ce le bon choix, ou devrais-je utiliser une solution plus robuste comme SQLite pour l'état partagé ?
- Qu'est-ce qui m'échappe ? Y a-t-il une faille évidente dans cette architecture que je n'ai pas prise en compte ? Plus précisément concernant :
- La résolution des conflits entre agents (que se passe-t-il si les deux agents tentent de modifier le même fichier de projet ?)
- Le risque d'injection de requêtes lorsque deux agents se trouvent dans le même espace de travail
- L'isolation réseau Docker : un pont réseau est-il suffisant ou devrais-je utiliser un sous-réseau personnalisé ?