Kanban in Hermes Agent für selbst gehostete LLM-Workflows

Hermes Agent wird mit einem Kanban-stilisierten Board und dem Hermes Gateway ausgeliefert, das Ihren selbst gehosteten LLM sättigen kann, wenn zu viele Aufgaben gleichzeitig zugewiesen werden.

Ich kann sagen, dass Sie auf diese Weise Ihren eigenen LLM leicht ddos-angreifen können.

Hermes Kanban ist ein dauerhaftes, mehrprofilfähiges Board, das auf ~/.hermes/kanban.db basiert.
Jede Spur (Lane) represents eine Arbeitsphase, und jede Karte ist eine Aufgabe, die von einem bestimmten Hermes-Profil übernommen werden kann.
Seriell kann der Dispatcher viele ready-Aufgaben in einem Durchgang befördern. Das ist für elastische Cloud-APIs in Ordnung, kann aber einen kleinen, selbst gehosteten GPU-Cluster überlasten.

Falls Sie mit diesem Stack neu sind, beginnen Sie mit dem umfassenderen Hermes-Einrichtungs- und Betriebsguide und mit der AI Systems Säule für die umgebende Architektur.

Dieser Beitrag zeigt, wie man:

• Versteht, wie die Hermes-Kanban-Zuweisung mit Ihrem LLM-Gateway interagiert.
• Steuert die Parallelität sicher für schwere Aufgaben.
• Bündelt (Batching) Beförderungen mit Cron, damit Hintergrundjobs nicht mit interaktiver Nutzung kollidieren.
• Überwacht und optimiert das System, sodass GPUs beschäftigt bleiben, ohne überlastet zu werden.

So funktionieren Hermes Kanban und der Dispatcher

Auf hoher Ebene hat das System drei Schichten:

1. Board – dauerhafter SQLite-Zustand für Aufgaben, Spalten, Relationen und Historie.
2. Worker – Hermes-Profile, die in isolierten Arbeitsbereichen gestartet werden, um eine Aufgabe zu verarbeiten.
3. Dispatcher – ein langlaufender Prozess, der nach zuweisbaren Karten scannt und Läufe startet.

Aufgaben, die aus der CLI oder dem Dashboard erstellt werden, starten normalerweise in backlog oder ready. Die unten verwendeten hermes kanban-Unterbefehle werden im Hermes Agent CLI Spickzettel zusammengefasst.
Der Dispatcher scannt nach qualifizierten Karten, beansprucht eine atomar und startet das zugewiesene Profil mit seinen Tools und seinem Speicher.
Jeder Worker ruft dann Ihr LLM-Gateway oder die lokale Laufzeitumgebung auf (zum Beispiel OpenAI-kompatible Endpunkte, die durch Ollama, vLLM oder llama.cpp unterstützt werden). Für Bereitstellungsoptionen über diese Laufzeitumgebungen hinweg verwenden Sie LLM-Hosting im Jahr 2026: Lokales Selbst-Hosting und Cloud-Infrastruktur im Vergleich. Wenn Sie die Anfrage-Aufweitung (Fan-out) auf Ollama selbst optimieren, passt dies gut zu Wie Ollama parallele Anfragen handhabt.

Fügen Sie viele schwere Aufgaben hinzu und beschränken Sie die Beförderungen nicht, kann Ihr Gateway mit gleichzeitigen Anfragen überschwemmt werden.
Auf einem Single-GPU- oder CPU-limitierten Host bedeutet das oft Wartezeiten, thrashing und Timeouts statt besserem Durchsatz.

Die praktische Einschränkung heute

In aktuellen Hermes-Versionen, die viele Teams ausführen, exponiert die Dispatcher-Konfiguration nur zwei Kanban-Zuweisungsschlüssel und wendet keinen globalen aktiven-Aufgaben-Limit aus der Konfiguration an:

kanban:
  dispatch_in_gateway: false
  dispatch_interval_seconds: 10

Für die Steuerung aktiver Aufgaben verlassen Sie sich auf explizite Zuweisungsintervalle (hermes kanban dispatch --max ...) plus Abhängigkeitsmodellierung.

Bekannte Stolpersteine:

