Multi-Agent-Orchestrierungsmuster mit OpenClaw

Ein einzelner KI-Agent kann einen Prozess automatisieren. Ein gut orchestriertes Agentensystem kann eine Geschäftsfunktion automatisieren. Der Unterschied liegt darin, wie Agenten Fehler über Grenzen hinweg koordinieren, kommunizieren und behandeln. Multiagenten-Orchestrierung ist die technische Disziplin, die den Unterschied zwischen einer Sammlung unabhängiger Bots und einem kohärenten, zuverlässigen autonomen System ausmacht.

OpenClaw stellt die Grundelemente für die Orchestrierung mehrerer Agenten bereit: einen typisierten Nachrichtenbus, eine Agentenregistrierung, Übergabeprotokolle, Namespaces für gemeinsam genutzten Speicher und verteiltes Tracing, das Anfragen über Agentengrenzen hinweg verfolgt. Dieser Leitfaden behandelt die vier grundlegenden Orchestrierungsmuster, wann sie jeweils zu verwenden sind, wie sie in OpenClaw implementiert werden und welche Fehlermodi beim Entwurf berücksichtigt werden müssen.

Wichtige Erkenntnisse

• Das Supervisor-Worker-Muster ist die gebräuchlichste Architektur: Ein orchestrierender Agent zerlegt Ziele und delegiert sie an spezialisierte Mitarbeiter. – Das Pipeline-Muster eignet sich am besten für die sequentielle Dokumentenverarbeitung oder die mehrstufige Datentransformation, bei der jede Stufe Eingaben für die nächste erzeugt.
• Das Konsensmuster ermöglicht es mehreren unabhängigen Agenten, dieselbe Frage zu bewerten, wodurch das Risiko von Fehlern einzelner Agenten bei Entscheidungen mit hohem Risiko verringert wird. – Das Market-Maker-Muster weist Aufgaben dynamisch dem leistungsstärksten verfügbaren Agenten zu und ermöglicht so einen Lastausgleich und eine sanfte Verschlechterung.
• Agentenübergreifende Kommunikation nutzt den typisierten Message Bus von OpenClaw – keine Weitergabe von Rohzeichenfolgen, kein gemeinsamer veränderlicher Status zwischen Agenten.
• Die verteilte Ablaufverfolgung ist für das Debuggen mehrerer Agenten unerlässlich – jede Nachricht trägt eine Korrelations-ID, die über Agentengrenzen hinweg reicht. – Leistungsschalter an der Agentengrenze verhindern Kaskadenausfälle, wenn ein Agent im System nicht verfügbar ist.
• ECOSIRE entwirft und implementiert Multiagentenarchitekturen für komplexe Unternehmensautomatisierungsworkflows.

---

Die Grundlage: Das Agentenkommunikationsmodell von OpenClaw

Bevor wir uns mit Mustern befassen, ist es wichtig zu verstehen, wie OpenClaw-Agenten kommunizieren. Es gibt drei Mechanismen mit jeweils unterschiedlichen Kompromissen:

Der Nachrichtenbus ist der primäre Kommunikationskanal zwischen Agenten im selben System. Agenten veröffentlichen getippte Nachrichten in benannten Kanälen. andere Agenten abonnieren diese Kanäle. Nachrichten werden vom Bus-Broker (Redis Streams oder Kafka, konfigurierbar) gespeichert, sodass Nachrichten nicht verloren gehen, wenn der empfangende Agent vorübergehend nicht verfügbar ist.

Direkter Aufruf ermöglicht es einem Agenten, die exponierten Fähigkeiten eines anderen Agenten direkt anzurufen und auf eine Antwort zu warten. Dies ist aus Sicht des Anrufers synchron und eignet sich für Arbeitsabläufe mit geringer Latenz, bei denen der anrufende Agent erst fortfahren kann, wenn das Ergebnis vorliegt. Sparsam verwenden – es entsteht eine enge Kopplung zwischen den Agenten.

Shared-Memory-Namespaces ermöglichen es Agenten innerhalb desselben Systems, aus einem gemeinsam genutzten Bereich des Speichers zu lesen und in diesen zu schreiben. Dies eignet sich für die Weitergabe großer Kontextobjekte (ein Dokument, das verarbeitet wird, ein Kundenprofil, das stufenweise angereichert wird), ohne sie durch Nachrichtennutzlasten zu serialisieren.

// 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);
});

Alle Nachrichten enthalten eine Korrelations-ID, einen Zeitstempel, eine Quell-Agent-ID und eine Schemaversion. Die Schemaversion ermöglicht es dem Nachrichtenbus, Nachrichten anhand ihres deklarierten Vertrags zu validieren und fehlerhafte Nachrichten abzulehnen, bevor sie den empfangenden Agenten erreichen.

---

