Muster zur Orchestrierung mehrerer Agenten: Ein praktischer Leitfaden

Einzelagenten-basierte KI-Systeme erreichten 2025 ihren Höhepunkt — man übertrug einem LLM einen Prompt, einige Tools und ein Ziel, und es erledigte abgegrenzte Aufgaben reasonably gut.

Im Jahr 2026 haben sich Multi-Agenten-Systeme von Forschungsdemos zu produktionsreifem Infrastruktur-Grundgerüst entwickelt. Gartner berichtet über einen Anstieg von 1.445 % bei Anfragen zu Multi-Agenten-Systemen von Q1 2024 bis Q2 2025, während der „2026 Connectivity Benchmark Report" von Salesforce ergab, dass Organisationen durchschnittlich 12 Agenten einsetzen — ein Wert, der innerhalb von zwei Jahren um 67 % steigen soll. Das [KI-Systeme-Cluster](https://www.glukhov.org/de/ai-systems/ „Eigen gehostete KI-Systeme mit OpenClaw, Hermes, RAG und lokaler LLM-Infrastruktur aufbauen.") deckt den gesamten Stack ab, auf dem diese Systeme arbeiten — von Inferenz und Speicher über Routing bis hin zur Observability.

Eine konkrete Produktionslast, die sich auf die hier beschriebenen Orchestrator-Worker- und hierarchischen Muster stützt, ist Deep Research: Ein Koordinator zerlegt eine Frage, und unabhängige Subagenten untersuchen Teile davon, bevor die Ergebnisse synthetisiert werden. [Eigen gehostete Deep-Research-Systeme: 12 Tools im Vergleich](https://www.glukhov.org/de/ai-systems/comparisons/deep-research-with-ai/ „12 eigen gehostete Deep-Research-Systeme im Vergleich: GPT Researcher, Onyx, Open WebUI, Khoj, Vane und mehr. Architekturen, lokale LLMs, RAG, Lizenzen.") geht auf DeerFlow, Open Deep Research und zehn weitere Systeme ein, die dieses Planner-Plus-Subagent-Modell (oder dessen rekursive und an Lücken im Beweismaterial orientierte Alternativen) speziell für die Recherche umsetzen.

Aber hier ist etwas, was weniger diskutiert wird: 40 % der Multi-Agenten-Pilotprojekte scheitern innerhalb von sechs Monaten nach der Produktivsetzung. Das Scheitern liegt nicht daran, dass Multi-Agenten-Systeme nicht funktionieren. Das Problem ist, 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 sich im Produktionsbetrieb bewähren, die spezifischen Arten, auf die jedes Muster fehlschlägt, sowie ein Entscheidungsframework zur Auswahl der richtigen Architektur.

Das Kernproblem: Koordination ist schwierig

Wenn man von einem einzelnen KI-Agenten zu mehreren zusammenarbeitenden Agenten übergeht, lautet die erste ingenieurtechnische Frage: Wie koordinieren sie sich?

Das Koordinationsmodell — das Orchestrierungsmuster — bestimmt die Latenz, Fehlertoleranz, Skalierungsgrenze und Fehlersuchkomplexität des Systems. Es ist durchweg die Architekturentscheidung mit der größten Wirkung im Multi-Agenten-Design und beeinflusst alle nachfolgenden Implementierungsentscheidungen.

Jedes produktionsreife Multi-Agenten-System lässt sich einem der sechs kanonischen Muster zuordnen oder ist ein Hybrid 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-Agenten-Koordination. Ein einzelner Orchestrierungs-Agent empfängt die Aufgabe, zerlegt sie in Teilaufgaben, delegiert jede Teilanfrage an einen spezialisierten Worker-Agenten und aggregiert die Ergebnisse. Die Worker kommunizieren nicht direkt miteinander — die gesamte Koordination fließt durch den Orchestrator, der den vollständigen Plan und die Entscheidungsbehörde hält.

Wann man es einsetzen sollte

• Querschnittsübergreifende Workflows mit klarer Aufgabenzerlegung
• Triage- und Routing-Szenarien (Kundenbetreuung, Vorfallklassifizierung)
• Arbeitslasten, bei denen ein einzelner Verantwortlichkeitspunkt erforderlich ist
• Aufgaben, bei denen der Orchestrator ein leistungsfähiges Modell verwenden kann, während die Worker günstigere, aufgabenspezifische Modelle nutzen

Praxisbeispiel: Salesforce Agentforce 2.0 nutzt Orchestrator-Worker, um Kundenanfragen in die Phasen Recherche, Entwurf und Überprüfung zu zerlegen.

Wie es fehlschlägt

Einzelpunktfehler. Der Orchestrator ist sowohl eine Engstelle als auch ein Fehlerpunkt. Wenn der LLM-Aufruf des Orchestrators 3 Sekunden dauert und 20 Worker auf Zuweisungen warten, liegt die maximale Durchsatzrate der Zerlegung bei etwa 6,7 Aufgaben pro Sekunde. Wenn der Orchestrator eine Aufgabe fehlklassifiziert, erhält der falsche Worker die Aufgabe — und Fehlklassifizierungsquoten verstärken sich bei großem Maßstab.

Kontextüberlauf. Der Orchestrator sammelt Kontext von allen Workern. Ab 4 Workern überschreitet der Orchestrator häufig die Kontextgrenzen, 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 Orchestrator führt mehrere LLM-Aufrufe für Zerlegung und Aggregation zusätzlich zu jedem Worker-Aufruf durch. Bei großem Maßstab dominiert der Overhead die Worker-Kosten.

Gegenmaßnahmen

• Definieren Sie explizite Schnittstellenverträge zwischen Orchestrator und Workern.
• Verlangen Sie strukturierte Ausgaben von Workern (JSON-Schemata, typisierte Antworten).
• Begrenzen Sie Teilanfrage-Budgets (Token-Limits, Schritt-Limits), um außer Kontrolle geratene Kosten zu verhindern.
• Erwägen Sie eine hierarchische Variante (siehe Muster 4), wenn die Worker-Anzahl 5 überschreitet.

Muster 2: Sequenzielle Pipeline

Wie es funktioniert

Die sequenzielle Pipeline ist die lineare Kette mit gemeinsamem Zustand — eine vordefinierte Abfolge von Agenten mit deterministischer Reihenfolge, bei der jede Stufe Daten transformiert oder anreichert und an die nächste weitergibt. Es gibt keine Verzweigung zur Laufzeit; die Ausführungsreihenfolge ist zur Designzeit festgelegt, was das Muster zwar hochgradig vorhersehbar, aber inflexibel macht.

Wann man es einsetzen sollte

• Dokumentverarbeitungs-Workflows (Import → Extraktion → Validierung → Ausgabe)
• Inhaltsgenerierungs-Pipelines (Recherche → Entwurf → Redaktion → Veröffentlichung)
• Compliance-Prüfung (Generierung → Check → Überarbeitung → Genehmigung)
• Datenanreicherung und ETL-Workflows

Praxisbeispiel: Der Microsoft Azure Rechtsanwaltsworkflow verwendet sequenzielle Pipelines für die Vertragsgenerierung: Entwurf → Überprüfung → Markierung von Änderungen → Finalversion.

Wie es fehlschlägt

Fehlerfortpflanzung. Schlechte Ausgabe in Stufe 1 kaskadiert ohne Rückverfolgung nach unten. Eine Halluzination in der Recherche-Stufe erzeugt einen fehlerhaften Entwurf, den der Redakteur zu einem selbstbewussten, aber falschen Endergebnis poliert.

Koordinations-Overhead. Eine 4-Agenten-Pipeline fügt etwa 950 ms Koordinations-Overhead hinzu, im Vergleich zu 500 ms Bearbeitungszeit. Sie zahlen das Dreifache für dasselbe Ergebnis, wenn Spezialisierung nicht erforderlich ist. Der Token-Verbrauch addiert sich: 29.000 Token in einer 4-Agenten-Pipeline gegenüber 10.000 für einen einzelnen Agenten, der dieselbe Arbeit verrichtet.

Keine bedingte Verzweigung. Die Pipeline kann sich nicht an Zwischenergebnisse anpassen. Wenn Stufe 2 feststellt, dass die Eingabe fehlerhaft ist, hat sie keinen Mechanismus, Stufe 1 zur Wiederholung aufzufordern — sie muss entweder fehlschlagen oder eine degradierte Ausgabe erzeugen.

Gegenmaßnahmen

• Fügen Sie Qualitätskontrollen zwischen den Stufen ein (leichtgewichtige Validierungsagenten, die die Ausgabe vor der Weitergabe nach unten prüfen).
• Fügen Sie Nachbearbeitungsschleifen für Stufen hinzu, die wiederholt werden können — robuste Workflow-Engines wie [Temporal](https://www.glukhov.org/de/app-architecture/integration-patterns/workflow-applications-temporal-in-go/ „Implementierung von Workflow-Anwendungen mit Temporal in Go") handhaben Wiederholungssemantiken zuverlässig.
• Begrenzen Sie Pipelines auf maximal 3–4 Stufen; darüber hinaus sollten Sie Orchestrator-Worker für bedingte Verzweigungen in Betracht ziehen.

Muster 3: Fan-Out / Fan-In

Wie es funktioniert

Fan-Out / Fan-In ist parallele Ausführung mit Aggregation. Ein Dispatcher verteilt die Arbeit auf mehrere parallel laufende Agenten, und ein Collector aggregiert anschließend ihre Ergebnisse durch Stimmabgabe, gewogenes Zusammenfügen oder LLM-Synthese. Die Agenten arbeiten während der gesamten Ausführung unabhängig und kommunizieren nicht miteinander — die einzige geteilte Grenze ist der Collector.

Wann man es einsetzen sollte

• Mehrperspektivische Analysen, bei denen diverse Ansichten wertvoll sind
• Parallel durchgeführte Code-Reviews (mehrere Reviewer parallel)
• 4 oder mehr unabhängige Aufgaben, die im Vorfeld zerlegt werden können
• Arbeitslasten, bei denen die Echtzeit (Wall-Clock-Time) wichtiger ist als die Token-Effizienz

Schlüsselmetrik: Fan-Out reduziert die Echtzeit um 75 % im Vergleich zur sequenziellen Ausführung. Vier parallel laufende Agenten sind in der Zeit eines einzelnen fertig.

Wie es fehlschlägt

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

Quadratische Wettlaufzustände. Konflikte um den gemeinsamen Zustand skalieren als N(N-1)/2. Bei 5 Agenten sind das 10 potenzielle Konflikte. Bei 10 Agenten sind es 45. Das Zustandsmanagement wird zur dominierenden Komplexität.

Aggregationshalluzination. LLM-Synthese kann Konsens erfinden. Wenn Agent A „Ja" sagt und Agent B „Nein", könnte der Aggregator „Vielleicht" erzeugen — einen halluzinierten Kompromiss, den kein Agent vorgeschlagen hat. Dies erfordert eine explizite Konfliktlösung, nicht nur eine Zusammenfassung.

Gegenmaßnahmen

• Verwenden Sie explizite Stimmmechanismen statt freier Synthese.
• Implementieren Sie Ratenbegrenzung auf Dispatcher-Ebene.
• Halten Sie getrennte Zustände pro Worker; fügen Sie sie beim Collector zusammen.
• Setzen Sie eine maximale Agentenanzahl (5–8), um Wettlaufzustände handhabbar zu halten.

Muster 4: Hierarchisch

Wie es funktioniert

Hierarchisch ist baumstrukturierte Delegation über mehrere Ebenen — ein Top-Level-Manager delegiert an Mittel-Level-Aufsichter, die ihrerseits an Leaf-Level-Worker delegieren. Jede Ebene fügt eine Abstraktionsebene hinzu: Strategie oben, Taktik in der Mitte und Ausführung an den Enden. 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 unternehmensweite Multi-Domain-Aufgaben, die 20+ Agenten erfordern
• Large-Scale-Codebase-Audits, bei denen verschiedene Module verschiedene Spezialisten benötigen
• Massive Dokumentverarbeitung (Tausende von Dokumenten über mehrere Kategorien hinweg)
• Aufgaben, bei denen das Kontextfenster eines einzelnen Agenten das volle Problem nicht fassen kann

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

Wie es fehlschlägt

Latenzakkumulation. Jede Ebene fügt Latenz hinzu. Eine 3-stufige Hierarchie erfordert mindestens 6–12 Sekunden Mindestzeit, die sich pro Ebene addieren. Der Top-Manager wartet auf alle Aufsichter, die auf alle Worker warten.

Informationsverlust. Zusammenfassungen zwischen den Ebenen sind verlustbehaftet. Ein Aufsichter fasst die Worker-Ausgabe für den Top-Manager zusammen und verliert dabei Details, die für die finale Entscheidung kritisch sein könnten.

Isolierung von Ast-Fehlern. Ein Fehler in einem Ast breitet sich nicht auf andere aus — was für die Fehlertoleranz gut, aber für die Konsistenz schlecht ist. Verschiedene Äste könnten zu widersprüchlichen Schlussfolgerungen kommen, die der Top-Manager nicht auflösen kann.

Gegenmaßnahmen

• Definieren Sie explizite Zusammenfassungsanforderungen für jede Ebene.
• Implementieren Sie Cross-Branche-Validierung auf der Top-Manager-Ebene.
• Halten Sie die Hierarchietiefe auf maximal 2–3 Ebenen.
• Verwenden Sie strukturierte Ausgaben auf jeder Ebene, um den Informationsverlust zu reduzieren.

Muster 5: Schwarm (Swarm)

Wie es funktioniert

Swarm ist dezentrale, emergente Koordination ohne zentrale Autorität. Autonome Agenten treffen lokale Entscheidungen auf Basis des gemeinsamen Zustands (eines Blackboards) oder Umgebungssignalen, ohne dass ein Orchestrator den Fluss steuert. Agenten entdecken verfügbare Aufgaben, beanspruchen sie und veröffentlichen die Ergebnisse zurück in den gemeinsamen Raum. Die Koordination ist emergent — das System organisiert sich selbst um verfügbare Arbeit, ähnlich wie Bienen zu einem neuen Bienenstock navigieren, ohne zentralen Koordinator.

Wann man es einsetzen sollte

• Recherche-Flows, bei denen der optimale Suchpfad unbekannt ist
• Wettbewerbsintelligenz über mehrere Quellen hinweg
• Large-Scale-Web-Scraping mit dynamischer Zielerkennung
• Parallele Hypothesenprüfung in wissenschaftlichen oder analytischen Bereichen

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

Wie es fehlschlägt

Fehlersuch-Albtraum. Ohne zentralen Kontrollfluss erfordern Fehlersuchen verteiltes Tracing und Blackboard-Playback. Man kann keinem einzelnen Ausführungspfad folgen — man muss das emergente Verhalten aus Logs rekonstruieren.

Keine transaktionalen Garantien. Swarm-Muster können strenge Reihenfolgen oder transaktionale Konsistenz nicht erzwingen. Wenn Sie benötigen, dass Agent A abgeschlossen ist, bevor Agent B beginnt, ist Swarm das falsche Muster.

Terminierungsbedingungen. Wie weiß der Schwarm, wann er aufhören soll? Ohne explizite Terminierungskriterien können Agenten unendlich weiterlaufen, Rechenleistung verbrauchen und abnehmende Erträge erzielen.

Gegenmaßnahmen

• Implementieren Sie explizite Terminierungsbedingungen (zeitbasiert, ergebniszahlbasiert oder konvergenzbasiert).
• Verwenden Sie ein Blackboard mit versionierten Einträgen, um Zustandsänderungen zu verfolgen.
• Fügen Sie einen Monitoring-Agenten hinzu, der das Schwarmverhalten beobachtet und eingreifen kann.
• Setzen Sie Agenten-Budgets (maximale Schritte, maximale Token), um außer Kontrolle geratene Auszuführen zu verhindern — [Kanban-artige Dispatcher](https://www.glukhov.org/de/ai-systems/hermes/kanban-in-hermes/ „Kanban im Hermes-Agent für selbst gehostete LLM-Workflows") bieten praktische Ratenlimits- und Parallelitätsmuster für selbst gehostete Swarm-Deploymentsszenarien.

Muster 6: Mesh

Wie es funktioniert

Mesh ist direkte Peer-to-Peer-Kommunikation mit persistenten Verbindungen — Agenten kommunizieren miteinander über explizite, vordefinierte Kanäle, statt über einen zentralen Hub. Der Kommunikationsgraph wird typischerweise zur Deployment-Zeit definiert, sodass Agent A weiß, dass er für Datenbankabfragen Agent B und für Authentifizierungslogik Agent C benötigt. Wenn diese Peers separate Dienste, Teams oder Vendor-Grenzen überspannen, ändert sich die Transportschicht; siehe unten Muster implementieren, wenn Agenten Grenzen überschreiten.

Wann man es einsetzen sollte

• Kollaboratives Reasoning, bei dem Agenten Zwischenzustände teilen müssen
• Multi-Agenten-Codierungssysteme (Planner ↔ Coder ↔ Tester-Schleifen)
• Iterative Artefaktverfeinerung, bei der mehrere Spezialisten beitragen
• Verhandlungsszenarien, bei denen Agenten verschiedene Stakeholder repräsentieren

Hauptvorteil: Ideal für iterative Verfeinerung. Agenten können Teilergebnisse hin und her schicken und auf der Arbeit des anderen aufbauen, ohne einen zentralen Aggregator.

Wie es fehlschlägt

Kombinatorische Explosion. Die Verbindungsanzahl skaliert als N(N-1)/2. Bei 3 Agenten sind das 3 Verbindungen. Bei 8 Agenten sind es 28. Am besten auf 3–8 stark gekoppelte Agenten begrenzen.

Zyklische 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.

Fehlersuchkomplexität. Nicht-deterministisches Routing macht das Verfolgen von Fehlern nahezu unmöglich. Wenn die Ausgabe falsch ist, muss man rekonstruieren, welche Agenten mit welchen kommuniziert haben, in welcher Reihenfolge.

Gegenmaßnahmen

• Definieren Sie den Kommunikationsgraphen zur Deployment-Zeit (nicht zur Laufzeit).
• Implementieren Sie Zykluserkennung mit maximalen Hop-Limits.
• Verwenden Sie Nachrichtenübergabe mit explizitem Acknowledgement.
• Fügen Sie einen [Circuit Breaker](https://www.glukhov.org/de/app-architecture/integration-patterns/circuit-breaker-pattern-in-go/ „Implementierung des Circuit-Breaker-Musters in Go mit gobreaker, Context-Timeouts, Retries, Fallbacks und produktionsreifer Konfiguration für Microservices.") hinzu, der Kommunikationsketten nach N Hops beendet.

Muster implementieren, wenn Agenten Grenzen überschreiten

Die Wahl der Orchestrierungs-Topologie und die Wahl, wie Agenten kommunizieren, sind separate Entscheidungen. Die oben genannten sechs Muster beschreiben wie die Arbeit fließt — wer an wen delegiert, ob Stufen parallel laufen, ob Peers direkt kommunizieren. Sie legen nicht fest, ob diese Agenten in einem einzigen Python-Prozess, einem Kubernetes-Cluster oder drei Vendor-SaaS-Produkten leben.

In-Process-Multi-Agenten-Systeme — LangGraph-Graphen, CrewAI-Crews, AutoGen-Gruppenschats in einem einzelnen Repository — halten die Koordination innerhalb einer einzigen Laufzeitumgebung. Der Nachrichtenaustausch erfolgt über Funktionsaufrufe oder gemeinsamen Zustand. Man erhält schnelle Iteration, einfache Fehlersuche und keine Netzwerkgrrenze, die abgesichert werden muss. Das ist die richtige Standardoption, bis es einen konkreten Grund gibt, Agenten in unabhängig deploybare Dienste aufzuteilen.

Man benötigt ein Wire-Protokoll an der Grenze, wenn Agenten von verschiedenen Teams besessen werden, auf verschiedenen Frameworks laufen oder ohne Neudeployment des Callers entdeckbar sein müssen. Dort wird [A2A vs MCP: Benötigen KI-Agenten wirklich beide Protokolle?](https://www.glukhov.org/de/ai-systems/mcp/a2a-vs-mcp-ai-agent-protocols/ „Praktischer Vergleich von A2A und MCP für KI-Agentensysteme.") zum Entscheidungspunkt: standardisierte Entdeckung über Agent Cards, Task-Lebenszyklus und Artefaktaustausch zwischen Diensten, die keinen Speicher teilen, plus ein Framework dafür, wann dieser Overhead sich lohnt im Vergleich zum Verbleiben in-process mit nur MCP.

Muster auf Deployment abbilden

Die gewählte Topologie spielt weiterhin eine Rolle, wenn Agenten separate Dienste sind. Nicht jedes Muster lässt sich sauber auf Cross-Boundary-A2A abbilden; manche bleiben naturgemäß intern.

Orchestrator-Worker und Hierarchisch sind die häufigsten Cross-Boundary-Formen in der Produktion: Ein benutzerseitiger Orchestrator entdeckt Spezialisten und verfolgt delegierte Aufgaben. Mesh wird zum natürlichen Fit, wenn kein einzelner Hub das Routing besitzen sollte — zum Beispiel 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-Graphkanten zu A2A-Task-Sends. Jeder Peer veröffentlicht eine [Agent Card](https://www.glukhov.org/de/ai-systems/architecture/a2a-protocol-explained/ „Praktischer Leitfaden zum A2A-Protokoll für KI-Agenten."), die seine Fähigkeiten, Authentifizierungsanforderungen und seinen Endpoint beschreibt. Caller entdecken Fähigkeiten zur Laufzeit oder aus einem kuratierten Registry, statt URLs in der App-Konfiguration hart zu codieren.

Zwei Deployment-Stile konkurrieren hier. Vordefinierter Graph zur Deployment-Zeit hält das Mesh vorhersehbar: Agent A ist konfiguriert, Agent B und C aufzurufen, und A2A handhabt das Wire-Format und den Task-Zustand. Entdeckung zur Laufzeit ermöglicht es Orchestratoren, Spezialisten aus einem Registry auszuwählen, wenn sich Fähigkeiten oder Vendor ändern, was jedoch mehr bewegliche Teile und strengere Governance kostet. Die meisten Teams beginnen mit einem vordefinierten Graphen und fügen Entdeckung hinzu, wenn das Agenten-Katalog größer wird, als Konfigurationsdateien es verwalten können.

A2A beseitigt die Mesh-Fehlerrisiken aus der obigen Sektion nicht. Kombinatorsches Verbindungs-Wachstum, zyklische Übergaben und undurchsichtige Fehlersuche gelten weiterhin — sie passieren nur über HTTP statt über in-memory-Warteschlangen. Behalten Sie Zykluserkennung und maximale Hop-Limits im Orchestrator oder Gateway. Lang laufende delegierte Arbeit sollte Task-IDs und asynchrone Nachverfolgung verwenden, statt jeden Hop zu blockieren; [A2A Streaming und Async Tasks für lang laufende Agenten-Workflows](https://www.glukhov.org/de/ai-systems/architecture/a2a-streaming-async-task-lifecycle/ „So gestalten Sie A2A-Protokoll-Streaming, asynchrone Tasks, Push-Benachrichtigungen und lang laufende Agenten-Workflows mit SSE, Polling, HITL-Zuständen und Produktions-Observability.") deckt SSE, Push-Webhooks und input_required-Pausen an dieser Grenze ab.

Identität, scoped Authorization und Audit-Trails werden obligatorisch, sobald Peers separate Dienste sind. [A2A und MCP Agent Security: Identität, Delegation und Audit-Trails](https://www.glukhov.org/de/llm-architecture/guardrails/a2a-mcp-agent-security/ „Sichern Sie A2A- und MCP-Agentensysteme mit Identität, Auth, Delegation Controls, Gateways, Registries, Audit-Trails und einer Produktions-Checkliste für Multi-Agenten-Deployment.") deckt Gateways, Delegation-Tokens und ab, was an jedem Hop protokolliert werden muss.

Fehlerrisiken spezifisch für Cross-Boundary-Agenten

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

Zyklische Delegation über Dienste hinweg. Agent A im Team eins delegiert an Agent B im Team zwei, der an A oder an einen dritten Agenten delegiert, der schließlich A aufruft. Die Gegenmaßnahmen aus der Mesh-Sektion — Hop-Limits, Zykluserkennung, [Circuit Breakers](https://www.glukhov.org/de/app-architecture/integration-patterns/circuit-breaker-pattern-in-go/ „Implementierung des Circuit-Breaker-Musters in Go mit gobreaker, Context-Timeouts, Retries, Fallbacks und produktionsreifer Konfiguration für Microservices.") — müssen am Gateway oder Orchestrator erzwungen werden, nicht ignoriert, nur weil A2A strukturierte Nachrichten bietet.

Versteckte Kostenexplosion über Delegationsketten. Jeder A2A-Hop kann einen LLM, Tools und weitere Sub-Delegationen aufrufen. Eine Topologie, die in-process günstig aussah, kann den Token-Verbrauch vervielfachen, wenn jeder Spezialist ein kostenpflichtiger API-Aufruf ist. Verfolgen Sie Kosten pro Task-ID und pro Hop; die Sektion Kostenkontrolle oben gilt direkt für Cross-Boundary-Ketten.

Unklare Ownership der finalen Antwort. Wenn drei Agenten bei zwei Vendor Artefakte beisteuern, müssen Benutzer und Auditor wissen, welcher Agent (und welches zugrunde liegende Modell und welche Tools) die Ausgabe erzeugt hat, die sie sehen. Propagieren Sie parent Task-IDs, protokollieren Sie Delegationsketten und behandeln Sie Artefakt-Herkunft als erstklassiges Observability-Feld — nicht als nachträgliche Überlegung, wenn etwas schiefgeht.

Wo es hingeht

Diese Sektion verbindet Orchestrierungs-Topologie und Protokollwahl. Für Tiefe auf jeder Schicht:

• [Was ist das A2A-Protokoll? Agent Cards und Tasks erklärt](https://www.glukhov.org/de/ai-systems/architecture/a2a-protocol-explained/ „Praktischer Leitfaden zum A2A-Protokoll für KI-Agenten.") — Agent Cards, Task-Lebenszyklus, Nachrichten, Teile und Artefakte
• [A2A vs MCP: Benötigen KI-Agenten wirklich beide Protokolle?](https://www.glukhov.org/de/ai-systems/mcp/a2a-vs-mcp-ai-agent-protocols/ „Praktischer Vergleich von A2A und MCP für KI-Agentensysteme.") — das A2A-außen, MCP-innen Deployment-Muster
• [A2A Streaming und Async Tasks für lang laufende Agenten-Workflows](https://www.glukhov.org/de/ai-systems/architecture/a2a-streaming-async-task-lifecycle/ „So gestalten Sie A2A-Protokoll-Streaming, asynchrone Tasks, Push-Benachrichtigungen und lang laufende Agenten-Workflows.") — SSE, Push, Polling und Human-in-the-Loop-Pausen über Dienstegrenzen hinweg
• [A2A und MCP Agent Security: Identität, Delegation und Audit-Trails](https://www.glukhov.org/de/llm-architecture/guardrails/a2a-mcp-agent-security/ „Sichern Sie A2A- und MCP-Agentensysteme mit Identität, Auth, Delegation Controls, Gateways, Registries, Audit-Trails und einer Produktions-Checkliste für Multi-Agenten-Deployment.") — Identität, Gateways, Delegation-Scope und Audit-Design

Der Entscheidungsrahmen

Beginnen Sie mit dem einfachsten Muster, das zu Ihrem Problem passt. Die meisten Teams over-architecten zu Multi-Agenten-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: Beginnen Sie Single-Agent

Der kanonische Agenten-Loop — ein einzelner Agent mit Tools, Reasoning und Iteration — ist immer noch die richtige Standardoption für General Purpose Agenten. [KI-Assistent-Architektur](https://www.glukhov.org/de/ai-systems/architecture/ai-assistant-architecture/ „KI-Assistent-Architektur: LLM, Speicher, Tools, Routing, Observability") deckt das fünfschichtige Fundament ab, auf dem Single-Agenten-Systeme aufbauen, und es lohnt sich, dieses Fundament zu meistern, bevor man Multi-Agenten-Koordination einbaut. Beachten Sie, dass Multi-Agenten-Systeme sich auch fundamental von Multi-Model-Routing unterscheiden; für Letzteres siehe [Multi-Model-Systemdesign](https://www.glukhov.org/de/llm-architecture/model-routing/multi-model-system-design/ „Multi-Model-Systemdesign: Wann ein Modell nicht ausreicht"), das sequenzielle, parallele und Ensemble-Muster behandelt, angewandt auf Modellauswahl statt Agenten-Koordination.

Eskalieren Sie zu Multi-Agenten nur, wenn die Messung sagt, dass Sie müssen:

• Das Single-Agent-Kontextfenster ist unzureichend
• Die Aufgabe erfordert echte Parallelität (Echtzeit ist wichtig)
• Spezialisierung bietet messbare Qualitätsverbesserung
• Die Kosten des Single-Agent-Ansatzes übersteigen den Multi-Agenten-Overhead

Eine leichtgewichtige Version dieser Eskalation ist bereits in individuellen Coding-Tools enthalten: [Claude Code Subagenten](https://www.glukhov.org/de/ai-devtools/claude-code/claude-code-subagents/ „Wie Claude Code Subagenten funktionieren: isolierter Kontext, Model-Routing, .claude/agents Setup, der Explore-Plan-Execute-Workflow und zu vermeidende Fehler.") delegieren isolierte, kontextintensive Aufgaben an einen scope-limitierten Subagenten innerhalb eines Tools, ohne den Cross-Process-Koordinationskosten der oben genannten Muster — es lohnt sich, das auszureizen, bevor man zu einem vollständigen Orchestrierungsframework greift.

Für Hintergrund- und proaktive Agentenarbeit — Planung, queue-basierte Ausführung, robuste Polling-Schleifen — siehe [Polling Agenten in KI-Assistenten: 11 Implementierungsmuster](https://www.glukhov.org/de/ai-systems/architecture/polling-agents-ai-assistants-implementation-patterns/ „Polling Agenten in KI-Assistenten: 11 Implementierungsmuster"), das Multi-Agenten-Orchestrierungsmuster mit der darunterliegenden Planungsschicht ergänzt.

Fehlerrisiken: Die MAST-Taxonomie

Forschung von NeurIPS 2025 (MAST — Multi-Agent System Failure Taxonomy) analysierte über 1.600 Ausführungsspuren über sieben beliebte Multi-Agenten-Frameworks. Fehler verteilen sich auf drei Wurzelkategorien:

1. Spezifikationsambiguität (33 % der Fehler)

Agenten missverstehen Rollen, duplizieren Arbeit oder überspringen Validierung, weil ihre Anweisungen unterbestimmt sind.

Lösung: Verwenden Sie Spezifikationsschemata. Definieren Sie explizite Rollendeskriptionen, Aufgabenbereiche und Ausgabeformate für jeden Agenten. Strukturierte Schemata (JSON, Pydantic-Modelle) schlagen Natural-Language-Anweisungen.

2. Koordinationszusammenbrüche (33 % der Fehler)

Agenten kommunizieren über unstrukturierte Protokolle, was zu Nachrichtenverlust, Wettlaufzuständen und zyklischen Übergaben führt.

Lösung: Implementieren Sie strukturierte Koordinationsprotokolle. Verwenden Sie typisierten Nachrichtenaustausch, Acknowledgement-Mechanismen und explizite Terminierungsbedingungen.

3. Validierungslücken (33 % der Fehler)

Keine unabhängige Validierung der Agenten-Ausgaben. Agenten vertrauen der Ausgabe der anderen ohne Überprüfung, was es Fehlern erlaubt, sich zu verbreiten.

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

Kostenkontrolle: Der versteckte Multiplikator

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

Kostenoptimierungsstrategien:

1. Verwenden Sie günstigere Modelle für Worker. Der Orchestrator benötigt Reasoning-Fähigkeit; Worker können kleinere, schnellere Modelle nutzen.
2. Begrenzen Sie Ausführungsbudgets. Setzen Sie maximale Token, maximale Schritte und maximale Zeit pro Agenten.
3. Implementieren Sie frühe Terminierung. Stoppen Sie Agenten, die offensichtlich gescheitert oder erfolgreich waren.
4. Cachen Sie gemeinsamen Kontext. Verwenden Sie Prefix Caching (vLLM, SGLang RadixAttention), um das Neu-Berechnen gemeinsamer System-Prompts zu vermeiden.
5. Überwachen Sie Kosten pro Agenten. Verfolgen Sie den Token-Verbrauch pro Agenten, nicht nur die Gesamtkosten. Identifizieren Sie die teuersten Agenten und optimieren Sie diese zuerst.

Für eine vertiefte Behandlung von Token-Optimierungsstrategien — Prompt-Kompression, Caching, Batching und smarte Modellauswahl — siehe [LLM-Kosten senken: Token-Optimierungsstrategien](https://www.glukhov.org/de/llm-performance/cost-effective-llm-applications/ „LLM-Kosten senken: Token-Optimierungsstrategien"). Die Techniken gelten gleichermaßen für individuelle Agenten-Aufrufe innerhalb eines Multi-Agenten-Systems.

Observability: Den Blick in den Black Box

Multi-Agenten-Systeme schlagen auf Arten fehl, die traditionelles Debugging unzureichend machen. Wenn mehrere Agenten koordinieren, breiten sich Probleme über Agentengrenzen aus, Ausführungspfade werden unvorhersehbar, und die Identifizierung von Ursachen erfordert Sichtbarkeit in verteilte Workflows. [Observability für LLM-Systeme](https://www.glukhov.org/de/observability/observability-for-llm-systems/ „Observability für LLM-Systeme: Metriken, Traces, Logs und Testing in der Produktion") deckt den vollständigen Produktions-Observability-Stack ab — Metriken, verteiltes Tracing, Logs, SLOs und Tool-Vergleiche — auf den sich Multi-Agenten-Systeme verlassen. Für die Instrumentierung von vLLM- und llama.cpp-Inferenz-Endpoints mit Prometheus und Grafana, siehe [LLM-Inferenz in der Produktion überwachen](https://www.glukhov.org/de/observability/monitoring-llm-inference-prometheus-grafana/ „LLM-Inferenz in der Produktion überwachen (2026): Prometheus und Grafana für vLLM, TGI, llama.cpp").

Wesentliche Observability-Komponenten

1. Verteiltes Tracing

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

Wichtige Spans zu tracen:

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

2. Blackboard-Playback

Für Swarm- und Mesh-Muster, unterhalten Sie ein versioniertes Blackboard, das zurückgespielt werden kann. Dies ermöglicht es Ihnen, das emergente Verhalten, das zu einem Fehler führte, zu rekonstruieren.

3. Kostenzuordnung

Verfolgen Sie den Token-Verbrauch pro Agenten, pro Schritt. Identifizieren Sie, welche Agenten überproportionale Ressourcen verbrauchen.

4. Konvergenzmonitoring

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

• Agentenanzahl, die erwartete Grenzen überschreitet
• Iterationsanzahl, die Schwellenwerte überschreitet
• Ausgabegüte, die sich mit der Zeit verschlechtert

Framework-Support-Matrix

Zusammenführung: Ein Produktionsbeispiel

Echte Systeme lassen sich selten sauber einem einzelnen Muster zuordnen — die meisten Produktions-Deployment kombinieren zwei oder drei Ansätze, die jeweils den Teil des Workflows behandeln, für den sie am besten geeignet sind. Infrastruktur-Muster wie [Go Microservices für AI/ML Orchestrierung](https://www.glukhov.org/de/app-architecture/integration-patterns/go-microservices-for-ai-ml-orchestration-patterns/ „Go Microservices für AI/ML Orchestrierung") beschreiben die diensteseitige Choreographie und Saga-Muster, die diese Hybrid-Architekturen in großem Maßstab stützen.

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

1. Triage (Orchestrator-Worker): Eingehender Ticket → Orchestrator klassifiziert → routet an Spezialisten
2. Recherche (Fan-Out): Spezialisten-Agent führt parallele Abfragen durch (Wissensbasis, Ticket-Historie, Produktdoku)
3. Entwurf (Sequenziell): Recherche → Antwortentwurf → Qualitätscheck
4. Eskalation (Hierarchisch): Wenn Qualitätscheck fehlschlägt, Eskalation an Senior Agent → menschliche Überprüfung

Dieser Hybrid-Ansatz verwendet vier Muster, weil kein einzelnes Muster den vollständigen Workflow optimal behandelt. Der Schlüsselinsight: Muster komponieren, nicht ein Muster zwingen, alles zu tun.

Kernpunkte

1. Einfach anfangen. Single-Agent mit Tools ist der Standard. Eskalieren Sie zu Multi-Agenten nur, wenn Messungen es verlangen.
2. Muster zum Problem passen. Orchestrator-Worker für Zerlegung, Pipeline für feste Sequenzen, Fan-Out für Parallelität, Hierarchisch für Skalierung, Swarm für Exploration, Mesh für Kollaboration.
3. Fehlerrisiken erwarten. Jedes Muster hat spezifische Arten, wie es zusammenbricht. Designen Sie Gegenmaßnahmen, bevor Sie deployen.
4. Kosten skalieren nicht linear. Multi-Agenten-Systeme multiplizieren den Token-Verbrauch. Planen Sie 2-5x die Kosten eines Single Agents ein.
5. Observability ist unverhandelbar. Ohne verteiltes Tracing und Kostenzuordnung können Sie Multi-Agenten-Systeme nicht debuggen oder optimieren.
6. Muster komponieren. Die meisten Produktionssysteme verwenden 2-3 kombinierte Muster. Zwingen Sie kein einzelnes Muster, alles zu behandeln.

Die Multi-Agenten-Landschaft reift schnell. Die Teams, die erfolgreich sind, sind diejenigen, die die Tradeoffs verstehen, Muster absichtlich wählen und Observability ab Tag eins aufbauen.

Häufig gestellte Fragen

Was ist Multi-Agenten-Orchestrierung? Multi-Agenten-Orchestrierung ist das Koordinationsmodell, das regelt, wie mehrere KI-Agenten zusammen an einer Aufgabe arbeiten. Das gewählte Muster — Hub-and-Spoke, Pipeline, Fan-Out, Hierarchisch, Swarm oder Mesh — bestimmt die Latenz, Fehlertoleranz, Skalierungsgrenze und Fehlersuchkomplexität des Systems. Jedes Muster trifft andere Tradeoffs und bricht auf unterschiedliche Arten zusammen.

Welches Multi-Agenten-Muster ist am besten für KI-Systeme in der Produktion? Die meisten Produktionssysteme beginnen mit Orchestrator-Worker. Es bietet klare Verantwortung, debuggbaren Kontrollfluss und vorhersehbare Kosten. Eskalieren Sie zu Hierarchisch, wenn die Worker-Anzahl 5-8 überschreitet, und zu Fan-Out, wenn unabhängige parallele Aufgaben die Last dominieren. Swarm und Mesh bleiben Nischen-Muster, die für Explorations-Workflows und enge Peer-Kollaboration reserviert sind.

Warum scheitern 40 % der Multi-Agenten-Pilotprojekte? Die drei Wurzelursachen laut der MAST-Taxonomie von NeurIPS 2025 sind Spezifikationsambiguität (Agenten missverstehen Rollen oder überspringen Validierungsschritte), Koordinationszusammenbrüche (unstrukturierter Messaging führt zu Nachrichtenverlust und zyklischen Übergaben) und Validierungslücken (keine unabhängige Validierung der Agenten-Ausgaben, was es Fehlern erlaubt, ungeprüft zu propagieren). Jede Kategorie macht etwa ein Drittel aller Fehler über 1.600+ analysierte Ausführungsspuren aus.

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

Wie debuggt man ein Multi-Agenten-System, wenn etwas schiefgeht? Beginnen Sie mit verteiltem Tracing — eine Spur pro Ausführung, mit Spans für jeden Agenten-Aufruf, Tool-Aufruf und Aggregationsschritt. Für Swarm- und Mesh-Muster, implementieren Sie Blackboard-Playback, damit Sie das emergente Verhalten aus Logs rekonstruieren können. Kostenzuordnung pro Agenten hilft, welche Agenten kaskadierende Fehler oder außer Kontrolle geratene Ausgaben auslösen, zu identifizieren, bevor sie Produktionsmaßstab erreichen.

Wann benötigen Multi-Agenten-Muster A2A statt in-process Orchestrierung? Bleiben Sie in-process, wenn alle Agenten eine Laufzeit, ein Repository und ein Team teilen. Fügen Sie A2A an der Grenze hinzu, wenn Spezialisten unabhängig deployt werden, von verschiedenen Teams oder Vendor besessen werden oder über Agent Cards entdeckt werden müssen, ohne den Caller neu zu deployen. Orchestrator-Worker und Mesh sind die häufigsten Cross-Boundary-Formen; siehe Muster implementieren, wenn Agenten Grenzen überschreiten für die vollständige Abbildungstabelle.