Dominando a automação do Hermes com Cron Jobs: De resumos diários a vigilantes personalizados


Se você usa o Hermes Agent e nunca mexeu no agendador cron dele, está deixando de lado um dos recursos mais poderosos. O Cron no Hermes não é um simples utilitário de “execute este script a cada hora” — é um framework de automação completo que abrange agendamento em linguagem natural, agentes apoiados por skills, pipelines multi-job e vigilantes de apenas script com custo zero de token.

Neste guia, você aprenderá a:

  • Agendar tarefas recorrentes e únicas com linguagem natural ou expressões cron
  • Anexar skills a um job para que ele herde fluxos de trabalho especializados
  • Encadear múltiplos jobs para que um alimente o próximo (o padrão pipeline)
  • Executar vigilantes de apenas script que consomem zero tokens de LLM
  • Configurar resumos diários prontos para produção, monitores do GitHub e verificações de saúde de sites

Vamos começar do básico.

O que torna o Cron do Hermes diferente?

A maioria das implementações de cron executa um único script em um temporizador. O cron do Hermes executa uma sessão completa de agente em um temporizador — seu prompt se torna a tarefa, o agente tem acesso a todas as suas ferramentas (terminal, arquivo, web, navegador, delegação), e o resultado é entregue na plataforma de chat de sua escolha.

A ideia central: Um job cron no Hermes é “uma sessão agendada do Hermes”. Tudo o que você pode pedir ao Hermes no chat, você pode agendar para que ele faça de forma autônoma.

Além disso, o cron do Hermes adiciona:

  • Injeção de skills — carregue um ou mais skills na sessão antes da execução do prompt
  • Encadeamento em pipeline — a saída de um job se torna o contexto do próximo job
  • Modo sem agente — execute um script simples em um agendamento, zero tokens de LLM, stdout entregue na íntegra
  • Entrega multiplataforma — envie resultados para Telegram, Discord, Slack, email, SMS, Feishu ou qualquer plataforma configurada
  • Gestão completa do ciclo de vida — pausar, retomar, editar, disparar sob demanda, tudo pelo chat ou CLI

O agendador roda dentro do daemon do gateway do Hermes, fazendo tick a cada 60 segundos. Os jobs são armazenados em ~/.hermes/cron/jobs.json e usam um bloqueio de arquivo (~/.hermes/cron/.tick.lock) para evitar ticks sobrepostos.

Agendamento básico: Três maneiras de criar um job

Você pode criar um job cron de três maneiras. Todos os caminhos levam ao mesmo agendador.

1. Pelo chat com /cron

A maneira mais rápida — digite o comando slash /cron durante uma sessão de chat:

/cron add "every 2h" "Check server status and report any issues"
/cron add "0 9 * * *" "Summarize yesterday's commits from the project repo"
/cron add "30m" "Remind me to stand up and stretch"

Com um skill anexado:

/cron add "every 1h" "Check feeds for new posts" --skill blogwatcher

2. Pela CLI independente

A versão CLI funciona de forma idêntica e é scriptável:

hermes cron create "every 2h" "Check server status"
hermes cron create "0 9 * * *" "Summarize yesterday's commits" --name "daily-summary"

Com múltiplos skills:

hermes cron create "every 1h" "Monitor feeds and maps" \
  --skill blogwatcher \
  --skill maps \
  --name "Multi-skill watcher"

3. Através de conversa natural

Apenas diga ao Hermes o que você quer:

“Every morning at 9am, check Hacker News for AI news and send me a summary on Telegram.”

O Hermes usa a ferramenta cronjob internamente para configurar — sem CLI, sem sintaxe para lembrar.

Referência de formato de agendamento

O Hermes aceita quatro formatos de agendamento:

Formato Exemplo Comportamento
Atraso relativo 30m, 2h, 1d Único, executa uma vez após o atraso
Intervalo every 30m, every 2h, every 1d Recorrente até ser removido
Expressão cron 0 9 * * * (diário), 0 9 * * 1-5 (dias úteis), 0 */6 * * * (a cada 6h) Recorrente em horário fixo
Timestamp ISO 2026-12-25T09:00:00 Único em um momento futuro específico

Você pode sobrescrever a contagem de repetições padrão:

cronjob(
    action="create",
    prompt="Check mailbox for urgent messages",
    schedule="every 2h",
    repeat=5,        # executar apenas 5 vezes, depois auto-remover
)

