79 lines
5.2 KiB
Markdown
79 lines
5.2 KiB
Markdown
|
---
|
|||
|
|
type: analysis/synthesis
|
|||
|
|
source_url: "https://t.me/c/-1003839640481/13"
|
|||
|
|
retrieved: 2026-07-26
|
|||
|
|
author: "Rüdiger"
|
|||
|
|
source_group: "OME-Gruppe Topic 13"
|
|||
|
|
title: "Die Drei-Säulen-Triade der Agenten-Architektur: Steinberger, Kopadze, LangGraph"
|
|||
|
|
tags: [agent-architecture, steinberger, kopadze, langgraph, diamond-pattern, loop-engineering, shape-vocabulary, design-patterns, orchestration, agent-topology]
|
|||
|
|
people: [peter-steinberger, harrison-chase]
|
|||
|
|
institutions: [langchain]
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
# Die Drei-Säulen-Triade der Agenten-Architektur: Steinberger, Kopadze, LangGraph
|
|||
|
|
|
|||
|
|
**Author:** Rüdiger
|
|||
|
|
**Posted:** 2026-07-26 (OME-Gruppe Topic 13)
|
|||
|
|
**Type:** Analysis/Synthesis
|
|||
|
|
|
|||
|
|
## Die Drei-Säulen-Triade der Agenten-Architektur
|
|||
|
|
|
|||
|
|
- **[Conceptual] Steinberger** → Loop-Engineering (WANN & WARUM kontrollieren?)
|
|||
|
|
- **[Architectural] Kopadze** → Shape-Vokabular (WELCHE FORM nutzt das System?)
|
|||
|
|
- **[Technical] LangGraph** → Implementation (WIE wird es verdrahtet?)
|
|||
|
|
|
|||
|
|
### 1. Steinberger = Loop-Engineering (Konzeptionell)
|
|||
|
|
|
|||
|
|
- **Perspektive:** Steinberger addressiert die Dynamik und Metrik. Loop-Engineering stellt Fragen wie: Wann bricht ein Loop ab? Wie verhindern wir Halluzinationen in der Feedback-Schleife? Welcher Threshold entscheidet über "gut genug"?
|
|||
|
|
- **Rolle:** Es leistet die wissenschaftliche/konzeptionelle Grundlagenarbeit für die Selbstkorrektur von LLMs (Self-Correction, Reflection, Grounding).
|
|||
|
|
- **Problem ohne die anderen:** Reines Loop-Engineering erklärt dir, wie ein Verifier-Loop mathematisch und logisch stabil bleibt, aber nicht, wie du 5 verschiedene Spezialagenten miteinander arrangierst.
|
|||
|
|
|
|||
|
|
### 2. LangGraph = Implementation (Infrastrukturell)
|
|||
|
|
|
|||
|
|
- **Perspektive:** Das Framework-Rückgrat. Es bietet Python/TypeScript-Primitive für State, Nodes, Edges, Checkpointing, Time-Travel und Routing.
|
|||
|
|
- **Rolle:** Es stellt sicher, dass der Zustand (State) deterministisch durch gerichtete Graphen fließt.
|
|||
|
|
- **Problem ohne die anderen:** 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.
|
|||
|
|
|
|||
|
|
### 3. Kopadze = Shape-Vokabular (Design-Patterns)
|
|||
|
|
|
|||
|
|
- **Perspektive:** Die fehlende Semantik. Kopadze liefert die Architektur-Muster (Shapes), die beschreiben, wie Information durch den Graph strömen soll.
|
|||
|
|
- **Rolle:** Ähnlich wie die Gang of Four (GoF) in der objektorientierten Programmierung (Design Patterns wie Singleton, Factory, Strategy) gibt Kopadze dem Agenten-Design eine abstrakte, aber präzise Sprache: Parallel Fan-Out, Diamond, Hierarchical Router, Cyclic Evaluator.
|
|||
|
|
- **Warum Kopadze die Lücke füllt:** Er übersetzt das abstrakte Loop-Engineering von Steinberger in Topologie, die sich direkt in LangGraph-Graphen gießen lässt.
|
|||
|
|
|
|||
|
|
## Warum das "Diamond Pattern" das mächtigste Workhorse ist
|
|||
|
|
|
|||
|
|
Das Diamond-Pattern (Fan-Out + Verifier / Join) löst das fundamentale Dilemma monolithischer LLM-Prompts.
|
|||
|
|
|
|||
|
|
### Topologie
|
|||
|
|
|
|||
|
|
```
|
|||
|
|
[Router/Splitting] ──► [Sub-Agent A: Task 1] ──┐
|
|||
|
|
──► [Sub-Agent B: Task 2] ──┼─► [Evaluator/Verifier] ──► [Output/Retry]
|
|||
|
|
──► [Sub-Agent C: Task 3] ──┘
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
### Warum dieses 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).
|
|||
|
|
|
|||
|
|
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.
|
|||
|
|
|
|||
|
|
### 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
|
|||
|
|
|
|||
|
|
- [[../../wiki/concepts/agents/graph-based-agents.md]] — Graph-basierte Agenten (LangGraph)
|
|||
|
|
- [[../../wiki/concepts/agents/agent-loops.md]] — Loop-Engineering (Steinberger)
|
|||
|
|
- [[../../wiki/concepts/agents/ai-agents-2026.md]] — AI Agents 2026 Übersicht
|
|||
|
|
- [[../../wiki/architecture/agent-orchestration.md]] — Agenten-Orchestrierung
|
|||
|
|
|
|||
|
|
## Quellen
|
|||
|
|
|
|||
|
|
- X-Post @steipete: "Are we still talking loops or did we shift to graphs yet?" — https://x.com/steipete/status/2078277297791189132
|
|||
|
|
- LangGraph Overview: https://docs.langchain.com/oss/python/langgraph/overview
|