Agentic DesignMuster und Werkzeuge für produktive KI-Agenten

Loading...

🔄

Graph-Zustandsmaschinen

Endliche Zustandsmaschinen, die als Graphen zur Workflow-Steuerung umgesetzt werden

Komplexität: mediumWorkflow-Orchestrierung

In 30 seconds

What: Modelliert Workflows als Zustände, die durch bewachte Übergänge verbunden sind, und führt deterministische Pfade auf Basis von Ereignissen und Validierungsregeln aus.
When to use: Mehrstufige Prozesse mit klaren Zustandsgrenzen, Rollback-Bedarf und bedingter Verzweigung anhand der Ergebnisse einzelner Schritte.
Watch out: Zustandsexplosion und Wartungsaufwand wachsen schnell, sobald Sonderfälle und Fehlerpfade über den ursprünglichen Entwurf hinaus zunehmen.

Loading technique guide…

Patterns

Loading...

Loading Agentic Design…

Agentic DesignMuster und Werkzeuge für produktive KI-Agenten

Expertenhilfe Preise

Entwurfsmuster und Techniken

Loading...

🔄

Graph-Zustandsmaschinen

Endliche Zustandsmaschinen, die als Graphen zur Workflow-Steuerung umgesetzt werden

Komplexität: mediumWorkflow-Orchestrierung

In 30 seconds

What: Modelliert Workflows als Zustände, die durch bewachte Übergänge verbunden sind, und führt deterministische Pfade auf Basis von Ereignissen und Validierungsregeln aus.
When to use: Mehrstufige Prozesse mit klaren Zustandsgrenzen, Rollback-Bedarf und bedingter Verzweigung anhand der Ergebnisse einzelner Schritte.
Watch out: Zustandsexplosion und Wartungsaufwand wachsen schnell, sobald Sonderfälle und Fehlerpfade über den ursprünglichen Entwurf hinaus zunehmen.

Kernmechanismus

Graph-Zustandsmaschinen bilden den Kontrollfluss als Zustände (Knoten) und ereignisgesteuerte Übergänge (Kanten) mit Guard-Bedingungen und Aktionen ab. Statecharts ergänzen das um hierarchische Zustände, orthogonale Regionen (Parallelität) und Historie, um komplexes reales Verhalten zu erfassen. Das ergibt deterministische, auditierbare Flusssteuerung für Agenten-/Tool-Aufrufe, Freigaben, Retries und Human-in-the-Loop-Checkpoints.

Ablauf / Schritte

Zustände auflisten (initial, intermediär, terminal) und State-/Context-Schema definieren.
Events auflisten; Übergänge mit Guards und Aktionen definieren (Fehler/Timeouts als Events einbeziehen).
Den Graphen entwerfen: Prioritäten/Defaults je Zustand; Hierarchie/parallele Regionen ergänzen, wenn Statecharts genutzt werden.
Reine Übergangslogik implementieren; Seiteneffekte in Effect-Handlern mit Retries und Idempotenz ausführen.
State plus minimalen Kontext persistieren; Maschine versionieren; Visualisierung aus dem Quellcode ermöglichen.
Übergänge testen (tabellengetrieben), Guards fuzzen und Invarianten validieren; Observability ergänzen.

Best Practices

Zustandsexplosion minimieren: Datenprüfungen in Guards kodieren, nicht in separaten Zuständen.

Statecharts für Hierarchie/Parallelität nutzen; Historie für die Wiederaufnahme einsetzen.

Übergangsfunktionen rein halten; I/O und Seiteneffekte mit Idempotenzschlüsseln isolieren.

Fehler/Timeouts explizit modellieren; Kompensationen und Rollback-Pfade ergänzen.

Diagramme als Source of Truth aus der Maschinendefinition generieren; Diffs in PRs reviewen.

Nur nötigen Kontext persistieren; große Artefakte per URI auslagern; sensible Daten schützen.

Umfassende Tests für Guards/Übergänge; Property-Tests für Sicherheitsinvarianten.

Wann NICHT einsetzen

Einfache lineare Abläufe, bei denen eine geradlinige Funktion oder ein DAG klarer und günstiger ist.

