Was passiert, wenn eine Betriebswirtin anfängt, KI-Agenten auf einem eigenen Server zu betreiben? Genau das. Dieser Artikel erzählt ehrlich von meinen Experimenten – was funktioniert hat, was nicht, und was ich dabei gelernt habe.
Meine Experimente mit KI-Agenten, Docker und automatisierten Workflows
Was passiert, wenn eine Betriebswirtin anfängt, KI-Agenten auf einem eigenen Server zu betreiben? Genau das. Dieser Artikel erzählt ehrlich von meinen Experimenten – was funktioniert hat, was nicht, und was ich dabei gelernt habe.
Der erste Schritt war der mutigste: Ein KI-Agent, der nicht nur antwortet – sondern selbst denkt, plant und handelt. OpenClaw ist ein autonomes Agenten-Framework, das ich auf meinem eigenen Server in einem Docker-Container betreibe.
Das Besondere daran: Der Agent läuft komplett lokal – kein OpenAI-API-Key, keine monatlichen Kosten. Als Gehirn dient Qwen 2.5 (1.5B), ein Open-Source-Sprachmodell, bereitgestellt über Ollama. Klein, schnell, und überraschend fähig.
OpenClaw hat eine eigene Persönlichkeit – definiert in einer SOUL.md-Datei.
Verhaltensregeln in AGENTS.md, ein Gedächtnis in täglichen Log-Dateien
und eine SQLite-Datenbank. Es ist wie ein Mini-Betriebssystem für einen KI-Assistenten.
Was mich am meisten fasziniert hat: Der Agent entscheidet selbst, wann er handelt und wann er fragt. Interne Aktionen (lesen, analysieren, planen) führt er eigenständig aus. Externe Aktionen (E-Mails senden, Posts veröffentlichen) – da wartet er auf meine Bestätigung. Das ist verantwortungsvolle KI.
docker-compose up
fühlt es sich ganz normal an. Das Schwierigste war nicht die Technik –
sondern zu verstehen, wie ein Agent denken soll.
Das zweite große Experiment: Kann ich meinen Instagram-Content automatisieren? Ideen generieren lassen, Scripts schreiben lassen, und ich bestätige nur noch per Telegram-Knopfdruck?
Die Antwort: Ja – und es funktioniert mit einem beeindruckenden KI-Stack, der komplett kostenlos ist.
Der Workflow besteht aus zwei n8n-Pipelines:
Der nächste Schritt ist die automatische Video-Generierung mit Veo 3 (Google AI Studio). Das Ziel: Vom Knopfdruck bis zum fertigen Reel – vollautomatisch. Ein Traum? Vielleicht. Ein erreichbares Ziel? Definitiv.
Eines Abends auf der Couch fiel mir ein, dass meine Website noch einen Tippfehler hat. Früher hieß das: Laptop hochfahren, einloggen, Editor auf, Datei finden, fixen, deployen. Heute öffne ich nur Telegram und tippe: „Bitte den Tippfehler im Impressum korrigieren – statt ‚Strase' soll da ‚Straße' stehen." Zwei Minuten später vibriert das Handy: „Erledigt."
Was dazwischen passiert, ist meine kleine Lieblings-Pipeline. Die Telegram-Nachricht landet über einen Bot in einem n8n-Workflow, der sie als Markdown-Datei in einen Inbox-Ordner auf meinem VPS schreibt. Ein systemd-Watcher pollt diesen Ordner alle paar Sekunden. Findet er etwas Neues, startet er Claude Code – mit der Aufgabe als Eingabe und vollem Zugriff auf alle meine Projekte. Wenn Claude fertig ist, feuert ein Stop-Hook einen Webhook ab, der mir das Ergebnis wieder per Telegram schickt.
Anfangs hatte ich noch ein lokales Ollama-Modell als Zwischenglied eingebaut – es sollte meine Telegram-Nachrichten in „saubere Tasks" umformulieren. Klang clever, war in der Praxis ein Problem: Das Modell brauchte 4,3 GB RAM, mein VPS hat 3,4 GB frei. Jeder zweite Aufruf kippte mit Memory-Error.
Die ehrliche Erkenntnis: Claude Code selbst ist das smarte LLM. Warum ein zweites, kleineres Modell davor versuchen lassen, etwas zu „verstehen", was Claude besser kann? Also Ollama wieder rausgeworfen. Seitdem läuft alles stabil – und schneller.
Wer mit Claude oder einem anderen KI-Assistenten arbeitet, kennt das Problem: Jede neue Session ist ein leeres Blatt. „Erkläre mir nochmal, was LernyTube ist." „Wo liegt das Whisky-Projekt nochmal?" Auf Dauer mühsam.
Die Lösung kommt aus einem Standard, der gerade groß rauskommt: Model Context Protocol (MCP). Der Hersteller meines Assistenten hat ihn definiert, damit man Tools von außen einbinden kann. Genau das habe ich gemacht – nur eben nicht für ein bestimmtes Tool, sondern für alle meine Projekte gleichzeitig.
Auf mcp.eiskopani.de läuft ein eigener kleiner
Server, der alle vier Projektverzeichnisse (LernyTube,
Whisky-Kuratorium, EIS Schuh-Atelier, vita.eiskopani) read-only
eingebunden hat und Tools wie list_projects,
read_project_file, list_tasks und
run_shell bereitstellt. Authentifizierung läuft
über ein Secret im URL-Query, HTTPS macht Traefik mit
Let's-Encrypt-Zertifikat.
Effekt: Jede neue Session weiß sofort, woran ich gerade arbeite, wo welcher Code liegt und was offene Aufgaben sind. Kein Briefing mehr nötig, keine wiederholten Erklärungen.
Aus einem Use-Case im öffentlichen Sektor kam die Idee für mein bisher größtes KI-Experiment: ein System, das iterativ E-Mail-Umfragen verschickt, die Antworten frei formuliert entgegennimmt, daraus strukturierte Daten extrahiert – und einen Menschen entscheiden lässt, ob die Auswertung passt.
Statt direkt einen Outlook-Connector zu bauen, habe ich den E-Mail-Teil komplett simuliert: „Versenden" ist ein Statusupdate, „Antwort eingeht" ist ein Browser-Formular. Dafür ist die KI-Auswertung echt: Jede simulierte Antwort geht durch einen Claude-API-Call, der daraus Kernaussage, Bewertung, Handlungsbedarf, Vollständigkeit und Stichworte extrahiert.
Spannend wurde es beim Human-in-the-Loop: Jede
KI-Extraktion landet zuerst im Status PENDING. Erst
nach manueller Freigabe geht die Antwort in die Auswertung. Wird
sie abgelehnt, ist die Extraktion verworfen. Ein simpler, aber
wichtiger Schritt: Die KI macht einen Vorschlag, kein Urteil.
Die ganze Geschichte mit Screenshots habe ich in einem eigenen Beitrag dokumentiert – inklusive der unangenehmen Lehre am Ende (siehe Kapitel 9).
Auf meiner Hobbyseite läuft ein Retro-Musikplayer mit 25 Songs. Klingen kann man sich anhören – schreiben tut sie eine KI, geträllert wird sie von einer KI, und auf den Server transportiert habe ich sie über einen kleinen Selbstbau-Upload-Proxy.
Erst kommt der Text: Das Thema gebe ich vor, eine Sprach-KI dichtet daraus eine Strophe samt Refrain. Dann der Klang: Suno macht aus dem Text einen vollständigen Song mit Stimme und Instrumenten. Der Output landet als MP3 auf meinem Rechner.
Damit ich Songs nicht jedesmal manuell hochladen muss, habe ich mir eine kleine Admin-Seite gebaut: Datei reinziehen, klicken, fertig. Im Hintergrund schickt sie die MP3 an einen Upload-Proxy auf dem VPS, der sie per SFTP zu Hostinger weiterreicht. Auth über einen Bearer-Token – und seit Kurzem mit Rate-Limit auf Traefik-Ebene, weil 50-MB-Bodies plus ungeschützter Auth-Endpoint ein klassisches DoS-Risiko sind.
Wer gerne lernt, kennt das Problem mit Recherche: Zwanzig Tabs offen, fünf PDFs herumliegen, am Ende weiß man nicht mehr, wo man die wichtige Stelle gesehen hat. NotebookLM von Google ist hier wirklich gut – man wirft Quellen rein, stellt Fragen, bekommt Antworten mit Zitaten. Aber: Die Web-Oberfläche ist langsam, wenn man viel macht.
Also habe ich mir notebooklm-py installiert, ein
CLI-Tool, mit dem ich vom Terminal aus Notebooks anlegen, Quellen
ergänzen und Fragen stellen kann. Login einmalig per Browser,
Storage-State gespeichert, ab da läuft alles im Skript.
Effekt: Ich kann meinen KI-Assistenten anweisen, eine Recherche in einem Notebook anzulegen, mehrere Quellen einzubinden und am Ende eine Zusammenfassung als Markdown zurückzugeben. Ohne dass ich selbst klicken muss. Für Projektrecherche ein riesiger Zeitgewinn.
Lange Zeit war „Tests schreiben" für mich das, was man bei den Profis macht und bei einem Lernprojekt sicher erstmal weglassen kann. Bis ich an einem Tag meine drei Hauptprojekte (LernyTube, Whisky-Kuratorium, EIS Schuh-Atelier) komplett mit Tests unterfüttert habe – Unit, Integration, End-to-End. Insgesamt 127 Tests.
Dazu jeweils eine GitHub-Actions-Pipeline, die auf jeden Push losläuft: Tests, Linter, Coverage-Report. Plötzlich gab es einen grünen Haken oder ein rotes X – und ich konnte nicht mehr so tun, als wüsste ich nicht, dass ich gerade etwas kaputtgemacht habe.
Die Erkenntnis kam beim Refactoring: Ich habe in der Whisky-App eine Funktion umgebaut, die ich seit Wochen nicht angefasst hatte. Drei Tests sind sofort rot geworden. Ohne die hätte ich das Problem erst Tage später bemerkt – wenn überhaupt.
Beim Umfrage-Projekt (Kapitel 5) hatte ich am Ende stolze 67 Tests, davon 26 explizit als Security-Tests, dazu Bandit (statische Code-Analyse) und Safety (CVE-Scan) in der CI-Pipeline. Alles grün. Trotzdem fragte mich mein Sparringspartner: „Hast du an die Sicherheit gedacht?" – und hatte recht.
Drei Lücken, die mir trotz aller Tests durchgegangen sind:
docker-compose.yml. Nicht im
Git-Repo, aber auf dem Server für jeden mit Zugriff lesbar.
innerHTML ins Dashboard. Wenn die
KI bösartige HTML-Tags zurückgegeben hätte (oder ein
Angreifer sie über den Eingabetext eingeschleust hätte), wäre
JavaScript im Browser ausgeführt worden.
X-Frame-Options, keine
X-Content-Type-Options. Klassische Hygienefehler.
Die Fixes waren je 5–20 Zeilen Code. Aber das ist nicht der Punkt. Der Punkt ist: Ich hätte sie alle vermeiden können, wenn ich Security als eigene Phase behandelt hätte – nicht als Häkchen am Ende, das durch grüne Tests gesetzt wird.
KI ist kein Zaubertrick – es ist ein Werkzeug. Und wie jedes gute Werkzeug muss man lernen, es richtig einzusetzen. Meine Experimente haben mir gezeigt: Man braucht kein Informatikstudium, um KI produktiv einzusetzen. Man braucht Neugier, Geduld und die Bereitschaft, Fehler zu machen.
Ich mache weiter. Denn jedes Scheitern war ein Lernmoment – und jeder Erfolg hat mich noch hungriger gemacht.
Austauschen? Schreib mir!