Le multi-agent d’OpenClaw

Un assistant unique est simple. Dès qu’un foyer, une équipe ou une petite entreprise partage une passerelle, la question devient comment séparer les personas, les fichiers et les historiques sans faire tourner des serveurs distincts. OpenClaw y répond en laissant un seul processus de passerelle héberger plusieurs agents isolés, chacun avec son espace de travail, son répertoire d’état et son historique de sessions adossé à SQLite, aux côtés de plusieurs comptes de canal comme deux numéros WhatsApp. Les messages entrants trouvent le bon agent grâce aux liaisons, qui associent un compte de canal à l’un de ces agents. Savoir où cet isolement tient et où il ne tient délibérément pas fait tout l’intérêt de la page.

Ce que possède un agent

• Un agent est la portée complète d’un persona, donc son espace de travail contient les fichiers, les fichiers d’instructions AGENTS.md, SOUL.md et USER.md, les notes locales et les règles de persona, tandis que son répertoire d’état contient les profils d’authentification, le registre des modèles et la configuration propre à l’agent.
• Chaque agent garde l’historique de discussion et l’état de routage dans son propre fichier de session SQLite, à l’intérieur de ce répertoire d’état, et les profils d’authentification sont lus dans le même fichier.
• Réutiliser un même répertoire d’état entre agents provoque des collisions d’authentification et d’état de session, et quand l’identifiant OAuth local d’un agent secondaire est expiré ou que son rafraîchissement échoue, OpenClaw lit l’identifiant de l’agent principal pour le même profil et adopte le jeton le plus frais, sans copier le jeton de rafraîchissement dans le magasin secondaire.
• Un espace de travail est le répertoire de travail par défaut et non un bac à sable strict, si bien que les chemins relatifs se résolvent à l’intérieur alors que les chemins absolus peuvent atteindre d’autres emplacements de l’hôte tant que le bac à sable n’est pas activé.

Si plusieurs liaisons correspondent dans le même palier, la première dans l’ordre de la configuration l’emporte.

Comment le routage décide

Les liaisons sont déterministes et la règle la plus spécifique l’emporte, avec un ordre de paliers complet qui va du correspondant exact au correspondant parent, au joker de correspondant, à la guilde avec rôles, à la guilde, à l’équipe, au compte et au canal, jusqu’à l’agent par défaut. Dans un même palier, l’ordre de la configuration départage. Une liaison qui fixe plusieurs champs de correspondance, par exemple un correspondant et un identifiant de guilde, exige que tous les champs indiqués correspondent. Une liaison qui omet l’identifiant de compte ne correspond qu’au compte par défaut et non à tous les comptes, donc un repli à l’échelle du canal demande un joker de compte explicite et un compte unique demande son nom, et rajouter la même liaison avec un identifiant de compte explicite met à niveau la liaison existante limitée au canal au lieu de la dupliquer. Les canaux qui gèrent plusieurs comptes utilisent un identifiant de compte pour chaque connexion, et chaque identifiant de compte route vers son propre agent, ce qui permet à un serveur d’héberger plusieurs numéros de téléphone sans mélanger les sessions. Quand le compte est omis, un compte par défaut configuré est utilisé, avec un repli sur un compte nommé default s’il existe, sinon sur le premier identifiant de compte configuré dans l’ordre trié. Pour les configurations multi agents existantes, la commande de réparation doctor matérialise l’ancien routage par défaut implicite en liaisons à l’échelle du canal, plus des cibles explicites pour le battement de cœur, le Custodian et Talk, en laissant les configurations à un seul agent inchangées. Elle ajoute aussi une liaison liée au compte quand un compte n’a pas de route de repli mais que ses liaisons plus étroites nomment toutes un seul agent configuré, et elle refuse d’emprunter la propriété à un autre compte ou canal comme de trancher entre des propriétaires en conflit.

Où l’isolement s’arrête

• L’accès aux sessions entre agents est actif par défaut et gouverné par le réglage d’outil d’agent à agent, donc la visibilité des sessions peut être restreinte, les paires d’agents limitées et l’accès ordinaire entre agents bloqué, tandis que des passerelles séparées restent la réponse pour une séparation stricte.
• Le stockage appartenant à une extension suit la configuration de cette extension, donc ajouter un deuxième agent ne scinde pas automatiquement chaque magasin global d’extension, et Memory Wiki par exemple utilise un coffre global unique tant que la portée de son coffre n’est pas fixée à l’agent.
• Le chemin de recherche mémoire entre agents a été retiré avec le reste du moteur QMD en v2026.8.1, donc la mémoire intégrée ne parcourt pas le corpus de transcriptions d’un autre agent et le matériel de référence partagé doit vivre dans un répertoire de recherche supplémentaire explicitement partagé.

Les discussions directes se replient sur la clé de session principale de l’agent par défaut, donc un véritable isolement suppose un agent par personne plutôt qu’une liaison par personne. Voir la référence de la commande agents pour créer et inspecter un effectif en ligne de commande, et l’isolement et le routage des sessions pour l’isolement et le routage au niveau des sessions.

Des liaisons, pas des heuristiques

Le modèle de routage est délibérément ennuyeux. Des paliers déterministes dont l’ordre est documenté se raisonnent facilement à trois heures du matin, et ils échouent de façon prévisible, ce qui compte bien plus que l’ingéniosité quand un message a reçu en silence la réponse du mauvais persona. La même préférence pour l’état explicite se retrouve dans la provenance des agents, où OpenClaw enregistre si un agent a été créé par un opérateur, par l’agent système ou par une installation Claw, conserve l’identifiant de l’agent demandeur, et ne crée un agent demandé par un agent qu’après approbation de l’opérateur. Elle se retrouve encore dans le modèle d’équipe, où un chef de cabinet découvre les spécialistes adaptés, attribue un travail borné, vérifie leurs artefacts et rend un résultat cohérent, tandis que les spécialistes renvoient artefacts et preuves sans déléguer plus loin. Même la préférence de délégation est honnête sur ses limites, puisqu’elle guide le coordinateur vers la délégation du travail approprié et reste une consigne de prompt et non un ordonnanceur. Si vous concevez un effectif, lisez la recherche mémoire intégrée et les espaces de travail et le bac à sable avant de décider ce que ces agents doivent partager.

Sur Diali

Sur Diali, chaque client fait tourner son propre assistant, donc la question de l’isolement se règle à la frontière plutôt qu’à l’intérieur d’un processus partagé. Les canaux se connectent depuis le tableau de bord, la configuration du runtime en est générée et remplacée à chaque version, et l’état vit sur un volume persistant, avec des instantanés quotidiens et une restauration en un clic grâce à l’option Sauvegardes (incluse avec Max). Voir OpenClaw hébergé sur Diali pour ce que nous hébergeons, et La sécurité Diali pour la façon dont nous traitons cet état.

• Une passerelle, plusieurs agents, chacun avec son espace et ses sessions.
• Les liaisons sont déterministes : le plus spécifique, puis l’ordre du fichier.
• Un espace de travail est un répertoire par défaut, pas un bac à sable.