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

L’agente Hermes viene fornito con una bacheca di stile Kanban che può facilmente saturare il tuo gateway LLM self-hosted se lasci che ogni task venga eseguito contemporaneamente.

Hermes Kanban è una bacheca multi-profilo durabile, supportata da ~/.hermes/kanban.db.
Ogni corsia rappresenta una fase del lavoro e ogni carta è un task che può essere preso in carico da un profilo Hermes specifico.
Di default, il demone dispatcher aventerà volentieri agenti per qualsiasi numero di task in stato ready (pronti), il che è ottimo per le API cloud ma pericoloso quando si dispone di un piccolo cluster di GPU self-hosted.

Se sei nuovo a questo stack, inizia con la guida completa alla configurazione e alle operazioni di Hermes e al pilastro AI Systems per comprendere l’architettura circostante.

Questo post mostra come:

• Comprendere come Hermes Kanban e il dispatcher interagiscono con il tuo gateway LLM.
• Configurare l’esecuzione sequenziale o parallela limitata per task pesanti.
• Raggruppare il lavoro con cron in modo che i job notturni non entrino in conflitto con l’uso interattivo diurno.
• Monitorare e ottimizzare il sistema affinché le tue GPU restino impegnate ma mai sovraccariche.

Come funzionano Hermes Kanban e il dispatcher

Ad alto livello, il sistema ha tre strati:

1. La bacheca — un database SQLite durabile che memorizza task, colonne, relazioni e cronologia.
2. I worker — profili Hermes che possono essere avviati in workspace isolati per elaborare un task.
3. Il demone dispatcher — un processo a lunga durata che monitora la bacheca e promuove i task in esecuzioni (runs).

Quando crei un task usando la CLI o la dashboard, solitamente inizia in una colonna backlog o ready.
Il dispatcher scansiona periodicamente i task che soddisfano i tuoi filtri, prende in carico atomicamente una carta e avvia il profilo assegnato con gli strumenti e la memoria giusti.
Ogni worker comunica quindi con il tuo gateway LLM o runtime locale — ad esempio un proxy compatibile OpenAI che fronteggia 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 il fan-out delle richieste su Ollama stesso, questo si abbina bene con Come Ollama Gestisce le Richieste Parallele.

Se non fai nient’altro e aggiungi cinquanta task di ricerca pesanti, il dispatcher potrebbe provare ad avviarli tutti e cinquanta, inondando il tuo gateway con richieste concorrenti.
Su un nodo limitato da una singola GPU o CPU, questo produce code, thrashing (cambio contesto eccessivo) e timeout invece di throughput.

Strategia 1: Ridurre la concorrenza al dispatcher

Il controllo più semplice è limitare quanti worker il dispatcher può eseguire in parallelo.
Nella tua configurazione Hermes vedrai tipicamente una sezione che controlla il dispatcher Kanban e il pool di worker.

Nelle versioni attuali di Hermes, il dispatcher è incorporato in hermes gateway start di default, e lo stesso kernel di claim e spawn applica limiti di concorrenza anche lì.
Tuttavia, gli utenti segnalano comportamenti strani che possono sembrare una deriva dei limiti, quindi convalida le condizioni di runtime prima di dare la colpa al limite stesso.

Un esempio minimo usando una configurazione in stile TOML potrebbe essere simile a questo:

[kanban.dispatcher]
enabled = true
poll_interval_seconds = 10
max_active_tasks = 3

[kanban.workers]
profile = "researcher"
max_parallel_per_profile = 2

Se la tua versione utilizza nomi di chiave diversi, mantieni la stessa intenzione quando mappi le impostazioni. I nomi dei comandi e i flussi operativi sono riassunti nella scheda di riferimento rapida per la CLI di Hermes Agent:

• un limite per i task attivi totali sull’intera bacheca
• un limite per il parallelismo per profilo o per pool di worker
• intervallo opzionale di tick del dispatch

Notevoli problemi noti da documentazione e thread della community:

• Non eseguire sia il dispatch embedded nel gateway che il legacy hermes kanban daemon --force sulla stessa kanban.db perché ciò crea gare di claim (race conditions).
• Se il gateway è giù, i task ready non vengono dispaccati affatto, per poi apparire in un’ondata quando il gateway ritorna.
• Un intervallo di dispatch lungo può sembrare uno scheduling irregolare perché i claim avvengono a scatti invece che continuamente.
• Le vecchie build di Kanban avevano diversi casi limite di stato di esecuzione e re-claim risolti in patch successive, quindi il comportamento può variare per versione.

Lista di verifica rapida quando il comportamento sembra sbagliato:

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

# 2) controlla la flag di dispatch in modalità gateway
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 active

Concetti chiave:

• max_active_tasks limita quanti task Kanban possono essere nello stato active contemporaneamente.
• max_parallel_per_profile assicura che, anche se esegui molti profili, solo un piccolo numero di quelli pesanti venga eseguito insieme.
• Con un piccolo cluster self-hosted, solitamente vuoi valori tra 1 e 4 per mantenere la latenza prevedibile.

Quando distribuisci Hermes per la prima volta vicino al tuo gateway LLM, inizia con cautela:

• Inizia con max_active_tasks = 1.
• Osserva l’utilizzo di GPU e CPU.
• Aumenta a 2 o 3 solo se l’hardware è chiaramente sottoutilizzato.

Strategia 2: Codificare le dipendenze per flussi strettamente sequenziali

Alcuni workflow dovrebbero essere eseguiti strettamente uno dopo l’altro — per esempio:

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

