Backoff und Jitter: Wiederholungen für Agenten begrenzen

Backoff und Jitter: Wie du Wiederholungen für Agenten begrenzt

Ein Socket-Timeout, ein HTTP 503, ein Rate Limit: Tool-Aufrufe scheitern im Normalbetrieb, ohne dass der Dienst dauerhaft kaputt sein muss. Einfach noch einmal zu versuchen liegt nahe, kann eine Störung aber verschärfen. Sehen viele Agenten denselben Fehler gleichzeitig, erzeugen ungeregelte Wiederholungen eine zweite Lastwelle, und zwar genau auf den Dienst, der gerade Luft braucht.

Wie lange ein Agent wartet, ist deshalb nachrangig. Vorher muss klar sein, ob er überhaupt noch einmal anfragen darf.

Erst klassifizieren, dann wiederholen

Für die Praxis reichen drei Klassen:

• Vorübergehend: Timeouts, Verbindungsabbrüche oder bestimmte Serverfehler können einen weiteren Versuch rechtfertigen.
• Gedrosselt: Bei Rate Limits braucht der Dienst Zeit, bevor neue Last sinnvoll ist.
• Dauerhaft: Validierungs-, Berechtigungs- oder Nicht-gefunden-Fehler werden durch Warten nicht besser.

Die AWS-Dokumentation zum Retry-Verhalten unterscheidet diese Fälle anhand konkreter Fehlercodes und HTTP-Statuswerte. Dabei zählt die Reihenfolge: Zuerst wird der konkrete Fehlercode ausgewertet, erst danach der HTTP-Status. Ein 5xx mit Throttling-Code gilt dort deshalb als Drosselung, nicht als vorübergehender Fehler.

Für den Betrieb heißt das: Jeder Retry braucht einen benannten Grund. Ein try/catch mit erneutem Aufruf ist keiner.

Die Formel hinter dem Warten

Exponentielles Backoff vergrößert die Pause nach jedem Fehlversuch, Full Jitter verteilt die tatsächliche Wartezeit zufällig innerhalb dieses Fensters:

delay = random(0, 1) × min(max_delay, base_delay × 2^retry)

Jitter ist kein Detail. Ohne den Zufallsanteil starten Clients, die gleichzeitig gescheitert sind, auch den nächsten Versuch nahezu gleichzeitig und erzeugen neue Spitzenlast, solange der Dienst noch unter Druck steht.

Die Parameter sind eine Betriebsentscheidung. AWS nennt für sein neues, derzeit noch per Opt-in aktiviertes Retry-Verhalten 50 Millisekunden Basisverzögerung bei vorübergehenden Fehlern, 1.000 Millisekunden bei Drosselung und eine Obergrenze von 20 Sekunden pro Pause. Wichtiger als jeder einzelne Wert ist, dass Wartezeit und Versuchszahl überhaupt hart begrenzt sind.

Ein Budget, das sich erschöpfen kann

Nach Angaben von AWS kombinieren die SDKs im Standardmodus die maximale Versuchszahl mit einem Retry-Budget. Wiederholungen verbrauchen Tokens aus einem Token-Bucket, erfolgreiche Aufrufe füllen ihn wieder auf. Ist das Budget leer, geht der Fehler direkt an den Aufrufer zurück, statt die Störung durch weitere Anfragen zu verlängern.

In Agentensystemen muss dieses Budget über alle Schichten gelten. Angenommen, das SDK versucht einen Request dreimal, der Tool-Wrapper wiederholt den gesamten Aufruf ebenfalls dreimal und der Agent-Loop setzt den Schritt danach bis zu dreimal neu an. Aus einer beabsichtigten Wiederholung werden so bis zu 27 Requests.

Verschachtelte Retry-Policies addieren sowohl Versuche als auch Verzögerungen. Die untere Ebene sollte deshalb ihren Fehlergrund sauber nach oben melden, statt unbemerkt eigene Wiederholungsschleifen aufzubauen. Ich würde das Budget am Agent-Loop festmachen und SDK sowie Wrapper bewusst knapp halten. Im Trace müssen dafür mindestens diese Felder sichtbar sein:

• aktuelle Schicht, etwa SDK, Tool-Wrapper oder Agent-Loop
• laufende und maximal erlaubte Versuchszahl
• klassifizierte Fehlerursache
• berechnete Wartezeit
• Entscheidung zur Idempotenz

Steigt der globale Versuchszähler stärker als erwartet, steckt meist eine versteckte Retry-Schicht darunter.

Warum Idempotenz die eigentliche Grenze ist

Ein wiederholbarer Fehler macht die Operation noch nicht sicher. Der Dienst kann eine Anfrage erfolgreich verarbeitet haben, obwohl die Antwort den Aufrufer nie erreicht. Schickt die Retry-Logik denselben Auftrag erneut, entstehen bei Schreiboperationen schnell doppelte Nebenwirkungen. Bei einer Kreditkartenbelastung ist das kein Schönheitsfehler.

Leseoperationen sind meist unkritisch. Für Schreibzugriffe braucht es eine belastbare Absicherung wie einen Idempotenzschlüssel, eine eindeutige Transaktions-ID, eine Vorbedingung für die Änderung oder eine vorherige Statusabfrage. Fehlt eine solche Absicherung, ist Abbrechen die bessere Entscheidung.

Mit mehreren parallel arbeitenden Agenten verschärft sich das. Retries treffen dann auf dieselben Konfliktrisiken von Agentenschwärmen: doppelte Tickets, mehrfach versandte Nachrichten, konkurrierende Änderungen.

Was Operatoren im Fehlerfall prüfen sollten

„Tool-Aufruf fehlgeschlagen“ reicht als Alarm nicht. Er sollte zeigen, ob der Ausgangsaufruf, eine Wiederholung oder das gesamte Budget gescheitert ist.

Für die Diagnose bietet sich dieser Ablauf an:

1. Fehlerklasse und betroffenen Dienst feststellen.
2. Versuchszähler über alle Schichten vergleichen.
3. Wartezeiten auf exponentielles Wachstum und Jitter prüfen.
4. Bei Schreiboperationen die Idempotenzabsicherung kontrollieren.
5. Bei anhaltender Überlastung Retries stoppen und auf Circuit Breaker, Queueing oder Kapazitätsmaßnahmen wechseln.

Frühe Fehlversuche können zunächst als Information protokolliert werden. Erst wenn der letzte erlaubte Versuch scheitert, sollte daraus ein Fehleralarm entstehen. Das hält Alarme ruhig, solange die vorgesehene Wiederholung greift. Ein ausgeschöpftes Budget oder eine unsichere Wiederholung gehört dagegen in den Fehlerstatus. Wer diese Verläufe systematisch auswertet, kann sie mit Agenten-Traces und Qualitätsbewertungen verbinden.

Fazit: die Mindestregel

Ein Tool-Call darf nur wiederholt werden, wenn drei Bedingungen erfüllt sind: Der Fehler ist klassifiziert, ein gemeinsames Budget begrenzt sämtliche Retry-Schichten, und die Operation ist idempotent oder technisch gegen doppelte Ausführung abgesichert.

Fehlt eine davon, bricht der Agent mit einer klaren Fehlermeldung ab. Das kostet gelegentlich einen Lauf, der beim zweiten Versuch funktioniert hätte. Dafür bleiben Nebenwirkungen, Last und Diagnose beherrschbar.