Lösungen für
Bitte auswählen
Web-App testen
ki-werkzeuge

LangGraph

Redaktion ·

Wenn ein Agent mehr als eine Gerade braucht — warum dich das angeht

Die meisten ersten Agenten-Prototypen sind eine Kette: Prompt rein, Tool-Aufruf, Antwort raus. Das funktioniert, solange der Ablauf linear bleibt. Sobald der Agent aber eine Entscheidung wiederholen, ein fehlgeschlagenes Tool erneut versuchen, auf eine menschliche Freigabe warten oder mitten in der Bearbeitung pausieren und Stunden später weiterlaufen soll, fällt die Kette auseinander. Du fängst an, Zustand in globalen Variablen zu halten, baust per Hand while-Schleifen, schreibst eigene Logik zum Speichern und Wiederherstellen — und irgendwann ist die Hälfte deines Codes Orchestrierung statt Fachlogik.

Genau diese Lücke füllt LangGraph. Es ist ein Framework, mit dem du LLM-Agenten als Graph modellierst: Arbeitsschritte sind Knoten, der Kontrollfluss zwischen ihnen sind Kanten, und ein zentraler State trägt die Daten durch den Ablauf. Anders als eine lineare Kette darf dieser Graph Schleifen, Verzweigungen und Unterbrechungen enthalten — das ist der entscheidende Unterschied. Mit dem 1.0-Release (22. Oktober 2025) hat LangGraph diese Konzepte stabilisiert, und im Lauf von 2026 hat es sich in vielen Stacks als De-facto-Standard für die Orchestrierung produktiver Agenten etabliert.

Dieser Artikel erklärt die Mechanik so, dass du am Ende selbst entscheiden kannst, wann LangGraph das richtige Werkzeug ist — und wann nicht.

Die Grundmechanik: Agent als Graph

Der zentrale Gedanke ist einfach: Statt deinen Agenten als Skript zu schreiben, das von oben nach unten läuft, beschreibst du ihn als Diagramm aus Knoten und Kanten. LangGraph führt diesen Graph dann aus — inklusive der Sprünge zurück, Verzweigungen und Wiederholungen, die ein echter Agent braucht.

Drei Bausteine musst du verstehen: State, Nodes, Edges.

State — das geteilte Gedächtnis

Der State ist eine geteilte Datenstruktur, die durch den gesamten Graph wandert. Du deklarierst ihn vorab als typisiertes Schema (in Python meist ein TypedDict): jedes Feld, das der Graph liest oder schreibt, muss dort stehen. Ein typischer State enthält die Nachrichtenhistorie, Zwischenergebnisse von Tools, Zähler, Flags.

Wichtig ist die Update-Semantik: Ein Knoten bekommt den kompletten State als Eingabe und gibt nur die Felder zurück, die er verändert hat. LangGraph merged diese Teilaktualisierung in den Gesamt-State. Für Felder wie die Nachrichtenliste gibt es Reducer — zum Beispiel ein add_messages, das neue Nachrichten anhängt statt die Liste zu überschreiben. Dadurch wächst die Historie korrekt, ohne dass jeder Knoten das selbst regeln muss.

Nodes — wo die Arbeit passiert

Ein Node ist eine Funktion. Sie nimmt den aktuellen State entgegen, tut etwas — ruft ein LLM auf, führt ein Tool aus, transformiert Daten, schreibt in eine Datenbank — und gibt die geänderten State-Felder zurück. Knoten sind die einzige Stelle, an der echte Logik und Seiteneffekte stattfinden. Die Faustformel: Nodes machen die Arbeit, Edges sagen, was als Nächstes passiert.

Edges — der Kontrollfluss

Edges verbinden Knoten und bestimmen die Reihenfolge. Es gibt zwei Sorten. Eine normale Kante ist fest: nach Knoten A läuft immer Knoten B. Eine bedingte Kante (conditional edge) ist eine Funktion, die den aktuellen State liest und entscheidet, welcher Knoten als Nächstes dran ist. Genau hier entsteht die Intelligenz des Ablaufs: Hat das Modell ein Tool angefordert, geht es zum Tool-Knoten; ist die Aufgabe erledigt, geht es zum Ende.

Weil eine Kante auch auf einen bereits durchlaufenen Knoten zeigen darf, entstehen Zyklen — der eigentliche Grund, warum LangGraph existiert.

Das Ausführungsmodell — Message Passing

Unter der Haube arbeitet LangGraph mit Message Passing, angelehnt an das Pregel-Modell für Graph-Verarbeitung. Wenn ein Knoten fertig ist, schickt er entlang seiner ausgehenden Kanten eine Nachricht an die nächsten Knoten. Diese führen ihre Funktion aus, geben ihre Nachrichten weiter, und so weiter. Der Graph läuft in diskreten Schritten („Super-Steps”) — Knoten ohne Abhängigkeit voneinander können dabei parallel laufen.

LangGraph vs. LangChain — kein Entweder-oder

Die häufigste Verwirrung: Ist LangGraph ein Konkurrent von LangChain? Nein. Beide kommen vom selben Team (LangChain Inc.) und sind als unterschiedliche Abstraktionsebenen desselben Stacks gedacht.

  • LangChain liefert die Bausteine: Integrationen zu Modellen und Tools, Prompt-Abstraktionen, Komponenten zum schnellen Zusammenstecken eines Agenten.
  • LangGraph ist die Orchestrierungs-Runtime darunter: die StateGraph-Engine, die zyklische Ausführung, Verzweigung, persistenten Zustand und Unterbrechbarkeit hinzufügt.

Seit den 1.0-Releases (Oktober 2025) ist die Trennung sauber: LangChains neue create_agent-Funktion hat den alten AgentExecutor abgelöst und ruft intern die LangGraph-Engine auf. Anders gesagt — wer in LangChain einen Agenten baut, nutzt LangGraph bereits, ob bewusst oder nicht.

Die Praxis in 2026 sieht meist so aus: LangChain zum schnellen Bauen, LangGraph zum zuverlässigen Orchestrieren und Skalieren, dazu ein Memory-Layer (LangMem, Mem0) für sitzungsübergreifendes Gedächtnis.

Wann LangChain reicht, wann LangGraph nötig ist

Bleibt deine Agenten-Logik linear — Prompt, ein paar Tool-Aufrufe, Antwort, keine Verzweigung, kein Zustand über Sitzungen hinweg — kommst du mit der LangChain-Ebene schneller und mit weniger Boilerplate ans Ziel. Sobald dein Agent verzweigen, schleifen, wiederholen oder Zustand über Sitzungen hinweg halten muss, oder sobald du Produktionsfeatures wie Persistence und Human-in-the-Loop brauchst, ist LangGraph der richtige Schnitt.

Die zwei Features, die LangGraph in die Produktion bringen

Schleifen und Verzweigungen sind die Grundmechanik. Was LangGraph aber wirklich produktionstauglich macht, sind zwei darauf aufbauende Fähigkeiten.

Persistence — Zustand überlebt Neustarts

LangGraph kann nach jedem Knoten-Schritt einen Checkpoint des State speichern. Dafür gibt es Checkpointer-Backends — In-Memory für Tests, SQLite oder Postgres für Produktion. Der Effekt: Stürzt dein Server mitten in einer Konversation ab oder wird ein langlaufender Workflow unterbrochen, läuft er beim nächsten Aufruf exakt an der Stelle weiter, an der er stehengeblieben ist — ohne Kontext zu verlieren und ohne dass du eigene Datenbank-Logik schreiben musst.

Damit werden Abläufe möglich, die über eine einzelne Anfrage hinausgehen: mehrtägige Freigabeprozesse, Hintergrund-Jobs, Workflows über mehrere Sitzungen. Jeder Lauf bekommt eine Thread-ID; über sie greifst du auf den gespeicherten Verlauf zu, kannst zu einem früheren Checkpoint zurückspringen oder „Time-Travel”-Debugging betreiben.

Human-in-the-Loop — pausieren und auf Menschen warten

LangGraph bietet First-Class-Unterstützung, um die Ausführung gezielt zu unterbrechen (interrupt), damit ein Mensch prüfen, korrigieren oder freigeben kann. Die Runtime pausiert, speichert den State per Checkpoint und blockiert dabei keinen Thread. Antwortet der Mensch — Sekunden oder Stunden später — läuft die Ausführung genau am Unterbrechungspunkt weiter.

Das ist der saubere Weg für alles, was nicht vollautonom laufen soll: ein Agent, der eine E-Mail entwirft, aber vor dem Versand auf Freigabe wartet; ein Workflow, der eine Datenbank-Änderung vorbereitet und einen Menschen bestätigen lässt.

Stolperfallen

  • State zu groß werden lassen. Wer die komplette Historie ungefiltert im State mitschleppt, zahlt das in Tokens — bei jedem LLM-Knoten wird der Kontext neu mitgesendet. Reducer und gezieltes Trimmen der Nachrichtenliste gehören von Anfang an dazu (siehe auch unser Lexikon-Artikel zu KI-Pricing).
  • Endlosschleifen. Ein Zyklus ohne sauberes Abbruchkriterium läuft, bis das Token-Budget oder ein recursion_limit greift. Setze die Abbruchbedingung in der bedingten Kante bewusst.
  • Overengineering. Nicht jeder Agent braucht einen Graph. Ist der Ablauf wirklich linear, ist LangGraph zusätzlicher Aufwand ohne Gegenwert. Der Graph lohnt sich ab dem Moment, in dem du Schleifen, Verzweigung oder Persistence brauchst.
  • Checkpointer für Tests in Produktion. Der In-Memory-Checkpointer überlebt keinen Neustart. In Produktion gehört ein persistentes Backend (Postgres) dazu — sonst ist die ganze Persistence-Idee wertlos.

Einordnung im Feld der Agenten-Frameworks

LangGraph ist nicht das einzige Framework für Agenten — aber es belegt eine bestimmte Nische: graph-basierte, zustandsbehaftete Orchestrierung mit Fokus auf Kontrolle und Produktionsreife. Andere Frameworks setzen andere Schwerpunkte.

| Framework | Grundidee | Stärke | |---|---|---| | LangGraph | Agent als Graph aus Nodes/Edges/State | Schleifen, Persistence, Human-in-the-Loop, feine Kontrolle | | CrewAI | Rollenbasierte Teams aus Agenten | schnelles Aufsetzen von Multi-Agenten-Crews | | AutoGen | Agenten, die per Konversation kooperieren | Multi-Agent-Dialog, Forschung | | DSPy | Prompts als optimierbare Programme | systematische Prompt-/Pipeline-Optimierung |

Wenn du explizite Kontrolle über jeden Übergang willst und Produktionsfeatures brauchst, ist LangGraph die naheliegende Wahl. Brauchst du dagegen schnell ein Team kooperierender Agenten, lohnt der Blick auf CrewAI oder AutoGen. Geht es dir um die systematische Optimierung der Prompts selbst, ist DSPy der andere Ansatz. Einen breiteren Vergleich findest du in unserem Überblick zu Agenten-Frameworks.

Typische Einsatzszenarien

  • Recherche-Agent mit Tool-Schleife: Suchen, Ergebnis bewerten, bei Bedarf nachsuchen, dann zusammenfassen — die klassische Zyklus-Aufgabe.
  • Mehrstufige Workflows mit Freigabe: Ein Agent bereitet eine Aktion vor (E-Mail, Datenbank-Change, Ticket), unterbricht und wartet auf menschliche Bestätigung.
  • Langlaufende Prozesse: Ein Vorgang, der über Stunden oder Tage läuft, Zwischenschritte persistiert und nach Unterbrechungen weiterläuft.
  • Verzweigte Entscheidungsbäume: Ein Support-Agent, der je nach Anliegen unterschiedliche Pfade durch unterschiedliche Tools nimmt.

FAQ

Ist LangGraph ein Ersatz für LangChain?
Nein. Beide kommen vom selben Team und arbeiten zusammen. LangChain ist die Bauteil- und Integrationsebene, LangGraph die Orchestrierungs-Runtime darunter. Seit den 1.0-Releases ruft LangChains create_agent intern die LangGraph-Engine auf.
Warum nicht einfach eine eigene Schleife in Python schreiben?
Kannst du — bis du Persistence, Human-in-the-Loop, paralleles Ausführen und Wiederaufnahme nach Abstürzen brauchst. Genau diese produktionskritischen Teile liefert LangGraph fertig, statt dass du sie pro Projekt neu und fehleranfällig baust.
Braucht jeder Agent LangGraph?
Nein. Für einen linearen Ablauf ohne Verzweigung und ohne sitzungsübergreifenden Zustand ist es Überbau. Der Nutzen beginnt bei Schleifen, Verzweigung, Persistence oder Freigabeschritten.
Was ist ein Checkpointer?
Ein Backend, das nach jedem Knoten-Schritt den State speichert. In-Memory für Tests, SQLite oder Postgres für Produktion. Er ermöglicht Wiederaufnahme nach Unterbrechungen, Zeitreise-Debugging und Human-in-the-Loop.
Seit wann ist LangGraph stabil?
LangGraph 1.0 wurde am 22. Oktober 2025 als allgemein verfügbar veröffentlicht — laut Anbieter ohne Breaking Changes gegenüber den späten Vorversionen, im Wesentlichen eine Stabilisierung der bestehenden API.

Fazit

LangGraph beantwortet eine konkrete Frage: Wie baue ich einen Agenten, der nicht nur geradeaus läuft, sondern schleifen, verzweigen, pausieren und nach einem Absturz weitermachen kann? Die Antwort ist der Graph aus Nodes, Edges und einem geteilten State — plus zwei Produktionsfeatures, Persistence und Human-in-the-Loop, die den Unterschied zwischen Prototyp und Live-Betrieb ausmachen.

Die Faustregel zum Mitnehmen: Bleibt dein Ablauf linear, nimm die LangChain-Ebene und spar dir den Graph. Sobald Schleifen, Zustand über Sitzungen oder menschliche Freigaben ins Spiel kommen, ist LangGraph das passende Werkzeug — und seit dem 1.0-Release stabil genug, um darauf zu produzieren.

Themenuebersicht

KI-WerkzeugeAgenten-Frameworks