Como testar o Hermes Agent em ambiente controlado antes de dar acesso ao que importa?

Fala aí, beleza? Dar acesso a um agente que roda comando de shell, aparece em mais de 20 plataformas de conversa e ainda escreve as próprias skills não é a mesma coisa que instalar mais um pacotinho no terminal

É como contratar alguém muito rápido, entregar a chave da casa e sair pro trabalho: pode dar muito certo, pode dar muito errado

O Hermes Agent é um agente open source da Nous Research publicado sob licença MIT, lançado em 25/02/2026, com a v0.20.1 (tag v2026.8.13) publicada em 13/08/2026 e cerca de 222,6 mil estrelas no GitHub segundo o rastreador Star History

Projeto grande, comunidade grande, e por isso mesmo vale a pena não sair testando na máquina onde tu trabalha

A proposta deste post é simples: montar um ambiente descartável, com permissões mínimas e dado que não dói perder, rodar o agente ali dentro e só depois decidir se ele merece acesso ao que importa 🙂

O que você precisa antes de começar o teste

A instalação só por linha de comando (sem o Hermes Desktop) usa o script oficial hospedado no domínio da documentação, em https://hermes-agent.nousresearch.com/install.sh, baixado com curl -fsSL

A forma exata de execução do script está na página de instalação da doc oficial

Depois de instalar, o fluxo básico é curtinho:

hermes setup    # configura o provedor de LLM
hermes          # inicia o agente
hermes doctor   # verifica a instalação

Que diretório de estado é esse? É onde o Hermes guarda tudo: configuração, memórias, sessões, skills, logs

Ele é resolvido pela variável de ambiente HERMES_HOME, com fallback para ~/.hermes quando ela não está definida

Se liga nisso, porque é o pulo do gato do teste controlado: o isolamento no Hermes acontece por HERMES_HOME, e não trocando o HOME do usuário

Do lado da máquina, você vai querer o Docker instalado, já que o backend de container é o que separa de verdade os comandos do agente do seu host

E "dados descartáveis" aqui é literal: repositório de brinquedo, chave de API criada só pra isso, nada de apontar o cwd pro projeto que paga suas contas

Formação Recomendada

Formação Vibe Coding

Do Prompt ao Produto: Crie Software Real com IA

• 474 aulas
• 20 projetos
• 39h 27min

Conhecer formação

Passo a passo para testar o Hermes Agent em ambiente controlado

1. Crie um perfil isolado só pro teste

Perfis criam instâncias completamente isoladas umas das outras, cada uma com seu próprio config.yaml, .env, SOUL.md, memories/, sessions/, skills/, state.db, cron/, logs/ e gateway.pid

   hermes profile create coder

O perfil criado vira um comando próprio, então passa a existir coder chat, coder setup, coder gateway start e por aí vai

Dá pra ir além e criar um perfil vazio, com zero skills empacotadas habilitadas: isso grava um marcador .no-bundled-skills no diretório do perfil, que impede o hermes update de re-semear o conjunto padrão depois

Só não dá pra combinar essa criação de perfil vazio com --clone, --clone-from ou --clone-all

E os caminhos daqui pra frente? Boa pergunta, porque isso confunde muita gente

Os ~/.hermes/config.yaml, ~/.hermes/memories/ e ~/.hermes/skills/ que aparecem nos próximos passos são como a doc escreve o diretório de estado padrão

Como o isolamento é por HERMES_HOME, com o perfil coder no comando esses mesmos arquivos passam a ser os do perfil: mesmo nome, mesma chave, só que dentro do estado isolado dele

O erro comum deste passo: achar que isolar é exportar um HOME falso antes de rodar o agente

Não é, o estado sai de HERMES_HOME

2. Aponte o terminal do agente para um container

O Hermes suporta sete backends de terminal, que definem ONDE os comandos de shell dele rodam: máquina local, Docker, servidor remoto via SSH, Modal, Daytona, Vercel Sandbox e Singularity/Apptainer

Pro teste, o Docker resolve, e a configuração fica no bloco terminal do config.yaml (o do perfil, lembra?), que na doc aparece como ~/.hermes/config.yaml:

   terminal:
     backend: "docker"
     docker_image: "<imagem-que-voce-escolheu>"
     cwd: "/caminho/do/repo-de-brinquedo"
     docker_mount_cwd_to_workspace: true
     container_persistent: false

Por padrão o backend Docker usa um container de vida longa, reaproveitado entre sessões

Com container_persistent: false, cada chat ganha um sandbox novo, criado na primeira chamada de terminal ou de arquivo e removido quando a sessão fecha ou fica ociosa

