De statique à adaptatif : un système dynamique d'orchestration d'agents basé sur un espace de travail partagé

Architecture Cockpit et Mode de Collaboration Multi-Agents

📌 Résumé Essentiel

Avec l'amélioration des capacités des grands modèles de langage (LLM), les agents uniques ont révélé des limitations inhérentes telles que la paresse agentive, le biais d'auto-préférence et la dérive d'objectif lors du traitement de tâches complexes et à long terme.

Les workflows dynamiques proposés par Claude Code résolvent ces problèmes grâce à l'isolation multi-instances et à une orchestration personnalisée des tâches, mais leurs conceptions mono-famille de modèles et d'orchestration sans état limitent les scénarios d'application pratiques.

Cet article propose l'Architecture Cockpit — un système d'orchestration d'agents adaptatif basé sur un espace de travail partagé. Cette architecture introduit :

• 🎯 Couche de Gestion d'État Centralisée (Cockpit)
• 🧠 Coordinateur Intelligent (PM)
• 🤖 Pool d'Agents Hétérogènes (Worker Pool)

Tout en conservant les avantages essentiels des workflows dynamiques, elle réalise une collaboration multi-agents multiplateforme et une optimisation adaptative basée sur les performances historiques.

La pratique montre que l'architecture Cockpit démontre des taux d'achèvement de tâches plus élevés et une meilleure contrôlabilité technique dans des tâches complexes telles que la migration de code et la recherche approfondie.

Mots-clés

: Workflow Dynamique · Orchestration d'Agents · Espace de Travail Partagé · Système Adaptatif · Collaboration Multiplateforme

01 Introduction : Du Dilemme à la Percée

🔴 Trois Dilemmes du Contexte Unique

Dans les applications pratiques d'IA agentive, les développeurs adoptent généralement l'approche la plus directe : laisser Claude, GPT ou d'autres LLM accomplir des tâches dans une seule fenêtre de conversation.

Ce mode fonctionne bien pour des scénarios simples, mais lorsque les tâches deviennent complexes — nécessitant l'examen de 50 fichiers, la migration d'une base de code entière ou la réalisation de recherches approfondies — le mode à contexte unique commence à révéler des problèmes systémiques.

La documentation de lancement de Claude Code pour les workflows dynamiques d'Anthropic souligne explicitement trois modes de défaillance :

💤 Paresse Agentive

L'agent prétend que la tâche est terminée prématurément après n'avoir effectué qu'une partie du travail.

Scénario Typique : Lors d'un audit de sécurité, il traite 20 éléments sur 50 et marque le reste comme « traité ».

🎭 Biais d'Auto-préférence

Lorsqu'on demande à un agent de vérifier sa propre production, il a tendance à favoriser ses propres résultats.

Problème Fondamental : Un validateur ayant un intérêt dans le résultat ne peut pas être un juge impartial.

🌊 Dérive d'Objectif

Dans les interactions multi-tours, surtout après une compression de contexte, l'agent s'écarte progressivement de l'objectif initial.

Cas Réel : La contrainte « ne pas faire X » disparaît silencieusement au 47e tour de conversation.

🟢 La Promesse des Workflows Dynamiques

Pour résoudre ces problèmes, Anthropic a lancé la fonctionnalité Workflows Dynamiques en mai 2026.

Idée Centrale : Laisser Claude générer automatiquement un cadre de coordination personnalisé pour une tâche spécifique — un fichier JavaScript qui génère et coordonne plusieurs sous-agents via des fonctions spéciales, chaque sous-agent ayant une fenêtre de contexte indépendante et des objectifs ciblés.

Trois Capacités Clés

✅ Isolation par Agent : Chaque sous-agent a un contexte indépendant, empêchant les interférences.

✅ Sélection de Modèle par Agent : Utiliser Opus pour le raisonnement complexe et Haiku pour l'exploration à faible coût.

✅ Niveau d'Isolation par Agent : Arbre de travail (checkout Git indépendant) ou dépôt distant.

Six Modèles Fondamentaux

Les ingénieurs d'Anthropic ont résumé six modèles d'orchestration récurrents :

