LangChain vs LangGraph: Welche Architektur passt?

LangChain vs LangGraph: Was passt zur Anwendung?

LangChain eignet sich für eine konfigurierbare Agentenschleife. LangGraph direkt einzusetzen lohnt sich, wenn der Prozess um diese Schleife herum selbst gestaltet werden muss. Entscheidend ist, wer den nächsten Schritt bestimmt, welcher Zustand eine Unterbrechung überstehen muss und welche Betriebsaufgaben das eigene Team übernehmen will.

Für einen neuen Supportassistenten, der Bestellungen abfragt und Fragen beantwortet, bietet sich LangChains create_agent an. Modell, Tools und Anweisungen werden vorgegeben; die Agentenabstraktion übernimmt den wiederholten Wechsel zwischen Modell und Tools. Regeln oder Freigabeprüfungen lassen sich über Middleware ergänzen – also Code, der rund um diese Interaktion ausgeführt wird.

Eine bestehende LangChain-Anwendung sollte bleiben, solange sich keine konkrete Workflow-Anforderung benennen lässt, die mit dieser Abstraktion umständlich abzubilden ist. Ein Gesprächsgedächtnis oder die Prüfung eines vorgeschlagenen Tool-Aufrufs reicht als Begründung allein nicht aus: Aktuelle LangChain-Agenten bieten für beides Funktionen auf Basis von LangGraph. Dokumentation zu LangChain-Agenten.

Muss eine Anwendung eine Anfrage validieren, Nachweise sammeln, auf eine zuständige Person warten, eine genehmigte Aktion ausführen und anschließend das Ergebnis abgleichen, kommt ein eigener LangGraph-Workflow infrage. Diese Phasen lassen sich als ausdrückliche Geschäftsregeln modellieren. Innerhalb einer Phase kann ein Agent die flexibel zu lösenden Aufgaben übernehmen.

Die Nutzungsbedingungen der Bibliotheken stehen auf den Produktseiten von LangChain und LangGraph. Der Funktionsvergleich stützt sich auf die Laufzeitübersicht und die Dokumentation zur Freigabe-Middleware des Anbieters. Die Empfehlung betrifft die Architektur; sie ist keine Rangliste nach Geschwindigkeit.

Welche Aufgaben übernehmen LangChain und LangGraph heute?

LangChain liefert Komponenten und die Agentenabstraktion; LangGraph stellt die darunterliegende Laufzeitumgebung für zustandsbehaftete Orchestrierung bereit. Wer beide als konkurrierende Ersatzlösungen betrachtet, schafft unnötigen Migrationsaufwand.

LangChain: die konfigurierbare Agentenschicht

LangChain beschreibt create_agent als „minimales, hochgradig konfigurierbares Gerüst“. Gemeint ist die Infrastruktur um das Modell herum: Anweisungen, aufrufbare Tools und Möglichkeiten, das Verhalten zu steuern. Dieselbe Übersicht hält ausdrücklich fest: „Die Agenten von LangChain bauen auf LangGraph auf.“ LangChain-Übersicht.

Der Vorteil liegt in einer brauchbaren Ausgangsstruktur. Bei einem Supportassistenten für Bestellungen lässt sich eine vorhandene Abfragefunktion als Tool bereitstellen und ihr Einsatz durch Regeln eingrenzen. Die Arbeit am Produkt kann beginnen, ohne zuvor die Schleife von Hand zu bauen.

Die Grenze liegt darin, wie gut diese Struktur zur Aufgabe passt. Ein länger laufender Vorgang mit benannten Geschäftsphasen kann unübersichtlich werden, wenn jeder Übergang in Prompts, Tool-Konventionen und Middleware verborgen ist. Das ist eine Frage der Wartbarkeit; es bedeutet nicht, dass LangChain-Agenten weder verzweigen noch Zustand speichern könnten. Die Bibliothek ist kostenlos. Modellzugriff und die gewählte Infrastruktur verursachen davon unabhängige Kosten.

LangGraph: die Workflow-Laufzeitumgebung unter eigener Kontrolle