• Führen Sie nicht Gateway-embedded-Dispatch und hermes kanban daemon --force gegen dasselbe Board aus, sonst können Sie Beanspruchungskonflikte (Claim Races) erhalten.
• Wenn das Gateway außer Betrieb ist, werden ready-Aufgaben nicht zugewiesen und können später, wenn der Dienst wiederhergestellt wird, in einem Schwall (Burst) zugewiesen werden.
• Längere Zuweisungsintervalle fühlen sich ungleichmäßig an, da das Beantragen in Ticks erfolgt.
• Das Verhalten kann zwischen Versionen variieren, da Edge-Cases für Laufzeitzustände und erneutes Beantragen im Laufe der Zeit gepatcht wurden.

Schnelle Verifikation, wenn das Verhalten falsch erscheint:

# 1) bestätigen, dass genau ein Dispatcher-Pfad aktiv ist
pgrep -af "hermes gateway start|hermes kanban daemon"

# 2) prüfen die verkabelten Kanban-Dispatcher-Schlüssel
rg "dispatch_in_gateway|dispatch_interval_seconds" ~/.hermes/config.yaml

# 3) Warteschlangenform inspizieren
hermes kanban list --status ready
hermes kanban list --status running

Wichtige Konzepte:

• Die Dispatcher-Konfiguration verkabelt dispatch_in_gateway und dispatch_interval_seconds.
• dispatch --max begrenzt neue Startvorgänge in diesem Durchgang, nicht die Gesamtzahl der laufenden Aufgaben.
• Für kleine, selbst gehostete Cluster konservativ beginnen und nur dann erhöhen, wenn die Latenz stabil bleibt.

Beim ersten Deployment von Hermes in der Nähe Ihres LLM-Gateways:

• Bewahren Sie nur unterstützte Kanban-Dispatcher-Schlüssel in der Konfiguration auf.
• Beobachten Sie GPU- und CPU-Auslastung unter echtem Warteschalendruck.
• Verwenden Sie Strategie 1 oder Strategie 2 für deterministische Taktung.

Untersuchungsergebnisse und Ursache

hermes kanban dispatch liest config.yaml nicht für max_active_tasks.

In hermes_cli/kanban.py exponiert der Dispatch-Befehl --max als CLI-Grenzwert (Standard None) und übergibt nur args.max an kb.dispatch_once(...). Es gibt keine Konfigurationsabfrage für max_active_tasks in diesem Pfad. Siehe hermes_cli/kanban.py roh.

Dann in kanban_db.dispatch_once ist der einzige Grenzwert max_spawn, mit Logik, die äquivalent zu folgender ist:

if max_spawn is not None and spawned >= max_spawn:
    break

Es gibt keine Überprüfung bereits laufender Aufgaben und keine Referenz zu max_active_tasks in diesem Zuweisungspfad. Siehe hermes_cli/kanban_db.py roh.

Effektives Verhalten:

hermes kanban dispatch

unbegrenzt für diesen Durchgang (begrenzt durch die Größe der Ready-Warteschlange).

hermes kanban dispatch --max 2

begrenzt nur neue Startvorgänge in diesem Durchgang, nicht die Gesamtzahl der laufenden Aufgaben.

Die verkabelten Konfigurationsregler um das Gateway-Dispatch herum sind kanban.dispatch_in_gateway und kanban.dispatch_interval_seconds.
Daher wird max_active_tasks in diesem Zuweisungspfad ignoriert, da er dort nicht implementiert ist.

Strategie 1 – Abhängigkeiten codieren für streng sequenzielle Workflows

Einige Workflows sollten streng nacheinander ablaufen — zum Beispiel:

• mehrstufige Datenpipelines mit gemeinsamen Zwischenartefakten
• Migrationen oder Infrastrukturänderungen
• Batch-Jobs, die in denselben Object Store oder dieselbe Datenbank schreiben

Hermes Kanban unterstützt Eltern-Kind-Abhängigkeiten zwischen Aufgaben, sodass eine Kindkarte erst zuweisbar ist, wenn das Eltern-Element abgeschlossen ist.

Sie können dies mit einem kleinen Hilfsskript um die Hermes-CLI modellieren:

#!/usr/bin/env bash

set -euo pipefail

parent_id="$(hermes kanban add \
  --title 'Ingest customer logs for April' \
  --profile 'etl-worker' \
  --column backlog)"

hermes kanban add \
  --title 'Generate April anomaly report' \
  --profile 'analytics-worker' \
  --column backlog \
  --parent "${parent_id}"

