J'ai créé un système d'exploitation collaboratif IA à 5 rôles avec OpenClaw : Analyse technique complète

J'ai passé beaucoup de temps à transformer OpenClaw, d'un simple assistant à un système d'exploitation collaboratif multi-rôles. Il ne s'agit pas simplement d'« ouvrir quelques bots pour discuter séparément ».

5 rôles IA, partageant une même passerelle, fonctionnant sur les canaux Discord et Telegram, avec une répartition claire des tâches, du routage, de l'isolation mémoire et des règles de collaboration, capables de travailler en relais comme une équipe.

Dans cet article, je détaille tout le processus de construction, les décisions de conception à chaque niveau, les configurations spécifiques et les pièges que j'ai rencontrés.

Si vous utilisez aussi OpenClaw ou si vous êtes intéressé par « comment faire collaborer plusieurs IA », cet article devrait vous aider à éviter de nombreux détours.

Conclusion avant tout : Ce n'est pas du « multi-bot », c'est un OS multi-agent sous une seule passerelle

Quand on entend « 5 rôles IA », la première réaction est souvent : tu fais tourner 5 bots indépendants, non ?

Oui, mais aussi non.

Mon architecture ressemble à ceci :

• 1 processus de passerelle, unifiant l'accès aux canaux et le routage
• 5 Agents indépendants : Commandant, Stratège, Ingénieur, Créateur, Penseur
• Chaque Agent possède son propre espace de travail (personnalité, règles, mémoire et sessions sont tous isolés)
• Fonctionne sur les canaux Discord + Telegram simultanément (peut fonctionner sur plusieurs plateformes, mais j'utilise seulement Discord), avec des liaisons pour une distribution précise des messages
• Les discussions privées et de groupe utilisent des mécanismes complètement différents

Une analogie : Ce n'est pas embaucher 5 personnes et les jeter dans une pièce pour qu'elles agissent librement. C'est construire une entreprise — avec une structure organisationnelle, des descriptions de poste, des protocoles de communication, des bureaux indépendants et des règles de réunion.

OpenClaw lui-même est un framework d'assistant IA personnel open-source qui supporte plusieurs plateformes (Discord, Telegram, WhatsApp, etc.) et plusieurs modèles (Claude, GPT, Gemini, etc.), avec des données entièrement localisées.

Sa capacité multi-agent est la raison principale pour laquelle je l'ai choisi — support natif pour des espaces de travail indépendants multi-agent + routage par liaisons, ce qui m'a permis de construire un véritable système collaboratif par-dessus.

1. Architecture globale : Passerelle unique + Multi-agent + Multi-espace de travail + Multi-canal

Commençons par les décisions architecturales de base.

1) Hébergement unifié via une passerelle unique

J'ai actuellement un seul processus de passerelle OpenClaw qui porte toutes les capacités — accès aux messages, routage, gestion de sessions, appels d'outils, indexation mémoire et gestion d'état, le tout dans une seule passerelle.

Pourquoi ne pas faire tourner un ensemble de services pour chaque rôle ? Trois raisons :

• Maintenance centralisée : Une seule passerelle à maintenir, pas besoin de services indépendants pour chaque rôle.
• Configuration unifiée : Un seul fichier de configuration principal gère les stratégies globales, et la surveillance/dépannage sont également centralisés.
• Fondation pour la collaboration : Pour que les rôles collaborent, ils doivent être dans le même environnement d'exécution pour une communication efficace.

2) 5 Agents parallèles, pas 5 bots décousus

Mes 5 rôles fixes :

• Commandant (zongzhihui) : Conscience de la situation globale, décomposition des tâches, assignation, correction et clôture.
• Stratège (junshi) : Analyse stratégique, évaluation des propositions et prédiction des risques.
• Ingénieur (engineer) : Exécution technique, implémentation de code et maintenance système.
• Créateur (creator) : Création de contenu, optimisation de l'expression et production externe.
• Penseur (zhiku) : Audit des connaissances, contrôle qualité et vérifications de conformité.

Chaque agent possède son propre espace de travail, comme workspace-engineer, workspace-junshi, etc. Les fichiers de personnalité, de règles, de mémoire et les ressources de scripts sont tous indépendants et ne se contaminent pas mutuellement.

