Como clonar um perfil do Hermes Agent para testes sem duplicar bots, cron jobs e logins

Fala aí, beleza? Teu Hermes já tá rodando liso, com bot conectado e cron jobs disparando no horário, e agora bateu aquela vontade de testar uma skill nova, trocar o modelo ou mexer na personalidade

Só que fazer isso direto na produção é pedir pra ter dor de cabeça 😛

O caminho é um perfil de teste. Perfis isolam o estado de cada agente e são criados com hermes profile create <nome> (está na documentação de perfis do Hermes Agent). Aqui o foco é só a CÓPIA: o que vem junto, o que fica de fora e como evitar que o clone responda no mesmo bot. Se tu ainda tá chegando agora, vale entender antes como o Hermes Agent funciona

Qual opção de criação de perfil usar: em branco, --clone, --clone-from ou --clone-all

Pra testar skills, modelo ou personalidade, --clone resolve na maioria dos casos

Se a origem não é o perfil ativo, use --clone-from. Se tu quer partir do estado completo do perfil, entra o --clone-all

Opção	Origem	O que copia	Exemplo documentado
sem flag	nenhuma	nasce com as skills empacotadas (bundled skills) já inclusas; precisa rodar o setup pra configurar chaves de API, modelo e tokens do gateway	hermes profile create <nome>
--clone	perfil ativo	config.yaml, .env, SOUL.md, skills, MEMORY.md, USER.md e a pasta plugins/	hermes profile create work --clone
--clone-from <perfil>	o perfil que tu indicar	o mesmo do --clone (fica implícito)	hermes profile create work2 --clone-from work
--clone-from + --clone-all	o perfil que tu indicar	config, memórias, skills e plugins: exceto histórico, cron jobs, canais de mensagem e logins OAuth	hermes profile create work2-backup --clone-from work --clone-all
--clone-all	perfil ATIVO, sem --clone-from	config, memórias, skills e plugins: exceto histórico, cron jobs, canais de mensagem e logins OAuth	hermes profile create backup --clone-all

Repara que mesmo o --clone-all não é ‘cópia de tudo, sem exceção’: histórico, cron jobs, canais de mensagem e logins OAuth ficam de fora em qualquer flag de clone. Os detalhes de cada exclusão estão nas seções abaixo

Se liga num detalhe da referência de comandos de perfil: --clone-from já implica --clone, a menos que tu combine com --clone-all

Ou seja, não precisa escrever as duas flags juntas

O que nunca é copiado no clone do Hermes Agent e por quê

Histórico de sessões, state.db, backups/, state-snapshots/ e checkpoints/ ficam no perfil de origem, nem o --clone-all leva isso

O motivo é simples: esse material pertence à origem e pode chegar a dezenas de GB 😀

Por que os cron jobs não vão junto?

Cron jobs continuam vinculados ao perfil de origem

Se o clone herdasse as tarefas, cada uma seria disparada duas vezes. Imagina aquele relatório diário chegando em dobro, ou pior, uma tarefa que mexe em algo externo rodando duplicada…

Por que os canais de mensagem não são copiados?

Nenhum clone carrega canais de mensagem por padrão: nem --clone, nem --clone-from, nem --clone-all, nem a opção ‘clone from profile’ do dashboard, Desktop ou TUI

Ficam de fora:

• tokens de bot e allowlists, como TELEGRAM_BOT_TOKEN, DISCORD_ALLOWED_USERS, WHATSAPP_ENABLED, API_SERVER_KEY e WEBHOOK_SECRET
• as seções platforms:, telegram: e discord: do config.yaml
• gateway.multiplex_profiles e profile_routes

E o porquê? Um bot só pode pertencer a um perfil. Se dois perfis compartilharem o mesmo token, dois gateways standalone disputam o long-poll da plataforma; num gateway multiplexado, o adaptador duplicado fica estacionado (parked); e o comando hermes gateway migrate --multiplex recusa a operação com um bloqueio de credencial duplicada por plataforma

Agora, se o que tu quer é backup completo, com histórico e cron jobs, clonagem não é a ferramenta certa. Pra isso a documentação aponta hermes profile export ou hermes backup

Antes de clonar: o que você precisa ter

• Hermes Agent já instalado, com um perfil de origem em uso
• Saber qual perfil está ativo (é dele que o --clone parte) ou o nome exato da origem, se for usar --clone-from
• Se o clone for conversar com usuários, um token de bot DIFERENTE do que a origem usa

Só isso, beleza? 🙂

Passo a passo para clonar um perfil do Hermes Agent para testes

1. Crie o clone com a flag escolhida

A partir do perfil ativo:

hermes profile create work --clone

Ou escolhendo a origem:

hermes profile create work2 --clone-from work

Erro comum deste passo: esperar que o histórico de conversas ou os cron jobs venham junto. Não vêm, e isso é por design

2. Ajuste o que vai ser testado

Edite o .env do novo perfil se o teste envolve outras chaves de API, ou o SOUL.md se a ideia é testar outra personalidade. Skills e config também vieram na cópia, então dá pra mexer nelas sem tocar na produção

Erro comum deste passo: esquecer que o .env foi copiado. Se tu não mexer nele, o clone continua usando as MESMAS chaves de API da origem

3. Confira credenciais duplicadas

hermes profile list

Esse comando imprime um aviso pra qualquer perfil cuja credencial de bot seja idêntica byte a byte à do perfil default. Serve também pra achar clones antigos antes que eles causem problema

