Modèles d'orchestration multi-agents avec OpenClaw

Un seul agent IA peut automatiser un processus. Un système d’agents bien orchestré peut automatiser une fonction commerciale. La différence réside dans la manière dont les agents se coordonnent, communiquent et gèrent les échecs au-delà des frontières. L'orchestration multi-agents est la discipline d'ingénierie qui fait la différence entre un ensemble de robots indépendants et un système autonome cohérent et fiable.

OpenClaw fournit les primitives pour l'orchestration multi-agents : un bus de messages typés, un registre d'agents, des protocoles de transfert, des espaces de noms de mémoire partagée et un traçage distribué qui suit les requêtes au-delà des frontières des agents. Ce guide couvre les quatre modèles d'orchestration fondamentaux, quand les utiliser, comment les implémenter dans OpenClaw et les modes de défaillance contre lesquels concevoir.

Points clés à retenir

• Le modèle Superviseur-Travailleur est l'architecture la plus courante : un agent orchestrateur décompose les objectifs et délègue à des travailleurs spécialisés.
• Le modèle Pipeline est idéal pour le traitement séquentiel de documents ou la transformation de données en plusieurs étapes, où chaque étape produit des entrées pour la suivante.
• Le modèle Consensus permet à plusieurs agents indépendants d'évaluer la même question, réduisant ainsi le risque d'erreurs d'un seul agent dans les décisions à enjeux élevés.
• Le modèle Market-Maker alloue dynamiquement des tâches à l'agent disponible le plus performant, permettant un équilibrage de charge et une dégradation gracieuse.
• La communication entre agents utilise le bus de messages typé d'OpenClaw : pas de passage de chaîne brute, pas d'état mutable partagé entre les agents.
• Le traçage distribué est essentiel pour le débogage multi-agents : chaque message comporte un ID de corrélation qui dépasse les limites des agents.
• Les disjoncteurs situés à la limite des agents empêchent les pannes en cascade lorsqu'un agent du système devient indisponible.
• ECOSIRE conçoit et met en œuvre des architectures multi-agents pour les workflows complexes d'automatisation d'entreprise.

---

La Fondation : le modèle de communication des agents d'OpenClaw

Avant d’aborder les modèles, il est important de comprendre comment les agents OpenClaw communiquent. Il existe trois mécanismes, chacun avec des compromis différents :

Le Message Bus est le principal canal de communication entre les agents d'un même système. Les agents publient des messages saisis sur des canaux nommés ; d'autres agents s'abonnent à ces chaînes. Les messages sont conservés par le courtier de bus (Redis Streams ou Kafka, configurable), de sorte que les messages ne sont pas perdus si l'agent récepteur est temporairement indisponible.

Invocation directe permet à un agent d'appeler directement les compétences exposées d'un autre agent et d'attendre une réponse. Ceci est synchrone du point de vue de l'appelant et convient aux flux de travail à faible latence dans lesquels l'agent appelant ne peut pas continuer tant qu'il n'a pas obtenu le résultat. À utiliser avec parcimonie : cela crée un couplage étroit entre les agents.

Les espaces de noms de mémoire partagée permettent aux agents du même système de lire et d'écrire dans une région partagée de la mémoire. Ceci est approprié pour transmettre des objets contextuels volumineux (un document en cours de traitement, un profil client enrichi au fil des étapes) sans les sérialiser via des charges utiles de messages.

// Publishing a message
await messageBus.publish("document.classified", {
  documentId: "DOC-4521",
  type: "vendor-invoice",
  confidence: 0.94,
  storageKey: "incoming/doc-4521.pdf",
});

// Subscribing to messages
messageBus.subscribe("document.classified", async (message) => {
  await extractionAgent.handle(message);
});

Tous les messages incluent un ID de corrélation, un horodatage, un ID d'agent source et une version de schéma. La version schéma permet au bus de messages de valider les messages par rapport à leur contrat déclaré et de rejeter les messages mal formés avant qu'ils n'atteignent l'agent récepteur.

---

Modèle 1 : Superviseur-Ouvrier

