langgraph agents llm architecture typescript python

LangGraph erläutert: Graphen, Zustände, Routing-Logik und Produktionsmuster

Wie LangGraph Agenten als zyklische Graphen mit typisierten Zuständen, Reduzierern, Kontrollpunkten, Routing-Logik, Werkzeugen sowie ReAct-Schleifen darstellt, zusammen mit Mustern für den Produktivgebrauch.

Verlag: REACTAPP.TOPAuf dieser Website hinzugefügt 28. Okt. 202619 Min. Lesezeit4342 Wörter

Quellen: Mastering LangGraph: The Complete Technical Guide to Building Production-Grade Agentic AI Systems

Die erste Welle an Anwendungen für große Sprachmodelle bestand aus einem einfachen Austausch: Man sendete eine Anfrage und erhielt eine Antwort. Agenten sind eine andere Art von Programm. Sie handeln in mehreren Schritten, entscheiden auf der Grundlage dessen, was sie bisher gelernt haben, was zu tun ist, und führen Aktionen in der Außenwelt durch. Dafür ist eine Infrastruktur erforderlich, die auf Schleifen, Verzweigungen und Speicher basiert – nicht eine geradlinige Verbindung von Eingang zu Ausgang.

LangGraph ist ein solches Framework. Es ist für Zustandsanwendungen konzipiert, in denen ein oder mehrere von großen Sprachmodellen gesteuerte Akteure zusammenarbeiten. Anstelle einer linearen Kette ermöglicht es es, ein gerichtetes Graphenmodell zu beschreiben, das Zyklen enthalten kann, bedingte Routen ermöglicht, einen persistenten Zustand beibehält und den Aufruf von Tools koordiniert. Das sind keine bloßen Bequemlichkeiten. Ein Agent, der mit Unsicherheiten umgehen, von Fehlern wiederherstellen und seine Arbeit über mehrere Durchgänge hinweg verbessern muss, benötigt all das.

Im Folgenden wird erläutert, wie das Framework intern funktioniert, warum seine Gestaltungsentscheidungen wichtig sind und wann jedes Muster Anwendung findet. Am Ende sollten Sie in der Lage sein, Architekturentscheidungen selbstbewusst zu treffen, das Verhalten von Agenten, das seltsam erscheint, zu debuggen, und das Framework an Ihre eigenen Bedürfnisse anzupassen.

Graphen als grundlegende Bausteine

Ältere Orchestrierungstools modellieren einen Workflow als eine einfache Kette oder höchstens als gerichteten azyklischen Graphen. Das funktioniert bei vorhersehbaren Aufgaben, bricht jedoch zusammen, wenn ein Agent iterieren, zurückgehen oder spontan einen anderen Weg wählen muss. LangGraph geht von der entgegengesetzten Annahme aus und betrachtet einen gerichteten Graphen mit Zyklen als seine grundlegende Primitivstruktur.

Warum eine Kette nicht ausreicht

Der Unterschied zwischen Ketten und Graphen ist praktischer Natur und nicht nur kosmetischer Art. Eine Kette setzt voraus, dass man beim Schreiben des Codes die genaue Reihenfolge der Operationen kennt. Ein Graph hingegen akzeptiert, dass der Weg durch das System von dem Laufzeitzustand, den Zwischenergebnissen sowie Bedingungen abhängt, die niemand vorhersagen kann.

Stellen Sie sich einen Agenten vor, der ein Unternehmen untersucht. Er beginnt mit finanziellen Daten. Ob er anschließend Nachrichten abruft, Analystenberichte herunterlädt oder die Unterlagen von Konkurrenten liest, hängt davon ab, was die Finanzdaten offenbaren. Dieses bedingte, wiederholte Verhalten erfordert sowohl Schleifen als auch Verzweigungen – und eine Kette kann keines davon darstellen.

Das übliche Agentenmuster besteht aus einem Loop: Man überlegt, was zu tun ist, handelt, beobachtet das Ergebnis und wiederholt diesen Vorgang, bis das Ziel erreicht ist. Bei einem auf Ketten basierenden Tool hat man nur zwei schlechte Optionen: Entweder zerlegt man den Loop in eine feste Anzahl von Schritten, was die Flexibilität zerstört, oder man schreibt den Kontrollfluss selbst außerhalb des Frameworks, was die Kompositionsfähigkeit opfert. In LangGraph ist der Loop an sich eine Erstklassige Idee, die als zyklischer Graph mit bedingten Kanten dargestellt wird.

Knoten

Ein Knoten repräsentiert einen diskreten Rechenschritt. Er erhält den aktuellen Zustand, führt eine Aktion aus und gibt Aktualisierungen zurück. Diese Aktion kann ein Aufruf eines LLMs zur Entscheidungsfindung sein, ein Aufruf eines Tools zur Interaktion mit einem externen System, eine Datenumwandlung oder eine Routing-Logik.

