LangGraph: eine Low-Level-Laufzeit für zustandsbehaftete Agenten

LangGraph ist der Teil des LangChain-Stacks, der den Agenten ausführt. Knoten und Kanten werden über ein gemeinsames Zustandsobjekt deklariert, und die Laufzeit durchläuft den Graphen Schritt für Schritt, einen Superstep auf einmal, und schreibt danach jeweils einen Checkpoint, damit der Lauf angehalten, fortgesetzt und inspiziert werden kann. Das ist das gesamte Produkt, und das Urteil folgt daraus: die beste quelloffene Antwort auf eine enge Frage, und wer diese enge Frage beantwortet haben will, sollte zugreifen.

Es liegt unterhalb des Agenten und oberhalb des Modells. LangChain-Agentenabstraktionen und das neuere Paket deepagents bauen darauf auf; CrewAI, LlamaIndex und das OpenAI Agents SDK gehen dieselbe Aufgabe von der anderen Seite mit mehr eingebauten Meinungen an. Gemessen an einer selbst geschriebenen Schleife zählt der Beitrag zur Persistenz, nicht zur Orchestrierung.

Was es ist

Die aktuelle Release-Reihe ist langgraph 1.2.x. Version 1.2.14 war im Oktober 2026 auf PyPI verfügbar und verlangt Python 3.10 oder neuer. Das Repository nennt Pregel und Apache Beam als Vorbilder und NetworkX als Vorbild für die öffentliche Schnittstelle, und es sagt ausdrücklich, dass die Bibliothek ohne LangChain selbst funktioniert.

• Ein Graph aus Knoten über einem Zustandsobjekt. Knoten liefern Teilaktualisierungen, und Kanal-Reducer entscheiden, wie zwei gleichzeitige Schreibvorgänge auf denselben Schlüssel zusammengeführt werden.
• Checkpointer, die pro Superstep einen Zustands-Snapshot ablegen und Läufe in Threads organisieren, adressiert über thread_id.
• Stores, eine eigene Schlüssel-Wert-Schicht über Threads hinweg für Langzeitgedächtnis wie Nutzerpräferenzen und geteilte Referenzdaten.
• interrupt(), das einen Knoten an beliebiger Stelle im Graphen anhält und die Kontrolle an den Aufrufer zurückgibt, bis der Graph fortgesetzt wird.
• Dauerhaftigkeitsmodi namens exit, async und sync, die pro Aufruf gesetzt werden.
• Typisiertes Streaming. Ab 1.2 liefert stream_events(..., version="v3") getrennte Projektionen für Nachrichten, Werte, Interrupts und die endgültige Ausgabe.

Zwei APIs erreichen dieselbe Laufzeit. Die Graph-API baut auf StateGraph auf und drückt den Kontrollfluss als Kanten aus. Die Functional-API drückt ihn als gewöhnliches Python aus, dekoriert mit @entrypoint und @task. Die funktionale liest sich besser im Pull Request; die graphische zeichnet sich als Bild, was mehr zählt als es klingt, wenn ein Betriebsteam nachts um drei entscheiden muss, was der Agent tun wird.

Wie es funktioniert

Die Ausführung folgt dem Pregel-Modell. Jeder ausführungsbereite Knoten startet gemeinsam in einem Superstep; wenn alle fertig sind, werden ihre Schreibvorgänge als ein einziger Checkpoint festgeschrieben, und der nächste Superstep wird aus dem aktualisierten Zustand geplant. Darum sind ausstehende Schreibvorgänge wichtig: Wirft ein Knoten in einem Superstep, sind die Schreibvorgänge seiner erfolgreichen Geschwister bereits dauerhaft, und ein Fortsetzen führt sie nicht erneut aus. Teure Modellaufrufe in einem Fan-out werden genau einmal bezahlt.