O erro comum deste passo: deixar o cwd apontando pro projeto real e montar ele no workspace

Aí não tem sandbox que salve, você entregou o que queria proteger

3. Controle o que entra no container

O que é encaminhado pra dentro fica visível pros comandos que rodam lá

Por isso o Docker recebe uma allowlist explícita de variáveis de ambiente, na chave terminal.docker_forward_env, e arquivos de credenciais são montados em modo somente leitura

O erro comum deste passo: encaminhar meia dúzia de variáveis "porque senão não funciona"

Se o teste precisa de segredo de produção pra rodar, não é um teste controlado, é produção com outro nome

4. Deixe a aprovação de comandos no modo manual

Antes de executar qualquer comando, o Hermes compara ele com uma lista curada de padrões perigosos e exige aprovação explícita quando bate

No CLI interativo aparece um prompt inline; em plataformas de mensagem o agente manda os detalhes no chat e espera resposta

Tome cuidado com uma pegadinha do passo 2: nos backends de container essas checagens de comando perigoso são PULADAS, porque o próprio container passa a ser a fronteira de segurança

Isso vale pra docker, singularity, modal, daytona e vercel_sandbox, ou seja, no setup com Docker quem segura a onda é o container, e o modo manual fica valendo como rede pra quando o backend não for de container

Mesmo assim vale deixar configurado, porque é a configuração que fica no config.yaml do perfil e aceita três valores:

   approvals:
     mode: manual   # manual | smart | off
     timeout: 60

O approvals.timeout é em segundos, com padrão documentado de 60, e ele falha fechando: sem resposta dentro do prazo, o comando é NEGADO

O modo off desliga todos os prompts de segurança, e a documentação indica ele só pra ambiente confiável, tipo CI/CD e containers

Tem ainda o modo YOLO, que ignora todos os prompts de aprovação da sessão atual (menos a blocklist rígida), ligado por hermes --yolo na linha de comando ou por /yolo durante a sessão

E existe uma blocklist irrecuperável que o Hermes recusa SEMPRE, sem flag de override, incluindo apagamentos irreversíveis de sistema de arquivos, fork bombs e escrita direta em block device

O erro comum deste passo: dar /yolo no meio do teste "só pra destravar" e esquecer que aquilo vale pra sessão inteira

5. Feche a memória antes da primeira tarefa

A memória e o perfil do usuário ficam na pasta memories/ do diretório de estado (na doc, ~/.hermes/memories/), e entram no system prompt como um snapshot congelado no início da sessão

Ou seja: o que o agente gravar hoje volta amanhã, sozinho

Dá pra desligar por completo com memory_enabled: false, ou deixar sob aprovação com memory.write_approval: true, exigindo aprovar cada gravação

Com o gate ligado, você revisa o que está na fila com /memory pending, e as gravações automáticas aparecem sinalizadas como automáticas na listagem

O erro comum deste passo: rodar o teste com memória aberta e depois querer "limpar"

Deixa fechado desde o começo, é mais barato

6. Ligue o gate de skills

Todas as skills vivem numa pasta única do diretório de estado (na doc, ~/.hermes/skills/), que é a fonte da verdade, incluindo as que o próprio agente cria (com suporte a subpastas pra organizar)

Com o gate de aprovação ligado, toda escrita de skill para em pending/skills/ antes de virar skill de verdade, cobrindo create, edit, patch, delete, write_file e remove_file

A revisão é por comando de chat, tanto no CLI quanto nas plataformas de mensagem:

   /skills pending
   /skills diff <id>
   /skills approve <id>
   /skills reject <id>
   /skills approval on|off

O erro comum deste passo: aprovar em lote sem olhar o diff

Skill aprovada é comportamento novo permanente, vale ler antes

7. Mantenha plugins e backends do usuário desativados

Aqui o padrão já joga a seu favor: plugins gerais e backends instalados pelo usuário vêm desativados

A descoberta encontra eles, mas nada com hooks ou ferramentas carrega até o nome ser adicionado na chave plugins.enabled do config.yaml

O erro comum deste passo: ligar tudo no dia um pra "ver funcionando" e nunca mais saber qual peça causou qual comportamento

8. Observe a sessão antes de julgar

As sessões de CLI e de mensageria ficam num banco SQLite, o state.db do diretório de estado, com busca full-text via FTS5

Então tu tem três lugares pra olhar depois do teste: state.db pra reler o que aconteceu, memories/ pra ver o que o agente quis guardar e skills/ pra ver o que ele quis aprender

O agente vem com mais de 40 ferramentas embutidas, incluindo busca web e automação de navegador, então a pergunta não é "funcionou?", é "ele tentou fazer o quê sem eu pedir?"

