OpenClaw 2026 : orchestration multi-agents (fan-out et pipelines)

Pourquoi l'orchestration multi-agents compte

Un contexte d'agent longue durée accumule du bruit : dumps de recherche, tentatives échouées et logs d'outils gonflent la fenêtre jusqu'à ce que la qualité chute. OpenClaw traite l'orchestration comme un problème de premier ordre — l'agent parent planifie et route ; les workers reçoivent des prompts étroits et des workspaces isolés.

Les équipes adoptent OpenClaw multi-agents quand :

• La génération CI/CD doit toucher plusieurs repos ou services en parallèle (les données benchmark montrent ~3,2× plus rapide en codegen parallèle vs Claude Code agent unique sur des tâches comparables)
• La revue de code bénéficie de lentilles indépendantes (sécurité, style, couverture) sans qu'un seul modèle joue tous les rôles
• Les longs documents ne doivent pas forcer un agent à porter recherche, plan, brouillon et audit dans un seul fil

Le mode d'échec est aussi architectural : exécuter cinq « agents » qui écrivent tous sur les mêmes clés mémoire sans isolation produit des race conditions — la couche d'orchestration doit posséder la logique de fusion et les timeouts.

Modèle d'orchestration OpenClaw

À l'exécution, OpenClaw se résout en un daemon gateway plus des identités d'agents nommées dans la configuration. Les flux multi-agents utilisent :

Règle de profondeur : Deux niveaux (orchestrateur → workers) couvrent ~95 % des charges. Trois niveaux (orchestrateur → team lead → leaf) n'aide que quand les sous-équipes sont vraiment indépendantes — le coût de debug augmente fortement.

Référence externe : OpenClaw GitHub et notes d'architecture communautaires sur maxSpawnDepth / comportement cascade stop.

Trois patterns d'orchestration

Pattern 1 — Fan-out parallèle

Quand : Les sous-tâches ne dépendent pas des sorties les unes des autres.

Forme : L'orchestrateur émet plusieurs spawns en un tour ; wall-clock ≈ worker le plus lent, pas la somme des workers.

Exemples :

• Linter trois packages simultanément
• Rechercher trois URLs concurrentes
• Générer des tests unitaires pour trois services

Anti-pattern : Fan-out d'un pipeline (recherche + brouillon) — le rédacteur démarre avec une entrée vide pendant que la recherche tourne encore.

Orchestrator ├── spawn worker-a (scope: package-frontend) ├── spawn worker-b (scope: package-api) └── spawn worker-c (scope: package-worker) → merge summaries → single PR plan

Pattern 2 — Pipeline séquentiel

Quand : L'étape B a besoin de l'artefact de l'étape A.

Forme : Recherche → plan → implémentation → audit → publication. Chaque worker reçoit un contexte propre avec uniquement le livrable de l'étape précédente collé dedans.

Pourquoi ça gagne : Le rédacteur ne porte jamais 3 000 lignes de tokens de recherche brute ; l'auditeur ne voit jamais l'historique du brouillon pré-audit.

Coût : Le wall-clock est additif — n'utilisez que quand les dépendances sont réelles.

Pattern 3 — Fan-out avec validation

Quand : La précision compte plus que la vitesse (texte conformité, diffs infra, tableaux de tarifs).

Forme : Même prompt à 2–3 workers ; l'orchestrateur ou un agent monitor compare les sorties ; les désaccords déclenchent retry ou escalade humaine.

Coût : ~2–3× dépense tokens vs worker unique — justifié pour les fusions à enjeu uniquement.

Runbook de configuration

Supposons qu'OpenClaw est déjà installé — sinon, complétez d'abord le guide de configuration.

Étape 1 — Définir le roster d'agents dans openclaw.json

Chemin typique : ~/.openclaw/openclaw.json (vérifiez pour votre release).

{ "agents": { "list": [ { "id": "orchestrator", "default": true, "workspace": "~/.openclaw/workspace-orchestrator", "sandbox": { "mode": "off" } }, { "id": "coder", "workspace": "~/.openclaw/workspace-coder", "sandbox": { "mode": "all", "scope": "agent" }, "skills": ["git", "nodejs", "testing"] }, { "id": "researcher", "workspace": "~/.openclaw/workspace-research", "sandbox": { "mode": "all", "scope": "agent" }, "skills": ["web", "docs"] } ] }, "tools": { "agentToAgent": { "enabled": true, "allow": ["orchestrator", "coder", "researcher"] } } }

Étape 2 — Isoler les workspaces par worker

