Wie unterscheidet sich dies vom einfachen Hinzufügen von try/except und einer Wiederholungsschleife?

Try/except behandelt einen einzelnen Fehler; eine Recovery-Strategie entscheidet, um welche Art von Fehler es sich handelt, und wählt unter harten Budgets zwischen Wiederholungsversuch, Fallback, Rollback und Eskalation. Der Kern liegt in der Kontrolllogik und der Idempotenz, nicht in der Ausnahmebehandlung.

Wie viele Wiederholungsversuche sollte ich zulassen?

Wenige – typischerweise eine niedrige, feste Obergrenze mit exponentiellem Backoff und Jitter, plus separate Zeit- und Kostenobergrenzen. Die genaue Anzahl hängt von der Abhängigkeit ab, aber die Schleife muss immer enden, und dauerhafte Fehler sollten überhaupt nicht wiederholt werden.

Was passiert, wenn eine Aktion nicht rückgängig gemacht oder idempotent gestaltet werden kann?

Führen Sie darüber hinweg keine automatischen Wiederholungsversuche aus. Setzen Sie vor dem unumkehrbaren Schritt einen Checkpoint und eskalieren Sie bei einem Fehler an einen Menschen oder einen überwachenden Agenten, anstatt Vermutungen anzustellen. Unumkehrbarkeit ist ein Signal, langsamer vorzugehen, nicht, es noch intensiver zu versuchen.

ZuverlässigkeitAktualisiert 2026-08-25 · Version 1.1

Recovery-Strategie

Geben Sie dem Agenten einen expliziten Plan für den Fall, dass Fehler auftreten. Erkennen Sie Fehler, indem Sie Ausgaben validieren und Tool-Fehler abfangen; führen Sie dann einen erneuten Versuch mit Anpassungen durch, weichen Sie auf einen alternativen Pfad aus, machen Sie Teilaktionen rückgängig oder eskalieren Sie. Begrenzen Sie die Anzahl der Versuche, um unkontrollierte Schleifen und Kosten zu vermeiden, machen Sie Aktionen idempotent und unterscheiden Sie zwischen vorübergehenden und dauerhaften Fehlern. Das Ziel ist ein kontrollierter Funktionsabbau (Graceful Degradation) anstelle von Abstürzen oder unbemerkt fehlerhaften Ergebnissen.

Evidenz: ProduktionKonfidenz: NiedrigQuelle: ProduktionssystemQuelle: Persönliche ErfahrungQuelle: Branchenbeobachtung

Maschinenlesbar: JSON

Problem

Agenten fallen ständig aus: Tools laufen in Timeouts, APIs geben Fehler zurück, Modelle liefern fehlerhafte Ausgaben, Pläne geraten in Sackgassen und mehrstufige Workflows hinterlassen unvollständige Nebeneffekte. Ohne einen expliziten Recovery-Pfad stürzt ein Agent entweder beim ersten Fehler ab oder – was noch schlimmer ist – arbeitet mit fehlerhaften Daten weiter und liefert unbemerkt, aber mit scheinbarer Gewissheit falsche Ergebnisse. Naive Wiederholungsschleifen verschlimmern das Problem, indem sie eine fehlerhafte Abhängigkeit überlasten, Token verbrauchen und endlos laufen. Die Schwierigkeit liegt nicht darin, einen einzelnen Fehler abzufangen, sondern zu entscheiden, um welche Art von Fehler es sich handelt und welche Reaktion sicher ist.

Wann zu verwenden

Verwenden Sie dieses Pattern bei jedem Agenten, der externe Tools aufruft, mehrstufige Pläne ausführt oder folgenschwere Aktionen durchführt, bei denen ein unvollständiger Abschluss möglich ist. Es ist besonders wichtig für langlebige oder autonome Workflows, die von keinem Menschen in Echtzeit überwacht werden, sowie für Aktionen mit Nebeneffekten (Zahlungen, Schreibvorgänge, E-Mails), bei denen ein blinder Wiederholungsversuch zu doppelter Arbeit führen könnte. Es setzt voraus, dass Sie Ausgaben anhand eines Kontrakts validieren können und dass zumindest einige Operationen idempotent gestaltet oder kompensiert werden können. Für einmalige, schreibgeschützte Prompts mit geringem Risiko ist es weniger relevant.

Lösung

