Vier Multi-Agent-Orchestrierungsmuster

Wenn wir beginnen, agentische Anwendungen zu entwickeln, lernen wir als Erstes, dass mehrere Agenten allein nicht ausreichen.

Die eigentliche Frage lautet:

Wie sollten diese Agenten zusammenarbeiten?

Ein Multi-Agenten-System benötigt eine Orchestrierungsstrategie.

Manche Aufgaben sind vorhersagbar und sollten einer festen Reihenfolge folgen. Andere können parallel laufen. Manche erfordern einen zentralen Agenten, der dynamisch Entscheidungen trifft, während andere davon profitieren, dass Agenten sich gegenseitig überprüfen und kritisieren.

In der Praxis gibt es vier sehr nützliche Orchestrierungsmuster, die eine große Anzahl agentischer Anwendungen abdecken:

• Sequentiell
• Gleichzeitig / Parallel
• Magentic Router
• Gruppenchat / Debatte

Wichtig ist, nicht ein einziges Muster für das gesamte System zu wählen. Eine echte Unternehmenslösung kann je nach Problem mehrere davon kombinieren.

🔄 Sequentielles Muster

Das sequentielle Muster ist wahrscheinlich am einfachsten zu verstehen. Es funktioniert wie ein Fließband. Ein Agent führt eine Aufgabe aus, gibt das Ergebnis weiter, und dann setzt der nächste Agent die Arbeit fort.

Zum Beispiel:

Recherche-Agent
      ↓
Zusammenfassungs-Agent
      ↓
E-Mail-Agent

Der Recherche-Agent sammelt zunächst Informationen. Der Zusammenfassungs-Agent erhält das Rechercheergebnis und erstellt eine präzise Zusammenfassung. Schließlich erhält der E-Mail-Agent die Zusammenfassung und bereitet die endgültige Nachricht vor oder sendet sie.

Das wesentliche Merkmal ist hier, dass die Reihenfolge vordefiniert ist.

A → B → C

Agent B ist abhängig von der Ausgabe von Agent A, und Agent C ist abhängig von dem Ergebnis von Agent B. Dieses Muster funktioniert sehr gut, wenn der Geschäftsprozess vorhersagbar ist und jeder Schritt natürlich vom vorherigen abhängt.

Der Nachteil ist die geringe Anpassungsfähigkeit. Wenn Schritt A fünf Sekunden dauert, Schritt B fünf Sekunden und Schritt C fünf Sekunden, kann die Gesamtausführung etwa fünfzehn Sekunden dauern, da jeder Vorgang auf den vorherigen wartet. Daher ist sequentiell ein gutes Muster für abhängige Aufgaben, aber nicht unbedingt für unabhängige Arbeiten.

⚡ Gleichzeitiges / Paralleles Muster

Das gleichzeitige Muster ist nützlich, wenn mehrere Agenten gleichzeitig unabhängige Aufgaben ausführen können. Stellen Sie sich vor, ein Agent benötigt Informationen aus drei verschiedenen Quellen:

              ┌─ Websuche-Agent
Benutzeranfrage ───┼─ Datenbank-Agent
              └─ Dokumentsuche-Agent
                       ↓
                    Zusammenführer

Es gibt keinen Grund, auf das Ende der Websuche zu warten, bevor die Datenbank abgefragt wird. Diese Vorgänge sind unabhängig. Der Workflow kann alle drei Agenten gleichzeitig ausführen und auf alle Ergebnisse warten, bevor es weitergeht. Ein abschließender Zusammenführer- oder Synthese-Agent kann dann die Informationen kombinieren.

Dies hat einen sehr wichtigen Vorteil: die Latenz.

Stellen Sie sich vor:

Websuche            = 4 Sekunden
Datenbank           = 3 Sekunden
Dokumentsuche       = 5 Sekunden

Die sequentielle Ausführung würde etwa dauern:

4 + 3 + 5 = 12 Sekunden

Bei paralleler Ausführung liegt die Gesamtzeit näher am langsamsten Vorgang:

≈ 5 Sekunden

Echte Systeme haben natürlich Netzwerk-Overhead, Provider-Limits und Synchronisationskosten, aber das Architekturprinzip bleibt gleich.