Erro comum deste passo: ignorar o aviso e subir o gateway do clone assim mesmo. Com o mesmo token, o resultado é a disputa pelo long-poll entre gateways standalone ou o adaptador do clone ficando estacionado (parked) num gateway multiplexado: nenhum dos dois cenários resolve o teste

4. Dê ao clone um bot próprio

hermes -p work setup

Troque work pelo nome do teu clone. Se preferir interface, a página Messaging do dashboard faz o mesmo papel

Erro comum deste passo: reaproveitar o token da produção ‘só pra testar rapidinho’. Tome cuidado! É exatamente o cenário de conflito descrito acima

Validação final: rode hermes profile list de novo. O comando compara a credencial do clone com a do perfil default: se não aparecer aviso, a duplicata com o default está resolvida. Mas se a origem do clone não foi o perfil default, a ausência de aviso não garante que não haja outro perfil usando o mesmo token; vale confirmar manualmente qual bot cada perfil está configurado para usar

Quando usar --clone-channels e quando ele é recusado

--clone-channels inclui os canais de mensagem de forma explícita (opt-in), e quase nunca é o que um perfil de teste precisa

Ele é recusado no CLI, no dashboard e na TUI quando um gateway multiplexado em execução já atende o perfil de origem, porque a cópia seria estacionada na hora

Nos demais casos o comando roda, mas imprime um aviso nomeando as plataformas que agora estão compartilhadas com a origem

Pra teste, o caminho mais simples segue sendo clonar sem canais e dar ao clone um bot próprio: a documentação garante que canais nunca são clonados por padrão e orienta configurar os bots do novo perfil com hermes -p <nome> setup ou pela página Messaging do dashboard. Se o teu setup usa vários perfis atrás de um mesmo gateway, o funcionamento disso está no guia de vários perfis em um gateway

Plugins e provedor de memória externo no clone

Com --clone ou --clone-from, a pasta plugins/ vai junto: plugins do catálogo, do Git e os instalados à mão, com seus registros de instalação

Um provedor de memória instalado pelo catálogo continua funcionando no clone, na mesma revisão

E as dependências Python dos plugins?

Elas vivem no ambiente compartilhado e não são reinstaladas no clone

Na prática: se tu mudar uma dependência pra testar algo, isso afeta origem E clone. O isolamento do perfil não chega até aí

E se eu uso memória externa?

Se o config.yaml define um provedor de memória externo em memory.provider, a config desse provedor também é copiada: o diretório <provider>/ ou o arquivo <provider>.json dentro da home do perfil

Ou seja, o clone nasce apontando pra mesma configuração do provedor que a produção usa. Mas a cópia da config não é isolamento total: numa config hindsight do tipo local_embedded, o clone continua compartilhando o mesmo daemon e o mesmo bank da origem até ganhar seu próprio profile/bank_id. Já com Honcho, o clone ganha um AI peer dedicado dentro do mesmo workspace de usuário. Revise esse arquivo antes de testar e decida se faz sentido o clone usar a mesma configuração, ou se precisa separar o bank/peer pra não misturar dados com a produção

Produção e teste lado a lado em uma VPS Hostinger

Pra manter o perfil de produção (com os cron jobs rodando) e o perfil de teste convivendo numa máquina sempre ligada, a recomendação aqui é uma VPS Hostinger com o template do Hermes como ponto de partida (link de afiliado da Hostinger)

O porquê:

• tem um template Docker de 1 clique do Hermes Agent no catálogo de aplicações da VPS, descrito com painel admin no navegador, mensagens multiplataforma e suporte a mais de 200 modelos de LLM
• numa VPS que tu já tem, dá pra implantar de dois jeitos pelo hPanel: via VPS → OS & Panel → Operating System → Change OS, buscando e selecionando Hermes Agent (depois abrindo o terminal web em Docker Manager → Projects), ou via Docker Manager → Catalog → Hermes Agent → Select → Deploy, que já cria e inicia o contêiner com os serviços necessários, como o Traefik
• pra atualizar, é ir no Docker Manager do painel, localizar o projeto Hermes Agent e selecionar Update
• hospedando na própria VPS, chaves de API, histórico de conversa e contexto ficam na tua infraestrutura

Se liga na conta, porque são dois custos separados: o servidor é um, o provedor ou modelo de IA é outro. A Hostinger oferece créditos do Hostinger AI Router como adicional opcional na compra da VPS; sem esses créditos, é preciso configurar credenciais de um provedor próprio. De qualquer forma, trate a cobrança do modelo como algo separado da assinatura do servidor

E não confunda produtos: o template Docker em VPS é uma coisa, o Managed Hermes Agent Hosting é outro produto, separado. Neste cenário, com perfis e clones que tu administra, a escolha é a VPS com o template Hermes

Vídeo complementar do canal

Se tu quer ver como dar mais recursos pro Hermes Agent com um repositório open source, tem esse vídeo do canal Hora de Codar 😀

Próximo passo depois de clonar

Transforme o hermes profile list em hábito. Rodar de tempos em tempos pega credenciais duplicadas de clones antigos antes que algum gateway brigue com a produção

Quando o teste aprovar uma mudança, aplique ela conscientemente no perfil de produção, editando lá a config, o SOUL.md ou as skills. Nada de sair copiando o clone inteiro por cima, beleza?

E se o objetivo mudar pra guardar tudo, com histórico e cron jobs, o caminho é hermes profile export ou hermes backup, conforme a documentação de perfis

É isso, até o próximo post! =)

Quer aprender mais sobre inteligência artificial e programação na prática? Conheça o canal Hora de Codar no YouTube e acompanhe os próximos vídeos.