Le modèle Supervisor-Worker est l’architecture multi-agent la plus largement applicable. Un agent superviseur reçoit l'objectif de niveau supérieur, le décompose en sous-tâches, attribue chaque sous-tâche à un agent travailleur spécialisé, surveille les progrès et synthétise les résultats.

User/System Goal
      ↓
[ Supervisor Agent ]
  ├─ task 1 → [ Worker Agent A ]
  ├─ task 2 → [ Worker Agent B ]
  └─ task 3 → [ Worker Agent C ]
      ↓
[ Supervisor Agent ] ← results from all workers
      ↓
Synthesized Response

Quand l'utiliser : lorsqu'un objectif complexe nécessite une expertise hétérogène. Le superviseur gère la logique de coordination ; les travailleurs sont des spécialistes de domaine qui font bien une chose.

Implémentation d'OpenClaw :

export const SupervisorAgent = defineAgent({
  name: "due-diligence-supervisor",
  skills: ["decompose-goal", "assign-workers", "synthesize-results"],
  async run({ goal, workerRegistry, messageBus }) {
    // Decompose goal into tasks
    const tasks = await decomposeGoal(goal);

    // Assign to appropriate workers
    const assignments = tasks.map((task) => ({
      task,
      worker: workerRegistry.findBestMatch(task.type),
    }));

    // Publish tasks and wait for results
    const results = await Promise.allSettled(
      assignments.map(({ task, worker }) =>
        messageBus.requestReply(`worker.${worker.id}.tasks`, task, { timeoutMs: 60_000 })
      )
    );

    // Synthesize
    const successfulResults = results
      .filter((r) => r.status === "fulfilled")
      .map((r) => r.value);

    return synthesize(goal, successfulResults);
  },
});

Décisions clés en matière de conception :

• Le superviseur ne doit pas contenir de logique de domaine : il doit uniquement coordonner.
• Les travailleurs doivent être apatrides et évolutifs de manière indépendante.
• Les tâches des travailleurs ayant échoué sont réessayées par le superviseur et non par le travailleur en interne.
• Les délais d'attente des tâches au niveau du superviseur empêchent un travailleur lent de bloquer l'intégralité du flux de travail.

Exemple concret : un système d'automatisation de diligence raisonnable dans lequel le superviseur décompose un examen d'entreprise en tâches parallèles assignées à un agent d'analyse financière, un agent d'examen de documents juridiques, un agent d'études de marché et un agent de vérification des références. Le superviseur regroupe toutes les conclusions dans un rapport de due diligence unifié.

---

Modèle 2 : Pipeline

Le modèle Pipeline séquence les agents de sorte que la sortie de chaque agent devienne l'entrée de l'agent suivant. Il est idéal pour le traitement de documents, l'enrichissement de données et tout flux de travail où chaque étape transforme ou enrichit la charge utile dans un ordre défini.

Input Document
    ↓
[ Stage 1: Ingestion Agent ]
    ↓
[ Stage 2: Classification Agent ]
    ↓
[ Stage 3: Extraction Agent ]
    ↓
[ Stage 4: Validation Agent ]
    ↓
[ Stage 5: Integration Agent ]
    ↓
Output: ERP Record

Quand l'utiliser : flux de travail séquentiels avec des limites d'étape claires et une transformation à chaque étape. Excellent pour le traitement de documents à haut débit.

Implémentation d'OpenClaw :

La primitive Pipeline d'OpenClaw gère la chaîne d'étapes, gère les échecs et prend en charge le branchement à n'importe quelle étape en fonction du contenu de la charge utile.

import { definePipeline } from "@openclaw/orchestration";

export const InvoicePipeline = definePipeline({
  name: "invoice-processing",
  stages: [
    { agent: "document-ingester", timeout: 30_000 },
    {
      agent: "document-classifier",
      timeout: 15_000,
      branch: {
        "vendor-invoice": "invoice-extractor",
        "credit-memo": "credit-memo-extractor",
        "unknown": "human-review-queue", // Branch to exception handling
      },
    },
    { agent: "invoice-validator", timeout: 20_000 },
    { agent: "invoice-enricher", timeout: 10_000 },
    { agent: "erp-integrator", timeout: 30_000, retries: 3 },
  ],
  onFailure: {
    agent: "exception-handler",
    preservePartialState: true,
  },
});