hermes kanban add \
  --title 'Publish April summary to dashboard' \
  --profile 'reporting-worker' \
  --column backlog \
  --parent "${parent_id}"

Mit einer geeigneten Board-Policy und niedrigen Dispatcher-Grenzwerten wird nur die Eltern-Aufgabe zuerst ausgeführt.
Sobald sie abgeschlossen ist, werden die Kindaufgaben allmählich bereit, und der Dispatcher zieht sie nacheinander, ohne jemals Ihre Parallelitätsgrenzen zu überschreiten.

Strategie 2 – Linux Cron mit einer laufzeitbewussten Dispatch-Grenze verwenden

Wenn Sie deterministische Taktung wünschen, verwenden Sie Host-Cron plus ein kleines Wrapper-Skript.
Anstelle, immer dispatch --max 2 aufzurufen, zählen Sie zuerst die aktuell laufenden Aufgaben und weisen dann nur die verbleibenden Slots zu.

Erstellen Sie hermes-kanban-dispatch-capped.sh:

#!/usr/bin/env bash
set -euo pipefail

MAX_PARALLEL="${MAX_PARALLEL:-2}"
BOARD="${BOARD:-}"

board_args=()
if [[ -n "$BOARD" ]]; then
  board_args=(--board "$BOARD")
fi

# oder dort, wo Ihr hermes installiert ist
export PATH="/home/abc/.local/bin:$PATH"

running_out="$(hermes kanban "${board_args[@]}" list --status running)"

if [[ "$running_out" == *"(no matching tasks)"* ]]; then
  running_count=0
else
  running_count="$(printf '%s\n' "$running_out" | wc -l)"
fi

slots=$(( MAX_PARALLEL - running_count ))

if (( slots <= 0 )); then
  echo "Already at limit running=$running_count max=$MAX_PARALLEL dispatch skipped"
  exit 0
fi

echo "running=$running_count max=$MAX_PARALLEL slots=$slots dispatching up to $slots"

hermes kanban "${board_args[@]}" dispatch --max "$slots"

Machen Sie es ausführbar:

chmod +x ./hermes-kanban-dispatch-capped.sh

Führen Sie es aus mit:

MAX_PARALLEL=2 ./hermes-kanban-dispatch-capped.sh

Für ein spezifisches Board:

BOARD=my-board MAX_PARALLEL=2 ./hermes-kanban-dispatch-capped.sh

Planen Sie es einmal pro Minute mit Cron ein:

* * * * * /opt/hermes/scripts/hermes-kanban-dispatch-capped.sh >> /var/log/hermes/kanban-cron.log 2>&1

Betriebshinweise:

• Cron hat oft einen minimalen PATH, daher wenn hermes nicht gefunden wird, verwenden Sie seinen vollen Pfad im Skript (zum Beispiel /usr/local/bin/hermes).
• Wenn Sie in /var/log/hermes/... protokollieren, erstellen Sie dieses Verzeichnis zuerst und stellen Sie sicher, dass der Cron-Benutzer Schreibzugriff hat.

Beispiel:

sudo mkdir -p /var/log/hermes
sudo chown "$USER":"$USER" /var/log/hermes

Erstellen oder bearbeiten Sie Cron-Einträge mit:

crontab -e

Verifizieren Sie dann mit:

crontab -l

Sub-Minuten-Taktung mit einem Cron-Eintrag

Cron tickt einmal pro Minute, aber Sie können immer noch häufiger zuweisen, indem Sie eine kurze Schleife innerhalb des Skripts ausführen.

Beispiel hermes-kanban-dispatch-subminute.sh:

#!/usr/bin/env bash
set -euo pipefail

LOCK_FILE="/tmp/hermes-kanban-dispatch.lock"
RUNS_PER_MINUTE="${RUNS_PER_MINUTE:-4}"    # 4 Läufe => alle 15 Sekunden
CAP_SCRIPT="${CAP_SCRIPT:-/opt/hermes/scripts/hermes-kanban-dispatch-capped.sh}"

exec 9>"$LOCK_FILE"
flock -n 9 || exit 0

sleep_seconds=$(( 60 / RUNS_PER_MINUTE ))

for ((i=1; i<=RUNS_PER_MINUTE; i++)); do
  "$CAP_SCRIPT"

  if (( i < RUNS_PER_MINUTE )); then
    sleep "$sleep_seconds"
  fi
done

Machen Sie es ausführbar:

chmod +x ./hermes-kanban-dispatch-subminute.sh

