--- created: 2026-07-18 updated: 2026-07-18 sources: - xpost/2026-07-18_steipete-loops-vs-graphs.md tags: [concept, agents, graphs, langgraph, orchestration, langchain, state-machine, agent-architecture] people: [peter-steinberger, harrison-chase] institutions: [langchain] --- # Graph-Based Agent Architecture (LangGraph) > *"Denk in Loops, implementier als LangGraph."* > — Aktueller Konsens (Juli 2026) ## Definition In einer graph-basierten Agent-Architektur wird der Agent als **gerichteter Graph** modelliert. **Nodes** repräsentieren Aktionen (plan, code, test, review), **Edges** definieren Übergänge zwischen diesen Aktionen — bedingt (conditional) oder unbedingt (unconditional). Der Graph kann Zyklen für Iterationen und parallele Branches für gleichzeitige Ausführung enthalten. ``` [Plan] ──→ [Code] ──→ [Test] ──→ [Review] ↑ │ │ │ │ ▼ ▼ │ └──── [Fehler] ← [Fail] ←─────────┘ │ ▼ [Done] ``` ## LangGraph **LangGraph** ist LangChains Low-Level-Orchestrierungs-Framework für graph-basierte Agenten. Entwickelt von Harrison Chase (@hwchase17) und dem LangChain-Team. ### Inspiration - **Google Pregel:** Large-Scale Graph Processing — LangGraph übernimmt das Pregel-Modell für verteilte Graph-Ausführung - **Apache Beam:** Dataflow-Pipeline-Modell — LangGraph nutzt Beam-inspirierte Konzepte für parallele Verarbeitung - **NetworkX:** Python-Graph-Bibliothek — LangGraphs API ist an NetworkX angelehnt (Nodes, Edges, Graph-Objekt) ### Einsatzmöglichkeiten LangGraph kann **standalone** oder **mit LangChain** verwendet werden. Es ist kein Ersatz für LangChain, sondern eine ergänzende Low-Level-Orchestrierungsschicht. ## Kern-Features | Feature | Beschreibung | Loop-Äquivalent | |---------|-------------|-----------------| | **Persistence** | Checkpoints + Durable Execution — Agent-Zustand bleibt bei Unterbrechung erhalten | Muss selbst gebaut werden | | **Human-in-the-Loop** | Native Approval Gates — Mensch kann an jedem Node eingreifen | Muss selbst gebaut werden | | **Comprehensive Memory** | Short-term + Long-term Memory integriert | Muss selbst gebaut werden | | **Debugging (LangSmith)** | Visuelles Tracing — jeder Graph-Schritt ist nachvollziehbar | Nur Log-Analyse | | **Production Deployment** | Skalierbare Ausführung, Fehlertoleranz, Monitoring | Manuelles Deployment | | **Cycles** | Native Zyklen-Unterstützung für Iteration | while-true | | **Parallel Branches** | Gleichzeitige Ausführung unabhängiger Pfade | Schwierig | ### Persistence & Durable Execution LangGraph speichert den Zustand des Agenten nach jedem Schritt (Checkpointing). Bei Unterbrechung (Crash, Timeout, Neustart) kann der Agent exakt dort weitermachen, wo er aufgehört hat. Dies ist besonders wichtig für: - **Langlaufende Agenten** (Stunden/Tage) - **Ressourcen-intensive Operationen** (teure API-Calls nicht wiederholen) - **Audit-Trails** (jeder Zustand ist dokumentiert) ### Human-in-the-Loop (Approval Gates) Native Approval Gates erlauben es, an jedem Node im Graphen einen menschlichen Review-Schritt einzufügen. Der Agent pausiert, bis der Mensch genehmigt, ablehnt oder modifiziert. Dies ist ein entscheidender Vorteil gegenüber Loop-Architekturen, wo HITL manuell implementiert werden muss. ### Comprehensive Memory LangGraph bietet zwei Memory-Ebenen: - **Short-term Memory:** Kontext der aktuellen Session (entspricht Working Memory) - **Long-term Memory:** Über Sessions hinweg persistierte Fakten und Beziehungen (entspricht Semantic + Episodic Memory) ### Debugging via LangSmith LangSmith bietet visuelles Tracing des gesamten Graph-Durchlaufs: - Jeder Node-Durchlauf ist einsehbar - Input/Output jedes Schritts ist dokumentiert - Latenz und Kosten pro Node sind messbar - Fehler sind exakt lokalisierbar ## Vorteile gegenüber Loops - **Built-in State:** Kein selbstgebautes State-Management nötig - **Persistenz:** Checkpoints und Durable Execution - **Tracing:** Visuelles Debugging via LangSmith - **Human-in-the-Loop:** Native Approval Gates - **Parallelität:** Native Unterstützung für parallele Branches - **Skalierbarkeit:** Für komplexe, mehrstufige Workflows ausgelegt ## Nachteile - **Komplexität:** Steilere Lernkurve als einfache Loops - **Vendor-Lock-in-Gefahr:** Stark an LangChain-Ökosystem gebunden - **Overhead:** Für einfache Aufgaben (ein Tool-Call) ist ein Graph over-engineered - **Abstraktion:** Der Kontrollfluss ist weniger offensichtlich als bei linearen Loops - **Debugging-Komplexität:** Bei vielen parallelen Branches wird das Tracing unübersichtlich ## Aktueller Konsens (Juli 2026) Die Community-Debatte hat sich zu einem pragmatischen Konsens entwickelt: > **Loops = Engineering-Philosophie, Graphen = Implementierung** - **Denk in Loops:** Konzipiere deinen Agenten als verschachtelte Loops (Steinbergers Loop Engineering) - **Implementier als LangGraph:** Nutze LangGraph für State, Persistenz, Tracing und HITL - **Wähle nach Komplexität:** Einfache Agenten (1-2 Tool-Calls) → Loop. Komplexe Workflows (5+ Schritte, HITL, Persistenz) → Graph Diese Synthese vereint die konzeptionelle Klarheit der Loops mit der infrastrukturellen Robustheit der Graphen. ## Verwandte Konzepte - [[agent-loops.md]] — Loop-Engineering als konzeptionelle Alternative - **ReAct-Pattern** — Das fundamentale Reason+Act-Pattern - [[../../architecture/agent-orchestration.md]] — Übergeordnete Orchestrierungs-Patterns - [[../../tools/openclaw.md]] — OpenClaw als Agent-Plattform - **Harrison Chase** — LangGraph-Erfinder (@hwchase17) ## Quellen - LangGraph Overview: https://docs.langchain.com/oss/python/langgraph/overview - Harrison Chase (@hwchase17): https://x.com/hwchase17/status/1915845925316268471 - @steipete: "Are we still talking loops or did we shift to graphs yet?" — https://x.com/steipete/status/2078277297791189132 - Google Pregel: https://research.google/pubs/pregel-a-system-for-large-scale-graph-processing/ - Apache Beam: https://beam.apache.org/ - NetworkX: https://networkx.org/