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

Hermes Agent dostarcza tablicę zadań w stylu Kanban, która może łatwo przeciążyć Twoją własną bramkę LLM, jeśli pozwolisz, by wszystkie zadania uruchamiały się jednocześnie.

Hermes Kanban to trwała, wieloprofilowa tablica oparta na pliku ~/.hermes/kanban.db.
Każdy wiersz reprezentuje fazę pracy, a każda karta to zadanie, które może zostać przyznane konkretnemu profilowi Hermes.
Domyślnie demon dystrybutora chętnie uruchomi agenty dla dowolnej liczby zadań w stanie gotowy (ready), co jest świetne dla chmurowych API, ale niebezpieczne, gdy masz małą klastrę własnych GPU.

Jeśli dopiero zaczynasz z tym stos technologiczny, zacznij od szerszego przewodnika po konfiguracji i obsłudze Hermes oraz filaru Systemów AI w celu zrozumienia otaczającej architektury.

Ten artykuł pokazuje, jak:

• Zrozumieć, jak Hermes Kanban i dystrybutor взаимодейują z Twoją bramką LLM.
• Skonfigurować sekwencyjne lub ograniczone równoległe wykonywanie dla ciężkich zadań.
• Grupować pracę za pomocą cron, aby nocne zadania nie kolidowały z interaktywnym użytkowaniem w ciągu dnia.
• Monitorować i stroić system, aby Twoje GPU były zajęte, ale nigdy nieprzeciążone.

Jak działają Hermes Kanban i dystrybutor

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

1. Tablica — trwała baza danych SQLite przechowująca zadania, kolumny, relacje i historię.
2. Pracownicy — profile Hermes, które mogą być uruchamiane w izolowanych przestrzeniach roboczych w celu przetworzenia zadania.
3. Demon dystrybutora — długotrwały proces, który obserwuje tablicę i przekształca zadania w uruchomienia.

Gdy tworzysz zadanie za pomocą CLI lub pulpitu nawigacyjnego, zwykle zaczyna ono w kolumnie backlog lub ready (gotowy).
Dystrybutor okresowo skanuje zadania spełniające Twoje filtry, atomowo przyznaje kartę i uruchamia przypisany profil z odpowiednimi narzędziami i pamięcią.
Każdy pracownik następnie komunikuje się z Twoją bramką LLM lub lokalnym środowiskiem wykonawczym — na przykład z proxy kompatybilnym z OpenAI, działającym przed Ollama, vLLM lub llama.cpp. Przy wyborze wdrożenia między tymi środowiskami wykonawczymi, skorzystaj z Hosting LLM w 2026 roku: Porównanie lokalnej, własnej i chmurowej infrastruktury. Jeśli stroisz rozgałęzianie żądań w samym Ollama, dobrze komponuje się to z Jak Ollama obsługuje równoległe żądania.

Jeśli nie zrobisz nic innego i dodasz pięćdziesiąt ciężkich zadań badawczych, dystrybutor może spróbować uruchomić je wszystkie, zalewając Twoją bramkę jednoczesnymi żądaniami.
Na pojedynczym węźle GPU lub ograniczonym procesorem CPU powoduje to kolejkowanie, thrashing i timeouty zamiast przepustowości.

Strategia 1: Zmniejszenie równoległości w dystrybutorze

Najprostszą kontrolą jest ograniczenie liczby pracowników, których dystrybutor może uruchamiać równolegle.
W konfiguracji Hermes zwykle znajdziesz sekcję kontrolującą dystrybutora Kanban i pulę pracowników.

W aktualnych wydaniach Hermes dystrybutor jest domyślnie wbudowany w komendę hermes gateway start, a ten sam rdzeń przyznawania i uruchamiania egzekwuje tam limity równoległości.
Jednak użytkownicy zgłaszają dziwne zachowania, które mogą wyglądać jak dryf limitów, więc zweryfikuj warunki środowiska wykonawczego, zanim obwinisz sam limit.

