Stell dir vor, du gibst jemandem eine Aufgabe. "Recherchiere mal, welche Sensoren in unserer Fertigungsanlage verbaut sind, und fasse das kurz zusammen." Die Person ist hochintelligent, spricht fließend sieben Sprachen und verfügt über ein beeindruckendes Allgemeinwissen – hat aber andererseits leider absolut kein Kurzzeitgedächtnis, keinen klaren Plan von der Reihenfolge der notwendigen Schritte. Dafür ist sie unglaublich kreativ. Der Person wird schon etwas einfallen, um die Aufgabe zu erledigen. Oder sie entscheidet bei irgendeinem Schritt spontan, dass sie keine Lust mehr auf die Aufgabe hat und jetzt – schließlich ist sie kreativ – doch lieber ein Gedicht über Schmetterlinge schreibt.
Falls du dich in dieser Beschreibung ein Stück weit wiedererkennst: Du bist damit in bester Gesellschaft: Hochintelligent, kreativ, aber mit einer nicht immer einfachen Beziehung zu Reihenfolgen und Fokus – das kennen viele von uns aus produktiven, aber gedankenreichen Tagen. Und großen Sprachmodellen geht es da ganz ähnlich, mit einem entscheidenden Unterschied: Menschen entwickeln ihre eigenen, oft brillanten Strategien für den Umgang mit derartigen Herausforderungen. Sprachmodelle müssen noch mehr an die Hand genommen werden, sie brauchen dafür ein Framework.
Das Problem: Ein LLM allein macht noch keinen Agenten
Große Sprachmodelle (LLMs) wie GPT, Claude oder Llama sind beeindruckend. Sie können Texte analysieren, Code schreiben, Fragen beantworten. Aber ein LLM ist erst mal nur ein sehr kluger (oder klug scheinender) Gesprächspartner – kein Agent. Der Unterschied? Ein Agent handelt aktiv und interagiert mit seiner Umwelt. Er ruft APIs auf, durchsucht Datenbanken, validiert Ergebnisse und entscheidet auf Basis des Zwischenergebnisses, wie es weitergeht.
Das Problem: Wenn wir ein LLM einfach in eine Schleife stecken und ihm Werkzeuge (Tools) an die sinnbildliche Hand geben, fehlt die Struktur. Es gibt keinen definierten Ablauf, keine Fehlerbehandlung, keinen Zustand, der über einzelne Interaktionen hinaus erhalten bleibt. Es gibt nur den Kontext als bestmögliche Annäherung an einen Zustand. Und wenn etwas schiefgeht? Dann macht der Agent das, was er sowieso schon die ganze Zeit tut: Er improvisiert. Entweder fängt er von vorne an oder macht einfach irgendwas anderes. Das ist ungefähr so, als würde man in einer Fabrik die Produktionsstraße durch eine Gruppe hochmotivierter Roboter ersetzen, die zwar jeder für sich brillant arbeiten – aber keinen gemeinsamen Schichtplan haben.
Für einen Prototypen auf dem eigenen Laptop mag das noch funktionieren. Für eine produktive Anwendung – etwa in der Planung von produktiven Fertigungsanlagen wie im Forschungsprojekt GENIUS, das mit realen Daten und dem Wissen menschlicher Experten arbeitet – brauchen wir etwas Besseres, etwas Verlässlicheres.
LangGraph: Der Fahrplan für KI-Agenten
Genau hier kommt LangGraph ins Spiel. LangGraph ist ein Open-Source-Framework aus dem LangChain-Ökosystem, das auf einer simplen, aber mächtigen Idee aufbaut: KI-Agenten werden als gerichtete Graphen modelliert.
Statt einem LLM die völlige Freiheit zu geben, definieren wir einen Graphen mit Knoten und Kanten. Jeder Knoten ist ein Arbeitsschritt – eine LLM-Anfrage, eine Datenbankabfrage, eine Validierung. Die Kanten beschreiben, welcher Schritt auf welchen folgt. Die Kanten können dabei bedingt sein: Je nach Ergebnis eines Schritts geht es in die eine oder andere Richtung.
Wenn dir das bekannt vorkommt – ja, das ist im Grunde ein Zustandsautomat. Aber einer, der auf KI-Agenten zugeschnitten ist und ein paar entscheidende Extras mitbringt.
Die Bausteine: Knoten, Kanten und Zustand
Schauen wir uns die Kernkonzepte von LangGraph etwas genauer an, ohne dabei zu theoretisch zu werden.
Der Graph (StateGraph)
Der Graph ist das große Ganze – der Bauplan, in dem alle anderen Bausteine zusammenkommen. In LangGraph heißt er StateGraph und er ist genau das, was der Name verspricht: ein gerichteter Graph, der einen typisierten Zustand durch eine Folge von Arbeitsschritten transportiert.
Man kann sich das wie einen U-Bahn-Netzplan vorstellen: Es gibt Stationen (Knoten), Verbindungen (Kanten) und einen Zug (der Zustand), der sich durch das Netz bewegt. Der Graph definiert, welche Stationen es gibt, wie sie verbunden sind und an welchen Weichen der Zug je nach Situation in die eine oder andere Richtung abbiegt. Am Ende wird der Graph “kompiliert” und damit zu einer ausführbaren Anwendung, die man starten, anhalten und sogar mittendrin weiterlaufen lassen kann.
Zustand (State)
Der Zustand ist das Gedächtnis des Agenten, genauer: das Kurzzeitgedächtnis. Alles, was zwischen den Schritten weitergegeben werden muss, lebt im State. Dazu gehören die bisherige Konversation, Zwischenergebnisse, Fehlerzähler oder User Input – einfach alles, was für die aktuelle Bearbeitung der Aufgabe relevant ist.
In LangGraph wird der Zustand als typisiertes Objekt definiert. In Python sieht das zum Beispiel so aus:
from typing import Annotated, TypedDict
from langgraph.graph.message import add_messages
class State(TypedDict):
messages: Annotated[list, add_messages] # conversation history
sparql_query: str # latest query
error_count: int # error counter for retries
Jedes Feld ist typisiert – der Fehlerzähler ist ein int, die Abfrage ein str, die Nachrichten eine Liste mit einer speziellen Merge-Strategie. Wenn etwas nicht zusammenpasst, merkt man das schon beim Entwickeln, nicht erst zur Laufzeit.
Knoten (Nodes)
Ein Knoten ist eine Funktion, die eine diskrete Aufgabe erfüllt. Das kann ein LLM-Aufruf sein, eine Validierungslogik, eine Datenbankabfrage oder eine Transformation von Daten. Jeder Knoten bekommt den aktuellen Zustand, arbeitet damit und gibt den (möglicherweise veränderten) Zustand zurück bzw. weiter an den nächsten Schritt, die nächste (Teil-) Aufgabe.
Kanten (Edges)
Kanten verbinden Knoten und bestimmen den Ablauf. Es gibt einfache Kanten ("nach Schritt A kommt immer Schritt B") und bedingte Kanten ("nach Schritt A kommt Schritt B, wenn das Ergebnis gültig ist – sonst zurück zu Schritt A für einen neuen Versuch" oder “je nach Antwort vom LLM geht es bei B, C oder D weiter“).
Diese Kombination aus typisierten Zuständen, klar definierten Arbeitsschritten und kontrollierbarem Ablauf ist das, was LangGraph von einem simplen "LLM in einer Schleife" unterscheidet. Man bekommt Nachvollziehbarkeit, Kontrolle und ist damit auch in der Lage, den Ablauf zu debuggen und reproduzieren.
Warum nicht einfach LangChain?
Berechtigte Frage. LangChain ist schließlich das bekanntere Framework und kommt aus dem gleichen Haus. LangChain eignet sich hervorragend für lineare Abläufe: Prompt rein, Antwort raus, vielleicht noch ein Tool-Aufruf dazwischen. Für viele Anwendungsfälle reicht das.
Aber sobald es komplexer wird – wenn Entscheidungen, Schleifen, Zusammenarbeit mehrerer Agenten, Fehlerbehandlung und Fortsetzung begonnener Abläufe ins Spiel kommen – stößt LangChain an seine Grenzen. LangGraph wurde genau für diese Szenarien entwickelt und bietet dafür die passende Abstraktionsebene: niedrig genug für volle Kontrolle, hoch genug, um nicht im Boilerplate zu ertrinken.
Ein konkretes Beispiel macht den Unterschied greifbar: Stell dir vor, dein Agent soll eine SPARQL-Abfrage generieren. Mit LangChain schreibst du eine Chain, die Prompt und LLM verknüpft und bekommst eine Antwort. So eine einfache Abfrage-Pipeline sieht in LangChain so aus:
from langchain_core.prompts import ChatPromptTemplate
from langchain_openai import ChatOpenAI
prompt = ChatPromptTemplate.from_template(
"Erzeuge eine SPARQL-Abfrage für: {frage}"
)
llm = ChatOpenAI(model="gpt-4o")
chain = prompt | llm
result = chain.invoke({"frage": "Welche Sensoren sind verbaut?"})
Das ist kurz und elegant, was passiert aber, wenn die generierte Abfrage fehlerhaft ist? Dann müssten wir die Retry-Logik, den Fehlerzähler und die Abbruchbedingung selbst drumherum bauen. In LangGraph ist das dagegen einfach eine bedingte Kante zurück zum Generierungsknoten:
from langgraph.graph import START, StateGraph
graph = (
StateGraph(State)
.add_node("generate", generate_sparql)
.add_node("validate", validate_sparql)
.add_node("execute", execute_sparql)
.add_edge(START, "generate")
.add_edge("generate", "validate")
.add_conditional_edges(
"validate",
check_validity, # valid → execute, otherwise → generate
["generate", "execute"]
)
)
Der Validierungsschritt prüft die Abfrage – und wenn sie fehlerhaft ist, geht es automatisch zurück zur Generierung, diesmal mit dem Fehler als zusätzlichem Kontext.
Aus der Praxis: LangGraph im Forschungsprojekt GENIUS
Theorie ist das eine – aber wie schlägt sich LangGraph in der Praxis? Genau das finden wir gerade heraus.
Im Forschungsprojekt GENIUS arbeiten wir gemeinsam mit dem Fraunhofer-Institut für Werkzeugmaschinen und Umformtechnik (IWU) und Industriepartnern an einem KI-gestützten Assistenzsystem für die Fertigung: dem Factory Buddy. Die Idee: Ein intelligenter Assistent, der Fragen zu Fertigungsanlagen beantworten kann – nicht auf Basis einer simplen FAQ-Datenbank, sondern indem er semantische Wissensgraphen abfragt, in denen Informationen über Maschinen, Sensoren, Prozesse und deren Zusammenhänge strukturiert abgelegt sind.
Das klingt zunächst wie ein klassisches Retrieval-Problem. Doch in der Realität ist es deutlich komplexer: Der Assistent muss die Frage des Anwenders oder der Anwenderin verstehen, in eine formale Abfragesprache (SPARQL) übersetzen, die erzeugte Abfrage validieren, gegen einen Knowledge Graph ausführen und das Ergebnis in eine verständliche Antwort aufbereiten. Und wenn die generierte Abfrage oder Antwort fehlerhaft ist? Dann muss er es erneut versuchen – idealerweise mit dem Wissen, was beim ersten Mal schiefgelaufen ist.
Genau hier spielt LangGraph seine Stärken aus. Der Ablauf des SPARQL-Agenten im Factory Buddy folgt einem klar definierten (und an dieser Stelle vereinfacht beschriebenen) Graphen:
- Abfrage generieren: Das LLM erstellt auf Basis der Nutzerfrage eine SPARQL-Abfrage.
- Abfrage validieren: Die generierte Abfrage wird syntaktisch und semantisch geprüft.
- Bedingte Kante: Ist die Abfrage valide, geht es weiter. Wenn nicht, geht es zurück zu Schritt 1 – mit dem Fehlerfeedback als zusätzlichem Kontext.
- Abfrage ausführen: Die validierte Abfrage wird gegen den Knowledge Graph ausgeführt.
- Ergebnis aufbereiten: Das Rohergebnis wird in eine verständliche Antwort umgewandelt.
Was hier auf den ersten Blick überschaubar wirkt, wäre ohne LangGraph deutlich aufwändiger. Die Validierungsschleife mit automatischem Retry, der typisierte Zustand, der Fehlerzähler und die bedingte Verzweigung – all das kommt out of the box und muss nicht selbst entwickelt werden.
Und das ist nur einer von mehreren Agenten im System. Factory Buddy nutzt eine Multi-Agent-Architektur: Ein Orchestrator-Agent entscheidet auf Basis der Eingangsfrage, welcher spezialisierte Sub-Agent am besten geeignet ist – ob das nun der SPARQL-Agent für strukturierte Daten ist, ein Retrieval-Agent für Dokumentensuche oder ein Agent für die Fabrikplanung. Auch diese Orchestrierung modellieren wir als LangGraph – mit Subgraphen, sozusagen Graphen, die in anderen Graphen eingebunden sind.
Besonders wertvoll im Kontext eines Forschungsprojekts: Die explizite Graphenstruktur macht die Abläufe nachvollziehbar. In einem Umfeld, in dem neurosymbolische KI erforscht wird – die Verbindung von Sprachmodellen mit ontologiebasiertem Wissen – ist Transparenz nicht nice-to-have, sondern eine Voraussetzung.
Was LangGraph sonst noch kann
Jenseits der Grundlagen bietet LangGraph eine Reihe von Features, die besonders für produktive Anwendungen relevant sind:
- Checkpointing: Der Zustand eines Agenten kann persistiert werden – in einer PostgreSQL-Datenbank zum Beispiel. Wenn der Agent abstürzt oder der Server neu startet, kann er genau dort weitermachen, wo er aufgehört hat. Im Factory Buddy nutzen wir das für die threadbasierte Konversationshistorie – jede*r Nutzer*in hat einen eigenen, isolierten Gesprächsverlauf.
- Streaming: Antworten können Token für Token an das Frontend gestreamt werden, statt auf die vollständige Antwort zu warten. Das macht die Interaktion mit dem Assistenten spürbar flüssiger.
- Human-in-the-Loop: An definierten Stellen kann der Agent anhalten und auf menschliche Eingabe warten – etwa für eine Freigabe oder Korrektur. In der Fertigung, wo Entscheidungen Konsequenzen haben, ist das kein nettes Feature, sondern eine Notwendigkeit.
- Subgraphen: Komplexe Agenten können aus kleineren, wiederverwendbaren Graphen zusammengesetzt werden – genau wie unsere Multi-Agent-Architektur es vormacht.
- Debugging und Observability: Durch die explizite Graphenstruktur lässt sich jeder Schritt nachvollziehen, loggen und visualisieren. Im GENIUS-Projekt integrieren wir dafür Langfuse als Tracing-Lösung und Grafana für das Monitoring.
Fazit: Struktur statt Hoffnung
KI-Agenten sind faszinierend. Aber Faszination allein reicht nicht, wenn man zuverlässige Software bauen will. LangGraph gibt uns die Werkzeuge, um aus einem beeindruckenden, aber unberechenbaren Sprachmodell einen nachvollziehbaren, kontrollierbaren und robusten Agenten zu machen.
Zurück zu unserem Bild vom Anfang: Das hochintelligente, aber orientierungslose Gegenüber bekommt mit LangGraph einen Fahrplan in die Hand – mit klar markierten Haltestellen, definierten Umstiegen und einer Notbremse für den Fall, dass doch mal etwas schiefgeht. Und das Gedicht über Schmetterlinge? Bleibt ein Hobby für die Freizeit.
