Multi-Agent-Orchestrierung: Architekturen im Vergleich

Welche Orchestrierungsarchitektur passt zu welcher Aufgabe?

Eine Orchestrierungsarchitektur legt fest, wer Teilaufgaben startet, welche Informationen geteilt werden und wer über Weitergabe, Wiederholung und Freigabe entscheidet. Sie ist keine Modellrangliste. Sequenzielle und parallele Workflows können bei gleicher Aufgabe unterschiedlich abschneiden, weil Latenz, Kontextverlust, Fehlerkosten und Kontrollbedarf verschieden sind. Die Dokumentation des Microsoft Agent Framework beschreibt unter anderem Sequential, Concurrent, Handoff, Group Chat und Magentic; das ist ein belegter Funktionsumfang des Frameworks, kein unabhängiger Performancenachweis. Microsoft Learn.

Sieben Muster im strukturierten Vergleich

Diese Matrix beschreibt Architekturmerkmale und typische Risiken; sie ist kein gemessener Siegervergleich. Welche dieser Muster ein konkretes Produkt wirklich unterstützt, muss durch die jeweilige Produktdokumentation belegt werden. Insbesondere besitzt eine Plattform nicht automatisch alle Fähigkeiten ihres Frameworks oder ihrer integrierten Agenten.

Muster und Verantwortlichkeiten im Detail

1. Einzelagent als notwendige Baseline

Ein einzelner Agent erledigt den Auftrag mit einem Tool- und Kontextbereich. Das ist oft die beste Kontrollgruppe, weil zusätzliche Komponenten sonst unbemerkt Kosten verursachen. Dokumentieren Sie Modell, Prompt, Tools, Zeitlimit, Datenzugriff und Ergebnis. Erst danach lässt sich prüfen, ob Rollenteilung wirklich hilft.

2. Sequenziell: sichere Reihenfolge vor Parallelität

Bei einem geordneten Review erzeugt ein Agent einen Entwurf, ein zweiter prüft Quellen und ein dritter legt ein Ergebnis zur Freigabe vor. Die Ausgabe jedes Schritts ist ein klar versioniertes Artefakt. Nachteil: Jeder Schritt wartet auf den vorherigen. Ein fehlerhafter erster Schritt kann alle folgenden Schritte beeinflussen. Deshalb gehört ein Validierungsgate zwischen kritische Stationen.

3. Concurrent: echte Unabhängigkeit ausnutzen

Drei Agenten recherchieren voneinander unabhängige Quellen. Der Orchestrator führt die Resultate erst zusammen, wenn definierte Mindestbelege vorliegen oder ein Zeitlimit erreicht ist. Typische Fehler sind konkurrierende Änderungen am selben Dokument und das mehrfache Nutzen derselben unzuverlässigen Quelle. Entscheidend ist eine nachgelagerte Konfliktprüfung, kein blindes Mehrheitsvotum.

4. Handoff: Zuständigkeit bewusst übergeben

Ein Triage-Agent erkennt, dass eine Anfrage in den Zuständigkeitsbereich eines Spezialagenten fällt. Er übergibt den Auftrag einschließlich Berechtigungsscope, verbleibender Arbeit, relevanter Quellen und Frist. Ein Handoff ist nicht die Freigabe, beliebige neue Werkzeuge einzusetzen. Fehlen Kontext und Auftragsvertrag, wird die nächste Instanz scheinbar autonom, tatsächlich aber unkontrollierbar.

5. Group Chat: Diskussion mit Abbruchkriterium

Mehrere Agenten äußern Vorschläge in einem gemeinsamen Verlauf, eine Instanz moderiert oder bewertet. Das kann alternative Lösungswege sichtbar machen. Ohne begrenzte Runden, Zitationspflicht und eine unabhängige Entscheidung können dagegen Wiederholungen und Scheinkonsens dominieren. Gleiche zugrunde liegende Modelle reduzieren die Unabhängigkeit vermeintlich unterschiedlicher Meinungen.

6. Hierarchie: Supervisor als Governance-Punkt

Ein übergeordneter Agent weist klar spezifizierte Unteraufgaben zu und prüft Rückmeldungen. Hier kann eine Organisation Freigaben, Identitäten und Kostenbudgets bündeln. Der Supervisor muss aber selbst gegen Prompt Injection und unberechtigte Ausführung geschützt werden. Ein einzelner Ausfall darf keine unkontrollierten Nebenwirkungen auslösen.