• 🔀 Classer-et-Aiguiller
• 🌟 Diffuser-et-Synthétiser
• ⚔️ Vérification Adversariale
• 🎯 Générer-et-Filtrer
• 🏆 Classement par Tournoi
• 🔄 Boucler Jusqu'à Terminaison

Ces modèles résolvent structurellement les modes de défaillance d'un contexte unique.

▲ Trois modes de défaillance du contexte unique : Paresse Agentive, Biais d'Auto-préférence, Dérive d'Objectif

🟡 L'Écart Entre la Théorie et la Pratique Technique

Cependant, les workflows dynamiques sont confrontés à deux limitations clés dans les applications techniques pratiques :

⚠️ Limitation de la Famille de Modèles Unique

Les workflows dynamiques ne peuvent utiliser que les modèles de la famille Claude (Opus/Sonnet/Haiku).

Dans les scénarios réels, les agents de différentes plateformes ont des forces différentes :

• Claude Code excelle dans le refactoring de code
• Codex performe de manière exceptionnelle dans l'implémentation d'algorithmes
• Gemini a des avantages dans les tâches multimodales

Une seule famille de modèles ne peut pas exploiter pleinement l'expertise des différentes plateformes.

⚠️ Orchestration Sans État

Chaque tâche génère un tout nouveau script de workflow ; il n'y a pas de mémoire historique entre les agents.

Problèmes :

• Incapacité à optimiser les stratégies de sélection d'agents en fonction des performances passées
• Incapacité à accumuler des connaissances entre les tâches
• Chaque fois, on « repart de zéro »

💡 Architecture Cockpit : Une Solution pour Combler l'Écart

L'architecture Cockpit proposée dans cet article est conçue pour combler cet écart.

Nous conservons les avantages essentiels des workflows dynamiques :

• ✅ Isolation multi-instances
• ✅ Orchestration dynamique

Tout en introduisant de nouvelles capacités :

• 🆕 Espace de travail partagé
• 🆕 Mécanisme adaptatif
• 🆕 Collaboration multiplateforme

Réalisant ainsi un mode de collaboration d'agents plus flexible et plus intelligent.

02 Revue de la Théorie des Workflows Dynamiques

Statique vs. Dynamique : Comparaison de Deux Paradigmes

Avant de comprendre les workflows dynamiques, il est nécessaire de clarifier le concept de workflows statiques.

🔵 Workflow Statique : Processus Fixes Prédéfinis

Que ce soit en utilisant des plateformes d'automatisation visuelle comme N8N ou Zapier, ou des scripts de coordination écrits avec le Claude Agent SDK, les caractéristiques sont :

Exemple : Un « Workflow de Révision de Code » conçu dans N8N

1Extraire le Code → Appeler Claude pour Analyse → Enregistrer les Résultats → Envoyer une Notification

Le processus est le même, quel que soit le code examiné.

🟣 Workflow Dynamique : Plans d'Exécution Personnalisés pour la Tâche

Un plan d'exécution adapté par Claude pour la tâche en cours :

Exemple : Pour la même révision de code, un workflow dynamique pourrait :

1. Scanner d'abord la base de code pour l'identifier comme un projet React
2. Décider d'utiliser Haiku ou Opus en fonction de la complexité des composants
3. Générer un agent de révision spécialisé pour l'utilisation des Hooks
4. Ajouter une étape de vérification des types TypeScript
5. Traiter en parallèle plutôt qu'en séquence

Explication Détaillée des Six Modèles Fondamentaux

Les ingénieurs d'Anthropic ont résumé six modèles d'orchestration récurrents dans la pratique :

1️⃣ Classer-et-Aiguiller

Utiliser un agent de classification pour déterminer le type de tâche, puis l'aiguiller vers différents agents de traitement.

Scénario : « Expliquer comment fonctionne le module d'authentification »

• L'agent de classification évalue d'abord la complexité
• Les modules simples utilisent Sonnet
• Les modules complexes utilisent Opus

2️⃣ Diffuser-et-Synthétiser

Décomposer une tâche en plusieurs sous-tâches indépendantes, les exécuter en parallèle, puis agréger les résultats.

Valeur Fondamentale : Résout le problème du « trop de choses à gérer à la fois ». Chaque sous-agent ne voit que sa propre partie et n'est pas distrait par 50 détails non pertinents.