Node sind einfache Python-Funktionen mit einer bestimmten Struktur: der aktuelle Zustand wird eingegeben, ein Dictionary mit den Änderungen ausgegeben. Diese funktionale Schnittstelle sorgt dafür, dass sie kombinierbar und leicht testbar sind. Ein Node ändert den Zustand niemals direkt. Er gibt die gewünschten Änderungen an, und LangGraph fügt sie gemäß von Ihnen definierten Regeln zusammen.

Node können so einfach sein wie ein einziger Aufruf einer KI oder so komplex wie mehrstufige Logik. Einige rufen ganze andere Graphen auf, was hierarchische Agenten ermöglicht. Andere laufen asynchron oder umfassen Wiederholungslogik mit exponentiellem Backoff. Das Framework kümmert sich nicht darum, wie kompliziert ein Node im Inneren ist.

Kanten

Kanten bestimmen, wohin die Steuerung als Nächstes geht, und es gibt zwei Arten mit sehr unterschiedlichen Semantiken.

Statische Kanten sind deterministisch. Wenn Knoten A abgeschlossen ist, geht die Steuerung immer an Knoten B. Sie verhalten sich wie gewöhnliche Funktionsaufrufe und eignen sich für vorab bekannte Abläufe. Nach der Initialisierung einer Forschungsaufgabe folgt beispielsweise immer die Datenerfassung.
Bedingte Kanten leiten dynamisch je nach Zustand weiter. Sobald die Datenerfassung beendet ist, muss man entscheiden, ob genügend Daten vorhanden sind, um mit der Analyse zu beginnen, oder ob fehlgeschlagene API-Aufrufe erneut versucht werden sollten. Diese Entscheidung kann nicht bereits zur Designzeit getroffen werden, weshalb eine Routenfunktion dies zur Laufzeit vornimmt.

Eine Routenfunktion prüft den aktuellen Zustand und gibt einen String zurück, der den zu wählenden Pfad angibt. Das Framework speichert eine Zuordnung dieser Strings zu den Zielknoten. Dadurch lässt sich eine Struktur für Entscheidungsbäume, Wiederholungslogik, Fehlerbehandlung sowie anpassungsfähige Abläufe erstellen, wobei die Routenlogik klar und testbar bleibt.

Als gemeinsame Speicherstruktur darstellen

Die Zustandsverwaltung ist der Punkt, an dem LangGraphs Design besonders interessant wird. Das Zustandsobjekt ist eine gemeinsame Struktur, die sich durch das Graphen bewegt. Jeder Knoten liest den aktuellen Zustand, und alle zurückgegebenen Aktualisierungen werden vor dem Ausführen des nächsten Knotens zusammengeführt. Jeder Schritt baut daher auf dem auf, was frühere Schritte gelernt haben.

Man definiert den Zustand mit typisierten Wörterbüchern oder Pydantic-Modellen, was Typsicherheit sowie einen klaren Vertrag zwischen den Knoten bietet. Das Schema legt fest, welche Felder vorhanden sind, welche Typen sie haben und wie Aktualisierungen zusammengeführt werden. Dieser letzte Aspekt wird oft übersehen, ist aber von großer Bedeutung.

Wenn ein Knoten eine Aktualisierung zurückgibt, muss LangGraph entscheiden, wie diese mit dem bereits vorhandenen Inhalt kombiniert werden soll. Bei einem String oder einer Zahl ist es offensichtlich, den alten Wert durch den neuen zu ersetzen. Bei einer Liste oder einem Dictionary ist das nicht der Fall. Soll die zurückgegebene Liste hinzugefügt werden, der alte Inhalt ersetzt werden oder die Listen Element für Element zusammengeführt werden? Darauf antworten Reducer.

Reducer

Ein Reducer ist eine Funktion, die bestimmt, wie eine Aktualisierung in den bestehenden Zustand integriert wird. Reducer verwandeln LangGraphs Zustand von einem einfachen Container in etwas, das Akkumulationsmuster verarbeiten kann.

Standardmäßig ersetzt der neue Wert einfach den alten. Das ist in Ordnung für die meisten Felder, aber falsch für Daten, die sich anhäufen. Stellen Sie sich eine Fehlerliste vor, die Probleme während eines Laufs sammelt. Man möchte nicht, dass jeder neue Eintrag die vorherigen Lesezeichen löscht – man möchte, dass neue Fehler neben den alten hinzugefügt werden. Der add_messages Reducer folgt diesem Prinzip, und dieses Muster lässt sich auf weitere Fälle übertragen.

Man kann einen benutzerdefinierten Reducer für jedes Feld schreiben. Seine Eingaben sind der bereits im Zustand vorhandene Wert sowie der neu eingehende Wert, und seine Ausgabe ist der Wert, den das Feld danach enthalten sollte. Bei Fehlern würde er Listen zusammenfügen, bei Wörterbüchern könnte er verschachtelte Strukturen tief verschmelzen und bei Zählern könnte er Zahlen addieren.

