learn ← Hermes Agent: profiles, multiuso e dois gateways
Hermes Agent · Profiles · Gateway

Hermes Agent: profiles, multiuso e dois gateways

Um guia prático para separar um Hermes para você e outro para seu filho, compartilhando apenas modelo e provider, sem misturar memória, skills e sessões.

Quando duas pessoas usam o mesmo Hermes, o ponto central não é “como abrir duas conversas”, mas como isolar estado. No Hermes, quem define esse isolamento é o profile. E quando a conversa sai do terminal e entra em Telegram ou outras plataformas, a pergunta seguinte passa a ser: um gateway só basta ou faz sentido ter dois gateways independentes?

TL;DR Para o seu caso, a opção mais limpa é criar um segundo profile para seu filho e compartilhar apenas o bloco de modelo/provider. Se cada um tiver seu próprio bot/canal, rode dois gateways, um por profile. Se ambos usarem o mesmo bot, dá para operar com um gateway só, mas a separação fica menos elegante e o risco de confusão operacional aumenta.

Estado atual desta instalação

Antes de decidir uma arquitetura, vale olhar o estado real da instância que está rodando agora.

Profile atual

$ hermes profile show default
Profile: default
Path:    /home/hermes/.hermes
Model:   gpt-5.4 (openai-codex)
Gateway: running
Skills:  100
.env:    exists
SOUL.md: exists

Gateways ativos

$ hermes gateway list
Gateways:
  ✓ default (current)        — PID 2372440

Hoje, portanto, existe um único profile operacional: default. E existe um único gateway em execução, ligado a esse profile.

O que um profile isola de verdade

A documentação oficial do Hermes é explícita: um profile é outro Hermes home. Isso significa que cada profile ganha seu próprio diretório com seus próprios arquivos de estado.

  • config.yaml
  • .env
  • SOUL.md
  • memórias
  • sessões
  • skills
  • cron jobs
  • logs
  • estado do gateway

Em termos simples: profile não é só um “nome” ou um “atalho”. É outra identidade operacional do Hermes.

O ponto-chave Se você quer que seu filho tenha histórico, memória, skills e personalidade próprios, profile é o recurso certo. Usar o mesmo profile para duas pessoas só resolve a superfície do problema, não o estado interno.

Profile não é sandbox

Vale marcar uma distinção importante que a documentação também faz: profile não é isolamento de filesystem. Ele isola estado do Hermes, não permissões do usuário Linux.

Então, se ambos os perfis rodam com o mesmo usuário do sistema e com backend local, os dois perfis ainda têm o mesmo alcance de arquivos que esse usuário já possui. O que muda é o contexto do Hermes, não o privilégio do processo.

Atenção Se o objetivo também inclui restringir acesso a diretórios do sistema, profile sozinho não resolve. Para isso, você precisa combinar profile com disciplina de terminal.cwd, containerização, outro usuário Linux ou outro backend.

O que significa “compartilhar apenas model/provider”

No seu caso, a intenção é boa: aproveitar o mesmo modelo e o mesmo provider, mas sem compartilhar o resto. Na prática, isso quer dizer:

  • compartilhar: configuração de modelo, provider e, possivelmente, credenciais do provider;
  • não compartilhar: memória, skills criadas, sessões, cron jobs, gateway state, bot tokens e possivelmente SOUL.md.

Esse desenho é totalmente compatível com profiles. A questão é escolher a forma de criação do profile novo.

Opção 1: profile novo em branco e copiar só o necessário

Essa é a opção mais limpa e a que mais combina com o seu objetivo declarado.

Fluxo conceitual

hermes profile create filho
filho config set model.default gpt-5.4
filho config set model.provider openai-codex
# depois configurar apenas o que quiser compartilhar

Vantagens:

  • não herda memórias nem sessões;
  • não herda skills pessoais suas por acidente;
  • não herda cron jobs;
  • não copia tokens de gateway automaticamente;
  • fica claro o que foi compartilhado e o que não foi.

Desvantagem: exige um pouco mais de configuração manual. Mas, no seu caso, isso é quase uma vantagem, porque reduz o risco de vazamento de contexto entre vocês dois.

Opção 2: --clone e depois podar o que não deve ser compartilhado

A documentação oficial diz que hermes profile create work --clone copia config.yaml, .env e SOUL.md, mas deixa memória e sessões novas. Isso é útil quando você quer começar “parecido” com o profile atual.

Fluxo conceitual

hermes profile create filho --clone
# depois editar ~/.hermes/profiles/filho/.env
# e ajustar ~/.hermes/profiles/filho/SOUL.md se necessário

Vantagens:

  • mais rápido para começar;
  • já leva model/provider;
  • já leva boa parte da configuração que funciona.

Riscos:

  • copia o .env inteiro, então pode levar tokens de Telegram, Discord e outros canais;
  • copia o SOUL.md, então a personalidade inicial pode ficar muito parecida com a sua;
  • pode acabar copiando mais integração do que você gostaria.
