Multi-Agent-Orchestrierungsmuster: Ein praktischer Leitfaden

Die Ära der Single-Agent-AI-Systeme erreichte 2025 ihren Höhepunkt — man gab einem LLM (Large Language Model) einen Prompt, einige Werkzeuge und ein Ziel, und es bewältigte begrenzte Aufgaben recht gut.

Im Jahr 2026 sind Multi-Agent-Systeme von Forschungs-Demos in die Produktionsinfrastruktur übergegangen. Gartner berichtet von einem Anstieg der Anfragen zu Multi-Agent-Systemen um 1.445 % von Q1 2024 bis Q2 2025, während der Salesforce Connectivity Benchmark Report 2026 ergab, dass Organisationen im Durchschnitt 12 Agenten einsetzen, was innerhalb von zwei Jahren um weitere 67 % wachsen soll. Der AI Systems Cluster behandelt den gesamten Stack, auf dem diese Systeme operieren — von Inferenz und Speicher bis hin zu Routing und Observability.

Doch was seltener diskutiert wird: 40 % der Multi-Agent-Pilotprojekte scheitern innerhalb von sechs Monaten nach der Produktionsfreigabe. Der Misserfolg liegt nicht daran, dass Multi-Agent-Systeme nicht funktionieren. Der Misserfolg besteht darin, dass Teams das falsche Orchestrierungsmuster für ihr Problem wählen — oder das richtige wählen, ohne zu verstehen, wie es zusammenbricht.

Dieser Leitfaden behandelt die Orchestrierungsmuster, die in der Produktion bestehen, die spezifischen Ausfallmechanismen jedes Musters und ein Entscheidungsframework für die Auswahl der richtigen Architektur.

Das Kernproblem: Koordination ist schwierig

Wenn Sie von einem einzelnen KI-Agenten zu mehreren zusammenarbeitenden Agenten wechseln, ist die erste technische Frage: Wie koordinieren sie sich?

Das Koordinationsmodell — das Orchestrierungsmuster — bestimmt die Latenz, die Fehlertoleranz, die Skalierungsgrenze und die Debugging-Komplexität Ihres Systems. Es ist konsistent die architekturbedingende Entscheidung mit der größten Auswirkung im Multi-Agent-Design und bedingt jede nachfolgende Implementierungsentscheidung.

Jedes produktionsreife Multi-Agent-System entspricht einem von sechs kanonischen Mustern oder einer Hybridform aus zwei oder mehr. Die Muster entstehen aus den Beschränkungen verteilter Systeme: Koordinationskosten, Fehlerisolierung, Durchsatzanforderungen und Observability.

Muster 1: Orchestrator-Worker

Wie es funktioniert

Orchestrator-Worker ist das zentralisierte Hub-and-Spoke-Modell der Multi-Agent-Koordination. Ein einzelner Orchestrierer-Agent erhält die Aufgabe, zerlegt sie in Teilaufgaben, delegiert jede Teilaufgabe an einen spezialisierten Worker-Agent und aggregiert die Ergebnisse. Worker kommunizieren nicht direkt miteinander — die gesamte Koordination läuft über den Orchestrierer, der den vollständigen Plan und die Entscheidungsbefugnis hält.

Wann man es einsetzen sollte

• Cross-funktionale Workflows mit klarer Aufgabenzerlegung
• Triage- und Routing-Szenarien (Kundensupport, Incident-Klassifizierung)
• Arbeitslasten, bei denen ein einzelner Verantwortlichkeitspunkt erforderlich ist
• Aufgaben, bei denen der Orchestrierer ein leistungsfähiges Modell verwenden kann, während Worker günstigere, aufgaben spezifische Modelle nutzen

Praxisbeispiel: Salesforce Agentforce 2.0 nutzt Orchestrator-Worker, um Kundenanfragen in Forschungs-, Entwurfs- und Review-Phasen zu zerlegen.

Wie es scheitert

Single Point of Failure (Einzelner Ausfallpunkt). Der Orchestrierer ist sowohl ein Engpass als auch ein Ausfallpunkt. Wenn der LLM-Aufruf des Orchestriers 3 Sekunden dauert und 20 Worker auf Zuweisungen warten, liegt Ihre maximale Zerlegungskapazität bei etwa 6,7 Aufgaben pro Sekunde. Wenn der Orchestrierer eine Aufgabe falsch klassifiziert, erhält der falsche Worker sie — und Fehlklassifizierungsraten summieren sich im großen Maßstab.

Kontextüberlauf. Der Orchestrierer sammelt Kontext von allen Workern. Ab 4+ Workern überschreitet der Orchestrierer häufig Kontextlimits, da er gleichzeitig den vollständigen Gesprächsverlauf für jede Worker-Interaktion hält.

Kostenexplosion. Workflows, die im Test 0,50 $ kosten, können bei 100.000 Ausführungen 50.000 $ pro Monat erreichen. Der Orchestrierer führt mehrere LLM-Aufrufe für Zerlegung und Aggregation zusätzlich zu jedem Worker-Aufruf durch. Im großen Maßstab dominiert der Overhead die Worker-Kosten.