Reducer werden über Pythons Annotated-Typhinweise angehängt, sodass das Schema weiterhin deklarativ bleibt:

from typing import TypedDict, Annotated

def append_lists(existing: list, new: list) -> list:
    return existing + new
class AgentState(TypedDict):
    query: str  # Simple replacement
    results: Annotated[list, append_lists]  # Custom accumulation
    iteration: int  # Simple replacement

Dadurch bleibt das Verhalten bei der Zusammenführung explizit und zentralisiert, anstatt über einzelne Knoten verstreut zu sein.

Checkpointing

Produktionsagenten laufen oft über lange Zeit, führen kostspielige API-Aufrufe durch oder bearbeiten Operationen, die aufgrund vorübergehender Fehler nicht verloren gehen dürfen. Checkpointing ist das Mechanismus, der dies abdeckt. Wenn es aktiviert ist, speichert LangGraph den vollständigen Zustand nach Abschluss jedes Knotens. Falls der Prozess abstürzt oder an Speicherplatz mangelt, kann die Ausführung vom letzten Checkpoint aus fortgesetzt werden, anstatt von vorne zu beginnen. Ein anfälliges sequenzielles Skript wird so zu einem wieder aufnahmbaren Workflow.

Checkpoints ermöglichen außerdem Designs mit menschlicher Einmischung. Die Ausführung kann an einem gewählten Punkt pausiert werden, damit eine Person den Fortschritt überprüfen oder Eingaben liefern kann, bevor die Ausführung nach ihrer Reaktion wieder aufgenommen wird. Da der Checkpoint den genauen Zustand zum Zeitpunkt der Pause festhält, spielt es keine Rolle, ob in der Zwischenzeit Tage vergehen.

Der dahinterliegende Speicher ist steckbar. Checkpointing im Arbeitsspeicher eignet sich gut für die Entwicklung, SQLite bietet lokale Persistenz und Redis passt zu verteilten Systemen. Das Diagramm bleibt unverändert, nur die Implementierung der Checkpoints ändert sich.

Bedingte Routenplanung

Die Routenplanung ist der Punkt, an dem das Verhalten wirklich dynamisch wird. Die Auswahl des nächsten Schritts zur Laufzeit anhand des gesammelten Zustands unterscheidet eine starre Automatisierung von einem adaptiven Agenten.

Routenfunktionen und Kantenzuordnungen

Eine Routing-Funktion ist eine kleine Python-Funktion, die den Zustand prüft und einen String zurückgibt. Wenn die Ausführung an einer bedingten Entscheidungspunkt ankommt, ruft LangGraph die Funktion auf, nimmt den String entgegen, findet den entsprechenden Knoten in der Zuordnung und überträgt die Steuerung. Da das Routing über Strings und nicht über direkte Knotenreferenzen erfolgt, können Sie die Zuordnung ändern, ohne die Funktion anzufassen, oder eine andere Routing-Funktion einsetzen, ohne die Struktur des Graphen zu verändern.

Typische Routing-Fragen beinhalten die Überprüfung, ob genügend Daten vorhanden sind, um fortzufahren, ob eine Operation erfolgreich war oder erneut versucht werden sollte, ob die Wiederholungsgrenze erreicht wurde und ob das Vertrauen in die Analyse hoch genug ist, um darauf zu handeln. Die Funktion kann den gesamten Zustand einsehen, wodurch sie mehrere Felder vergleichen, Berechnungen durchführen, externe Bedingungen abfragen oder Geschäftsregeln kodieren kann. Die einzige Voraussetzung ist, dass sie deterministisch und rein ist, sodass sie für denselben Zustand immer dieselbe Antwort liefert.

Vermeidung endloser Schleifen

Schleifen ermöglichen leistungsstarke Iterationen, können aber auch zu endlosen Schleifen führen. Ein Agent, der ständig versucht, eine Aufgabe erneut auszuführen, kann Ressourcen endlos verbrauchen, und LangGraph bietet einige Möglichkeiten, dies zu verhindern.

Die einfachste Methode ist ein Zähler im Zustand. Die Routing-Funktion vergleicht diesen Zähler mit einem Maximum und leitet die Steuerung an einen Endknoten weiter, sobald die Grenze überschritten wird. Nahezu jedes Produktionsagent nutzt dieses Muster. Raffiniertere Optionen umfassen die Konvergenzerkennung, bei der die Verarbeitung abbricht, wenn sich die Änderungen zwischen den Iterationen unter einen Schwellenwert senken, sowie die zeitbasierte Beendigung, bei der das Routing die verstrichene Zeit berücksichtigt.

Die Schlussfolgerung ist, dass die Verhinderung von Schleifen eine Aufgabe des Routings ist und keine Einschränkung des Frameworks darstellt. LangGraph stellt Ihnen die notwendigen Elemente zur Verfügung, um Schutzmechanismen anzupassen, die zu Ihrem Fall passen, anstatt pauschale Regeln aufzuzwingen.

