Autonomes KI-Nachrichtensystem ohne manuelle Steuerung

## Autonomes KI-News-System: So ersetzen Sie sieben Workflows durch eine einheitliche Architektur

In etwas über anderthalb Monaten verwandelte sich eine fragmentierte News-Pipeline aus sieben n8n-Workflows in ein stabiles System mit 160 Quellen, 11 Workern und 5 KI-Agenten. Nun werden 7127 Datensätze in der Datenbank ohne manuelles Eingreifen verarbeitet, und ein lokales LLM auf einem Mini-PC ersetzt Cloud-APIs. Wir zerlegen die Architektur, die Ausfallpunkte eliminiert und einen 24/7-Betrieb sicherstellt.

Von sieben Ausfallpunkten zu einem einzigen System

Ursprünglich bestand die News-Pipeline aus sieben unabhängigen n8n-Workflows: Datensammlung, Filterung, Übersetzung, Bildgenerierung und Veröffentlichung. Jede Stufe lief isoliert, was zu kaskadierenden Fehlern führte. Ein typisches Problem: Ein Workflow markierte eine Aufgabe als "abgeschlossen", aber die Ausgabe war leer. Da den Stufen kein einheitliches Überwachungssystem fehlte, dauerten Diagnosen stundenlang. Die kritische Schwachstelle war das Fehlen eines einheitlichen Status für jeden News-Artikel. Wenn ein Workflow hängen blieb, verarbeiteten die anderen weiter und erzeugten inkonsistente Daten.

Die Lösung kam nach einer Analyse mit Perplexity und Experimenten mit Claude Code. Statt die Logik manuell in Python umzuschreiben, erhielt der KI-Assistent die Quell-Workflows und architektonischen Anforderungen. In einer Stunde generierte er eine containerisierte Anwendung mit klarer Trennung der Verantwortlichkeiten. Wichtige Änderung: Übergang von triggerbasierten Workflows zu einer zustandsorientierten Pipeline, in der jeder News-Artikel streng definierte Stufen durchläuft, wobei der Status in der Datenbank festgehalten wird.

Lokale Verarbeitung: Warum Qwen 3.5 auf einem Mini-PC

Die Übersetzung von News über Cloud-APIs erwies sich als wirtschaftlich nicht machbar: 160 Quellen, die alle 15 Minuten aktualisiert werden, würden täglich Zehntausende Anfragen erfordern. Die Lösung: Bereitstellung eines lokalen LLM auf einem Heim-Mini-PC mit Ubuntu und Optimierung für Vulkan über llama.cpp. Das Qwen 3.5-Modell (qwen3.5-9b-q5_k_m.gguf) wurde wegen seines ausgewogenen Geschwindigkeits- und Qualitätsverhältnisses für die russische Sprache gewählt.

Die Einrichtung umfasste:

• Feinabstimmung für CPU-Architektur über Cursor
• Kalibrierung der Thread-Anzahl zur Minimierung der Latenz
• Konfiguration des Cachings von Zwischenergebnissen

Das System bewältigt bis zu 50 Anfragen pro Minute, ohne die CPU zu überlasten. Daten verlassen nie das lokale Netzwerk, was für Quellen mit API-Key-Beschränkungen entscheidend ist. Zum Vergleich: Cloud-Übersetzung würde bei aktuellem Volumen ~120 $/Monat kosten, lokal – 0 $ nach der Ersteinrichtung.

Pipeline-Architektur: So arbeiten die 11 Worker

Aufgebaut nach dem Prinzip „ein Prozess – eine Aufgabe“. Jeder Worker ist isoliert, was kaskadierende Fehler verhindert. Verarbeitungsfluss:

collector → scraper → deduplicator → ai_filter → translator
    → llm_editor → image_worker → publisher

collector läuft alle 15 Minuten und parst RSS/API von 160 Quellen (einschließlich arXiv, TechCrunch, GitHub). scraper extrahiert den Volltext über eine lokale Jina Reader-Instanz – das eliminierte Cloud-Service-Limits. deduplicator nutzt semantischen Vergleich basierend auf Embeddings, nicht exakte Textübereinstimmung. ai_filter weist eine relevance_score (0-100) zu und filtert Artikel unter 75 Punkten heraus.

