Ein Scheduler ist kein autonomer Redakteur
„Nimm das ursprüngliche Markdown, korrigiere es und veröffentliche es.“
Klingt fast lächerlich einfach.
Bis man versucht, es vollständig zu automatisieren.
Das System muss das Markdown lesen, die Veröffentlichungsreife bewerten, 12 Sprachen prüfen, seltsame Überschriften entfernen, Links kontrollieren, veröffentlichen, die echte Seite öffnen, bei Fehlern zurückgehen, die Ursache finden, reparieren, erneut ausführen und anschließend prüfen, ob die Reparatur nicht an anderer Stelle etwas kaputt gemacht hat.
Plötzlich soll das Fließband auch noch Chefredakteur sein.
Das Problem ist nicht, dass Cloudflare Workers, geplante Aufgaben oder GitHub Actions schlecht wären.
Sie sind für eine andere Art von Arbeit gebaut.
Klassische Automatisierung ist hervorragend darin, bekannte Abläufe zu wiederholen. Eine Content-Pipeline bekommt dagegen jedes Mal andere Texte und oft auch andere Fehler. Dann muss gelesen, verstanden, korrigiert und überprüft werden.
Das ist eher ein Agentenproblem als ein Cron-Problem.
1. Dieselbe Pipeline bedeutet nicht dieselbe Arbeit
Eine Artikelfabrik sieht zunächst nach Massenproduktion aus.
Eingabe: Markdown. Ausgabe: veröffentlichter Artikel.
Also scheint es logisch, denselben Prozess hundertmal zu wiederholen.
Text ist aber kein genormtes Bauteil.
Artikel A hat einen merkwürdigen Titel. Artikel B verliert eine von 12 Sprachversionen. Artikel C ist übersetzt, verwendet aber Suchbegriffe, die lokal niemand benutzt. Artikel D veröffentlicht versehentlich eine interne SEO-Notiz. Artikel E enthält einen gültigen Affiliate-Link an einer redaktionell absurden Stelle. Artikel F wurde korrekt veröffentlicht, steht im System aber weiterhin auf „läuft“.
Alles passiert innerhalb derselben Veröffentlichungspipeline.
Die Reparaturen sind trotzdem verschieden.
Wenn sich die Eingabe jedes Mal ändert, ändert sich auch die Form des Fehlers.
2. Scheduler sind hervorragend bei bekanntem, definiertem Ablauf
GitHub Actions führt vordefinierte Workflows aus, wenn ein Repository-Ereignis eintritt, ein manueller Start erfolgt oder ein Zeitplan erreicht ist.[1]
ChatGPT Scheduled Tasks führt Aufgaben ebenfalls zu gewählten Zeiten oder bei unterstützten Ereignissen aus.[2]
Cloudflare Workers ist stark bei Request-Verarbeitung, periodischer Ausführung und Service-Orchestrierung.
Solche Systeme beantworten sehr gut:
„Wann soll es laufen?“ „Welches Skript soll ausgeführt werden?“ „War der Befehl erfolgreich?“ „Was passiert, wenn diese Bedingung erfüllt ist?“
Anders sind Fragen wie:
„Klingt dieser Titel nach Maschinenübersetzung?“ „Ist dieser Abschnitt zwar korrekt, aber für Leser nutzlos?“ „Der Link funktioniert – aber warum steht er hier?“ „Ist der heutige Fehler wirklich derselbe wie gestern?“
Ein Scheduler hat eine Uhr.
Redaktionelles Bauchgefühl ist nicht automatisch eingebaut.
3. Schwierig ist das vollständige Schließen der Verbesserungsschleife
Nicht die einzelne Änderung ist das Problem.
Der gesamte Zyklus muss funktionieren:
Fehler entdecken, Ursache bestimmen, korrigieren, erneut ausführen, echtes Ergebnis prüfen, Nebenwirkungen suchen, bei Bedarf eine andere Hypothese testen.
Menschen machen das beinahe automatisch.
In einem automatisierten System muss jeder Übergang bewusst entworfen werden.
Besonders unangenehm sind Teilerfolge.
Die Seite ist veröffentlicht, aber der Status wurde nicht aktualisiert.
Die Übersetzung ist fertig, aber eine Sprache blieb leer.
Das Repository wurde geändert, aber Produktion nicht aktualisiert.
Wenn man einfach alles wiederholt, können doppelte Veröffentlichungen entstehen.
Robuste Automatisierung versucht deshalb nicht nur, „niemals zu scheitern“.
Sie versucht:
Wiederholung muss sicher sein.
Cloudflare Workflows unterstützt dauerhafte Schritte, gespeicherte Ergebnisse und Wiederholungen. Die Dokumentation empfiehlt außerdem, Operationen so zu gestalten, dass eine erneute Ausführung keine falschen Nebenwirkungen erzeugt.[3][4]
4. Cloudflare kann Prozesse gut wiederherstellen, aber Wiederherstellung ist kein redaktionelles Urteil
Cloudflare Workflows kann den Zustand mehrstufiger Prozesse erhalten, fehlgeschlagene Schritte wiederholen und nach bereits abgeschlossenen Schritten fortsetzen.[3]
Cloudflare Queues kann Nachrichten erneut zustellen und wiederholt fehlgeschlagene Nachrichten in eine Dead Letter Queue verschieben.[5]
Das ist ideal für:
vorübergehende Netzwerkfehler, API-Ausfälle, Timeouts, Nachrichten, die wiederholt scheitern, Aufgaben, die später fortgesetzt werden müssen.
Aber ein anderer Fehlertyp lautet:
„Der spanische Text ist verständlich, aber so sucht dort niemand.“
Oder:
„Der Inhalt stimmt, aber diese Zwischenüberschrift macht den Artikel schlechter.“
Von drei auf zehn Wiederholungen zu erhöhen, erzeugt kein redaktionelles Urteilsvermögen.
Im schlimmsten Fall wird derselbe Fehler zehnmal beeindruckend zuverlässig wiederholt.
Retry ist kein Denken.
5. GitHub Actions ist eine sehr gute Werkbank, aber kein autonomer Redakteur
GitHub Actions ist hervorragend für deterministische Aufgaben.
Tests ausführen. Dateien prüfen. Builds erstellen. Unter klaren Bedingungen deployen. Skripte regelmäßig starten.
Dafür ist es gebaut.[1]
Actions selbst liest jedoch keinen Artikel und denkt:
„Das eigentliche Problem liegt in der Einleitung, nicht im Titel.“
Natürlich kann ein Workflow ein KI-System aufrufen.
Dann verschiebt sich das schwierige Problem aber zu:
Welchen Kontext bekommt die KI? Was darf sie verändern? Wie wird das Ergebnis geprüft? Wo wird nach einem Fehler fortgesetzt?
Einer Bohrmaschine die Redaktionssitzung zu übergeben und sie danach für ihre Moderation zu kritisieren, wäre etwas unfair.
6. Normalpfad und Ausnahmeweg trennen statt 100 Prozent Automatisierung erzwingen
Eine praktische Content-Fabrik braucht zwei Wege.
Normalpfad: klar prüfbare Dinge automatisieren
Maschinen können kontrollieren:
- Pflichtdateien vorhanden
- alle 12 Sprachen vorhanden
- keine Pflichtfelder leer
- URL-Format korrekt
- IDs eindeutig
- Veröffentlichungsbefehl erfolgreich
- Produktionsseite erreichbar
Workers, Skripte und Actions sind dafür sehr gut.
Ausnahmeweg: Fehler isolieren und weiterarbeiten
Ein fehlerhafter Artikel sollte nicht den ganzen Stapel stoppen.
Grund speichern. Artikel aus dem Hauptfluss nehmen. Mit dem nächsten weitermachen.
Sinnvolle Kategorien:
- Sprache fehlt
- Struktur ungültig
- Linkfehler
- Veröffentlichungsfehler
- inhaltliche Prüfung nötig
- Ursache unbekannt
Wenn 90 von 100 Artikeln automatisch durchlaufen, können diese 90 veröffentlicht werden.
90 gesunde Artikel müssen nicht mit zehn Problemfällen gemeinsam nachsitzen.
Ausnahme überspringen und weitermachen.
7. Die Ausnahmen an einen Agenten geben, der das Repository lesen kann
Ausnahmen brauchen oft Lesen, Schlussfolgern, Bearbeiten und Prüfen.
Dafür passt ein Coding-Agent.
Die Dokumentation von Codex Cloud beschreibt Aufgaben in vorbereiteten Projektumgebungen, in denen Bugs untersucht, Code geändert, Tests ausgeführt und dieselbe Cloud-Aufgabe auf unterstützten Geräten fortgesetzt werden kann.[6]
In einer Content-Fabrik kann der Agent die Reparaturstation sein:
fehlgeschlagenen Artikel holen, ursprüngliches Markdown lesen, generierte Ausgabe ansehen, Fehlerprotokoll lesen, bei Bedarf Code prüfen, korrigieren, Checks ausführen, neu veröffentlichen, Produktionsseite prüfen.
Es ist unnötig, teure Denkfähigkeit auf jeden langweiligen Normalfall zu werfen.
Routine zur Maschine.
Kurioses zum Agenten.
8. Häufige Ausnahmen später in feste Regeln verwandeln
Der Ausnahmeweg darf keine dauerhafte Müllhalde werden.
Wenn derselbe Fehler häufig auftritt, ist er kein Ausnahmefall mehr. Er ist ein Muster.
Fehlt regelmäßig eine Sprache, kommt eine automatische Prüfung hinzu.
Taucht immer dieselbe unerwünschte Überschrift auf, blockiert ein Validator sie.
Gelingt die Veröffentlichung, aber die Statusaktualisierung scheitert oft, wird zuerst Produktion geprüft und anschließend der Status repariert.
Die gesunde Reihenfolge lautet:
Fabrik laufen lassen, echte Fehler sammeln, seltene Fälle vom Agenten reparieren lassen, wiederkehrende Muster erkennen, nur diese Muster automatisieren.
Wer vor der ersten Veröffentlichung jeden denkbaren Fehler vorhersagen will, baut sehr effizient eine Fabrik, die niemals fertig wird.
Fazit: Scheduler sind das Fließband, Agenten die Reparaturstation
Cloudflare, geplante Aufgaben und GitHub Actions wirken enttäuschend, wenn man von ihnen erwartet, autonome Redakteure zu sein.
Die Rollen sind aber verschieden.
Das geplante System soll:
starten, objektive Prüfungen durchführen, Normalfälle weiterleiten, Fehler isolieren, und die Linie am Laufen halten.
Der Agent soll beantworten:
„Warum ist genau dieser Artikel seltsam?“ „Was muss geändert werden?“ „Hat die Reparatur wirklich funktioniert?“
Die praktische Architektur ist einfach:
Den leichten Weg automatisieren. Eine Ausnahme darf nicht den ganzen Stapel blockieren. Nur Ausnahmen zum Agenten schicken. Wiederkehrende Ausnahmen später in Maschinenregeln verwandeln.
Die Content-Fabrik brauchte kein Fließband, das über alles nachdenken kann.
Sie brauchte ein Fließband, das nicht stehen bleibt, und eine intelligente Reparaturstation für die Kartons, die herunterfallen.
Quellen (6)
- GitHub Docs, Workflows docs.github.com
- OpenAI Help Center, Scheduled tasks in ChatGPT help.openai.com
- Cloudflare Docs, Build your first Workflow developers.cloudflare.com
- Cloudflare Docs, Rules of Workflows developers.cloudflare.com
- Cloudflare Docs, Dead Letter Queues developers.cloudflare.com
- OpenAI Help Center, Using Codex Cloud help.openai.com