Nebenläufigkeit ist der Ort mit den scharfen Kanten. Zwei Knoten, die im selben Superstep denselben Zustandsschlüssel schreiben, brauchen einen Reducer. LangGraph liefert add und einen Last-Value-Standard, den Rest schreibt man von Hand. Ein Fehler hier löst nichts aus: einer der beiden Schreibvorgänge verschwindet lautlos, und das Symptom zeigt sich weit später als eine Entscheidung, die der Agent nicht erklären kann.

Der Zustand ist auch die Speicherrechnung. Jeder Superstep schreibt das gesamte Zustandsobjekt neu, ein Schlüssel, der abgerufene Dokumente sammelt, macht damit jeden Schritt zu einem vollständigen Payload-Write. Den Zustand an der Knotengrenze ausdünnen und dauerhafte Artefakte außerhalb des Graphen halten.

Erste Schritte

Der kleinste Graph, den man schreiben sollte, ist ein Genehmigungsablauf, denn dafür ist die Laufzeit gedacht. Dieser hält für einen Menschen an, setzt auf demselben Thread fort und legt den Seiteneffekt hinter den Interrupt, damit er genau einmal ausgeführt wird.

from typing import Literal, TypedDict
from langgraph.checkpoint.postgres import PostgresSaver
from langgraph.graph import END, START, StateGraph
from langgraph.types import Command, interrupt

class State(TypedDict):
    request: str
    decision: str | None

def ask(state: State) -> Command[Literal["send", "cancel"]]:
    if interrupt({"question": "Send this?", "details": state["request"]}):
        return Command(goto="send")
    return Command(goto="cancel")

builder = StateGraph(State)
builder.add_node("ask", ask)
builder.add_node("send", lambda s: {"decision": "sent"})
builder.add_node("cancel", lambda s: {"decision": "cancelled"})
builder.add_edge(START, "ask")
builder.add_edge("send", END)
builder.add_edge("cancel", END)

with PostgresSaver.from_conn_string("postgresql://…") as saver:
    saver.setup()
    graph = builder.compile(checkpointer=saver)
    config = {"configurable": {"thread_id": "req-42"}}
    print(graph.invoke({"request": "refund 8891"}, config, durability="sync")["__interrupt__"])
    print(graph.invoke(Command(resume=True), config, durability="sync")["decision"])

Zwei Details in diesem Snippet wiegen schwerer als der Rest. PostgresSaver.setup() legt die Checkpoint-Tabellen einmal beim Deployment an, nicht einmal pro Prozess. Und durability="sync" ist für einen Genehmigungsablauf die richtige Wahl: der Write ist abgeschlossen, bevor der nächste Schritt startet, ein Absturz zwei Sekunden später kann die gerade getroffene Entscheidung also nicht verlieren.

Persistenz und Dauerhaftigkeit

Persistenz ist der Grund für die Einführung des Frameworks und zugleich die Stelle, an der die Marketing-Sprache unscharf wird. Ein Checkpointer schreibt einen Snapshot. Dauerhafte Ausführung bedeutet, dass der Lauf weiterläuft. LangGraph macht das Erste; das Zweite bleibt bei dem, der den Prozess betreibt.

• exit — es wird nichts geschrieben, bis der Lauf endet, fehlschlägt oder unterbrochen wird. Am schnellsten, ein Prozessabsturz verliert den Lauf.
• async — die Schreibvorgänge laufen, während der nächste Schritt ausgeführt wird. Der Standard-Kompromiss: gute Latenz und ein kleines Fenster, in dem ein Absturz Zustand verliert.
• sync — jeder Checkpoint wird festgeschrieben, bevor der nächste Schritt beginnt. Höchste Dauerhaftigkeit, der Write liegt auf dem kritischen Pfad.

Checkpoints wachsen unbegrenzt. Die Persistenz-Dokumentation sagt das direkt und schlägt einen geplanten Job vor, der Checkpoints älter als ein Aufbewahrungsfenster löscht. Teams, die das überspringen, merken es an einer Datenbank, die still zur größten Komponente im Stack geworden ist, und das ist ein schlechter Nachmittag.