3) Accès double pile multi-canal : Discord + Telegram

La même passerelle est connectée à la fois à Discord et à Telegram. Chaque rôle dispose de liaisons au niveau accountId sur les deux canaux. Bien sûr, vous pouvez utiliser ce même fichier de configuration pour intégrer d'autres plateformes comme Lark, WeChat, etc.

Ce n'est pas un « déploiement en double sur plusieurs plateformes », mais « le même cluster cérébral, différentes couches d'accès ». J'ai configuré Discord comme principal champ de bataille de collaboration.

Si vous voulez que plusieurs agents coopèrent et collaborent dans un groupe, choisissez simplement Discord ; une plateforme suffit. Les autres ne sont pas parfaites, je les ai testées !!!

2. Couche de routage : Les liaisons associent les « comptes » aux « rôles »

C'est la logique d'entrée de tout le système.

J'ai configuré une stratégie de liaison explicite pour les deux canaux : channel + accountId -> agentId.

En pratique :

• discord + zongzhihui -> zongzhihui
• discord + engineer -> engineer
• telegram + creator -> creator
• ... soit 10 correspondances au total (5 rôles × 2 canaux)

Pourquoi faire cela ?

Parce que le système décide « qui doit traiter ce message » au niveau de l'entrée, plutôt que de laisser tous les agents l'entendre puis se précipiter pour répondre. Si cette étape n'est pas bien faite, toute la collaboration ultérieure sera chaotique.

Vous pouvez considérer les liaisons comme le « triage à l'accueil » de ce système. Quand un message arrive, il vérifie d'abord quel canal et quel compte l'ont reçu, puis le route directement vers le rôle correspondant — propre et efficace.

3. Isolation des sessions : Pourquoi les discussions privées ne se croisent pas et les discussions de groupe ne sont pas en désordre

C'est l'un des points d'ingénierie les plus critiques de mon système.

Configuration centrale : session.dmScope = per-account-channel-peer

Ce paramètre signifie : Le contexte de discussion privée est isolé selon trois dimensions : « compte + canal + pair utilisateur ».

Pourquoi ce choix ?

• Si la même personne contacte le même rôle via Discord et Telegram, les contextes ne se croisent pas.
• Si différents utilisateurs contactent le même rôle, les contextes sont complètement isolés.
• Dans les scénarios multi-agent + multi-compte, le risque de « dialogue croisé » est minimisé.

En d'autres termes, je n'ai pas seulement créé des « multi-rôles » ; j'ai aussi fait de « l'ingénierie de stratégie d'isolation de contexte ».

Beaucoup de gens construisent des systèmes multi-agents avec des rôles bien définis, mais la gestion du contexte est un fouillis — le contenu des discussions privées de l'utilisateur A se retrouve dans la réponse de l'utilisateur B, ou la mémoire des conversations Discord contamine le contexte Telegram.

per-account-channel-peer est la stratégie d'isolation recommandée par OpenClaw pour les scénarios multi-comptes, et mes tests montrent que c'est effectivement le choix le plus stable.

4. Orchestration des discussions de groupe : Collaboration pilotée par les règles, pas de discussion libre

Cette partie est la plus intéressante et comporte le plus de pièges.

Stratégie centrale : Écoute globale du Commandant + Déclenchement par @ des autres rôles

Ma stratégie de groupe côté Discord est la suivante :

Commandant : requireMention = false (Écoute globale)

• Peut voir tous les messages du groupe par défaut.
• Chargé de saisir la situation globale, de juger si une collaboration est nécessaire, de décomposer les tâches et d'assigner le travail.

Les 4 autres rôles : `requireMention = true` (Déclenchement par @)

• N'agissent que lorsqu'ils sont explicitement mentionnés avec @.
• Réduit le bruit et évite de se marcher sur les pieds.

Chaque rôle est configuré avec `mentionPatterns`

• Par exemple, l'ingénieur peut être déclenché par @Engineer ou [@engineer](https://x.com/@engineer).
• Rend l'invocation dans le groupe plus stable et prévisible.

Quelle est l'essence de cette combinaison ?

• Le Commandant « voit l'ensemble », comme un chef de projet dans une équipe.
• Les rôles spécialisés sont « déclenchés à la demande », comme des experts dans divers postes.
• La parole dans le groupe passe d'une « forme libre » à un « relais contrôlé ».

