KI-Workflows überwachen und optimieren

Workflow-Registry: die gibt es nicht — Cronjobs sind es

Es gibt keine separate „Workflow-Registry", in die du etwas per Befehl einträgst. Ein Workflow ist ein Cronjob. Er wird in einer JSON-Datei unter ~/.hermes/cron/jobs.json bzw. ~/.hermes/profiles/<profil>/cron/jobs.json beschrieben.

Auf diesem System liegen – Jobs in – Dateien. So sieht ein echter Job aus (gekürzt, echte Feldnamen):

{
  "id": "…",
  "name": "…",
  "prompt": "…",              // die Aufgabe
  "schedule": "…",             // Zeitplan
  "schedule_display": "…",
  "repeat": …,
  "enabled": true,
  "script": "…",               // optionales Skript
  "workdir": "…",
  "deliver": "…",             // wo das Ergebnis hin soll
  "model": "…",
  "provider": "…",
  "timeout_seconds": …,
  "last_run_at": …,
  "last_status": "…",
  "failure_streak": 0,
  "last_error": null
}

Quelle: ~/.hermes/cron/jobs.json + ~/.hermes/profiles/*/cron/jobs.json, 4 Dateien ausgewertet.

Die echten Zustandsfelder — und was sie bedeuten

Es gibt kein Menü „Workflows → Monitoring" mit farbigen Listen. Der Zustand eines Jobs steht in sechs Feldern, die man direkt liest. Das ist die vollständige Liste der Überwachungs-relevanten Felder:

Quelle: dieselben 4 Cron-Dateien, Feldnamen über alle 47 Jobs gemergt.

Kennzahlen: welche es wirklich gibt

Diese Anleitung versprach früher sieben Metriken je Workflow — Durchlaufzeit, Token-Verbrauch, Fehlerrate, Erfolgsquote, Auslastung, Wartezeit, Speichernutzung — abrufbar mit hypdb workflow stats. Diesen Befehl gibt es nicht, und eine Workflow-Metrik-Datenbank gibt es nicht.

Belegbar sind stattdessen diese Zahlen, jede von einer echten Route geliefert:

• System-Kennzahlen — CPU, RAM, Speicher, Netzwerk: GET /api/status (metrics).
• Aktive Agenten — wie viele Prozesse laufen: GET /api/status (agenten_online, agenten_detail).
• Produkt-Skills — was der Tarif freischaltet: GET /api/skills.
• Content-Protokolle — Laufzeit des Auto-Content-Systems: GET /ac/stats auf 127.0.0.1:7920.
• Cron-Zustand — die sechs Felder aus Schritt 2, direkt aus der JSON-Datei.

Hinweis: Diese Route ist bewusst nicht über die öffentliche Adresse erreichbar. Ein 200 auf Port 7777 für /ac/stats wäre der nginx-Fallback, kein Backend.

Alarme: der gefährlichste Cronjob-Fehler

Es gibt kein hypdb workflow alert --on error --threshold 3. Es gibt aber ein deutlich schlimmeres Problem, das dieselbe Funktion erfüllt: einen Cronjob, der fehlschlägt und es niemandem sagt.

Genau das ist der Fall, wenn enabled: true gilt und der Zeitplan trotzdem nie feuert. Prüfe deshalb bei jedem Job diese drei Dinge in dieser Reihenfolge:

• enabled — ist der Job überhaupt scharf?
• next_run_at — liegt die Zeit in der Zukunft?
• last_run_at — ist das Feld gefüllt, wenn der Job längst laufen müsste?

Ist enabled: true und last_run_at leer, läuft der Job nicht — und er meldet sich nicht. Genau das ist der Fehler, den ein echter Cronjob-Monitor als Erstes finden muss.

Engpässe identifizieren und optimieren

Mit belegbaren Zustandsfeldern lassen sich echte Muster erkennen. Diese Muster treten auf dem laufenden System tatsächlich auf:

• Agent-Prozess weg — agenten_online fällt. Zwei Rollen laufen hier normal: gateway und cli.
• Speicherknappheit — metrics.speicher in Prozent, mit speicher_detail für belegt/frei. Schreiben und Ausführen brauchen Platz.
• Hohe Temperatur — temperatur in Grad. Dauerhaft hohe Werte kosten Leistung.
• Cronjob-Fehlerkette — failure_streak > 0 mit last_error gefüllt.
• Content ohne Nachweis — /ac/stats zeigt published_with_proof: 0. Protokolleinträge können allesamt simuliert sein; das Backend unterscheidet das in log_status.
• Backend nicht erreichbar — eine Route antwortet nicht. Dann wird nichts angezeigt, statt eine Zahl zu erfinden.

Überprüfen statt behaupten

Der wichtigste Grundsatz dieser überarbeiteten Anleitung: kein Befund ohne Werkzeug und Ausgabe. Ein HTTP-Status von 200 beweist nicht, dass eine Route echt ist — nginx liefert bei fehlenden Pfaden die Startseite mit 200 zurück. Ein Toter-Link-Scan, der nur den Status prüft, meldet deshalb alles als gesund.

Deshalb gilt: Existenz auf der Platte prüfen, dann Status messen, dann den Inhalt ansehen. Erst wenn alle drei zusammenpassen, gilt etwas als vorhanden.