Interrupts und die Wiedergaberegeln

interrupt() ist das meistgenutzte Feature und das am häufigsten falsch gelesene. Es hält nicht an einer Zeile an. Es löst eine Ausnahme aus, wickelt sich bis zur Laufzeit ab, schreibt den Zustand und wartet unbegrenzt. Setzt der Graph den Lauf fort, startet die Laufzeit den gesamten Knoten von oben neu und ordnet die Wiederaufnahme-Werte strikt nach Index den Interrupt-Aufrufen zu. Jeder Produktionsfehler in diesem Bereich entsteht aus dem Ignorieren eines dieser beiden Sätze.

• Ein interrupt()-Aufruf gehört niemals in ein blankes try/except. Die Pause ist eine geworfene Ausnahme, ein breiter Handler schluckt sie, und der Graph hält überhaupt nicht an.
• Interrupts in einem Knoten nicht bedingt überspringen und nicht umsortieren. Die Zuordnung erfolgt nach Index, eine geänderte Reihenfolge verbraucht ohne jede Fehlermeldung den falschen Wert.
• Jeden Seiteneffekt vor einem Interrupt idempotent machen, ihn hinter die Pause verschieben oder in einen eigenen Knoten auslagern. Die Dokumentation sagt ausdrücklich, dass ein vor dem Interrupt angelegter Datensatz bei jedem Fortsetzen erneut angelegt wird.
• while True-Schleifen um einen Interrupt in einem Knoten vermeiden. Jedes Fortsetzen spult die früheren Iterationen erneut ab, die Arbeit in der Schleife wächst also exponentiell.

Wo es schwächelt

Die Schwächen kommen zuerst, weil sie entscheiden, ob das Framework passt. Ein Lauf lebt in einem Prozess. In der quelloffenen Bibliothek gibt es keinen Supervisor, keine Aufgabenwarteschlange und keinen Worker-Pool; stirbt der Prozess, ist der Lauf tot, bis ein System außerhalb von LangGraph es bemerkt und erneut einsteigt. Menschliche Prüfung hat dieselbe Form: interrupt() hält den Lauf an, und das Ding zu bauen, das eine Genehmigung bemerkt und den richtigen Thread aufweckt, ist nun das eigene Problem.

Die zweite Schwäche ist die Ergonomie. LangGraph abstrahiert nichts über Prompts oder Architektur, was ein Vorteil ist, wenn der Agent das Produkt ist, und ein Hindernis, wenn nicht. Das Framework sagt nicht, wie ein Prompt aufzubauen ist, wann mit Werkzeugaufrufen aufzuhören ist oder wie viele Retries ein Schritt verdient. Die meisten Teams verbringen die ersten Wochen eines LangGraph-Projekts damit, die Werkzeugschleife neu zu erfinden, also genau das, was eine höhere Abstraktion geliefert hätte.

Die dritte ist die Bindung an den Hersteller, und sie ist milder als üblicher behauptet. Die Laufzeit steht unter MIT, läuft im eigenen Prozess und schreibt in die eigene Datenbank, es werden also keine Daten als Pfand gehalten. Die echte Abhängigkeit entsteht, sobald Graphen über LangSmith deployed werden: Deployment, Assistants-API und Cron-Planung sind LangChain-Oberflächen, und der Umstieg später ist echte Arbeit.

Was es kostet

LangGraph ist kostenlos. Bei LangSmith liegt das Geld, abgerechnet pro Sitz mit metrikbasierter Nutzung obendrauf: Developer ist für einen Sitz mit 5.000 Basis-Traces pro Monat kostenlos, Plus kostet 39 US-Dollar pro Sitz und Monat mit 10.000 Basis-Traces sowie Zugang zu Deployment, Engine und Sandboxes, und Enterprise wird auf Anfrage bepreist, mit hybrider oder vollständig selbst gehosteter Installation.

