Канбан в Hermes Agent для самохостинга рабочих процессов LLM

Агент Hermes поставляется с доской в стиле Канбан и шлюзом Hermes Gateway, который может перегрузить вашу локально развернутую модель LLM, если одновременно будет отправлено слишком много задач.

Могу сказать, что таким образом вы легко сможете провести DDoS-атаку на свою собственную LLM.

Hermes Kanban — это надежная многопрофильная доска, работающая на базе файла ~/.hermes/kanban.db.
Каждая дорожка представляет собой этап работы, а каждая карточка — это задача, которую может взять на себя определенный профиль Hermes.
По умолчанию диспетчер может повысить статус многих задач ready за один проход. Это нормально для эластичных облачных API, но может перегрузить небольшой локальный кластер GPU.

Если вы новичок в этом стеке, начните с более подробного руководства по настройке и эксплуатации Hermes и раздела Системы ИИ, чтобы понять окружающую архитектуру.

В этой статье показано, как:

• Понимать, как взаимодействие диспетчеризации Hermes Kanban влияет на ваш шлюз LLM.
• Контролировать параллелизм безопасно для тяжелых задач.
• Группировать повышение статуса задач через cron, чтобы фоновые задания не конфликтовали с интерактивным использованием.
• Мониторить и настраивать систему так, чтобы GPU оставались занятыми, но без перегрузки.

Как работают Hermes Kanban и диспетчер

На высоком уровне система состоит из трех слоев:

1. Доска — надежное состояние SQLite для задач, колонок, связей и истории.
2. Воркеры — профили Hermes, запущенные в изолированных рабочих пространствах для обработки задачи.
3. Диспетчер — долгоживущий процесс, который сканирует доски на наличие задач для диспетчеризации и запускает их выполнение.

Задачи, созданные через CLI или панель управления, обычно начинаются в статусе backlog или ready.
Диспетчер сканирует подходящие карточки, атомарно захватывает одну и запускает назначенный профиль с его инструментами и памятью.
Каждый воркер затем обращается к вашему шлюзу LLM или локальному runtime (например, к конечным точкам, совместимым с OpenAI, на базе Ollama, vLLM или llama.cpp). Для выбора вариантов развертывания среди этих runtime используйте руководство Хостинг LLM в 2026 году: сравнение локальных и облачных инфраструктур. Если вы настраиваете параллельную обработку запросов непосредственно в Ollama, это хорошо сочетается с статьей Как Ollama обрабатывает параллельные запросы.

Если вы добавите много тяжелых задач и не ограничите количество повышений статуса, ваш шлюз может быть затоплен параллельными запросами.
На хосте с одним GPU или ограниченным процессором это часто означает очередь, фрагментацию и таймауты вместо повышения пропускной способности.

Практическое ограничение на сегодняшний день

В текущих сборках Hermes многие команды используют конфигурацию диспетчера, которая экспонирует только два ключа диспетчеризации Kanban и не применяет глобальное ограничение активных задач из конфигурации:

kanban:
  dispatch_in_gateway: false
  dispatch_interval_seconds: 10

Для контроля активных задач полагайтесь на явный ритм диспетчеризации (hermes kanban dispatch --max ...) плюс моделирование зависимостей.

Известные подводные камни:

• Не запускайте встроенную в шлюз диспетчеризацию и hermes kanban daemon --force одновременно для одной доски, иначе могут возникнуть гонки при захвате задач.
• Если шлюз недоступен, задачи ready не диспетчеризируются и могут всплеском выполниться позже, когда сервис вернется.
• Длиннные интервалы диспетчеризации ощущаются неравномерно, потому что захват происходит дискретно.
• Поведение может различаться между версиями, так как крайние случаи состояния выполнения и возврата задач исправлялись с течением времени.

Быстрая проверка, когда поведение выглядит неправильно:

# 1) убедитесь, что активен только один путь диспетчера
pgrep -af "hermes gateway start|hermes kanban daemon"