Werkzeuge: von Sprache zu Handlung

Agenten werden erst wirklich nützlich, wenn ein LLM auf externe Systeme zugreifen kann. Werkzeuge sind es, die die Sprachverarbeitung in konkrete Handlungen in der realen Welt umsetzen.

Das Ausführungsmuster

In LangGraph ist ein Tool ein Knoten, der außerhalb des Prozesses etwas ausführt. Er kann eine API aufrufen, eine Datenbank abfragen, Code ausführen oder im Internet suchen. Er erhält Parameter vom Zustand, führt die Operation aus und gibt die Ergebnisse als Zustandsaktualisierungen zurück.

Das Muster wird mächtig, wenn es mit der Urteilsfähigkeit des LLM kombiniert wird. Ein LLM-Knoten liest den Zustand und entscheidet, welches Tool aufgerufen werden soll. Eine Routing-Funktion leitet die Steuerung an den entsprechenden Tool-Knoten weiter. Das Tool wird ausgeführt und schreibt sein Ergebnis in den Zustand. Die Steuerung kehrt zum LLM zurück, das das Ergebnis interpretiert und den nächsten Schritt wählt. Dies setzt sich so lange fort, bis das Ziel erreicht ist.

Moderne Modelle unterstützen Funktionsaufrufe, was bedeutet, dass sie eine strukturierte Anfrage aussenden, in der ein Tool sowie seine Parameter genannt werden. Der LLM-Knoten analysiert eine solche Anfrage aus der Antwort des Modells und speichert das gewählte Tool im Zustand. Die Routing-Funktion liest diese Wahl und leitet den Ablauf an den richtigen Tool-Knoten weiter.

Umgang mit Tools-Fehlern

Externe Systeme versagen, laufen aus, liefern ungewöhnliche Daten und durchbrechen Annahmen. Tool-Node müssen darauf vorbereitet sein.

Auffangen und Melden. Ausnahmen erfassen, protokollieren und anstelle eines Absturzes des Agents Fehlerdetails im Zustand zurückgeben. So kann das LLM erkennen, was schiefgelaufen ist, mit anderen Parametern erneut versuchen oder einen anderen Ansatz wählen.
Zeitlimits. Operationen so umschließen, dass sie nach einer maximalen Dauer abbrechen. Eine langsame API sollte den gesamten Agent nicht blockieren.
Validierung. Antworten parsen und gegen Schemata überprüfen. Falsche Daten sollten einen Fehlerweg auslösen und nicht gespeichert werden, wo sie weitere Node stören könnten.

Fallback-Möglichkeiten. Wenn die primäre Quelle versagt, sollte man eine andere ausprobieren. Ein Tool kann nacheinander mehrere APIs aufrufen, auf gespeicherte Daten zurückgreifen oder teilweise Ergebnisse liefern, wobei klar angegeben wird, was fehlt.

Der ReAct-Zyklus

ReAct, abgekürzt für Reasoning and Acting, ist eine grundlegende Agentenarchitektur, die LangGraph auf natürliche Weise darstellt, und ihre Betrachtung zeigt, wie die anderen Konzepte zusammenpassen.

Wie der Zyklus abläuft

Er beginnt bei einem Reasoning-Node. Ein LLM prüft den aktuellen Zustand und entscheidet, was als Nächstes zu tun ist: ein Tool aufrufen, nach weiteren Informationen fragen, eine endgültige Antwort geben oder menschliche Eingabe anfordern. Hier spielen die Fähigkeiten des Modells eine entscheidende Rolle, da es einen komplexen Kontext bewerten und differenzierte Entscheidungen treffen kann.

Falls entschieden wird, etwas zu unternehmen, geht die Steuerung an einen Aktionston, der die ausgewählte Operation ausführt – sei es ein API-Aufruf, eine Berechnung oder eine Datenbankabfrage. Der Aktionston bleibt deterministisch und präzise, führt die Anfrage aus und gibt Ergebnisse zurück.

Danach tritt ein Beobachtungston in Aktion, der die Ergebnisse dem Zustand hinzufügt und sie für den LLM vorbereitet. Dabei kann er Daten formatieren, Störungen filtern oder abgeleitete Metriken berechnen, die eine einfachere Interpretation der Ergebnisse ermöglichen. Anschließend kehrt der Kreislauf mit einem erweiterten Zustand zur Logikverarbeitung zurück. Der LLM sieht, was geschehen ist, wählt den nächsten Schritt aus und setzt dies so lange fort, bis genügend Informationen vorliegen, um abzuschließen.

Wann aufhören?

Die Entscheidung, wann zu beenden ist, ist ein wesentlicher Bestandteil des Kreislaufs, und in der Praxis zeigen sich verschiedene Muster dafür.

