Wie mehrere spezialisierte KI-Agenten an einer Aufgabe arbeiten — mit dem, was das System tatsächlich kann.
Diese Seite beschrieb drei Dinge, die es nicht gibt: einen
Dashboard-Bereich „Agenten verwalten" mit dem Knopf „Neuen Agenten erstellen",
ein Aufrufbefehl /usr/local/bin/hypdb run-workflow und die Modellangabe
deepseek-v4-flash.
Geprüft am 04.10.2026: Das Binary hypdb existiert auf
dem System nicht (which hypdb liefert nichts). Einen Menüpunkt „Agenten verwalten"
gibt es im Webroot nicht. Und das in der Konfiguration tatsächlich gesetzte Modell ist
deepseek/deepseek-v4-flash-0731 beim Anbieter nous — nicht die
abkürzende Schreibweise der alten Seite.
Eine Cron-Zeile mit einem nicht vorhandenen Befehl sieht in der Dokumentation perfekt aus und scheitert still, wenn sie zum ersten Mal läuft. Diese Seite beschreibt deshalb nur Wege, die im laufenden System nachprüfbar sind.
Diese Werte liest die Seite beim Laden aus den Kennzahlen-Dateien des Webroots. Sie sind kein Beispiel, sondern der Zustand von eben.
| Kanal | Erreichbar | Umfang |
|---|---|---|
| Content | — | — |
| Chat | — | — |
| Messaging | — | — |
| Cron | — | — |
| Social | — | — |
| Recherche | — | — |
Quelle: agenten_status.json (wird alle 5 Minuten neu geschrieben) und
/api/stats. Die Datei liegt im Webroot und ist daher öffentlich abrufbar — sie
enthält nur Zähler, keine Zugangsdaten.
Der häufigste Fehler bei Multi-Agenten-Workflows ist die Aufgabenstellung. Sobald zwei Agenten dieselbe Frage bearbeiten und dann eine Antwort zusammenführen müssen, entsteht ein zusätzlicher Klärungsschritt — und der macht mehr Arbeit als eine einzige Agentenkette.
Die Frage lautet daher nicht „welche Agenten brauche ich", sondern: welche Teile der Aufgabe sind wirklich unabhängig?
Beginne mit zwei Agenten. Wenn die Kette ohne Streuern läuft, ist die Grenze gefunden. Ein dritter Agent bringt nur dann etwas, wenn er eine eigene Frage beantwortet.
Eine Rolle ist kein Knopf im Dashboard, sondern ein eigenständiges Profil mit eigener Konfiguration: eigenes Modell, eigene Skills, eigenes Gedächtnis, eigene Cronjobs. Genau deshalb sind Profile der saubere Schnittpunkt für parallele Agenten — sie teilen sich nicht versehentlich denselben Zustand.
Gemessen auf diesem System sind 6 aktive Profile:
Jedes Profil hat einen eigenen Ordner mit skills/,
cron/ und memories/. Das ist der eigentliche Vorteil: Ein Agent im
Profil deepseek-coder sieht die Coding-Skills, ein Agent im Profil
jarvis die Recherche-Skills — ohne dass eine lange Liste jedes Mal neu geladen
werden muss.
Profile teilen das Dateisystem, nicht den Speicher. Zwei Agenten dürfen deshalb nicht gleichzeitig dieselbe Datei schreiben. Für parallele Arbeiten: getrennte Zieldateien je Agent, zusammengeführt erst im dritten Schritt.
Statt Anweisungen in jeden Aufruf zu kopieren, legst du sie als SKILL.md ab.
Der Vorteil ist doppelt: Die Anweisung ist wiederverwendbar, und sie wird nur geladen, wenn sie
zur Aufgabe passt — ein Skill, der nichts mit dem Auftrag zu tun hat, kostet dann keinen
Kontext.
Gemessen: — Skill-Dateien liegen unter
~/.hermes, davon — in der Kategorie
devops und — in software-development.
Zum Vergleich: /api/stats zählt — freigeschaltete
Skills. Das sind zwei verschiedene Zähler — die API kennt nur die aktivierbaren Skills des
Starter-Tarifs, der Dateizähler sieht alle Fähigkeiten aller Profile.
~/.hermes (davon 156 in
devops, 60 in software-development); nur im Default-Profil
~/.hermes/skills 535. Zwei frühere Fassungen dieser Seite nannten
510/2833 — beides überholt. Der Zähler /api/stats.skills ist wieder etwas
anderes: er zählt die im System freigeschalteten Skills, nicht die Dateien. Selbst prüfen:
find ~/.hermes -name SKILL.md | wc -l bzw.
find ~/.hermes/skills -name SKILL.md | wc -l.
Der description-Eintrag ist der wichtigste Teil: Er entscheidet, ob die Fähigkeit
überhaupt geladen wird. Eine schwache Beschreibung bedeutet, dass die Anweisung im falschen
Moment gelesen wird — oder gar nicht.
Schreibe die Beschreibung als Auslöser, nicht als Inhalt: „Verwende diese Fähigkeit, wenn ein Cronjob fehlschlägt" statt „Alles über Cronjobs". Der Unterschied entscheidet, ob sie im richtigen Moment im Kontext landet.
Das ist der Schritt, der in den meisten Anleitungen fehlt und in der Praxis am meisten Ärger verursacht. Ein Agent meldet „fertig". Die Frage ist: Wo ist das Ergebnis, und wie prüfe ich es, ohne dem Agenten zu glauben?
Eine Zusammenfassung eines Subagenten ist eine Selbstauskunft. Sie ist ein Hinweis, kein Nachweis. Zwei subagenten können dasselbe falsche Ergebnis melden.
/api/status den erwarteten
Zustand? Ein Endpunkt, der 404 liefert, hat nichts bewiesen.Ein Skript kann fehlerfrei syntaktisch gültig sein, JSON valide, die Tabelle ausgeglichen — und trotzdem [object Object] in jeder Zelle anzeigen. Passiert, wenn ein Objekt statt seines Wertes in eine Zelle geschrieben wird.
Ebenso bleibt ein Element leer, wenn es mit einer Elementauswahl
ohne Raute gesucht wurde — querySelector('id') findet nie etwas und liefert
trotzdem keinen Fehler. Beide Fälle fallen ausschließlich im Browser auf, nie in der
Code-Prüfung. Bei externen und teuren Aktionen gilt deshalb: Das Ergebnis selbst nachsehen,
nicht die Meldung darüber.
Damit die Kette ohne Startauftrag läuft, hängt sie an einem Cronjob. Die Seite nennt keine festen Zahlen mehr: die Tabelle unten liest die vier Profil-Jobdateien, soweit ein Browser das kann — und nennt offen, was er nicht kann.
| Profil | Gesamt | Aktiv | Quelle |
|---|---|---|---|
| Jobs werden geladen … | |||
~/.hermes/ und werden vom Webserver nicht ausgeliefert. /api/automation
liefert die Aufträge der laufenden Dienste, aber nicht nach Profil gruppiert — die
Profilaufteilung unten kann der Browser deshalb nicht selbst nachmessen. So prüfst du sie
in der Shell: grep -c '"id"' ~/.hermes/cron/jobs.json je Datei, und
grep -c '"enabled": true' für die aktiven Jobs.~/.hermes/cron/jobs.json und den drei Profil-Verzeichnissen:
48 Jobs angelegt, davon 40 aktiv — je Profil 14/7 (default), 10/10 (jarvis),
8/8 (hypdb-creator), 16/15 (hermes-system-linux). Eine frühere Fassung dieser Seite nannte
46/38; auch die spätere Korrektur auf 47/39 war bereits überholt. Diese Zahlen sind eine
Momentaufnahme: /api/automation kennt kein Feld profile und kein
cron, also kann die Seite sie nicht selbst nachziehen. Sie bleibt bei dieser
Feststellung und behauptet keine laufende Messung.
Zwei Muster aus dem laufenden Betrieb, die sich bewährt haben:
Der Job agenten-status-frisch läuft alle 5 Minuten und schreibt die Statusdatei.
Der Job hypdb-one-seiten-rotation arbeitet im 5-Minuten-Takt über mehrere Seiten
— immer eine Seite pro Lauf, damit keine zwei Läufe dieselbe Datei anfassen.
Erst manuell durchlaufen lassen, dann automatisieren. Ein Workflow, der beim Test schon beim zweiten Schritt abbricht, wird durch einen Zeitplan nicht besser — nur häufiger.