Datenintensive Dataflow-/ETL-Lasten, für die Stream-/DAG-Engines besser passen als ereignisgesteuerte Guard-Maschinen.

Pfade mit ultraniedriger Latenz, empfindlich gegenüber Event-Loop-/Guard-Auswertungs-Overhead.

Strikte serviceübergreifende ACID-Transaktionen; Workflow-Engines mit Sagas/Transaktionen bevorzugen.

Häufige Fallstricke

Zustandsexplosion, weil feingranulare Datenbedingungen als Zustände statt als Guards kodiert werden.

Mehrdeutige oder überlappende Guards; fehlende Default-Übergänge → Nichtdeterminismus.

Seiteneffekte in Übergängen → Nichtdeterminismus und Retry-Risiken.

Fehlende Persistenz/Idempotenz → nicht wiederherstellbare oder doppelte Effekte beim Retry.

Parallele Regionen ohne saubere Isolation → Races und Deadlocks.

Kernfunktionen

Deterministische Event→Übergang-Semantik mit Guards und Aktionen

Hierarchische und parallele Zustände (Statecharts); Historie/Wiederherstellung

Explizite Fehler-, Timeout- und Kompensationsübergänge

Visuelle Modelle und formales Schließen über Erreichbarkeit/Invarianten

Komponierbare Submaschinen; Wiederverwendung über Regionen und aufgerufene Maschinen

KPIs / Erfolgsmetriken

Übergangsabdeckung und Erkennung unerreichbarer Zustände in Tests.

Mittlere Schritte bis zum Abschluss; Verteilung der Verweildauer je Zustand; p50/p95 je Übergang.

Raten von Fehler-/Kompensationsübergängen; Erfolgsquoten von Replay/Resume.

Für LLM-Schritte: Tokens je Zustand und je Lauf; Kosten je Lauf; Cache-Trefferquote.

Token- / Ressourcenverbrauch

Treiber: LLM-/Tool-Aufrufe je Zustand, Validierungs-/Selbstprüfungs-Prompts und Kontextwachstum in den State-Daten.

Steuerung: Token-Budgets je Zustand; Kontext zusammenfassen/kürzen; deterministische Schritte cachen; Nebenläufigkeit begrenzen.

Storage/CPU: minimalen State plus Referenzen persistieren; sensiblen Kontext nicht loggen; Kosten je Übergang instrumentieren.

Beste Anwendungsfälle

Bestell-, Freigabe- und Fulfillment-Abläufe mit Retries, Kompensationen und menschlichen Freigaben.

Agenten-/Dialog-Controller, die Tool-Aufrufe und Sicherheitsprüfungen je Schritt kontrollieren.

Compliance-Workflows mit Bedarf an deterministischem Replay und Audit-Trails.

Geräte-/Prozesssteuerungen mit hierarchischen/parallelen Modi.

Referenzen und weiterführende Literatur

Wissenschaftliche Arbeiten

Implementierungsleitfäden

Werkzeuge und Bibliotheken

XState/Statecharts, AWS Step Functions, Temporal, Camunda BPMN 2.0
LangGraph, LlamaIndex Workflows

Community und Diskussionen

Loading technique guide…

Patterns

Entwurfsmuster und Techniken

Loading...

Kernmechanismus

Ablauf / Schritte

Zustände auflisten (initial, intermediär, terminal) und State-/Context-Schema definieren.
Events auflisten; Übergänge mit Guards und Aktionen definieren (Fehler/Timeouts als Events einbeziehen).
Den Graphen entwerfen: Prioritäten/Defaults je Zustand; Hierarchie/parallele Regionen ergänzen, wenn Statecharts genutzt werden.
Reine Übergangslogik implementieren; Seiteneffekte in Effect-Handlern mit Retries und Idempotenz ausführen.
State plus minimalen Kontext persistieren; Maschine versionieren; Visualisierung aus dem Quellcode ermöglichen.
Übergänge testen (tabellengetrieben), Guards fuzzen und Invarianten validieren; Observability ergänzen.

Best Practices

