Agents
Deux instances, sept sub-agents
OpenClaw tourne en deux instances indépendantes -- Max et Eva -- sur des machines physiques separees, operees par des personnes différentes. Chaque instance dispose de ses propres sub-agents spécialisés pour des tâches spécifiques.
Agent Topology
Machine 1
Max
mainmail-readerkickoff-codingbridge-readerbridge-voiceMachine 2
Eva
mainbridge-readerMax
Mac dédié, 8 Go RAM
mainOrchestrateur central. Gère les commandes Telegram, la délégation de tâches, l'administration système.
mail-readerTraitement email isole. Exec en mode allowlist, seul le script mail-extract est autorise.
kickoff-codingDéploiement de projets web. Reçoit les briefs clients, génère le code, déploie sur l'hébergement.
bridge-readerSanitiseur jetable pour les messages inter-agents. Zéro outils, timeout 60s, reecrit tout.
bridge-voiceTraité les messages vocaux du bridge. Transcription + traitement en isolation.
Eva
Mac dédié, 8 Go RAM
mainOrchestrateur central. Gère les commandes de messagerie, gestion des tâches.
bridge-readerSanitiseur jetable pour les messages inter-agents. Même pattern zéro-trust que Max.
Avec EasyClaw v2, la personnalite, les capacités et les règles d'un agent sont definies dans un fichier Markdown standard avec frontmatter YAML. Plus besoin de code serveur : tout se fait dans un fichier lisible et versionnable. Modifier un agent devient aussi simple que modifier un document.
Comment ca marche
- 1Creez un fichier Markdown avec les sections standardisees : identité, personnalite, instructions, outils, règles, limites.
- 2EasyClaw lit le fichier au démarrage et construit le prompt système à partir de son contenu.
- 3Un agent peut heriter d'un autre en referençant son fichier. Seules les sections redefinies sont remplacees.
- 4Les modifications sont détectées et appliquees à chaud, sans interrompre les sessions en cours.
EXEMPLE
# Agent: Analyste ## Personnalite Rigoureux et methodique. ## Outils - search, calculator ## Limites - Pas de conseil d'investissement
| 07:00 | Briefing meteo |
| 07:05 | Digest actualites |
| 07:10 | Traitement emails |
| 2x/jour | Distillation mémoire |
| 2x/jour | Reflexions autonomes |
| Toutes les 3h | Cycle memory shepherd |
| Horaire | Extraction mémoire + reindexation |
Les opérations longues (analyse de codebase, migration, tests de regression) s'executent en arrière-plan. L'agent confirme le lancement, puis continue de répondre. L'utilisateur peut à tout moment consulter le statut, mettre en pause ou annuler une tâche.
Cycle de vie d'une tâche
- 1L'agent identifié une opération longue et cree une tâche avec un identifiant unique.
- 2La tâche s'exécuté en arrière-plan. L'agent reste disponible.
- 3Progression en temps réel : pourcentage, étape en cours, temps estimé.
- 4Les résultats sont stockes et consultables via /task status, même après changement de session.
Un daemon de surveillance iMessage poll la base de données système en continu. Chaque message entrant spawne un sub-agent one-shot frais avec des permissions minimales et un timeout strict de 300 secondes. Le sub-agent traite la demande, répond, puis se termine. Aucune session persistante entre les messages.
Un message = un agent = une session. Isolation complète.
ACP dispatch est désactivé sur les deux instances. Tout le routage passe par les skills directes et les crons.
Le pattern Coordinator décompose les tâches complexes en sous-tâches, les délégué aux agents les plus qualifies sur différentes machines, et synthetise les résultats. Le bridge garantit le routage, le rate-limiting et la traçabilité de chaque délégation.
Flux du Coordinator
- 1Le coordinateur reçoit la demande et analyse les domaines impliques.
- 2La tâche est decoupee en sous-tâches indépendantes avec critères de succès.
- 3Chaque sous-tâche est assignee à l'agent spécialisé le plus qualifie.
- 4Les résultats sont collectes, les contradictions resolues, et une synthèse unifiée est produite.