LangGraph mit Temporal: Retries sichern keinen festen Kontext

LangGraph kann für lang laufende Agenten genügen, wenn ein dauerhafter Checkpointer den Graphzustand speichert und das Team die Wiederaufnahme selbst betreibt. Temporal ergänzt die Ausführung über Worker-Ausfälle hinweg: Die Dokumentation der LangGraph-Integration beschreibt Knoten als Activities mit eigenen Timeouts und Retry-Regeln; deterministische Knoten können direkt im Workflow laufen. Ein Retry sorgt jedoch nicht dafür, dass ein späterer Aufruf denselben Prompt, Modellalias, Suchindex oder dieselbe Werkzeugversion vorfindet.

Entscheidend ist, ob ein Lauf nur technisch weitergehen oder unter denselben fachlichen Annahmen fortgesetzt werden soll. Ein Preprint zur semantischen Isolation fand unter 100 populären Repositories mit ausführbarem LangGraph-Code vier von 54 Codebasen mit dauerhaften Workflows, die veränderliche Ressourcen ohne erkennbare unveränderliche Bindung auflösten – 7,4 Prozent dieser Teilgruppe. Das beschreibt ein im Quellcode sichtbares Risiko, keine beobachtete Ausfallquote.

Was LangGraph speichert und Temporal ausführt

Ein LangGraph-Checkpoint hält den Zustand eines Laufs fest, etwa eine Bestell-ID, Zwischenergebnisse und abgeschlossene Schritte. Wird eine begonnene Aufgabe vor dem Speichern ihres Ergebnisses unterbrochen, kann sie bei der Wiederaufnahme erneut ausgeführt werden. Deshalb gehören externe Aufrufe in klar abgegrenzte Aufgaben: Der gespeicherte Graphzustand allein verrät nicht zuverlässig, ob ein Dienst eine Anfrage bereits verarbeitet hat.

In der Temporal-Integration trägt die Workflow-Historie die Dauerhaftigkeit. Ein zusätzlicher externer LangGraph-Checkpointer ist dafür nicht nötig; benötigt eine LangGraph-Funktion einen Checkpointer, etwa für eine Unterbrechung, sieht die Integration einen InMemorySaver vor. Modellaufrufe, Datenbankabfragen und andere Ein- und Ausgaben gehören in Activities. Direkt im Workflow laufen nur deterministische Zustandsänderungen und Verzweigungen, damit Temporal den Ablauf anhand seiner Historie wiedergeben kann.

Die Arbeitsteilung beantwortet die Architekturfrage: Wer mit LangGraph-Checkpoints und eigener Betriebslogik auskommt, braucht für die bloße Wiederaufnahme keinen zweiten Workflow-Dienst. Temporal ist sinnvoll, wenn Timeouts, Worker-Ausfälle und wiederholte externe Schritte als Teil einer gemeinsamen dauerhaften Ausführung gesteuert werden sollen. Die Wahl dieser Laufzeit entscheidet noch nicht, welche Versionen veränderlicher Agentenressourcen ein fortgesetzter Schritt verwendet.

Vier Fehlerfälle in einer Bestellung

Der folgende Bestellworkflow ist hypothetisch. Ein Agent fragt Produktinformationen ab, bewertet sie mit einem Prompt und ruft anschließend einen Dienst zur Auftragsfreigabe auf. An jedem Fehlerfall zeigt sich eine andere Grenze zwischen gespeichertem Zustand, wiederholter Activity, Idempotenzschlüssel und Versionsbindung.

