LangGraph in Produktion: Checkpointing, Freigaben und Fehlerbehandlung für den Mittelstand

Ein LangGraph-Prototyp ist schnell gebaut: ein paar Knoten, ein Modell, ein Werkzeug, fertig. Schwierig wird es an dem Tag, an dem der Agent echte Arbeit übernimmt. Dann soll er nach einem Neustart weitermachen, vor einer Bestellung auf eine Freigabe warten, eine wackelige Schnittstelle aushalten und trotzdem nachvollziehbar bleiben. Genau dafür hat LangGraph eigene Bausteine: Checkpointer, Interrupts, Retry-Policies, Fehlerhandler und eine Laufzeit für den Betrieb.

Dieser Beitrag ist die Fortsetzung unseres Überblicks LangGraph im Mittelstand: Agenten orchestrieren ohne Chaos. Dort ging es um das Grundprinzip. Hier geht es um die Frage, was Du einbauen musst, damit ein LangGraph-Agent im Betrieb verlässlich läuft. Alle technischen Angaben stammen aus der aktuellen LangGraph-Dokumentation (Stand Oktober 2026).

Warum Produktion etwas anderes ist als die Demo

LangGraph beschreibt sich selbst als Orchestrierungs-Framework und Laufzeit für langlebige, zustandsbehaftete Agenten. Der wichtigste Satz für den Mittelstand steckt in einem Detail: Du kannst in einem Graphen fest programmierte Schritte und KI-gesteuerte Schritte mischen. Die Prüfung einer Kundennummer, das Anlegen eines Vorgangs oder die Berechnung eines Rabatts bleiben deterministisch. Nur dort, wo Sprache verstanden oder ein Entwurf formuliert werden muss, entscheidet das Modell.

In der Demo läuft alles in einem Durchgang. Im Betrieb dagegen dauern Abläufe Stunden oder Tage, weil eine Freigabe aussteht. Prozesse werden neu gestartet, Schnittstellen antworten nicht, und irgendwann will jemand wissen, warum der Agent eine bestimmte Entscheidung getroffen hat. Vier Themen entscheiden deshalb über den Erfolg: Zustand sichern, Freigaben einbauen, Fehler abfangen und sauber betreiben.

Checkpointing: Der Agent verliert nicht den Faden

Ein Checkpointer speichert laut Dokumentation nach jedem sogenannten Super-Step einen Schnappschuss des Graph-Zustands, sortiert nach Threads. Ein Thread ist ein Vorgang, etwa eine Reklamation oder eine Angebotsanfrage, und wird über eine thread_id angesprochen. Wer dieselbe ID wieder verwendet, setzt genau dort an, wo der Vorgang stand. Wer eine neue ID nimmt, beginnt mit leerem Zustand.

Für den Betrieb sind drei Punkte wichtig:

• Kein Arbeitsspeicher in Produktion: InMemorySaver hält Checkpoints nur im RAM. Nach einem Neustart sind sie weg. Für den Echtbetrieb nennt die Dokumentation persistente Checkpointer, etwa auf Basis von Postgres oder MongoDB. SQLite ist für Experimente und lokale Abläufe gedacht.
• Durability-Modus bewusst wählen: LangGraph kennt die Modi exit, async und sync. Bei exit wird nur am Ende gespeichert, ein Absturz mittendrin ist dann nicht wiederherstellbar. sync schreibt jeden Checkpoint, bevor der nächste Schritt startet, und kostet dafür etwas Leistung. Für Abläufe mit Buchungen oder Bestellungen ist sync meist die ruhigere Wahl.
• Aufräumen und schützen: Checkpoints wachsen mit jedem Schritt. Die Dokumentation empfiehlt, alte Checkpoints regelmäßig zu löschen. Außerdem lässt sich der gespeicherte Zustand mit einem EncryptedSerializer verschlüsseln. Weil in Checkpoints oft Kundendaten stehen, gehören Aufbewahrungsfrist und Verschlüsselung ins Datenschutzkonzept.

