Kanban w Hermes Agent dla samodzielnie hostowanych przepływów pracy LLM

Hermes Agent dostarcza tablicę w stylu Kanban oraz Hermes Gateway, które mogą przytłoczyć Twoją własną samohostowaną LLM, jeśli jednocześnie zostanie uruchomionych zbyt wiele zadań.

Można śmiało powiedzieć, że w ten sposób łatwo jest przeprowadzić atak DDoS na własną LLM.

Hermes Kanban to trwała tablica wieloprofilowa oparta na pliku ~/.hermes/kanban.db.
Każdy pas reprezentuje fazę pracy, a każda karta to zadanie, które może zostać przypisane do konkretnego profilu Hermes.
Domyślnie dyspozytor może promować wiele zadań w stanie ready w jednym przebiegu. To rozwiązanie sprawdza się w przypadku elastycznych interfejsów API w chmurze, ale może przeciążyć mały, własny klastr GPU.

Jeśli dopiero zaczynasz przygodę z tym stackiem, zacznij od ogólnego przewodnika po konfiguracji i działaniu Hermes oraz filaru Systemy AI w celu zrozumienia otaczającej architektury.

Ten artykuł pokaże, jak:

• Zrozumieć, jak interakcja wysyłania zadań w Hermes Kanban oddziałuje na bramkę LLM.
• Kontrolować równoległość bezpiecznie w przypadku ciężkich zadań.
• Grupować promocje za pomocą cron, aby zadania tła nie kolidowały z użyciem interaktywnym.
• Monitorować i stroić system, aby GPU były zajęte, ale nie przeciążone.

Jak działają Hermes Kanban i dyspozytor

Na wysokim poziomie system składa się z trzech warstw:

1. Tablica – trwały stan SQLite dla zadań, kolumn, relacji i historii.
2. Pracownicy – profile Hermes uruchamiane w izolowanych przestrzeniach roboczych w celu przetworzenia zadania.
3. Dyspozytor – długotrwały proces skanujący karty gotowe do wysłania i uruchamiający wykonania.

Zadania tworzone z CLI lub pulpitu nawigacyjnego zazwyczaj zaczynają się w backlog lub ready.
Dyspozytor skanuje kwalifikujące się karty, atomistycznie przejmuje jedną i uruchamia przypisany profil z jego narzędziami i pamięcią.
Każdy pracownik następnie wywołuje Twoją bramkę LLM lub lokalną środowisko uruchomieniowe (na przykład końce interfejsu kompatybilne z OpenAI wspierane przez Ollama, vLLM lub llama.cpp). W przypadku wyboru rozwiązań wdrożeniowych między tymi środowiskami uruchomieniowymi, skorzystaj z przewodnika Hosting LLM w 2026 roku: Infrastruktura lokalna, samohostowana i chmurowa w porównaniu. Jeśli stroisz rozszerzanie żądań w samym Ollama, dobrze komponuje się to z artykułem Jak Ollama obsługuje żądania równoległe.

Jeśli dodasz wiele ciężkich zadań i nie ograniczysz promocji, Twoja bramka może zostać zalewana równoległymi żądaniami.
W przypadku hosta opartego na jednym GPU lub procesorze CPU oznacza to często kolejkowanie, thrashing i przekraczanie limitów czasu zamiast lepszej przepustowości.

Praktyczne ograniczenie dzisiaj

W obecnych wersjach Hermes, na których pracuje wiele zespołów, konfiguracja dyspozytora udostępnia tylko dwa klucze dystrybucji Kanban i nie stosuje globalnego limitu aktywnych zadań z konfiguracji:

kanban:
  dispatch_in_gateway: false
  dispatch_interval_seconds: 10

Do kontroli aktywnych zadań polegaj na eksplicitnej częstotliwości dystrybucji (hermes kanban dispatch --max ...) oraz modelowaniu zależności.

Znane pułapki:

• Nie uruchamiaj dystrybucji osadzonej w bramce oraz hermes kanban daemon --force na tej samej tablicy, ponieważ może dojść do wyścigu w przejmowaniu zadań.
• Jeśli bramka jest wyłączona, zadania ready nie są wysyłane i mogą wybuchnąć później, gdy usługa wróci.
• Dłuższe interwały dystrybucji mogą wydawać się nierównomierne, ponieważ przejmowanie następuje w odstępach czasu.
• Zachowanie może się różnić między wersjami, ponieważ przypadki brzegowe stanu uruchomieniowego i ponownego przejmowania były łatanne z czasem.

