222 lines
No EOL
12 KiB
Markdown
222 lines
No EOL
12 KiB
Markdown
---
|
|
created: 2026-07-26
|
|
updated: 2026-07-26
|
|
sources:
|
|
- xpost/2026-07-26_ruediger-agent-architecture-triade.md
|
|
- xpost/2026-07-18_steipete-loops-vs-graphs.md
|
|
- xpost/2026-07-24_steipete-graph-engineer-codex.md
|
|
tags: [concept, agents, architecture, steinberger, kopadze, langgraph, diamond-pattern, loop-engineering, shape-vocabulary, design-patterns, orchestration, agent-topology, graph-compiler, codex, kotliarskyi]
|
|
people: [peter-steinberger, harrison-chase, alex-kotliarskyi]
|
|
institutions: [langchain, openai]
|
|
---
|
|
|
|
# Architecture Triade: Steinberger, Kopadze, LangGraph
|
|
|
|
> *"Ohne die Abstraktionsebene von Kopadze versuchen Entwickler oft, komplexe Systeme in LangGraph zu bauen, indem sie entweder einen riesigen, instabilen Single-Agent-Loop nutzen oder einen starren Pipeline-Graph verdrahten."*
|
|
> — Rüdiger, OME Topic 13, 2026-07-26
|
|
|
|
## Überblick
|
|
|
|
Die Architecture Triade beschreibt die drei notwendigen Säulen der Agenten-Architektur, die zusammenwirken müssen, um robuste, skalierbare Agenten-Systeme zu bauen. Jede Säule adressiert eine andere Frage:
|
|
|
|
| Säule | Perspektive | Kernfrage | Analogie in OOP |
|
|
|-------|-------------|-----------|-----------------|
|
|
| **[Conceptual] Steinberger** | Loop-Engineering | WANN & WARUM kontrollieren? | Algorithmen |
|
|
| **[Architectural] Kopadze** | Shape-Vokabular | WELCHE FORM nutzt das System? | GoF Design Patterns |
|
|
| **[Technical] LangGraph** | Implementation | WIE wird es verdrahtet? | Framework / Runtime |
|
|
|
|
## Die Drei-Säulen-Triade im Detail
|
|
|
|
### 1. Steinberger = Loop-Engineering (Konzeptionell)
|
|
|
|
**Perspektive:** Steinberger adressiert die Dynamik und Metrik des Agentenverhaltens.
|
|
|
|
**Kernfragen:**
|
|
- Wann bricht ein Loop ab?
|
|
- Wie verhindern wir Halluzinationen in der Feedback-Schleife?
|
|
- Welcher Threshold entscheidet über "gut genug"?
|
|
- Wie bleibt ein Verifier-Loop mathematisch und logisch stabil?
|
|
|
|
**Rolle:** Liefert die wissenschaftliche/konzeptionelle Grundlagenarbeit für die Selbstkorrektur von LLMs (Self-Correction, Reflection, Grounding).
|
|
|
|
**Lücke ohne die anderen:** Reines Loop-Engineering erklärt, wie ein Verifier-Loop stabil bleibt, aber nicht, wie man 5 verschiedene Spezialagenten miteinander arrangiert. Es fehlt die Topologie.
|
|
|
|
**Verwandte Wiki-Seite:** [[agent-loops.md]]
|
|
|
|
### 2. LangGraph = Implementation (Infrastrukturell)
|
|
|
|
**Perspektive:** Das Framework-Rückgrat.
|
|
|
|
**Primitive:**
|
|
- State (deterministischer Zustand)
|
|
- Nodes (Aktionen)
|
|
- Edges (Übergänge, bedingt/unbedingt)
|
|
- Checkpointing (Durable Execution)
|
|
- Time-Travel (Debugging)
|
|
- Routing (Conditional Edges)
|
|
|
|
**Rolle:** Stellt sicher, dass der Zustand deterministisch durch gerichtete Graphen fließt — mit Built-in Persistenz, Tracing, HITL und Parallelität.
|
|
|
|
**Gefahr ohne Patterns:** LangGraph ist eine mächtige "Turing-vollständige" Infrastruktur — und genau das ist die Falle. Da man mit Nodes und Edges alles bauen kann, entstehen in der Praxis unlesbare, zusammengeschusterte "Spaghetti-Graphen", weil Entwickler ohne ein klares Pattern einfach Nodes aneinanderreihen.
|
|
|
|
**Verwandte Wiki-Seite:** [[graph-based-agents.md]]
|
|
|
|
### 3. Kopadze = Shape-Vokabular (Design-Patterns)
|
|
|
|
**Perspektive:** Die fehlende Semantik zwischen Loop-Engineering und Framework.
|
|
|
|
**Rolle:** Kopadze liefert die Architektur-Muster (Shapes), die beschreiben, wie Information durch den Graph strömen soll — ähnlich wie die **Gang of Four (GoF)** in der OOP Design Patterns (Singleton, Factory, Strategy) lieferte.
|
|
|
|
**Kopadze-Shapes:**
|
|
| Shape | Beschreibung | Anwendungsfall |
|
|
|-------|-------------|----------------|
|
|
| **Parallel Fan-Out** | Verteilung einer Aufgabe auf mehrere Sub-Agenten | Unabhängige Teilaufgaben |
|
|
| **Diamond** | Fan-Out + Verifier/Join | Qualitätsgesicherte parallele Verarbeitung |
|
|
| **Hierarchical Router** | Verschachtelte Entscheidungsbäume | Komplexe Routing-Logik |
|
|
| **Cyclic Evaluator** | Wiederholte Prüfschleifen | Qualitätsiteration, Self-Correction |
|
|
|
|
**Warum Kopadze die Lücke füllt:** Er übersetzt das abstrakte Loop-Engineering von Steinberger in konkrete Topologien, die sich direkt in LangGraph-Graphen gießen lassen.
|
|
|
|
## Das Diamond Pattern — Das mächtigste Workhorse
|
|
|
|
Das Diamond-Pattern (Fan-Out + Verifier / Join) löst das fundamentale Dilemma monolithischer LLM-Prompts: Ein einzelner Prompt verliert an Fokus und Qualität, je mehr Aufgaben er gleichzeitig lösen soll.
|
|
|
|
### Topologie
|
|
|
|
```
|
|
[Router/Splitting] ──► [Sub-Agent A: Task 1] ──┐
|
|
──► [Sub-Agent B: Task 2] ──┼─► [Evaluator/Verifier] ──► [Output/Retry]
|
|
──► [Sub-Agent C: Task 3] ──┘
|
|
```
|
|
|
|
### Warum das Diamond Pattern im Alltag dominiert
|
|
|
|
1. **Parallel Fan-Out (Verteilung & Spezialisierung):** Statt ein einziges Modell mit einer riesigen Aufgabe zu überfordern (wo der Kontext verwaschen wird), bricht der Start-Node das Problem in synchrone/asynchrone Teilaufgaben auf. Jeder Zweig hat einen spezialisierten Prompt, ggf. eigene Tools oder sogar schlankere/günstigere Modelle (z. B. Haiku/Mini für Sub-Tasks) — eine direkte Verbindung zum [[../../architecture/model-routing.md|Model Routing]]-Pattern.
|
|
|
|
2. **Der Evaluator / Verifier (Der Steinberger-Join):** Am Ende des Fan-Out läuft die Information nicht einfach ungeprüft zusammen (Merge), sondern trifft auf ein Verifier-Node. Dieser Prüfknoten agiert als Qualitätstor: Er prüft Konsistenz, halluzinierte Daten oder fehlende Teile. Der entscheidende Clou: Scheitert der Verifier, geht es nicht zurück an den Start, sondern gezielt in eine Kopadze-Loop an den betreffenden Sub-Knoten zurück.
|
|
|
|
### Verbindung zur Triade
|
|
|
|
Das Diamond Pattern ist die praktische Synthese aller drei Säulen:
|
|
- **Kopadze** liefert die Shape (Diamond-Topologie)
|
|
- **Steinberger** liefert den Verifier-Mechanismus (Abbruchkriterien, Thresholds, Loop-Control)
|
|
- **LangGraph** liefert die Implementation (Nodes, Edges, State, Parallel Branches, Checkpointing)
|
|
|
|
## Die Triade in der Praxis
|
|
|
|
### Zusammenspiel
|
|
|
|
```
|
|
┌──────────────────────────────┐
|
|
│ [Kopadze] Shape-Vokabular │
|
|
│ (Welche Form?) │
|
|
└──────────┬───────────────────┘
|
|
│ übersetzt in Topologie
|
|
┌──────────▼───────────────────┐
|
|
│ [Steinberger] │
|
|
│ Loop-Engineering │
|
|
│ (Wann/Warum?) │
|
|
└──────────┬───────────────────┘
|
|
│ dockt an Verifier-Nodes an
|
|
┌──────────▼───────────────────┐
|
|
│ [LangGraph] │
|
|
│ Implementation │
|
|
│ (Wie verdrahten?) │
|
|
└──────────────────────────────┘
|
|
```
|
|
|
|
### Fazit
|
|
|
|
Ohne die Abstraktionsebene von Kopadze versuchen Entwickler oft, komplexe Systeme in LangGraph zu bauen, indem sie entweder einen riesigen, instabilen Single-Agent-Loop nutzen oder einen starren Pipeline-Graph verdrahten. Erst das Verständnis von Kopadzes Shape-Vokabular erlaubt es:
|
|
|
|
1. Den Problemraum in erprobte Topologien (wie das Diamond-Pattern) zu zerlegen.
|
|
2. Das Loop-Engineering nach Steinberger punktuell an den Verifier-Nodes anzudocken.
|
|
3. Das Ganze in LangGraph sauber, wartbar und skalierbar zu implementieren.
|
|
|
|
## Verwandte Wiki-Seiten
|
|
|
|
- [[agent-loops.md]] — Loop-Engineering (Steinberger)
|
|
- [[graph-based-agents.md]] — Graph-basierte Agenten (LangGraph)
|
|
- [[ai-agents-2026.md]] — AI Agents 2026 Übersicht
|
|
- [[../../architecture/agent-orchestration.md]] — Agenten-Orchestrierung
|
|
- [[../../architecture/model-routing.md]] — Model Routing (komplementär: Task-Spezialisierung auf Sub-Agent-Ebene)
|
|
|
|
## 4. Codex = Graph Compiler (Automatisierungsebene)
|
|
|
|
*Hinzugefügt 2026-07-26 — basierend auf @steipete's Post "am I a graph engineer now".*
|
|
|
|
**Perspektive:** Codex als Übersetzer von visuellen Graphen in ausführbaren Code. Die fehlende Automatisierungsebene, die die Triade vervollständigt.
|
|
|
|
### Die Entdeckung
|
|
|
|
Am 24.07.2026 postete **Alex Kotliarskyi (@alexk, OpenAI Engineering Lead)** einen Workflow, der sofort von Peter Steinberger (@steipete) aufgegriffen wurde:
|
|
|
|
> "How to graph-max with Codex and 5.6 Sol:
|
|
> 1. Draw a graph (literally in any tool, even on paper)
|
|
> 2. Send it to Codex and say 'write a code mode script that implements this workflow, run it with <your inputs>'
|
|
> 3. There's no step 3, it just works."
|
|
|
|
Steinberger antwortete mit: "am I a graph engineer now" — eine selbstironische Bestätigung, dass sein Loop-Engineering jetzt durch Codex in Graph-Code übersetzt wird.
|
|
|
|
**Quelle:** `raw/xpost/2026-07-24_steipete-graph-engineer-codex.md`
|
|
|
|
### Was der Graph Compiler bedeutet
|
|
|
|
Codex fungiert als **Graph → Code Compiler**:
|
|
- **Input:** Ein visuelles Diagramm (handgezeichnet, in einem beliebigen Tool, auf Papier)
|
|
- **Verarbeitung:** Codex erkennt die Struktur des Graphen (Nodes, Edges, Fluss)
|
|
- **Output:** Ein ausführbares Code-Mode-Script, das den Workflow implementiert
|
|
- **Ausführung:** Der generierte Code wird mit den bereitgestellten Inputs ausgeführt
|
|
|
|
Das ist fundamental anders als bisher:
|
|
| Bisher | Mit Graph Compiler |
|
|
|--------|-------------------|
|
|
| Entwickler verdrahtet Nodes/Edges manuell in LangGraph | Codex generiert den Code aus einer visuellen Skizze |
|
|
| Shape-Vokabular bleibt abstraktes Konzept | Shape-Diagramm wird direkt zum ausführbaren Agenten |
|
|
| Loop-Engineering erfordert manuelle Threshold-Setzung | Verifier-Logik aus Shapes kann mitgeneriert werden |
|
|
|
|
### Verbindung zur Triade
|
|
|
|
Die vier Säulen bilden jetzt eine vollständige Kette:
|
|
|
|
```
|
|
[Konzeption] ──► [Design] ──► [Implementation] ──► [Automatisierung]
|
|
Steinberger Kopadze LangGraph Codex
|
|
Loop-Engineering Shape-Vokabular Framework Graph → Code
|
|
```
|
|
|
|
**Konkrete Integration:**
|
|
1. **Kopadze** definiert das Shape (z.B. Diamond-Pattern)
|
|
2. **Steinberger** definiert die Loop-Bedingungen (Wann evaluieren? Welcher Threshold?)
|
|
3. **Codex** übersetzt die Shapes + Parameter in ausführbaren LangGraph-Code
|
|
4. **LangGraph** führt den generierten Code als Runtime aus
|
|
|
|
### Was ist hier wirklich neu?
|
|
|
|
Bisher wurde das Shape-Wissen (Kopadze) manuell in LangGraph gegossen: Ein Entwickler sieht das Diamond-Pattern und übersetzt es per Hand in Nodes und Edges. Der Graph Compiler automatisiert diesen Schritt:
|
|
- **Shape → Code:** Das Diamond-Pattern wird nicht mehr von Hand implementiert, sondern von Codex aus dem Diagramm generiert
|
|
- **Visuelle Programmierung:** Die Graph-Struktur wird zum Source Code — analog zu UML → Code-Generierung in klassischer Softwareentwicklung
|
|
- **Demokratisierung:** Auch Nicht-Entwickler können Agent-Workflows entwerfen (zeichnen) und ausführen lassen
|
|
|
|
### Einordnung in die Triade-Entwicklung
|
|
|
|
Die Drei-Säulen-Triade beschrieb, *wie* man Agenten-Architektur denken und bauen sollte. Der Graph Compiler automatisiert diesen Prozess:
|
|
- **Früher:** Stunde → Shape denken → in Code gießen
|
|
- **Jetzt:** Minute → Shape zeichnen → Codex generiert Code → ausführen
|
|
|
|
Die Automatisierungsebene macht die Triade erst vollständig: Sie schließt den Kreis von der Idee über das Design zur Implementation — und zurück zur Idee (iterative Verfeinerung durch erneutes Zeichnen).
|
|
|
|
### Rezeption und Community
|
|
|
|
- Steinbergers Post erreichte ~730K Views, 4.7K Likes, 333 Reposts und 5.5K Bookmarks — ein starkes Signal, dass der Graph Compiler-Ansatz auf breites Interesse stößt
|
|
- Notable Replies: @luckeyfaraday (athena-graphs Repo), @CaryPalmerr (Puppetmaster)
|
|
- Die hohe Bookmark-Rate (5.5K bei 730K Views) deutet auf praktisches Interesse hin: Leser speichern den Post für späteren Gebrauch
|
|
|
|
## Quellen
|
|
|
|
- Rüdiger (OME Topic 13, 2026-07-26): Drei-Säulen-Triade der Agenten-Architektur
|
|
- @steipete: Loops vs. Graphs — 248K Views, 402 Quotes (raw: `xpost/2026-07-18_steipete-loops-vs-graphs.md`)
|
|
- @steipete (2026-07-24): "am I a graph engineer now" — ~730K Views (raw: `xpost/2026-07-24_steipete-graph-engineer-codex.md`)
|
|
- Alex Kotliarskyi (@alexk, OpenAI): Codex Graph-Max Workflow (via @steipete Quote)
|
|
- LangGraph Overview: https://docs.langchain.com/oss/python/langgraph/overview
|
|
- Harrison Chase (@hwchase17): https://x.com/hwchase17/status/1915845925316268471 |