OpenClaw a décomposé le travail multi-agent en trois modes : agents autonomes, sous-agents et ACP

OpenClaw a présenté un modèle multi-agents non pas comme une idée abstraite, mais comme un ensemble de modes de fonctionnement pour des tâches réelles dans Telegram. Un utilisateur peut gérer un agent principal et ensuite distribuer les rôles aux exécuteurs permanents, sous-agents temporaires et outils de développement externes via ACP.

Trois modes de fonctionnement

Le schéma OpenClaw est basé sur trois manières différentes de déléguer. La première—des agents permanents séparés avec leur propre dossier de travail, mémoire et instructions. La deuxième—des sous-agents que l'agent principal lance pour une tâche spécifique unique et fournit uniquement le contexte nécessaire. La troisième—ACP, c'est-à-dire un mode où le travail d'ingénierie est exécuté non pas par OpenClaw lui-même, mais par un outil externe connecté comme Codex, Claude Code ou Gemini CLI. Le résultat n'est pas un assistant universel, mais un dispatcher qui peut sélectionner le niveau d'exécution approprié pour le type de travail.

• Agent permanent—pour un rôle nécessaire régulièrement
• Sous-agent—pour une recherche unique ou une partie d'une grande tâche
• ACP—pour les tâches de développement dans un environnement externe
• Agent principal—pour le routage, le contrôle et la compilation des résultats

"La fonctionnalité multi-agents dans

OpenClaw n'est pas un bouton, mais plusieurs modes de fonctionnement pour les agents."

Quand chacun est nécessaire

Les agents séparés dans ce modèle sont utiles là où une tâche se répète et accumule son propre contexte. L'article fournit des exemples simples : un agent pour la recherche, un agent pour la réécriture, un agent pour la publication. Chacun peut vivre dans son propre dossier de travail, mémoriser les actions précédentes et recevoir des tâches à la fois directement et via l'agent principal. Cette approche réduit le chaos : au lieu d'une longue conversation avec des attributions mélangées, émerge un système de rôles où chaque exécuteur a son propre domaine de responsabilité et sa propre mémoire accumulée.

Les sous-agents résolvent un problème différent—comment extraire rapidement du travail unique ou parallèle du flux principal. Si vous devez brièvement étudier un sujet, recueillir plusieurs conclusions ou diviser une grande tâche en pièces indépendantes, l'agent principal peut lancer des exécutions enfants et ensuite consolider les réponses en un seul résumé. Ceci est particulièrement utile pour la recherche et l'analyse préliminaire. Dans ce mode, vous n'avez pas besoin de créer un nouveau participant permanent à l'avance : un sous-agent apparaît pour la tâche, reçoit un contexte limité et disparaît après l'achèvement, sans surcharger le système général avec une mémoire inutile.

Pour le développement, OpenClaw offre une route séparée via ACP. Ici, l'agent principal reste le point d'entrée et l'orchestrateur, mais le code lui-même est écrit par un outil externe. L'article décrit trois scénarios : une session ACP unique pour une tâche d'ingénierie isolée, une session ACP permanente pour un projet à long terme, et la liaison du contexte ACP à un sujet Telegram séparé, où la ligne de discussion technique existe séparément du chat principal. Ce mode est nécessaire quand un projet nécessite un contexte long, des itérations séquentielles et les avantages des outils CLI spécialisés.

Telegram comme panneau de contrôle

L'auteur met un accent particulier sur Telegram comme interface naturelle pour une telle architecture. Un agent permanent peut être lié à un bot séparé ou à la rubrique actuelle, et le contexte ACP technique—à une branche dédiée dans le chat. En conséquence, les rôles et les lignes de travail ne se mélangent pas : la recherche se fait dans un endroit, le développement—dans un autre, tandis que l'agent principal reste le point d'entrée central pour l'attribution des tâches. Pour l'utilisateur, cela ne ressemble pas à une infrastructure complexe, mais à une carte compréhensible de dialogues avec différents types d'exécuteurs.

De cela découle le scénario principal d'OpenClaw : l'agent principal cesse d'être simplement un interlocuteur et devient un coordinateur du système. Il peut envoyer de la recherche à un agent séparé, une sous-tâche unique—à un sous-agent, la partie ingénierie—à ACP via Codex, puis retourner une réponse compilée. C'est-à-dire que l'utilisateur gère non pas chaque action manuellement, mais la logique de distribution du travail. C'est précisément là que réside la valeur pratique de la fonctionnalité multi-agents : moins de micromanagement, plus de spécialisation gérée et de travail parallèle.

Ce que cela signifie

OpenClaw offre effectivement non pas un « agent IA magique », mais un modèle opérationnel pour les équipes et les développeurs solo qui souhaitent distribuer les rôles, le contexte et les outils sur différents canaux. Si cette approche s'enracine, les chats Telegram avec des agents ressembleront de plus en plus à la fois à un IDE léger et à un centre de dispatching simultanément : un point d'entrée, plusieurs exécuteurs et une séparation plus nette entre la recherche, le contenu et le code.