Bot Mode: no Hermes, um Bot é um perfil

A funcionalidade mais recente do Hermes chama-se Bot Mode e é fácil de descrever mal. Na app Desktop aparece um separador Bots ao lado de Sessions: agentes com avatar, nome e descrição, um painel Routines encostado à conversa, salas com dois a seis Bots e mensagens diretas de Bot para Bot. Parece uma camada nova, com a sua própria ideia de “agente”.

Não é. Um Bot é um perfil.

Um Bot é um perfil (e o terminal vê o mesmo)

Não há primitivo novo, daemon nenhum, armazenamento extra: config, memória, skills, credenciais e histórico continuam em ~/.hermes/profiles/<nome>/. O Bot Mode é uma UI por cima disso, e tudo o que se faz na app tem equivalente na shell:

No Bot Mode	Na shell
Conversar com um Bot	hermes -p <bot> chat
Ficheiros, skills e memória do Bot	~/.hermes/profiles/<bot>/
Rotinas	hermes cron list (jobs com o nome [bot:<name>] …)
Criar e inspecionar perfis	hermes profile create, hermes profile list

Nesta máquina isso lê-se no disco: o bloco ui_meta: hermes-bots está em onze profile.yaml, do architect ao writer que escreve isto, e há sessões com o título Bot Chat nas bases de estado do default, do architect e do qa. Nada disto veio de um daemon: foi a app a marcar perfis que já existiam.

O hermes profile rename dá nome amigável ao Bot e a tag passa a resolver contra ele (@scribe, @dr-foo), com @hermes como alias permanente do Bot primário. O perfil é o mesmo; muda o que escreves no composer.

O Bot Chat canónico não se recomeça

Cada Bot nasce com uma conversa permanente, o Bot Chat, criada quando o Bot aparece e escondida da lista de sessões. A identidade dela é o par (perfil, sessão com o título exatamente Bot Chat).

O pormenor curioso está no /new: lá dentro não abre sessão nova, o composer reencaminha-o para /compact — contexto limpo, mesma conversa. As docs explicam a razão sem rodeios: um /new bifurcava a relação numa sessão de rascunho, e é isso que o Bot Mode promete evitar. Só um archive explícito reforma o Bot Chat; a limpeza por inatividade não lhe toca.

Rotinas são cron jobs com outro nome

O painel Routines prende tarefas recorrentes ao Bot que as executa, e por baixo são cron jobs normais com o nome [bot:<name>] <rotina>: aparecem em hermes cron list e o resultado de cada execução cai no histórico de chat desse Bot, onde já ias falar com ele. Nesta máquina não há nenhuma («No scheduled jobs»), mas não há aqui nada de mágico.

O mesmo vale para as salas: uma mensagem dispara até três rondas seriais de turnos, cada membro responde ou passa, @menção restringe a ronda e @user escala para ti com um badge de “needs you”. É orquestração em cima das mesmas sessões de perfil.

O que corre mal

O título tem de ser exatamente Bot Chat. Qualquer outro título, ou uma sessão sem título, não recebe a secção de protocolo nem a tool message_agent; é o que torna a conversa canónica identificável sem uma tabela nova.

Sem Desktop, o message_agent nunca aparece. O agent.bot_mode_protocol do config.yaml (ligado por omissão) é só um interruptor: antes de injetar o protocolo têm de valer duas condições — a sessão com o título exato e pelo menos um perfil do install com o bloco ui_meta: { hermes-bots: … }. Num install só de terminal (gateway e Telegram) ninguém escreve nenhum dos dois, e os Bots conversam pela plataforma de mensagens sem que a tool do lado do agente exista. Para o ligar à mão:

hermes -p <bot> chat -c "Bot Chat" --create-if-missing   # a conversa canónica, criada uma vez

# ~/.hermes/profiles/<qualquer-bot>/profile.yaml
ui_meta:
  hermes-bots: {}   # um bloco vazio chega

Não há comando de CLI que escreva o marcador, e como o gate varre todos os perfis, um perfil marcado marca o install inteiro.

Hermes backend for profile "x" exited (1) no desktop.log não é um crash. Cada Bot local corre no seu processo e o Desktop mantém três vivos por omissão (~60 MB cada), com reaping após dez minutos de inatividade. Frota grande pede o valor subido em Settings → Advanced → Warm Bot Backends; com todos os lugares ocupados, um Bot aberto espera trinta segundos e falha por timeout.

A entrega Bot-a-Bot é fire-and-forget. message_agent(target="researcher", message="…") valida o alvo contra o roster e entrega no Bot Chat canónico do destinatário, que pega na mensagem no turno seguinte. O status: queued confirma admissão durável, não resposta entregue, e interromper um Bot a meio da conversa é trabalho futuro. As falhas vêm com código tipado (provider_quota_limit, delivery_timeout, target_busy, …); auth, quota e configuração nunca são re-tentados, o que poupa quota a quem erra a chave.

Vale a pena?

Sim, e pela razão certa: o Bot Mode não inventou dados. Perfis, sessões e cron jobs continuam a ser teus, e desligar o plugin em Settings → Plugins → Bots remove o roster e o painel Routines a quente, sem reiniciar. O «Bot Mode never owns your data, it only renders it» das docs é literal. Uma frota que já corria no terminal só ganha cara, avatar e um sítio onde ler as rotinas.

Docs: Bot Mode · Perfis