Ich habe LangGraph in der Erwartung eingeführt, dass „State-Management und Flow-Kontrolle sauberer werden“, doch stattdessen wurde der Code komplexer.
Dies ist ein Bericht und eine geteilte Erfahrung darüber, wie ich selbst erlebt und aufgearbeitet habe, dass sich die Struktur trotz Einführung eines Frameworks verschlechtern kann.
Bei der Diagnose sah der Zustand so aus:
- Im Graph gab es nur einen einzigen Node. Eine Struktur
current_step → END, also weder bedingte Edges noch Verzweigungen, undgraph.invoke()war faktisch dasselbe wie ein direkter Funktionsaufruf. Über den Step-Wechsel entschied der Service-Code außerhalb des Graphen. - Derselbe State wurde an zwei Stellen gespeichert. LangGraph MemorySaver (In-Memory) und ein eigener PostgreSQL-Checkpointer speicherten und restaurierten dieselbe Session doppelt, wodurch Inkonsistenzen entstanden.
- Duplizierung in drei LangGraph-Ausführungs-Codes (Executors) mit rund 8.700 Zeilen. Die eigentliche Kernlogik war im Wesentlichen nur „LLM-Aufruf + Prompt-Zusammenbau“, der Großteil war State-Management, bedingte Verzweigungen und Edge-Case-Patches.
Oberflächlich betrachtet war das Problem, dass reale Framework-Funktionen (bedingte Edges, integrierter Checkpointer, Human-in-the-Loop) nicht genutzt wurden und nur die Hülle eingeführt wurde. Beim tieferen Nachforschen zeigte sich jedoch eine andere Ursache.
- Das meiste wurde als Vibe Coding erstellt, aber im Entstehungsprozess wurden weder interner Code noch Designprinzipien wirklich tief untersucht; stattdessen wurden jedes Mal nur Anforderungen und Absichten sortiert und die Implementierung so fortgeführt.
- Das Problem war nicht Vibe Coding selbst, sondern Fortschritt ohne Validierung. Dabei wird nur die Funktion direkt vor den Augen optimiert, aber die Verantwortungsgrenzen der Gesamtstruktur werden nicht gewahrt. Doppelte Checkpointing-Logik, verstreuter State und duplizierte Logik waren alles angesammelte Teiloptimierungen.
- Nicht etwa, dass es keinen Designer gab, sondern dass Anweisungen darauf gegeben wurden, ohne ausreichend zu verstehen, wofür das Framework überhaupt Verantwortung übernehmen soll — das war die eigentliche Ursache.
Also habe ich das reflektiert und so zurückgebaut:
- Session-Trennung durch unabhängige Topologie +
thread_id-Isolierung - Im State nur Metadaten belassen und den Hauptinhalt in den Store verschoben
- Statt
regex-Parsing nativestool_useverwendet - Nodes so getrennt, dass sie testbar sind
- Und ich selbst brauchte ein präzises Verständnis des Frameworks und einer Struktur, um es richtig zu nutzen
Dies ist kein Bericht darüber, „wie man es verwendet“, sondern darüber, „wie ich es falsch verwendet habe“.
2 Kommentare
Alle Fälle, in denen langchain und langgraph verwendet werden, scheinen durch AI SDK ersetzbar zu sein.
Stimmt, kann ich nachvollziehen. Es würde zwar eine Abhängigkeit vom SDK entstehen, aber bei der hohen Lernkurve ist das vermutlich trotzdem die bessere Wahl.