Fehlerszenarien von Multi-Agent-Systemen vermeiden
Die Fehlerszenarien, die Multi-Agent-Systeme im Produktivbetrieb scheitern lassen — kaskadierende Fehler, Deadlocks, Kostenexplosion — und die Architekturmuster dagegen.
Multi-Agent-KI hat 2026 den Sprung von Konferenzfolien zu Produktions-Roadmaps geschafft. Mit der allgemeinen Verfügbarkeit von Microsoft Agent Framework 1.0, dem A2A-Protokoll zur Standardisierung der Agent-zu-Agent-Kommunikation und über 160.000 Organisationen, die bereits mehr als 400.000 individuelle Agenten auf Copilot Studio betreiben, lautet die Frage nicht mehr, ob Sie ein Multi-Agent-System bauen können. Sie lautet, ob Ihres den Kontakt mit echten Nutzern, echten Daten und echter Last übersteht.
Meist tut es das nicht — zumindest nicht im ersten Anlauf. Genau die Muster, die eine Multi-Agent-Demo auf der Bühne glänzen lassen, machen sie im Produktivbetrieb fragil. Dieser Beitrag ist ein praxisnaher Katalog der Fehlerszenarien, die uns immer wieder begegnen, und der Architekturentscheidungen, die sie eindämmen.
TL;DR / Kernaussagen
- Zuverlässigkeit arbeitet gegen Sie. Fünf Agenten mit je 95 % Einzelzuverlässigkeit liefern rund 77 % Gesamterfolg. Mehr Agenten bedeuten mehr probabilistische Übergaben, nicht mehr Robustheit.
- Die gefährlichen Fehler sind still. Multi-Agent-Systeme werfen selten saubere Exceptions — sie liefern selbstsichere, plausible Antworten auf Basis einer kaputten Teilaufgabe. Standard-Monitoring übersieht das vollständig.
- Jede Grenze zwischen Agenten ist eine Vertrauensgrenze. Validieren Sie strukturierte Ausgaben, ergänzen Sie Kritiker-Schritte für kritische Übergaben und lassen Sie Agenten laut scheitern statt zu raten.
- Kosten- und Schleifen-Explosion ist ein erstrangiges Risiko. Agenten in unbegrenzten Zyklen können ein Monatsbudget an Tokens in Minuten verbrennen, ohne eine Antwort zu liefern.
- Beginnen Sie mit einem Agenten. Zerlegen Sie erst dann in mehrere, wenn klar trennbare Fähigkeiten die zusätzlichen Koordinationskosten wirklich rechtfertigen.
Warum Multi-Agent-Systeme anders scheitern
Ein klassisches verteiltes System scheitert auf Weisen, die wir seit zwei Jahrzehnten zu beherrschen gelernt haben: Timeouts, Retries, Idempotenz, Circuit Breaker. Das gilt weiterhin. Doch ein Multi-Agent-System legt ein zweites, schwierigeres Problem darüber — die Ausgaben sind probabilistische natürliche Sprache, keine deterministischen Datenstrukturen.
Wenn ein Zahlungs-Microservice ausfällt, erhalten Sie einen HTTP-500 und einen Stacktrace. Wenn ein Agent ausfällt, erhalten Sie oft eine wunderbar formatierte, selbstsichere und völlig falsche Antwort, die der nächste Agent pflichtbewusst als Tatsache akzeptiert. Der Fehler kündigt sich nicht an. Er pflanzt sich fort.
Das ist der zentrale Denkwechsel. In einem Multi-Agent-System sind die teuersten Fehler keine Abstürze — es sind erfolgreiche Ausführungen des Falschen. Ihr Reliability-Engineering muss auf Korrektheit zielen, nicht nur auf Verfügbarkeit.
Die sechs entscheidenden Fehlerszenarien
In unserer Projektarbeit beim Aufbau agentenbasierter Systeme auf Azure wiederholen sich dieselben Fehlerszenarien über sehr unterschiedliche Domänen hinweg. Hier der Katalog, jeweils mit dem Signal, das ihn verrät.
| Fehlerszenario | Erscheinungsbild | Ursache | Primäre Abwehr |
|---|---|---|---|
| Kaskadierende Fehler | Eine falsche Ausgabe verfälscht alle nachgelagerten Agenten | Keine Validierung an Übergabegrenzen | Schema-Validierung + Kritiker-/Prüfer-Schritte |
| Koordinations-Deadlock | Agenten warten unbegrenzt aufeinander | Zirkuläre Abhängigkeiten, kein Timeout-Budget | Orchestrierungstopologie + harte Timeouts |
| Kontext-Drift | Das gemeinsame Ziel degeneriert über Übergaben | Verlustbehaftete Kontextweitergabe, Prompt-Verwässerung | Strukturierter gemeinsamer State, kein Freitext |
| Kosten-/Schleifen-Explosion | Token-Verbrauch explodiert, keine Antwort | Unbegrenzte Agent-zu-Agent-Zyklen | Schrittlimits, Budget-Caps, Loop-Erkennung |
| Stiller Teilausfall | Plausible Antwort auf fehlgeschlagener Teilaufgabe | Keine durchgängige Evaluation | Evaluations-Gates + Tracing |
| Tool-/Datenkorruption | Agent handelt auf veralteter oder falscher Tool-Ausgabe | Nicht vertrauenswürdige Tool-Grenzen | MCP mit Validierung, Least-Privilege-Tools |
1. Kaskadierende Fehler
Das häufigste und schädlichste Szenario. Agent A erzeugt eine subtil falsche Ausgabe — ein falsch gelesenes Datum, eine halluzinierte Entität, ein invertierter Boolean. Agent B behandelt sie als Tatsache und baut darauf auf. Wenn Agent E die Endantwort erzeugt, ist der Fehler eingebrannt und unsichtbar.
Die Abwehr besteht darin, jede Grenze zwischen Agenten als Vertrauensgrenze zu behandeln — genau wie zwischen Microservices in einer Zero-Trust-Architektur. Validieren Sie strukturierte Ausgaben gegen ein Schema, bevor sie weitergegeben werden. Fügen Sie bei kritischen Übergaben einen Kritiker- oder Prüfer-Agenten ein, dessen einzige Aufgabe es ist, die vorherige Ausgabe gegen das ursprüngliche Ziel zu prüfen. Lassen Sie Agenten bei fehlerhaften Eingaben laut scheitern — mit explizitem Fehler — statt zu raten.
2. Koordinations-Deadlock
Wenn Agenten sich frei gegenseitig aufrufen können, entstehen irgendwann Zyklen: A wartet auf B, B auf C, C auf A. Oder zwei Agenten verweisen einander höflich. Das System hängt, verbrennt Compute und läuft schließlich in einen Timeout — sofern Sie diszipliniert genug waren, einen zu setzen.
Die Lösung ist architektonisch, nicht taktisch. Wählen Sie eine explizite Orchestrierungstopologie — ein Supervisor-/Orchestrator-Muster, eine sequenzielle Pipeline oder einen begrenzten Graphen — statt eines freien Mesh, in dem jeder Agent jeden anderen rufen kann. Die Muster auf Protokollebene behandeln wir in unserem Beitrag zu A2A-Protokollmustern. Jede Wartephase braucht ein hartes Timeout-Budget.
3. Kontext-Drift
Jede Übergabe ist ein Kompressionsschritt. Agent A fasst für Agent B zusammen, der für C erneut zusammenfasst. Die ursprüngliche Absicht erodiert, bis der letzte Agent ein subtil anderes Problem löst, als der Nutzer gestellt hat. Das ist das Multi-Agent-Äquivalent der stillen Post.
Geben Sie strukturierten gemeinsamen State weiter, keinen paraphrasierten Freitext. Ein kanonisches Aufgabenobjekt — Ziel, Randbedingungen, gesammelte Fakten, offene Fragen — aus dem jeder Agent liest und in das er schreibt, hält das Ziel stabil. Vermeiden Sie es, das Ziel bei jedem Schritt neu zusammenzufassen.
4. Kosten- und Schleifen-Explosion
Dieses Szenario produziert die wütende Mail aus dem Controlling. Zwei Agenten, die in einer Verfeinerungsschleife festhängen und sich gegenseitig zur "Verbesserung" einer Ausgabe auffordern, können in Minuten tausende LLM-Aufrufe absetzen. Ohne Leitplanken kann ein einziger fehlerhafter Request einen erheblichen Teil eines Monats-Token-Budgets aufzehren.
Die Abwehr ist nicht verhandelbar und einfach: ein globales Schrittlimit pro Aufgabe, ein Token-/Kostenbudget pro Workflow mit hartem Abbruch und eine Loop-Erkennung, die anhält, wenn sich derselbe Agenten-State wiederholt. Die Kostensteuerung von Azure AI Foundry und das Tracing des Frameworks machen diese Limits durchsetzbar und beobachtbar.
5. Stiller Teilausfall
Das System liefert eine Antwort. Sie sieht richtig aus. Doch eine Teilaufgabe ist still gescheitert — ein Retrieval lieferte nichts, ein Tool-Aufruf schlug fehl und der Agent improvisierte — und die Endausgabe steht auf Sand. Weil es keine Exception gibt, bleiben Ihre Dashboards grün.
Die einzige echte Abwehr ist Evaluation. Bewerten Sie Ausgaben gegen erwartetes Verhalten, nicht nur gegen Erfolgscodes. Führen Sie kontinuierliche Evaluation gegen ein kuratiertes Testset durch und sichern Sie produktive Übergaben mit Konfidenz- und Groundedness-Prüfungen ab. Hier greift der Pilot-zu-Produktion-Wandel von 2026 am härtesten: Demos überspringen Evaluation, der Produktivbetrieb kann es nicht.
6. Tool- und Datenkorruption
Agenten sind nur so vertrauenswürdig wie die Tools und Daten, die sie konsumieren. Ein Tool, das veraltete, fehlerhafte oder durch Angreifer beeinflusste Daten zurückgibt, macht aus einem wohlerzogenen Agenten einen selbstsicheren Verbreiter falscher Informationen. Das ist zugleich eine Sicherheitsfläche — Prompt Injection über Tool-Ausgaben ist ein realer Angriffspfad.
Standardisieren Sie den Tool-Zugriff über das Model Context Protocol mit Validierung an der Grenze und wenden Sie Least-Privilege-Scoping an, damit ein Agent nur das berühren kann, was seine Aufgabe erfordert. Wir gehen in unserem Leitfaden zum MCP-Server-Design für Unternehmen tiefer darauf ein.
Zuverlässigkeit by Design: eine Checkliste
Diese Fehlerszenarien einzudämmen ist eine Architekturdisziplin, kein Feature, das man später anschraubt. Hier die Reihenfolge, die wir in Projekten anwenden.
- Jeden Agenten rechtfertigen. Beginnen Sie mit einem Agenten. Fügen Sie einen zweiten erst hinzu, wenn eine klar trennbare Fähigkeit oder eine echte Parallelitätsanforderung es verlangt. Jeder Agent ist ein Zuverlässigkeitsrisiko.
- Eine explizite Topologie wählen. Supervisor, Pipeline oder begrenzter Graph — niemals ein offenes Mesh. Dokumentieren Sie, wer wen aufrufen darf.
- Jede Grenze zur Vertrauensgrenze machen. Strukturierte Ausgaben gegen ein Schema validieren. Fehlerhafte Eingaben ablehnen, nicht erzwingen.
- Durchgängiges Tracing instrumentieren. Jeden Prompt, Tool-Aufruf und jede Inter-Agent-Nachricht via OpenTelemetry erfassen. Sie können nicht debuggen, was Sie nicht sehen.
- Harte Budgets setzen. Schrittlimits, Token-/Kosten-Caps und Timeouts auf jede Wartephase und jede Schleife.
- Evaluations-Gates einbauen. Kontinuierliche Evaluation gegen ein kuratiertes Set; Groundedness- und Konfidenzprüfungen vor kritischen Übergaben.
- Graceful Degradation einplanen. Definieren Sie, wie eine Teilantwort aussieht, und machen Sie Unsicherheit gegenüber dem Nutzer sichtbar, statt Vollständigkeit zu fingieren.
Die gute Nachricht ist, dass das Tooling von 2026 dies endlich unterstützt. Die erste Welle von Eigenbau-Agenten-Frameworks zwang Teams, Kommunikation, State und Observability selbst zu stricken — und die letzten beiden still zu überspringen. Microsoft Agent Framework 1.0 liefert A2A, MCP und OpenTelemetry-Tracing als erstklassige Primitive, und Azure AI Foundry stellt die Deployment-, Evaluations- und Kostensteuerungsebene darum bereit. Die internen Mechanismen des Frameworks erläutern wir in Microsoft Agent Framework 1.0 Architektur.
Die Zuverlässigkeitsmathematik, die niemand auf die Folie schreibt
Es lohnt sich, die Potenzierung explizit zu machen, denn sie verschiebt die gesamte Designdiskussion. Gelingt jeder Agent in einer Kette unabhängig mit Wahrscheinlichkeit p, beträgt der Gesamterfolg einer Kette aus n Agenten näherungsweise pⁿ.
| Zuverlässigkeit pro Agent | 3 Agenten | 5 Agenten | 8 Agenten |
|---|---|---|---|
| 90 % | 73 % | 59 % | 43 % |
| 95 % | 86 % | 77 % | 66 % |
| 99 % | 97 % | 95 % | 92 % |
Die Lehre ist unmissverständlich: Halten Sie die Kette entweder kurz, oder machen Sie jeden Agenten außergewöhnlich zuverlässig — was praktisch Validierung, Evaluation und Retries an jeder Grenze bedeutet. Ein ausufernder Zehn-Agenten-"Schwarm" ohne Grenzkontrollen ist mathematisch zum Enttäuschen verurteilt, egal wie beeindruckend die einzelnen Agenten sind.
Vom Piloten zum Produktivbetrieb
Der prägende Wandel von 2026 ist der Übergang von Agenten-Piloten zu Produktionssystemen — und es sind genau die obigen Fehlerszenarien, die beide trennen. Ein Pilot beweist den Happy Path. Der Produktivbetrieb übersteht die unglücklichen Pfade: die fehlerhafte Eingabe, den Tool-Ausfall, den adversen Prompt, die Kostenspitze um 3 Uhr nachts.
In unserer eigenen Projektarbeit — dem Aufbau und Härten agentenbasierter Plattformen auf Azure für europäische Unternehmen — ist die Zuverlässigkeitsarbeit durchweg umfangreicher als das "einmal zum Laufen bringen". Das ist kein Versagen der Technologie; es ist die Natur probabilistischer Systeme, die unter realer Last und realer regulatorischer Prüfung im Maßstab arbeiten.
FAQ
Was sind die häufigsten Fehlerszenarien in Multi-Agent-Systemen?
Wiederkehrend im Produktivbetrieb sind: kaskadierende Fehler (eine falsche Ausgabe eines Agenten verfälscht alle nachgelagerten Agenten), Koordinations-Deadlocks (Agenten warten unbegrenzt aufeinander), Kontext-Drift (das gemeinsame Aufgabenziel degeneriert über Übergaben hinweg), Kosten- und Schleifen-Explosion (Agenten rufen sich in unbegrenzten Zyklen auf) sowie stille Teilausfälle (das System liefert eine plausible Antwort auf Basis einer fehlgeschlagenen Teilaufgabe). Keines dieser Szenarien tritt in Einzelagenten-Demos auf — deshalb überraschen sie Teams im Produktivbetrieb.
Wie unterscheidet sich das Debugging eines Multi-Agent-Systems von einem normalen Microservice?
Ein Microservice hat deterministische Ein- und Ausgaben, ein fehlgeschlagener Request erzeugt einen klaren Fehler. In einem Multi-Agent-System sind die Ausgaben probabilistische natürliche Sprache, ein Fehler erscheint daher oft als selbstsichere, aber falsche Antwort statt als Exception. Sie brauchen durchgängiges Distributed Tracing, das jeden Prompt, Tool-Aufruf und jede Inter-Agent-Nachricht erfasst, sowie Evaluations-Gates, die Ausgaben gegen erwartetes Verhalten bewerten — nicht nur HTTP-Statuscodes.
Machen mehr Agenten ein System zuverlässiger oder unzuverlässiger?
Standardmäßig unzuverlässiger. Jede Agentenübergabe ist ein probabilistischer Schritt, und Zuverlässigkeit potenziert sich multiplikativ — fünf Agenten mit je 95 Prozent Zuverlässigkeit ergeben rund 77 Prozent Gesamterfolg. Mehr Agenten bedeutet mehr Übergaben, mehr Stellen für Kontext-Drift und mehr Angriffsfläche für kaskadierende Fehler. Fügen Sie Agenten nur hinzu, wenn eine Aufgabe wirklich spezialisierte, trennbare Fähigkeiten erfordert, und gestalten Sie explizite Validierung dazwischen.
Wie stoppt man kaskadierende Fehler zwischen Agenten?
Behandeln Sie jede Grenze zwischen Agenten als Vertrauensgrenze. Validieren Sie strukturierte Ausgaben gegen ein Schema, bevor sie weitergegeben werden, ergänzen Sie einen Kritiker- oder Prüfer-Schritt für kritische Übergaben und lassen Sie Agenten bei fehlerhaften Eingaben laut scheitern statt zu raten. Circuit Breaker und Konfidenzschwellen verhindern, dass ein degradierter Agent den restlichen Workflow vergiftet.
Was bietet das Microsoft Agent Framework für Zuverlässigkeit?
Microsoft Agent Framework 1.0, allgemein verfügbar seit dem 3. April 2026, liefert Produktionsprimitive, die den frühen Eigenbau-Frameworks fehlten: standardisierte Agent-zu-Agent-Kommunikation über das A2A-Protokoll, Tool- und Datenzugriff über das Model Context Protocol sowie erstklassige Observability via OpenTelemetry-Tracing. Zusammen mit Azure AI Foundry für Deployment, Evaluation und Kostensteuerung erhalten Sie die Bausteine, um Fehlerszenarien einzudämmen, statt sie im Produktivbetrieb zu entdecken.
Ist ein einzelner, gut entworfener Agent manchmal besser als ein Multi-Agent-System?
Häufig ja. Ein einzelner Agent mit guten Tools, Retrieval und einem präzisen Prompt vermeidet die gesamte Klasse der Koordinations- und Kaskadenfehler. Wir empfehlen regelmäßig, mit einem Agenten zu beginnen und erst dann in mehrere Agenten zu zerlegen, wenn es einen konkreten Grund gibt — unterschiedliche Fachkompetenzen, Parallelität oder organisatorische Zuständigkeitsgrenzen. Multi-Agent ist eine Architekturentscheidung mit realen Zuverlässigkeitskosten, kein Standard.
Wenn Sie einen Agenten-Piloten in den Produktivbetrieb überführen und Zuverlässigkeit, Observability und Kostensteuerung von Anfang an richtig entworfen haben möchten, unterstützt Sie unsere Praxis für KI- und Daten-Plattform-Engineering. Wir entwerfen agentenbasierte Systeme, die reale Last überstehen — nicht nur die Demo.
Themen