LangGraph bezeichnet sich als „Orchestrierungsframework und Laufzeitumgebung auf niedriger Abstraktionsebene“ für langlebige, zustandsbehaftete Agenten. Ein Knoten ist eine Arbeitseinheit, eine Kante bestimmt den nächsten Ausführungsschritt, und der Zustand enthält die Informationen, die zwischen diesen Schritten weitergegeben werden. Klassische Anwendungslogik lässt sich mit modellgesteuerten Entscheidungen kombinieren. LangGraph-Übersicht.

LangGraph spielt seine Stärke aus, wenn der Workflow selbst Teil des Produkts ist. Ein Modell kann etwa einen Antwortentwurf erstellen, während Anwendungscode entscheidet, ob eine Freigabe nötig ist und ob die genehmigte Aktion bereits ausgeführt wurde.

Die Grenze ist die eigene Verantwortung. Zustand, Übergänge und Fehlerverhalten müssen sinnvoll entworfen werden. Ein Graph mit unklaren Abgrenzungen bleibt unübersichtliche Software. Auch LangGraph ist eine kostenlose Bibliothek und lässt sich ohne LangChain einsetzen. Dessen Modell- und Tool-Komponenten weiterzuverwenden ist jedoch oft praktisch.

Ein praktikabler Mittelweg ist ein LangChain-Agent innerhalb eines größeren Prozesses. Die nützliche Abstraktion für flexible Tool-Aufgaben bleibt erhalten; die umgebende Geschäftsabfolge wird nur dort ausdrücklich modelliert, wo es nötig ist.

LangChain-Agenten oder LangGraph: Wo liegt die Kontrolle?

LangChain bietet Komfort innerhalb der Agentenschleife; LangGraph ermöglicht explizite Kontrolle über mehrere Geschäftsphasen hinweg. Dauerhafte Zustandsverwaltung und menschliche Prüfungen gehören zu den gemeinsamen Fähigkeiten. Entscheidend bleibt ihre Konfiguration.

Agentenschleifen und Tool-Freigaben: Vorteil LangChain

Ein Assistent, der eine Bestellung liest, ihren Status erklärt und eine Antwort vorschlägt, passt zur Modell-Tool-Schleife. Das gilt auch, wenn die Antwort vor dem Versand durch ein Tool geprüft werden soll: HumanInTheLoopMiddleware kann konfigurierte Tool-Aufrufe anhalten und eine Freigabe, bearbeitete Argumente oder eine Ablehnung entgegennehmen. Den unterbrochenen Zustand hält die Persistenz von LangGraph fest. Dokumentation zur menschlichen Prüfung.

Für eine bestehende LangChain-Anwendung ergibt sich daraus ein überschaubarer nächster Schritt: Freigaberegeln und einen persistenten Checkpointer konfigurieren und anschließend die ausstehende Entscheidung in die Anwendung einbinden. Die Middleware erstellt weder eine Oberfläche für offene Prüfungen noch legt sie fest, welcher Mitarbeiter freigeben darf. Beides bleibt Aufgabe der Anwendung.

Explizite Geschäftsphasen: Vorteil LangGraph

Ein eigener Graph eignet sich, wenn sich der richtige nächste Schritt aus dem Geschäftsvorgang ergibt und nicht aus dem nächsten Tool-Vorschlag des Modells. Ein Beispiel ist die Aufnahme eines neuen Lieferanten: Nachweise sammeln, Pflichtfelder validieren, einen Ausnahmefall an eine zuständige Person weiterleiten und den Lieferanten erst nach der Freigabe aktivieren.

Ein Graph kann diese Übergänge unmittelbar abbilden. Der Knoten zum Sammeln der Nachweise darf weiterhin einen LangChain-Agenten aufrufen. Validierung und Aktivierung können gewöhnliche Funktionen mit klar definierten Ergebnissen sein. Der entscheidende Unterschied ist hier LangGraphs dokumentierte Fähigkeit, deterministische und agentengesteuerte Schritte zu verbinden. LangGraph-Übersicht.

Für den Wechsel gilt eine konkrete Regel: Eine Abstraktionsebene tiefer zu gehen lohnt sich, wenn explizite Zustände und Übergänge wiederkehrende Unklarheiten darüber beseitigen, was die Anwendung als Nächstes tun darf. Ein längerer Prompt, zusätzliche Tools oder eine langsame Modellantwort begründen diesen Bedarf allein noch nicht.

Dauerhafte Ausführung: gemeinsame Grundlage, unterschiedlicher Entwurfsaufwand

