Richte mehrere spezialisierte KI-Agenten ein und orchestriere sie in einem gemeinsamen Workflow
Das HYPDB.ONE Orchestrierungssystem verbindet spezialisierte Agenten über ein zentrales Gatewaysystem. Jeder Agent übernimmt eine klar definierte Rolle: Recherche, Analyse, Generierung oder Prüfung.
Die Orchestrierung folgt dem Pipeline-Prinzip: Der Output eines Agenten wird zum Input des nächsten. Du bestimmst die Reihenfolge und die Regeln.
Jeder Agent benötigt ein eigenes Profil mit definierten Fähigkeiten, Grenzen und einem spezifischen Prompt-Template. Lege für jede Rolle fest, welche Aufgaben sie übernehmen darf und welche nicht.
Im HYPDB.ONE Dashboard legst du den Ablauf fest: Welcher Agent startet, welche Daten weitergereicht werden und wo entschieden wird.
Eine Oberfläche namens Pipeline Manager gibt es nicht — im gesamten Webroot kommt der Begriff nur auf dieser Seite vor, und die Routen /api/pipeline, /api/workflows, /api/templates antworten alle mit 404. Was tatsächlich existiert, ist der Auftragsschalter in Schritt 4.
Nicht jeder Schritt soll automatisch ausgeführt werden. Für kritische Entscheidungen baust du Approval-Gates ein: Der Agent bereitet eine Aktion vor, wartet aber auf deine Freigabe, bevor er sie ausführt.
Das ist besonders wichtig bei:
enabled: false — er beendet den Auftrag aber, statt ihn anzuhalten. Wer eine Aktion wirklich freigeben lassen will, muss das im Skript selbst bauen.
Es gibt keinen Testmodus. Ein Auftrag läuft entweder ganz oder gar nicht: das Feld enabled ist der einzige Schalter, ein Probelauf existiert nicht. Zum Prüfen schaltest du den Auftrag auf enabled: false und liest danach das Feld last — das hält den Ausgang des letzten echten Laufs fest.
Prüfe bei jedem Durchlauf:
Der wichtigste Schritt ist der unspektakulärste: Es gibt genau einen Schalter, und er ist ein boolesches Feld pro Auftrag. Die Tabelle unten liest ihn live aus der Auftrags-API — jede Zahl stammt aus einer Messung, keine ist eingetragen.
| Kennzahl | Quelle | Wert |
|---|---|---|
| Wird geladen… | ||
Quelle: /api/automation — die Freigabelogik von HYPDB.ONE.
enabled: false beendet den
Auftrag vollständig; es gibt keinen Wartemodus, der auf eine Freigabe wartet. Wer einen
Freigabeschritt braucht, muss ihn im Skript selbst bauen — im System gibt es dafür keine Route.
Bevor du eine Pipeline baust, lohnt der Blick auf das, was bereits läuft. HYPDB.ONE meldet den tatsächlichen Betriebszustand über die Status-API — keine Attrappe, sondern eine Messung. Diese Werte werden beim Laden dieser Seite live abgefragt.
| PID | Profil | Rolle |
|---|---|---|
| Wird geladen… | ||
Zur Rollenspalte: Der Dienst leitet die Rolle aus dem Startbefehl ab, indem er ihn der Reihe nach auf die Zeichenketten gateway, serve und cron durchsucht. Weil die Reihenfolge fest ist, kann ein Cron- oder CLI-Agent als gateway erscheinen, sobald ein Argument (Jobname, Profilname) diese Zeichenkette enthält. Keine dieser Rollen ist daher eine geprüfte Identität — das ist kein Messfehler der Seite, sondern eine Grenze der Quelle.
Zur Profilspalte: Der Dienst liest das Profil nur aus dem Langargument --profile <name> des Startbefehls. Ein mit der Kurzform -p <name> oder mit gesetztem HERMES_HOME gestarteter Agent erscheint deshalb als default — das ist kein Messfehler der Seite, sondern eine Grenze der Quelle.
| Baustein | Zustand | Kennzahl |
|---|---|---|
| Wird geladen… | ||
/api/status und agenten_status.json gebunden und nicht fest eingetragen. Steht das Backend nicht, siehst du BACKEND OFFLINE in der Leiste oben — keine erfundenen Zahlen.
last sind der ganze WegDie Agentenebene wird über Personas und ein Level-System gesteuert. Die Zahlen unten sind der tatsächliche Inhalt der Registrierungsdateien im Webroot — keine Platzhalter. Sie werden beim Laden dieser Seite live gelesen; bleibt der Abruf aus, siehst du nicht erreichbar, keine Ersatzwerte.
| Kennzahl | Quelle | Wert |
|---|---|---|
| Wird geladen … | ||
Quellen: persona_registry.json (Personas, Familien, Level) und system_data_v3.json (Domänen, Erzeugungs-Agenten, Übergabe-Status).
Die Tabelle unten liest die laufende Auftragsverwaltung aus
/api/automation: Erfolgsquote, erledigte und fehlgeschlagene Aufträge sowie die
Server-Ressourcen. Jeder Wert ist eine Messung zum Zeitpunkt des Seitenaufrufs.
| Kennzahl | Wert |
|---|---|
| Wird geladen … | |
Quelle: /api/automation — Felder leistung und ressourcen.
last je Auftrag aus
Schritt 6 — eine aggregierte Rangfolge gibt es nicht.
Vorgefertigte Pipeline-Vorlagen gibt es nicht — /api/templates und /api/vorlagen antworten beide mit 404. Der gangbare Weg führt über den Worker und über zeitgesteuerte Aufträge.