Was ist ein Worker?
Ein Worker ist ein spezialisierter KI-Agent, der eigenständig Aufgaben für dich erledigt. Anders als ein Chatbot wartet er nicht auf deine Eingabe – er arbeitet selbstständig nach einem definierten Plan. Worker können:
- Recherchen durchführen und Ergebnisse zusammenfassen
- Dokumente analysieren und Berichte erstellen
- Daten aus verschiedenen Quellen sammeln und aufbereiten
- Wiederkehrende Aufgaben automatisieren
- Im Team mit anderen Workern zusammenarbeiten
Voraussetzungen
Bevor du startest, stelle sicher, dass du folgendes hast:
- Einen aktiven HYPDB.ONE Account — es gibt kein kostenloses Konto. Die vier Tarife kosten 39 / 99 / 199 / 399 EUR monatlich, jeder mit 14 Tagen Testphase (Preise werden geladen …)
- Zugang zur Laufzeitumgebung dieser Website unter www.hypdb.one — app.hypdb.one wird geprüft …
- Ein definiertes Ziel für deinen ersten Worker
Die Schritte 1 bis 7 beschreiben den gedachten Ablauf über eine Worker-Oberfläche. Diese Oberfläche ist auf dem Server nicht vorhanden: die naheliegenden Routen /api/worker, /api/workers, /api/sources, /api/testlauf, /api/runs und /api/dashboard antworten alle mit 404. Die Schritte bleiben als Zielbild stehen, damit du weißt, was ein Worker kann — aber keiner der genannten Knöpfe lässt sich anklicken. Was heute tatsächlich läuft, steht weiter unten gemessen: /api/automation (48 Aufträge) und die Statusdatei.
Starte mit einem einfachen Ziel, z. B. "Tägliche Zusammenfassung der wichtigsten Tech-News". So lernst du den Workflow ohne Überforderung.
Schritt 1: Worker erstellen
Neuen Worker anlegen
Zielbild — die Oberfläche existiert noch nicht. Öffne das Dashboard und klicke auf Worker → Neuen Worker erstellen. Gib deinem Worker einen Namen, z. B. "News-Rechercheur" oder "Tagesbericht".
Wähle eine Kategorie, die am besten zu deiner Aufgabe passt: Recherche, Analyse, Dokumentation, Kommunikation oder Automatisierung. Die Kategorien, die der Dienst heute ausliefert, sind Automatisierung, Chat, Content, Kommunikation — werden geladen … Über Recherche und Analyse als Oberflächen-Kategorie gibt es keinen Beleg.
Schritt 2: Ziel definieren
Arbeitsanweisung formulieren
Beschreibe so genau wie möglich, was der Worker tun soll. Je präziser die Anweisung, desto besser das Ergebnis.
Beispiel für einen Recherche-Worker:
Neuigkeiten zu KI-Agenten. Fasse die wichtigsten
3 Artikel in je 3 Sätzen zusammen. Speichere das
Ergebnis als Markdown-Datei im Ordner 'Tagesberichte'."
Schritt 3: Quellen anbinden
Datenquellen konfigurieren
Worker können auf verschiedene Quellen zugreifen:
- Webseiten & RSS-Feeds – für regelmäßige Recherchen
- Dateien & Dokumente – PDF, Markdown, Textdateien
- APIs – für Daten aus externen Diensten
- Notizen & Wissensdatenbanken – deine eigenen Inhalte
Zielbild. Klicke auf Quellen verwalten und füge die gewünschten Quellen hinzu. Für den Einstieg reicht eine Web-Quelle. Gemessen: eine Route zum Anlegen von Quellen gibt es nicht — /api/sources und /api/quellen antworten 404. Quellen hängst du heute nicht über eine Oberfläche an, sondern im Skript des Auftrags.
Nutze RSS-Feeds von Tech-Seiten als erste Quelle. Sie liefern strukturierte Daten und sind einfach einzurichten. Suche einfach nach "[Seitenname] RSS Feed" im Web.
Schritt 4: Zeitplan festlegen
Ausführungsintervall wählen
Bestimme, wann und wie oft dein Worker arbeiten soll:
- Einmalig – für einmalige Aufgaben
- Stündlich – für aktuelle Updates
- Täglich – für Zusammenfassungen und Berichte
- Wöchentlich – für regelmäßige Analysen
- Benutzerdefiniert – für individuelle Zeitpläne
Wähle das Intervall, das zu deiner Aufgabe passt. Für einen ersten Test empfiehlt sich täglich.
Gemessen: Die Zeitpläne der 48 laufenden Aufträge sind Cron-Ausdrücke (*/30 * * * *, 0 9 * * *) und Intervalle in der Kurzform every 5m / every 120m, dazu einmalige Termine (once at …). every 5m ist in einer crontab ungültig — dieser Worker liest es, eine Crontab nicht. Zeitpläne werden geladen …
Schritt 5: Ausgabeformat definieren
Ergebnis festlegen
Lege fest, in welcher Form der Worker seine Ergebnisse liefern soll:
- Dashboard-Benachrichtigung – direkt im HYPDB.ONE Dashboard
- Datei – speichern als Markdown, HTML oder PDF
- Telegram – Nachricht in deinen Chat-Kanal
E-Mail und Discord fallen weg: /api/discord und /api/telegram antworten 404, und keiner der 48 Aufträge führt ein Zustell-Feld — die Schnittstelle kennt enabled, state, schedule, typ, profile, script, last. Welcher Kanal eine Meldung bekommt, steht damit in keiner Route dieser Website — es wird nichts versprochen, was nicht ablesbar ist (Felder werden geladen …). Auch Dashboard-Benachrichtigung ist keine belegte Oberfläche: dafür gibt es keine Route.
Schritt 6: Testlauf starten
Worker testen
Bevor der Worker in den regulären Betrieb geht, starte einen Testlauf:
- Zielbild. Klicke auf Jetzt testen im Worker-Dashboard
- Der Worker führt die Aufgabe einmalig aus
- Prüfe das Ergebnis auf Vollständigkeit und Qualität
- Passe bei Bedarf die Arbeitsanweisung an
Erst wenn das Testergebnis zufriedenstellend ist, aktiviere den Worker mit In Betrieb nehmen.
Gemessen: diese beiden Knöpfe gibt es nicht. /api/testlauf, /api/test und /api/runs antworten 404. Ein Testlauf auf Zuruf ist nicht verfügbar — getestet wird über den schedule des Auftrags, und der letzte Lauf steht im Feld last.
Ein Testlauf verbraucht keine Cron-Job-Ressourcen. Nutze diese Funktion ruhig mehrmals, bis die Arbeitsanweisung perfekt sitzt. Qualität vor Geschwindigkeit.
Belegt ist diese Aussage nicht: es gibt keinen abrufbaren Testlauf, also auch keine gemessenen Kosten dafür. Die tatsächlichen Betriebskosten stehen in den Ressourcen — /api/status meldet load (1/5/15-Minuten-Last) und temperatur, /api/automation meldet ressourcen mit cpu_pct, ram_pct und disk_pct (Werte werden geladen …).
Schritt 7: Überwachung & Optimierung
Worker im Betrieb beobachten
Nach der Aktivierung kannst du deinen Worker im Dashboard überwachen:
- Status – siehst du, ob der Worker läuft oder pausiert
- Letzte Ausführung – wann der Worker zuletzt aktiv war
- Ergebnis-Historie – alle bisherigen Ausgaben auf einen Blick
- Fehlerprotokoll – falls etwas schiefgeht, siehst du es hier
Optimiere die Arbeitsanweisung basierend auf den ersten Ergebnissen. Mit der Zeit wird dein Worker immer besser.
Gemessen: Diese vier Punkte gibt es — aber nicht im Dashboard, sondern in /api/automation: state (aktiv / Fehler / pausiert / geplant), last für den letzten Lauf und protokolle als Protokoll Liste. Die Historie einzelner Ergebnisse je Auftrag führt die Schnittstelle nicht — dafür gibt es kein Feld. Zustände werden geladen …
Welche Bausteine es aktuell wirklich gibt
Damit du die Anleitung nicht theoretisch liest, hier die Bausteine, die auf dieser Plattform aktuell tatsächlich vorhanden und abrufbar sind. Die Werte werden beim Laden der Seite aus /assets/data/agenten_status.json gelesen. Steht das Backend nicht, bleiben die zuletzt geschriebenen Werte der Datei stehen – erfunden wird nichts.
| Baustein | Zustand | Details |
|---|---|---|
| Cron-Automation | – | – |
| Recherche | – | – |
| Content-Pipeline | – | – |
| Social-Media | – | – |
| Chat-Agent | – | – |
| Messaging | – | – |
Quelle: assets/data/agenten_status.json – der Status-Writer läuft alle 5 Minuten und schreibt die Datei neu. Der Zeitstempel in der Datei ist der Zeitpunkt der letzten Messung, nicht der Zeitpunkt deines Seitenaufrufs. Messung wird geladen…
Was heute tatsächlich läuft — 48 Aufträge, live gemessen
Das ist der Teil der Anleitung, der nicht vom Bildschirm abhängt. Die folgenden Werte werden beim Laden aus /api/automation gelesen — der einzigen Schnittstelle, die Aufträge, Zustände, Zeitpläne, Protokolle und Dienste wirklich ausliefert. Messung läuft …
| Kennzahl | Wert | Quelle |
|---|---|---|
| Aufträge gesamt | – | aufgaben.length |
| state: aktiv | – | state === "aktiv" |
| enabled: true | – | enabled === true |
| state: Fehler | – | state === "Fehler" |
| state: pausiert | – | state === "pausiert" |
| state: geplant | – | state === "geplant" |
| Erfolgsquote | – | leistung.erfolgsquote_pct |
| Protokollzeilen | – | protokolle.length |
| Dienste gesamt / erreichbar | – | dienste[].ok |
–
Zeitpläne in den 48 Aufträgen: werden gezählt … · Profile: werden gezählt …
Wenn du heute wirklich einen Worker aufsetzen willst, ist der Weg nicht das Dashboard, sondern ein Auftrag mit Skript und Zeitplan. Wie ein Auftrag aufgebaut ist, zeigen die 48 Einträge oben; wie Zeitpläne aussehen, die Cron-Anleitung, und wie mehrere Aufträge sich die Arbeit aufteilen, die Multi-Agenten-Anleitung.
„Verbinde deinen Worker mit Telegram oder Discord" aus der Fassung von vorher: Discord gibt es nicht, /api/discord antwortet 404 und kein Auftrags-Feld nennt einen Discord-Kanal. Es gibt Aufträge mit Telegram-Bezug im Namen (werden gezählt …) — belegt ist damit der Name, nicht eine Status-Route.
Was die Bausteine unterscheidet — Tarife, live aus /api/tiers
Die vier Tarife unterscheiden sich nicht nur im Preis. Die folgenden Werte werden beim Laden aus /api/tiers gelesen, Spalte für Spalte aus features_sql übernommen — nicht aus dem Prosatext über der Tabelle abgeschrieben. Tarife werden geladen …
| Recht / Wert | ||||
|---|---|---|---|---|
| Tarife werden geladen … | ||||
–
Passende Anleitungen
Der Worker ist der Einstieg. Diese Anleitungen führen jeweils einen Schritt weiter:
Noch Fragen?
Die häufigsten Fragen zu Preisen, Local-LLM und Datenhaltung stehen in der FAQ. Die verfügbaren Stufen findest du unter PLÄNE, den Einstieg in das System über LOGIN. Anbieter: JD Smart Vision e.U., Wien.