Planen Sie es einmal pro Minute ein:

* * * * * /opt/hermes/scripts/hermes-kanban-dispatch-subminute.sh >> /var/log/hermes/kanban-subminute.log 2>&1

Dies ergibt eine effektive Sub-Minuten-Taktung, während flock überlappende Läufe verhindert.

Warum das funktioniert:

• list --status running liefert die aktuelle laufende Auslastung.
• dispatch --max N begrenzt nur neue Startvorgänge für diesen Durchgang.
• Das Berechnen von N als verbleibende Slots hält die Gesamtzahl der laufenden Aufgaben nahe Ihrem Ziellimit.

Wichtiger Hinweis: Diese Grenze funktioniert nur für Zuweisungen, die durch dieses Skript erfolgen.
Deaktivieren Sie Gateway-embedded-Dispatch, sonst kann er weiterhin unabhängig Aufgaben befördern:

kanban:
  dispatch_in_gateway: false

Die offiziellen Doku beschreiben beide Befehlsfähigkeiten und erwähnen Gateway-Dispatch-Standardwerte im Kanban-Funktionsguide: Hermes Kanban Doku.

Interner Hermes Cron

Verwenden Sie ihn nicht. Möchten Sie wirklich, dass Ihr LLM reguläre Prompts wie Execute in terminal the command /path/hermes-kanban-dispatch-capped.sh verarbeitet, besonders wenn es mit nützlicher Arbeit beschäftigt ist?

Hermes Kanban Überwachung und Optimierung

Welche Strategie Sie auch wählen, Sie sollten überwachen:

• LLM-Gateway-Metriken — Anfragerate, Latenz, Fehlerquote, Token-Durchsatz.
• Knoten-Gesundheit — GPU-Auslastung, VRAM-Nutzung, CPU-Last und RAM.
• Hermes-Metriken — wie viele Aufgaben im Backlog, ready, aktiv und abgeschlossen sind.

Für produktionsreife Metrik-Baselines und Dashboards siehe LLM-Inferenz in der Produktion mit Prometheus und Grafana überwachen und den umfassenderen LLM Performance Hub.

Beginnen Sie mit niedriger Parallelität und erhöhen Sie dann schrittweise die Limits, während Sie auf Folgendes achten:

• steigende Latenz bei konstantem Durchsatz
• zunehmende Timeout- oder Ratenlimit-Fehler
• lange Schwänze, bei denen einige Aufgaben sehr lange aktiv bleiben

Sobald Sie diese Symptome sehen, rollen Sie auf die vorherige stabile Konfiguration zurück und behalten Sie diese als Ihren Standard bei.

Wann Kanban das richtige Werkzeug ist

Hermes Kanban glänzt, wenn Sie haben:

• langlebige Forschungs- oder Engineering-Backlogs
• Multi-Agent-Kollaboration mit benannten Profilen
• Workflows, die Neustarts und Host-Reboots überstehen müssen
• Menschen, die ein Dashboard zum Triage von Arbeit wollen

Wenn Sie nur einen einzelnen Lauf brauchen, um einige temporäre Helfer zu erstellen, sind die eingebauten Delegat-Aufgaben-Tools normalerweise einfacher.
Sobald Sie Historie, Dashboards und strenge Kontrolle darüber brauchen, wie Ihre Agenten selbst gehostete LLMs treffen, ist das Kanban-Board plus Dispatcher die richtige Grundlage.

Mit einigen Konfigurationseinstellungen und optionalem Cron-basiertem Batching können Sie Hermes Kanban reaktionsfähig halten und gleichzeitig Ihr Gateway und Ihre Hardware schützen.

Für einen umfassenderen Blick darauf, wie Hermes-artige Hintergrundworker in produktionsreife KI-Assistenten-Architekturen passen — einschließlich Scheduler, warteschlangenbasiertes Polling, Claim-Protokolle, dauerhafte Workflows und semantische Auswertung — siehe Polling Agents in AI Assistants: 11 Implementation Patterns. Wenn mehrere benannte Profile oder Spezialagenten über eine einfache Aufgabenzuweisung hinaus koordinieren müssen, deckt Multi-Agent Orchestration Patterns die Koordinations-Topologien ab — Hub-and-Spoke, Fan-out, Schwarm — die größere Multi-Agenten-Setups auf selbst gehosteter Infrastruktur untermauern.