2025f0babb
- raw: raw/xpost/2026-07-18_healthranger-kimi-k3-anthropic-panic.md - wiki: concepts/llm/kimi-k3.md (new concept page) - wiki: institutions/moonshot-ai.md (updated with Kimi K3 section) - wiki: index.md (77. update, new LLM entry + raw source) - wiki: log.md (ingest entry) - fix: broken links in agent-loops.md + graph-based-agents.md Kernaussagen: ~8x cheaper than Claude, open source July 27, safeguard controversy (curcumin/cyclospora block vs. free answer), AI bubble thesis from HealthRanger (Mike Adams).
126 lines
6.1 KiB
Markdown
126 lines
6.1 KiB
Markdown
---
|
|
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/
|