Jobs Cron apoiados por Skills

O verdadeiro poder começa quando você anexa skills. Um skill codifica um fluxo de trabalho reutilizável — quando um job cron o carrega, o agente herda essa expertise sem que você precise enfiar instruções no prompt.

Skill único

cronjob(
    action="create",
    skill="blogwatcher",
    prompt="Check the configured feeds and summarize anything new.",
    schedule="0 9 * * *",
    name="Morning feeds",
)

Múltiplos skills

Skills são carregados em ordem. O prompt se torna a instrução final sobre todos os skills carregados:

cronjob(
    action="create",
    skills=["blogwatcher", "maps"],
    prompt="Look for new local events and interesting nearby places, then combine them into one short brief.",
    schedule="every 6h",
    name="Local brief",
)

Dica prática: Use skills para separar responsabilidades. Um skill “coletor de dados” busca dados brutos; um skill “formatador” os embeleza; um skill “entrega” os roteia. Misture e combine em diferentes jobs.

Executando dentro de um diretório de projeto

Por padrão, jobs cron rodam em modo detached — nenhum CLAUDE.md ou AGENTS.md é carregado. Passe --workdir (CLI) ou workdir= (chamada de ferramenta) para fazer o job rodar dentro de um repositório específico:

hermes cron create "every 1d at 09:00" \
  "Audit open PRs, summarize CI health, and post to #eng" \
  --workdir /home/me/projects/acme

Quando workdir está definido, os arquivos de contexto do projeto desse diretório são injetados no prompt do sistema, e todas as ferramentas de arquivo/terminal usam esse diretório como base de trabalho.

Nota de serialização: Jobs com workdir rodam sequencialmente (não no pool paralelo) porque mudam o estado global do terminal do processo. Jobs sem workdir continuam rodando em paralelo.

Avançado: Pipelines multi-job com context_from

Jobs cron rodam em sessões isoladas sem memória de execuções anteriores. Mas às vezes a saída de um job é exatamente o que o próximo job precisa. O parâmetro context_from estabelece essa conexão automaticamente.

O padrão Pipeline

Aqui está um pipeline de notícias de IA de 3 estágios — coleta, triagem e entrega:

# Passo 1: Encontre o ID do job coletor
cronjob(action="list")

# Passo 2: Crie um job de triagem que recebe a saída do coletor
cronjob(
    action="create",
    prompt="Read ~/.hermes/data/briefs/raw.md. Score each story 1-10 for engagement and novelty. Output top 5 to ~/.hermes/data/briefs/ranked.md.",
    schedule="30 7 * * *",
    context_from="<collector_job_id>",
    name="AI News Triage",
)

# Passo 3: Crie um despachante que recebe a saída da triagem
cronjob(
    action="create",
    prompt="Read ~/.hermes/data/briefs/ranked.md. Write 3 tweet drafts (hook + body + hashtags).",
    schedule="0 8 * * *",
    context_from="<triage_job_id>",
    deliver="telegram:7976161601",
    name="AI News Brief",
)