Zustandsexplosion minimieren: Datenprüfungen in Guards kodieren, nicht in separaten Zuständen.

Statecharts für Hierarchie/Parallelität nutzen; Historie für die Wiederaufnahme einsetzen.

Übergangsfunktionen rein halten; I/O und Seiteneffekte mit Idempotenzschlüsseln isolieren.

Fehler/Timeouts explizit modellieren; Kompensationen und Rollback-Pfade ergänzen.

Diagramme als Source of Truth aus der Maschinendefinition generieren; Diffs in PRs reviewen.

Nur nötigen Kontext persistieren; große Artefakte per URI auslagern; sensible Daten schützen.

Umfassende Tests für Guards/Übergänge; Property-Tests für Sicherheitsinvarianten.

Wann NICHT einsetzen

Einfache lineare Abläufe, bei denen eine geradlinige Funktion oder ein DAG klarer und günstiger ist.

Datenintensive Dataflow-/ETL-Lasten, für die Stream-/DAG-Engines besser passen als ereignisgesteuerte Guard-Maschinen.

Pfade mit ultraniedriger Latenz, empfindlich gegenüber Event-Loop-/Guard-Auswertungs-Overhead.

Strikte serviceübergreifende ACID-Transaktionen; Workflow-Engines mit Sagas/Transaktionen bevorzugen.

Häufige Fallstricke

Zustandsexplosion, weil feingranulare Datenbedingungen als Zustände statt als Guards kodiert werden.

Mehrdeutige oder überlappende Guards; fehlende Default-Übergänge → Nichtdeterminismus.

Seiteneffekte in Übergängen → Nichtdeterminismus und Retry-Risiken.

Fehlende Persistenz/Idempotenz → nicht wiederherstellbare oder doppelte Effekte beim Retry.

Parallele Regionen ohne saubere Isolation → Races und Deadlocks.

Kernfunktionen

Deterministische Event→Übergang-Semantik mit Guards und Aktionen

Hierarchische und parallele Zustände (Statecharts); Historie/Wiederherstellung

Explizite Fehler-, Timeout- und Kompensationsübergänge

Visuelle Modelle und formales Schließen über Erreichbarkeit/Invarianten

Komponierbare Submaschinen; Wiederverwendung über Regionen und aufgerufene Maschinen

KPIs / Erfolgsmetriken

Übergangsabdeckung und Erkennung unerreichbarer Zustände in Tests.

Mittlere Schritte bis zum Abschluss; Verteilung der Verweildauer je Zustand; p50/p95 je Übergang.

Raten von Fehler-/Kompensationsübergängen; Erfolgsquoten von Replay/Resume.

Für LLM-Schritte: Tokens je Zustand und je Lauf; Kosten je Lauf; Cache-Trefferquote.

Token- / Ressourcenverbrauch

Treiber: LLM-/Tool-Aufrufe je Zustand, Validierungs-/Selbstprüfungs-Prompts und Kontextwachstum in den State-Daten.

Steuerung: Token-Budgets je Zustand; Kontext zusammenfassen/kürzen; deterministische Schritte cachen; Nebenläufigkeit begrenzen.

Storage/CPU: minimalen State plus Referenzen persistieren; sensiblen Kontext nicht loggen; Kosten je Übergang instrumentieren.

Beste Anwendungsfälle

Bestell-, Freigabe- und Fulfillment-Abläufe mit Retries, Kompensationen und menschlichen Freigaben.

Agenten-/Dialog-Controller, die Tool-Aufrufe und Sicherheitsprüfungen je Schritt kontrollieren.

Compliance-Workflows mit Bedarf an deterministischem Replay und Audit-Trails.

Geräte-/Prozesssteuerungen mit hierarchischen/parallelen Modi.

Referenzen und weiterführende Literatur

Wissenschaftliche Arbeiten

Implementierungsleitfäden

Werkzeuge und Bibliotheken

XState/Statecharts, AWS Step Functions, Temporal, Camunda BPMN 2.0
LangGraph, LlamaIndex Workflows

Community und Diskussionen

Graph-Zustandsmaschinen - Agentic Design