Quando usar --clone faz sentido quando você quer um perfil “quase igual” ao atual e tem disciplina para limpar o que não deve permanecer. Para pai e filho, isso pode funcionar, mas exige revisão cuidadosa do .env e do SOUL.md.

Opção 3: --clone-all

Essa opção não combina com o seu objetivo. A própria documentação descreve --clone-all como cópia completa: config, API keys, memórias, histórico de sessões, skills, cron jobs, plugins e mais.

Para criar um Hermes do seu filho, isso é quase o oposto do que você quer. Só seria útil se a meta fosse um snapshot completo para backup ou fork operacional temporário.

Um gateway só ou dois gateways?

Aqui está a decisão arquitetural mais importante para o caso de multiuso familiar.

A documentação oficial de profiles é direta: cada profile roda seu próprio gateway como processo separado, com seu próprio bot token. Além disso, o Hermes possui um mecanismo de token lock: se dois perfis tentarem usar o mesmo token de bot ao mesmo tempo, o segundo é bloqueado com erro claro.

Em outras palavras: dois profiles com dois gateways simultâneos pedem dois tokens/bots distintos quando você está falando da mesma plataforma, como Telegram.

Opção A: um bot / um gateway / um profile compartilhado

Essa é a solução mais simples de operar, mas a mais fraca em isolamento.

  • um único bot no Telegram;
  • um único gateway rodando;
  • um único profile;
  • duas pessoas podem falar com o mesmo bot em chats diferentes.

Isso pode funcionar tecnicamente, mas não é o ideal para o seu objetivo, porque profile, skills, cron, personalidade e várias decisões globais continuam compartilhados.

O isolamento de sessões por chat ajuda, mas não substitui o isolamento de profile.

Opção B: dois profiles e um gateway para cada um

Essa é a arquitetura que melhor respeita o requisito de “compartilhar apenas model/provider”.

  • default continua sendo o seu profile;
  • filho vira um novo profile;
  • cada um tem suas próprias sessões, memórias, skills e gateway state;
  • cada um usa seu próprio bot/token, se ambos forem operar por Telegram;
  • o modelo/provider pode ser igual nos dois.

Comandos conceituais

hermes profile create filho
filho setup
filho gateway install
filho gateway start

No seu cenário, essa é a recomendação principal.

Opção C: dois profiles, mas só um deles com gateway

Existe um meio-termo interessante: você continua usando o default com gateway e cria um profile filho que, por enquanto, é usado só via CLI ou TUI.

  • seu profile: CLI + Telegram;
  • profile do filho: CLI apenas, ou TUI local;
  • modelo/provider iguais;
  • sem necessidade imediata de novo token de bot.

Essa opção é útil se você quer validar primeiro a separação de contexto antes de também investir em outro bot/gateway.

Opção D: um bot só, mas usando um profile distinto apenas para o filho em outro momento

Outra alternativa prática é operar em fases:

  1. criar o profile do filho já isolado;
  2. testá-lo via CLI;
  3. depois, se fizer sentido, criar um segundo bot e ativar um segundo gateway.

Isso reduz a chance de mudar muita coisa ao mesmo tempo.

Minha recomendação para o seu caso

Como você disse que quer compartilhar apenas modelo e provider, eu recomendo este desenho:

Recomendação Crie um profile novo em branco para seu filho, copie apenas a configuração de modelo/provider e, se necessário, as credenciais mínimas do provider. Mantenha memória, sessões, skills, cron e gateway separados. Se ele for usar Telegram também, crie um segundo bot/token e rode um segundo gateway para esse profile.

Em termos de equilíbrio entre simplicidade e isolamento, isso costuma ser o melhor ponto.

Matriz rápida de opções

Opção Isolamento Complexidade Serve ao objetivo?
Mesmo profile, mesmo gateway baixo baixa fraco
Dois profiles, filho via CLI alto média bom para começar
Dois profiles, dois gateways, dois bots muito alto média melhor opção
--clone-all muito baixo para este caso baixa não recomendado

Comandos úteis para esse desenho

Descoberta

hermes profile list
hermes profile show default
hermes gateway list

Criar e usar o profile novo

hermes profile create filho
hermes -p filho chat
hermes -p filho doctor
hermes -p filho config
hermes -p filho gateway status

Se optar por clone parcial

hermes profile create filho --clone
hermes profile show filho
# depois revisar ~/.hermes/profiles/filho/.env
# e ~/.hermes/profiles/filho/SOUL.md

Gateway independente

hermes -p filho gateway install
hermes -p filho gateway start
hermes gateway list

Fechamento

O Hermes já nasce com uma ideia boa para multiuso: separar estado por profile. Para o seu caso, isso encaixa muito bem. Você preserva a sua identidade operacional no default, cria uma identidade limpa para o seu filho e decide, com calma, se ele também precisa de um gateway próprio agora ou só depois.

Se a pergunta for “qual a melhor solução técnica para pai e filho usando o mesmo servidor?”, a resposta curta é: dois profiles, mesmo modelo/provider, estados separados; e, se ambos usarem Telegram, dois gateways com dois bots distintos.