Gegenmaßnahmen

• Definieren Sie explizite Interface-Verträge zwischen Orchestrierer und Workern
• Fordern Sie strukturierte Ausgaben von Workern (JSON-Schemas, typisierte Antworten)
• Begrenzen Sie Subtask-Budgets (Token-Limits, Schrittlimits), um unkontrollierbare Kosten zu verhindern
• Erwägen Sie eine hierarchische Variante (siehe Muster 4), wenn die Anzahl der Worker 5 überschreitet

Muster 2: Sequential Pipeline

Wie es funktioniert

Sequential Pipeline ist die lineare Kette mit gemeinsamem Zustand — eine vordefinierte Sequenz von Agenten mit deterministischer Reihenfolge, bei der jede Stufe Daten transformiert oder anreichert und sie an die nächste weitergibt. Es gibt kein Branching zur Laufzeit; die Ausführungsreihenfolge ist zum Designzeitpunkt festgelegt, was das Muster hochgradig vorhersehbar, aber unflexibel macht.

Wann man es einsetzen sollte

• Dokumentverarbeitungs-Workflows (Eingabe → Extraktion → Validierung → Ausgabe)
• Content-Generierungs-Pipelines (Forschung → Entwurf → Bearbeitung → Veröffentlichung)
• Compliance-Verifikation (Generierung → Prüfung → Überarbeitung → Genehmigung)
• Datenanreicherungs- und ETL-Workflows

Praxisbeispiel: Microsoft Azure Law Firm Workflow nutzt sequentielle Pipelines für die Vertragsgenerierung: Entwurf → Review → Redlining → Finale.

Wie es scheitert

Fehlerfortpflanzung. Schlechte Ausgabe in Stufe 1 pflanzt sich flussabwärts fort, ohne Rückverfolgung. Eine Halluzination in der Forschungsstufe produziert einen fehlerhaften Entwurf, den der Redakteur zu einem selbstbewussten, aber falschen Endausgang poliert.

Koordinations-Overhead. Eine 4-Agent-Pipeline fügt etwa 950 ms Koordinations-Overhead gegenüber 500 ms Verarbeitungszeit hinzu. Sie zahlen das 3-fache für dasselbe Ergebnis, wenn Spezialisierung nicht erforderlich ist. Der Token-Verbrauch summiert sich: 29.000 Tokens über einer 4-Agent-Pipeline gegenüber 10.000 für einen einzelnen Agenten, der dieselbe Arbeit leistet.

Kein konditionales Branching. Die Pipeline kann sich nicht basierend auf Zwischenergebnissen anpassen. Wenn Stufe 2 feststellt, dass die Eingabe fehlerhaft ist, hat sie keinen Mechanismus, um Stufe 1 zum erneuten Versuch aufzufordern — sie muss entweder scheitern oder eine degradierte Ausgabe produzieren.

Gegenmaßnahmen

• Fügen Sie Qualitätskontrollen zwischen Stufen ein (leichtgewichtige Validierungsagenten, die die Ausgabe vor der Weitergabe prüfen)
• Fügen Sie Verarbeitungsschleifen für Stufen hinzu, die erneut versucht werden können — robuste Workflow-Engines wie Temporal handhaben Retry-Semantik zuverlässig
• Halten Sie Pipelines auf maximal 3-4 Stufen; darüber hinaus sollten Sie Orchestrator-Worker für konditionales Branching in Betracht ziehen

Muster 3: Fan-Out / Fan-In

Wie es funktioniert

Fan-Out / Fan-In ist parallele Ausführung mit Aggregation. Ein Dispatcher leitet Arbeit an mehrere gleichzeitig laufende Agenten weiter, und ein Collector aggregiert deren Ergebnisse via Voting, gewichteter Zusammenführung oder LLM-Synthese. Agenten arbeiten während der gesamten Ausführung unabhängig und kommunizieren nicht miteinander — die einzige gemeinsame Grenze ist der Collector.

Wann man es einsetzen sollte

• Analyse aus mehreren Perspektiven, bei der diverse Standpunkte wertvoll sind
• Parallele Code-Reviews (mehrere Reviewer parallel)
• 4+ unabhängige Tasks, die im Voraus zerlegt werden können
• Arbeitslasten, bei denen die Wall-Clock-Zeit wichtiger ist als Token-Effizienz

Kennzahl: Fan-Out reduziert die Wall-Clock-Zeit um 75 % im Vergleich zur sequentiellen Ausführung. Vier parallel laufende Agenten sind in der Zeit eines einzelnen fertig.

Wie es scheitert

API-Ratenlimits. Die kollektive Last überschreitet die Kapazität, auch wenn einzelne Agenten innerhalb der Limits bleiben. Fünf Agenten, die jeweils 10 Anfragen pro Minute stellen, können ein Limit von 40 RPM überschreiten, das ein einzelner Agent respektiert.