Ein praktischer Nebeneffekt: Wenn in einem Schritt mehrere Knoten parallel laufen und einer scheitert, speichert LangGraph die Ergebnisse der erfolgreichen Knoten als ausstehende Schreibvorgänge. Beim Fortsetzen müssen diese nicht erneut laufen. Für das Langzeitgedächtnis über Vorgänge hinweg gibt es zusätzlich Stores. Wie Du Kurzzeit- und Langzeitgedächtnis trennst, beschreibt unser Beitrag Gedächtnis für KI-Agenten.

Interrupts: Freigaben, bevor etwas Wichtiges passiert

Mit der Funktion interrupt() hält ein Knoten an, speichert den Zustand über den Checkpointer und wartet ohne Zeitlimit auf eine Antwort. Fortgesetzt wird mit Command(resume=...) und derselben thread_id. Der übergebene Wert wird zum Rückgabewert von interrupt(). Die Dokumentation zu Interrupts nennt als typische Muster Freigaben vor kritischen Aktionen, das Prüfen und Bearbeiten von Entwürfen und das Anhalten vor Werkzeugaufrufen.

Im Mittelstand heißt das zum Beispiel: Der Agent bereitet eine Gutschrift vor, die Buchhaltung gibt frei oder korrigiert den Betrag, erst dann wird gebucht. Damit das zuverlässig klappt, gibt die Dokumentation klare Regeln vor:

• Der Knoten startet beim Fortsetzen von vorn. Code vor dem interrupt() läuft also erneut. Seiteneffekte davor müssen idempotent sein, ein zweites Ausführen darf nichts doppelt anlegen. Am einfachsten legst Du Buchungen und Mails hinter die Freigabe.
• Kein pauschales try/except um den Interrupt. Der Interrupt arbeitet intern mit einer Ausnahme. Wer sie abfängt, verhindert die Pause.
• Reihenfolge stabil halten. Mehrere Interrupts in einem Knoten werden über ihre Position zugeordnet. Sie dürfen nicht je nach Lauf übersprungen oder umsortiert werden.
• Nur einfache Werte übergeben. Die Nutzlast muss JSON-serialisierbar sein. Ab Version 1.2.12 lässt sich zudem ein Antwortschema festlegen, gegen das die Rückmeldung geprüft wird.

Wo Freigaben in einem Team aus mehreren Agenten sitzen sollten, zeigt unser Beitrag Multi-Agent-Systeme mit Human-in-the-Loop.

Fehler abfangen: Retries, Timeouts und Ausgleich

Die Seite zur Fehlertoleranz beschreibt drei Mechanismen, die in fester Reihenfolge greifen. Zuerst entscheidet eine Retry-Policy, ob ein gescheiterter Versuch wiederholt wird. Standard sind drei Versuche mit wachsendem Abstand und Zufallsanteil. Bei HTTP-Fehlern aus Bibliotheken wie requests oder httpx wird standardmäßig nur bei 5xx-Antworten wiederholt. Ab Version 1.2 kommen Timeouts pro Knoten hinzu, allerdings nur für asynchrone Knoten. Erst wenn alle Versuche aufgebraucht sind, läuft ein Fehlerhandler.

Dieser Fehlerhandler ist für Geschäftsprozesse besonders nützlich. Er kann den Zustand ändern und den Ablauf an einen anderen Knoten weiterleiten, etwa um eine Reservierung zurückzunehmen oder den Vorgang als gescheitert zu markieren und eine Person zu informieren. Mit set_node_defaults legst Du Retry, Timeout und Fehlerhandler einmal für den ganzen Graphen fest. Zwei Details solltest Du kennen: Ein interrupt() löst weder Retry noch Fehlerhandler aus. Und Standardwerte gelten nicht automatisch für Teilgraphen.

Für Wartungsfenster gibt es außerdem einen geordneten Stopp. Ein laufender Graph beendet den aktuellen Schritt, speichert einen fortsetzbaren Checkpoint und hält an. So geht bei einem Update keine Arbeit verloren.