O que apareceu no teste em VPS

Quando testei o Hermes, montei ele numa VPS separada, e não na minha máquina de trabalho, justamente pra mexer sem risco no ambiente principal

Subi o servidor com o sistema limpo, removendo o pacote pré-instalado que vinha na oferta, pra começar sem nada em volta atrapalhando o diagnóstico

No setup eu fui pelo caminho mínimo em vez de configurar tudo de uma vez, porque o mínimo já mostra a ferramenta funcionando

Pra não gastar no teste, conectei a um roteador de LLMs com opção gratuita

E criei uma chave de API nova, exclusiva pro Hermes, em vez de reaproveitar uma que já existia

Nessa chave eu defini limite de crédito, porque agente costuma consumir mais que o normal, e dá pra colocar data de expiração também

Gateway de mensagens eu deixei pra depois: dei skip no Telegram no setup, porque primeiro eu queria saber como a ferramenta se comporta antes de plugar ela num chat

Esse cuidado também vem de eu evitar as APIs de provedores que estão restringindo uso por agentes

No fim do setup a tela mostrou onde ficam os arquivos e pastas principais, o comando pra editar configuração, o pra checar problemas e o pra configurar o gateway de mensagens

Meu primeiro pedido dentro da ferramenta não foi tarefa: foi um resumo das ferramentas disponíveis, pra saber o que ele conseguia fazer antes de soltar ele em cima de qualquer coisa

Vieram leitura e escrita de arquivos, busca em arquivos, patch, navegação web, memória e tarefas recorrentes

Traduzindo: acesso ao sistema operacional da máquina, e é exatamente por isso que a conversa sobre dar acesso às suas contas vem antes da conversa sobre produtividade

O segundo teste foi um comando inofensivo de diagnóstico, uso de disco e memória: deu 8% de disco usado e 7 GB de memória disponível na VPS

Depois testei a busca web pedindo novidades recentes, e achei rápida a resposta com o modelo gratuito que escolhi

Sobre o plano de servidor: o nível mais básico aguenta se a intenção for só testar, e eu indico o nível acima pra quem for usar de verdade

E recomendo o óbvio que quase ninguém faz: ler a documentação oficial em vez de confiar só no que o youtuber mostrou, inclusive eu 😀

Veja o Hermes Agent rodando no vídeo

No vídeo abaixo eu mostro a instalação na VPS, a primeira sessão e o comportamento do agente respondendo os primeiros pedidos, que é a parte que texto nenhum consegue passar direito

Quando já dá para promover o agente para tarefas de verdade

Promover não é virar uma chave

É abrir acesso por camadas, uma de cada vez, esperando algumas sessões entre uma e outra pra ver se aparece surpresa

O sinal de que dá pra avançar é bem concreto: você conseguiu reler as sessões e não achou nada que te fez levantar a sobrancelha, o /skills pending só trouxe coisa que você entendeu, e as gravações de memória em espera eram todas coisas que você mesmo teria escrito

E tem um ponto que a própria documentação faz questão de dizer, que eu acho honesto demais pra ignorar: as regras de negação são guarda-corpo contra um agente honesto porém errado, e não um sandbox contra um processo deliberadamente adversarial

Pro caso adversarial, a doc manda usar backend isolado (Docker, Modal) ou ambiente com saída de rede restrita

Pra deployment de gateway em produção, a recomendação é backend de container pra isolar os comandos do agente do host: docker, modal, daytona ou vercel_sandbox

Juntando com o que apareceu lá no passo 4: container e prompt de aprovação não se somam do jeito que você imagina, um substitui o outro

E existem relatos públicos no repositório oficial sobre execução de código no sandbox contornando a aprovação de comandos perigosos, como a issue #4146

Eu não confirmei o status dela na v0.20.1, então trato como mais um motivo pra não apostar tudo em uma camada só

Se você está montando um critério mais amplo antes de depender do projeto, esse é o tipo de coisa que entra na conta

Conclusão

Perfil descartável não é ritual de uma vez só, é padrão de trabalho

Cria, testa, joga fora, cria de novo quando for testar outra coisa

O custo disso é baixo perto do custo de descobrir tarde o que um agente com acesso ao shell consegue fazer sozinho

Próximo passo bem concreto, na ordem: roda hermes doctor, cria o perfil de teste, aponta o terminal pro container com container_persistent: false e revisa o primeiro /skills pending ANTES de mandar qualquer tarefa de verdade

Depois disso tu tira as próprias conclusões, que é o que importa

até o próximo post! =)