Hermes Kanban supporta dipendenze genitore-figlio tra task in modo che una carta figlia diventi dispacciabile solo quando il suo genitore è completato.

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

#!/usr/bin/env bash

set -euo pipefail

parent_id="$(hermes kanban add \
  --title 'Ingestione log clienti per Aprile' \
  --profile 'etl-worker' \
  --column backlog)"

hermes kanban add \
  --title 'Generazione report anomalie Aprile' \
  --profile 'analytics-worker' \
  --column backlog \
  --parent "${parent_id}"

hermes kanban add \
  --title 'Pubblicazione riassunto Aprile sulla dashboard' \
  --profile 'reporting-worker' \
  --column backlog \
  --parent "${parent_id}"

Con una politica di bacheca appropriata e limiti dispatcher bassi, solo il task genitore viene eseguito per primo.
Una volta completato, i task figli diventano gradualmente pronti, e il dispatcher li preleva uno per uno senza mai superare i tuoi limiti di concorrenza.

Strategia 3: Disabilitare il dispatch automatico e usare cron

Per alcuni ambienti, potresti preferire finestre temporali esplicite per carichi di lavoro pesanti.
Ad esempio, potresti voler far eseguire task di ricerca e ingestione documenti dopo mezzanotte, mentre le GPU sono inattive.

Ci sono due varianti di scheduling che le persone chiamano cron in questo setup:

1. Cron dell’host Linux usando crontab.
2. Espressioni cron del scheduler interno di Hermes nella configurazione Hermes.

Opzione A: Cron dell’host Linux

In questo modello, disabiliti il dispatch automatico di Kanban e lasci che il sistema operativo programmi uno script wrapper.

Uno script di esempio:

#!/usr/bin/env bash

set -euo pipefail

MAX_TO_PROMOTE="${1:-3}"

ready_ids="$(hermes kanban list --column ready --limit "${MAX_TO_PROMOTE}" --quiet)"

if [ -z "${ready_ids}" ]; then
  exit 0
fi

for id in ${ready_ids}; do
  echo "Promozione del task ${id} a active"
  hermes kanban promote --id "${id}" --column active
done

Poi aggiungi una voce cron Linux sull’host dove gira il dispatcher o il gateway:

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

Questo garantisce che non più di due nuovi task diventino attivi ogni quindici minuti, indipendentemente da quanti task aggiungi nella colonna ready.

Opzione B: Scheduler cron interno di Hermes

Se preferisci mantenere le regole di scheduling all’interno di Hermes stesso, definisci un job programmato con un’espressione cron nella configurazione di Hermes e chiama lo stesso comando promote lì.

Pattern di esempio:

[kanban.dispatcher]
enabled = false

[[scheduler.jobs]]
name = "kanban-batch-promote"
cron = "*/15 * * * *"
command = "hermes kanban promote-batch --from ready --to active --max 2"
timezone = "Australia/Melbourne"

Se la tua build di Hermes espone comandi di gestione dello scheduler, puoi registrare lo stesso job dalla CLI invece di modificare manualmente i file di configurazione:

hermes scheduler jobs add \
  --name "kanban-batch-promote" \
  --cron "*/15 * * * *" \
  --timezone "Australia/Melbourne" \
  --command "hermes kanban promote-batch --from ready --to active --max 2"

hermes scheduler jobs list

Se la versione installata non ha hermes scheduler jobs ..., continua a usare il metodo basato su configurazione sopra, poi ricarica o riavvia Hermes affinché lo scheduler prenda il nuovo job.

Come usarlo in sicurezza:

• Mantieni kanban.dispatcher.enabled = false se il job dello scheduler è il tuo unico promotore.
• Inizia con un valore --max basso, come 1 o 2.
• Metti i log dello scheduler nella tua normale pipeline di log di Hermes in modo che promozioni saltate o fallite siano visibili.

Questo ti dà lo stesso comportamento di raggruppamento (batching) del cron Linux, ma gestito come configurazione Hermes invece che a livello di host con crontab.

Strategia 4: Segmentare bacheche e profili per gateway diversi

Se operi più backend LLM — per esempio:

• un nodo GPU piccolo con un modello instruct da 7B
• un nodo solo CPU per classificazione leggera
• una macchina separata di fascia alta per ragionamento pesante

puoi ridurre la contesa assegnando profili e bacheche Hermes diversi a ciascun gateway.

Pattern tipico:

• Crea profili come research-gpu, summarise-cpu, ops-gateway.
• Configura ogni profilo con un URL base e una chiave API dedicate per il proprio gateway.
• Crea corsie Kanban separate o persino bacheche separate per ogni profilo.

Quando combinato con i limiti del dispatcher, questo mantiene ogni gateway saturo dal proprio set di worker senza che un carico rumoroso affami gli altri.

Monitoraggio e Ottimizzazione di Hermes Kanban

Indipendentemente dalla strategia che scegli, 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 task sono in backlog, ready, active e done.

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

Inizia con una bassa concorrenza, poi aumenta gradualmente i limiti monitorando:

• latenza in aumento a throughput costante
• aumento di timeout o errori di rate limit
• code lunghe dove alcuni task 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 ingegneristici a lunga durata
• collaborazione multi-agente con profili nominativi
• workflow che devono sopravvivere a riavvii e reboot dell’host
• umani che vogliono una dashboard per triare il lavoro

Se hai bisogno solo di un’esecuzione singola 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 bacheca Kanban più il dispatcher sono la base giusta.

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