Ziel erreicht. Der sauberste Fall: Das LLM gibt an, dass die Aufgabe erledigt ist, und liefert eine endgültige Antwort. Die Routenfunktion erkennt dies und weist den Prozess auf den Abschlussknoten.
Iterationsschranke. Nach einer maximalen Anzahl an „Begründen-und-Handeln“-Zyklen endet der Loop unabhängig davon, ob das Ziel erreicht wurde oder nicht, sodass der Agent letztendlich immer aufhört.
Vertrauensschwelle. Wenn das Modell eine ausreichende Gewissheit erreicht, beispielsweise 95 %, kann es früher aufhören, anstatt weiterhin Informationen zu sammeln, deren Nutzen immer geringer wird.
Fatale Fehler. Wenn kritische Operationen ständig fehlschlagen oder der Agent auf eine Situation stößt, die er nicht bewältigen kann, sollte der Prozess mit einem Fehlerbericht enden, anstatt sinnlos weiterzumachen.

Mehrere Agenten arbeiten zusammen

Manche Aufgaben eignen sich besser für ein Team spezialisierter Agenten als für einen einzigen monolithischen Agenten. Ein Graph macht einige Zusammenarbeitsmuster verständlich.

Hierarchie

In einem hierarchischen Design teilt ein Planer auf höherer Ebene die Arbeit auf und delegiert sie an spezialisierte Agenten. Er behält das übergeordnete Ziel und koordiniert, erledigt aber nicht die detaillierten Arbeiten. Implementierungstechnisch rufen einige Knoten andere kompilierte Graphen auf. Ein Planungsknoten kann eine komplexe Aufgabe analysieren, sie zerlegen und für jeden Teil einen spezialisierten Graphen ausführen. Die Ergebnisse fließen zurück zum Planer, der sie zu dem endgültigen Ergebnis zusammenführt.

Der Hauptvorteil ist die Trennung der Aufgabenbereiche. Jeder Spezialist kann eigenständig entwickelt, getestet und optimiert werden, und der Planer muss nur wissen, wie er sie koordiniert, nicht wie sie funktionieren.

Gleiche Ebene

Agenten können auch als Gleichgestellte zusammenarbeiten, wobei jeder sein Fachwissen einbringt. Ein Team von Softwareagenten kann separate Agenten für Architektur, Implementierung, Testing und Dokumentation umfassen, die alle über einen gemeinsamen Nachrichtenbus miteinander kommunizieren. Dabei wird ein gemeinsamer Zustand verwendet, den jeder Agent lesen und schreiben kann. Eine Routenfunktion entscheidet anhand dieses Zustands sowie der erforderlichen Fähigkeiten, wer als Nächstes handelt. Jeder Agent schreibt seinen Beitrag, kennzeichnet ihn mit Metadaten darüber, was er bearbeitet hat, und gibt die Kontrolle weiter; anschließend wählt der Router den nächsten relevanten Agenten aus.

Peer-Setups bringen vielfältige Sichtweisen mit sich und ermöglichen es den Agenten, die Fehler der anderen zu erkennen – beispielsweise wenn einer einen Fehler in der Argumentation eines anderen entdeckt.

Debatte und Konsens

Bei wichtigen Entscheidungen können mehrere Agenten ein Problem unabhängig lösen und anschließend auf eine Einigung hinarbeiten. Dabei werden konstitutionelle KI-Ideen übernommen, wobei Meinungsverschiedenheiten als Qualitätsindikator betrachtet werden. Drei Agenten analysieren eine Situation und jeder schlägt eine Lösung vor. Ein Moderator leitet abwechselnd Debatten, in denen jeder Agent seine Argumente vorstellt, die anderen kritisiert und spezifische Kritiken beantworten muss. Nach einigen Runden führt ein Konsensschritt die Diskussion zu einer Entscheidung zusammen, wobei möglicherweise die überzeugendsten Argumente stärker gewichtet werden.

Dieser Ansatz macht Halluzinationen sowie Fehler im Denken sichtbar, die bei einem einzelnen Agenten unentdeckt bleiben würden, aber auffallen, wenn mehrere Agenten das Problem aus unterschiedlichen Perspektiven betrachten.

Retrieval innerhalb der Agenten

Retrieval-augmented Generation ermöglicht es Agenten, auf umfangreiche Wissensbasen und Fachmaterial zuzugreifen, wobei Graphen eine natürliche Ergänzung darstellen.

Auf Anfrage abrufen

Beim klassischen RAG wird die Information einmal zu Beginn einer Aufgabe abgerufen. Beim agierenden RAG wird das Abrufen zu einem Werkzeug, das der Agent jedes Mal aufruft, wenn er eine Lücke feststellt. Der Agent beginnt mit dem Schlussfolgern auf der Grundlage seines Grundwissens. Wenn er auf eine Frage stößt, die er nicht beantworten kann, oder mehr Kontext benötigt, formuliert er eine Abfrage, ruft das Werkzeug auf und setzt mit dem neuen Material fort.