💡

C'est le modèle le plus couramment utilisé

3️⃣ Vérification Adversariale

Créer un agent de vérification indépendant pour chaque résultat généré. Ce validateur n'a jamais vu le travail original et ne peut pas produire de biais d'auto-préférence.

Solution Structurelle : La méthode fondamentale pour résoudre le biais d'auto-préférence.

4️⃣ Générer-et-Filtrer

Générer plusieurs solutions candidates, puis utiliser un validateur pour les filtrer.

Différence Clé : Contrairement à la demande directe de la « meilleure réponse », ce modèle permet à l'agent de retarder l'engagement, ne prenant une décision qu'après que toutes les options aient été contestées.

5️⃣ Classement par Tournoi

Faire concourir plusieurs agents pour la même tâche et déterminer le gagnant par des comparaisons par paires.

Scénario Applicable : Travail orienté goût

• Choix de design
• Schémas de dénomination
• Décisions d'interface utilisateur

Avantage Fondamental : Le jugement comparatif est plus fiable que la notation absolue.

6️⃣ Boucler Jusqu'à Terminaison

Générer continuellement des agents jusqu'à ce qu'une condition d'arrêt soit remplie.

Exemples de Conditions d'Arrêt :

• Aucune nouvelle découverte
• Aucune erreur dans les journaux
• Théorie vérifiée

Garantie : « Vraiment terminé » plutôt que « prétendre être terminé ».

▲ Six modèles d'orchestration fondamentaux : Classer-et-Aiguiller, Diffuser-et-Synthétiser, Vérification Adversariale, Générer-et-Filtrer, Classement par Tournoi, Boucler Jusqu'à Terminaison

Limitations des Solutions Existantes

Bien que les workflows dynamiques soient élégants en théorie, ils présentent quatre lacunes majeures dans la pratique technique :

Question Fondamentale : Pouvons-nous concevoir une architecture qui conserve les avantages de l'orchestration dynamique tout en possédant une contrôlabilité technique ?

03 Conception de l'Architecture Cockpit

Aperçu du Système : Architecture à Trois Couches

L'architecture Cockpit adopte une conception à trois couches :