Quadratische Race Conditions. Konflikte in gemeinsamen Zuständen skalieren als N(N-1)/2. Bei 5 Agenten sind das 10 potenzielle Konflikte. Bei 10 Agenten sind es 45. State-Management wird zur dominanten Komplexität.

Aggregations-Halluzination. LLM-Synthese kann Konsens erfinden. Wenn Agent A “Ja” sagt und Agent B “Nein”, könnte der Aggregator “Vielleicht” produzieren — eine halluzinierte Mittelstellung, die keiner der Agenten vorgeschlagen hat. Erfordert explizite Konfliktlösung, nicht nur Zusammenfassung.

Gegenmaßnahmen

• Nutzen Sie explizite Voting-Mechanismen statt freier Synthese
• Implementieren Sie Ratenbegrenzung auf Dispatcher-Ebene
• Halten Sie den Zustand pro Worker separat zusammen; führen Sie am Collector zusammen
• Setzen Sie eine maximale Agentenanzahl (5-8), um Race Conditions handhabbar zu halten

Muster 4: Hierarchical

Wie es funktioniert

Hierarchical ist baumstrukturierte Delegation mit mehreren Ebenen — ein Top-Level-Manager delegiert an Mid-Level-Supervisors, die wiederum an leaf-level Worker delegieren. Jede Ebene fügt eine Abstraktionsebene hinzu: Strategie an der Spitze, Taktik in der Mitte und Ausführung an den Blättern. Kontextfenster werden auf jeder Ebene unabhängig verwaltet, sodass kein einzelner Agent das gesamte Problem im Kontext halten muss.

Wann man es einsetzen sollte

• Komplexe, multidomäne Enterprise-Aufgaben, die 20+ Agenten erfordern
• Großangelegte Codebase-Audits, bei denen verschiedene Module verschiedene Spezialisten benötigen
• Massive Dokumentverarbeitung (Tausende von Dokumenten über mehrere Kategorien hinweg)
• Aufgaben, bei denen kein einzelner Agent-Kontext das gesamte Problem halten kann

Vorteil: Hierarchische Systeme skalieren logarithmisch. Jeder Manager handhabt eine begrenzte Anzahl von Untergebenen, sodass das Hinzufügen von Workern den Koordinations-Overhead nicht linear erhöht.

Wie es scheitert

Latenzakkumulation. Jede Ebene fügt Latenz hinzu. Eine 3-Ebenen-Hierarchie erfordert mindestens 6-12 Sekunden Mindestzeit, die sich pro Ebene summiert. Der Top-Manager wartet auf alle Supervisors, die wiederum auf alle Worker warten.

Informationsverlust. Zusammenfassung zwischen Ebenen ist verlustbehaftet. Ein Supervisor fasst die Worker-Ausgabe für den Top-Manager zusammen, wobei Details verloren gehen, die für die endgültige Entscheidung kritisch sein könnten.

Branch-Fehlerisolierung. Ein Ausfall in einem Branch pflanzt sich nicht auf andere fort — was gut für die Fehlertoleranz, aber schlecht für die Konsistenz ist. Verschiedene Branches könnten zu widersprüchlichen Schlussfolgerungen gelangen, die der Top-Manager nicht auflösen kann.

Gegenmaßnahmen

• Setzen Sie explizite Zusammenfassungsanforderungen für jede Ebene
• Implementieren Sie Cross-Branch-Validierung beim Top-Manager
• Halten Sie die Hierarchietiefe auf maximal 2-3 Ebenen
• Nutzen Sie strukturierte Ausgaben auf jeder Ebene, um Informationsverlust zu reduzieren

Muster 5: Swarm

Wie es funktioniert

Swarm ist dezentrale emergente Koordination ohne zentrale Autorität. Autonome Agenten treffen lokale Entscheidungen basierend auf gemeinsamem Zustand (ein Blackboard) oder Umweltsignalen, ohne dass ein Orchestrierer den Fluss lenkt. Agenten entdecken verfügbare Tasks, beanspruchen sie und veröffentlichen Ergebnisse zurück in den gemeinsamen Raum. Koordination ist emergent — das System organisiert sich selbst um verfügbare Arbeit ähnlich wie Bienen, die zu einem neuen Stock navigieren, ohne einen zentralen Koordinator.

Wann man es einsetzen sollte

• Forschungsflows, bei denen der optimale Suchpfad unbekannt ist
• Wettbewerbsintelligenz-Erhebung über mehrere Quellen
• Großangelegtes Web-Scraping mit dynamischer Zielentdeckung
• Parallele Hypothesenexploration in wissenschaftlichen oder analytischen Domänen

Vorteil: Ein Swarm von 50 Forschungsagenten kann 50 Hypothesen parallel erkunden, ohne dass ein zentraler Koordinator die Suche plant. Das System organisiert sich selbst um verfügbare Arbeit.

Wie es scheitert

