Orchestrator-Workers
Ein Orchestrator-LLM zerlegt eine Aufgabe dynamisch in Teilaufgaben, delegiert diese jeweils an ein Worker-LLM und führt die Ergebnisse zusammen. Im Gegensatz zur festen Parallelisierung entscheidet der Orchestrator zur Laufzeit über die Teilaufgaben – was ihn für komplexe Aufgaben eignet, deren Zerlegung im Vorfeld nicht bekannt ist.
Problem
Einige Aufgaben sind zu komplex für einen einzelnen Aufruf und können nicht im Vorfeld zerlegt werden, da die benötigten Teilaufgaben von der Eingabe abhängen.
Wann zu verwenden
Verwenden Sie das Orchestrator-Workers-Muster, wenn eine Aufgabe eine dynamische Zerlegung erfordert – die Anzahl und Art der Teilaufgaben variieren je nach Eingabe – und ein koordinierendes Modell die Arbeit planen und integrieren kann.
Lösung
Ein führendes Modell (Orchestrator) analysiert die Aufgabe, entscheidet, welche Teilaufgaben erforderlich sind, und delegiert diese jeweils an ein (oft spezialisiertes) Worker-Modell. Anschließend sammelt und synthetisiert es die Ausgaben der Worker zu einem Endergebnis.
Es ist die agentenbasierte Generalisierung der Parallelisierung: Die Zerlegung wird zur Laufzeit entschieden und nicht fest codiert, was Flexibilität auf Kosten von mehr Koordination und Unvorhersehbarkeit bringt.
Komponenten
Vorteile
- Bewältigt komplexe Aufgaben mit dynamischer Zerlegung.
- Worker können pro Teilaufgabe spezialisiert werden.
- Skaliert für unterschiedliche Eingaben ohne fest codierte Schritte.
Risiken
- Koordinationsaufwand, Latenz und Token-Kosten.
- Schwerer vorherzusagen und zu debuggen als feste Workflows.
- Der Orchestrator kann Fehlplanungen vornehmen oder in Endlosschleifen geraten.
Wann nicht zu verwenden
- Wenn die Zerlegung im Vorfeld bekannt ist – verwenden Sie Chaining oder feste Parallelisierung.
- Für einfache Aufgaben, die mit einem einzigen Aufruf erledigt werden können.
- Wenn Vorhersehbarkeit und strenge Kostenkontrolle im Vordergrund stehen.
Technologien
Beispiele
- Eine Programmieraufgabe, bei der das Lead-Modell entscheidet, welche Dateien geändert werden sollen, und die Bearbeitungen delegiert.
- Eine Forschungsaufgabe, die in Teilfragen aufgeteilt wird, die jeweils untersucht und anschließend synthetisiert werden.
- Ein komplexer Bericht, der aus dynamisch ausgewählten Abschnitten zusammengestellt wird.
Praxisbelege
- Kontext
- Lokale Bereitstellung für einen einzelnen Operator (Local-First) von OpenClaw, beobachtet über 57 Tage (161 Sessions / 2.776 Turns), aggregiert aus den eigenen Trajektorien-Traces des Agenten.
- Szenario
- Geplante Arbeiten laufen in isolierten, einmaligen Worker-Sessions, die vom übergeordneten Prozess geforkt wurden, mit Berechtigungseinschränkungen (Capability Scoping) sowie Limits für Child-Prozesse und Tiefe.
- Technologie
- Cron-isolierte Agenten-Laufzeitumgebung, Session-Forking (forkSessionFromParent), eine Subagenten-Lane und -Registry sowie Child-/Tiefenlimits pro Agent.
- Last
- 57 Cron-isolierte Worker-Sessions über das Zeitfenster (das explizite Tool sessions.spawn wurde nicht verwendet).
- Ergebnisse
- 57 isolierte Worker-Sessions liefen ohne gegenseitige Beeinflussung; die Isolation durch geforkte Sessions war das dominierende Worker-Muster, während das explizite Spawn-Tool in diesem Zeitfenster ungenutzt blieb. Lokale Bereitstellung für einen einzelnen Operator (Local-First).
KPIs
- End-to-End-Aufgabenerfüllungsrate
- Anteil der orchestrierten Jobs, die über alle Teilaufgaben hinweg korrekt abgeschlossen werden; der Orchestrator trägt die Verantwortung für das Gesamtergebnis.
- Worker-Fan-out & Kosten
- Anzahl der Worker-Aufrufe pro Job und deren kombinierte Token-Kosten; die Orchestrierung kann die Ausgaben explodieren lassen, wenn die Zerlegung ungenau ist.
- Latenz des kritischen Pfads
- Tatsächliche Laufzeit (Wall-clock) der längsten abhängigen Kette, nicht die Summe der Worker – dies begrenzt die Reaktionsfähigkeit.
- Fehlerrate der Teilaufgaben
- Wie oft einzelne Worker fehlschlagen oder unbrauchbare Ergebnisse liefern, was zu Wiederholungsversuchen und Fehlerbehebungen führt.
Beobachtete Fehlermuster
- Fehlerhafte Zerlegung: Der Orchestrator teilt die Aufgabe falsch auf, sodass korrekt arbeitende Worker dennoch ein falsches Gesamtergebnis liefern.
- Kontextverlust zwischen Orchestrator und Workern, was zu inkonsistenten oder widersprüchlichen Teilergebnissen führt.
- Kostenexplosion durch das Erzeugen zu vieler Worker oder tiefe Verschachtelung ohne Budgetgrenzen.
- Single Point of Failure: Wenn sich der Orchestrator verschätzt, schlägt der gesamte Job trotz funktionierender Worker fehl.
Lessons Learned
- Investieren Sie in die Zerlegungslogik – die meisten Fehler lassen sich darauf zurückführen, wie die Arbeit aufgeteilt wurde, nicht auf die Worker.
- Übergeben Sie Workern explizit nur den minimal benötigten Kontext, um Abweichungen und Widersprüche zu vermeiden.
- Legen Sie ein Budget und ein Tiefenlimit fest; eine grenzenlose Orchestrierung lässt die Agenten-Kosten explodieren.
- Machen Sie den Plan des Orchestrators einsehbar, damit Fehler auf eine bestimmte Teilaufgabe zurückgeführt werden können.
FAQs
- Wie unterscheidet sich dies von der Parallelisierung?
- Die Parallelisierung nutzt eine feste, vordefinierte Aufteilung. Orchestrator-Workers entscheidet über die Teilaufgaben dynamisch zur Laufzeit und bewältigt so Aufgaben, deren Struktur je nach Eingabe variiert.
- Handelt es sich hierbei um ein Multi-Agenten-System?
- Ja – es ist ein gängiges Multi-Agenten-Muster. Verwenden Sie es nur, wenn eine Aufgabe tatsächlich von dynamischen, trennbaren Teilaufgaben profitiert.
- Wie verhindere ich, dass es außer Kontrolle gerät?
- Legen Sie Budgets, Schrittbegrenzungen und Abbruchbedingungen fest und fügen Sie Observability hinzu, damit Sie die Planung des Orchestrators einsehen und eingrenzen können.