Cloudflare Workflows: Durable Execution KI-Agenten

Im Jahr 2026, in dem autonome KI-Agenten (Autonomous AI Agents) zum Standard geworden sind, besteht die größte Hürde bei der Einführung von KI-Agenten in Produktionsumgebungen von Unternehmen in kurzen Serverless-Timeouts (HTTP-Einschränkungen von 30 Sekunden bis 5 Minuten) und der Unmöglichkeit der Wiederherstellung des gesamten Workflows bei Fehlschlagen externer API-Aufrufe. Wenn Prozesse wie LLM-Inferenz, Web-Browsing, Code-Ausführung und menschliche Genehmigungen (Human-in-the-loop) Minuten oder Stunden dauern, geht bei herkömmlichen ephemeren Lambda-/Worker-Funktionen der Speicherstatus verloren, oder der gesamte Ablauf wird bei einem erneuten Versuch sinnlos ab dem ersten Schritt erneut ausgeführt.

Eine Technologie, die veröffentlicht wurde, um dieses Problem grundlegend zu lösen, ist die Durable Execution (dauerhafte/robuste Ausführung)-Pipeline von Cloudflare Workflows.

Dieser Artikel nutzt Cloudflares neueste Edge-Orchestrierungs-Engine Cloudflare Workflows, um den Status jedes Schritts automatisch per Checkpointing zu sichern, selbst bei Netzwerkunterbrechungen oder Agenten-Stopps. Er garantiert 50.000 gleichzeitige Ausführungen und implementiert nahtlos einen Enterprise-Multi-Agenten-Workflow, der mit dem Cloudflare Agents SDK Guide und dem DeepSeek-R1 MLX Guide verknüpft ist.

Wesentliche Zusammenfassung

• Durable Execution: Alle step.do()-Ausführungsergebnisse des Agenten-Workflows werden automatisch per Checkpoint gesichert, sodass bei Serverausfällen oder API-Fehlern sofort ab dem letzten erfolgreichen Punkt wiederhergestellt (Hydrate) wird.
• Vollständige Aufhebung von Serverless-Timeouts: Befreit von den Beschränkungen einzelner HTTP-Anfrage-Timeouts sind langlaufende (Long-running) KI-Agenten-Aufgaben möglich, die Tage oder Wochen warten.
• Human-in-the-loop & Genehmigungswarten: Über step.sleep() und das Warten auf externe Ereignisse bleibt der Warte-Modus bei $0 Rechenkosten aufrecht, bis die menschliche Freigabe erfolgt.
• Überragende Skalierbarkeit: Unterstützt die Erstellung von 300 Instanzen pro Sekunde und 50.000 gleichzeitige Ausführungen (Concurrent Instances), was die Kosten um über 80 % im Vergleich zu AWS Step Functions senkt.

1. Ephemere Agenten vs. Durable Execution Architektur

Dies ist der entscheidende Unterschied zwischen herkömmlichen funktionalen Agenten und Cloudflare Workflows.

[Herkömmliche ephemere Agenten-Architektur] ❌
[Step 1: LLM-Planung] ──► [Step 2: Web-Crawling] ──► [Step 3: Timeout/Fehler bei Code-Ausführung!]
                                                          ▼
                                            Gesamter Prozess verloren & Neustart ab Step 1 (Kosten-/Zeitverschwendung)

[Cloudflare Workflows Durable Execution] ⭕️
[Step 1: LLM-Planung] (Checkpointing)
         ▼
[Step 2: Web-Crawling] (Checkpointing)
         ▼
[Step 3: Störung bei Code-Ausführung] ──► Automatische Wiederherstellung (Hydrate) ──► Nur Step 3 erneut versuchen & abschließen!

2. Die 4 Kernelemente der Cloudflare Workflows Orchestrierung

Dies ist die Kern-Primitiven-Konfiguration gemäß der offiziellen Entwicklerdokumentation von Cloudflare Workflows.