Debugging-Alptraum. Ohne zentralen Kontrollfluss erfordert das Nachverfolgen von Ausfällen verteiltes Tracing und Blackboard-Replay. Sie können keinen einzelnen Ausführungspfad folgen — Sie müssen das emergente Verhalten aus Logs rekonstruieren.

Keine transaktionalen Garantien. Swarm-Muster können strikte Reihenfolge oder transaktionale Konsistenz nicht durchsetzen. Wenn Sie benötigen, dass Agent A vor Agent B abgeschlossen wird, ist ein Swarm das falsche Muster.

Terminierungsbedingungen. Wie weiß der Swarm, wann er aufhören soll? Ohne explizite Terminierungskriterien können Agenten unendlich weitermachen, Compute verbrauchen und abnehmende Renditen generieren.

Gegenmaßnahmen

• Implementieren Sie explizite Terminierungsbedingungen (zeitbasiert, ergebnisanzahlbasiert oder konvergenzbasiert)
• Nutzen Sie ein Blackboard mit versionierten Einträgen, um Zustandsänderungen zu verfolgen
• Fügen Sie einen Monitoring-Agent hinzu, der das Swarm-Verhalten beobachtet und eingreifen kann
• Setzen Sie Agent-Level-Budgets (maximale Schritte, maximale Tokens), um unkontrollierbare Ausführung zu verhindern — Kanban-Style-Dispatcher bieten praktische Ratenbegrenzungs- und Konkurrenzmuster für selbst gehostete Swarm-Deployments

Muster 6: Mesh

Wie es funktioniert

Mesh ist direkte Peer-to-Peer-Kommunikation mit persistenten Verbindungen — Agenten kommunizieren miteinander durch explizite, vordefinierte Kanäle, anstatt durch irgendeinen zentralen Hub. Der Kommunikationsgraph wird typischerweise zum Deployment-Zeitpunkt definiert, sodass Agent A weiß, dass er Agent B für Datenbankabfragen und Agent C für Authentifizierungslogik benötigt. Wenn diese Peers separate Dienste, Teams oder Anbieter überspannen, ändert sich die Transportebene; siehe Implementierung von Mustern, wenn Agenten Grenzen überschreiten unten.

Wann man es einsetzen sollte

• Kollaboratives Reasoning, bei dem Agenten Zwischenzustände teilen müssen
• Multi-Agent-Coding-Systeme (Planer ↔ Coder ↔ Tester-Loops)
• Iterative Artefaktverfeinerung, bei der mehrere Spezialisten beitragen
• Verhandlungsszenarien, in denen Agenten verschiedene Stakeholder repräsentieren

Vorteil: Ideal für iterative Verfeinerung. Agenten können partielle Ergebnisse hin und her reichen und aufeinander aufbauen, ohne einen zentralen Aggregator.

Wie es scheitert

Kombinatorische Explosion. Die Anzahl der Verbindungen skaliert als N(N-1)/2. Bei 3 Agenten sind das 3 Verbindungen. Bei 8 Agenten sind es 28. Am besten auf 3-8 eng gekoppelte Agenten begrenzt.

Zirkuläre Abhängigkeiten. Agent A ruft Agent B auf, der Agent C aufruft, der Agent A aufruft. Ohne Zykluserkennung können Mesh-Muster in Endlosschleifen geraten.

Debugging-Komplexität. Nicht-deterministisches Routing macht das Nachverfolgen von Ausfällen nahezu unmöglich. Wenn die Ausgabe falsch ist, müssen Sie rekonstruieren, welche Agenten miteinander kommuniziert haben und in welcher Reihenfolge.

Gegenmaßnahmen

• Definieren Sie den Kommunikationsgraphen zum Deployment-Zeitpunkt (nicht zur Laufzeit)
• Implementieren Sie Zykluserkennung mit maximalen Hop-Limits
• Nutzen Sie Message-Passing mit expliziter Bestätigung
• Fügen Sie einen Circuit Breaker hinzu, der Kommunikationsketten nach N Hops terminiert

Implementierung von Mustern, wenn Agenten Grenzen überschreiten

Die Wahl einer Orchestrierungstopologie und die Wahl, wie Agenten kommunizieren, sind separate Entscheidungen. Die sechs Muster oben beschreiben wie Arbeit fließt — wer an wen delegiert, ob Stufen parallel laufen, ob Peers direkt sprechen. Sie schreiben nicht vor, ob diese Agenten in einem Python-Prozess, einem Kubernetes-Cluster oder drei Vendor-SaaS-Produkten leben.

In-process Multi-Agent-Systeme — LangGraph-Graphen, CrewAI-Crews, AutoGen-Group-Chats in einem einzigen Repo — halten die Koordination innerhalb eines Runtimes. Message-Passing ist Funktionsaufrufe oder gemeinsamer Zustand. Sie erhalten schnelle Iteration, einfaches Debugging und keine Netzwerk-Grenze, die gesichert werden muss. Dies ist das richtige Standardverhalten, bis Sie einen konkreten Grund haben, Agenten in unabhängig deploybare Dienste aufzuteilen.

