APPLIED AI · AUTOMATIONMVP · aktive Entwicklung

X Bot: Kontrollierte KI-Automation für Social Media

Ein Python-System, das Inhalte generiert, die X-Timeline und Benachrichtigungen verarbeitet und alle Abläufe über Zustände, Limits, Deduplizierung und ein geschütztes Dashboard kontrollierbar hält.

LangGraph-Abläufe: 4
geplante Jobtypen: 5
getrennte Docker-Dienste: 2

AUSLÖSER

ZeitplanX TimelineBenachrichtigungen

LANGGRAPHVier getrennte Abläufe

Generieren + prüfenLesen + bewertenAntwortenInspiration

ZUSTAND & GEDÄCHTNIS

ChromaDBJSON · SQLite

EXTERNE AKTIONEN

Selenium → XLesen · Posten · Antworten

BEDIENUNG & EINBLICK

FastAPI + HTMXStatus · Logs · Einstellungen

KONTROLLMECHANISMEN

TageslimitsÄhnlichkeitsprüfungJob-SperrePause / ResumeAuth + Logs

Vereinfachte, aus dem aktuellen Quellcode abgeleitete Architektur – keine Darstellung eines Produktivbetriebs.

Ausgangslage

Autonome Social-Media-Abläufe bestehen nicht nur aus Textgenerierung. Das System muss Quellen lesen, Relevanz bewerten, Wiederholungen verhindern, Aktionen zeitlich koordinieren und trotz externer Browser-Automation beobachtbar und stoppbar bleiben.

Ziel und Randbedingungen

Ziel war ein betreibbares MVP, das Generierung, Timeline-Lesen, Interessensbewertung, Benachrichtigungen und Antworten in getrennten Abläufen orchestriert – mit persistentem Zustand, Tageslimits und einer Oberfläche für Beobachtung und Eingriffe.

Aufgabe und eigene Rolle

Eigenprojekt: Konzeption und Entwicklung der Python-Architektur, LangGraph-Abläufe, LLM- und Browser-Integration, Zustands- und Speicherschicht, Scheduler, Dashboard, Containerisierung und technische Dokumentation.

Systemübersicht und Abhängigkeiten

Vier LangGraph-Abläufe für Generierung, Timeline-Auswertung, Benachrichtigungen und Antworten
Fünf APScheduler-Jobs für Beiträge, Lesen, Benachrichtigungen, Antworten und inspirationsbasierte Inhalte
ChromaDB für Ähnlichkeitssuche sowie JSON und SQLite für Laufzeitstatus und historische Analysedaten
Selenium als gekapselte Schnittstelle für Lesen, Posten und Antworten auf X
FastAPI-Dashboard mit HTMX für Status, Beiträge, Analytics, Logs, Einstellungen und Scheduler-Steuerung

Lösung und wichtige Entscheidungen

Mehrere LLM-Anbieter sind hinter einem gemeinsamen Client gekapselt; Fallbacks bleiben konfigurierbar
Generierte Beiträge durchlaufen Ähnlichkeitsprüfung und eine zweite modellbasierte Bewertungsstufe vor dem Posten
Eine globale Ausführungssperre und eine deduplizierte Warteschlange verhindern parallele Scheduler-Jobs
Konfigurierbare Tageslimits begrenzen Beiträge und Antworten; Zähler werden persistent geführt
Das authentifizierte Dashboard macht Status und Logs sichtbar und kann alle Jobs pausieren, fortsetzen oder neu konfigurieren

Ergebnis oder Zwischenstand

Der aktuelle Repo-Stand implementiert die Kernarchitektur als zusammenhängendes MVP und lässt sich lokal oder als zwei Docker-Dienste für Bot und Dashboard starten. Belegt sind Systemumfang und technische Entscheidungen – nicht Reichweite, Geschäftswirkung oder ein dauerhaft stabiler Produktionsbetrieb.

Grenzen, Daten, Sicherheit und Betrieb

Selenium hängt von einer veränderlichen externen Oberfläche ab; Selektoren, Login und Plattformregeln bleiben Betriebsrisiken.
Ähnlichkeitsprüfung und Modellbewertung sind technische Gates, aber keine menschliche Freigabe vor jedem Beitrag.
Ein reproduzierbarer Test-, Sicherheits- und Langzeitbetriebsnachweis ist im aktuellen Repo-Stand noch offen.
Zugangsdaten, Cookies und Dashboard-Konfiguration benötigen vor einem öffentlichen Betrieb eine gehärtete Secret- und Deployment-Strategie.

Wichtigste Erkenntnis

Der belastbare Teil eines Agentensystems entsteht außerhalb des Prompts: durch getrennte Abläufe, persistenten Zustand, begrenzte Aktionen, beobachtbaren Betrieb und eine konkrete Möglichkeit zum Eingreifen.