Skip to content
Produkt

Playbooks: Wenn ein einzelner Workflow nicht ausreicht

JieGou Playbooks führen komplexe, langläufige Automatisierungen als asynchrone Agenten mit Node-Level-Checkpointing, Crash-Recovery und Concurrency-Control aus.

JT
JieGou Team
· · 4 Min. Lesezeit

Ein Recipe erledigt eine Aufgabe. Ein Workflow verkettet Aufgaben. Aber manche Automatisierungen sind größer als ein einzelner Workflow — sie laufen minuten- oder stundenlang, koordinieren mehrere parallele Arbeitsstränge und müssen Fehler elegant überstehen.

Playbooks sind JieGous Antwort darauf. Sie führen Workflows als asynchrone Hintergrund-Agenten mit eingebautem Checkpointing, Crash-Recovery und Concurrency-Control aus.

Was Playbooks unterscheidet

Standard-Workflow-Ausführung läuft synchron. Der Client wartet auf das Ergebnis. Das funktioniert gut für Workflows, die in Sekunden bis wenigen Minuten abgeschlossen sind. Aber für eine 30-Schritte-Automatisierung, die einen Stapel Dokumente verarbeitet, Daten aus drei externen Quellen anreichert, auf eine Genehmigung wartet und einen Abschlussbericht generiert — synchrone Ausführung stößt an praktische Grenzen.

Playbook-Ausführung ist asynchron. Sie starten das Playbook und erhalten sofort eine Run-ID. Die Ausführung läuft im Hintergrund weiter. Sie können den Fortschritt jederzeit prüfen, und das System benachrichtigt Sie bei Abschluss.

Node-Level-Checkpointing

Der wichtigste architektonische Unterschied ist Checkpointing. Nach erfolgreichem Abschluss jedes Schritts persistiert das Playbook seinen Zustand — alle Schritt-Ausgaben, die aktuelle Position im Ausführungsgraphen und jeden Loop- oder Branch-Kontext.

Wenn ein Playbook während der Ausführung abstürzt — ein Server-Neustart, ein vorübergehender Infrastrukturfehler, ein Timeout bei einem externen Service — startet es nicht von vorne. Es setzt am letzten Checkpoint fort und macht dort weiter, wo es aufgehört hat. Bereits abgeschlossene Schritte werden nicht erneut ausgeführt.

Das ist wichtig für langläufige Automatisierungen, bei denen das erneute Ausführen abgeschlossener Schritte Zeit und Geld verschwendet (LLM-Aufrufe sind nicht kostenlos) und Nebenwirkungen verursachen kann (Sie wollen nicht dieselbe E-Mail zweimal senden).

Concurrency-Control

Playbooks handhaben parallele Branches sicher. Wenn ein Playbook einen parallelen Schritt erreicht, wird jeder Branch unabhängig mit ordnungsgemäßem Concurrency-Management ausgeführt. Ressourcen-Locks verhindern konfligierende Operationen, und das Playbook verfolgt, welche Branches abgeschlossen sind, um sicherzustellen, dass der parallele Schritt erst endet, wenn alle Branches fertig sind.

Fortschritts-Streaming

Während ein Playbook im Hintergrund läuft, streamt die UI Echtzeit-Fortschrittsupdates. Sie können sehen:

  • Welcher Schritt gerade ausgeführt wird
  • Welche Schritte abgeschlossen sind (mit Ausgabevorschau)
  • Welche Schritte ausstehen
  • Geschätzte verbleibende Zeit basierend auf historischen Ausführungsdaten

Das ist dieselbe Fortschrittsansicht, die für synchrone Workflows verwendet wird, aber sie aktualisiert sich asynchron über Polling statt über eine langlebige Verbindung.

Retry und Wiederaufnahme

Wenn ein Playbook-Schritt fehlschlägt, wendet das System die Standard-Retry-Strategie an (exponentielles Backoff, konfigurierbare maximale Versuche). Wenn die Wiederholungen erschöpft sind und der Schritt endgültig fehlschlägt, pausiert das Playbook mit einem Fehlerstatus.

Aus dem pausierten Zustand haben Sie drei Optionen:

  • Wiederholen des fehlgeschlagenen Schritts (nachdem das zugrunde liegende Problem behoben wurde, wie ein widerrufener API-Schlüssel)
  • Überspringen des fehlgeschlagenen Schritts und Fortfahren mit dem nächsten
  • Abbrechen des gesamten Playbooks

Die Fähigkeit, nach einem Fehler fortzufahren — statt von Anfang an neu zu starten — ist das, was Playbooks für komplexe, mehrstufige Automatisierungen praktikabel macht.

Wann Playbooks vs. Workflows verwenden

Verwenden Sie Standard-Workflows, wenn:

  • Die Ausführung in unter 5 Minuten abgeschlossen ist
  • Sie das Ergebnis sofort brauchen (synchrone Antwort)
  • Der Workflow durch eine Benutzeraktion ausgelöst wird und der Benutzer auf die Ausgabe wartet

Verwenden Sie Playbooks, wenn:

  • Die Ausführung länger als ein paar Minuten dauert
  • Die Automatisierung viele Schritte oder große Datenmengen umfasst
  • Crash-Recovery wichtig ist (die Kosten eines Neustarts sind hoch)
  • Die Automatisierung im Hintergrund läuft (geplant, getriggert oder Fire-and-Forget)

Teilen und Analysen

Playbook-Runs unterstützen dasselbe Freigabemodell wie Workflow-Runs — privat, Abteilung, Konto oder Gruppensichtbarkeit. Teammitglieder können Fortschritt sehen, Schritt-Ausgaben inspizieren und abgeschlossene Runs basierend auf ihrer Zugriffsebene überprüfen.

Playbook-Analysen zeigen Ausführungshäufigkeit, Erfolgsraten, durchschnittliche Dauer und Kosten pro Run. Diese helfen Ihnen zu identifizieren, welche Playbooks am wertvollsten sind und welche Optimierung brauchen.

Playbooks sind in Enterprise-Plänen verfügbar. Erfahren Sie mehr über Playbooks oder kontaktieren Sie uns für Enterprise-Zugang.

playbooks agents orchestration async-execution enterprise
Diesen Artikel teilen

Hat Ihnen dieser Artikel gefallen?

Erhalten Sie Workflow-Tipps, Produktupdates und Automatisierungsleitfäden direkt in Ihren Posteingang.

No spam. Unsubscribe anytime.