# 2) проверьте настроенные ключи диспетчера Kanban
rg "dispatch_in_gateway|dispatch_interval_seconds" ~/.hermes/config.yaml

# 3) проверьте состояние очереди
hermes kanban list --status ready
hermes kanban list --status running

Ключевые идеи:

• Конфигурация диспетчера настраивает dispatch_in_gateway и dispatch_interval_seconds.
• dispatch --max ограничивает новые запуски в этом проходе, а не общее количество работающих задач.
• Для небольших локальных кластеров начинайте консервативно и увеличивайте лимиты только после того, как задержка стабилизируется.

При первоначальном развертывании Hermes рядом с вашим шлюзом LLM:

• Оставляйте в конфигурации только поддерживаемые ключи диспетчера Kanban.
• Наблюдайте за использованием GPU и CPU под реальной нагрузкой очереди.
• Используйте Стратегию 1 или Стратегию 2 для детерминированного ритма.

Результаты расследования и корневая причина

hermes kanban dispatch не читает config.yaml для параметра max_active_tasks.

В hermes_cli/kanban.py команда диспетчеризации экспонирует --max как лимит CLI (по умолчанию None) и передает только args.max в kb.dispatch_once(...). В этом пути нет поиска конфигурации max_active_tasks. См. исходный код hermes_cli/kanban.py.

Затем в kanban_db.dispatch_once единственным ограничением является max_spawn, с логикой, эквивалентной:

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

Нет проверки уже запущенных задач и нет ссылки на max_active_tasks в этом пути диспетчеризации. См. исходный код hermes_cli/kanban_db.py.

Эффективное поведение:

hermes kanban dispatch

неограниченно для этого прохода (ограничено размером очереди ready).

hermes kanban dispatch --max 2

ограничивает только новые запуски в этом проходе, а не общее количество работающих задач.

Настроенные конфигурационные параметры вокруг диспетчеризации шлюза — это kanban.dispatch_in_gateway и kanban.dispatch_interval_seconds.
Таким образом, max_active_tasks игнорируется в этом пути диспетчеризации, поскольку он там не реализован.

Стратегия 1 — Кодирование зависимостей для строго последовательных потоков

Некоторые рабочие процессы должны выполняться строго один за другим — например:

• многоступенчатые конвейеры данных с общими промежуточными артефактами
• миграции или изменения инфраструктуры
• пакетные задания, которые записывают в одно и то же хранилище объектов или базу данных

Hermes Kanban поддерживает зависимости родитель-потомок между задачами, так что дочерняя карточка становится доступной для диспетчеризации только после завершения родительской.

Вы можете смоделировать это с помощью небольшого вспомогательного скрипта вокруг CLI Hermes:

#!/usr/bin/env bash

set -euo pipefail

parent_id="$(hermes kanban add \
  --title 'Сбор журналов клиентов за апрель' \
  --profile 'etl-worker' \
  --column backlog)"

hermes kanban add \
  --title 'Создание отчета об аномалиях за апрель' \
  --profile 'analytics-worker' \
  --column backlog \
  --parent "${parent_id}"

hermes kanban add \
  --title 'Публикация апрельского сводного отчета на панели' \
  --profile 'reporting-worker' \
  --column backlog \
  --parent "${parent_id}"

При соответствующей политике доски и низких лимитах диспетчера сначала выполняется только родительская задача.
После ее завершения дочерние задачи постепенно становятся доступными, и диспетчер извлекает их по одной, никогда не превышая ваши лимиты параллелизма.

Стратегия 2 — Использование Linux cron с учетом работающих задач при диспетчеризации

Если вам нужен детерминированный ритм, используйте cron хоста плюс небольшой обертывающий скрипт.
Вместо того чтобы всегда вызывать dispatch --max 2, сначала подсчитайте количество текущих работающих задач, затем диспетчеризируйте только оставшиеся слоты.

Создайте 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

