Kanban in Hermes Agent per flussi di lavoro LLM self-hosted

L’agente Hermes include una board in stile Kanban e il Hermes Gateway, che può sovraccaricare il tuo LLM self-hosted se vengono inviati troppi compiti contemporaneamente.

Posso affermare che in questo modo puoi facilmente effettuare un DDoS contro il tuo stesso LLM.

Hermes Kanban è una board multi-profilo durevole, supportata da ~/.hermes/kanban.db.
Ogni corsia rappresenta una fase del lavoro e ogni carta è un compito che può essere assunto da un profilo Hermes specifico.
In configurazione predefinita, il dispatcher può promuovere molti compiti ready in un unico passaggio. Questo va bene per le API cloud elastiche, ma può sovraccaricare un piccolo cluster GPU self-hosted.

Se sei nuovo di questo stack, inizia con la più ampia Guida alla configurazione e alle operazioni di Hermes e al Pilastro dei Sistemi AI per l’architettura circostante.

Questo post mostra come:

• Comprendere come l’inoltro (dispatch) di Hermes Kanban interagisce con il tuo gateway LLM.
• Controllare il parallelismo in modo sicuro per compiti pesanti.
• Aggregare le promozioni con cron in modo che i lavori in background non entrino in conflitto con l’uso interattivo.
• Monitorare e ottimizzare il sistema in modo che le GPU restino occupate senza sovraccarico.

Come funzionano Hermes Kanban e il dispatcher

Ad alto livello, il sistema ha tre strati:

1. Board - stato SQLite durevole per compiti, colonne, relazioni e cronologia.
2. Worker - profili Hermes avviati in workspace isolati per elaborare un compito.
3. Dispatcher - un processo a lunga durata che scansiona le carte invocabili e avvia le esecuzioni.

I compiti creati da CLI o dashboard solitamente iniziano in backlog o ready.
Il dispatcher scansiona le carte eleggibili, ne assume una atomicamente e avvia il profilo assegnato con i suoi strumenti e memoria.
Ogni worker chiama poi il tuo gateway LLM o runtime locale (ad esempio, endpoint compatibili con OpenAI supportati da Ollama, vLLM o llama.cpp). Per le scelte di deployment tra questi runtime, utilizza Hosting LLM nel 2026: Infrastruttura Locale Self-Hosted e Cloud Confrontata. Se stai ottimizzando la fan-out delle richieste su Ollama stesso, questo si abbina bene con Come Ollama Gestisce le Richieste Parallele.

Se aggiungi molti compiti pesanti e non limiti le promozioni, il tuo gateway può essere inondato di richieste concorrenti.
Su un host con singola GPU o vincolato dalla CPU, questo spesso significa code, thrashing e timeout invece di un migliore throughput.

La limitazione pratica attuale

Nelle build Hermes attualmente utilizzate da molti team, la configurazione del dispatcher espone solo due chiavi di dispatch Kanban e non applica un limite globale di compiti attivi dalla configurazione:

kanban:
  dispatch_in_gateway: false
  dispatch_interval_seconds: 10

Per il controllo dei compiti attivi, affidati a una cadenza di dispatch esplicita (hermes kanban dispatch --max ...) oltre alla modellazione delle dipendenze.

Trabocchetti noti:

• Non eseguire il dispatch incorporato nel gateway e hermes kanban daemon --force sulla stessa board, o potresti ottenere corse per l’acquisizione (claim races).
• Se il gateway è down, i compiti ready non vengono inviati e possono esplodere più tardi quando il servizio torna online.
• Intervalli di dispatch più lunghi sembrano irregolari perché l’acquisizione avviene a scatti.
• Il comportamento può variare tra le versioni perché i casi limite dello stato di esecuzione e del recupero sono stati corretti nel tempo.

Verifica rapida quando il comportamento sembra errato:

# 1) conferma che esattamente un percorso del dispatcher sia attivo
pgrep -af "hermes gateway start|hermes kanban daemon"

# 2) controlla le chiavi del dispatcher Kanban cablate
rg "dispatch_in_gateway|dispatch_interval_seconds" ~/.hermes/config.yaml

# 3) ispeziona la forma della coda
hermes kanban list --status ready
hermes kanban list --status running

Concetti chiave:

• La configurazione del dispatcher cabla dispatch_in_gateway e dispatch_interval_seconds.
• dispatch --max limita le nuove creazioni in quel passaggio, non i compiti totali in esecuzione.
• Per piccoli cluster self-hosted, inizia in modo conservativo e aumenta solo dopo che la latenza rimane stabile.

Quando si deploya Hermes per la prima volta vicino al tuo gateway LLM:

• Mantieni solo le chiavi del dispatcher Kanban supportate nella configurazione.
• Osserva l’utilizzo di GPU e CPU sotto pressione della coda reale.
• Usa la Strategia 1 o la Strategia 2 per un ritmo deterministico.

Risultati dell’indagine e causa radice

hermes kanban dispatch non legge config.yaml per max_active_tasks.

In hermes_cli/kanban.py, il comando dispatch espone --max come limite CLI (default None) e passa solo args.max in kb.dispatch_once(...). Non c’è nessuna ricerca di configurazione max_active_tasks in questo percorso. Vedi hermes_cli/kanban.py raw.

Poi in kanban_db.dispatch_once, l’unico limite è max_spawn, con logica equivalente a:

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

Non c’è alcun controllo dei compiti già in esecuzione e nessun riferimento a max_active_tasks in quel percorso di dispatch. Vedi hermes_cli/kanban_db.py raw.

Comportamento effettivo:

hermes kanban dispatch

senza limiti per quel passaggio (limitato dalla dimensione della coda ready).

hermes kanban dispatch --max 2

limita solo le nuove creazioni in quel passaggio, non i compiti totali in esecuzione.

I pulsanti di configurazione cablati per il dispatch del gateway sono kanban.dispatch_in_gateway e kanban.dispatch_interval_seconds.
Quindi max_active_tasks viene ignorato in questo percorso di dispatch perché non è implementato lì.

Strategia 1 - Codificare dipendenze per flussi strettamente sequenziali

Alcuni flussi di lavoro dovrebbero eseguire strettamente uno dopo l’altro — ad esempio:

• pipeline di dati multi-step con artefatti intermedi condivisi
• migrazioni o cambiamenti infrastrutturali
• lavori batch che scrivono nello stesso object store o database

Hermes Kanban supporta dipendenze genitore-figlio tra compiti in modo che una carta figlia diventi invocabile solo quando il suo genitore è terminato.

Puoi modellare questo con un piccolo script helper intorno alla CLI Hermes:

#!/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}"

Con una politica di board appropriata e limiti del dispatcher bassi, solo il compito genitore viene eseguito per primo.
Una volta terminato, i compiti figlio diventano gradualmente pronti e il dispatcher li tira uno per uno senza mai superare i tuoi limiti di concorrenza.

Strategia 2 - Usare Linux cron con un limite di dispatch consapevole dell’esecuzione

Se vuoi un ritmo deterministico, usa cron dell’host più un piccolo script wrapper.
Invece di chiamare sempre dispatch --max 2, conta prima i compiti attualmente in esecuzione, poi invia solo gli slot rimanenti.

Crea 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

# o dove è installato il tuo hermes
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 "Già al limite running=$running_count max=$MAX_PARALLEL dispatch saltato"
  exit 0
fi

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

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

Rendilo eseguibile:

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

Eseguilo con:

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

Per una board specifica:

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

Pianificalo una volta al minuto con cron:

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

Note operative:

• Cron spesso ha un PATH minimo, quindi se hermes non viene trovato, usa il suo percorso completo all’interno dello script (ad esempio /usr/local/bin/hermes).
• Se registri su /var/log/hermes/..., crea prima quella directory e assicurati che l’utente cron abbia accesso in scrittura.

Esempio:

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

Crea o modifica le voci cron con:

crontab -e

Poi verifica con:

crontab -l

Cadenza sub-minuto con una voce cron

Cron scatta una volta al minuto, ma puoi comunque inviare più frequentemente eseguendo un breve ciclo all’interno dello script.

Esempio 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 esecuzioni => ogni 15 secondi
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

Rendilo eseguibile:

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

Pianificalo una volta al minuto:

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

Questo fornisce una cadenza effettiva sub-minuto mentre flock previene esecuzioni sovrapposte.

Perché funziona:

• list --status running fornisce il carico in esecuzione corrente.
• dispatch --max N limita solo le nuove creazioni per quel passaggio.
• Calcolare N come slot rimanenti mantiene i compiti totali in esecuzione vicino al tuo limite target.

Avvertenza importante: questo limite funziona solo per gli invii fatti attraverso questo script.
Disabilita il dispatch incorporato nel gateway, altrimenti può comunque promuovere compiti in modo indipendente:

kanban:
  dispatch_in_gateway: false

La documentazione ufficiale descrive entrambe le funzionalità dei comandi e nota i valori predefiniti del dispatch del gateway nella guida alle funzionalità Kanban: Documentazione Hermes Kanban.

Hermes Cron Interno

Non usarlo. Vuoi davvero che il tuo LLM elabori prompt regolari come Execute in terminal the command /path/hermes-kanban-dispatch-capped.sh, specialmente quando è impegnato a fare qualche lavoro utile?

Monitoraggio e Ottimizzazione di Hermes Kanban

Qualunque strategia tu scelga, dovresti monitorare:

• Metriche del gateway LLM — tasso di richieste, latenza, tasso di errore, throughput dei token.
• Salute del nodo — utilizzo GPU, utilizzo VRAM, carico CPU e RAM.
• Metriche Hermes — quanti compiti sono in backlog, ready, attivi e completati.

Per baseline delle metriche di produzione e dashboard, vedi Monitorare l’Inferenza LLM in Produzione con Prometheus e Grafana e il più ampio Hub Prestazioni LLM.

Inizia con bassa concorrenza, poi aumenta gradualmente i limiti mentre osservi:

• latenza in aumento a throughput costante
• aumento di timeout o errori di limite di tasso
• code lunghe dove alcuni compiti restano attivi per un tempo molto lungo

Non appena vedi questi sintomi, torna alla configurazione stabile precedente e mantienila come predefinita.

Quando Kanban è lo strumento giusto

Hermes Kanban brilla quando hai:

• backlog di ricerca o ingegneria a lunga vita
• collaborazione multi-agente con profili nominati
• flussi di lavoro che devono sopravvivere ai riavvii e ai reboot dell’host
• umani che vogliono una dashboard per triare il lavoro

Se hai bisogno solo di un’unica esecuzione per creare alcuni helper temporanei, gli strumenti di delega task integrati sono solitamente più semplici.
Una volta che hai bisogno di cronologia, dashboard e controllo rigoroso su come i tuoi agenti colpiscono LLM self-hosted, la board Kanban più il dispatcher sono la fondazione giusta.

Con alcuni tweak di configurazione e batching opzionale basato su cron, puoi mantenere Hermes Kanban reattivo proteggendo il tuo gateway e l’hardware.