Effet concret : Vous posez une question dans le groupe, le Commandant juge d'abord de quel type de tâche il s'agit, puis mentionne @ le rôle correspondant pour la traiter. Une fois le rôle terminé, le Commandant boucle la boucle. Tout le processus ressemble à une véritable réunion d'équipe.

5. Discord vs Telegram : Pourquoi Discord est le champ de bataille principal

À strictement parler, ce n'est pas que « seul Discord peut collaborer ». C'est juste que, dans ma configuration actuelle, Discord est le mieux adapté pour l'orchestration de collaboration publique multi-rôle.

Raisons spécifiques :

1. J'ai configuré 5 comptes parallèles sur Discord + un mécanisme clair de @collaboration.
2. Les identités des rôles, les chaînes de conversation et le processus de relais sont tous visibles — cela ressemble à une discussion d'équipe.
3. La stratégie d'écoute globale du Commandant + la porte de mention des autres rôles est plus intuitive dans les scénarios de groupe.
4. J'ai actuellement configuré le groupPolicy de Discord sur open, ce qui offre une plus grande flexibilité.

Côté Telegram, ma stratégie penche vers allowlist + mention gate, plus contrainte et sécurisée, adaptée aux « canaux de production contrôlés ».

Donc, en résumé : Discord est la scène de collaboration.

6. Couche de configuration + Couche de prompt : Gouvernance à double voie

C'est la plus grande différence entre ce système et « juste jouer avec ».

Je ne me fie pas uniquement à la configuration, ni uniquement aux Prompts. J'utilise deux voies qui se chevauchent.

A. Voie de configuration (Contrôle au niveau de la plateforme)

Ce sont des configurations dures au niveau de la plateforme OpenClaw :

• politique de canal : groupPolicy, dmPolicy, contrôlant les stratégies de base pour les discussions de groupe et privées.
• requireMention : Qui doit être mentionné par @ par défaut pour répondre.
• bindings : Mappage de routage des messages.
• dmScope : Granularité de l'isolation des sessions.
• limite de ping-pong agentToAgent : Je l'ai réglée à 0, supprimant directement les allers-retours sans signification entre agents.

Le dernier point est crucial — si vous ne limitez pas le ping-pong entre agents, vous verrez deux IA dans un groupe faire de la politesse, se confirmer mutuellement, et boucler indéfiniment. Le mettre à 0 indique au système : les agents ne doivent pas se ping automatiquement.

B. Voie des règles (Contrôle au niveau du comportement)

Ce sont les fichiers de règles que j'ai écrits dans chaque espace de travail :

• SOUL.md : Le fichier d'âme du rôle — personnalité, ton, responsabilités et plancher de qualité de sortie.
• AGENTS.md : Manuel d'opérations — processus de vérification de collaboration, normes de lecture/écriture mémoire et stratégies de chargement paresseux.
• ROLE-COLLAB-RULES.md : Limites de collaboration spécifiques au rôle et lignes rouges.
• TEAM-RULEBOOK.md : Règles dures unifiées pour l'équipe (partagées par tous les rôles).
• TEAM-DIRECTORY.md : Table de correspondance des rôles aux identifiants réels pour éviter de mentionner @ la mauvaise personne.

L'effet du chevauchement de ces deux voies est : la couche plateforme limite le flux + la couche comportement ajoute des contraintes.

Il ne s'agit pas de tout mettre sur la « conscience de soi » du modèle. Les modèles font des erreurs, dérivent et oublient les règles. Par conséquent, des contraintes dures doivent être définies d'abord au niveau de la configuration, suivies par des orientations douces au niveau du prompt. Double sécurité.

7. Système de fichiers de l'espace de travail : « Bureau indépendant » de chaque rôle

Le squelette de fichiers de chaque espace de travail est fondamentalement cohérent, ce qui est important — cela montre que je standardise, et non que j'empile simplement des fichiers au hasard pour chaque rôle.

Structure de fichiers standard

8. Système mémoire : Chargement paresseux + Hiérarchisation + Archivage

La gestion de la mémoire est l'aspect le plus souvent négligé mais le plus problématique dans un système multi-agent.