Betrieb: Wo der Agent läuft

Für den Betrieb verweist LangChain auf LangSmith Deployment. Alle Varianten nutzen denselben Agent Server, der Checkpointing und Persistenz selbst übernimmt. Zur Wahl stehen eine verwaltete Cloud, ein Hybridmodell mit Agent Servern in der eigenen Infrastruktur, ein selbst betriebener Standalone-Server mit eigenem PostgreSQL und Redis sowie eine komplett selbst gehostete Variante. Die einzelnen Varianten setzen unterschiedliche LangSmith-Tarife voraus. Prüfe deshalb Preise, Speicherort und Auftragsverarbeitung, bevor Du Dich festlegst.

Wichtig für Euren Betrieb: Ein Agent ist erst produktiv, wenn Ihr seht, was er tut. Logs, Traces und Kennzahlen pro Schritt gehören dazu, egal auf welcher Plattform. Wie das herstellerneutral mit OpenTelemetry gelingt, steht in Observability für KI-Agenten. Und wer Agenten mit Werkzeugzugriff baut, sollte die Risiken aus Guardrails gegen Prompt Injection kennen.

Einordnung: LangGraph, Google ADK und CrewAI

LangGraph ist nicht die einzige Option. Die Konzepte ähneln sich, die Schwerpunkte unterscheiden sich:

• LangGraph arbeitet bewusst auf niedriger Abstraktionsebene. Du modellierst Zustand, Knoten und Übergänge selbst und bekommst dafür viel Kontrolle über Checkpoints, Freigaben und Fehlerpfade.
• Google ADK bietet laut ADK-Dokumentation ab Python 1.16 fortsetzbare Workflows und mit der Tool-Bestätigung Freigaben vor Werkzeugaufrufen, die derzeit als experimentell gekennzeichnet sind. Wer ohnehin auf Google Cloud und Vertex AI setzt, findet hier den kürzesten Weg, mehr dazu in Google ADK und Agent Engine.
• CrewAI denkt in Rollen und Crews. Für feste Abläufe gibt es Flows mit dem Decorator @persist, der den Zustand laut CrewAI-Dokumentation standardmäßig in SQLite speichert. Einen Vergleich findest Du in CrewAI im Mittelstand.

Interessant: LangSmith Deployment kann laut Dokumentation auch ADK- und CrewAI-Agenten betreiben. Die Wahl des Frameworks und die Wahl der Laufzeit sind also zwei getrennte Entscheidungen. Für uns zählt am Ende, welches Werkzeug zu Deinem Team, Deiner Cloud und Deinem Prozess passt.

Checkliste vor dem Go-live

1. Persistenter Checkpointer statt Arbeitsspeicher, Durability-Modus bewusst gewählt.
2. Eindeutige thread_id pro Vorgang, zum Beispiel aus Auftragsnummer oder Ticket-ID.
3. Freigaben vor jeder Aktion mit Außenwirkung, Seiteneffekte erst nach dem Interrupt.
4. Retry-Policy, Timeouts und Fehlerhandler mit klarer Eskalation an eine verantwortliche Person.
5. Aufbewahrung, Verschlüsselung und Löschung der Checkpoints im Datenschutzkonzept beschrieben.
6. Traces und Kennzahlen pro Schritt, damit Fehler sichtbar werden, bevor Kunden sie merken.

Fazit

LangGraph bringt die Bausteine für produktive Agenten mit. Ob ein Agent im Alltag trägt, hängt aber weniger vom Framework ab als von Disziplin bei Zustand, Freigaben und Fehlerpfaden. Wer diese drei Punkte vor dem Go-live klärt, baut Agenten, denen das Team vertraut.

Du willst wissen, ob Dein Betrieb für Agenten bereit ist? Starte mit dem AI-Readiness-Check oder lies unser Whitepaper zur KI-Readiness. Für einen konkreten Prozess sprich uns an: Kostenloses Erstgespräch vereinbaren.