Ein Checkpointer speichert den Workflow-Zustand eines Threads, damit die Ausführung später fortgesetzt werden kann. Ein Store hält von der Anwendung definierte Informationen über mehrere Threads hinweg vor, etwa eine Präferenz, die in getrennten Gesprächen genutzt wird. Damit lösen beide unterschiedliche Persistenzprobleme. Dokumentation zur Persistenz.

Bei beiden Ansätzen muss der Speicher zum Ausfall passen, den die Anwendung überstehen soll. InMemorySaver hält Checkpoints im laufenden Prozess und verliert sie bei dessen Neustart. Damit lassen sich Gesprächszustand oder Unterbrechungen demonstrieren, aber keine Wiederherstellung nach dem Ausfall eines Workers gewährleisten. Ein produktionsgeeigneter, datenbankgestützter Saver oder die von Agent Server verwaltete Persistenz deckt diese Speicheranforderung ab.

Ein Checkpoint ist außerdem von der Bestätigung einer externen Aktion zu unterscheiden. Der gespeicherte Zustand „bereit zur Lieferantenaktivierung“ belegt nicht, dass das Lieferantensystem die Aktivierung angenommen hat. Externe Kennung und Ergebnis gehören in einen Anwendungsdatensatz, der sich abgleichen lässt.

Der Anbieter dokumentiert dieses Neustartverhalten und die Notwendigkeit idempotenter Seiteneffekte: Aktionen müssen sich wiederholen lassen, ohne ihre geschäftliche Wirkung zu wiederholen. Eine stabile Vorgangskennung kann beispielsweise verhindern, dass ein fortgesetzter Auftrag denselben Lieferanten zweimal anlegt. Regeln für Unterbrechung und erneute Ausführung.

LangChain vs LangGraph mit Python: dieselbe kleine Aufgabe

Für eine einfache Bestellstatusabfrage drückt LangChain dieselbe Absicht mit weniger Orchestrierungscode aus. Der eigene Graph macht den Weg zwischen Modell und Tools sichtbar. Das lohnt sich, sobald dieser Weg verändert werden muss.

Die Beispiele verwenden dasselbe Modell, denselben Prompt, dasselbe ausschließlich lesende Tool und dieselbe Eingabe. Der Bestelldatensatz ist ausdrücklich eine fiktive lokale Testvorgabe. Benötigt werden langchain[anthropic] und langgraph; für einen echten Modellaufruf muss die Anwendung über ANTHROPIC_API_KEY verfügen. Die Modellkennung im Beispiel folgt der aktuellen LangChain-Übersicht und dem LangGraph-Schnellstart des Anbieters. Beide Codebeispiele wurden lokal mit einem skriptgesteuerten Modell auf Tool-Ausführung und gespeicherten Zustand geprüft. Das prüft das Zusammenspiel der Komponenten, nicht das Verhalten oder die Leistung eines echten Modells.

Die gemeinsame Grundlage wird als common.py gespeichert:

from langchain.chat_models import init_chat_model
from langchain.tools import tool

model = init_chat_model("claude-sonnet-4-6", temperature=0)
prompt = "Use lookup_order for order status. Do not invent a status."
request = {"messages": [{"role": "user", "content": "Status of order demo?"}]}
config = {"configurable": {"thread_id": "order-demo"}}

@tool
def lookup_order(order_id: str) -> str:
    """Read an order's status from a fictional local fixture."""
    return {"demo": "shipped"}.get(order_id, "unknown order")

LangChain: die vorhandene Schleife nutzen

Dieses Beispiel läuft als separates Skript neben common.py:

from common import model, prompt, request, config, lookup_order
from langchain.agents import create_agent
from langgraph.checkpoint.memory import InMemorySaver

agent = create_agent(
    model, tools=[lookup_order], system_prompt=prompt,
    checkpointer=InMemorySaver(),
)
print(agent.invoke(request, config)["messages"][-1].content)

Unter diesem Agenten arbeitet bereits die Graph-Laufzeitumgebung. Um einen Checkpointer zu übergeben, muss create_agent nicht durch einen selbst geschriebenen Graphen ersetzt werden. Agentenkonfiguration.

LangGraph: dieselbe Schleife ausdrücklich definieren

Dieses alternative Skript läuft neben derselben Datei common.py:

from common import model, prompt, request, config, lookup_order
from langchain.messages import SystemMessage
from langgraph.checkpoint.memory import InMemorySaver
from langgraph.graph import StateGraph, MessagesState, START
from langgraph.prebuilt import ToolNode, tools_condition

bound_model = model.bind_tools([lookup_order])

def call_model(state: MessagesState):
    reply = bound_model.invoke([SystemMessage(prompt)] + state["messages"])
    return {"messages": [reply]}

builder = StateGraph(MessagesState)
builder.add_node("model", call_model)
builder.add_node("tools", ToolNode([lookup_order]))
builder.add_edge(START, "model")
builder.add_conditional_edges("model", tools_condition)
builder.add_edge("tools", "model")
agent = builder.compile(checkpointer=InMemorySaver())
print(agent.invoke(request, config)["messages"][-1].content)

Die bedingte Kante leitet einen angeforderten Tool-Aufruf an tools weiter oder beendet den Ablauf, sobald das Modell eine abschließende Antwort liefert. Der Tool-Knoten gibt die Kontrolle an das Modell zurück. Das entspricht dem expliziten Schleifenmuster aus dem LangGraph-Schnellstart, umgesetzt mit den mitgelieferten Hilfsfunktionen für Tool-Knoten.

Beide Beispiele verwenden bewusst prozesslokalen Speicher und zeigen ausschließlich den erfolgreichen Leseablauf. Sie liefern weder eine Deployment-Anleitung noch eine dauerhafte Datenbankanbindung oder eine vollständige Fehlerstrategie. Auch bei identischer Konfiguration ist nicht garantiert, dass die Modellausgaben Wort für Wort übereinstimmen.

Für diese Aufgabe ist LangChain die passende Wahl. Ein eigener Graph wird dann sinnvoll, wenn die nächste Anforderung den Prozess verändert: etwa eine verpflichtende Validierung vor der Abfrage, eine getrennte Warteschlange für Ausnahmefälle oder eine Freigabephase mit eigenem Zustand und eigenen Ergebnissen.

LangGraph-Kosten: LangSmith und Deployment im Überblick

Die Wahl der Bibliothek legt keinen eigenen Hostingtarif fest. Bei den kostenpflichtigen Angeboten geht es darum, welche LangSmith-Dienste und welche Deployment-Umgebung benötigt werden. Die folgenden Preis- und Produktangaben wurden am 13. Oktober 2026 anhand der live verfügbaren Anbieterseiten geprüft.

LangChain, LangGraph und LangSmith: die Unterschiede

LangSmith ist die Plattform für Tracing, Evaluation und Deployment rund um die Anwendung. Ein Trace zeichnet eine Anwendungsausführung auf und kann Modellaufrufe sowie weitere Schritte enthalten. Er ist ein anderes Objekt als der Checkpoint, mit dem sich die Anwendung fortsetzen lässt. LangSmith-Preise und Begriffe.

Beide Bibliotheken sind kostenlos nutzbar. Beim Betrieb auf eigener Infrastruktur müssen dennoch Modellaufrufe, Rechenleistung, Speicher und Betrieb eingeplant werden. Der Kauf von LangSmith ist eine separate Entscheidung; die Deployment-Dokumentation unterstützt ausdrücklich Anwendungen mit LangGraph und LangChain.

Das sind die Tarifbedingungen auf langchain.com/pricing. Der Rechner auf der Seite beschreibt das enthaltene Plus-Kontingent als insgesamt 10K Traces. Zusätzliche Nutzerplätze bedeuten also nicht automatisch ein weiteres Kontingent je Platz. Für die dort angezeigte Observability-Konfiguration nennt er 0.005 LSU je zusätzlichem Trace. Dieser Rechnerwert lässt sich nicht pauschal auf jede Aufbewahrungsoption für Traces übertragen.

Basis-Traces werden 14 Tage aufbewahrt; erweiterte Traces haben eine Aufbewahrungsdauer von 180 Tagen und kosten zusätzlich. Längere Aufbewahrung und Evaluationsdienste sind eigene Budgetentscheidungen. Sie werden durch die Wahl eines Graphen nicht kostenlos. FAQ zu den Preisen.

Deployment-Optionen und ihre Grenzen