Szybka weryfikacja, gdy zachowanie wygląda nieprawidłowo:

# 1) potwierdź, że aktywna jest dokładnie jedna ścieżka dyspozytora
pgrep -af "hermes gateway start|hermes kanban daemon"

# 2) sprawdź podpięte klucze dyspozytora Kanban
rg "dispatch_in_gateway|dispatch_interval_seconds" ~/.hermes/config.yaml

# 3) zinspektuj kształt kolejki
hermes kanban list --status ready
hermes kanban list --status running

Kluczowe pomysły:

• Konfiguracja dyspozytora podłącza dispatch_in_gateway i dispatch_interval_seconds.
• dispatch --max ogranicza nowe wystąpienia w tym przebiegu, a nie całkowitą liczbę uruchomionych zadań.
• W przypadku małych, własnych klastrów zacznij ostrożnie i zwiększaj limity dopiero po ustabilizowaniu się opóźnień.

Podczas pierwszego wdrożenia Hermes w pobliżu bramki LLM:

• Pozostaw w konfiguracji tylko obsługiwane klucze dyspozytora Kanban.
• Obserwuj wykorzystanie GPU i CPU pod rzeczywistym obciążeniem kolejki.
• Używaj Strategii 1 lub Strategii 2 dla deterministycznego tempa.

Wyniki dochodzenia i przyczyna źródłowa

hermes kanban dispatch nie odczytuje config.yaml dla max_active_tasks.

W hermes_cli/kanban.py polecenie dispatch udostępnia --max jako limit CLI (domyślnie None) i przekazuje tylko args.max do kb.dispatch_once(...). Nie ma tam wyszukiwania konfiguracji max_active_tasks. Zobacz hermes_cli/kanban.py raw.

Następnie w kanban_db.dispatch_once jedynym limitem jest max_spawn, z logiką równoważną:

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

Nie ma tam sprawdzenia już uruchomionych zadań ani odwołania do max_active_tasks w tej ścieżce dystrybucji. Zobacz hermes_cli/kanban_db.py raw.

Efektywne zachowanie:

hermes kanban dispatch

nieograniczone w tym przebiegu (ograniczone wielkością kolejki ready).

hermes kanban dispatch --max 2

ogranicza tylko nowe wystąpienia w tym przebiegu, a nie całkowitą liczbę uruchomionych zadań.

Podpiętymi gałkami konfiguracji wokół dystrybucji bramki są kanban.dispatch_in_gateway i kanban.dispatch_interval_seconds.
Zatem max_active_tasks jest ignorowane w tej ścieżce dystrybucji, ponieważ nie jest tam zaimplementowane.

Strategia 1 - Kodowanie zależności dla ściśle sekwencyjnych przepływów

Niektóre przepływy pracy powinny być uruchamiane ściśle jeden po drugim — na przykład:

• wieloetapowe potoki danych ze wspólnymi artefaktami pośrednimi
• migracje lub zmiany infrastrukturalne
• zadania wsadowe zapisujące do tej samej magazynu obiektów lub bazy danych

Hermes Kanban obsługuje zależności rodzic-dziecko między zadaniami, dzięki czemu karta dziecka staje się wysyłalna dopiero po zakończeniu pracy rodzica.

Możesz to zamodelować za pomocą małego skryptu pomocniczego wokół 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}"

Z odpowiednią polityką tablicy i niskimi limitami dyspozytora najpierw uruchamiane jest tylko zadanie rodzica.
Po jego zakończeniu zadania potomne stopniowo stają się gotowe, a dyspozytor pobiera je po jednym, nie przekraczając nigdy limitów równoległości.

Strategia 2 - Użyj Linux cron z limitem dystrybucji uwzględniającym uruchomione zadania

Jeśli chcesz deterministycznego tempa, użyj cron hosta oraz małego skryptu opakowującego.
Zamiast zawsze wywoływać dispatch --max 2, najpierw policz aktualnie uruchomione zadania, a następnie wyślij tylko pozostałe sloty.

Utwórz 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

# lub tam, gdzie masz zainstalowanego hermesa
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"

Uczyń go wykonywalnym:

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

Uruchom go za pomocą:

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

Dla konkretnej tablicy:

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

Zaplanuj go raz na minutę za pomocą cron:

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