Muster 1: Vorgesetzter-Arbeiter

Das Supervisor-Worker-Muster ist die am weitesten verbreitete Multi-Agent-Architektur. Ein Supervisor-Agent empfängt das Ziel der obersten Ebene, zerlegt es in Unteraufgaben, weist jede Unteraufgabe einem spezialisierten Worker-Agenten zu, überwacht den Fortschritt und fasst die Ergebnisse zusammen.

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

Wann zu verwenden: Wenn ein komplexes Ziel heterogenes Fachwissen erfordert. Der Vorgesetzte kümmert sich um die Koordinationslogik; Mitarbeiter sind Fachspezialisten, die eine Sache gut machen.

OpenClaw-Implementierung:

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);
  },
});

Wichtige Designentscheidungen:

• Der Supervisor sollte keine Domänenlogik enthalten – er sollte nur koordinieren.
• Arbeiter sollten staatenlos und unabhängig skalierbar sein.
• Fehlgeschlagene Worker-Aufgaben werden vom Vorgesetzten und nicht vom Worker intern erneut versucht.
• Aufgaben-Timeouts auf Supervisor-Ebene verhindern, dass ein langsamer Mitarbeiter den gesamten Workflow blockiert.

Beispiel aus der Praxis: Ein Due-Diligence-Automatisierungssystem, bei dem der Vorgesetzte eine Unternehmensbewertung in parallele Aufgaben zerlegt, die einem Mitarbeiter für Finanzanalyse, einem Mitarbeiter für die Überprüfung von Rechtsdokumenten, einem Mitarbeiter für Marktforschung und einem Mitarbeiter für Referenzprüfungen zugewiesen werden. Der Vorgesetzte fasst alle Erkenntnisse in einem einheitlichen Due-Diligence-Bericht zusammen.

---

Muster 2: Pipeline

Das Pipeline-Muster sequenziert Agenten so, dass die Ausgabe jedes Agenten zur Eingabe des nächsten Agenten wird. Es ist ideal für die Dokumentenverarbeitung, Datenanreicherung und jeden Arbeitsablauf, bei dem jeder Schritt die Nutzlast in einer definierten Reihenfolge transformiert oder anreichert.

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

Wann zu verwenden: Sequentielle Arbeitsabläufe mit klaren Phasengrenzen und Transformation bei jedem Schritt. Hervorragend geeignet für die Dokumentenverarbeitung mit hohem Durchsatz.

OpenClaw-Implementierung:

Das Pipeline-Grundelement von OpenClaw verwaltet die Phasenkette, behandelt Fehler und unterstützt die Verzweigung in jeder Phase basierend auf dem Nutzlastinhalt.

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,
  },
});

Wichtige Designentscheidungen:

• Jede Stufe sollte idempotent sein – wenn sie zweimal mit derselben Eingabe ausgeführt wird, erzeugt sie dieselbe Ausgabe. – Der onFailure-Handler empfängt den Teil-Pipeline-Status, sodass er ab der letzten erfolgreichen Phase fortfahren kann, anstatt von vorne zu beginnen.
• Durch die Verzweigung können verschiedene Dokumenttypen nach der Klassifizierung unterschiedlichen Unterpipelines folgen. – Verwenden Sie den Shared-Memory-Namespace, um große Nutzlasten (Dokumentpuffer) zwischen den Stufen zu übergeben, anstatt sie über den Nachrichtenbus zu serialisieren.

Fehlerbehandlung: Wenn Stufe N nach M erfolgreichen Stufen fehlschlägt, wird der Pipeline-Status auf Stufe M überprüft. Nachdem der Fehler behoben wurde (manuelle Korrektur, erneuter Versuch nach Wiederherstellung der Abhängigkeit), wird die Pipeline ab Stufe M+1 mit derselben Nutzlast fortgesetzt.

---

Muster 3: Konsens

Das Konsensmuster führt mehrere unabhängige Agenten gegen dieselbe Eingabe aus und erfordert, dass sie zustimmen (innerhalb eines Schwellenwerts), bevor das System reagiert. Es handelt sich um das Multi-Agent-Äquivalent einer Zweitmeinung und ist vor allem bei Entscheidungen mit hohem Risiko wertvoll, bei denen ein Fehler eines einzelnen Agenten kostspielig wäre.

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

Verwendungszweck: Entscheidungen mit hohem Risiko (Kreditgenehmigung, Betrugserkennung, Analyse von Krankenakten, Überprüfung von Vertragsklauseln), kontroverse Eingaben, bei denen ein einzelner Agent manipuliert werden könnte, oder Situationen, in denen verschiedene Modelle komplementäre Stärken haben.

OpenClaw-Implementierung:

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 };
    }
  },
});

Wichtige Designentscheidungen:

• Bewerter sollten unterschiedliche Modelle oder unterschiedliche Aufforderungsstrategien verwenden, um damit verbundene Fehler zu minimieren. Zwei Agenten, die dasselbe Modell mit derselben Aufforderung verwenden, werden normalerweise einer Meinung sein – was dem Zweck zuwiderläuft.
• Der Konsensschwellenwert ist konfigurierbar. Bei unumkehrbaren Maßnahmen ist eine einstimmige Zustimmung angebracht; Für umkehrbare Entscheidungen genügt die einfache Mehrheit.
• Eskalationspfade erfordern eine Kapazitätsplanung – wenn Ihre Eskalationsrate hoch ist, müssen die Bewertungskriterien angepasst werden.

---

Muster 4: Market-Maker

Das Market-Maker-Muster verwaltet einen Pool von Worker-Agenten und weist Aufgaben dynamisch dem am besten geeigneten verfügbaren Worker zum Zeitpunkt des Eintreffens der Aufgabe zu. Arbeiter registrieren ihre Fähigkeiten und aktuelle Belastung; Der Market-Maker leitet jede Aufgabe an die beste Übereinstimmung weiter.

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

Wann zu verwenden: Systeme mit hohem Durchsatz, bei denen das Aufgabenvolumen erheblich variiert. Ermöglicht die horizontale Skalierung von Worker-Agents, ohne die Routing-Logik zu ändern. Ermöglicht außerdem eine sanfte Herabstufung – wenn ein spezialisierter Worker nicht verfügbar ist, kann der Market-Maker zu einem generalistischen Worker mit geringerer Leistung weiterleiten, anstatt die Aufgabe nicht zu bestehen.

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);
    }
  },
});

Wichtige Designentscheidungen:

• Die Meldung der Worker-Auslastung muss präzise und mit geringer Latenz erfolgen. Veraltete Lastdaten führen zu einer ungleichmäßigen Verteilung.
• Die Fallback-Kette (Spezialist → Generalist → Warteschlange mit Verzögerung) verhindert den Verlust von Aufgaben bei Kapazitätsengpässen.
• Mitarbeiter registrieren sich beim Start selbst und melden sich beim ordnungsgemäßen Herunterfahren wieder ab. Durch die Abfrage der Integritätsprüfung werden abgestürzte Worker automatisch entfernt.

---

Cross-Pattern: Verteilte Ablaufverfolgung

Unabhängig davon, welches Orchestrierungsmuster Sie verwenden, ist die verteilte Ablaufverfolgung für Produktionssysteme mit mehreren Agenten nicht verhandelbar. Jede Nachricht trägt einen correlationId und einen spanId. Wenn ein Agent eine untergeordnete Aufgabe erstellt (im Supervisor-Muster) oder Arbeit an die nächste Stufe übergibt (im Pipeline-Muster), erstellt er eine neue Spanne als untergeordnetes Element der aktuellen Spanne.

// 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();
});

Mit der verteilten Ablaufverfolgung können Sie den vollständigen Ausführungsbaum für jede Aufgabe über alle Agentengrenzen hinweg visualisieren – von unschätzbarem Wert für die Fehlerbehebung bei Latenzproblemen und unerwartetem Verhalten.

---

Zu vermeidende Anti-Patterns

Gemeinsamer veränderlicher Zustand: Mehrere Agenten, die unkoordiniert in denselben Datenspeicherdatensatz schreiben, führen zu verlorenen Aktualisierungen und Race Conditions. Nutzen Sie den Nachrichtenbus zur Koordination; Agenten besitzen ihren eigenen Staat.

Synchronisierte Ketten, die länger als drei Agenten sind: Wenn Agent A B anruft, der C anruft, der D synchron anruft, erhöht sich die Latenz und der Radius der Fehlerexplosion ist groß. Teilen Sie lange synchrone Ketten mit Checkpointing in asynchrone Pipeline-Stufen auf.

Supervisor-Agenten mit Domänenlogik: Supervisoren sollten Domänenarbeit orchestrieren und nicht ausführen. Wenn ein Supervisor anfängt, Extraktionslogik oder Validierungsregeln zu enthalten, wird er zu einem getarnten Monolithen.

Implizite Verträge zwischen Agenten: Nachrichtenschemata sollten auf Busebene versioniert und validiert werden. Agenten, die die Nachrichtenstruktur übernehmen, anstatt sie zu validieren, schlagen stillschweigend fehl, wenn der Absender sein Ausgabeformat ändert.

---

Häufig gestellte Fragen

Wie gehen Sie mit Teilausfällen in einem Supervisor-Worker-System um, in dem einige Worker erfolgreich sind und andere scheitern?

