Hauptbereich
Agency
KI-Orchestrierung Workflow-Automatisierung

Fehlerbehandlung: Retry und Idempotenz

Martin Rau ·

Ein KI-Agent, der Tools aufruft, arbeitet über ein Netzwerk — und Netzwerke sind unzuverlässig. APIs antworten mit 429 oder 503, Verbindungen brechen ab, Modelle brauchen mal drei, mal dreißig Sekunden. Fehlerbehandlung fasst die Muster zusammen, mit denen ein Agent solche Störungen abfängt, statt bei der ersten Panne die ganze Aufgabe hinzuwerfen: Retries mit Backoff, Idempotenz, Timeouts und Kompensation.

Das klingt nach klassischem Backend-Handwerk, und genau das ist es auch. Der Unterschied bei KI-Agenten: Sie rufen Tools autonom und in Schleifen auf, oft ohne dass ein Mensch jeden einzelnen Schritt beobachtet. Ein Fehler, der bei einem Menschen sofort auffällt, kann bei einem Agenten unbemerkt zehnmal wiederholt werden — mit entsprechend vervielfachtem Schaden.

Warum naive Agenten in Produktion scheitern

Ein naiver Agent behandelt jeden Tool-Aufruf so, als würde er garantiert klappen. Schlägt er fehl, bricht der Agent entweder ganz ab oder ruft das Tool blind erneut auf — ohne zu wissen, ob der erste Versuch vielleicht doch durchgegangen ist. Analysen von LLM-API-Traffic zeigen, dass ein spürbarer Anteil aller Aufrufe mit einem Fehler endet, ein Großteil davon durch Rate-Limits. Produktive Agentensysteme scheitern schätzungsweise in zehn bis fünfzehn Prozent der Fälle an solchen vorübergehenden Störungen.

Ohne Gegenmaßnahmen kaskadieren diese kleinen Störungen zu handfesten Problemen: doppelt angelegte Tickets, doppelt verschickte E-Mails, doppelt gebuchte Bestellungen. Der Agent selbst hat oft keine Ahnung, dass er gerade zum zweiten Mal dieselbe Aktion auslöst — er sieht nur “Aufruf fehlgeschlagen, also nochmal versuchen”.

Retries mit Backoff

Ein Retry ist der einfachste Reflex: Schlägt ein Aufruf fehl, versuch es nochmal. Naiv umgesetzt — sofort und ohne Pause — verschärft das aber genau das Problem, das den Fehler verursacht hat. Bei einem Rate-Limit etwa feuert der Agent nur noch mehr Anfragen in kurzer Zeit ab und verschlimmert die Drosselung.

Der Standard dagegen ist exponentielles Backoff mit Jitter: Die Wartezeit zwischen den Versuchen verdoppelt sich nach jedem Fehlschlag, und ein zufälliger Streuwert verhindert, dass viele Agenten gleichzeitig im selben Rhythmus erneut anfragen. Eine gängige Formel dafür ist Basis-Wartezeit mal zwei hoch Versuchsnummer, plus Zufallswert. In der Praxis heißt das oft: erste Wartezeit ein bis zwei Sekunden, danach verdoppeln, nach fünf bis sieben Versuchen aufgeben und den Fehler nach oben melden.

Nicht jeder Fehler verdient einen Retry. Ein Timeout oder ein 503 ist meist vorübergehend — hier lohnt sich Wiederholen. Ein 400 wegen fehlerhafter Eingabe bleibt beim zweiten Versuch genauso fehlerhaft. Ein Agent sollte also nach Fehlertyp unterscheiden, statt jeden Fehlschlag gleich zu behandeln.

Idempotenz: die Voraussetzung für sicheres Retry

Idempotenz bedeutet: Eine Aktion mehrfach auszuführen hat denselben Effekt wie sie einmal auszuführen. Ein GET-Request ist naturgemäß idempotent — er verändert nichts. Ein “Erstelle Ticket” oder “Sende E-Mail” ist es von Natur aus nicht: Jeder Aufruf legt ein neues Ticket an oder verschickt eine neue Mail.

Das Standardmuster, um solche Aktionen retry-sicher zu machen, ist der Idempotenz-Schlüssel. Der Agent erzeugt vor dem ersten Versuch eine eindeutige ID für die Aktion und schickt sie bei jedem Aufruf mit. Die Gegenseite merkt sich, welche IDs sie schon verarbeitet hat — kommt dieselbe ID nochmal an, liefert sie einfach das gespeicherte Ergebnis zurück, statt die Aktion erneut auszuführen. Große Zahlungs-APIs wie Stripe machen das seit Jahren so vor, und das Muster hat sich als Standard für zustandsverändernde Agenten-Tools etabliert.

Wichtig dabei: Die ID muss vor dem Aufruf feststehen und bei jedem Retry dieselbe bleiben — nicht bei jedem Versuch neu erzeugt werden. Sonst verliert der Schlüssel seinen Zweck.

Timeouts richtig setzen