Décisions clés en matière de conception :

• Chaque étape doit être idempotente : si elle s'exécute deux fois avec la même entrée, elle produit la même sortie.
• Le gestionnaire onFailure reçoit l'état partiel du pipeline afin qu'il puisse reprendre à partir de la dernière étape réussie plutôt que de recommencer.
• Le branchement permet à différents types de documents de suivre différents sous-pipelines après classification.
• Utilisez l'espace de noms de mémoire partagée pour transmettre des charges utiles volumineuses (tampons de documents) entre les étapes plutôt que de les sérialiser via le bus de messages.

Gestion des échecs : lorsque l'étape N échoue après M étapes réussies, l'état du pipeline est contrôlé à l'étape M. Une fois l'échec résolu (correction manuelle, nouvelle tentative après la récupération de la dépendance), le pipeline reprend à partir de l'étape M+1 avec la même charge utile.

---

Modèle 3 : Consensus

Le modèle Consensus exécute plusieurs agents indépendants sur la même entrée et les oblige à se mettre d'accord (dans les limites d'un seuil) avant que le système n'agisse. Il s’agit de l’équivalent multi-agent d’un deuxième avis et s’avère particulièrement utile dans les décisions à enjeux élevés où une erreur d’un seul agent serait coûteuse.

Input
  ├─ → [ Evaluator Agent A ] → assessment A
  ├─ → [ Evaluator Agent B ] → assessment B
  └─ → [ Evaluator Agent C ] → assessment C
          ↓
  [ Consensus Resolver ]
    ├── unanimous or majority? → act
    └── no consensus? → escalate to human

Quand l'utiliser : décisions à enjeux élevés (approbations de prêts, détection de fraudes, analyse des dossiers médicaux, examen des clauses contractuelles), contributions contradictoires dans lesquelles un seul agent peut être manipulé ou situations dans lesquelles différents modèles ont des atouts complémentaires.

Implémentation d'OpenClaw :

export const FraudConsensusCheck = defineAgent({
  name: "fraud-consensus",
  async run({ transaction, evaluators }) {
    // Run all evaluators in parallel
    const assessments = await Promise.all(
      evaluators.map((evaluator) =>
        evaluator.assess(transaction)
      )
    );

    const fraudVotes = assessments.filter((a) => a.isFraud).length;
    const totalVotes = assessments.length;
    const agreementRatio = fraudVotes / totalVotes;

    if (agreementRatio >= 0.67) { // Supermajority fraud detection
      return { decision: "block", confidence: agreementRatio, assessments };
    } else if (agreementRatio === 0) { // Unanimous clear
      return { decision: "allow", confidence: 1 - agreementRatio, assessments };
    } else {
      // Disagreement — escalate with all assessments for human review
      return { decision: "escalate", confidence: null, assessments };
    }
  },
});

Décisions clés en matière de conception :

• Les agents évaluateurs doivent utiliser différents modèles ou différentes stratégies d'incitation pour minimiser les échecs corrélés. Deux agents qui utilisent le même modèle avec la même invite seront généralement d'accord, ce qui va à l'encontre de l'objectif.
• Le seuil de consensus est configurable. L’accord unanime est approprié pour les actions irréversibles ; la majorité simple suffit pour les décisions réversibles.
• Les voies de remontée d'informations nécessitent une planification des capacités : si votre taux de remontée d'informations est élevé, les critères de l'évaluateur doivent être ajustés.

---

Modèle 4 : Teneur de marché

Le modèle Market-Maker gère un pool d'agents Worker et alloue dynamiquement des tâches au travailleur disponible le plus approprié au moment où la tâche arrive. Les travailleurs enregistrent leurs capacités et leur charge actuelle ; le Market-Maker achemine chaque tâche vers la meilleure correspondance.

Task Queue
    ↓