1. WorkflowEntrypoint: Einstiegspunkt-Klasse des gesamten Workflows (erbt von der Klasse Workflow).
2. step.do(): Schritt-Einheit einer einzelnen Transaktion. Bei Erfolg wird das Ergebnis dauerhaft gespeichert und eine erneute Ausführung dieses Schritts wird umgangen.
3. step.sleep(): Warte-Schritt, der für eine bestimmte Zeit anhält und dabei Compute-Ressourcen freigibt (Kosten: $0).
4. step.sleepUntil(): Wartet im Leerlauf bis zu einem bestimmten zukünftigen Zeitpunkt oder bis zum Empfang eines Ereignisses (Human Approval).

3. Praxis-Code: Autonomer Forschungs- & Berichtserstellungs-Agent

Hier ist der vollständige TypeScript-Implementierungscode für einen Durable AI Agent Workflow, der sich von Web-Recherche ➔ Analyse ➔ Menschliche Genehmigung ➔ Versand des finalen Berichts erstreckt.

import { WorkflowEntrypoint, WorkflowEvent, WorkflowStep } from 'cloudflare:workers';

interface Env {
  AI: any;
  MY_WORKFLOW: Workflow;
}

interface AgentParams {
  topic: string;
  requesterEmail: string;
}

export class ResearchAgentWorkflow extends WorkflowEntrypoint<Env, AgentParams> {
  async run(event: WorkflowEvent<AgentParams>, step: WorkflowStep) {
    const { topic, requesterEmail } = event.payload;

    // Step 1: Erstellung eines LLM-basierten Sub-Rechercheplans (Checkpoint 1)
    const researchPlan = await step.do('generate-research-plan', async () => {
      const response = await this.env.AI.run('@cf/meta/llama-3.3-70b-instruct', {
        messages: [
          { role: 'system', content: 'Sie sind eine Chef-Forscher-KI. Extrahieren Sie 3 Unterthemen zur Untersuchung.' },
          { role: 'user', content: `Thema: ${topic}` },
        ],
      });
      return response.response;
    });

    // Step 2: Externes API-Crawling und Datenerfassung (Checkpoint 2)
    // Selbst wenn bei diesem Schritt ein externes API-Timeout auftritt, wird Step 1 nicht erneut ausgeführt
    const collectedData = await step.do('crawl-web-sources', async () => {
      const searchResults = await fetch(`https://api.search-provider.com/v1/search?q=${encodeURIComponent(topic)}`);
      return await searchResults.json();
    });

    // Step 3: Erster Entwurf des KI-Syntheseberichts (Checkpoint 3)
    const draftReport = await step.do('synthesize-report-draft', async () => {
      const summary = await this.env.AI.run('@cf/meta/llama-3.3-70b-instruct', {
        messages: [
          { role: 'system', content: `Fügen Sie die gesammelten Daten zusammen und erstellen Sie einen technischen Bericht mit 3.000 Zeichen.` },
          { role: 'user', content: `Plan: ${researchPlan}\nDaten: ${JSON.stringify(collectedData)}` },
        ],
      });
      return summary.response;
    });

    // Step 4: Leerlauf-Warten für 24 Stunden auf menschliche Überprüfung und Genehmigung ($0 Kosten)
    // Belegt während dieser Wartezeit keinen Server-Speicher
    await step.sleep('wait-for-human-approval', '24 hours');

    // Step 5: E-Mail-Versand des finalen Berichts (Checkpoint 4)
    await step.do('send-final-email', async () => {
      await fetch('https://api.email-service.com/v1/send', {
        method: 'POST',
        headers: { 'Content-Type': 'application/json' },
        body: JSON.stringify({
          to: requesterEmail,
          subject: `[Abgeschlossen] ${topic} KI-Synthese-Recherchebericht`,
          body: draftReport,
        }),
      });
    });

    return { status: 'completed', topic, timestamp: new Date().toISOString() };
  }
}