Ein fehlender Timeout ist genauso gefährlich wie ein fehlender Retry — nur andersherum. Ohne Zeitlimit wartet ein Agent im schlimmsten Fall unbegrenzt auf eine Antwort, die nie kommt, und blockiert damit die ganze Pipeline dahinter. Jeder Tool-Aufruf braucht also ein explizites Zeitlimit, nach dessen Ablauf der Agent den Versuch als gescheitert behandelt und in die Retry- oder Fehlerlogik übergeht.

Die Schwierigkeit liegt in der richtigen Dosis: Zu kurz, und der Agent bricht Aufrufe ab, die eigentlich noch durchgelaufen wären — das erzeugt unnötige Retries und im schlimmsten Fall unnötige Duplikate. Zu lang, und eine einzelne hängende Anfrage lähmt minutenlang den gesamten Ablauf. Als Ausgangspunkt hilft die tatsächliche Antwortzeit-Verteilung des jeweiligen Tools unter Last, nicht ein pauschaler Wert für alle Aufrufe.

Kompensation und Rollback

Retry und Timeout kümmern sich um einzelne Aufrufe. Doch was passiert, wenn ein mehrstufiger Ablauf mittendrin scheitert — wenn etwa Schritt drei von fünf fehlschlägt, nachdem die Schritte eins und zwei bereits echte Nebenwirkungen ausgelöst haben? Hier greift das Saga-Muster: Statt einer echten Transaktion über alle Schritte hinweg bekommt jeder Schritt eine passende Kompensationsaktion, die seine Wirkung rückgängig macht.

Scheitert Schritt drei, ruft der Agent die Kompensation für Schritt zwei auf, dann die für Schritt eins — in umgekehrter Reihenfolge, zuletzt begonnen, zuerst rückgängig gemacht. Eine reservierte Zahlung wird storniert, ein angelegter Datensatz wieder gelöscht, eine verschickte Benachrichtigung durch eine Korrektur ersetzt. Wichtig: Die Kompensation selbst muss denselben Zuverlässigkeitsmustern folgen wie die ursprüngliche Aktion — auch ein Rollback kann fehlschlagen und braucht eigene Retry-Logik.

So passt es zusammen

Diese vier Muster — Retry, Idempotenz, Timeout, Kompensation — sind kein Sonderfall für Ausnahmesituationen, sondern die Grundausstattung jedes produktiven Agenten-Workflows. Wie mehrere Agenten koordiniert zusammenarbeiten und wo Fehlerbehandlung in der Orchestrierungsschicht sitzt, steht unter Multi-Agent-Orchestrierung. Die API-seitige Praxis zu Rate-Limits und Retry-freundlichen Aufrufen zeigt Mit der LLM-API arbeiten. Und welche Frameworks dir Retry- und State-Management-Logik bereits mitbringen, findest du unter Agenten-Frameworks im Überblick.

FAQ

Was ist der Unterschied zwischen Retry und Idempotenz?
Retry ist die Handlung, einen fehlgeschlagenen Aufruf erneut zu versuchen. Idempotenz ist die Eigenschaft der Aktion dahinter, die dafür sorgt, dass mehrfaches Ausführen keinen zusätzlichen Schaden anrichtet. Retry ohne Idempotenz führt zu Duplikaten, Idempotenz ohne Retry bringt allein keine Zuverlässigkeit — beide gehören zusammen.
Wie funktioniert exponentielles Backoff genau?
Die Wartezeit zwischen Versuchen verdoppelt sich nach jedem Fehlschlag, plus ein zufälliger Streuwert (Jitter), damit nicht viele Agenten im selben Takt erneut anfragen. Üblich ist eine Startwartezeit von ein bis zwei Sekunden, Verdopplung pro Versuch und ein Abbruch nach fünf bis sieben Versuchen.
Sollte jeder Tool-Aufruf einen Idempotenz-Schlüssel bekommen?
Nur zustandsverändernde Aufrufe brauchen ihn zwingend — alles, was Daten anlegt, ändert oder eine Aktion in der echten Welt auslöst. Reine Lese-Operationen sind meist von Natur aus idempotent und brauchen keinen zusätzlichen Schlüssel.
Was ist der Unterschied zwischen Timeout und Retry?
Ein Timeout entscheidet, wann ein Aufruf als gescheitert gilt, weil er zu lange dauert. Retry entscheidet, was danach passiert — ob und wie oft erneut versucht wird. Ohne Timeout weiß der Agent nie, wann er überhaupt zum Retry übergehen soll.
Wann brauche ich Kompensationslogik statt einfachem Retry?
Sobald ein Ablauf aus mehreren Schritten mit echten Nebenwirkungen besteht und ein späterer Schritt scheitern kann, nachdem frühere bereits gewirkt haben. Ein einzelner, in sich abgeschlossener Aufruf braucht meist nur Retry und Idempotenz — ein mehrstufiger Workflow zusätzlich Kompensationspfade je Schritt.

Themenuebersicht

KI-OrchestrierungWorkflow-Automatisierung