Orchestration Patterns

Wissen

Das zentrale Problem in Multi-Agent Systemen ist nicht der einzelne Agent -- es ist die Koordination. Wer gibt Aufgaben? Wer bekommt welche Information? Was passiert bei Konflikten? Die Antwort liegt im Orchestration Pattern.

Vier Patterns haben sich in der Praxis bewährt. Jedes löst das Koordinationsproblem auf eine andere Art:

Pattern 1: Meta-Controller

Ein zentraler Controller-Agent koordiniert alle anderen Agents. Er nimmt die Aufgabe entgegen, zerlegt sie in Teilaufgaben, delegiert an spezialisierte Sub-Agents und fügt die Ergebnisse zusammen.

                    ┌──────────────┐
                    │  Meta-       │
                    │  Controller  │
                    └──────┬───────┘
                           │
              ┌────────────┼────────────┐
              v            v            v
        ┌──────────┐ ┌──────────┐ ┌──────────┐
        │ Agent A  │ │ Agent B  │ │ Agent C  │
        │ (Code)   │ │ (Review) │ │ (Test)   │
        └──────────┘ └──────────┘ └──────────┘

Der Meta-Controller ist typischerweise ein leistungsstarkes Modell (Opus, GPT-5.6), das die strategischen Entscheidungen trifft. Die Sub-Agents können günstigere Modelle sein, die ihre spezifische Aufgabe ausführen.

Pattern 2: Plan-and-Execute (Vertiefung)

Du kennst Plan-and-Execute bereits aus dem Fortgeschrittenen-Modul: Ein teures Modell plant, ein günstiges führt aus. In Multi-Agent Systemen wird dieses Pattern mächtiger, weil der Planner nicht nur Schritte definiert, sondern ganze Agent-Teams orchestriert.

Planner (Opus)
  │
  ├── Schritt 1: Research-Agent sammelt Daten
  ├── Schritt 2: Analysis-Agent wertet aus (parallel: 3 Instanzen)
  ├── Schritt 3: Writer-Agent erstellt Bericht
  └── Schritt 4: Review-Agent prüft Qualität
                    │
                    └── Bei Problemen: Zurück zum Planner

Der entscheidende Unterschied zur Einzelaufgaben-Variante: Der Planner kennt die Fähigkeiten jedes Agents und kann Schritte parallelisieren.

Pattern 3: Blackboard Architecture

Statt dass ein Controller Aufgaben verteilt, arbeiten alle Agents an einem gemeinsamen Wissensraum -- dem "Blackboard". Jeder Agent beobachtet das Blackboard, erkennt, wann sein Wissen gefragt ist, und trägt sein Ergebnis bei.

        ┌──────────┐  ┌──────────┐  ┌──────────┐
        │ Agent A  │  │ Agent B  │  │ Agent C  │
        └────┬─────┘  └────┬─────┘  └────┬─────┘
             │              │              │
             v              v              v
        ╔══════════════════════════════════════╗
        ║         BLACKBOARD                   ║
        ║  (Gemeinsamer Wissensraum)           ║
        ║                                      ║
        ║  - Aufgabe: "Analysiere System X"    ║
        ║  - Agent A: Security-Analyse done    ║
        ║  - Agent B: Performance-Daten...     ║
        ║  - Agent C: wartet auf B             ║
        ╚══════════════════════════════════════╝

Das Blackboard Pattern ist ideal, wenn keine klare Aufgabenreihenfolge existiert, emergentes Verhalten erwünscht ist und Loose Coupling wichtig ist.

Pattern 4: Ensemble Decision-Making

Statt einem Agent die Entscheidung zu überlassen, lässt du mehrere Agents unabhängig dieselbe Frage beantworten und aggregierst die Antworten. Das ist das "Wisdom of Crowds"-Prinzip, angewandt auf AI Agents.

        Aufgabe: "Ist dieser Code sicher?"
                    │
        ┌───────────┼───────────┐
        v           v           v
   ┌─────────┐ ┌─────────┐ ┌─────────┐
   │ Agent 1 │ │ Agent 2 │ │ Agent 3 │
   │ (Opus)  │ │ (GPT-5) │ │ (Gemini)│
   │ Ja: 85% │ │ Nein    │ │ Ja: 70% │
   └─────────┘ └─────────┘ └─────────┘
        │           │           │
        v           v           v
   ┌──────────────────────────────────┐
   │  Aggregator                      │
   │  Mehrheitsentscheid: Ja (2:1)    │
   │  Aber: Agent 2 warnt → Eskalation│
   └──────────────────────────────────┘

Varianten der Aggregation: Majority Voting, Weighted Voting, Debate (Multi-Runden) und Red-Team / Blue-Team.

Verstehen

Praxisbeispiel: Claude Code

Claude Code (Anthropics CLI-Coding-Agent) nutzt ein Meta-Controller Pattern: Ein Haupt-Agent koordiniert Sub-Agents für verschiedene Aufgaben -- Dateianalyse, Code-Generierung, Test-Ausführung. Der Controller entscheidet, welcher Sub-Agent wann aktiv wird.

Dynamische Re-Planung

Das fortgeschrittene Plan-and-Execute Pattern enthält einen Evaluator, der nach jedem Schritt prüft: Passt das Ergebnis zum Plan? Falls nicht, geht die Kontrolle zurück an den Planner, der den Rest des Plans anpassen kann. Das gibt dem System Flexibilität, ohne die Kostenvorteile zu verlieren.

Wann Blackboard statt Controller?

Die Schwäche des Blackboard Patterns: Ohne zentralen Controller kann es zu Koordinationsproblemen kommen. Wer entscheidet, wann die Aufgabe fertig ist? Was passiert bei widersprüchlichen Beiträgen?

Praxisbeispiel: Architektur-Review -- Ein Blackboard-System für Code-Architektur-Reviews: Ein Security-Agent, ein Performance-Agent und ein Maintainability-Agent analysieren unabhängig denselben Code. Ihre Findings landen auf dem Blackboard. Ein Synthesizer-Agent liest alle Findings und erstellt einen konsolidierten Review.

Wann Ensemble statt Einzelentscheidung?

Ensemble Decision-Making lohnt sich bei high-stakes Entscheidungen, wo ein einzelner Fehler teuer wäre: Security-Reviews, medizinische Diagnosen, finanzielle Bewertungen. Der Overhead (mehrere Agents, mehr Kosten) wird durch die höhere Zuverlässigkeit gerechtfertigt.

Patterns im Vergleich

Anwenden

Die Wahl des Patterns ist eine der wichtigsten Architekturentscheidungen in Multi-Agent Systemen. Teste dein Verständnis mit den folgenden Szenarien:

Reflektieren

Die vier Orchestration Patterns -- Meta-Controller, Plan-and-Execute, Blackboard Architecture und Ensemble Decision-Making -- sind das Fundament jeder Multi-Agent Architektur. Das richtige Pattern zu wählen, hängt von Vorhersagbarkeit, Kosten und Fehlertoleranz ab. Im nächsten Abschnitt schauen wir uns die Frameworks an, die dir bei der Implementierung helfen.