7. Graph / Hybrid: bedingte Steuerung mit Checkpoints

Ein graphbasierter Ablauf verzweigt anhand überprüfbarer Zustände: Wenn Quellen fehlen, wird erneut recherchiert; wenn ein Test scheitert, folgt eine Korrekturschleife; nach bestandener Prüfung geht es zur Freigabe. Das erfordert versionierte Zustandsübergänge, explizite Guardrails und eine überprüfbare Abbruchgrenze. Die ACL-2025-Studie MultiAgentBench prüfte verschiedene Kommunikations-/Koordinationstopologien, aber ihre Resultate lassen sich nicht ohne Weiteres auf jeden Workflow übertragen. Studie.

Szenario A: Parallele Recherche für einen technischen Vergleich

Auftrag: Drei Implementierungen sollen anhand offizieller Dokumentationen vergleichbar beschrieben werden. Eine Sequenz aus Recherche → Prüfung → Zusammenführung wäre möglich, verursacht aber Wartezeit für unabhängige Quellenarbeit. Eine Concurrent-Architektur startet jeweils eine getrennte Quellenrecherche mit identischen Anforderungen. Jede Ausgabe enthält URL, Abschnitt, Abrufdatum, Produktscope und ungelöste Fragen. Ein Prüfagent kontrolliert ausdrücklich, ob die Quellen denselben Versionsstand und denselben Begriff verwenden. Erst danach erstellt ein Zusammenführer die Vergleichsmatrix. Der Mensch entscheidet, ob ausreichend Belege vorliegen. Das Verfahren kann Latenz sparen, erhöht aber Aufrufkosten und Prüfaufwand; ein tatsächlicher Gewinn muss gemessen werden.

Szenario B: Kontrollierte mehrstufige Freigabe

Auftrag: Ein Agent soll eine Änderung an einem betrieblichen System vorschlagen. Eine sequenzielle Pipeline erzeugt einen technischen Änderungsvorschlag, prüft Auswirkungen, testet in isolierter Umgebung und wartet auf eine ausdrücklich autorisierte menschliche Freigabe. Erst dann darf ein Ausführungsagent den begrenzten Änderungsschritt durchführen. Ein unabhängiger Prüfpunkt verifiziert den Zustand; bei Fehlern ist ein definierter Rollback möglich, falls das jeweilige Produkt ihn unterstützt. Keine Gruppendiskussion darf eine erforderliche Berechtigung ersetzen.

Architekturdiagramm: Rollen, Nachrichten und Eskalation

Die folgende textbasierte Ablaufskizze zeigt einen konzeptionellen Kontrollfluss, kein tatsächlich ausgeführtes AgentenCode-System:

1. Auftrag → Eingabevertrag mit Quellen, Datenrechten und Kostenbudget.
2. Orchestrator → wählt Sequential, Concurrent oder Handoff anhand überprüfbarer Bedingungen.
3. Spezialagenten → liefern signierte oder referenzierbare Ergebnisse mit Quellen und Version.
4. Validator → prüft Schema, Zitate, Risiken, Tests und Unsicherheit.
5. Entscheidung → bei unvollständiger Evidenz zurück zur Bearbeitung; bei kritischer Aktion zur menschlichen Freigabe.
6. Ausgabe + Audit → fertiges Artefakt, Zeitpunkte, Zustände, Kosten und Verantwortlichkeiten.

Auswahlmatrix für ein echtes Pilotprojekt

Frameworks, Protokolle und reale Produktbezüge

Die offiziellen Microsoft-Agent-Framework-Workflows beschreiben konkrete Orchestrierungsbausteine. AgentenCode führt ein Profil zum Microsoft Agent Framework; die hier dokumentierten Muster beziehen sich auf die Framework-Dokumentation, nicht pauschal auf alle Microsoft-Agenten. Für systemübergreifende Kommunikation können A2A und für Werkzeugzugriff MCP relevant sein. Protokollunterstützung muss jeweils als spezifische Laufzeiteigenschaft nachgewiesen werden.

Zur Studienvergleichbarkeit siehe die Benchmark-Seite. Die Methodik erklärt Evidenzstatus, Konflikte und Quellenregeln.