Dies ist aus zwei Gründen vorteilhaft gegenüber dem Vorkopieren von Informationen: Es ist kostengünstiger, da der Agent nur das abruft, was er benötigt. Zudem ist es genauer, da die Abfragen von dem geprägt werden, was der Agent derzeit versteht.

Von dem aktuellen Zustand geleitete Abfragen

Der eigentliche Nutzen zeigt sich, wenn die Abfragen alles widerspiegeln, was bisher gesammelt wurde, und nicht nur die ursprüngliche Frage. Nehmen wir eine Unternehmensuntersuchung: Sie kann mit einer umfassenden Übersichtsabfrage beginnen. Das Ergebnis erwähnt eine kürzliche Übernahme, was zu einer gezielten Abfrage zu diesem Deal führt. Dadurch kommen regulatorische Bedenken zum Vorschein, die wiederum eine Abfrage zu den relevanten Vorschriften auslösen. Jede Suche baut auf der vorherigen auf, sodass man eine gezielte Untersuchung erhält anstelle eines unstrukturierten Überblicks.

Mehrere Quellen

Agenten wenden häufig Quellen mit unterschiedlicher Latenz, Kosten und Zuverlässigkeit an: interne Dokumente, externe APIs, Websuche, spezialisierte Datenbanken. LangGraph unterstützt Strategien mit mehreren Quellen. Ein Agent kann zunächst einen schnellen lokalen Cache prüfen, im Notfall auf eine API zurückgreifen und nur als letztes Mittel eine kostspielige Websuche nutzen. Oder er kann mehrere Quellen parallel abfragen und das LLM bitten, widersprüchliche Antworten miteinander in Einklang zu bringen.

Die Routing-Logik kann die Quelle je nach Frageart auswählen. Faktensuche erfolgt in einer strukturierten Datenbank, konzeptionelle Fragen werden per Vektorsuche in Dokumenten abgehandelt, aktuelle Ereignisse durch Websuche und historische Fragen durch eine sorgfältig zusammengestellte Wissensdatenbank.

Produktionsreif machen

Einen Proof-of-Concept-Agenten lässt sich mit LangGraph leicht erstellen. In der Produktion kommen zusätzliche Anforderungen hinsichtlich Zuverlässigkeit, Überwachbarkeit und Betrieb hinzu.

Fehlerbehandlung auf jeder Ebene

Produktionsagenten kümmern sich um Fehler auf mehreren Ebenen. Tool-Node erfassen erwartete Fehler und geben sie als Zustandsaktualisierungen zurück, nicht als Ausnahmen. Routing-Funktionen überprüfen Fehlerbedingungen und richten Versuchspfade mit exponentiellem Backoff ein. Das Diagramm enthält spezielle Fehlerbehandlungs-Node, die die angesammelten Fehler prüfen und entscheiden, ob ein erneuter Versuch unternommen, auf einen Ersatzweg umgestellt oder der Vorgang ordnungsgemäß beendet werden soll. Für kritische Operationen kann ein Circuit Breaker nach wiederholten Fehlern die Versuche pausieren, um Kaskaden zu verhindern und einem fehlerhaften Service zusätzliche Last zu ersparen.

Was passiert ist, einsehen

Wenn etwas schiefgeht, muss man wissen, was der Agent getan hat und warum. LangGraph integriert sich mit Plattformen wie LangSmith, um detaillierte Aufzeichnungen jeder Knotenausführung, Zustandsänderung sowie LLM-Aufrufe bereitzustellen. Die Knoten sollten strukturierte Protokolle mit ausreichend Kontext abgeben, um ihre Entscheidungen zu erklären. Zeitangaben zeigen Engpässe auf, Tokenzählungen unterstützen die Kostenermittlung, und die Überwachung der Benutzerinteraktionen dient der Bewertung. Das Wiederspielen von Zuständen aus Checkpoints ist besonders praktisch – man lädt den genauen Zustand herunter, in dem ein Fehler auftrat, und geht Schritt für Schritt vor, um die Ursache zu finden.

Kosten senken

LLM-Aufrufe machen in den meisten Agenten den größten Teil der Kosten aus, und einige Strategien können diese senken, ohne die Qualität zu beeinträchtigen.

Modellwahl. Verwenden Sie ein leistungsstarkes Modell wie GPT-4 nur für komplexe Berechnungen. Einfache Klassifizierungs- oder Extraktionsaufgaben sollten an schnellere, günstigere Modelle weitergeleitet werden, wobei eine Routing-Logik die Aufgabe prüft.
Antwortcaching. Speichern Sie Ausgaben für identische oder semantisch ähnliche Eingaben. Wenn dieselbe Analyse erneut durchgeführt wird, vermeidet das Caching überflüssige Aufrufe, und Embeddings können Abfragen abgleichen, die unterschiedlich formuliert sind, aber dasselbe bedeuten.
Kürzung von Prompts. Kompakte Prompts, die nur notwendige Informationen enthalten, sparen Tokens. Vorlagen mit Variablensubstitution sorgen für Konsistenz.
Frühzeitiger Abbruch. Beenden Sie den Prozess, sobald der Agent genug Informationen hat, anstatt ein festes Iterationsbudget aufzubrauchen.