export default {
  async fetch(request: Request, env: Env): Promise<Response> {
    const url = new URL(request.url);
    if (url.pathname === '/start-agent') {
      const { topic, email } = await request.json<{ topic: string; email: string }>();

      // Erstellung der Durable Workflow-Instanz und Ausführungstrigger
      const instance = await env.MY_WORKFLOW.create({
        params: { topic, requesterEmail: email },
      });

      return Response.json({ instanceId: instance.id, status: 'started' });
    }
    return new Response('Not Found', { status: 404 });
  },
};

4. Leistungs- und Kosten-Benchmark: Cloudflare Workflows vs. AWS Step Functions

Dies sind die Benchmark-Ergebnisse bei der Verarbeitung von 1 Million langlaufenden KI-Agenten-Workflows pro Monat.

In Kombination mit dem Migrationsleitfaden von AWS Lambda zu Cloudflare Workers und dem Cloudflare AI Gateway Kostenkontroll-Leitfaden können die gesamten Infrastruktur-Betriebskosten drastisch um mehr als 80 % gesenkt werden.

5. Dynamic Workflows: Dynamische Isolierung von Multi-Tenant-KI-Agenten

Mit den 2026 aktualisierten Dynamic Workflows können SaaS-Plattformen unterschiedliche LLM-Prompt-Regeln oder Agenten-Pipeline-Codes für jeden Kunden (Tenant) sicher injizieren.

// Beispiel für die Erstellung einer dynamischen Agenten-Workflow-Instanz pro Tenant
const tenantWorkflow = await env.DYNAMIC_WORKFLOWS.get(tenantId);
const instance = await tenantWorkflow.create({
  params: { customPrompt: tenantConfig.prompt, payload },
});

Durch dieses Muster bleibt der Ausführungsstatus des Agenten jedes Tenants selbst in einer Multi-Tenant-Umgebung vollständig isoliert (Isolated), und Fehlfunktionen einzelner Agenten beeinträchtigen nicht das Gesamtsystem.

6. Best-Practice-Checkliste für die Enterprise-Einführung

Häufig gestellte Fragen

Stoppt der gesamte Workflow, wenn innerhalb von step.do() ein Fehler auftritt?

Standardmäßig wird nur der jeweilige Schritt erneut versucht (Retry). Wenn die festgelegte maximale Anzahl an Wiederholungsversuchen überschritten wird, können Sie über einen try-catch-Block zu einem Ausweichschritt (Fallback) umleiten oder sicher in einen Workflow-Fehlerstatus wechseln.

Werden im Wartezustand (Sleep) wirklich keinerlei Serverkosten berechnet?

Ja, es ist zu 100 % kostenlos. Wenn step.sleep() ausgeführt wird, wird die betreffende Workflow-Instanz vollständig aus dem Speicher des Edge-Servers entfernt (Dehydrate). Erst wenn die angegebene Zeit erreicht ist, stellt die Edge-Engine den Status wieder her (Hydrate) und setzt den nächsten Schritt fort.

Wie werden das Cloudflare Agents SDK und Cloudflare Workflows zusammen verwendet?

Echtzeit-WebSocket-Gespräche mit Benutzern und die Kurzzeitspeicher-Verwaltung werden vom Agents SDK (Durable Objects) übernommen, während langlaufende Prozesse wie Recherche, externe API-Batch-Verarbeitung und Zahlungsfreigaben an Workflows delegiert werden. Diese hybride Architektur ist die Best Practice für 2026.

Ist die Migration von bestehendem Temporal- oder AWS Step Functions-Code einfach?

Da die konzeptionelle Struktur (Step, Sleep, Retry) identisch ist, ist es sehr einfach. Anstelle von bestehenden JSON-Definitionen oder komplexen YAML-Dateien können Sie die gewohnte Intuitivität von TypeScript-Code nutzen, was die Entwicklerproduktivität mehr als verdoppelt.