155 lines
No EOL
7.5 KiB
Markdown
155 lines
No EOL
7.5 KiB
Markdown
---
|
||
created: 2026-07-26
|
||
updated: 2026-07-26
|
||
sources:
|
||
- xpost/2026-07-25_anatoli-kopadze-graph-engineering-guide.md
|
||
tags: [concept, agents, graph-engineering, workflows, orchestration, parallel-execution, verification, agent-architecture, shapes, chain, diamond, router, cycle]
|
||
people: [anatoli-kopadze]
|
||
---
|
||
|
||
# Graph Engineering — Die 4 Fundamental Shapes für AI Agent Workflows
|
||
|
||
> *"Most people use 10% of AI — type one prompt, close tab. The people using the other 90% aren't typing prompts at all. They're running agents in parallel, wired into graphs that check their own work."*
|
||
> — Anatoli Kopadze (@AnatoliKopadze), Juli 2026
|
||
|
||
## Definition
|
||
|
||
**Graph Engineering** ist die Disziplin, AI-Workflows als gerichtete Graphen zu modellieren und zu optimieren. **Tasks** sind Nodes, **Dependencies** sind Edges. Das Ziel: unabhängige Tasks parallel laufen lassen statt sequentiell — und die klassische lineare Loop-Struktur durch einen optimierten, kontrollierten Plan ersetzen.
|
||
|
||
Anders als [[graph-based-agents.md]] (das LangGraph als Implementierungsframework in den Mittelpunkt stellt), fokussiert Graph Engineering auf die **Shape-Klassifikation** — ein Vokabular von 4 fundamentalen Graph-Formen, die als Bausteine für jeden Agent-Workflow dienen.
|
||
|
||
## Shape 0 – Basics: Graph als visueller Plan
|
||
|
||
Jeder Graph besteht aus:
|
||
- **Nodes (Tasks):** Was soll passieren? (z.B. `research`, `code`, `test`, `review`, `decide`)
|
||
- **Edges (Dependencies):** Was muss vorher fertig sein?
|
||
- **Parallelität:** Tasks ohne Abhängigkeiten können gleichzeitig laufen
|
||
|
||
Der Shift von linearen Loops zu Graphen ist nicht nur technisch — es ist ein **Planungs-Paradigmenwechsel**: Statt "mach das immer wieder, bis es passt" → "zeichne den optimalen Pfad, dann führe ihn aus".
|
||
|
||
## Shape 1 – The Chain (Sequentiell)
|
||
|
||
```
|
||
A → B → C
|
||
```
|
||
|
||
**Wann verwenden:** Nur wenn Tasks wirklich voneinander abhängen.
|
||
**Vorteil:** Einfach, vorhersagbar, debug-bar.
|
||
**Nachteil:** Langsam — nutzt keine Parallelität.
|
||
|
||
> **Beispiel:** Datenbereinigung → Feature-Extraktion → Modell-Training. Jeder Schritt braucht den vorherigen.
|
||
|
||
## Shape 2 – The Diamond (Der Arbeitgeber) ⬥
|
||
|
||
```
|
||
┌── Worker 1 ──┐
|
||
Start ───┼── Worker 2 ──┼── Verifier/Merge ──→ Output
|
||
└── Worker N ──┘
|
||
```
|
||
|
||
**Wann verwenden:** Für die meisten Alltags-Workflows.
|
||
**Was passiert:**
|
||
1. **Start-Node:** Verteilt die Aufgabe
|
||
2. **Fan-Out (Parallel Workers):** N unabhängige Agenten arbeiten parallel
|
||
3. **Verifier/Merge-Node:** Sammelt Ergebnisse, prüft Qualität, konsolidiert
|
||
4. **Output:** Fertiges Ergebnis
|
||
|
||
**Anwendungen:**
|
||
- **Research:** Mehrere Quellen parallel scannen → Synthese
|
||
- **Market Scans:** Gleichzeitige Analyse verschiedener Segmente
|
||
- **Code Reviews:** N Review-Agenten parallel → Merge der Findings
|
||
|
||
> 💡 **Kopadzes Empfehlung:** Starte IMMER mit dem Diamond. Es ist das mächtigste Pattern für den Alltag.
|
||
|
||
## Shape 3 – The Router (Entscheidungs-Verzweigung)
|
||
|
||
```
|
||
┌── Pfad A ──┐
|
||
Decision Node ──┼── Pfad B ──┼──→ Output
|
||
└── Pfad C ──┘
|
||
```
|
||
|
||
**Wann verwenden:** Wenn das Ergebnis einer Task bestimmt, was als nächstes passiert.
|
||
**Was passiert:**
|
||
1. **Decision Node:** Ein Evaluations-Agent prüft das Ergebnis (z.B. "Ist der Code korrekt?")
|
||
2. **Routing:** Basierend auf dem Ergebnis wird zu einem spezifischen Pfad geroutet
|
||
3. **Ziel-Pfade:** Jeder Pfad hat seine eigene Logik
|
||
|
||
**Kern-Insight:** Die Branching-Logik lebt in der **Graph-Struktur** (den Edges), nicht im **Model Guess** (dem Prompt). Das macht das Verhalten deterministischer, testbarer und sicherer.
|
||
|
||
> **Beispiel:** Code-Generierung → Code-Review → [Bestanden? → Merge | Fehler gefunden? → Fix-Node | Sicherheitsproblem? → Escalation-Node]
|
||
|
||
## Shape 4 – The Cycle (Kontrollierte Schleife)
|
||
|
||
```
|
||
┌─────────────────────────┐
|
||
│ ▼
|
||
Start ──→ Process ──→ Check Condition ──→ Stop (wenn erfüllt)
|
||
│
|
||
└── (weiter, wenn nicht erfüllt)
|
||
```
|
||
|
||
**Wann verwenden:** Für Discovery-Work und iterative Verfeinerung.
|
||
**Wichtig:** Braucht eine **harte Stop-Bedingung** (max cycles, timeout, convergence threshold).
|
||
|
||
**Anwendungen:**
|
||
- **Bug Sweeps:** Wiederholte Tests, bis keine Fehler mehr gefunden werden
|
||
- **Iterative Refinements:** Schrittweise Verbesserung eines Outputs
|
||
- **Discovery Work:** Solange forschen, bis eine Schwelle erreicht ist
|
||
|
||
> ⚠️ **Risiko:** Ohne harte Stop-Bedingung wird der Cycle zum Infinite Loop.
|
||
|
||
## Step-by-Step: Graph from Scratch
|
||
|
||
Kopadzes 10-Schritte-Plan für den Bau eines Agent-Graphen:
|
||
|
||
1. **Define goal** — Was soll der Graph erreichen?
|
||
2. **List every sub-task** — Alle Einzelschritte (egal ob parallel oder sequentiell)
|
||
3. **Draw dependencies** — Welcher Schritt braucht welchen anderen?
|
||
4. **Choose dominant shape** — Starte mit **Diamond** (Shape 2). Es passt für 80% der Fälle
|
||
5. **Add Router/Cycle only where needed** — Füge Komplexität nur dort hinzu, wo der Diamond nicht reicht
|
||
6. **Add verification nodes** — Jeder kritische Pfad braucht eine Qualitätskontrolle
|
||
7. **Set limits** — Max parallel workers, max cycles, timeout, retry count
|
||
8. **Test small** — Erst mit einem Mini-Datensatz, dann skalieren
|
||
9. **Visualize and iterate** — Mach den Graphen sichtbar (Mermaid, LangGraph Studio), iteriere
|
||
10. **Scale** — Erhöhe Parallelität, füge Quellen hinzu, deploye in Produktion
|
||
|
||
## Vergleichstabelle: Shapes
|
||
|
||
| Shape | Name | Parallelität | Komplexität | Anwendung | Stop-Bedingung |
|
||
|-------|------|-------------|-------------|-----------|----------------|
|
||
| 1 | Chain | ❌ Keine | Einfach | Strikt sequentielle Pipelines | Natürliches Ende |
|
||
| 2 | Diamond | ✅ Hoch | Mittel | Research, Scans, Reviews | Merge/Verifier |
|
||
| 3 | Router | ⚠️ Pro Pfad | Mittel | Entscheidungsbäume | Ziel-Pfad-Ende |
|
||
| 4 | Cycle | ⚠️ Intern | Hoch | Discovery, Iteration | Hard Limit nötig |
|
||
|
||
## Verhältnis zu Loops & LangGraph
|
||
|
||
Kopadzes Graph Engineering ergänzt die bestehende [[graph-based-agents.md]]- und [[agent-loops.md]]-Debatte:
|
||
|
||
- **Loops = konzeptionelle Grundlage** (ReAct-Pattern, Steinbergers Loop Engineering)
|
||
- **LangGraph = Implementierungs-Framework** (State, Persistenz, HITL, Tracing)
|
||
- **Graph Engineering = Shape-Vokabular** (Chain, Diamond, Router, Cycle als Design-Bausteine)
|
||
|
||
Zusammen ergibt sich ein **3-Ebenen-Modell**:
|
||
1. **Konzeption:** In Loops denken (Steinberger)
|
||
2. **Design:** Shapes zeichnen (Kopadze)
|
||
3. **Implementation:** Als LangGraph bauen (Harrison Chase)
|
||
|
||
## Verwandte Konzepte
|
||
|
||
- [[graph-based-agents.md]] — LangGraph als Implementierungs-Framework
|
||
- [[agent-loops.md]] — Loop Engineering (ReAct-Pattern)
|
||
- [[../../architecture/agent-orchestration.md]] — Übergeordnete Orchestrierungs-Patterns
|
||
- [[../../architecture/model-routing.md]] — Model Routing als komplementäre Optimierung (richtiges Modell für jede Node)
|
||
- [[../../tools/openclaw.md]] — OpenClaw als Agent-Plattform
|
||
- [[ai-agents-2026.md]] — Gesamtentwicklung autonomer Agenten
|
||
- [[../../../tools/model-routing.md]] — Cost-Saving Patterns mit Model-Split
|
||
- [[../../concepts/llm/llm-model-catalog.md]] — Modell-Katalog für Node-Zuweisung
|
||
|
||
## Quellen
|
||
|
||
- @AnatoliKopadze (2026-07-25): Graph Engineering Guide — X-Thread (viral)
|
||
- [[../../../../raw/xpost/2026-07-25_anatoli-kopadze-graph-engineering-guide.md]] (Raw Source)
|
||
- [[graph-based-agents.md]] — Vergleich und Einordnung
|
||
- [[agent-loops.md]] — Loop vs. Graph Abgrenzung |