Sie benötigen ein Wire-Protocol an der Grenze, wenn Agenten von verschiedenen Teams besessen werden, auf verschiedenen Frameworks laufen oder ohne Neudeployment des Aufrufers discoverbar sein müssen. Hier wird A2A vs MCP: Brauchen KI-Agenten wirklich beide Protokolle? zum Entscheidungspunkt: standardisierte Discovery via Agent Cards, Task-Lebenszyklus und Artefakt-Austausch zwischen Diensten, die keinen gemeinsamen Speicher haben, plus ein Framework dafür, wann dieser Overhead im Vergleich zum Bleiben in-process mit nur MCP lohnenswert ist.

Abbildung von Mustern auf Deployment

Die Topologie, die Sie wählen, bleibt relevant, sobald Agenten separate Dienste sind. Nicht jedes Muster bildet sich sauber auf cross-boundary A2A ab; einige bleiben naturgemäß intern.

Orchestrator-Worker und Hierarchical sind die häufigsten cross-boundary Shapes in der Produktion: ein nutzerorientierter Orchestrierer entdeckt Spezialisten und verfolgt delegierte Tasks. Mesh wird zur natürlichen Passform, wenn kein einzelner Hub das Routing besitzen sollte — beispielsweise ein Coding-Agent, der direkt mit einem Test-Agent und einem Security-Review-Agent spricht, die von verschiedenen Teams besessen werden.

Mesh über Ownership-Grenzen hinweg

Wenn Mesh-Teilnehmer Ownership-Grenzen überspannen, werden in-process Graph-Kanten zu A2A-Task-Sends. Jeder Peer veröffentlicht eine Agent Card, die seine Skills, Auth-Anforderungen und Endpunkte beschreibt. Aufrüfer entdecken Fähigkeiten zur Laufzeit oder aus einem kuratierten Registry, anstatt URLs in der App-Konfiguration hardzucoden.

Zwei Deployment-Styles konkurrieren hier. Vordefinierter Graph zum Deploy-Zeitpunkt hält das Mesh vorhersehbar: Agent A ist konfiguriert, Agent B und C aufzurufen, und A2A handhabt das Wire-Format und den Task-Zustand. Runtime-Discovery lässt Orchestrierer Spezialisten aus einem Registry auswählen, wenn Skills oder Anbieter wechseln, auf Kosten von mehr beweglichen Teilen und strikterer Governance. Die meisten Teams beginnen mit einem vordefinierten Graphen und fügen Discovery hinzu, wenn der Agent-Katalog jenseits dessen wächst, was Konfigurationsdateien verwalten können.

A2A entfernt die Mesh-Ausfallmodi aus dem Abschnitt oben nicht. Kombinatorisches Verbindungswachstum, zirkuläre Handoffs und undurchsichtiges Debugging gelten weiterhin — sie geschehen nur über HTTP statt in-memory Queues. Halten Sie Zykluserkennung und maximale Hop-Limits im Orchestrierer oder Gateway. Lang laufende delegierte Arbeit sollte Task-IDs und async Follow-up verwenden, anstatt jeden Hop zu blockieren; A2A Streaming und Async Tasks für lang laufende Agent-Workflows behandelt SSE, Push-Webhooks und input_required-Pausen an dieser Grenze.

Identität, scoped Authorisierung und Audit-Trails werden obligatorisch, sobald Peers separate Dienste sind. A2A und MCP Agent Security: Identity, Delegation und Audit Trails behandelt Gateways, Delegation-Tokens und was bei jedem Hop geloggt werden sollte.

Ausfallmodi spezifisch für cross-boundary Agenten

Drei Probleme treten häufig auf, wenn Orchestrierungsmuster die Prozessgrenze verlassen:

Zirkuläre Delegation über Dienste hinweg. Agent A von Team 1 delegiert an Agent B von Team 2, der zurück an A oder an einen dritten Agenten delegiert, der schließlich A aufruft. Die Gegenmaßnahmen aus dem Mesh-Abschnitt — Hop-Limits, Zykluserkennung, Circuit Breakers — müssen am Gateway oder Orchestrierer durchgesetzt werden, nicht davon ausgegangen, dass sie durch strukturierte A2A-Nachrichten wegfallen.

Versteckte Kostenexplosion über Delegationsketten. Jeder A2A-Hop kann einen LLM, Tools und weitere Sub-Delegation aufrufen. Eine Topologie, die in-process günstig aussah, kann den Token-Aufwand multiplizieren, wenn jeder Spezialist ein abgerechneter API-Aufruf ist. Verfolgen Sie Kosten pro Task-ID und pro Hop; der Cost Control-Abschnitt oben gilt direkt für cross-boundary Ketten.

