Kanban no Hermes Agent para Fluxos de Trabalho de LLMs Auto-Hospedados

O Hermes Agent vem com um quadro estilo Kanban e o Hermes Gateway, que podem saturar seu LLM auto-hospedado se muitas tarefas forem despachadas de uma só vez.

Posso afirmar que, dessa forma, é fácil realizar um ataque de negação de serviço (DDoS) no seu próprio LLM.

O Hermes Kanban é um quadro multi-perfil durável, suportado por ~/.hermes/kanban.db.
Cada pista representa uma fase do trabalho, e cada cartão é uma tarefa que pode ser assumida por um perfil específico do Hermes.
Por padrão, o despachante pode promover muitas tarefas ready (prontas) em uma única passagem. Isso é aceitável para APIs de nuvem elásticas, mas pode sobrecarregar um pequeno cluster de GPUs auto-hospedado.

Se você é novo nesta stack, comece pelo Guia de configuração e operações do Hermes e pelo Pilar de Sistemas de IA para entender a arquitetura geral.

Este post mostra como:

• Compreender como o despachamento do Hermes Kanban interage com seu gateway de LLM.
• Controlar o paralelismo de forma segura para tarefas pesadas.
• Agrupar promoções com cron para que jobs em background não colidam com o uso interativo.
• Monitorar e ajustar o sistema para que as GPUs permaneçam ocupadas sem sobrecarga.

Como o Hermes Kanban e o despachante funcionam

Em um alto nível, o sistema possui três camadas:

1. Quadro (Board) - estado SQLite durável para tarefas, colunas, relações e histórico.
2. Trabalhadores (Workers) - perfis Hermes iniciados em workspaces isolados para processar uma tarefa.
3. Despachante (Dispatcher) - um processo de longa duração que varre em busca de cartões despacháveis e inicia execuções.

As tarefas criadas via CLI ou dashboard geralmente começam em backlog ou ready.
O despachante varre em busca de cartões elegíveis, assume um atomicamente e inicia o perfil atribuído com suas ferramentas e memória.
Cada worker então chama seu gateway de LLM ou runtime local (por exemplo, endpoints compatíveis com OpenAI suportados por Ollama, vLLM ou llama.cpp). Para escolhas de implantação entre esses runtimes, use o guia Hospedagem de LLM em 2026: Auto-hospedado Local vs Nuvem Comparado. Se você está ajustando o fan-out de solicitações no próprio Ollama, isso se encaixa bem com Como o Ollama Lida com Solicitações Paralelas.

Se você adicionar muitas tarefas pesadas e não limitar as promoções, seu gateway pode ser inundado com solicitações concorrentes.
Em um host com GPU única ou limitado por CPU, isso geralmente significa fila, thrashing e timeouts em vez de melhor throughput.

A limitação prática atual

Nas builds atuais do Hermes que muitas equipes usam, a configuração do despachante expõe apenas duas chaves de despacho do Kanban e não aplica um limite global de tarefas ativas via configuração:

kanban:
  dispatch_in_gateway: false
  dispatch_interval_seconds: 10

Para controle de tarefas ativas, confie em cadência de despacho explícita (hermes kanban dispatch --max ...) mais modelagem de dependências.

Armadilhas conhecidas:

• Não execute o despacho embutido no gateway e hermes kanban daemon --force contra o mesmo quadro, ou você pode ter corridas de assumição (claim races).
• Se o gateway estiver fora, as tarefas ready não são despachadas e podem estourar mais tarde quando o serviço retornar.
• Intervalos de despacho mais longos parecem irregulares porque a assumição acontece em ticks.
• O comportamento pode variar entre versões porque casos de borda de estado de execução e re-assumição foram corrigidos ao longo do tempo.

Verificação rápida quando o comportamento parece incorreto:

# 1) confirme que exatamente um caminho de despachante está ativo
pgrep -af "hermes gateway start|hermes kanban daemon"

# 2) verifique as chaves do despachante Kanban configuradas
rg "dispatch_in_gateway|dispatch_interval_seconds" ~/.hermes/config.yaml

# 3) inspecione a forma da fila
hermes kanban list --status ready
hermes kanban list --status running

Principais conceitos:

• A configuração do despachante conecta dispatch_in_gateway e dispatch_interval_seconds.
• dispatch --max limita novos spawns naquela passagem, não o total de tarefas em execução.
• Para pequenos clusters auto-hospedados, comece de forma conservadora e aumente apenas após a latência se estabilizar.

Ao implantar o Hermes próximo ao seu gateway de LLM pela primeira vez:

• Mantenha apenas as chaves do despachante Kanban suportadas na configuração.
• Observe a utilização de GPU e CPU sob pressão real de fila.
• Use a Estratégia 1 ou Estratégia 2 para ritmo determinístico.

Achados da investigação e causa raiz

hermes kanban dispatch não lê config.yaml para max_active_tasks.

Em hermes_cli/kanban.py, o comando dispatch expõe --max como um limite CLI (padrão None) e passa apenas args.max para kb.dispatch_once(...). Não há lookup de configuração max_active_tasks neste caminho. Veja hermes_cli/kanban.py raw.

Em seguida, em kanban_db.dispatch_once, o único limite é max_spawn, com lógica equivalente a:

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

Não há verificação de tarefas já em execução e nenhuma referência a max_active_tasks naquele caminho de despacho. Veja hermes_cli/kanban_db.py raw.

Comportamento efetivo:

hermes kanban dispatch

ilimitado para aquela passagem (limitado pelo tamanho da fila ready).

hermes kanban dispatch --max 2

limita apenas novos spawns naquela passagem, não o total de tarefas em execução.