Gleichzeitige Orchestrierung ist ideal, wenn die Aufgaben unabhängig sind. Typische Beispiele sind:

• Durchsuchen mehrerer Datenquellen
• Ausführen unabhängiger Sicherheitsprüfungen
• Einholen von Meinungen mehrerer Spezialagenten
• Paralleles Sammeln von Informationen über APIs
• Vergleichen mehrerer Datensätze

Die entscheidende Frage lautet:

Benötigt Agent B das Ergebnis von Agent A?

Wenn die Antwort nein lautet, könnte die parallele Ausführung die bessere Architektur sein.

🧭 Magentic Router-Muster

Das Magentic-Router-Muster ist deutlich dynamischer. Anstatt den gesamten Pfad vorher festzulegen, führen wir einen zentralen Orchestrator ein. Dieser Agent verhält sich wie ein Projektmanager. Jedes Mal, wenn ein Worker seine Aufgabe beendet hat, kehrt die Kontrolle zum Router zurück. Der Router analysiert den aktuellen gemeinsamen Zustand und entscheidet, was als Nächstes passieren soll.

Zum Beispiel:

              ┌─ Research Agent ──┐
              │                   │
Router ───────┼─ Finance Agent ───┼─→ Router
              │                   │
              └─ Technical Agent ─┘

Der Ablauf könnte so aussehen:

Router
   ↓
Research Agent
   ↓
State updated
   ↓
Router
   ↓
Technical Agent
   ↓
State updated
   ↓
Router
   ↓
Finish

Der wesentliche Unterschied besteht darin, dass der Router den Zustand nach jedem Schritt bewertet. Er kann entscheiden:

Einen anderen Agenten aufrufen
Denselben Agenten erneut aufrufen
Ein anderes Tool verwenden
Weitere Informationen anfordern
Den Arbeitsablauf beenden

Hier werden Multi-Agent-Systeme deutlich anpassungsfähiger. Anstatt zur Entwurfszeit ein festes Ablaufdiagramm zu erstellen, wird ein Teil des Arbeitsablaufs dynamisch während der Ausführung erzeugt.

Allerdings gibt es eine wichtige architektonische Überlegung. Ich würde nicht jede Entscheidung unter die Kontrolle des LLM stellen. Für Unternehmensanwendungen ist die beste Architektur in der Regel hybrid.

Zum Beispiel:

LLM Router
    ↓
Select specialist
    ↓
Deterministic validation
    ↓
Business rules
    ↓
Human approval if required
    ↓
Execution

Eine Rückerstattung, Zahlung, Löschung oder andere kritische Operation sollte nicht einfach passieren, weil ein LLM entschieden hat, dass es eine gute Idee sei. Probabilistisches Denken und deterministische Kontrollen sollten zusammenwirken.

💬 Group Chat / Debate Pattern

Das Group Chat-Muster unterscheidet sich von der Router-Architektur. Anstatt dass Agenten einfach isolierte Aufgaben ausführen, können Agenten an einer gemeinsamen Konversation teilnehmen und die Arbeit der anderen überprüfen.

Ein klassisches Beispiel ist:

Writer Agent
     ↓
Critic Agent
     ↓
Writer Agent
     ↓
Critic Agent
     ↓
Final Result

Der Writer erstellt die erste Version. Der Critic überprüft sie und sagt etwas wie:

This section is too complex.
The argument needs stronger evidence.
The conclusion is unclear.

Der Writer erhält dieses Feedback und erstellt eine weitere Version. Der Prozess kann sich wiederholen, bis das Ergebnis ein akzeptables Qualitätsniveau erreicht.

Dieses Muster ist nützlich, wenn das Ziel nicht nur die Erledigung einer Aufgabe ist, sondern die Verbesserung ihrer Qualität durch Iteration. Beispiele sind:

• Technical document review
• Architecture review
• Code review
• Legal analysis
• Security review
• Content generation
• Research reports

Der gemeinsame Zustand in dieser Art von Arbeitsablauf ähnelt oft eher einem Konversationsverlauf. Jeder Agent kann frühere Nachrichten sehen und eine weitere Perspektive beisteuern.