Ma stratégie n'est pas de « se souvenir autant que possible », mais une hiérarchisation claire :

1) Journaux à court terme (mémoire quotidienne)

• Enregistre les processus de tâches du jour, les fragments de contexte et les décisions sur le vif.
• Les fichiers sont nommés par date, créant naturellement une chronologie.

2) Mémoire à long terme (MEMORY.md)

• Distille les préférences stables, les décisions à long terme, l'expérience réutilisable et les règles dures.
• Tout n'y va pas ; seules les informations vérifiées et stables sont écrites.

3) Mémoire à long terme de groupe (GROUP_MEMORY.md)

• Ne conserve que les informations réutilisables et sûres du groupe.
• Ne mélange pas le contenu des discussions privées ; c'est une ligne rouge de confidentialité.

4) Archivage à froid (archive)

• Les anciennes données sont archivées périodiquement pour empêcher le contexte actif de devenir incontrôlable.
• Ce n'est pas supprimé, mais déplacé vers un stockage prioritaire bas.

5) Mécanisme de récupération (memory_search + memory_get)

• Rappel sémantique d'abord, puis lecture précise.
• Évite le chargement complet — la fenêtre de contexte est une ressource limitée et ne peut pas être gaspillée.

La valeur centrale de cette hiérarchisation :

• La qualité des discussions privées n'est pas contaminée par l'historique des discussions de groupe.
• La collaboration de groupe n'est pas interférée par le contexte privé personnel.
• La fenêtre de contexte est « chargée à la demande », pas « remplie complètement ».

Je considère le budget de contexte comme un problème de gestion des ressources. Les tokens sont finis ; chaque souvenir inséré occupe de l'espace d'inférence. Donc, chaque bit doit être calculé avec soin.

9. Mode privé vs Mode groupe : Deux stratégies pour le même rôle

C'est quelque chose que beaucoup de gens ne considèrent pas : le même rôle devrait se comporter différemment en discussion privée et en groupe.

Je distingue explicitement les deux modes dans le SOUL.md de chaque rôle :

Mode privé :

• Chaque rôle agit comme un expert solo, traitant les problèmes de l'utilisateur de bout en bout.
• Aucun processus de collaboration nécessaire ; fournir des réponses complètes directement.
• Le standard de qualité est « une personne peut le gérer ».

Mode groupe :

• Effectue un relais incrémental selon les protocoles de collaboration de l'équipe.
• Chaque rôle est responsable uniquement de ce dans quoi il est bon.
• Le Commandant est responsable de la liaison et de la clôture.

Spécifique à chaque rôle :

• Commandant : Reste silencieux et observe par défaut dans les groupes, n'intervient fortement qu'en cas de nécessité pour éviter de couper la parole.
• Ingénieur : Les livrables doivent être exécutables, vérifiables et réversibles — pas seulement fournir une idée.
• Stratège : Les conclusions doivent être accompagnées d'hypothèses et de chemins de vérification — pas seulement sorties de la tête.
• Penseur : Les audits doivent fournir un classement des problèmes + des plans de réparation — pas seulement dire « il y a un problème ».
• Créateur : L'expression ne peut pas sacrifier l'authenticité et l'exécutabilité — pas seulement rechercher l'esthétique.

C'est la source du « même rôle se comportant différemment dans différents scénarios ». Cela ne repose pas sur le jugement propre du modèle, mais est explicitement indiqué via les fichiers de règles.

Derniers mots

Multi-Agent ne consiste pas seulement à ouvrir quelques bots supplémentaires. C'est tout un système d'ingénierie — de la conception architecturale, aux stratégies de routage, en passant par l'isolation des sessions, l'orchestration de la collaboration, la gestion de la mémoire, la gouvernance des règles et les vérifications automatisées ; chaque couche nécessite une conception minutieuse.

OpenClaw fournit une excellente base, mais la quantité d'ingénierie nécessaire pour passer de « fonctionnel » à « qui fonctionne bien » est bien plus grande que ce que la plupart des gens imaginent.

Si vous faites quelque chose de similaire, j'espère que cet article vous donnera quelques références. Bien sûr, ce contenu n'est que le début ; je publierai plusieurs autres articles plus tard pour partager davantage de problèmes « spécifiques et affinés ».