Orchestrateur-Workers
Un LLM orchestrateur décompose dynamiquement une tâche en sous-tâches, délègue chacune à un LLM worker, et synthétise les résultats. Contrairement à la parallélisation fixe, l'orchestrateur décide des sous-tâches au moment de l'exécution — ce qui le rend adapté aux tâches complexes dont la décomposition n'est pas connue à l'avance.
Problème
Certaines tâches sont trop complexes pour un seul appel et ne peuvent pas être décomposées à l'avance, car les sous-tâches nécessaires dépendent de l'entrée.
Quand l'utiliser
Utilisez le modèle orchestrateur-workers lorsqu'une tâche nécessite une décomposition dynamique — le nombre et la nature des sous-tâches variant selon l'entrée — et qu'un modèle de coordination peut planifier et intégrer le travail.
Solution
Un modèle principal (orchestrateur) analyse la tâche, décide des sous-tâches nécessaires et délègue chacune à un modèle worker (souvent spécialisé). Il collecte et synthétise ensuite les sorties des workers en un résultat final.
Il s'agit de la généralisation agentique de la parallélisation : la décomposition est décidée au moment de l'exécution plutôt que codée en dur, ce qui ajoute de la flexibilité au prix d'une coordination accrue et d'une plus grande imprévisibilité.
Composants
Avantages
- Gère les tâches complexes avec une décomposition dynamique.
- Les workers peuvent être spécialisés par sous-tâche.
- S'adapte à des entrées variées sans étapes codées en dur.
Risques
- Surcharge de coordination, latence et coût en jetons.
- Plus difficile à prédire et à déboguer que les flux de travail fixes.
- L'orchestrateur peut mal planifier ou boucler sans limites.
Quand ne pas l'utiliser
- Lorsque la décomposition est connue à l'avance — utilisez le chaînage ou la parallélisation fixe.
- Pour les tâches simples qu'un seul appel peut traiter.
- Lorsque la prévisibilité et un contrôle strict des coûts sont primodiaux.
Technologies
Exemples
- Une tâche de codage où le lead décide quels fichiers modifier et délègue les éditions.
- Une tâche de recherche divisée en sous-questions, chacune faisant l'objet de recherches puis d'une synthèse.
- Un rapport complexe assemblé à partir de sections choisies dynamiquement.
Preuves de production
- Contexte
- Déploiement OpenClaw local-first à opérateur unique observé sur 57 jours (161 sessions / 2 776 tours), agrégé à partir des propres traces de trajectoire de l'agent.
- Scénario
- Le travail planifié s'exécute dans des sessions de workers isolées et uniques, dupliquées (forked) depuis le parent, avec une délimitation des capacités et des limites d'enfants/profondeur.
- Technologie
- Runtime d'agent isolé Cron, duplication de session (forkSessionFromParent), un couloir et registre de sous-agents, et limites d'enfants/profondeur par agent.
- Charge
- 57 sessions de workers isolées par cron sur la fenêtre (l'outil explicite sessions.spawn n'a pas été utilisé).
- Résultats
- 57 sessions de workers isolées ont fonctionné sans interférence entre sessions ; l'isolation par duplication de session (forked-session) a été le modèle de worker dominant, tandis que l'outil explicite spawn est resté inutilisé dans cette fenêtre. Déploiement local-first à opérateur unique.
KPI
- Taux de réussite des tâches de bout en bout
- Part des tâches orchestrées qui se terminent correctement sur l'ensemble des sous-tâches ; l'orchestrateur est responsable du résultat global.
- Facteur de division (fan-out) et coût des workers
- Nombre d'appels de workers par tâche et leur coût combiné en jetons ; l'orchestration peut faire exploser les dépenses si la décomposition est bâclée.
- Latence du chemin critique
- Temps réel de la chaîne dépendante la plus longue, et non la somme des workers — cela limite la réactivité.
- Taux d'erreur des sous-tâches
- Fréquence à laquelle les workers individuels échouent ou renvoient des résultats inutilisables, entraînant des tentatives de réessai et de récupération.
Modes de défaillance observés
- Mauvaise décomposition : l'orchestrateur divise mal la tâche, de sorte que des workers corrects produisent tout de même un résultat global erroné.
- Perte de contexte entre l'orchestrateur et les workers, provoquant des résultats partiels incohérents ou contradictoires.
- Explosion des coûts due à la création de trop nombreux workers ou à une imbrication profonde sans limites de budget.
- Point de défaillance unique : si l'orchestrateur évalue mal la situation, l'ensemble de la tâche échoue malgré des workers sains.
Leçons apprises
- Investissez dans la logique de décomposition — la plupart des échecs proviennent de la manière dont le travail a été divisé, et non des workers.
- Transmettez explicitement aux workers le contexte minimal dont ils ont besoin pour éviter les dérives et les contradictions.
- Définissez un budget et une limite de profondeur ; l'orchestration sans limites est la cause de l'envolée des coûts des agents.
- Rendez le plan de l'orchestrateur inspectable afin que les échecs puissent être attribués à une sous-tâche spécifique.
FAQ
- En quoi cela diffère-t-il de la parallélisation ?
- La parallélisation utilise une division fixe et prédéfinie. Orchestrator-workers décide des sous-tâches de manière dynamique au moment de l'exécution, ce qui lui permet de gérer des tâches dont la forme varie selon l'entrée.
- S'agit-il d'un système multi-agent ?
- Oui — c'est un modèle multi-agent courant. Utilisez-le uniquement lorsqu'une tâche bénéficie réellement de sous-tâches dynamiques et séparables.
- Comment éviter qu'il ne devienne incontrôlable ?
- Définissez des budgets, des limites d'étapes et des conditions d'arrêt, et ajoutez de l'observabilité afin de pouvoir visualiser et limiter la planification de l'orchestrateur.