1┌─────────────────────────────────────────┐
2│      Cockpit (Couche Espace de Travail)  │
3│  ┌──────┬──────┬──────────────────┐    │
4│  │ Plan │ Tâches│ Recherche       │    │
5│  │ Obj. │ Prog │ Recherche       │    │
6│  ├──────┼──────┼──────────────────┤    │
7│  │Rapports│Probl.│ Base de Connais.│    │
8│  │ Rapport│ Probl.│ Base de Connais.│    │
9│  └──────┴──────┴──────────────────┘    │
10└─────────────────────────────────────────┘
11              ↕️ Accès Lecture/Écriture
12┌─────────────────────────────────────────┐
13│         PM (Couche de Coordination)      │
14│  • Décomposition des Tâches             │
15│  • Sélection des Workers (Perf. Hist.)  │
16│  • Suivi de la Progression              │
17│  • Maintien du Plan                     │
18└─────────────────────────────────────────┘
19         ↕️ Attribution des Tâches & Collecte des Résultats
20┌─────────────────────────────────────────┐
21│      Pool de Workers (Couche d'Exécution)│
22│  ┌────────┬────────┬──────────────┐    │
23│  │ Claude │ Codex  │ Gemini       │    │
24│  │ Code   │ Agent  │ Agent        │    │
25│  └────────┴────────┴──────────────┘    │
26│       ↕️ Mise à Jour de l'État des Tâches vers Cockpit│
27└─────────────────────────────────────────┘

▲ Architecture à Trois Couches du Cockpit : Couche Espace de Travail Partagé, Couche de Coordination PM, Couche d'Exécution des Workers

Concept de Conception Fondamental : Tous les agents travaillent autour du même « tableau blanc » (Cockpit) plutôt que de collaborer par passage de messages.

💡

Similaire à une équipe logicielle collaborant autour d'un Dépôt Git + Tableau de Projet plutôt que de s'envoyer des e-mails.

Conception des Composants du Cockpit : Six Composants Fondamentaux

Le Cockpit est le centre nerveux du système, contenant six composants fondamentaux.

Voici l'interface du Cockpit en fonctionnement réel :

▲ Vue Plan du Cockpit - Affichage des objectifs du projet et de la progression des jalons

▲ Vue Tâches du Cockpit - Suivi en temps réel de l'état d'achèvement des tâches

▲ Vue Chronologie du Cockpit - Analyse de l'utilisation des Workers et tendances des affectations

📋 Plan (Ancrage des Objectifs)

Fonction :

• Stocke les objectifs fondamentaux du projet et les contraintes
• Tous les agents doivent lire le Plan pour aligner leurs objectifs avant l'exécution

Valeur : Empêche la dérive d'objectif — même après plusieurs tours d'interaction, l'intention originale reste claire.

Données Réelles : D'après la capture d'écran, la progression du projet HippoTeam est de 89% (187/209), incluant 6 jalons de M1 à M6, chacun avec un état d'achèvement clair.

✅ Tâches (Suivi de la Progression)

Fonction :

• Enregistre l'état de toutes les sous-tâches : En Attente, En Cours, Terminée
• Les Workers mettent à jour l'état après avoir terminé les tâches
• Le PM ajuste l'orchestration ultérieure en fonction de l'état en temps réel

Valeur : Résout la « paresse agentive » — l'achèvement des tâches est clair en un coup d'œil, empêchant les fausses déclarations.

Données Réelles : Il y a 408 tâches en fonctionnement réel, avec un taux d'achèvement de 401/408, et des enregistrements d'affectation détaillés sont visibles.

🔬 Recherche (Accumulation de Recherche)

Fonction :

• Stocke les informations collectées pendant le processus de recherche
• Accessible à tous les agents pour éviter les recherches redondantes

Valeur : Prend en charge la réutilisation des connaissances et l'approfondissement itératif.

Données Réelles : Il y a actuellement 71 enregistrements de recherche dans le système.

📊 Rapports (Gestion des Livrables)

Fonction :

• Stocke les résultats de sortie de chaque étape
• Prend en charge le suivi des versions et le retour en arrière

Valeur : Facilite l'agrégation finale et les contrôles de qualité.

Données Réelles : 78 rapports ont été accumulés dans le système.

⚠️ Problèmes (Gestion des Problèmes)

Fonction :

• Enregistre les problèmes découverts pendant l'exécution
• Tout agent peut ajouter un problème

Valeur : Le PM ajuste les stratégies ou attribue des tâches de réparation en fonction des problèmes.

📚 Base de Connaissances (Base de Connaissances)

Fonction :

• Accumulation de connaissances entre les tâches
• Enregistre les statistiques opérationnelles des Workers

Valeur : Fournit une base de données pour l'analyse humaine et l'optimisation adaptative future.

Implémentation Réelle : Enregistre les performances historiques des Workers via la vue Chronologie. D'après la capture d'écran, on peut voir les données détaillées pour Guan Yu (55 affectations, moyenne 12 min), Zhao Yun (21 affectations, moyenne 10 min), Dian Wei (20 affectations, moyenne 10 min) et Zhang Fei (4 affectations, moyenne 7 min), ainsi que des graphiques de tendance des affectations du 20-05 au 25-05. Ces données sont actuellement utilisées pour la surveillance et l'analyse humaine, et peuvent être utilisées pour établir des boucles de rétroaction automatiques à l'avenir.

💡

Composants Supplémentaires : Le système réel inclut également des modules auxiliaires tels que Idées (pool d'idées, 4 en attente d'évaluation) et Décisions (enregistrements de décisions, 24), prenant en charge des modèles avancés comme « Générer-et-Filtrer ».

Flux de Données et Mécanisme d'Interaction

Avant de plonger dans le mécanisme d'orchestration du PM, comprenons le flux de données entre les agents et le Cockpit.

🔄 Diagramme de Flux de Données Agent-Cockpit

▲ Interaction complète du flux de données entre l'agent et le Cockpit

Chemin d'Interaction Fondamental :

Conception Clé :

• ✅ Dépendance Unidirectionnelle : Les Workers dépendent du Cockpit mais ne communiquent pas directement avec le PM ou d'autres Workers.
• ✅ État Centralisé : Tous les changements d'état passent par le Cockpit, garantissant la cohérence globale.
• ✅ Découplage Asynchrone : Les Workers mettent simplement à jour leur état après avoir terminé une tâche sans attendre une réponse du PM.

🔒 Mécanisme de Synchronisation d'État pour l'Accès Concurrent

Lorsque plusieurs Workers accèdent au Cockpit simultanément, comment la cohérence des données est-elle garantie ?

▲ Mécanisme de synchronisation d'état pour l'accès concurrent multi-Workers

Mécanisme de Garantie à Trois Niveaux :

1️⃣ Verrou Optimiste

Chaque composant du Cockpit maintient un numéro de version :

1Tâches v1 → Worker A lit
2Tâches v1 → Worker B lit
3
4Worker A soumet la mise à jour → vérifie la version v1 → Succès → Tâches v2
5Worker B soumet la mise à jour → vérifie la version v1 → Conflit détecté → Nouvelle tentative automatique

Avantage : Sans verrou dans la plupart des cas, hautes performances.

2️⃣ File d'Attente de Transactions

Toutes les opérations d'écriture entrent dans une file d'attente et sont exécutées séquentiellement :

1Worker #1 : Mettre à jour l'état de Tâche-001 → Position dans la file 1
2Worker #2 : Écrire Rapport-042 → Position dans la file 2
3Worker #3 : Ajouter Problème-015 → Position dans la file 3
4Worker #4 : Mettre à jour l'état de Tâche-002 → Position dans la file 4

Garantie : Atomicité et ordre des opérations d'écriture.

3️⃣ Détection de Conflit et Nouvelle Tentative Automatique

Lorsqu'un conflit de version est détecté :

1. Annulation : Ignorer la mise à jour en cours.
2. Relecture : Obtenir le dernier état.
3. Recalcul : Régénérer la mise à jour en fonction du nouvel état.
4. Nouvelle Soumission : Essayer d'écrire à nouveau.

Cas Réel :

Le Worker A et le Worker B terminent simultanément Tâche-001 et Tâche-002, tous deux essayant de mettre à jour les statistiques de taux d'achèvement dans le composant Tâches.

- Le Worker A soumet en premier, Tâches passe de v5 à v6, taux d'achèvement 400/408.

- Le Worker B détecte que la version est passée à v6 (pas la v5 qu'il a lue) lors de la soumission.

- Le système fait automatiquement relire v6 au Worker B et recalcule le taux d'achèvement à 401/408.

- Le Worker B soumet avec succès, Tâches passe à v7.

Optimisation des Performances :

• 🟢 Opérations de Lecture Sans Verrou : Plusieurs Workers peuvent lire simultanément sans se bloquer mutuellement.
• 🟡 Opérations d'Écriture Légères : La plupart des mises à jour sont des opérations d'ajout (ajout de Rapports, Problèmes), donc la probabilité de conflit est faible.
• 🔴 Conflits Rares : Les conflits ne se produisent que lors de la mise à jour simultanée du même état de tâche, avec un taux d'occurrence réel < 2%.

Mécanisme d'Orchestration Adaptative du PM

Le PM (Chef de Projet) est le cerveau du système, responsable de l'orchestration dynamique.

Contrairement à l'orchestration sans état des workflows dynamiques de Claude, le PM du Cockpit possède des capacités de mémoire et d'apprentissage.

🧩 Décomposition des Tâches

Processus :

1. Après avoir reçu les exigences de l'utilisateur, le PM analyse les caractéristiques de la tâche.
2. Lit les données historiques et le contexte actuel depuis le Cockpit.
3. Décompose la tâche en sous-tâches parallèles ou séquentielles.
4. Met à jour les composants Plan et Tâches.

🎯 Sélection des Workers Basée sur les Rôles

Le PM effectue une affectation intelligente en fonction du type de tâche et des rôles des Workers :

Processus de Décision :

11️⃣ Identifier le Type de Tâche
2   Refactoring de Code / Implémentation d'Algorithme / Révision de Code / Analyse Multimodale
3
42️⃣ Faire Correspondre le Préréglage de Rôle
5   codeur / testeur / relecteur / chercheur
6
73️⃣ Considérer l'Affectation Explicite de l'Utilisateur
8   Tâches spécifiques attribuées à des Workers spécifiques
9
104️⃣ Considérer la Charge Actuelle
11   Nombre de tâches en cours et disponibilité du Worker

Cas d'Opération Réelle :

D'après les données d'opération réelles d'HippoTeam, nous pouvons voir :

Tâches de Refactoring de Code

→ Attribuées aux Workers avec le rôle de codeur (Guan Yu, Zhao Yun, Dian Wei)

Tâches de Révision de Code

→ Attribuées à des rôles de relecteur indépendants (Zhong Kui) pour garantir une vérification adversariale

Tâches d'Implémentation d'Algorithme

→ Worker codeur approprié sélectionné en fonction de la complexité

Surveillance de la Chronologie : Le système enregistre le nombre d'affectations et le temps d'achèvement moyen pour chaque Worker (par exemple, Guan Yu 55 fois/moy. 12 min, Zhao Yun 21 fois/moy. 10 min) via la vue Chronologie, facilitant l'analyse humaine et l'ajustement de la configuration des rôles.

💡

Orientation Future : Les données actuelles de la Chronologie sont destinées à l'affichage ; à l'avenir, une boucle de rétroaction peut être établie pour permettre au PM d'optimiser automatiquement les stratégies de sélection des Workers en fonction des performances historiques.

📈 Suivi de la Progression et Ajustement Dynamique

Capacités en Temps Réel :

• Lecture en temps réel de l'état des Tâches.
• Si un Worker ne répond pas pendant une longue période, réattribuer la tâche.
• Si un problème bloquant apparaît dans les Problèmes, ajuster le plan d'exécution.

Conception du Pool de Workers

Le Pool de Workers est la couche d'exécution du système, contenant plusieurs agents hétérogènes.

🌐 Agents Hétérogènes Multiplateforme

Contrairement aux workflows dynamiques de Claude qui ne peuvent utiliser que la famille Claude, le Cockpit prend en charge les agents de n'importe quelle plateforme :

Chaque plateforme peut avoir plusieurs instances (par exemple, Claude Code #1, #2, #3), réalisant un véritable traitement parallèle.

⚖️ Rôles Fixes vs. Responsabilités Dynamiques

C'est un compromis technique clé.

Le Cockpit adopte un mode « Pool de Rôles Fixes + Attribution Dynamique des Responsabilités » :

✅ Rôles Fixes : Les limites de capacité des Workers sont prédéfinies (Claude Code est un expert en code, Gemini est un expert multimodal).

✅ Responsabilités Dynamiques : Les tâches spécifiques sont attribuées dynamiquement par le PM en fonction de la situation.

Avantages de Conception :

🔄 Protocole de Mise à Jour d'État

Après avoir terminé une tâche, un Worker doit mettre à jour le Cockpit :

• ✅ Mettre à jour l'état de la tâche dans Tâches.
• 📄 Écrire les résultats dans Rapports.
• ⚠️ Ajouter un Problème si un problème est trouvé.
• 📚 Écrire les connaissances accumulées dans Recherche.

Cela garantit la cohérence et la traçabilité de l'état du système.

▲ Agents hétérogènes multiplateforme collaborant autour d'un espace de travail partagé

Implémentation des Six Modèles dans le Cockpit

L'architecture Cockpit est totalement compatible avec les six modèles des workflows dynamiques de Claude et améliore leur implémentation :

🔀 Classer-et-Aiguiller

Implémentation :

• Le PM agit comme un classificateur, sélectionnant le Worker approprié en fonction des caractéristiques de la tâche.

Amélioration :

• Contrairement au modèle original, la décision de classification du PM est basée sur des données historiques, ce qui la rend plus précise.

🌟 Diffuser-et-Synthétiser

Implémentation :

• Le PM décompose la tâche et l'attribue à plusieurs Workers pour une exécution parallèle.
• Tous les Workers écrivent les résultats dans Rapports dans le Cockpit.
• Le PM lit tous les résultats et effectue l'agrégation et la synthèse.

⚔️ Vérification Adversariale

Implémentation :

• Le PM attribue un Worker de vérification indépendant pour chaque tâche de génération.
• Le Worker de vérification ne lit que les résultats de Rapports et ne sait pas qui les a générés.
• Les résultats de vérification sont écrits dans Problèmes, et le PM décide s'il faut refaire en fonction des Problèmes.

🎯 Générer-et-Filtrer

Implémentation :

• Le PM attribue plusieurs Workers pour générer des solutions candidates.
• Ensuite, il attribue des Workers de vérification pour filtrer et noter.
• La solution optimale est écrite dans Rapports.

🏆 Classement par Tournoi

Implémentation :

• Le PM organise des comparaisons par paires, attribuant deux tâches de comparaison à des Workers à chaque fois.
• Les résultats de comparaison sont enregistrés dans le Cockpit, et le PM maintient le classement.
• Le gagnant final est écrit dans Rapports.

🔄 Boucler Jusqu'à Terminaison

Implémentation :

• Le PM vérifie l'état des Tâches et des Problèmes.
• Tant qu'il y a des tâches non terminées ou des problèmes non résolus, il continue d'attribuer des Workers.
• Jusqu'à ce que toutes les Tâches soient marquées comme terminées et que les Problèmes soient vides.

04 Décisions de Conception Clés

Pourquoi Choisir un Pool de Rôles Fixes ?

Lors de la conception du Cockpit, nous avons été confrontés à une question fondamentale :

Devrions-nous générer des agents temporairement à chaque fois comme les workflows dynamiques de Claude, ou maintenir un pool d'agents fixes ?

Nous avons choisi la seconde option pour les raisons suivantes :

💰 Contrôlabilité des Coûts

La génération temporaire d'agents peut entraîner une perte de contrôle des coûts.

Scénario à Risque : Dans une tâche complexe, sans limites, le système pourrait générer des dizaines, voire des centaines d'instances d'agents.

Solution : Un pool de rôles fixes définit un plafond de concurrence, rendant les coûts prévisibles.

🛠️ Stabilité Technique

Les rôles fixes signifient que les limites de capacité de chaque agent sont claires, facilitant :

• La surveillance
• Le débogage
• L'optimisation

Comparaison : Les agents générés temporairement sont difficiles à suivre et difficiles à localiser en cas de problème.

🌐 Avantages Multiplateforme

Un pool de rôles fixes nous permet d'intégrer des agents de différentes plateformes et d'exploiter leurs forces respectives.

Limitation : Les modes de génération temporaire sont difficiles à coordonner entre les plateformes.

📊 Base pour l'Apprentissage Adaptatif

Ce n'est qu'avec des rôles fixes que les données de performances historiques de chaque agent peuvent être accumulées, permettant une affectation intelligente basée sur les performances.

Cela ne signifie pas perdre en flexibilité

Le PM peut toujours décider dynamiquement :

• ✅ À qui attribuer cette tâche.
• ✅ Combien de Workers utiliser pour le traitement parallèle.
• ✅ Si une vérification adversariale est nécessaire.
• ✅ Quand arrêter la boucle.

💡

Ce qui est fixe, c'est le rôle ; ce qui est dynamique, c'est la stratégie d'orchestration.

Espace de travail partagé vs. Passage de messages

Dans le domaine de la collaboration entre Agents, la solution dominante est le mode de passage de messages :

1L'Agent A termine sa tâche → envoie le résultat sous forme de message → Agent B

Ce mode est simple et intuitif, mais présente des problèmes :

❌ Trois problèmes majeurs du passage de messages

✅ Mode Espace de travail partagé de Cockpit

Avantages :

Analogie : Changement de paradigme dans le développement logiciel

1De la « Communication par e-mail » → à la « Collaboration autour d'un dépôt Git »

Cette dernière améliore considérablement l'efficacité de la collaboration.

Avantages des Agents multiplateformes

L'un des avantages les plus significatifs de l'architecture Cockpit est sa prise en charge de l'orchestration hybride d'Agents multiplateformes.

🎯 Exploiter les forces des plateformes

🛡️ Réduire le risque de dépendance à une plateforme

Ne pas être lié à une seule plateforme permet de basculer rapidement vers une alternative en cas de panne ou de limitation de débit.

💰 Optimisation des coûts

Choisir le modèle adapté en fonction de la complexité de la tâche :

• Tâches simples → Modèles peu coûteux
• Tâches complexes → Modèles à haute capacité

Le mécanisme adaptatif du PM trouvera progressivement le point d'équilibre optimal entre coût et qualité.

🏗️ Cas concret

Scénario : Tâche de migration de code source

💡

Ce type d'orchestration hybride est impossible à réaliser dans une solution mono-plateforme.

Comparaison complète des trois modes

▲ Évolution de trois paradigmes de flux de travail : du Statique au Dynamique, puis au Collaboratif

Recommandations de scénarios d'application

🔵 Utilisez les flux de travail statiques (N8N/Zapier) lorsque :

• ✅ Les processus de tâches sont très fixes et ne nécessitent quasiment aucun changement.
• ✅ Une collaboration complexe entre Agents n'est pas nécessaire.
• ✅ La simplicité et la visualisation extrêmes sont recherchées.

🟣 Utilisez les flux de travail dynamiques Claude lorsque :

• ✅ Les tâches sont complexes et nécessitent l'isolation de plusieurs Agents.
• ✅ Seule la plateforme Claude est utilisée.
• ✅ L'accumulation de connaissances entre les tâches n'est pas nécessaire.
• ✅ Une consommation élevée de tokens est acceptable.

🟢 Utilisez l'architecture Cockpit lorsque :

• ✅ Une orchestration hybride d'Agents multiplateformes est nécessaire.
• ✅ Il est nécessaire de réutiliser les connaissances entre les tâches.
• ✅ Des pools de rôles fixes et une attribution intelligente basée sur les rôles sont requis.
• ✅ Il existe des exigences de contrôle des coûts et de traçabilité.
• ✅ Vous êtes prêt à investir des ressources d'ingénierie pour construire le système.

Conclusion

L'architecture Cockpit proposée dans cet article réalise une avancée technique sur le fondement théorique des flux de travail dynamiques en introduisant un espace de travail partagé et des mécanismes d'orchestration basés sur les rôles :

✅ Conserve les avantages essentiels des flux de travail dynamiques

• Isolation des instances multi-Agents, résolvant la paresse agentique et la dérive des objectifs.
• Vérification contradictoire, résolvant le biais d'auto-préférence.
• Orchestration dynamique, optimisée pour des tâches spécifiques.

🚀 Dépasse les limites des solutions originales

• Pool d'Agents multiplateformes, exploitant les forces de chaque plateforme.
• Attribution intelligente basée sur les rôles, garantissant l'adéquation des tâches aux capacités.
• Espace de travail partagé, assurant la cohérence de l'état et la réutilisation des connaissances.
• Pool de rôles fixe, garantissant la maîtrise des coûts et la stabilité technique.

Vérification pratique

Les données opérationnelles réelles du projet HippoTeam (408 tâches, 8 Workers fixes, 71 enregistrements de recherche, 78 rapports) montrent que l'architecture Cockpit démontre dans la collaboration sur des tâches complexes :

• ✅ Une meilleure contrôlabilité technique
• ✅ Une efficacité de collaboration plus élevée
• ✅ Une traçabilité complète

Perspectives d'avenir

Alors que les capacités des LLM continuent de s'améliorer et que les applications des Agents se développent, nous croyons que :

Le mode espace de travail partagé deviendra le paradigme standard pour les systèmes de collaboration complexes entre Agents.

Références

1. Anthropic. (2026). « Dynamic Workflows in Claude Code : 6 patterns and 14 steps »
2. « How to master Dynamic Workflows in Claude Code : 6 patterns and 14 steps Anthropic engineers actually use »
3. Projet AutoGPT. « Autonomous AI Agent Framework »
4. Documentation LangChain. « Agent and Chain Orchestration »
5. CrewAI. « Role-based Agent Collaboration Framework »

Auteur : Huangserva Date : Juin 2026 Mots-clés : Flux de travail dynamique · Orchestration d'Agents · Espace de travail partagé · Système adaptatif · Collaboration multiplateforme

💡

Si cet article vous a été utile, n'hésitez pas à le partager avec d'autres amis intéressés par l'architecture des Agents IA !