Unklare Ownership des finalen Answers. Wenn drei Agenten von zwei Anbietern Artefakte beisteuern, müssen Benutzer und Auditoren wissen, welcher Agent (und welches zugrunde liegende Modell und welche Tools) die Ausgabe produziert hat, die sie sehen. Propagieren Sie Parent-Task-IDs, loggen Sie Delegationsketten und behandeln Sie Artefakt-Provenienz als first-class Observability-Feld — nicht als nachträglichen Gedanken, wenn etwas schiefgeht.

Wohin es geht

Dieser Abschnitt überbrückt Orchestrierungstopologie und Protokollwahl. Für Tiefe in jeder Schicht:

• Was ist das A2A-Protokoll? Agent Cards und Tasks erklärt — Agent Cards, Task-Lebenszyklus, Nachrichten, Parts und Artefakte
• A2A vs MCP: Brauchen KI-Agenten wirklich beide Protokolle? — das A2A außen, MCP innen Deployment-Muster
• A2A Streaming und Async Tasks für lang laufende Agent-Workflows — SSE, Push, Polling und Human-in-the-Loop-Pausen über Service-Grenzen hinweg
• A2A und MCP Agent Security: Identity, Delegation und Audit Trails — Identität, Gateways, Delegations-Scope und Audit-Design

Das Entscheidungsframework

Beginnen Sie mit dem einfachsten Muster, das zu Ihrem Problem passt. Die meisten Teams over-architecten sich auf Multi-Agent-Topologien, lange bevor der Single-Agent-Ansatz wirklich erschöpft ist.

Schritt 1: Charakterisieren Sie Ihr Problem

Schritt 2: Schätzen Sie Ihre Constraints

Schritt 3: Starten Sie Single-Agent

Der kanonische Agent-Loop — ein einzelner Agent mit Tools, Reasoning und Iteration — ist immer noch das richtige Standardverhalten für general-purpose Agenten. AI Assistant Architecture behandelt den fünf-Schichten-Grundstein, auf dem Single-Agent-Systeme aufbauen, und es lohnt sich, diesen Grundstein zu meistern, bevor man Multi-Agent-Koordination hinzufügt. Beachten Sie, dass Multi-Agent-Systeme auch fundamental unterschiedlich von Multi-Model-Routing sind; für Letzteres siehe Multi-Model System Design, das sequentielle, parallele und Ensemble-Muster behandelt, die auf Modellselektion angewendet werden, nicht auf Agent-Koordination.

Escalieren Sie zu Multi-Agent nur, wenn Messung sagt, dass Sie müssen:

• Single-Agent-Kontextfenster ist unzureichend
• Task erfordert echte Parallelität (Wall-Clock-Zeit ist wichtig)
• Spezialisierung bietet messbare Qualitätsverbesserung
• Kosten des Single-Agent-Ansatzes überschreiten Multi-Agent-Overhead

Für Background- und proaktive Agent-Arbeit — Scheduling, queue-basierte Ausführung, durable Polling-Loops — siehe Polling Agents in AI Assistants: 11 Implementation Patterns, das Multi-Agent-Orchestrierungsmuster mit der Scheduling-Schicht darunter ergänzt.

Ausfallmodi: Die MAST-Taxonomie

Forschung von NeurIPS 2025 (MAST — Multi-Agent System Failure Taxonomy) analysierte 1.600+ Execution-Traces über sieben populäre Multi-Agent-Frameworks. Ausfälle verteilen sich über drei Wurzelkategorien:

1. Spezifikationsambiguität (33 % der Ausfälle)

Agenten missverstehen Rollen, duplizieren Arbeit oder überspringen Verifikation, weil ihre Anweisungen unzureichend spezifiziert sind.

Fix: Nutzen Sie Spezifikationsschemas. Definieren Sie explizite Rollbeschreibungen, Task-Grenzen und Ausgabeformate für jeden Agenten. Strukturierte Schemas (JSON, Pydantic-Modelle) schlagen natürliche Sprachanweisungen.

2. Koordinationszusammenbrüche (33 % der Ausfälle)

Agenten kommunizieren mit unstrukturierten Protokollen, was zu Nachrichtenverlust, Race Conditions und zirkulären Handoffs führt.

Fix: Implementieren Sie strukturierte Koordinationsprotokolle. Nutzen Sie typisiertes Message-Passing, Bestätigungsmechanismen und explizite Terminierungsbedingungen.

3. Verifikationslücken (33 % der Ausfälle)

Keine unabhängige Validierung von Agent-Ausgaben. Agenten vertrauen der Ausgabe anderer ohne Verifikation, was Fehlerfortpflanzung erlaubt.

Fix: Fügen Sie unabhängige Validierungsagenten hinzu. Nutzen Sie ein separates Modell oder einen Verifikationsschritt, um Ausgaben zu validieren, bevor sie akzeptiert werden. Dies ist das Maker-Checker-Muster.

Kostenkontrolle: Der versteckte Multiplikator

Multi-Agent-Systeme haben eine Kostenstruktur, die nicht-linear skaliert:

Kostenoptimierungsstrategien:

1. Nutzen Sie günstigere Modelle für Worker. Der Orchestrierer benötigt Reasoning-Fähigkeit; Worker können kleinere, schnellere Modelle nutzen.
2. Begrenzen Sie Execution-Budgets. Setzen Sie maximale Tokens, maximale Schritte und maximale Zeit pro Agent.
3. Implementieren Sie frühe Terminierung. Stoppen Sie Agenten, die eindeutig gescheitert oder erfolgreich waren.
4. Cachen Sie gemeinsamen Kontext. Nutzen Sie Prefix-Caching (vLLM, SGLang RadixAttention), um das Neucomputen gemeinsamer Systemprompts zu vermeiden.
5. Monitorieren Sie pro-Agent-Kosten. Verfolgen Sie Token-Verbrauch pro Agent, nicht nur Gesamtkosten. Identifizieren Sie die teuersten Agenten und optimieren Sie zuerst.

Für eine tiefere Behandlung von Token-Optimierungsstrategien — Prompt-Kompression, Caching, Batching und intelligente Modellselektion — siehe Reduce LLM Costs: Token Optimization Strategies. Die Techniken gelten gleichermaßen für einzelne Agent-Aufrufe innerhalb eines Multi-Agent-Systems.

Observability: In die Black Box sehen

Multi-Agent-Systeme scheitern auf Arten, die traditionelles Debugging unzureichend machen. Wenn mehrere Agenten koordinieren, pflanzen sich Probleme über Agent-Grenzen fort, Ausführungspfade werden unvorhersehbar, und die Identifizierung von Root Causes erfordert Sichtbarkeit in verteilte Workflows. Observability for LLM Systems behandelt den vollständigen Produktions-Observability-Stack — Metriken, verteiltes Tracing, Logs, SLOs und Tool-Vergleiche — auf den Multi-Agent-Systeme angewiesen sind. Für die Instrumentierung von vLLM- und llama.cpp-Inferenzendpunkten mit Prometheus und Grafana siehe Monitor LLM Inference in Production.

Wesentliche Observability-Komponenten

1. Verteiltes Tracing

Erfassen Sie den vollständigen Interaktionsgraphen über alle Agenten. Traditionelle Tools zeigen Ihnen, ob Komponenten laufen, aber Multi-Agent-Debugging erfordert das Verständnis, wie Komponenten interagieren und wo Koordination zusammenbricht.

Wichtige Spans zum Tracen:

• Orchestrierer-Zerlegungsschritt
• Ausführung jedes Workers
• Aggregationsschritt
• Cross-Agent-Kommunikation (Mesh/Swarm)

2. Blackboard-Replay

Für Swarm- und Mesh-Muster, halten Sie ein versioniertes Blackboard, das replayt werden kann. Dies erlaubt Ihnen, das emergente Verhalten, das zu einem Ausfall führte, zu rekonstruieren.

3. Kostenzuordnung

Verfolgen Sie Token-Verbrauch pro Agent, pro Schritt. Identifizieren Sie, welche Agenten überproportional Ressourcen verbrauchen.

4. Konvergenzmonitoring

Für Swarm- und Mesh-Muster, monitorieren Sie, ob das System konvergiert oder divergiert. Setzen Sie Alerts für:

• Agentenanzahl, die erwartete Grenzen überschreitet
• Iterationsanzahl, die Schwellen überschreitet
• Ausgabequalität, die sich im Laufe der Zeit verschlechtert

Framework-Support-Matrix

Zusammensetzen: Ein Produktionsbeispiel

Reale Systeme bilden sich selten sauber auf ein einzelnes Muster ab — die meisten Produktionsdeployments kombinieren zwei oder drei Ansätze, wobei jeder den Teil des Workflows handhabt, für den er am besten geeignet ist. Infrastruktur-Muster wie Go Microservices for AI/ML Orchestration beschreiben die Service-Level-Choreografie und Saga-Muster, die diesen hybriden Architekturen im großen Maßstab zugrunde liegen.

Betrachten Sie ein Kundensupport-System, das technische Anfragen bearbeitet:

1. Triage (Orchestrator-Worker): Eingehendes Ticket → Orchestrierer klassifiziert → routet an Spezialisten
2. Forschung (Fan-Out): Spezialist-Agent führt parallele Queries aus (Knowledge Base, Ticket-Historie, Produktdokumente)
3. Entwurf (Sequential): Forschung → Entwurfsantwort → Qualitätscheck
4. Escalation (Hierarchical): Wenn Qualitätscheck fehlschlägt, eskalieren an Senior-Agent → Human Review

Dieser hybride Ansatz nutzt vier Muster, weil kein einzelnes Muster den vollständigen Workflow optimal handhabt. Die zentrale Erkenntnis: Komponieren Sie Muster, zwingen Sie nicht ein Muster, alles zu tun.

Wichtige Erkenntnisse