• Die Nutzung wird in LangChain Standard Units zu je 1 US-Dollar abgerechnet, eine serverlose Deployment zusätzlich über Rechenzeit, Arbeitsspeicher, Datenbankrechenzeit und Datenbankspeicher sowie die Zeit, in der die Datenbank live ist.
• Die Aufbewahrung von Traces beträgt 14 Tage für einen Basis-Trace und 180 Tage für einen erweiterten Trace, der gesondert berechnet wird.
• LangSmith gibt an, nicht mit Kundendaten zu trainieren, und bietet auf der Enterprise-Stufe eine selbst gehostete Datenebene für Teams, deren eigene Kontrollen das verlangen.

Das Trace-Kontingent ist die Zahl, auf die es ankommt. Ein Agentenlauf ist ein Trace, und ein Lauf, der fünf Werkzeuge über zehn Knoten aufruft, erzeugt einen Graphen von Spans darin. Jede Produktionsanfrage zu tracen, verbraucht 5.000 oder 10.000 Traces erstaunlich schnell, und in diesem Moment hört die Rechnung auf, ein Randposten zu sein. Sampling nach Umgebung ist die billigste Gegenmaßnahme.

Urteil

LangGraph ist eine gute Antwort auf eine Frage: wie hält man einen langen Agentenlauf über einen Absturz, ein Deployment oder eine menschliche Genehmigung hinweg am Leben. Innerhalb dieser Grenze ist die Arbeit sorgfältig: das Checkpoint-Format ist dokumentiert, ausstehende Schreibvorgänge sind eine wirklich gute Idee, und die Interrupt-Semantik ist so klar beschrieben, dass man sie beim Entwurf berücksichtigen kann. Außerhalb ist die Bibliothek eine Laufzeit ohne Meinungen, und alles, was sie nicht entscheidet, wird um drei Uhr nachts zur Arbeit der lesenden Person.

1. Einführen, wenn ein Lauf einen Neustart überleben muss: eine Genehmigungswarteschlange, ein Forschungsauftrag über Stunden, ein Agent, der auf einen Menschen wartet.
2. Einführen, wenn der Lauf prüfbar sein muss. Knoten und Kanten sind der günstigste Weg, einem Nicht-Ingenieur genau zu zeigen, was der Agent tun wird.
3. Einführen, wenn es darauf ankommt, deterministische und modellgetriebene Schritte zu mischen, und die Grenze dazwischen exakt und testbar sein muss.
4. Auslassen für eine Werkzeugschleife, die in drei Schritten fertig ist. Zwanzig Zeilen Python sind billiger zu besitzen und schneller zu debuggen.
5. Nicht als Dauerhaftigkeitsschicht betrachten. Wenn ein stiller Totalausfall Bestellungen kostet, einen Supervisor ergänzen oder den Graphen auf Temporal betreiben, dessen LangGraph-Plugin im Juli 2026 in die Public Preview ging.
6. Nicht einführen, ohne die Interrupt-Regeln einmal gelesen zu haben. Die Wiedergabesemantik ist der Teil, der in der Produktion doppelte Seiteneffekte erzeugt.

LangGraph ist ein einfacher, effizienter Weg, einen Agenten auszudrücken: das Graphmodell ist klar, das Ökosystem ist reichhaltig, und Prototypen kommen schnell zusammen. Aber es ist keine vollständige Produktionsgeschichte. Temporal, zum LangGraph-Plugin, Juli 2026

Quellen

1. LangGraph-Dokumentation: Überblick
2. LangGraph-Dokumentation: Checkpointer und Dauerhaftigkeitsmodi
3. LangGraph-Dokumentation: Interrupts und die Regeln dazu
4. langchain-ai/langgraph auf GitHub
5. LangSmith-Preise
6. Temporal: LangGraph-Integration für Python erreicht die Public Preview (16. Juli 2026)