Cloud ist die verwaltete Variante, verfügbar ab Plus. LangChain betreibt die Infrastruktur. Innerhalb von Cloud bietet die öffentliche Preisseite Serverless- und Dedicated-Deployments in den Größen Small, Medium und Large an. Deployment-Umgebungen.

Serverless eignet sich für gelegentliche Aufgaben, Hintergrundverarbeitung oder Arbeit, die Wartezeiten verträgt. Im Leerlauf skaliert es auf null; Plus enthält ein kleines Deployment. Dedicated eignet sich für kundenorientierte Anwendungen, die verlässliche Verfügbarkeit benötigen, mit dauerhaft laufender Infrastruktur, automatischer Skalierung, Backups und Hochverfügbarkeit. Das sind die vom Anbieter vorgesehenen Einsatzbereiche, keine Leistungsmessungen aus diesem Vergleich. FAQ zu Deployment-Preisen.

Für die Migrationsplanung ist eine praktische Einschränkung wichtig: Die Größe eines Deployments lässt sich ändern, sein Typ nach der Erstellung jedoch nicht. Der Wechsel von Serverless zu Dedicated erfordert deshalb den Umzug auf ein anderes Deployment; eine Größenanpassung genügt nicht. Serverless-Ressourcen werden außerdem während ihrer Bereitstellung abgerechnet, einschließlich der Leerlaufzeit vor dem Herunterskalieren. „Skaliert auf null“ bedeutet nicht, dass jede Sekunde ohne Anfrage kostenlos ist. Funktionen der Cloud-Plattform.

Hybrid kombiniert eine verwaltete Steuerungsebene mit selbst betriebener Agenteninfrastruktur. Die Steuerungsebene, die Control Plane, verwaltet Deployments; die Datenebene, die Data Plane, führt Agenten und deren unterstützende Dienste aus. Beim Selbsthosting mit Control Plane liegen beide in der eigenen Umgebung. Die Preisseite ordnet hybride und selbst gehostete Optionen dem Enterprise-Tarif mit individueller Preisgestaltung zu. Einen öffentlich festgelegten monatlichen Enterprise-Preis, den man stattdessen einsetzen könnte, gibt es nicht. Preise und Deployment-Umgebungen.

Standalone Agent Server ist eine weitere Betriebsoption, ohne Control Plane und mit selbst bereitgestellten unterstützenden Diensten. Laut Dokumentation sind eine LangSmith-Lizenz, PostgreSQL und Redis erforderlich. Das ist vom Einbetten der kostenlosen LangGraph-Bibliothek in die eigene Anwendung zu unterscheiden. Die Standalone-Dokumentation warnt zudem davor, diesen Server in einer Serverless-Umgebung zu betreiben, die auf null skaliert. Das verwaltete Produkt Cloud Serverless verwendet eine andere Konfiguration. Standalone Agent Server.

Gleiche Arbeitslast, gleiche Kosten – bei beiden Frameworks

Die öffentliche Preisseite legt $1.00 je LSU fest, also je LangChain Standard Unit, und nennt folgende Abrechnungssätze für Deployments:

• Rechenleistung der Laufzeitumgebung: 0.0675 LSU / vCPU-hr.
• Arbeitsspeicher der Laufzeitumgebung: 0.0090 LSU / GiB-hr.
• Rechenleistung der Datenbank: 0.177 LSU / vCPU-hr.
• Arbeitsspeicher der Datenbank: 0.025 LSU / GiB-hr.

Diese Sätze gelten für den abrechenbaren Ressourcenverbrauch zusätzlicher Serverless- und Dedicated-Deployments. Veröffentlichte Deployment-Sätze.

Für einen LangChain-Agenten wie für eine eigene LangGraph-Anwendung lautet die monatliche Plus-Grundrechnung $39 × Nutzerplätze, zuzüglich jeder abrechenbaren Ressourcenstundenmenge multipliziert mit dem jeweiligen Satz oben sowie Modell-, Tracing- und sonstiger anfallender Nutzungskosten. Das enthaltene Deployment-Kontingent wird berücksichtigt, bevor abrechenbare Ressourcen gezählt werden. Anfragen oder Graphknoten dürfen ohne Messungen nicht in Ressourcenstunden umgerechnet werden.