[ Market-Maker Agent ]
    ├── Worker A: [language-translation] load: 30%
    ├── Worker B: [language-translation] load: 80%
    └── Worker C: [language-translation] load: 10%  ← assigned

Quand l'utiliser : systèmes à haut débit où le volume des tâches varie considérablement. Permet la mise à l'échelle horizontale des agents de travail sans modifier la logique de routage. Permet également une dégradation progressive : si un travailleur spécialisé n'est pas disponible, le teneur de marché peut s'adresser à un travailleur généraliste aux performances inférieures plutôt que d'échouer la tâche.

export const TranslationMarketMaker = defineAgent({
  name: "translation-market-maker",
  tools: ["worker-registry", "task-queue"],
  async run({ tools }) {
    while (true) {
      const task = await tools.taskQueue.dequeue("translation.pending");
      if (!task) { await sleep(100); continue; }

      const workers = await tools.workerRegistry.getAvailable({
        capability: "language-translation",
        targetLanguage: task.targetLanguage,
      });

      if (workers.length === 0) {
        // No specialist available — try generalist
        const generalists = await tools.workerRegistry.getAvailable({ capability: "general-translation" });
        if (generalists.length === 0) {
          await tools.taskQueue.requeueWithDelay(task, { delayMs: 5000 });
          continue;
        }
        workers.push(...generalists);
      }

      // Select worker with lowest load
      const selected = workers.sort((a, b) => a.currentLoad - b.currentLoad)[0];
      await selected.dispatch(task);
    }
  },
});

Décisions clés en matière de conception :

