Kanban в Hermes Agent для самодостаточных LLM-воркфлоу

Агент Hermes поставляется с канбан-доской для задач, которая может легко перегрузить ваш локальный шлюз 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 или локальным рантаймом — например, прокси, совместимым с OpenAI, который работает перед Ollama, vLLM или llama.cpp. Для выбора вариантов развертывания в этих средах используйте руководство Развертывание LLM в 2026 году: Сравнение локальных, самодостаточных и облачных инфраструктур. Если вы настраиваете параллельную обработку запросов непосредственно в Ollama, это хорошо сочетается с материалом [Как Ollama обрабатывает параллельные запросы](https://www.glukhov.org/ru/llm-performance/ollama/how-ollama-handles-parallel-requests/ “Как Ollama обрабатывает параллельные запросы + как настроить OLLAMA_NUM_PARALLEL для пропускной способности и задержки.”}).

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

Стратегия 1: Снижение параллелизма на уровне диспетчера

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

В текущих версиях Hermes диспетчер по умолчанию встроен в команду hermes gateway start, и то же ядро захвата и запуска применяет ограничения параллелизма и там.
Однако пользователи сообщают о странном поведении, которое может выглядеть как дрейф ограничений, поэтому проверяйте условия среды выполнения, прежде чем винить само ограничение.

Минимальный пример конфигурации в стиле TOML может выглядеть так:

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

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

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

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

Известные подводные камни из документации и форумов сообщества:

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

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

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

# 2) проверьте флаг диспетчеризации в режиме шлюза
rg "dispatch_in_gateway|dispatch_interval_seconds" ~/.hermes/config.yaml

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

Основные идеи:

• max_active_tasks ограничивает количество карточек Kanban, которые могут находиться в состоянии active одновременно.
• max_parallel_per_profile гарантирует, что даже если вы запускаете много профилей, только небольшое количество тяжелых из них выполняется вместе.
• Для небольшого локального кластера обычно нужны значения от 1 до 4, чтобы задержка оставалась предсказуемой.

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

• Начните с max_active_tasks = 1.
• Наблюдайте за использованием GPU и CPU.
• Увеличивайте до 2 или 3 только если оборудование явно недогружено.

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

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

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

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

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

Стратегия 3: Отключение автоматической диспетчеризации и использование cron

Для некоторых сред вы можете предпочесть явные временные окна для ресурсоемких рабочих нагрузок.
Например, вы можете захотеть, чтобы исследовательские задачи и ingestion документов выполнялись после полуночи, когда GPU простаивают.

В этой настройке люди называют cron два варианта планирования:

1. Хостовый cron Linux с использованием crontab.
2. Внутренний планировщик cron-выражений Hermes в конфигурации Hermes.

Вариант A: Хостовый cron Linux

В этой модели вы отключаете автоматическую диспетчеризацию Kanban и позволяете ОС планировать обертку-скрипт.

Пример скрипта:

#!/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 "Перевод задачи ${id} в активное состояние"
  hermes kanban promote --id "${id}" --column active
done

Затем добавьте запись Linux cron на хосте, где работает диспетчер или шлюз:

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

Это гарантирует, что каждые пятнадцать минут активируется не более двух новых задач, независимо от того, сколько карточек вы сбросили в состояние ready.

Вариант B: Внутренний планировщик cron Hermes

Если вы предпочитаете хранить правила планирования внутри самого Hermes, определите запланированное задание с cron-выражением в конфигурации Hermes и вызовьте там ту же команду promote.

Пример шаблона:

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

Если ваша сборка Hermes предоставляет команды управления планировщиком, вы можете зарегистрировать то же задание через CLI вместо ручного редактирования файлов конфигурации:

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

Если в вашей установленной версии нет hermes scheduler jobs ..., продолжайте использовать описанный выше метод на основе конфигурации, а затем перезагрузите или перезапустите Hermes, чтобы планировщик подхватил новое задание.

Как использовать это безопасно:

• Держите kanban.dispatcher.enabled = false, если задание планировщика — ваш единственный промотор.
• Начните с низкого значения --max, например 1 или 2.
• Разместите журналы планировщика в вашем обычном конвейере журналов Hermes, чтобы пропущенные или неудачные продвижения были видны.

Это дает вам такое же поведение пакетной обработки, как и Linux cron, но управляемое как конфигурация Hermes, а не на уровне хоста crontab.

Стратегия 4: Сегментирование досок и профилей для разных шлюзов

Если вы используете несколько бэкендов LLM — например:

• узел с малым GPU и инструктивной моделью 7B
• узел только на CPU для легкой классификации
• отдельная высокопроизводительная машина для сложных рассуждений

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

Типичный шаблон:

• Создайте профили, такие как research-gpu, summarise-cpu, ops-gateway.
• Настройте каждый профиль с выделенным базовым URL и API-ключом для собственного шлюза.
• Создайте отдельные канбан-дорожки или даже отдельные доски для каждого профиля.

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

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

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

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

Для базовых метрик и панелей мониторинга в продакшене см. Мониторинг инференса LLM в продакшене с Prometheus и Grafana и более широкий раздел [Центр производительности LLM](https://www.glukhov.org/ru/llm-performance/ “Практическая инженерия производительности LLM: пропускная способность против задержки, лимиты VRAM, параллельные запросы, выделение памяти и бенчмарки для различных сред выполнения и оборудования.”}).

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

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

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

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

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

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

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

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