LangGraph gibt Agenten einen kontrollierten Fehlerpfad

Ein Agent wartet auf eine externe API. Der Aufruf hängt, läuft ins Zeitlimit und endet mit einer Exception. Jetzt entscheidet die Fehlerarchitektur darüber, ob der Lauf kontrolliert weitergeht, falsche Ergebnisse produziert oder komplett neu gestartet werden muss. LangGraph bündelt dafür Wiederholungen, Zeitlimits und Fehlerbehandler direkt im Graphen.

Bei Agenten reicht ein großer Catch-Block um den gesamten Ablauf nicht aus. Ein kurzer Netzwerkaussetzer darf wiederholbar sein. Nach mehreren Fehlversuchen braucht derselbe Aufruf womöglich einen Ersatzpfad. Vor einer extern wirksamen Folgeaktion kann zusätzlich eine menschliche Freigabe nötig werden. Diese Entscheidungen sollten getrennt sichtbar bleiben.

Das ergänzt die grundsätzliche Trennung von Planung, Ausführung und Kontrolle, die auch im Vergleich von LangChain, CrewAI und AutoGen wichtig ist: Ein Framework nimmt dem System nicht die Entscheidung ab, welcher Fehler wiederholbar ist und welcher den fachlichen Zustand verändert.

Erst wiederholen, dann den Fehlerpfad öffnen

Die Fehlerbehandlung folgt einer festen Reihenfolge. Eine Exception – auch ein durch das Zeitlimit ausgelöster NodeTimeoutError – wird zunächst von der Wiederholungsregel geprüft. Passt die Regel und sind weitere Versuche erlaubt, startet der Knoten erneut. Nach dem letzten zulässigen Versuch übernimmt ein hinterlegter Fehlerbehandler.

Damit haben die drei Mechanismen unterschiedliche Aufgaben: Das Timeout begrenzt die Dauer eines einzelnen Versuchs. Die Retry-Regel entscheidet, welche Fehler einen weiteren Anlauf rechtfertigen. Der Fehlerbehandler bestimmt, was danach mit dem Lauf und seinem Zustand geschieht.

Typische Auslöser sind langsame externe APIs, vorübergehende Netzwerkfehler und unbehandelte Exceptions. Per-Node-Timeouts und Fehlerbehandler auf Knotenebene setzen mindestens LangGraph 1.2 voraus. Regeln lassen sich einzelnen Knoten zuweisen oder über set_node_defaults als gemeinsame Vorgabe setzen. Für Plattformteams ist die zweite Variante vor allem eine Absicherung gegen vergessene Zeitlimits und ungewollte Sonderwege.

Recovery muss den fachlichen Zustand verändern

Der Fehlerbehandler erhält einen NodeError. Er kann den Zustand aktualisieren und den Graphen mit einem Command an einen anderen Knoten weiterleiten. Ein fehlgeschlagener Abruf muss den Lauf daher nicht sofort beenden. Entscheidend ist, dass der Ersatzpfad den Fehler nicht verdeckt.

Angenommen, ein Agent lädt Kundendaten aus einem Drittsystem und erstellt daraus einen Entwurf. Ein kurzer Verbindungsfehler rechtfertigt einen erneuten Versuch. Sind die Wiederholungen ausgeschöpft, darf der Agent die fehlenden Daten jedoch nicht als vollständig behandeln. Der Fehlerpfad sollte den Zustand als unvollständig markieren und den Entwurf an eine kontrollierte Prüfstufe übergeben.

Für mich ist das die wichtigste Grenze: Recovery bedeutet nicht, um jeden Preis weiterzulaufen. Ein guter Fehlerpfad erhält nur so viel Arbeit wie fachlich noch vertretbar ist und macht die Unsicherheit für nachfolgende Knoten sichtbar.

Bei lang laufenden Aufgaben kann ein später Netzwerkfehler, Werkzeugfehler oder Rate Limit einen vollständigen Neustart teuer machen. Die Wiederverwendung des vorhandenen Zustands ist aber nur dann sinnvoll, wenn klar dokumentiert ist, welche Ergebnisse fehlen oder als unsicher gelten.

Für länger laufende Prozesse lohnt sich deshalb zusätzlich ein dauerhaftes Ereignisprotokoll. Der Beitrag über ActiveGraph und agentischen Zustand zeigt, warum ein nachvollziehbarer Verlauf belastbarer ist als ein großer, still fortgeschriebener Kontext.

Menschliche Freigaben begrenzen das Geschäftsrisiko

Technische Fehlertoleranz beantwortet nicht, welche Aktionen ein Agent selbstständig ausführen darf. Human-in-the-Loop-Middleware schafft dafür einen zusätzlichen Kontrollpunkt: Ausgewählte Werkzeugaufrufe pausieren vor der Ausführung, bis ein Mensch sie genehmigt, bearbeitet oder ablehnt. Risikoarme Aufrufe können währenddessen automatisch weiterlaufen.

Damit lassen sich Betriebsstörung und Geschäftsrisiko getrennt behandeln. Ein fehlgeschlagener Lesezugriff darf möglicherweise automatisch wiederholt werden. Das Versenden einer E-Mail, die Freigabe einer Zahlung oder die Änderung kritischer Datensätze benötigt dagegen einen Prüfpunkt, bevor die Wirkung eintritt.

Für die Architektur ergeben sich drei getrennte Fragen:

1. Wie lange darf ein technischer Versuch laufen, und welche Fehler sind wiederholbar?
2. Welchen Zustand und welchen Pfad erzeugt das endgültige Scheitern?
3. Wer darf eine sensible Folgeaktion freigeben?

Wer diese Ebenen vermischt, bekommt entweder unnötig viele manuelle Stopps oder lässt riskante Aktionen ohne ausreichende Kontrolle passieren.

Fazit: Mindestregel für den produktiven Betrieb

Vor dem Rollout braucht jeder relevante Knoten eine klare Grenze für Laufzeit, Wiederholungen und den Zustand nach dem letzten Fehlversuch. Bei schreibenden oder anderweitig extern wirksamen Werkzeugen kommt eine Freigaberegel hinzu. Ohne Tests, die Timeouts, erschöpfte Retries und unvollständige Zustände gezielt auslösen, ist der Knoten nicht produktionsreif.

LangGraphs feste Reihenfolge liefert dafür ein nachvollziehbares Grundgerüst. Sie ersetzt weder fachliche Fehlerklassen noch die Risikobewertung einzelner Werkzeuge. Die Mindestregel bleibt deshalb einfach: automatisch nur wiederholen, was sicher wiederholbar ist; nach dem Scheitern Unsicherheit im Zustand festhalten; vor riskanter Wirkung einen kontrollierten Prüfpunkt setzen. So wird ein Fehler nicht unsichtbar – aber begrenzt und behandelbar.