1. Beginnen Sie einfach. Single-Agent mit Tools ist das Standardverhalten. Escalieren Sie zu Multi-Agent nur, wenn Messung es erfordert.
2. Passen Sie Muster an Problem an. Orchestrator-Worker für Zerlegung, Pipeline für feste Sequenzen, Fan-Out für Parallelität, Hierarchical für Skalierung, Swarm für Exploration, Mesh für Kollaboration.
3. Erwarten Sie Ausfallmodi. Jedes Muster hat spezifische Wege, wie es zusammenbricht. Gestalten Sie Gegenmaßnahmen, bevor Sie deployen.
4. Kosten skalieren nicht-linear. Multi-Agent-Systeme multiplizieren Token-Verbrauch. Budgetieren Sie für 2-5x die Kosten eines einzelnen Agents.
5. Observability ist nicht verhandelbar. Ohne verteiltes Tracing und Kostenzuordnung können Sie Multi-Agent-Systeme nicht debuggen oder optimieren.
6. Komponieren Sie Muster. Die meisten Produktionsysteme nutzen 2-3 kombinierte Muster. Zwingen Sie nicht ein einzelnes Muster, alles zu handhaben.

Die Multi-Agent-Landschaft reift schnell. Die Teams, die erfolgreich sind, sind jene, die die Tradeoffs verstehen, Muster bewusst wählen und Observability von Tag eins aufbauen.

Häufig gestellte Fragen

Was ist Multi-Agent-Orchestrierung? Multi-Agent-Orchestrierung ist das Koordinationsmodell, das regelt, wie mehrere KI-Agenten an einer Aufgabe zusammenarbeiten. Das Muster, das Sie wählen — Hub-and-Spoke, Pipeline, Fan-Out, Hierarchical, Swarm oder Mesh — bestimmt die Latenz, Fehlertoleranz, Skalierungsgrenze und Debugging-Komplexität Ihres Systems. Jedes Muster macht verschiedene Tradeoffs und bricht auf unterschiedliche Weise.

Welches Multi-Agent-Muster ist am besten für Produktions-KI-Systeme? Die meisten Produktionsysteme beginnen mit Orchestrator-Worker. Es bietet klare Accountability, debuggbaren Kontrollfluss und vorhersehbare Kosten. Escalieren Sie zu Hierarchical, wenn die Worker-Anzahl 5-8 überschreitet, und zu Fan-Out, wenn unabhängige parallele Tasks die Arbeitslast dominieren. Swarm und Mesh bleiben Nischenmuster, die für Explorations-Workflows bzw. enge Peer-Kollaboration reserviert sind.

Warum scheitern 40 % der Multi-Agent-Pilotprojekte? Die drei Wurzelfaktoren gemäß der MAST-Taxonomie von NeurIPS 2025 sind Spezifikationsambiguität (Agenten missverstehen Rollen oder überspringen Verifikationsschritte), Koordinationszusammenbrüche (unstrukturierte Messaging führt zu Nachrichtenverlust und zirkulären Handoffs) und Verifikationslücken (keine unabhängige Validierung von Agent-Ausgaben, was Fehlerfortpflanzung unchecked erlaubt). Jede Kategorie macht etwa ein Drittel aller Ausfälle über 1.600+ analysierte Execution-Traces aus.

Wie viel mehr kostet ein Multi-Agent-System als ein Single-Agent? Erwarten Sie das 2- bis 10-fache der Token-Kosten, abhängig vom Muster. Orchestrator-Worker ist am günstigsten mit 2-3x. Fan-Out und Swarm sind am teuersten mit 4-10x, da Agenten parallel laufen und jeder unabhängig ein volles Token-Budget verbraucht. Diese Multiplikatoren summieren sich im großen Maßstab — ein Workflow, der im Test 0,50 $ kostet, kann bei 100.000 Ausführungen 50.000 $ pro Monat erreichen.

Wie debuggt man ein Multi-Agent-System, wenn etwas schiefgeht? Beginnen Sie mit verteiltem Tracing — ein Trace pro Ausführung, mit Spans für jeden Agent-Aufruf, Tool-Aufruf und Aggregationsschritt. Für Swarm- und Mesh-Muster implementieren Sie Blackboard-Replay, sodass Sie das emergente Verhalten aus Logs rekonstruieren können. Pro-Agent-Kostenzuordnung hilft zu identifizieren, welche Agenten kaskadierende Ausfälle oder unkontrollierbare Ausgaben auslösen, bevor sie Produktionsmaßstab erreichen.

Wann benötigen Multi-Agent-Muster A2A statt in-process Orchestrierung? Bleiben Sie in-process, wenn alle Agenten einen Runtime, ein Repo und ein Team teilen. Fügen Sie A2A an der Grenze hinzu, wenn Spezialisten unabhängig deployed werden, von verschiedenen Teams oder Anbietern besessen sind oder via Agent Cards entdeckt werden müssen, ohne den Aufrufer neu zu deployen. Orchestrator-Worker und Mesh sind die häufigsten cross-boundary Shapes; siehe Implementing patterns when agents cross boundaries für die vollständige Mapping-Tabelle.