Minimalny przykład używający konfiguracji w stylu TOML może wyglądać następująco:

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

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

Jeśli Twoja wersja używa innych nazw kluczy, zachowaj tę samą intencję przy mapowaniu ustawień. Nazwy komend i przepływy operatora są podsumowane w krótkim przewodniku CLI Hermes Agent:

• jeden limit dla całkowitej liczby aktywnych zadań na całej tablicy
• jeden limit dla równoległości na profil lub pulę pracowników
• opcjonalny interwał tiku dystrybucji

Znane pułapki z dokumentacji i wątków społecznościowych:

• Nie uruchamiaj jednocześnie wbudowanego dystrybucja w bramce i legacy hermes kanban daemon --force na tym samym kanban.db, ponieważ powoduje to wyścigi przy przyznawaniu.
• Jeśli bramka jest wyłączona, zadania ready (gotowe) w ogóle nie są dystrybuowane, a następnie pojawiają się w formie wybuchu, gdy bramka wróci.
• Długi interwał dystrybucji może sprawiać wrażenie nierównej harmonogramu, ponieważ przyznawanie następuje w tikach, a nie ciągle.
• Starsze wersje Kanban miały kilka przypadków brzegowych dotyczących stanu uruchomienia i odzyskiwania, naprawionych w kolejnych patchach, więc zachowanie może różnić się w zależności od wersji.

Szybka lista kontrolna weryfikacji, gdy zachowanie wygląda nieprawidłowo:

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

# 2) sprawdź flagę dystrybucji trybu bramki
rg "dispatch_in_gateway|dispatch_interval_seconds" ~/.hermes/config.yaml

# 3) sprawdź kształt kolejki
hermes kanban list --status ready
hermes kanban list --status active

Kluczowe idee:

• max_active_tasks ogranicza liczbę kart Kanban, które mogą znajdować się w stanie active (aktywny) jednocześnie.
• max_parallel_per_profile zapewnia, że nawet jeśli uruchomisz wiele profili, tylko mała liczba ciężkich z nich będzie działać razem.
• Przy małym własnym klastrze zwykle chcesz wartości między 1 a 4, aby utrzymać przewidywalne opóźnienia.

Gdy po raz pierwszy wdrażasz Hermes w pobliżu swojej bramki LLM, zacznij ostrożnie:

• Zacznij od max_active_tasks = 1.
• Obserwuj wykorzystanie GPU i CPU.
• Zwiększaj do 2 lub 3 tylko wtedy, gdy sprzęt jest wyraźnie niewykorzystywany.

Strategia 2: Kodowanie zależności dla ściśle sekwencyjnych przepływów

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

• wieloetapowe potoki danych ze wspólnymi artefaktami pośrednimi
• migracje lub zmiany infrastrukturalne
• zadania wsadowe zapisujące do tego samego obiektu store lub bazy danych

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

Możesz to zmodelować 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 dystrybutora tylko zadanie rodzic jest uruchamiane pierwsze.
Po jego zakończeniu zadania dzieci stopniowo stają się gotowe, a dystrybutor pobiera je po kolei, nigdy nie przekraczając limitów równoległości.

Strategia 3: Wyłączenie automatycznej dystrybucji i użycie cron

W niektórych środowiskach możesz preferować jawne okna czasowe dla ciężkich obciążen.
Na przykład możesz chcieć, aby zadania badawcze i ingest dokumentów uruchamiały się po północy, gdy GPU są bezczynne.

Istnieją dwie warianty harmonogramu, które ludzie nazywają cron w tej konfiguracji:

1. Cron hosta Linux używający crontab.
2. Wewnętrzne wyrażenia cron harmonogramu Hermes w konfiguracji Hermes.

Opcja A: Cron hosta Linux

W tym modelu wyłączasz automatyczną dystrybucję Kanban i pozwalasz systemowi operacyjnemu harmonogramować skrypt opakowujący.

Przykładowy skrypt:

#!/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 "Promoting task ${id} to active"
  hermes kanban promote --id "${id}" --column active