Der Vorgesetzte erhält die Ergebnisse aller Arbeitsaufgaben als eine Mischung aus Erfolgen und Misserfolgen. Die Synthesefähigkeit entscheidet, wie mit Teilergebnissen auf der Grundlage des Ziels umgegangen wird: Bei manchen Zielen reichen Teilergebnisse aus, um einen nützlichen Output zu erzeugen; für andere sind alle Ergebnisse erforderlich. Konfigurieren Sie den Supervisor mit einem Mindesterfolgsschwellenwert. Wenn weniger als dieser Anteil der Mitarbeiter erfolgreich ist, eskalieren Sie, anstatt eine möglicherweise irreführende Teilausgabe zu erzeugen.

Kann derselbe Agent gleichzeitig an mehreren Orchestrierungsmustern teilnehmen?

Ja. Ein Agent ist nur ein Dienst – er kann ein Worker in einem Supervisor-Worker-System sein, gleichzeitig aber auch eine Stufe in einer Pipeline sein und als Evaluator an einer Konsensprüfung teilnehmen. Jeder Aufruf ist unabhängig. Die entscheidende Anforderung besteht darin, dass Agenten zwischen den Aufrufen zustandslos sind (zustandsbehaftete Daten werden in Arbeitsspeichern abgelegt, nicht in Agenteninstanzvariablen), sodass sich mehrere gleichzeitige Aufrufe nicht gegenseitig stören.

Wie hoch ist der Overhead des Nachrichtenbusses für Systeme mit hohem Durchsatz?

Mit Redis Streams als Nachrichtenbus-Backend beträgt die Veröffentlichungs-/Abonnementlatenz für Nachrichten normalerweise weniger als 2 ms für Nachrichten unter 64 KB. Bei Pipelines mit hohem Durchsatz, die Tausende von Dokumenten pro Minute verarbeiten, ist dies im Vergleich zum Verarbeitungsaufwand in jeder Phase vernachlässigbar. Für Systeme mit extrem hohem Durchsatz (Millionen Nachrichten pro Tag) bietet Kafka einen höheren dauerhaften Durchsatz auf Kosten einer höheren betrieblichen Komplexität.

Wie versionieren Sie Multiagentensysteme, wenn sich einzelne Agenten weiterentwickeln?

Versionsagenten verwenden unabhängig voneinander semantische Versionierung in ihren Manifesten. Der Nachrichtenbus validiert Nachrichten anhand ihrer deklarierten Schemaversion. Wenn ein Agent sein Ausgabeschema ändert (Breaking Change), erhöht er die Hauptversion und der Bus leitet Nachrichten des alten Schemas an die vorherige Version weiter. Beide Versionen werden während des Migrationsfensters gleichzeitig ausgeführt. Die Supervisor- oder Pipeline-Konfiguration gibt an, welche Version jedes Workers benötigt wird, sodass Sie die volle Kontrolle über den Rollout-Timing haben.

Wie geht das Market-Maker-Muster mit der Aufgabenreihenfolge um, wenn Aufgaben Abhängigkeiten aufweisen?

Der Market-Maker eignet sich für unabhängige Aufgaben – Aufgaben, die in beliebiger Reihenfolge ausgeführt werden können. Verwenden Sie für Aufgaben mit Abhängigkeiten stattdessen das Pipeline- oder Supervisor-Muster, die die Reihenfolge explizit erzwingen. Wenn Sie eine Mischung aus unabhängigen und abhängigen Aufgaben haben, funktioniert das Supervisor-Muster gut: Der Supervisor verteilt unabhängige Aufgaben an den Market-Maker-Pool und verwaltet die Abhängigkeitsreihenfolge für den Rest.

---

Nächste Schritte

Durch die Orchestrierung mit mehreren Agenten wird eine Automatisierungskomplexität freigesetzt, die einzelne Agenten nicht bewältigen können. Die Muster in diesem Leitfaden – Supervisor-Worker, Pipeline, Consensus und Market-Maker – decken die überwiegende Mehrheit der Anwendungsfälle der Unternehmensautomatisierung ab. Der Schlüssel liegt darin, das richtige Muster für die Kommunikationsstruktur des Problems auszuwählen und nicht jedes Problem in eine einzige Architektur zu zwingen.

Der OpenClaw Multi-Agent-Orchestrierungsdienst von ECOSIRE bietet Architekturdesign, Implementierung und fortlaufende Optimierung für komplexe Multi-Agent-Systeme. Unser Team hat Orchestrierungsarchitekturen für Dokumentenverarbeitungssysteme entwickelt, die monatlich Millionen von Dokumenten verarbeiten, Finanzanalyse-Pipelines, die rund um die Uhr laufen, und HR-Automatisierungssysteme, die ein Dutzend spezialisierter Agenten koordinieren.

Kontaktieren Sie ECOSIRE, um Ihre Anforderungen an die Multi-Agent-Architektur zu besprechen.