Como context_from funciona:

  • Quando o Job B dispara, o Hermes lê a saída mais recente do Job A de ~/.hermes/cron/output/{job_a_id}/*.md
  • Essa saída é automaticamente prefixada ao prompt do Job B
  • A cadeia pode ter qualquer comprimento: A → B → C → …
  • Você pode passar um único ID (string) ou uma lista de IDs para padrões fan-in

Quando usar pipelines:

  • Processamento multi-estágio (coletar → filtrar → formatar → entregar)
  • Tarefas dependentes onde o passo N precisa dos resultados do passo N−1
  • Fan-out/fan-in: um job agregador coleta resultados de vários coletores

Modo sem agente: Vigilantes de apenas script

Para tarefas recorrentes que não precisam de um LLM — vigilantes clássicos de sistema, alertas de disco/memória, heartbeats, pings de CI — passe no_agent=True. O agendador executa seu script programado e entrega stdout diretamente, zero tokens, zero chamadas de inferência.

Configuração CLI

hermes cron create "every 5m" \
  --no-agent \
  --script memory-watchdog.sh \
  --deliver telegram \
  --name "memory-watchdog"

Configuração orientada pelo agente

Apenas diga ao Hermes no chat:

“Ping me on Telegram if RAM is over 85%, every 5 minutes.”

O Hermes escreve o script de verificação em ~/.hermes/scripts/ e configura o job cron automaticamente.

Semântica do modo sem agente

Condição Comportamento
Script stdout (não vazio) Entregue na íntegra como mensagem
stdout vazio Tick silencioso — nada é enviado (o padrão watchdog)
Saída diferente de zero ou timeout Alerta de erro entregue (para que watchdogs quebrados não falhem silenciosamente)
Última linha {"wakeAgent": false} Tick silencioso (mesmo gate que jobs LLM usam)

Arquivos de script:

  • .sh / .bash → executa sob /bin/bash
  • Qualquer outra coisa → executa sob o interpretador Python atual (sys.executable)
  • Devem residir em ~/.hermes/scripts/

Exemplo real — um script watchdog de memória:

#!/bin/bash
# ~/.hermes/scripts/memory-watchdog.sh
THRESHOLD=85
USAGE=$(free | awk '/^Mem:/ {printf "%.0f", $3/$2 * 100}')
if [ "$USAGE" -gt "$THRESHOLD" ]; then
    echo "⚠️  RAM alert: ${USAGE}% used (threshold: ${THRESHOLD}%)"
    echo "Top processes:"
    ps aux --sort=-%mem | head -6
fi
# Se abaixo do limite, o script não produz stdout → tick silencioso

Este script produz saída apenas quando a memória excede 85%. Em dias tranquilos, não envia nada — sem spam, sem atenção desperdiçada.

Gestão do ciclo de vida

Cada job cron tem um ciclo de vida completo. Você gerencia tudo pela CLI ou pelo chat.

Comandos CLI

hermes cron list              # Listar todos os jobs (--all para desabilitados)
hermes cron pause my-digest   # Pausar por nome ou ID
hermes cron resume my-digest  # Reativar
hermes cron run my-digest     # Disparar no próximo tick do agendador
hermes cron edit my-digest --schedule "every 4h"  # Alterar agendamento
hermes cron edit my-digest --prompt "Revised task"
hermes cron edit my-digest --add-skill maps       # Adicionar um skill
hermes cron edit my-digest --remove-skill maps    # Remover um skill
hermes cron edit my-digest --clear-skills          # Remover todos os skills
hermes cron remove my-digest  # Excluir completamente
hermes cron status            # Status do agendador
hermes cron runs my-digest --limit 20  # Histórico de execução

Pelo chat

/cron list
/cron pause <job_id>
/cron resume <job_id>
/cron run <job_id>
/cron edit <job_id> --schedule "every 4h"
/cron remove <job_id>

Busca por nome: Todos os comandos aceitam o ID hexadecimal do job ou o nome do job (sem distinção de maiúsculas/minúsculas). Se um nome corresponder a vários jobs, o comando imprime os candidatos para que você possa desambiguar.

Histórico de execução

O Hermes registra cada execução cron em ~/.hermes/cron/executions.db. Cada tentativa passa por claimedrunning → um de completed, failed ou unknown (após reinício do processo). Inspecione com hermes cron runs [job-id] --limit 20.

Recuperação de provedor e fixação de modelo

Jobs cron herdam seus provedores de fallback configurados e a rotação do pool de credenciais. Se a chave API principal tiver limite de taxa, o job automaticamente faz fallback para um provedor alternativo ou rotaciona para a próxima credencial no pool.

Importante — comportamento de fixação de modelo: Quando você cria um job cron sem especificar provedor/modelo, o Hermes tira um snapshot do seu padrão global atual no job. Se você depois alterar o padrão global, o job falha de forma segura — ele pula a execução e alerta você para fixar o provedor/modelo explicitamente. Isso evita que jobs não supervisionados mudem silenciosamente para um provedor pago ou um modelo diferente:

# Fixar um modelo específico a um job
cronjob(
    action="update",
    job_id="<job_id>",
    provider="openrouter",
    model="anthropic/claude-sonnet-4",
)

Para execuções não supervisionadas, hermes setup --portal (Nous Portal OAuth) é a opção de menor atrito — a atualização OAuth é automática.

Regra de segurança: Sessões executadas por cron não podem criar novos jobs cron. O Hermes desabilita as ferramentas de gestão de cron dentro das execuções cron para evitar loops de agendamento descontrolados.

Configuração de entrega

Direcionamento por plataforma

Ao agendar um job, especifique para onde o resultado vai através do parâmetro deliver:

# Entregar para o Telegram
cronjob(action="create", ..., deliver="telegram")

# Entregar para um canal específico do Discord
cronjob(action="create", ..., deliver="discord:#engineering")

# Entregar para múltiplas plataformas
cronjob(action="create", ..., deliver="telegram,discord")

# Distribuir para todos os canais principais conectados
cronjob(action="create", ..., deliver="all")

# Entregar para a origem mais todos os canais
cronjob(action="create", ..., deliver="origin,all")

Os destinos suportados incluem Telegram, Discord, Slack, WhatsApp, Signal, SMS, email, Feishu, DingTalk, WeCom, Matrix e outros.

O padrão silencioso

Se a resposta final do agente contiver [SILENT], a entrega é totalmente suprimida. A saída ainda é salva localmente para auditoria, mas nenhuma mensagem é enviada:

# Texto do prompt:
"Check if nginx is running. If everything is healthy, respond with only [SILENT]. Otherwise, report the issue."

Jobs com falha sempre são entregues independentemente do silenciador — apenas execuções bem-sucedidas podem ser silenciadas.

Encapsulamento de resposta

Por padrão, a saída cron entregue é encapsulada com um cabeçalho/rodapé:

Cronjob Response: Morning feeds
-------------

<saída do agente aqui>

Note: The agent cannot see this message, and therefore cannot respond to it.

Para entregar saída bruta sem o encapsulamento:

# ~/.hermes/config.yaml
cron:
  wrap_response: false

Jobs continuáveis (Responder a um Cron)

Por padrão, uma entrega cron é do tipo disparar-e-esquecer. Defina um job como continuável (via attach_to_session=True) e você poderá respondê-lo — o resumo se torna uma conversa:

# ~/.hermes/config.yaml
cron:
  mirror_delivery: true

Ou por job através da ferramenta:

cronjob(
    action="create",
    ...,
    attach_to_session=True,
)

Em plataformas com capacidade de threads (tópicos do Telegram, threads do Discord), cada entrega abre uma thread dedicada. Em plataformas apenas DM (WhatsApp, Signal), o resumo é espelhado na sessão DM.

Playbook de produção: Três configurações testadas em batalha

1. Resumo diário pessoal

Um resumo matinal que coleta atividade do GitHub, clima e itens do calendário:

hermes cron create "0 8 * * 1-5" \
  "1. Check my GitHub notifications for any PRs requesting my review
   2. Check the weather forecast for today
   3. Summarize anything from my calendar that needs attention
   4. Format everything into a clean morning brief" \
  --deliver telegram \
  --name "daily-briefing"

Por que isso funciona: Roda apenas em dias úteis (1-5), usa as ferramentas integradas de busca web e arquivos do Hermes, e entrega diretamente no Telegram onde você pode ler durante o café.

2. Watchdog de repositório do GitHub

Um script sem agente que avisa quando o último release de um repositório muda:

#!/bin/bash
# ~/.hermes/scripts/github-watchdog.sh
REPO="NousResearch/hermes-agent"
CACHE_FILE="$HOME/.hermes/cron/output/latest_release.txt"
LATEST=$(curl -s "https://api.github.com/repos/$REPO/releases/latest" | grep -o '"tag_name": *"[^"]*"' | head -1)

if [ ! -f "$CACHE_FILE" ]; then
    echo "$LATEST" > "$CACHE_FILE"
    echo "📦 Initialized watcher for $REPO — latest: $LATEST"
    exit 0
fi

PREVIOUS=$(cat "$CACHE_FILE")
if [ "$LATEST" != "$PREVIOUS" ]; then
    echo "$LATEST" > "$CACHE_FILE"
    echo "🚀 New release detected for $REPO!"
    echo "   Previous: $PREVIOUS"
    echo "   Latest:   $LATEST"
    echo "   View: https://github.com/$REPO/releases/tag/$LATEST"
fi

Configure:

hermes cron create "every 6h" \
  --no-agent \
  --script github-watchdog.sh \
  --deliver telegram \
  --name "github-release-watchdog"

Custo zero de token. O script roda a cada 6 horas, só envia uma mensagem quando um release realmente muda.

3. Verificador de saúde de site

Um pipeline multi-estágio: verificação web → análise de logs → entrega de alerta.

Estágio 1 — Coletor (script sem agente):

#!/bin/bash
# ~/.hermes/scripts/health-check.sh
URL="https://hermes-agent-lab.com"
STATUS=$(curl -s -o /dev/null -w "%{http_code}" --max-time 10 "$URL")
TIME=$(curl -s -o /dev/null -w "%{time_total}" --max-time 10 "$URL")
TIMESTAMP=$(date '+%Y-%m-%d %H:%M:%S')
echo "[$TIMESTAMP] $URL → HTTP $STATUS (${TIME}s)"
hermes cron create "every 30m" \
  --no-agent \
  --script health-check.sh \
  --name "site-health-collector"

Estágio 2 — Análise (impulsionado por LLM, encadeado do coletor):

hermes cron create "0 */2 * * *" \
  "Review the last 4 health checks for hermes-agent-lab.com.
   Are any failures or slow responses apparent?
   If everything is healthy, respond with only [SILENT].
   If there is an issue, write a summary of the problem and deliver it." \
  --context_from "<collector_job_id>" \
  --name "site-health-analyst"