Behandeln Sie Recovery als erstklassigen Kontrollkreis (Control Loop), der um die normale Ausführung des Agenten gelegt wird. Jeder Tool-Aufruf und jede Modellausgabe durchläuft ein Validierungs-Gate: Fangen Sie Exceptions und Timeouts ab und prüfen Sie Ausgaben anhand eines Schemas oder Kontrakts, bevor Sie ihnen vertrauen. Klassifizieren Sie den Fehler im Fall eines Fehlschlags. Vorübergehende Fehler (Timeouts, Ratenbegrenzungen, 5xx) erhalten eine begrenzte Anzahl von Wiederholungsversuchen mit exponentiellem Backoff und Jitter, idealerweise bezogen auf eine idempotente Operation, sodass eine doppelte Anfrage harmlos ist. Dauerhafte Fehler (ungültige Argumente, Authentifizierungsfehler, Kontraktverletzungen) überspringen Wiederholungsversuche und führen direkt zu einer Alternative: einem anderen Tool, einem einfacheren Plan oder einer Fallback-Antwort. Wenn der Fortschritt entscheidend ist, speichern Sie den Zustand über Checkpoints, damit der Agent beim letzten erfolgreichen Schritt fortfahren kann, anstatt neu zu starten. Wenn ein Schritt bereits Nebeneffekte erzeugt hat und nicht fortgesetzt werden kann, führen Sie kompensierende Aktionen aus, um den Zustand zurückzusetzen – stornieren Sie die Bestellung, löschen Sie den Entwurf, buchen Sie die Gebühr zurück. Schließen Sie die gesamte Schleife in harte Budgets ein: maximale Versuche, maximale Echtzeit (Wall-Clock Time) und eine Kostenobergrenze, ergänzt durch einen Circuit Breaker, der Aufrufe an eine dauerhaft fehlerhafte Abhängigkeit stoppt. Wenn alle Recovery-Optionen ausgeschöpft sind, eskalieren Sie sauber – leiten Sie den Fehler an einen Menschen oder einen überwachenden Agenten mit ausreichend Kontext weiter, anstatt Vermutungen anzustellen.

Komponenten

Validierungs-GateFehler-KlassifiziererBegrenzter Wiederholungsversuch mit BackoffFallback-RouterCheckpoint-SpeicherKompensations-Handler

Vorteile

Der Agent liefert ein unvollständiges Ergebnis oder ein Fallback-Ergebnis sowie einen klaren Status, anstatt abzustürzen oder mit scheinbarer Gewissheit unbrauchbare Daten zurückzugeben.
Harte Limits für Versuche, Zeit und Kosten verhindern, dass unkontrollierte Wiederholungsschleifen Budget für eine fehlerhafte Abhängigkeit verbrauchen.
Kompensierende Aktionen und Checkpoints halten externe Systeme und den Aufgabenstatus konsistent, wenn ein Workflow mittendrin abbricht.
Wenn die Recovery fehlschlägt, übergibt der Agent die Aufgabe mit ausreichend Kontext, damit ein Mensch oder ein Supervisor handeln kann, anstatt Vermutungen anzustellen.

Risiken

Aggressive Wiederholungsversuche bei einer überlasteten Abhängigkeit erhöhen die Last und können eine kurze Störung in einen kaskadierenden Ausfall verwandeln.
Der Wiederholungsversuch einer nicht-idempotenten Aktion kann zu doppelten Abbuchungen, doppeltem Senden oder doppelten Schreibvorgängen führen, wenn keine Request-Keys verwendet werden.
Zu voreilige Fallbacks können systematische Fehler verbergen, sodass ein defektes Tool fehlerfrei erscheint, während es im Hintergrund jedes Ergebnis verschlechtert.
Rollback-Logik ist oft unvollständig oder schlägt selbst fehl, was Systeme in einem inkonsistenten Zustand hinterlässt, der schwer zu erkennen ist.

Wann nicht zu verwenden

Bei risikoarmen Prompts ohne Nebeneffekte und ohne mehrstufigen Plan reicht ein einfaches Wiederholen-oder-Abbrechen aus; eine vollständige Recovery-Infrastruktur bedeutet hier nur unnötigen Overhead.
Wenn ein Fehler bedeutet, dass die Aufgabe tatsächlich unmöglich ist (fehlende Berechtigung, veraltete API), verschwenden Wiederholungsversuche und Fallbacks nur Zeit – brechen Sie schnell ab (Fail-Fast) und eskalieren Sie.
Wenn ein Nebeneffekt unumkehrbar ist und nicht idempotent gemacht werden kann, führen Sie keine automatischen Wiederholungsversuche durch; fordern Sie stattdessen eine Bestätigung oder eine menschliche Freigabe an.

Technologien

Retries with backoffCircuit breakersCheckpointingCompensating actions

Beispiele

Das Such-Tool eines Recherche-Agenten gibt einen 503-Fehler zurück; der Agent versucht es mit Backoff erneut, ist beim dritten Versuch erfolgreich und fährt fort, ohne den Durchlauf abzubrechen.
Ein Code-Agent generiert JSON, das die Schema-Validierung nicht besteht; das Validierungs-Gate lehnt es ab und fordert das Modell unter Angabe des Fehlers erneut auf (Re-Prompt), anstatt fehlerhafte Daten an nachgelagerte Systeme weiterzugeben.
Ein Buchungs-Agent reserviert einen Flug, aber der Schritt für das Hotel schlägt dauerhaft fehl; der Kompensations-Handler storniert die Reservierung und eskaliert, anstatt eine halb gebuchte Reise zu hinterlassen.

Praxisbelege