Uwagi operacyjne:

• Cron często ma minimalną ścieżkę PATH, więc jeśli hermes nie zostanie znaleziony, użyj jego pełnej ścieżki wewnątrz skryptu (np. /usr/local/bin/hermes).
• Jeśli logujesz do /var/log/hermes/..., najpierw utwórz ten katalog i upewnij się, że użytkownik cron ma dostęp do zapisu.

Przykład:

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

Twórz lub edytuj wpisy cron za pomocą:

crontab -e

Następnie zweryfikuj za pomocą:

crontab -l

Częstotliwość mniejsza niż minuta z jednym wpisem cron

Cron tikuje raz na minutę, ale nadal możesz wysyłać zadania częściej, uruchamiając krótką pętlę wewnątrz skryptu.

Przykład 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 uruchomienia => co 15 sekund
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

Uczyń go wykonywalnym:

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

Zaplanuj go raz na minutę:

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

Daje to efektywną częstotliwość mniejszą niż minuta, podczas gdy flock zapobiega nakładaniu się uruchomień.

Dlaczego to działa:

• list --status running daje aktualne obciążenie uruchomionych zadań.
• dispatch --max N ogranicza tylko nowe wystąpienia w tym przebiegu.
• Obliczanie N jako pozostałych slotów utrzymuje całkowitą liczbę uruchomionych zadań blisko docelowego limitu.

Ważne zastrzeżenie: ten limit działa tylko dla dystrybucji wykonanych przez ten skrypt.
Wyłącz dystrybucję osadzoną w bramce, w przeciwnym razie nadal może ona promować zadania niezależnie:

kanban:
  dispatch_in_gateway: false

Oficjalna dokumentacja opisuje obie możliwości poleceń i zauważa domyślne dystrybucje bramki w przewodniku po funkcjach Kanban: Dokumentacja Hermes Kanban.

Wewnętrzny Hermes Cron

Nie używaj go. Czy naprawdę chcesz, aby Twoja LLM przetwarzała regularne prompty takie jak Execute in terminal the command /path/hermes-kanban-dispatch-capped.sh, szczególnie gdy jest zajęta wykonywaniem przydatnej pracy?

Monitorowanie i strojenie Hermes Kanban

Bez względu na wybraną strategię, powinieneś monitorować:

• Metryki bramki LLM — szybkość żądań, opóźnienie, wskaźnik błędów, przepustowość tokenów.
• Zdrowie węzła — wykorzystanie GPU, użycie VRAM, obciążenie CPU i pamięci RAM.
• Metryki Hermes — ile zadań znajduje się w backlogu, ready, active i done.

W przypadku bazowych metryk produkcyjnych i pulpitów nawigacyjnych zobacz Monitorowanie wnioskowania LLM w produkcji z Prometheus i Grafana oraz szerszy Hub Wydajności LLM.

Zacznij od niskiej równoległości, a następnie stopniowo podnosz limity, obserwując:

• rosnące opóźnienie przy stałej przepustowości
• zwiększającą się liczbę błędów przekraczania limitu czasu lub limitów szybkości
• długie ogony, gdzie niektóre zadania pozostają aktywne przez bardzo długi czas

Natychmiast po zauważeniu tych objawów cofnij się do poprzedniej stabilnej konfiguracji i zachowaj ją jako domyślną.

Kiedy Kanban jest właściwym narzędziem

Hermes Kanban błyszczy, gdy masz:

• długotrwałe backlogi badawcze lub inżynieryjne
• współpracę wieloagentową z nazwanymi profilami
• przepływy pracy, które muszą przetrwać restarty i rebooty hosta
• ludzi, którzy chcą pulpitu nawigacyjnego do triażu pracy

Jeśli potrzebujesz tylko pojedynczego uruchomienia, aby utworzyć kilka tymczasowych asystentów, wbudowane narzędzia do delegowania zadań są zazwyczaj prostsze.
Gdy potrzebujesz historii, pulpitów nawigacyjnych i ścisłej kontroli nad tym, jak Twoje agenty oddziałują na własne LLM, tablica Kanban plus dyspozytor jest właściwą podstawą.

Dzięki kilku modyfikacjom konfiguracji i opcjonalnemu grupowaniu opartemu na cronie możesz utrzymać responsywność Hermes Kanban, chroniąc jednocześnie swoją bramkę i sprzęt.