Entwurfsrichtlinien

Die Einsetzung von LangGraph-Agenten zeigt, welche Muster starke Systeme von brüchigen Prototypen unterscheiden.

State Schema

Das Schema bildet die Grundlage. Verwenden Sie Pydantic-Modelle anstelle loser Dictionaries, damit die Validierung Fehler frühzeitig erkennt, und dokumentieren Sie die Bedeutung sowie den Verwendungszweck jedes Feldes. Optionale Felder ermöglichen es verschiedenen Knoten, schrittweise Teile beizutragen, während erforderliche Felder sicherstellen, dass kritische Daten vorhanden sind. Diskriminierte Unionen bewältigen Zustände, die je nach eingeschlagener Route unterschiedliche Formen annehmen. Vermeiden Sie tiefe Verkettungen, die es erschweren, auf Felder zuzugreifen. Vereinfachen Sie wo immer möglich, verwenden Sie eine Benennung, die Beziehungen zeigt, und halten Sie Metadaten getrennt von Domänendaten, damit Kontrollinformationen klar erkennbar bleiben.

Knotengrenzen

Gute Knoten erledigen eine Aufgabe gut. Dadurch sind sie in verschiedenen Graphen wiederverwendbar und leichter zu testen sowie zu warten. Tool-Knoten sollten nur mit externen Systemen kommunizieren und keine Geschäftslogik enthalten. Transformationsknoten führen Umwandlungen durch, ohne Entscheidungen zu treffen. Entscheidungsknoten leiten den Datenfluss, ohne Operationen auszuführen. Vermeiden Sie versteckte Nebeneffekte: Knoten sollten so rein wie möglich sein und jede Zustandsänderung explizit zurückgeben, anstatt globale Variablen zu ändern.

Graphenform

Die Struktur sollte dem Denkprozess des Agenten entsprechen. Beginnen Sie mit einer Einrichtungsphase, in der die Eingaben überprüft und der Kontext vorbereitet wird. Anschließend werden Daten gesammelt, möglicherweise parallel. Fügen Sie Analyseknoten hinzu, dann Syntheseknoten, die die Ausgabe erzeugen, sowie Abschlussknoten, die die Ergebnisse aufbereiten. Platziern Sie bedingte Kanten an echten Entscheidungspunkten, an denen der nächste Schritt von den Erkenntnissen abhängt, und verwenden Sie statische Kanten, wenn der Ablauf deterministisch ist. Halten Sie jeden Graphen auf einer Ebene der Abstraktion. Wenn ein Teil davon eine komplexe Unterprozedur implementiert, nehmen Sie diese in einen eigenen Graphen auf und rufen Sie sie als Knoten auf.

Testing

Graphen können auf verschiedenen Ebenen getestet werden. Testen Sie Knoten durch das Übergeben von Simulationszuständen und die Überprüfung der Aktualisierungen. Testen Sie Routing-Funktionen, indem Sie verschiedene Zustände eingeben und den zurückgegebenen Pfad überprüfen. Führen Sie Integrationstests an ganzen Graphen mit bekannten Eingaben durch und überprüfen Sie den Endzustand. Simulieren Sie LLM-Antworten, damit die Tests schnell und deterministisch ablaufen, und verwenden Sie aufgezeichnete echte Antworten für realistische Testfälle. Eigenschaftsbasiertes Testen kann das Verhalten über einen weiten Eingabebereich hinweg überprüfen. Behandeln Sie kritische Pfade gründlich sowie Fehlerwege besonders sorgfältig, da diese in der Produktion schwer auszulösen sind, aber entscheidend sind, sobald sie auftreten.

Entscheiden, ob Sie es benötigen

LangGraph ist leistungsstark, aber nicht jede LLM-Anwendung erfordert es.

Es kommt zum Tragen, wenn der Agent iterativ reasoning durchführen muss, indem er Informationen sammelt und analysiert sowie entscheidet, ob er weiter suchen soll. Es eignet sich auch dann, wenn der Kontrollfluss von dem Laufzeitzustand abhängt – wie bei Wiederholungsversuchen, Fehlerrückgewinnung oder adaptiven Arbeitsabläufen –, wenn mehrere Tools oder Systeme komplexe Abhängigkeiten aufweisen, wenn der Zustand über Schritte oder Sitzungen hinweg beibehalten werden muss, wenn die Ausführung für Menschen pausiert und wieder aufgenommen werden muss, oder wenn mehrere Agenten zusammenarbeiten oder eine Hierarchie bilden.