Os knobs de configuração conectados ao redor do despacho do gateway são kanban.dispatch_in_gateway e kanban.dispatch_interval_seconds.
Portanto, max_active_tasks é ignorado neste caminho de despacho porque não está implementado ali.

Estratégia 1 - Codificar dependências para fluxos estritamente sequenciais

Alguns fluxos de trabalho devem rodar estritamente um após o outro — por exemplo:

• pipelines de dados multi-etapa com artefatos intermediários compartilhados
• migrações ou mudanças de infraestrutura
• jobs em batch que escrevem no mesmo object store ou banco de dados

O Hermes Kanban suporta dependências pai-filho entre tarefas, para que um cartão filho se torne despachável apenas quando seu pai estiver concluído.

Você pode modelar isso com um pequeno script auxiliar ao redor do CLI do Hermes:

#!/usr/bin/env bash

set -euo pipefail

parent_id="$(hermes kanban add \
  --title 'Inger logs de clientes para Abril' \
  --profile 'etl-worker' \
  --column backlog)"

hermes kanban add \
  --title 'Gerar relatório de anomalias de Abril' \
  --profile 'analytics-worker' \
  --column backlog \
  --parent "${parent_id}"

hermes kanban add \
  --title 'Publicar resumo de Abril no dashboard' \
  --profile 'reporting-worker' \
  --column backlog \
  --parent "${parent_id}"

Com uma política de quadro apropriada e limites baixos do despachante, apenas a tarefa pai roda primeiro.
Uma vez que ela termina, as tarefas filho gradualmente se tornam prontas, e o despachante as puxa uma por uma sem nunca exceder seus limites de concorrência.

Estratégia 2 - Usar cron do Linux com um limite de despacho ciente do que está em execução

Se você quer ritmo determinístico, use o cron do host mais um pequeno script wrapper.
Em vez de sempre chamar dispatch --max 2, primeiro conte as tarefas atualmente em execução, depois despache apenas os slots restantes.

Crie 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

# ou onde seu hermes está instalado
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 "Já no limite running=$running_count max=$MAX_PARALLEL despacho ignorado"
  exit 0
fi

echo "running=$running_count max=$MAX_PARALLEL slots=$slots despachando até $slots"

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

Torne-o executável:

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

Execute-o com:

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

Para um quadro específico:

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

Agende-o uma vez por minuto com cron:

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

Notas operacionais:

• O cron frequentemente tem um PATH mínimo, então se hermes não for encontrado, use seu caminho completo dentro do script (por exemplo /usr/local/bin/hermes).
• Se você logar para /var/log/hermes/..., crie esse diretório primeiro e certifique-se de que o usuário do cron tenha acesso de escrita.

Exemplo:

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

Crie ou edite entradas de cron com:

crontab -e

Depois verifique com:

crontab -l

Cadência sub-minuto com uma entrada de cron

O cron ticka uma vez por minuto, mas você ainda pode despachar mais frequentemente executando um loop curto dentro do script.

Exemplo 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 execuções => a cada 15 segundos
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

Torne-o executável:

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

Agende-o uma vez por minuto:

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

Isso dá uma cadência efetiva sub-minuto enquanto flock previne execuções sobrepostas.

Por que isso funciona:

• list --status running dá a carga de execução atual.
• dispatch --max N limita apenas novos spawns para aquela passagem.
• Calcular N como slots restantes mantém o total de tarefas em execução próximo ao seu limite alvo.

Observação importante: esse limite funciona apenas para despachos feitos através deste script.
Desative o despacho embutido no gateway, caso contrário, ele ainda pode promover tarefas independentemente:

kanban:
  dispatch_in_gateway: false

Os docs oficiais descrevem ambas as capacidades de comando e notam os padrões de despacho do gateway no guia de recursos do Kanban: Docs do Hermes Kanban.

Hermes Cron Interno

Não o use. Você realmente quer que seu LLM processe prompts regulares como Execute no terminal o comando /path/hermes-kanban-dispatch-capped.sh, especialmente quando ele está ocupado fazendo algum trabalho útil?

Monitoramento e Ajuste do Hermes Kanban

Qualquer estratégia você escolher, você deve monitorar:

• Métricas do gateway de LLM — taxa de requisições, latência, taxa de erro, throughput de tokens.
• Saúde do nó — utilização de GPU, uso de VRAM, carga de CPU e RAM.
• Métricas do Hermes — quantas tarefas estão em backlog, ready, active e done.

Para baselines de métricas de produção e dashboards, veja Monitorar Inferência de LLM em Produção com Prometheus e Grafana e o mais amplo Hub de Desempenho de LLM.

Comece com baixa concorrência, depois gradualmente aumente os limites enquanto observa por:

• latência crescente em throughput constante
• aumento de erros de timeout ou limite de taxa
• caudas longas onde algumas tarefas permanecem ativas por muito tempo

Assim que você ver esses sintomas, reverta para a configuração estável anterior e mantenha-a como seu padrão.

Quando o Kanban é a ferramenta certa

O Hermes Kanban brilha quando você tem:

• backlogs de pesquisa ou engenharia de longa duração
• colaboração multi-agente com perfis nomeados
• fluxos de trabalho que devem sobreviver a reinícios e reboots do host
• humanos que querem um dashboard para triar trabalho

Se você precisa apenas de uma execução única para criar alguns helpers temporários, as ferramentas de tarefa delegate embutidas são geralmente mais simples.
Uma vez que você precisa de histórico, dashboards e controle estrito sobre como seus agentes atingem LLMs auto-hospedados, o quadro Kanban mais o despachante é a fundação correta.

Com alguns ajustes de configuração e agrupamento opcional baseado em cron, você pode manter o Hermes Kanban responsivo enquanto protege seu gateway e hardware.