# или там, где установлен ваш 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 "Уже достигнут лимит: running=$running_count max=$MAX_PARALLEL, диспетчеризация пропущена"
  exit 0
fi

echo "running=$running_count max=$MAX_PARALLEL slots=$slots, диспетчеризация до $slots"

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

Сделайте его исполняемым:

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

Запустите его с:

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

Для конкретной доски:

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

Запланируйте его один раз в минуту через cron:

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

Операционные примечания:

• Cron часто имеет минимальный PATH, поэтому если hermes не найден, используйте его полный путь внутри скрипта (например /usr/local/bin/hermes).
• Если вы ведете логи в /var/log/hermes/..., сначала создайте эту директорию и убедитесь, что пользователь cron имеет права на запись.

Пример:

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

Создайте или отредактируйте записи cron с:

crontab -e

Затем проверьте с:

crontab -l

Частота меньше минуты с одним элементом cron

Cron тикает раз в минуту, но вы все равно можете диспетчеризировать чаще, запустив короткий цикл внутри скрипта.

Пример 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 запуска => каждые 15 секунд
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

Сделайте его исполняемым:

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

Запланируйте его один раз в минуту:

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

Это дает эффективную частоту меньше минуты, при этом flock предотвращает наложение запусков.

Почему это работает:

• list --status running дает текущую нагрузку работающих задач.
• dispatch --max N ограничивает только новые запуски для этого прохода.
• Вычисление N как оставшихся слотов держит общее количество работающих задач близко к вашему целевому лимиту.

Важное предостережение: этот лимит работает только для диспетчеризаций, сделанных через этот скрипт.
Отключите встроенную диспетчеризацию шлюза, иначе она все равно может повышать статус задач независимо:

kanban:
  dispatch_in_gateway: false

Официальная документация описывает обе возможности команд и указывает значения по умолчанию для диспетчеризации шлюза в руководстве по функциям Kanban: Документация Hermes Kanban.

Внутренний Cron Hermes

Не используйте его. Действительно ли вы хотите, чтобы ваша LLM обрабатывала регулярные промпты типа Выполнить в терминале команду /path/hermes-kanban-dispatch-capped.sh, особенно когда она занята полезной работой?

Мониторинг и настройка Hermes Kanban

Какой бы стратегию вы ни выбрали, вы должны мониторить:

• Метрики шлюза LLM — частота запросов, задержка, уровень ошибок, пропускная способность токенов.
• Состояние узла — использование GPU, использование VRAM, нагрузка CPU и RAM.
• Метрики Hermes — сколько задач в backlog, ready, active и done.

Для производственных базовых метрик и дашбордов см. Мониторинг инференса LLM в production с Prometheus и Grafana и более широкий раздел Центр производительности LLM.

Начинайте с низкой параллельности, затем постепенно повышайте лимиты, наблюдая за:

• ростом задержки при постоянной пропускной способности
• увеличением ошибок таймаута или лимита частоты
• длинными хвостами, где некоторые задачи остаются активными очень долго

Как только вы заметите эти симптомы, откатитесь к предыдущей стабильной конфигурации и оставьте ее как значение по умолчанию.

Когда Kanban — правильный инструмент

Hermes Kanban сияет, когда у вас есть:

• долгосрочные бэклоги исследований или инженерных задач
• многоагентное сотрудничество с именованными профилями
• рабочие процессы, которые должны пережить перезагрузки и перезапуски хоста
• люди, которые хотят дашборд для сортировки работы

Если вам нужна только одноразовая задача для создания нескольких временных помощников, встроенные инструменты делегирования задач обычно проще.
Как только вам понадобится история, дашборды и строгий контроль над тем, как ваши агенты обращаются к локальным LLM, доска Kanban плюс диспетчер — правильная основа.

С несколькими настройками конфигурации и опциональной пакетной обработкой через cron вы можете держать Hermes Kanban отзывчивым, одновременно защищая свой шлюз и оборудование.