Worker-Absturz: Der Worker fällt während einer Modellabfrage aus, bevor deren Ergebnis feststeht. Ein LangGraph-Checkpoint liefert bei eigenständigem Betrieb den zuletzt gespeicherten Zustand; in der Integration kann Temporal die offene Modell-Activity nach ihren Retry-Regeln erneut ausführen. Für eine Freigabe, die bereits beim externen Dienst angekommen sein könnte, braucht es zusätzlich einen stabilen Idempotenzschlüssel. Soll die erneute Modellabfrage unter denselben Annahmen erfolgen, müssen die aufgelöste Modellversion, Promptrevision und benötigten Produktdaten für diesen Lauf verfügbar bleiben.
Doppelter Werkzeugaufruf: Der Freigabedienst verarbeitet die Bestellung, doch der Worker fällt aus, bevor Temporal den Erfolg erfährt. Die Temporal-Anleitung zur Fehlerbehandlung beschreibt für Activities eine Ausführung mindestens einmal: In genau dieser Lage kann der Aufruf wiederholt werden und soll deshalb idempotent sein. Im Beispiel könnte ein Schlüssel die Bestell-ID und die konkrete Freigabeaktion verbinden; der empfangende Dienst müsste ihn speichern und bei einem Retry das frühere Ergebnis zurückgeben. Für eine spätere, eigenständige Freigabe derselben Bestellung wäre eine neue Aktionskennung nötig.
Geänderter Prompt: Die Bestellung pausiert nach der Produktprüfung; währenddessen wird der Prompt hinter demselben Namen überarbeitet. Der Checkpoint enthält die alten Bestellinformationen, eine erneut ausgeführte Modell-Activity kann aber die neue Anweisung lesen. Ein Idempotenzschlüssel verhindert allenfalls eine doppelte Freigabe, nicht diese Verschiebung der Entscheidungsgrundlage. Der Lauf braucht daher die konkret aufgelöste Promptrevision sowie die dazu passende Modell- und Werkzeugkonfiguration.
Ausgetauschter Retrieval-Index: Bei der Fortsetzung zeigt derselbe Indexname auf einen anderen Datenbestand. Die erneute Suche kann andere Produktinformationen liefern, obwohl Checkpoint und Activity ordnungsgemäß funktionieren. Für eine Fortsetzung auf derselben Grundlage braucht der Lauf einen erreichbaren Indexstand oder Snapshot und die Kennungen der herangezogenen Dokumente; auch das zugehörige Embedding-Modell muss zum Index passen. Ist der alte Stand nicht mehr verfügbar, kann eine neue Abfrage eine neue Bewertung und gegebenenfalls eine erneute Freigabe erfordern.

Versionsbindung muss über den Retry hinausreichen

Ressourcennamen allein bilden keinen stabilen Kontext. Für eine Bestellung sollten die tatsächlich aufgelösten Versionen von Prompt, Modell, Index und Werkzeug-Schnittstellen zusammen mit dem Laufzustand festgehalten und an spätere Activities weitergegeben werden. Wird ein Werkzeug erst nach einer Modellentscheidung ausgewählt, muss seine Bindung dann ergänzt werden. Die Versionsangabe ist nur nützlich, wenn die referenzierte Ressource bei der Fortsetzung noch abrufbar ist.

Auch zueinander müssen die gebundenen Ressourcen passen. Ein alter Prompt kann ein Werkzeugformat erwarten, das eine neue Implementierung anders interpretiert; ein Index kann mit einem Embedding-Modell aufgebaut worden sein, das nicht zur späteren Anfrage passt. Stabile Einzelversionen verhindern solche Kombinationen nicht von selbst. Wo eine benötigte Version fehlt, sollte der Lauf den Kontextwechsel als neue fachliche Entscheidung behandeln, statt unbemerkt mit einer anderen Ressource weiterzurechnen.

Selbst bei gebundenem Kontext ist ein identischer Modelltext nicht garantiert: Die Bindung legt die verwendeten Ressourcen und ihre Verträge fest, nicht jeden möglichen Modellausgang. Für die Bestellung ist deshalb die präzise Zusage wichtiger als das Wort „Wiederaufnahme“: Welcher Zustand bleibt erhalten, welcher externe Schritt darf erneut laufen und auf welcher Informationsgrundlage darf die Freigabe erfolgen?

Wann die zusätzliche Laufzeit hilft

LangGraph allein passt, wenn das Team Checkpoints, Unterbrechungen und erneute Aufgaben mit seiner bestehenden Infrastruktur zuverlässig betreibt. Temporal ergänzt eine dauerhafte Workflow-Ausführung mit getrennt konfigurierbaren Activities und kontrollierten Retries. Bei externen Seiteneffekten bleibt die Pflicht zur Idempotenz bestehen; bei veränderlichen Prompts, Modellen, Indizes und Werkzeugen kommt die Bindung ihrer Versionen hinzu. Diese Anforderungen hängen am Bestellschritt und seiner fachlichen Wirkung, nicht daran, welche Komponente den Retry auslöst.

Lesen Sie auch: