Wer heute einen KI-Agenten baut, der mehr kann als eine einzelne Frage beantworten, stößt schnell an die Grenzen von linearen Chains. Sobald ein Workflow verzweigt, auf sich selbst zurückgreift oder einen Menschen zur Freigabe braucht, reicht ein simples Prompt-Template nicht mehr aus. Genau für diesen Fall hat das LangChain-Team LangGraph gebaut: ein Open-Source-Framework, das Agenten als Graphen aus Knoten und Kanten modelliert, inklusive Zustand, Persistenz und kontrollierter Unterbrechung. Das Projekt zählt laut GitHub-API-Abfrage vom 16. September 2026 41.776 Sterne und 7.056 Forks und wird unter MIT-Lizenz vertrieben. Dieser Tutorial-Artikel zeigt in 12 Schritten, wie du LangGraph installierst, einen ersten Graphen baust, Zustände persistierst, einen Menschen in den Loop einbindest und am Ende ein funktionierendes Multi-Agenten-System mit Supervisor-Muster zum Laufen bringst.

Der Artikel richtet sich an Python-Entwickler, die bereits mit einer LLM-API gearbeitet haben, aber noch keine mehrstufigen Agenten mit Zustand gebaut haben. Du brauchst keine Vorkenntnisse zu Graphentheorie, alle relevanten Begriffe werden unterwegs erklärt. Am Ende steht ein vollständiges, lauffähiges Projekt mit zwei zusammenarbeitenden Fach-Agenten, das du direkt als Ausgangspunkt für eigene Anwendungsfälle wie Kundensupport, interne Recherche-Bots oder automatisierte Freigabe-Workflows nutzen kannst.

Alle Versionsangaben, Preise und Fakten in diesem Artikel stammen aus direkten Abfragen der GitHub-API, aus den offiziellen PyPI-Paketseiten und aus der offiziellen LangChain-Dokumentation, jeweils mit Stand 16. September 2026. Wo Quellen sich widersprochen haben, etwa bei Detailfragen zur Preisgestaltung der gehosteten Platform, ist das im entsprechenden Abschnitt ausdrücklich vermerkt.

Was ist LangGraph? Einordnung im LangChain-Ökosystem

LangGraph ist eine eigenständige Python- und JavaScript-Bibliothek, die auf GitHub im Repository langchain-ai/langgraph gepflegt wird. Das Repository wurde im August 2023 angelegt und laut Live-Abfrage der GitHub-API zuletzt am 16. September 2026 aktualisiert, die Entwicklung läuft also mit hoher Frequenz weiter. Offiziell beschreibt LangChain das Projekt als Werkzeug zum Bau “resilienter Agenten” (im Original: “Build resilient agents”), und genau das ist der Kern: Wo eine klassische Chain Schritt für Schritt von A nach B läuft, erlaubt LangGraph Zyklen, bedingte Sprünge und dauerhaft gespeicherten Zustand.

Technisch besteht ein LangGraph-Workflow aus drei Bausteinen: Nodes (einzelne Funktionen oder LLM-Aufrufe), Edges (Übergänge zwischen Nodes, die auch bedingt sein können) und einem gemeinsamen State-Objekt, das zwischen den Schritten weitergereicht wird. Darüber legt sich eine Checkpoint-Schicht, die den Zustand nach jedem Schritt sichert. Das macht lange, mehrstufige Agenten-Läufe wiederaufnehmbar, selbst wenn der Prozess zwischendurch abstürzt oder bewusst pausiert wird, etwa weil ein Mensch eine Aktion freigeben muss. Laut den Repository-Beschreibungen ist LangGraph bei Unternehmen wie Klarna, Uber, J.P. Morgan, Replit, Elastic, LinkedIn und GitLab im Einsatz, wobei öffentlich dokumentierte technische Details zu diesen Produktiveinsätzen bislang begrenzt sind.

Der Name ist Programm: Ein Graph in diesem Sinne ist nichts anderes als eine Landkarte möglicher Abläufe. Jeder Knoten steht für eine konkrete Aktion, etwa “rufe das Sprachmodell auf”, “prüfe eine Datenbank” oder “warte auf menschliche Eingabe”. Jede Kante beschreibt, wohin der Ablauf als Nächstes springt, und diese Entscheidung kann von beliebiger Logik abhängen, nicht nur von einer festen Reihenfolge. Dadurch lassen sich Muster abbilden, die mit einer linearen Chain kaum sauber umzusetzen wären, etwa ein Agent, der so lange zwischen “recherchieren” und “bewerten” hin- und herspringt, bis ein Qualitätskriterium erfüllt ist, und erst dann zum nächsten Schritt übergeht.

Neben der Python-Bibliothek pflegt das LangChain-Team parallel das JavaScript-Pendant “langgraphjs”, das dieselben Grundkonzepte für Node.js- und TypeScript-Projekte bereitstellt. Für dieses Tutorial konzentrieren wir uns auf die Python-Variante, weil sie im Data-Science- und Backend-Umfeld in Deutschland und der DACH-Region am weitesten verbreitet ist, die gezeigten Konzepte lassen sich aber nahezu eins zu eins auf das JavaScript-Paket übertragen.

LangGraph vs. LangChain vs. AutoGen vs. CrewAI: Die Unterschiede

LangChain liefert die Bausteine: Prompt-Templates, Modell-Wrapper, Tool-Integrationen. LangGraph setzt eine Ebene darüber und übernimmt die Orchestrierung, also die Frage, welcher Schritt als Nächstes läuft, wie der Zustand aussieht und wie ein abgebrochener Lauf fortgesetzt wird. Wer schon mit LangChain gearbeitet hat, erkennt viele Konzepte wieder, etwa Chat-Modelle oder Tool-Aufrufe, LangGraph fügt aber die Kontrollstruktur hinzu, die LangChain allein nicht bietet.

Im Vergleich zu Microsofts AutoGen oder zu CrewAI verfolgt LangGraph einen bewusst niedrigschwelligen, expliziten Ansatz: Statt Agentenrollen weitgehend automatisch aushandeln zu lassen, definierst du Knoten und Kanten von Hand und behältst die volle Kontrolle über den Programmfluss. CrewAI und AutoGen abstrahieren mehr und sind dadurch für einfache Team-Szenarien schneller aufgesetzt, geraten bei komplexer Verzweigungslogik aber eher an Grenzen. Direkte, öffentlich verifizierte Vergleichszahlen zu Adoption oder Marktanteil zwischen den drei Frameworks liegen aktuell nicht vor, die folgende Tabelle stellt deshalb nur die technischen und lizenzrechtlichen Eckdaten gegenüber, die sich aus den jeweiligen offiziellen Quellen bestätigen lassen.

FrameworkGrundprinzipLizenzZyklen/SchleifenPersistenz/Checkpoints
LangGraphExpliziter Graph aus Nodes und EdgesMITJa, nativJa, eingebaut (InMemorySaver, PostgresSaver, SqliteSaver)
LangChainLineare Chains und Tool-AufrufeMITEingeschränktNicht nativ
CrewAIRollenbasierte Agenten-TeamsMITEingeschränktTeilweise über Zusatzmodule
AutoGenKonversationsbasierte Multi-AgentenMITJa, über GruppendialogeTeilweise

Für die Praxis heißt das: Wenn dein Team bereits LangChain-Komponenten wie Retriever, Tool-Wrapper oder Prompt-Vorlagen im Einsatz hat und nur eine kontrolliertere Ablaufsteuerung fehlt, ist der Umstieg auf LangGraph meist der kleinste Schritt, weil sich bestehender Code größtenteils als Node wiederverwenden lässt. Startest du dagegen bei null und willst mit möglichst wenig Konfigurationsaufwand ein Team aus zwei oder drei Agenten zusammenstellen, kann CrewAI schneller zu einem ersten Ergebnis führen. AutoGen wiederum eignet sich gut, wenn der Workflow im Kern aus einem freien Dialog zwischen mehreren Agenten besteht, etwa bei Code-Review-Szenarien mit mehreren kritischen Gegenstimmen.

Ein häufig unterschätzter Faktor bei der Framework-Wahl ist die Fehlersuche im laufenden Betrieb. Weil LangGraph den Zustand explizit modelliert und über Checkpoints jederzeit einsehbar macht, lässt sich im Nachhinein exakt rekonstruieren, welcher Node zu welchem Zeitpunkt welche Entscheidung getroffen hat. Bei stärker abstrahierten Frameworks, die die Ablaufsteuerung intern verstecken, ist diese Art von Nachvollziehbarkeit oft schwieriger zu erreichen, gerade wenn ein Agent in Produktion ein unerwartetes Verhalten zeigt und du Stunden später herausfinden musst, warum.

Voraussetzungen: Python, Pakete und API-Zugang

Bevor es losgeht, brauchst du eine funktionierende Python-Umgebung und ein paar Pakete. Laut PyPI-Metadaten setzt die aktuelle LangGraph-Version 1.2.11 (veröffentlicht am 11. August 2026) mindestens Python 3.10 voraus, dasselbe gilt für das Kommandozeilen-Werkzeug langgraph-cli in Version 0.4.31 (veröffentlicht am 10. Juli 2026). Für das Beispielprojekt in diesem Artikel verwenden wir zusätzlich langgraph-supervisor in Version 0.0.31 sowie langchain-openai als Modell-Anbindung, du kannst stattdessen aber auch jeden anderen von LangChain unterstützten Provider einsetzen.

  • Python 3.10 oder neuer (offiziell getestete Wheels existieren bis Python 3.13), prüfbar mit “python3 –version”
  • pip oder uv als Paketmanager, beide funktionieren mit den in diesem Artikel gezeigten Befehlen
  • Ein API-Schlüssel für ein LLM, zum Beispiel OpenAI, Anthropic oder ein selbst gehostetes Modell über eine OpenAI-kompatible Schnittstelle
  • Ein Terminal mit Internetzugang für die Installation der Pakete aus PyPI
  • Grundkenntnisse in Python, insbesondere Funktionen, Dictionaries und Type Hints
  • Optional: Docker, falls du später mit “langgraph build” ein Deployment-Image erzeugen willst
  • Optional: eine lokale oder gehostete PostgreSQL-Instanz für den Persistenz-Teil in Schritt 9

Plane für die komplette Einrichtung inklusive erstem Testlauf rund 45 bis 60 Minuten ein, für das vollständige Multi-Agenten-Beispiel am Ende des Artikels kommen noch einmal 20 bis 30 Minuten dazu.

Ein Wort zu den laufenden Kosten während der Entwicklung: Da jeder Testlauf mindestens einen LLM-Aufruf auslöst, summieren sich kleine Beträge pro Anfrage schnell, wenn du den Graphen häufig manuell testest. Es lohnt sich, während der Entwicklungsphase ein günstiges, schnelles Modell zu wählen und erst kurz vor dem Produktivbetrieb auf ein leistungsfähigeres, teureres Modell umzustellen. Da LangGraph die Modellwahl nicht selbst vorgibt, sondern über die jeweilige Chat-Modell-Klasse aus LangChain einbindet, lässt sich dieser Wechsel meist mit einer einzigen Codezeile umsetzen.

Grundkonzepte: Nodes, Edges, State und Checkpoints

Ein LangGraph-Graph besteht aus einem Zustandsobjekt (State), das meist als TypedDict oder als Pydantic-Modell definiert wird. Jeder Node ist eine Python-Funktion, die den aktuellen State entgegennimmt und eine partielle Aktualisierung zurückgibt. Edges verbinden Nodes miteinander, entweder fest oder bedingt über eine Routing-Funktion, die anhand des States entscheidet, welcher Node als Nächstes drankommt. Zwei feste Marker, START und END, markieren Ein- und Ausstiegspunkt des Graphen.

Darüber legt sich der Checkpointer: Er speichert nach jedem Node-Durchlauf eine Momentaufnahme des States unter einer Thread-ID. Dadurch lässt sich ein Lauf später an genau der Stelle fortsetzen, an der er unterbrochen wurde, egal ob wegen eines Absturzes, eines geplanten Stopps oder einer Rückfrage an einen Menschen. Für Entwicklung reicht ein In-Memory-Checkpointer, für den Produktivbetrieb empfiehlt die offizielle Dokumentation einen persistenten Checkpointer wie PostgresSaver, der eigene Tabellen samt Indizes anlegt.

Bedingte Kanten sind der Teil, der LangGraph von einer simplen Abfolge unterscheidet. Statt eine feste Kante von Node A zu Node B zu ziehen, definierst du eine Routing-Funktion, die den aktuellen State liest und den Namen des nächsten Nodes zurückgibt. Ein einfaches Beispiel für eine solche Routing-Funktion, die je nach Inhalt der letzten Nachricht entweder zu einem Tool-Node oder direkt zum Ende springt, sieht so aus:

def route(state: MessagesState) -> str:
    letzte_nachricht = state["messages"][-1]
    if getattr(letzte_nachricht, "tool_calls", None):
        return "tools"
    return END

graph.add_conditional_edges("chat_node", route)

Mit “add_conditional_edges()” kannst du beliebig viele Zielknoten anbinden und die Entscheidung vollständig in Python-Code ausdrücken, inklusive Schleifen, bei denen ein Node wiederholt aufgerufen wird, bis eine Bedingung im State erfüllt ist.

Schritt 1 bis 4: LangGraph installieren und Projekt aufsetzen

Schritt 1: Virtuelle Umgebung anlegen

Lege zuerst ein sauberes Projektverzeichnis mit eigener virtueller Umgebung an, damit sich die Pakete nicht mit anderen Projekten in die Quere kommen.

mkdir langgraph-projekt
cd langgraph-projekt
python3 -m venv .venv
source .venv/bin/activate

Schritt 2: LangGraph und Zusatzpakete installieren

Installiere anschließend das Kernpaket, das CLI-Werkzeug für die lokale Entwicklung sowie die Modell-Anbindung.

pip install -U langgraph
pip install -U "langgraph-cli[inmem]"
pip install -U langchain-openai langgraph-supervisor

Prüfe danach mit “pip show langgraph”, ob wirklich Version 1.2.11 oder neuer installiert wurde. Weicht die Ausgabe stark ab, hilft meist ein “pip install –upgrade –force-reinstall langgraph”.

Schritt 3: API-Schlüssel als Umgebungsvariable setzen

export OPENAI_API_KEY="sk-dein-schluessel-hier"

Unter Windows in PowerShell lautet der Befehl “$env:OPENAI_API_KEY = ‘sk-dein-schluessel-hier'”. Speichere den Schlüssel niemals direkt im Code oder im Git-Repository, sondern nutze eine “.env”-Datei, die in der “.gitignore” steht.

Schritt 4: Projektstruktur anlegen

Lege eine Datei “graph.py” für die Graph-Definition und eine “langgraph.json” für die spätere lokale Entwicklung mit dem CLI-Server an.

{
  "$schema": "https://langgra.ph/schema.json",
  "dependencies": ["."],
  "graphs": {
    "chat": "graph:graph"
  }
}

Schritt 5 bis 8: Den ersten Graphen bauen

Schritt 5: State-Klasse definieren

Für einen einfachen Chat-Agenten reicht die eingebaute Klasse “MessagesState”, die eine Liste von Nachrichten als Zustand verwaltet. Für eigene Anwendungsfälle definierst du stattdessen ein TypedDict mit genau den Feldern, die dein Workflow braucht, zum Beispiel für einen Support-Agenten, der zusätzlich Kundendaten und einen Eskalationsstatus mitführen soll:

from typing import TypedDict, Annotated
from langgraph.graph.message import add_messages

class SupportState(TypedDict):
    messages: Annotated[list, add_messages]
    kunde_id: str
    eskaliert: bool

Das “Annotated”-Feld mit “add_messages” sorgt dafür, dass neue Nachrichten an die bestehende Liste angehängt werden, statt sie zu überschreiben. Ohne diese Reducer-Funktion würde jeder Node-Rückgabewert den kompletten Nachrichtenverlauf ersetzen, was in der Praxis der häufigste Grund für scheinbar “amnesische” Agenten ist.

Schritt 6: Knoten und Kanten anlegen

Der folgende Code zeigt den minimalen Aufbau, wie ihn die offizielle LangGraph-Dokumentation als Einstiegsbeispiel führt: ein StateGraph, ein einzelner Node und zwei feste Kanten von START zum Node und vom Node zu END.

from langgraph.graph import StateGraph, MessagesState, START, END
from langchain_openai import ChatOpenAI

model = ChatOpenAI(model="gpt-4o-mini")

def chat_node(state: MessagesState):
    antwort = model.invoke(state["messages"])
    return {"messages": [antwort]}

graph = StateGraph(MessagesState)
graph.add_node("chat_node", chat_node)
graph.add_edge(START, "chat_node")
graph.add_edge("chat_node", END)
graph = graph.compile()

Schritt 7: Graphen kompilieren und aufrufen

ergebnis = graph.invoke(
    {"messages": [{"role": "user", "content": "Was ist LangGraph in einem Satz?"}]}
)
print(ergebnis["messages"][-1].content)

Die Ausgabe sieht in etwa so aus:

LangGraph ist ein Open-Source-Framework, mit dem sich zustandsbehaftete,
mehrstufige KI-Agenten als Graph aus Knoten und Kanten modellieren lassen.

Für Anwendungen, bei denen Nutzer nicht auf die komplette Antwort warten sollen, bietet sich statt “invoke()” die Streaming-Variante an. Sie liefert die Ausgabe jedes einzelnen Nodes, sobald er fertig ist, statt erst am Ende des gesamten Graph-Laufs.

for schritt in graph.stream(
    {"messages": [{"role": "user", "content": "Erkläre Checkpointing kurz."}]}
):
    print(schritt)

Jeder ausgegebene Schritt enthält den Namen des zuletzt ausgeführten Nodes zusammen mit dessen partieller State-Aktualisierung, sodass sich eine Chat-Oberfläche Wort für Wort oder zumindest Node für Node befüllen lässt, statt den Nutzer auf eine stumme Wartezeit zu vertrösten.

Schritt 8: Lokalen Dev-Server starten

Mit dem CLI-Befehl “langgraph dev” startest du einen leichten lokalen Server, standardmäßig auf Port 2024 unter 127.0.0.1. Über “–port” und “–host” lässt sich das anpassen, mit “–no-reload” deaktivierst du den automatischen Neustart bei Codeänderungen.

langgraph dev --port 2024

Läuft alles korrekt, meldet das Terminal, dass der Server erreichbar ist, und öffnet in der Regel automatisch eine lokale Oberfläche im Browser, über die du einzelne Graph-Läufe Schritt für Schritt nachvollziehen kannst. Das ist beim Debuggen deutlich angenehmer als reine Konsolen-Logs, weil du auf einen Blick siehst, welcher Node zuletzt ausgeführt wurde und wie der State an dieser Stelle aussah.

Schritt 9 und 10: Persistenz und Checkpointing einrichten

Schritt 9: Checkpointer einbinden

Damit ein Graph seinen Zustand über mehrere Aufrufe hinweg behält, brauchst du einen Checkpointer. Für lokale Tests genügt “InMemorySaver”, für den Produktivbetrieb nennt die Dokumentation “PostgresSaver” und die asynchrone Variante “AsyncPostgresSaver” als empfohlene Optionen, daneben existiert “SqliteSaver” für dateibasierte Speicherung während der Entwicklung.

from langgraph.checkpoint.memory import InMemorySaver

checkpointer = InMemorySaver()
graph = builder.compile(checkpointer=checkpointer)

Für den Wechsel auf eine echte PostgreSQL-Datenbank installierst du zusätzlich das passende Zusatzpaket und rufst einmalig “setup()” auf, bevor der erste produktive Lauf startet. Dieser Schritt wird in der Praxis häufig vergessen und führt dann zu Verbindungsfehlern, weil die notwendigen Tabellen schlicht noch nicht existieren.

pip install -U "langgraph-checkpoint-postgres" psycopg[binary]
from langgraph.checkpoint.postgres import PostgresSaver

DB_URI = "postgresql://user:passwort@localhost:5432/langgraph"

with PostgresSaver.from_conn_string(DB_URI) as checkpointer:
    checkpointer.setup()
    graph = builder.compile(checkpointer=checkpointer)

Achte darauf, “setup()” wirklich nur einmalig auszuführen, etwa in einem separaten Migrations-Skript, statt es bei jedem Anwendungsstart erneut aufzurufen. Auf einer produktiven Datenbank mit bereits laufendem Betrieb kann ein wiederholter Aufruf zu unnötigen Sperren auf den betroffenen Tabellen führen.

Schritt 10: Mit Thread-ID aufrufen und fortsetzen

Jeder Aufruf, der denselben Zustand teilen soll, braucht dieselbe “thread_id” in der Konfiguration. So kannst du eine Unterhaltung später exakt dort fortsetzen, wo sie stehen geblieben ist.

config = {"configurable": {"thread_id": "kunde-482"}}

graph.invoke(
    {"messages": [{"role": "user", "content": "Hallo, ich heiße Sabine."}]},
    config,
)

graph.invoke(
    {"messages": [{"role": "user", "content": "Wie war noch mal mein Name?"}]},
    config,
)

Beim zweiten Aufruf lädt LangGraph automatisch den gespeicherten Verlauf zur Thread-ID “kunde-482” und der Agent kann den Namen korrekt wiedergeben, ohne dass du die vorherige Nachricht erneut mitschicken musst.

Schritt 11: Human-in-the-Loop mit interrupt() und Command

Für Aktionen, die eine menschliche Freigabe brauchen, etwa eine Zahlung oder eine Löschoperation, bietet LangGraph die Funktion “interrupt()” und das Objekt “Command”. Ruft ein Node “interrupt()” auf, pausiert der Graph an genau dieser Stelle, der übergebene Wert wird an die aufrufende Anwendung zurückgegeben, und der Zustand bleibt über den Checkpointer erhalten, bis jemand die Ausführung fortsetzt.

from langgraph.types import interrupt, Command
from langgraph.checkpoint.memory import InMemorySaver
from langgraph.graph import StateGraph, START, END
from typing import TypedDict

class State(TypedDict):
    freigegeben: bool

def freigabe_node(state: State):
    entscheidung = interrupt("Soll diese Zahlung ausgeführt werden?")
    return {"freigegeben": entscheidung}

builder = StateGraph(State)
builder.add_node("freigabe", freigabe_node)
builder.add_edge(START, "freigabe")
builder.add_edge("freigabe", END)

graph = builder.compile(checkpointer=InMemorySaver())
config = {"configurable": {"thread_id": "zahlung-1"}}

graph.invoke({"freigegeben": False}, config)
# Graph pausiert hier und wartet auf Freigabe

graph.invoke(Command(resume=True), config)
# {'freigegeben': True}

Der Wert, den du an “Command(resume=…)” übergibst, wird laut offizieller Dokumentation zum Rückgabewert des ursprünglichen “interrupt()”-Aufrufs. Das ergibt ein sauberes Freigabe-Muster, ohne dass du eigene Warteschlangen oder Polling-Logik bauen musst.

Schritt 12: Multi-Agenten-System mit Supervisor-Muster bauen

Der letzte Schritt kombiniert alles zu einem vollständigen Projekt: ein Supervisor-Agent verteilt Anfragen an zwei spezialisierte Fach-Agenten. In der offiziellen Dokumentation heißt es dazu, ein gängiger Weg für komplexe Aufgaben sei “ein Teile-und-herrsche-Ansatz: für jede Aufgabe oder Domäne einen spezialisierten Agenten anlegen und Aufgaben an den richtigen Experten weiterleiten” (im Original: “create a specialized agent for each task or domain and route tasks to the correct expert”). Die dazu passende Zusatzbibliothek heißt “langgraph-supervisor”, aktuell in Version 0.0.31 verfügbar über PyPI.

Neben dem Supervisor-Muster, bei dem ein zentraler Agent die Kontrolle behält und Aufgaben gezielt weiterreicht, kennt die offizielle Dokumentation auch das sogenannte Netzwerk-Muster, bei dem jeder Agent direkt mit jedem anderen kommunizieren kann, ohne einen zentralen Koordinator. Für die meisten praktischen Anwendungsfälle, etwa Kundensupport oder interne Recherche-Tools, ist der Supervisor-Ansatz einfacher zu verstehen und zu debuggen, weil der Kontrollfluss an einer einzigen Stelle sichtbar bleibt, statt sich über viele Peer-to-Peer-Verbindungen zu verteilen. Aus diesem Grund konzentriert sich das folgende Beispiel auf das Supervisor-Muster.

from langchain_openai import ChatOpenAI
from langgraph_supervisor import create_supervisor
from langgraph.prebuilt import create_react_agent

model = ChatOpenAI(model="gpt-4o-mini")

def rechnen(a: float, b: float) -> float:
    """Addiert zwei Zahlen."""
    return a + b

def websuche(anfrage: str) -> str:
    """Simuliert eine Websuche."""
    return f"Suchergebnisse zu: {anfrage}"

mathe_agent = create_react_agent(
    model=model,
    tools=[rechnen],
    name="mathe_experte",
    prompt="Du bist Mathe-Experte. Nutze pro Schritt immer nur ein Werkzeug.",
)

recherche_agent = create_react_agent(
    model=model,
    tools=[websuche],
    name="recherche_experte",
    prompt="Du bist Recherche-Experte mit Zugriff auf eine Websuche.",
)

workflow = create_supervisor(
    [recherche_agent, mathe_agent],
    model=model,
    prompt="Du bist Team-Supervisor und koordinierst einen Recherche- und einen Mathe-Experten.",
)

app = workflow.compile()

ergebnis = app.invoke({
    "messages": [
        {"role": "user", "content": "Addiere 17 und 25 und recherchiere danach den Begriff LangGraph."}
    ]
})
print(ergebnis["messages"][-1].content)

Beim Ausführen erkennst du im Log, dass der Supervisor zuerst an “mathe_experte” weiterleitet, das Ergebnis 42 zurückbekommt und anschließend an “recherche_experte” übergibt, bevor er eine zusammenfassende Antwort formuliert. Genau dieses Routing-Verhalten beschreibt die LangGraph-Dokumentation zum Supervisor-Muster: “Du kannst die langgraph-supervisor-Bibliothek nutzen, um Supervisor-Multi-Agenten-Systeme zu erstellen” (im Original: “You can use langgraph-supervisor library to create a supervisor multi-agent systems”). Damit hast du ein vollständig lauffähiges Multi-Agenten-Projekt, das du um weitere Fach-Agenten, eigene Tools und einen persistenten Checkpointer erweitern kannst.

Projektstruktur und Abhängigkeiten im Überblick

Für ein sauberes, reproduzierbares Setup solltest du die Abhängigkeiten des Projekts in einer “requirements.txt” festhalten, statt sie nur lose in der virtuellen Umgebung zu installieren. Damit lässt sich das Projekt später auf einem anderen Rechner oder in einem Docker-Image mit einem einzigen Befehl wiederherstellen.

langgraph>=1.2.11
langgraph-cli[inmem]>=0.4.31
langgraph-supervisor>=0.0.31
langchain-openai
python-dotenv

Die vollständige Verzeichnisstruktur des Beispielprojekts aus diesem Tutorial sieht damit so aus, mit “graph.py” als Einstiegspunkt für den lokalen Dev-Server und einer getrennten “.env”-Datei für Geheimnisse:

langgraph-projekt/
├── .venv/
├── .env
├── requirements.txt
├── langgraph.json
└── graph.py

Mit “pip install -r requirements.txt” in einer frischen virtuellen Umgebung ist das komplette Projekt reproduzierbar, und mit “langgraph dev” lässt es sich sofort lokal testen, bevor du es später über “langgraph build” als Docker-Image für die Produktion packst.

LangGraph Platform und Cloud-Deployment: Preise im Überblick

Für den Betrieb im großen Stil bietet LangChain die gehostete LangGraph Platform an. Laut einer aktuellen Preisanalyse von CostBench liegt die Spanne bei 0,005 bis 1,50 US-Dollar pro Sitz und Monat zuzüglich Nutzung, gestaffelt in drei Stufen: Developer, Plus und Enterprise. Der Plus-Tarif startet demnach bei 39 US-Dollar pro Sitz und Monat plus Verbrauch, der Enterprise-Tarif wird individuell verhandelt. Zur Einordnung: Bei 25 Sitzen im Plus-Tarif kämen laut derselben Analyse rund 975 US-Dollar Grundgebühr pro Monat zusammen, bevor überhaupt Nutzungskosten anfallen.

Zu den nutzungsabhängigen Kosten zählt CostBench unter anderem 0,001 US-Dollar pro ausgeführtem Node, Standby-Gebühren von 0,0007 US-Dollar pro Minute für Entwicklungs-Deployments und 0,0036 US-Dollar pro Minute für Produktiv-Deployments, sowie 2,50 US-Dollar pro 1.000 zusätzlichen LangSmith-Traces. Zu den Angaben, ob es einen dauerhaft kostenlosen Developer-Plan gibt, widersprechen sich zwei Quellen derselben Analysefirma teilweise, weshalb Teams die tagesaktuelle Preisseite von LangChain direkt prüfen sollten, bevor sie größere Deployments planen.

TarifStartpreisZielgruppe
DeveloperAb 0 $ (nutzungsbasiert, laut CostBench teils als kostenlos gelistet)Einzelentwickler, Prototypen
PlusAb 39 $ pro Sitz/Monat + NutzungKleine bis mittlere Teams
EnterpriseIndividuelles AngebotGroße Organisationen mit Compliance-Anforderungen

Wer die Kosten der Cloud-Plattform umgehen will, kann mit “langgraph build” ein eigenes Docker-Image erzeugen und es auf eigener Infrastruktur betreiben. Für lokale Tests mit Docker steht zusätzlich der Befehl “langgraph up” bereit, für den Produktivbetrieb außerhalb der eigenen Testumgebung verlangt LangChain dafür allerdings einen Lizenzschlüssel.

Häufige Fehler und Stolperfallen bei LangGraph

  • Fehlender Checkpointer bei Multi-Turn-Gesprächen: Ohne “checkpointer” beim “compile()”-Aufruf vergisst der Graph nach jedem Invoke den kompletten Verlauf, weil kein Zustand gespeichert wird. Das äußert sich meist so, dass ein Agent bei der zweiten Nachricht plötzlich so reagiert, als hätte das Gespräch gerade erst begonnen.
  • Gleiche Thread-ID für verschiedene Nutzer: Wird dieselbe “thread_id” für mehrere Kunden verwendet, vermischen sich deren Gesprächsverläufe im selben Zustand, was in der Praxis zu falschen Antworten und im schlimmsten Fall zu einem Datenschutzproblem führt, wenn Nutzer A Informationen aus dem Gespräch von Nutzer B zu sehen bekommt.
  • State-Typen, die sich nicht serialisieren lassen: Objekte wie offene Datei-Handles oder Datenbankverbindungen im State sorgen dafür, dass der Checkpointer beim Speichern fehlschlägt, weil er den Zustand nicht in ein persistierbares Format bringen kann. Halte den State deshalb auf einfache, serialisierbare Typen wie Strings, Zahlen, Listen und Dictionaries beschränkt.
  • Fehlende bedingte Kanten: Wer nur feste “add_edge()”-Verbindungen nutzt, obwohl der Workflow eigentlich verzweigen soll, baut versehentlich lineare Chains statt echter Graphen und verschenkt den Hauptvorteil von LangGraph gegenüber einer einfachen Kette von Funktionsaufrufen.
  • interrupt() ohne Checkpointer: Der Aufruf von “interrupt()” funktioniert nur zuverlässig, wenn ein Checkpointer konfiguriert ist, sonst lässt sich der pausierte Lauf nach einem Neustart der Anwendung nicht mehr fortsetzen und der State geht komplett verloren.
  • Veraltete langgraph-cli-Version: Da sich das Format der “langgraph.json” zwischen Versionen leicht ändert, führt eine veraltete CLI-Version häufig zu kryptischen Schema-Fehlern beim Start von “langgraph dev”, obwohl der eigentliche Python-Code fehlerfrei ist.
  • Kostenfalle bei der Platform: Wer die nutzungsbasierten Gebühren für Node-Ausführungen und Standby-Zeit ignoriert, wird bei produktiven Deployments mit vielen kurzen Läufen von der monatlichen Rechnung überrascht, besonders wenn viele Graphen lange auf menschliche Freigaben warten.
  • Zu große, monolithische Nodes: Wer sehr viel Logik in einen einzigen Node packt, statt sie auf mehrere kleine, klar benannte Nodes zu verteilen, verliert den Übersichtsvorteil eines Graphen und erschwert sich das Debugging im Studio-Interface erheblich.

Fehlerbehebung: Die wichtigsten Troubleshooting-Fälle

Die meisten Probleme beim Einstieg in LangGraph lassen sich auf drei Ursachen zurückführen: eine fehlende oder falsch konfigurierte Checkpointer-Instanz, eine veraltete Paketversion, oder eine Routing-Funktion, die nicht alle möglichen State-Kombinationen abdeckt. Bevor du tief in die Fehlersuche einsteigst, lohnt sich deshalb immer zuerst ein Blick auf die installierten Versionen mit “pip list | grep langgraph” und ein Abgleich mit den Mindestanforderungen aus dem Abschnitt zu den Voraussetzungen. Die folgende Tabelle sammelt die Fehlerbilder, auf die Entwickler beim Einstieg in LangGraph am häufigsten stoßen, zusammen mit der wahrscheinlichsten Ursache und einer konkreten Lösung.

ProblemWahrscheinliche UrsacheLösung
Graph “vergisst” vorherige NachrichtenKein Checkpointer beim compile() übergeben“checkpointer=InMemorySaver()” oder persistenten Checkpointer ergänzen
“langgraph dev” startet nichtExtra “inmem” fehlt oder falsche Python-Version“pip install -U ‘langgraph-cli[inmem]'” ausführen, Python-Version mit “python –version” prüfen
Schema-Fehler beim Laden der langgraph.jsonVeraltetes CLI oder falscher Pfad im Feld “graphs”CLI aktualisieren, Pfad im Format “datei:variable” korrigieren
interrupt() setzt Lauf nicht fortAndere oder fehlende thread_id beim Resume-AufrufExakt dieselbe “thread_id” wie beim ursprünglichen Aufruf verwenden
Supervisor leitet nicht an den richtigen Agenten weiterUnklare oder zu allgemeine Prompt-Beschreibung der AgentenNamen und Prompt jedes Agenten im create_react_agent präziser formulieren
ImportError bei langgraph.typesZu alte installierte langgraph-Version“pip install –upgrade langgraph” auf Version 1.2.11 oder neuer
PostgresSaver-Verbindung schlägt fehlsetup() wurde nicht einmalig ausgeführt“checkpointer.setup()” einmal vor dem ersten produktiven Lauf aufrufen
Hohe, unerwartete Rechnung auf der LangGraph PlatformViele kurze Standby-Zeiten oder unnötige Node-DurchläufeGraphen straffen, unnötige Zwischen-Nodes entfernen, Nutzung im Dashboard prüfen

Erweiterte Tipps für den Produktionseinsatz

Sobald ein Graph den Prototyp-Status verlässt, lohnt sich der Wechsel von “InMemorySaver” zu “PostgresSaver” oder der asynchronen Variante “AsyncPostgresSaver”, damit Zustände einen Neustart der Anwendung überstehen. Rufe dazu vor dem ersten Produktivlauf einmalig die “setup()”-Methode auf, sie legt laut Dokumentation die notwendigen Tabellen samt Indizes an.

Für Multi-Agenten-Systeme mit mehr als zwei oder drei Fach-Agenten zahlt es sich aus, jeden Agenten mit einem eng begrenzten Werkzeugsatz und einer klaren, kurzen Rollenbeschreibung auszustatten. Ein Supervisor trifft bessere Routing-Entscheidungen, wenn die Namen der Agenten eindeutig sind, etwa “rechnungs_experte” statt allgemein “agent_2”. Teste außerdem regelmäßig, wie sich dein Graph verhält, wenn ein einzelner Node eine Ausnahme wirft, denn ohne eigene Fehlerbehandlung bricht standardmäßig der gesamte Lauf ab, statt an der fehlgeschlagenen Stelle sauber zu pausieren.

Wer auf die gehostete Platform setzt, sollte die Standby-Gebühren im Blick behalten: Ein Graph, der lange auf eine menschliche Freigabe per “interrupt()” wartet, läuft in der Zwischenzeit nicht kostenlos, sondern erzeugt laut CostBench-Analyse fortlaufende Standby-Kosten. Für Workflows mit langen Wartezeiten kann es günstiger sein, den pausierten Zustand aus dem Checkpointer auszulesen und den eigentlichen Graphen erst bei tatsächlichem Bedarf neu zu starten.

Ein weiterer Punkt, der sich in größeren Projekten auszahlt, ist eine konsequente Trennung zwischen Fachlogik und Orchestrierung. Halte die eigentlichen Tool-Funktionen, etwa Datenbankzugriffe oder externe API-Aufrufe, in eigenen Modulen fest und binde sie nur über “create_react_agent()” oder direkte Node-Funktionen in den Graphen ein. So lassen sich einzelne Tools isoliert testen, ohne jedes Mal den kompletten Graphen mit einem echten LLM-Aufruf durchlaufen zu müssen, was sowohl die Testzeit als auch die API-Kosten während der Entwicklung spürbar senkt.

Teststrategie für Graphen mit vielen Zweigen

Bei Graphen mit mehreren bedingten Kanten reicht ein einzelner End-to-End-Test selten aus, um alle möglichen Pfade abzudecken. Teste stattdessen jede Routing-Funktion isoliert mit synthetischen State-Objekten, ohne den umgebenden Graphen überhaupt aufzurufen. Das prüft die eigentliche Verzweigungslogik direkt und ohne die Unsicherheit eines echten LLM-Aufrufs, dessen Ausgabe von Lauf zu Lauf leicht variieren kann.

def test_route_zu_tools():
    fake_state = {"messages": [FakeMessageMitToolCall()]}
    assert route(fake_state) == "tools"

def test_route_zu_ende():
    fake_state = {"messages": [FakeMessageOhneToolCall()]}
    assert route(fake_state) == END

Erst wenn die einzelnen Routing-Funktionen und Nodes für sich genommen zuverlässig funktionieren, lohnt sich ein zusätzlicher End-to-End-Test mit einem echten oder gemockten Modell, der den kompletten Graphen einmal von START bis END durchspielt.

Monitoring und Nachvollziehbarkeit im Betrieb

Sobald ein Agent produktiv läuft, reicht es nicht mehr, Fehler nur im lokalen Terminal zu beobachten. Die LangGraph Platform bringt dafür eine Anbindung an LangSmith mit, über die sich jeder einzelne Node-Durchlauf als Trace nachvollziehen lässt, inklusive der genauen Eingabe und Ausgabe jedes Schritts. Wie weiter oben beschrieben, ist diese Trace-Aufzeichnung ab einer bestimmten Menge kostenpflichtig, weshalb es sich lohnt, in der Entwicklungsphase mit Stichproben statt mit lückenloser Aufzeichnung zu arbeiten und erst im produktiven Betrieb auf vollständiges Tracing umzustellen, wenn die Kosten dafür eingeplant sind. Wer komplett ohne die gehostete Plattform arbeitet, kann alternativ eigene Logging-Hooks an jedem Node ansetzen und die State-Übergänge in ein bestehendes Log- oder Observability-System der eigenen Infrastruktur schreiben.

LangGraph in der Praxis: Wer setzt es ein?

Die offizielle LangGraph-Dokumentation und das zugehörige JavaScript-Repository “langgraphjs” nennen mehrere namhafte Unternehmen als Nutzer des Frameworks, darunter Klarna, Uber, J.P. Morgan, Replit, Elastic, LinkedIn und GitLab. Detaillierte, öffentlich einsehbare Fallstudien mit konkreten Architekturen oder Kennzahlen liegen zu diesen Einsätzen bislang nicht vor, die Nennungen stammen aus den “Trusted by”-Abschnitten der jeweiligen Projektseiten.

Für deutsche und europäische Teams ist vor allem der Selbsthosting-Weg über “langgraph build” interessant, weil sich damit Modelle und Daten vollständig in der eigenen oder einer EU-Cloud-Umgebung betreiben lassen, ohne auf die US-gehostete Platform angewiesen zu sein. Gerade bei Anwendungsfällen mit Kundendaten oder regulatorischen Anforderungen ist das häufig der ausschlaggebende Punkt für die Entscheidung zwischen Self-Hosting und gehosteter Platform.

Typische Einsatzfelder, die sich in Projekten und Diskussionen rund um das Framework wiederholt zeigen, sind mehrstufige Kundensupport-Agenten, die zwischen Wissensdatenbank-Recherche und Eskalation an einen Menschen wechseln, interne Recherche-Assistenten, die mehrere Datenquellen nacheinander abfragen und die Ergebnisse zusammenfassen, sowie Freigabe-Workflows im Finanz- und Rechtsbereich, bei denen jede kritische Aktion erst nach expliziter menschlicher Bestätigung ausgeführt werden darf. In all diesen Fällen ist der entscheidende Vorteil gegenüber einer einfachen Chain nicht die reine Textgenerierung, sondern die zuverlässige Steuerung, wann welcher Schritt läuft und wann eine Unterbrechung nötig ist.

Häufig gestellte Fragen zu LangGraph

Zum Abschluss die Fragen, die bei der Einarbeitung in LangGraph am häufigsten aufkommen, kurz und konkret beantwortet.

Ist LangGraph kostenlos?

Das Kernframework ist unter MIT-Lizenz quelloffen und kostenlos nutzbar, auch im Selbsthosting-Betrieb über ein eigenes Docker-Image. Kosten entstehen erst, wenn du die gehostete LangGraph Platform nutzt, dort startet der Plus-Tarif laut CostBench bei 39 US-Dollar pro Sitz und Monat zuzüglich Nutzung. Zusätzlich fallen natürlich die üblichen API-Kosten des jeweiligen LLM-Anbieters an, unabhängig davon, ob du LangGraph selbst hostest oder die Platform nutzt.

Brauche ich LangChain, um LangGraph zu nutzen?

Nein, LangGraph lässt sich auch unabhängig von LangChain einsetzen. In der Praxis kombinieren die meisten Projekte aber beide Bibliotheken, weil LangChain die Modell- und Tool-Anbindungen liefert, die LangGraph als Nodes einbindet.

Welche Python-Version brauche ich mindestens?

Laut PyPI-Metadaten der aktuellen Version 1.2.11 wird mindestens Python 3.10 vorausgesetzt, offizielle Wheels existieren bis einschließlich Python 3.13.

Wie unterscheidet sich LangGraph von einer klassischen LangChain-Chain?

Eine klassische Chain läuft linear von Schritt zu Schritt. LangGraph erlaubt zusätzlich Zyklen, bedingte Verzweigungen, dauerhaften Zustand über einen Checkpointer sowie geplante Unterbrechungen für menschliche Freigaben, was für komplexere Agenten-Workflows in der Regel notwendig ist.

Kann ich LangGraph ohne die gehostete Platform in Produktion betreiben?

Ja. Mit “langgraph build” erzeugst du ein eigenständiges Docker-Image, das sich auf jeder Infrastruktur betreiben lässt, die Docker unterstützt. Für den lokalen Testlauf mit Docker steht zusätzlich “langgraph up” bereit.

Was ist der Unterschied zwischen InMemorySaver und PostgresSaver?

“InMemorySaver” hält den Zustand nur im Arbeitsspeicher des laufenden Prozesses und geht bei einem Neustart verloren, eignet sich also für Entwicklung und Tests. “PostgresSaver” schreibt den Zustand dauerhaft in eine PostgreSQL-Datenbank und wird von der Dokumentation für den Produktivbetrieb empfohlen.

Eignet sich langgraph-supervisor auch für mehr als zwei Fach-Agenten?

Ja, “create_supervisor()” nimmt eine Liste beliebig vieler Agenten entgegen. In der Praxis lohnt es sich ab etwa vier oder fünf Fach-Agenten, zusätzlich über hierarchische Supervisor-Strukturen nachzudenken, bei denen ein übergeordneter Supervisor mehrere Teil-Supervisor-Graphen koordiniert, statt einen einzigen Supervisor mit allen Agenten gleichzeitig zu überladen.

Läuft LangGraph auch mit lokal gehosteten, offenen Modellen?

Ja. Da LangGraph die Modellanbindung über die jeweilige LangChain-Chat-Modell-Klasse einbindet, funktioniert es grundsätzlich mit jedem Modell, für das eine solche Klasse existiert, einschließlich lokal über eine OpenAI-kompatible Schnittstelle bereitgestellter offener Modelle. Für den produktiven Einsatz solltest du vorher prüfen, ob das gewählte Modell zuverlässig strukturierte Tool-Aufrufe erzeugt, da Multi-Agenten-Muster wie der Supervisor-Ansatz darauf angewiesen sind.