Etwas Einfacheres reicht aus, wenn die Aufgabe aus einer einfachen Anfrage und Antwort besteht, ohne Schleifen oder Verzweigungen, der Ablauf linear und im Voraus bekannt ist, die Arbeit aus einer Kette deterministischer Schritte besteht, nichts über einen einzigen Ausführungsvorgang hinaus gespeichert werden muss, oder die App höchstens eine oder zwei einfache APIs aufruft. In solchen Fällen liefern LangChain-Ketten oder direkte API-Aufrufe klareren und wartbareren Code als das Zwangsvorhaben, das Problem in ein Graphen umzuwandeln.

Langsam komplexer werden

Viele Anwendungen beginnen einfach und werden später komplex. Ein gutes Design erwartet das. Beginnen Sie mit einer Kette, halten Sie die Anfragen, Tools und Geschäftslogik jedoch modular und lose voneinander getrennt, damit eine Umwandlung in ein Graphen später einfach möglich ist. Sobald die Kette fünf bis sieben Schritte umfasst oder Sie eine zweite bedingte Verzweigung hinzufügen, sollten Sie in Erwägung ziehen, migrieren zu müssen, bevor die Komplexität außer Kontrolle gerät.

Fortgeschrittene Techniken

Jenseits der Grundlagen eröffnen einige Techniken weitere Möglichkeiten.

Parallelverarbeitung. Knoten, die nicht von den Ausgaben anderer Knoten abhängen, können gleichzeitig ausgeführt werden. Knoten zur Datenerfassung, die beispielsweise auf unterschiedliche APIs zugreifen, verkürzen die Gesamtlaufzeit, wenn sie parallel laufen, und das Framework sammelt sowie verschmilzt die Ergebnisse. Es sind explizite parallele Verbindungen erforderlich, und man muss sicherstellen, dass die Knoten tatsächlich unabhängig sind, ohne versteckte Kopplungen durch gemeinsame Ressourcen oder globales Zustandsmanagement.

Streaming. Bei langlaufenden Agenten verbessert die Anzeige von Zwischenergebnissen das Erlebnis. Knoten können teilweise aktualisierte Zustände ausgeben, die Beobachter sofort sehen können. Das eignet sich für Berichterstellung, bei der Absätze bereits während der Erstellung angezeigt werden können, sowie für Suchfunktionen, die Ergebnisse sofort nach ihrer Findung anzeigen.

Untergraphen. Komplexe Agenten profitieren von einer hierarchischen Aufteilung. Untergraphen werden getrennt kompiliert und als Knoten in einem übergeordneten Graphen aufgerufen, erhalten einen Teilzustand des übergeordneten Graphen und geben Aktualisierungen zurück, die wieder integriert werden. Verschiedene Ingenieure können unterschiedliche Untergraphen verwalten, diese unabhängig einsetzen und testen sowie gemeinsam genutzte Untergraphen in mehreren übergeordneten Graphen wiederverwenden.

Dynamische Änderungen am Graphen. Die meisten Graphen sind zur Zeit der Konzeption festgelegt, doch in einigen fortgeschrittenen Fällen werden sie laufend geändert. Ein Planungsagent könnte nach der Analyse einer Aufgabe einen benutzerdefinierten Graphen erstellen und dabei spontan Knoten sowie Kanten hinzufügen. Dadurch wird das Verhalten schwieriger zu durchschauen, weshalb dieses Vorgehen sparsam angewendet werden sollte. Es ermöglicht jedoch Meta-Agenten, benutzerdefinierte Workflows für neue Arten von Aufgaben zu entwerfen und auszuführen.

Zusammenfassende Perspektive

LangGraph spiegelt ein reifendes Werkzeugset für agierende Systeme wider. Seine Stärke liegt nicht in der Komplexität, sondern darin, wie genau die Primitiven dem Verhalten von Agenten entsprechen: Sie denken, handeln und beobachten in Schleifen, treffen Entscheidungen auf der Grundlage angesammelten Wissens, koordinieren Werkzeuge und passen sich an, wenn etwas schiefgeht. Man drückt diese Muster direkt aus, anstatt sie von Grund auf zu entwickeln.

Gute Ergebnisse zu erzielen bedeutet, State-Management, bedingte Routing-Strategien sowie Werkzeugintegration als architektonische Muster zu meistern – und nicht nur als Funktionen. Die besten Anwendungen weisen ein sorgfältig entworfenes State-Schema, klare Verantwortlichkeiten der Knoten, durchdachtes Fehlerrhandling sowie umfassende Überwachungsmöglichkeiten auf. Das Framework bietet Werkzeuge, keine Lösungen. Ihr Fachwissen und Ihr Urteilsvermögen bestimmen, wie gut sie angewandt werden – beginnen Sie daher einfach, testen Sie Annahmen frühzeitig und lassen Sie reale Anforderungen, nicht imaginäre, die Architektur gestalten.