• Les rapports sur la charge des travailleurs doivent être précis et à faible latence. Les données de charge obsolètes entraînent une répartition inégale.
• La chaîne de secours (spécialiste → généraliste → file d'attente avec retard) évite la perte de tâches en cas de manque de capacité.
• Les travailleurs s'auto-enregistrent au démarrage et se désinscrivent lors d'un arrêt progressif. L'interrogation de vérification de l'état supprime automatiquement les travailleurs en panne.

---

Modèle croisé : traçage distribué

Quel que soit le modèle d'orchestration que vous utilisez, le traçage distribué n'est pas négociable pour les systèmes multi-agents de production. Chaque message comporte un correlationId et un spanId. Lorsqu'un agent crée une tâche enfant (dans le modèle Superviseur) ou transmet le travail à l'étape suivante (dans le modèle Pipeline), il crée un nouveau span en tant qu'enfant du span actuel.

// Middleware that injects tracing into all agent message handlers
agent.useHook("preRun", (ctx) => {
  ctx.span = tracer.startSpan(ctx.skill, { childOf: ctx.message.parentSpan });
  ctx.span.setTag("agent.id", ctx.agentId);
  ctx.span.setTag("correlation.id", ctx.message.correlationId);
});

agent.useHook("postRun", (ctx) => {
  ctx.span.finish();
});

Avec le traçage distribué, vous pouvez visualiser l'arborescence d'exécution complète de n'importe quelle tâche dans toutes les limites des agents, ce qui est inestimable pour déboguer les problèmes de latence et les comportements inattendus.

---

Anti-modèles à éviter

État mutable partagé : plusieurs agents écrivant dans le même enregistrement de magasin de données sans coordination entraînent des pertes de mises à jour et des conditions de concurrence. Utilisez le bus de messages pour la coordination ; les agents possèdent leur propre État.

Chaînes synchrones de plus de trois agents : si l'agent A appelle B qui appelle C qui appelle D de manière synchrone, la latence s'aggrave et le rayon d'explosion est grand. Divisez les longues chaînes synchrones en étapes de pipeline asynchrones avec des points de contrôle.

Agents superviseurs avec logique de domaine : les superviseurs doivent orchestrer et non exécuter le travail de domaine. Lorsqu’un superviseur commence à contenir une logique d’extraction ou des règles de validation, il devient un monolithe déguisé.

Contrats implicites entre agents : les schémas de messages doivent être versionnés et validés au niveau du bus. Les agents qui assument la structure du message plutôt que de la valider échouent silencieusement lorsque l'expéditeur modifie son format de sortie.

---

Questions fréquemment posées

Comment gérer les échecs partiels dans un système Superviseur-Travailleur où certains travailleurs réussissent et d'autres échouent ?

Le superviseur reçoit les résultats de toutes les tâches des travailleurs sous la forme d'un mélange de réussites et d'échecs. La compétence de synthèse décide comment gérer les résultats partiels en fonction de l'objectif : pour certains objectifs, des résultats partiels suffisent pour produire un résultat utile ; pour d’autres, tous les résultats sont requis. Configurez le superviseur avec un seuil de réussite minimum : si moins de cette proportion de travailleurs réussissent, augmentez le problème plutôt que de produire un résultat partiel potentiellement trompeur.

Le même agent peut-il participer simultanément à plusieurs modèles d'orchestration ?

Oui. Un agent n'est qu'un service : il peut être un travailleur dans un système superviseur-travailleur tout en étant également une étape dans un pipeline et en participant en tant qu'évaluateur à une vérification de consensus. Chaque invocation est indépendante. L'exigence essentielle est que les agents soient sans état entre les invocations (les données avec état sont stockées dans les magasins de mémoire, pas dans les variables d'instance d'agent), afin que plusieurs invocations simultanées n'interfèrent pas.

Quelle est la surcharge du bus de messages pour les systèmes à haut débit ?

Avec Redis Streams comme backend du bus de messages, la latence de publication/abonnement des messages est généralement inférieure à 2 ms pour les messages de moins de 64 Ko. Pour les pipelines à haut débit traitant des milliers de documents par minute, cela est négligeable par rapport au travail de traitement à chaque étape. Pour les systèmes à très haut débit (des millions de messages par jour), Kafka offre un débit soutenu plus élevé au prix d'une complexité opérationnelle plus élevée.

Comment gérer les versions des systèmes multi-agents lorsque les agents individuels évoluent ?

Agents de version utilisant indépendamment le versioning sémantique dans leurs manifestes. Le bus de messages valide les messages par rapport à leur version de schéma déclarée. Lorsqu'un agent modifie son schéma de sortie (modification avec rupture), il remplace la version majeure et le bus achemine les messages de l'ancien schéma vers la version précédente. Les deux versions s'exécutent simultanément pendant la fenêtre de migration. La configuration Superviseur ou Pipeline spécifie la version de chaque travailleur requise, vous donnant un contrôle total sur le calendrier de déploiement.

Comment le modèle Market-Maker gère-t-il l'ordre des tâches lorsque celles-ci ont des dépendances ?

Le Market-Maker convient aux tâches indépendantes, c'est-à-dire aux tâches qui peuvent être exécutées dans n'importe quel ordre. Pour les tâches avec dépendances, utilisez plutôt le modèle Pipeline ou Supervisor, qui impose explicitement l'ordre. Si vous avez un mélange de tâches indépendantes et dépendantes, le modèle Superviseur fonctionne bien : le Superviseur répartit les tâches indépendantes vers le pool Market-Maker et gère l'ordre des dépendances pour le reste.

---

Prochaines étapes

L’orchestration multi-agents libère une complexité d’automatisation que les agents seuls ne peuvent pas gérer. Les modèles présentés dans ce guide (Superviseur-Travailleur, Pipeline, Consensus et Market-Maker) couvrent la grande majorité des cas d'utilisation de l'automatisation d'entreprise. La clé est de choisir le bon modèle pour la structure de communication du problème, sans imposer chaque problème dans une architecture unique.

Le service d'orchestration multi-agent OpenClaw d'ECOSIRE fournit la conception d'architecture, la mise en œuvre et l'optimisation continue pour les systèmes multi-agents complexes. Notre équipe a conçu des architectures d'orchestration pour des systèmes de traitement documentaire traitant des millions de documents par mois, des pipelines d'analyse financière fonctionnant 24h/24 et 7j/7, et des systèmes d'automatisation RH coordonnés entre une douzaine d'agents spécialisés.

Contactez ECOSIRE pour discuter de vos besoins en architecture multi-agent.