Besondere Aufmerksamkeit galt der llm_editor-Stufe. Dort formatiert MiniMax M2.7 den Text zum Kanal-Stil: Fügt Emojis zu Überschriften hinzu, strukturiert Inhalte, ergänzt Quellenangaben. Das Modell ist auf historische Kanaldaten trainiert und gewährleistet konsistente Formatierung. Alle Worker interagieren über eine Message Queue mit Zustellgarantie, was eine Wiederaufnahme nach Fehlern ab dem letzten Checkpoint ermöglicht.

Verwaltung über KI-Agenten: Von Telegram-Befehlen zu Aktionen

Der auf OpenClaw basierende Koordinator ersetzt die manuelle Verwaltung. Er läuft auf demselben Mini-PC und hat Zugriff auf Tools über API. Das System nutzt 5 spezialisierte Agenten:

• AgentLLMEditor: korrigiert Texte alle 20 Minuten
• AgentPipelineManager: verteilt Posts auf Slots 4-mal täglich
• AgentSourceAuditor: deaktiviert nicht funktionierende Quellen wöchentlich
• AgentAnalyst: erzeugt Analysen um 21:05 Uhr
• Coordinator: verwaltet die anderen Agenten

Ein Telegram-Befehl wie „Coordinator, reduziere Veröffentlichungslimit auf 8 pro Tag“ wird zu einem API-Aufruf an den Pipeline-Manager. Der Agent prüft aktuelle Einstellungen, führt Änderungen durch und bestätigt die Ausführung. Das macht SSH-Zugriff und Kenntnisse der Config-Datei-Syntax überflüssig. Für kritische Operationen (z. B. Deaktivierung einer Quelle) fordert das System eine Bestätigung über einen Human-in-the-Loop (HITL)-Worker an.

Dashboard: Echtzeit-Überwachung

Die Oberfläche kombiniert 9 Tabs: Übersicht, Agenten, Quellen, Warteschlange, Worker, Slots, Veröffentlicht, Einstellungen, GitHub Discovery. Wichtige Metriken:

• Durchlaufquote nach Quellen: Anthropic News (100 %) vs iXBT.com (14 %)
• Stufenverarbeitungszeit: Übersetzung (4 Min.) vs Filterung (2 Min.)
• Worker-Status: aktive/leerlaufende Prozesse

Bei Anomalien (z. B. hängende Übersetzungswarteschlange) erstellt das Dashboard automatisch eine Aufgabe im Telegram-Arbeitsgruppe. Die Integration mit GitHub Discovery verfolgt Repos mit starkem Sternenwachstum – diese Daten werden auf einem separaten Tab mit Aktivitätsdiagramm angezeigt. Das System warnt vor Problemen, bevor sie Veröffentlichungen beeinträchtigen: z. B. wenn die Durchlaufquote einer Quelle eine Woche lang unter 10 % fällt.

Einsparungen durch Auswahl: Von 1000 News-Artikeln zu 8 Posts pro Tag

Das System veröffentlicht nicht alles. ~1000 Artikel pro Woche werden verarbeitet, aber nur 56 Posts gehen online (8 pro Tag). Auswahlkriterien:

• relevance_score ≥ 80 (ai_filter)
• Genehmigt vom LLM-Editor (Status approved)
• Passt zum Tageszeit-Slot

Zeitplan an Zeitzonen gebunden:

• Vormittag (08:00–11:00): 2 Posts
• Tag (12:00–16:00): 2 Posts
• Abend (18:00–22:00): 2 Posts
• Nacht (00:00–06:00): 2 Posts

Früher 28 Posts pro Tag, aber Analysen zeigten, dass Nutzer nur die letzten 1-2 lasen. Nun hat die Volumenreduktion die Retention um 37 % gesteigert – Leser schauen sich alle Posts im Slot an. Durchlaufquoten der Quellen erlauben wöchentliche Listenanpassungen: 20 ineffiziente RSS-Feeds bereits deaktiviert.

Was zählt

• Einheitliches Zustandssystem ersetzt isolierte Workflows: Jeder News-Artikel hat einen klaren Status, was Fehldiagnosen um das 5-Fache beschleunigt.
• Lokale LLMs sparen bis zu 120 $/Monat bei Übersetzung und Bearbeitung, mit Latenz nicht über 4 Minuten bei 50 parallelen Aufgaben.
• KI-Agenten eliminieren manuelle Verwaltung: Telegram-Befehle werden zu API-Aufrufen ohne Beteiligung des Operators.
• Strenge Inhaltsauswahl (8 Posts/Tag statt 28) steigerte die Zuschauerbindung um 37 %, indem Rauschen reduziert wurde.

— Editorial Team