done

Następnie dodaj wpis Linux cron na hoście, gdzie działa dystrybutor lub bramka:

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

To gwarantuje, że co piętnaście minut nie więcej niż dwa nowe zadania staną się aktywne, niezależnie od tego, ile kart wrzucisz do ready (gotowe).

Opcja B: Wewnętrzny harmonogram cron Hermes

Jeśli wolisz zachować reguły harmonogramu wewnątrz samego Hermes, zdefiniuj zadanie zaplanowane z wyrażeniem cron w konfiguracji Hermes i wywołaj tam tę samą komendę promote.

Przykładowy wzorzec:

[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"

Jeśli Twoje wydanie Hermes udostępnia komendy zarządzania harmonogramem, możesz zarejestrować to samo zadanie z CLI zamiast ręcznej edycji plików konfiguracyjnych:

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

Jeśli zainstalowana wersja nie ma hermes scheduler jobs ..., kontynuuj używanie metody opartej na konfiguracji powyżej, a następnie przeładuj lub zrestartuj Hermes, aby harmonogram mógł podjąć nowe zadanie.

Jak używać tego bezpiecznie:

• Zachowaj kanban.dispatcher.enabled = false, jeśli zadanie harmonogramu jest jedynym promotorem.
• Zacznij od niskiej wartości --max, takiej jak 1 lub 2.
• Umieść logi harmonogramu w normalnym pipeline logów Hermes, aby pominięte lub nieudane promocje były widoczne.

Daje to takie samo zachowanie grupowania jak Linux cron, ale zarządzane jako konfiguracja Hermes zamiast hostowego crontab.

Strategia 4: Segmentacja tablic i profili dla różnych bramek

Jeśli obsługujesz wiele backendów LLM — na przykład:

• mały węzeł GPU z modelem instruct 7B
• węzeł tylko CPU do lekkiej klasyfikacji
• osobny wysokiej klasy komputer do ciężkiego wnioskowania

możesz zmniejszyć konkurencję, przypisując różne profile Hermes i tablice do każdej bramki.

Typowy wzorzec:

• Twórz profile takie jak research-gpu, summarise-cpu, ops-gateway.
• Skonfiguruj każdy profil z dedykowanym adresem URL podstawowym i kluczem API dla własnej bramki.
• Twórz osobne wiersze Kanban lub nawet osobne tablice dla każdego profilu.

W połączeniu z limitami dystrybutora utrzymuje to każdą bramkę nasyconą przez własny zestaw pracowników, bez jednego głośnego obciążenia głodzącego inne.

Monitorowanie i strojenie Hermes Kanban

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

• Metryki bramki LLM — szybkość żądań, opóźnienia, błąd, przepustowość tokenów.
• Zdrowie węzła — wykorzystanie GPU, użycie VRAM, obciążenie CPU i RAM.
• Metryki Hermes — ile zadań jest w backlogu, gotowych, aktywnych i zakończonych.

Dla produkcyjnych baz metryk i dashboardów, zobacz Monitoruj wnioskowanie LLM w produkcji z Prometheus i Grafana oraz szerszy hub Wydajności LLM.

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

• rosnące opóźnienia przy stałej przepustowości
• zwiększające się błędy timeout lub limitu szybkości
• długie ogony, gdzie niektóre zadania pozostają aktywne przez bardzo długi czas

Jak tylko zauważysz te objawy, cofnij się do poprzedniej stabilnej konfiguracji i utrzymaj ją jako domyślną.

Kiedy Kanban jest odpowiednim 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 trywialnej pracy

Jeśli potrzebujesz tylko pojedynczego uruchomienia, aby utworzyć kilka tymczasowych pomocników, wbudowane narzędzia do delegowania zadań są zwykle prostsze.
Gdy potrzebujesz historii, dashboardów i ścisłej kontroli nad tym, jak Twoi agenty uderzają we własne LLM, tablica Kanban plus dystrybutor jest odpowiednią podstawą.

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