Kontext: Lokale OpenClaw-Bereitstellung (Single-Operator), beobachtet über 57 Tage (161 Sitzungen / 2.776 Turns), aggregiert aus den eigenen Trajektorien-Traces des Agenten.
Szenario: Fehler, Abbrüche und Timeouts während autonomer Turns werden durch Retry/Backoff und eine Modell-Fallback-Kette abgefangen, sodass der Agent weiterläuft.
Technologie: retryAsync mit exponentiellem Backoff und Jitter, runWithModelFallback, Abort-Propagierung und Cron-Selbstschutz gegen wiederholte Auslöseschleifen.
Last: 2.942 Terminal-Turns; 52 Fehler, 126 Abbrüche, 120 Timeouts und 31 Prompt-Fehler beobachtet.
Ergebnisse: Eine Terminal-Fehlerrate von 1,77 % bei 2.942 Turns; Recovery-Primitive fingen vorübergehende Fehler ab und die Bereitstellung hielt eine Sitzungserfolgsquote von 98,8 %. Lokale Bereitstellung (Single-Operator).

KPIs

Recovery-Erfolgsquote: Anteil der Fehler, die automatisch durch Wiederholungsversuche oder Fallbacks ohne menschliche Hilfe behoben wurden; ein gesunder Wert ist hoch und stabil, ohne unbemerkt abfallenden Trend.
Mittlere Anzahl der Versuche pro erfolgreicher Aufgabe: Wie viele Versuche für einen Erfolg nötig sind; achten Sie auf einen schleichenden Anstieg, der eher auf eine sich verschlechternde Abhängigkeit als auf eine echte Recovery hindeutet.
Quote unbegrenzter Schleifen / Budgetüberschreitungen: Wie oft Durchläufe an Wiederholungs-, Zeit- oder Kostenobergrenzen stoßen; dies sollte selten vorkommen, und Spitzen deuten darauf hin, dass Limits oder die Klassifizierung angepasst werden müssen.
Vollständigkeit der Kompensation: Anteil fehlgeschlagener mehrstufiger Workflows, die in einem konsistenten Zustand enden; das Ziel ist ein vollständiges Rollback ohne verwaiste Nebeneffekte.

Beobachtete Fehlermuster

Fehlende oder zu hohe Obergrenzen für Versuche führen dazu, dass der Agent einen dauerhaften Fehler endlos wiederholt, was Kosten verursacht und keinen Fortschritt bringt.
Die Behandlung eines dauerhaften Fehlers als vorübergehend verschwendet Wiederholungsversuche; die Behandlung eines vorübergehenden Fehlers als dauerhaft führt zu einem zu frühen Aufgeben und löst unnötige Fallbacks aus.
Ein Fallback-Pfad gibt eine plausible, aber falsche Antwort zurück, ohne zu signalisieren, dass eine Recovery stattgefunden hat, sodass nachgelagerte Konsumenten fehlerhaften Ausgaben vertrauen.
Der Agent fällt nach einem Schreibvorgang oder einer externen Aktion aus, aber bevor die Kompensation ausgeführt wird, was zu doppelten oder verwaisten Datensätzen führt.

Lessons Learned

Die Entscheidung zwischen Wiederholungsversuch, Fallback und Eskalation hängt von der Unterscheidung zwischen vorübergehenden und dauerhaften Fehlern ab; investieren Sie in eine klare Klassifizierung, bevor Sie Backoff-Kurven optimieren.
Idempotenz-Keys machen aus einem riskanten Wiederholungsversuch einen sicheren; planen Sie dies von Anfang an ein, anstatt später eine Deduplizierung dranzuflanschen.
Harte Obergrenzen für Versuche, Zeit und Kosten sind nicht verhandelbar; ein Agent ohne diese Limits wird irgendwann einen Weg finden, endlos zu laufen.
Protokollieren Sie jeden Wiederholungsversuch, jedes Fallback und jede Kompensation, damit eine unbemerkte Verschlechterung als Metrik sichtbar wird und nicht als überraschender Vorfall.

FAQs

Wie unterscheidet sich dies vom einfachen Hinzufügen von try/except und einer Wiederholungsschleife?: Try/except behandelt einen einzelnen Fehler; eine Recovery-Strategie entscheidet, um welche Art von Fehler es sich handelt, und wählt unter harten Budgets zwischen Wiederholungsversuch, Fallback, Rollback und Eskalation. Der Kern liegt in der Kontrolllogik und der Idempotenz, nicht in der Ausnahmebehandlung.
Wie viele Wiederholungsversuche sollte ich zulassen?: Wenige – typischerweise eine niedrige, feste Obergrenze mit exponentiellem Backoff und Jitter, plus separate Zeit- und Kostenobergrenzen. Die genaue Anzahl hängt von der Abhängigkeit ab, aber die Schleife muss immer enden, und dauerhafte Fehler sollten überhaupt nicht wiederholt werden.
Was passiert, wenn eine Aktion nicht rückgängig gemacht oder idempotent gestaltet werden kann?: Führen Sie darüber hinweg keine automatischen Wiederholungsversuche aus. Setzen Sie vor dem unumkehrbaren Schritt einen Checkpoint und eskalieren Sie bei einem Fehler an einen Menschen oder einen überwachenden Agenten, anstatt Vermutungen anzustellen. Unumkehrbarkeit ist ein Signal, langsamer vorzugehen, nicht, es noch intensiver zu versuchen.