Chaque ID worker doit mapper vers un répertoire workspace séparé. Ne partagez jamais un workspace writable entre workers fan-out parallèles — les races fichier corrompent les fusions.

mkdir -p ~/.openclaw/workspace-{orchestrator,coder,researcher}

Étape 3 — Écrire le prompt système orchestrateur avec table de routage

Le prompt orchestrateur doit lister :

1. IDs workers disponibles et skills
2. Quand fan-out vs pipeline
3. Timeout par spawn (ex. 120 s pour recherche, 300 s pour codegen)
4. Politique d'échec : retry une fois, puis escalade

Règle contexte sub-agent : Les workers doivent recevoir AGENTS.md + TOOLS.md + payload tâche uniquement — pas le fil orchestrateur complet.

Étape 4 — Activer le sandbox pour workers non fiables

Gardez orchestrateur sandbox.mode: off pour les outils de coordination ; sandboxez coders/researchers avec mode: all quand les workers peuvent exécuter shell ou réseau.

Étape 5 — Définir les limites de spawn

Configurez maxChildren / maxSpawnDepth selon la doc de votre version OpenClaw. Commencez avec max 3 enfants parallèles jusqu'à mesure RAM et rate limits API.

Étape 6 — Tester avec openclaw doctor

openclaw doctor openclaw status

Résolvez les hooks dupliqués ou bindings agents conflictuels avant de lancer le fan-out sous CI.

Étape 7 — Exécuter une tâche fan-out contrôlée

Exemple d'instruction orchestrateur (conceptuel) :

Task: Review modules auth/, billing/, notify/ in parallel. Spawn researcher once per directory with identical rubric. Merge into one markdown report with per-module sections. Timeout: 180s per worker. If one worker fails, continue with partial merge and flag gaps.

Loguez le RSS de pointe pendant le test — comparez aux empreintes benchmark.

Étape 8 — Brancher le trigger CI (optionnel)

Exposez le gateway localement ; déclenchez via SSH + REST depuis votre pipeline. Stockez les artefacts sous chemins scopés par tâche :

export TASK_ID="${GITHUB_RUN_ID}" mkdir -p "/tmp/openclaw-runs/${TASK_ID}"

Mémoire, état et discipline de fusion

Contrat de fusion : L'orchestrateur doit définir le schéma de sortie en amont (sections JSON, titres requis). Les workers valident contre le schéma avant handoff.

Matériel et budget RAM

Mesuré sur hôtes Apple Silicon M4 (voir article benchmark) :

L'orchestration ne nécessite pas de GPU — les goulots sont les rate limits API et l'I/O disque sur sync workspace. Pour dimensionner les nœuds par région (latence API uniquement), voir la matrice régions M4.

Gestion des échecs

Définissez explicitement dans le prompt orchestrateur :

Les échecs CI nocturnes tracent souvent vers des timeouts manquants — le défaut « attendre indéfiniment » bloque le gateway.

Parcours recommandé

En une ligne : Si le prompt du worker B a besoin de la sortie du worker A, pipeline. Sinon, fan-out.

FAQ

Combien d'agents OpenClaw peut-il exécuter en parallèle ?

Il n'existe pas de plafond global fixe — les limites pratiques sont la RAM, les rate limits API et la complexité de fusion. Commencez avec 3 workers parallèles, mesurez le RSS de pointe avec ps ou le Moniteur d'activité, puis scalez.

Le fan-out accélère-t-il toujours les tâches ?

Uniquement lorsque les tâches sont indépendantes. Un fan-out mal appliqué sur des étapes dépendantes échoue silencieusement (brouillons vides, travail dupliqué). Cartographiez toujours les dépendances avant de choisir un pattern.

Quelle est la différence entre agentToAgent et sub-agent spawn ?

agentToAgent envoie des messages à des agents persistants nommés (bots vente vs support). Sub-agent spawn crée des workers éphémères pour une branche de tâche unique. L'orchestration CI repose généralement sur spawn ; les bots multi-tenant utilisent agentToAgent plus bindings.

Puis-je exécuter l'orchestration sur un Mac Mini sans location cloud ?

Oui. Tout Mac toujours actif avec Node 22.19+, RAM suffisante et réseau stable fonctionne. Les équipes utilisent des Mac mini dédiés — locaux ou hébergés — quand les portables s'endorment et interrompent les sessions gateway longues.

Quel lien avec TradingAgents ou MiroFish ?

TradingAgents orchestre un débat trading firm (LangGraph). MiroFish orchestre des essaims sociaux pour la prédiction. OpenClaw orchestre les workflows dev (code, CI, revue). Choisissez le framework adapté au domaine — ils sont complémentaires, pas interchangeables.