Die folgende Rechnung verwendet die veröffentlichten Größen des Anbieters. Es handelt sich ausdrücklich um berechnete Werte, nicht um zitierte Tarifpreise. Ein zusätzliches Small-Serverless-Deployment hat 1 vCPU und 2 GiB Laufzeitressourcen. Daraus ergeben sich 1 × 0.0675 + 2 × 0.0090 = $0.0855 je bereitgestellter Stunde. Für ein Small-Dedicated-Deployment sind 3 vCPU und 6 GiB für die Laufzeitumgebung sowie 1 vCPU und 4 GiB für die Datenbank aufgeführt. Das ergibt 3 × 0.0675 + 6 × 0.0090 + 1 × 0.177 + 4 × 0.025 = $0.5335 je bereitgestellter Stunde. Diese ressourcenbezogenen Schätzungen anhand der Größe berücksichtigen noch keine zusätzliche Skalierung oder weitere Dienste. Grundlage sind die Größentabelle und die veröffentlichten Sätze.

Für einen einzelnen Plus-Nutzerplatz bei konstantem Dedicated-Ressourcenprofil beträgt die monatliche Zwischensumme $39 + $0.5335 × bereitgestellte Stunden, noch ohne die übrigen gerade genannten Kosten. Für beide Frameworks gilt dieselbe Formel. Eine verbindliche Monatsrechnung setzt die tatsächlichen Ressourcenlaufzeiten und die Skalierung des Deployments voraus.

Bei gleicher Arbeitslast gibt es keinen Schwellenwert, ab dem eines der Frameworks günstiger wird. Werden Nutzerplätze, abrechenbare Ressourcen, Modell- und Tool-Nutzung sowie die Trace-Regeln konstant gehalten, beträgt der berechnete Unterschied $0. Ein neu gestalteter Workflow kann diese Mengen verändern. Der Name der Bibliothek allein bringt jedoch weder einen Rabatt noch eine niedrigere Tokenrechnung.

Von LangChain zu LangGraph wechseln, ohne alles neu zu schreiben

Migriert wird der Teil der Orchestrierung, der mehr Kontrolle braucht. Bewährte Komponenten bleiben erhalten. Der wesentliche Migrationsaufwand steckt im neuen Entwurf von Zustand, Verhalten und Wiederaufnahme, nicht im geänderten Import.

Zunächst muss zwischen der Aktualisierung einer älteren API und der Entscheidung für einen eigenen Graphen unterschieden werden. Der aktuelle Migrationsleitfaden empfiehlt langchain.agents.create_agent anstelle des früheren Konstruktors langgraph.prebuilt.create_react_agent. Diese Migration bedeutet nicht, LangGraph als Grundlage aufzugeben. Eine ältere Anwendung kann zunächst von den aktuellen LangChain-Funktionen profitieren, bevor sie eine individuell entworfene Orchestrierung benötigt. LangChain-Migrationsleitfaden.

Ein funktionierender LangChain-Assistent sollte nicht allein deshalb umgebaut werden, weil Graphen produktionsnäher wirken. Erfüllen Schleife, Middleware und persistenter Speicher die Anforderungen, verursacht ein eigener Graph zusätzlichen Entwurfsaufwand ohne belegten Nutzen.

Auch die Bindung an eine Technologie oder einen Anbieter hat mehrere Ebenen. Wiederverwendbare Modell- und Tool-Komponenten können bestehen bleiben, während sich Graphzustand und Kontrollfluss ändern. Gehostete Infrastruktur bringt eigene Einschränkungen mit: Auf die Cloud-Persistenz wird über Agent Server zugegriffen; die gehostete Datenbank ist nicht direkt zugänglich. Diese Zugriffsgrenze gehört in die Planung eines späteren Exports oder Hostingwechsels. Details zur Cloud-Persistenz.

Für die andere Architekturfrage – Graph-Orchestrierung oder die Abstraktion eines Spezialistenteams – bietet LangGraph vs CrewAI den passenden Vergleich. Optionen jenseits dieses Stacks behandelt der umfassendere Vergleich von Frameworks für KI-Agenten.

Häufige Fragen zur Entscheidung

Mit der Checkliste zur Prüfung von KI-Geschäftsworkflows lassen sich Aufgabe, Prüfschritt und Betriebsverantwortung klären, bevor die Orchestrierung geändert wird.