Maximum 4 iterations

Stop when Critic approves

Stop when confidence > threshold

🧩 Sequential vs Concurrent vs Router vs Debate

Eine einfache Möglichkeit, sich die vier Muster zu merken, ist:

Sequential
→ Tasks depend on each other

Concurrent
→ Tasks are independent

Magentic Router
→ The next task is not known in advance

Group Chat
→ Agents iteratively improve each other's work

Zum Beispiel:

Wenn ich benötige:

Research → Summary → Email

würde ich Sequential verwenden.

Wenn ich benötige:

Web Search
Database Search
Document Search

zur gleichen Zeit, würde ich Concurrent verwenden.

Wenn ich nicht weiß, ob ich Forschung, Berechnung, einen anderen Spezialisten oder einen weiteren Versuch benötige, bis ich die aktuellen Ergebnisse sehe, würde ich einen Router verwenden. Wenn ich möchte, dass ein Agent etwas erstellt und ein anderer es wiederholt überprüft, würde ich Group Chat verwenden.

🔄 Muster kombinieren

Der interessanteste Teil ist, dass diese Muster sich nicht gegenseitig ausschließen. Ein anspruchsvoller Workflow könnte so aussehen:

                    ┌─ Web Search
                    │
Router ─→ Research ─┼─ Database Search
                    │
                    └─ Document Search
                           ↓
                         Joiner
                           ↓
                        Writer
                           ↓
                        Critic
                           ↓
                         Router

Hier kombinieren wir:

• Magentic Router
• Nebenläufige Ausführung
• Group Chat
• Möglicherweise sequentielle Schritte

Hier werden agentische Workflows leistungsstark.

Statt zu fragen:

Welches Orchestrierungsmuster sollte meine Anwendung verwenden?

Eine bessere Frage ist:

Welches Orchestrierungsmuster sollte jeder Teil meiner Anwendung verwenden?

⚙️ Determinismus zählt immer noch

Eine wichtige Lektion aus dem Bau agentischer Systeme ist, dass die Einführung von Agenten nicht bedeutet, dass alles probabilistisch werden sollte. Eine robuste Architektur trennt weiterhin Verantwortlichkeiten.

Das LLM kann übernehmen:

Intentionsverständnis
Schlussfolgerung
Klassifizierung
Planung
Auswahl von Spezialisten
Erstellung von Erklärungen

C# und deterministische Systeme sollten weiterhin übernehmen:

Zustandsänderung
Validierung
Autorisierung
Geschäftsregeln
Persistenz
Finanztransaktionen
Sicherheitsrichtlinien
Workflow-Einschränkungen

Zum Beispiel könnte ein LLM ein IT-Ticket klassifizieren als:

Hardware

Aber C# kann dieses Ergebnis abbilden auf:

TicketCategory.Hardware

und eine deterministische Workflow-Kante entscheidet, wohin die Anfrage tatsächlich geht. Das ergibt eine nützliche Balance:

Probabilistische Intelligenz
        ↓
Typisierter deterministischer Zustand
        ↓
Kontrollierte Ausführung

Dies ist besonders wichtig beim Bau von Enterprise-KI-Systemen.

🏁 Schlussgedanken

Multi-Agenten-Architektur geht nicht darum, so viele Agenten wie möglich zu erstellen. Es geht darum, klare Verantwortlichkeiten zuzuweisen und das richtige Kommunikationsmuster zwischen ihnen zu wählen.

• ✅ Sequentielle Workflows geben uns Vorhersagbarkeit.
• ✅ Nebenläufige Workflows geben uns Geschwindigkeit.
• ✅ Magentic Router geben uns Anpassungsfähigkeit.
• ✅ Group Chat Workflows geben uns iterative Verbesserung.

Und echte Systeme werden wahrscheinlich alle vier kombinieren.

Das wichtigste Architekturprinzip ist, die Agenten fokussiert zu halten, den gemeinsamen Zustand explizit zu halten und kritische Geschäftsabläufe unter deterministischer Kontrolle zu lassen. Agenten sollten Intelligenz liefern. Der Workflow sollte Struktur liefern.