O coletor roda a cada 30 minutos (grátis, sem tokens). O analista roda a cada 2 horas, recebe a saída do coletor como contexto e só dispara uma mensagem quando algo está errado.

Armadilhas comuns e como evitá-las

1. Esquecer que o Gateway deve estar rodando

A execução do cron é gerenciada pelo daemon do gateway. Se o gateway não estiver rodando, seus jobs não serão disparados:

hermes gateway install     # Instalar como serviço de usuário
hermes gateway status      # Verificar se está rodando
hermes gateway run         # Ou rodar em primeiro plano para testes

2. Confusão entre atraso relativo e intervalo

  • 30m = único em 30 minutos
  • every 30m = recorrente a cada 30 minutos

Este é um erro comum. Use every explicitamente quando quiser recorrência.

3. Jobs silenciosos que nunca falam

Se seu job roda mas você nunca vê saída, o agente provavelmente respondeu com [SILENT] (caso de sucesso) ou o script não produziu stdout (caso sem agente). Verifique a saída local:

ls ~/.hermes/cron/output/
cat ~/.hermes/cron/output/<job_id>/*.md

4. Modelo/Provedor de repente não funciona

Jobs não fixados tiram um snapshot do padrão atual na criação. Se você mudou de provedor (hermes model), o job alerta você para fixar explicitamente. Sempre fixe jobs de produção:

hermes cron edit my-job --provider openrouter --model anthropic/claude-sonnet-4

5. Tempos de pipeline sobrepostos

Ao encadear jobs com context_from, certifique-se de que o job upstream termine antes do downstream começar. Se o Job A roda em 0 7 * * * (7:00) e o Job B em 0 7 * * * (também 7:00), o Job B obtém a saída do Job A do dia anterior — ou um arquivo vazio se for a primeira execução. Desloque-os em pelo menos 15–30 minutos.

6. Jobs com Workdir bloqueando uns aos outros

Jobs com workdir definido rodam sequencialmente. Projete seus pipelines para que jobs com workdir não se tornem um gargalo — mantenha-os curtos ou use jobs intermediários sem workdir para processamento pesado.

Resumo

O cron do Hermes transforma você de um operador manual em alguém que configura e esquece. Aqui está a folha de referência:

Tarefa Abordagem Custo LLM
Resumo diário pessoal Job LLM único com busca web Baixo
Monitor de releases do GitHub Script sem agente Zero
Verificação de saúde web + alerta Pipeline: coletor sem agente → analista LLM Baixo (a cada 2 horas)
Pipeline de notícias de IA Cadeia multi-job com context_from Moderado
Watchdog de disco/memória Script sem agente Zero
Difusão multiplataforma Job único com deliver="all" Baixo

A combinação de sessões completas de agente, injeção de skills, modo script sem agente e pipelines multi-job torna o cron do Hermes uma das ferramentas de automação mais versáteis disponíveis em qualquer framework de agentes de IA.

Comandos de início rápido

# Onboarding em 1 minuto: agende seu primeiro job
hermes cron create "every 1d at 09:00" "Give me a 3-sentence summary of what happened on GitHub with NousResearch/hermes-agent since yesterday" --deliver telegram

# Listar e verificar
hermes cron list
hermes cron status

# Vê-lo rodar em tempo real
hermes cron run my-job-name

Para mais informações sobre automação do Hermes, consulte a documentação oficial do cron, nosso guia de instalação e a comparação de recursos.