Como revisar o que o Hermes Agent entregou antes de aceitar o resultado

Revisar saída do Hermes Agent é uma rotina de cinco checagens rápidas, não uma leitura de fé no resumo do agente: olhar o /diff da sessão, comparar contra o checkpoint com /rollback diff <N>, auditar as mensagens reais com session_search (SQLite com FTS5 em ~/.hermes/state.db), aprovar ou rejeitar memória em /memory pending e skill em /skills pending. Isso só funciona se você ligar as travas antes: checkpoints são opt-in desde o v2, approvals.mode fica em ~/.hermes/config.yaml e skills.write_approval vem false. Quando o rumo errou lá atrás, refazer com /rewind ou /rollback sai mais barato que corrigir na mão
Aceitar entrega de agente sem conferir é assinar embaixo de um código que você nunca leu
O Hermes Agent é um agente open source da Nous Research, publicado sob licença MIT e lançado em 25 de fevereiro de 2026
A versão mais recente publicada no repositório oficial é a v0.20.1, de 13 de agosto de 2026 (tag v2026.8.13), descrita como rollup de estabilização e correções
E aqui não tem prompt mágico, é roteiro mesmo: o que olhar primeiro, que tipo de erro escapa da conferida rápida e quando vale mais mandar refazer do que sair corrigindo na mão
Se a sua dúvida ainda é anterior a essa, mais no sentido de avaliar o projeto antes de adotar, esse papo é outro… aqui a gente já parte do agente rodando na sua máquina
O que ligar antes de deixar o agente trabalhar
Revisão boa é configuração feita ANTES, não boa vontade depois
Se você só lembra de conferir quando a entrega chegou, metade das ferramentas de revisão já não tem o que mostrar
Formação Claude Code
Domine Claude Code do absoluto zero até o avançado
- 120 aulas
- 4 projetos
- 9h 45min
Então liga isso primeiro:
- Checkpoints: eles são opt-in e vêm desligados por padrão, dá pra habilitar por sessão com a flag
--checkpoints - Aprovações: a chave
approvals.modefica no~/.hermes/config.yamle aceitamanual,smartouoff, com timeout padrão de 60 segundos esperando a sua resposta ecron_mode: deny - Lista de bloqueio:
approvals.denyé uma lista editável de padrões glob que barra comandos de terminal incondicionalmente, e ela é consultada ANTES de--yolo,/yoloeapprovals.mode: off - Skills:
skills.write_approvalvem comofalsepor padrão, ou seja, escrita livre, comtruetoda escrita deskill_manage(create, edit, patch, delete, write_file, remove_file) fica em espera - Memória:
/memory approval onliga o portão de aprovação de escrita e a escolha fica persistida
Um esqueleto mínimo de config pra quem quer conferir tudo:
# ~/.hermes/config.yaml
approvals:
mode: manual
skills:
write_approval: true
Tome cuidado com um detalhe: a documentação de segurança recomenda NÃO ativar aprovação em um gateway que não consiga exibir o prompt de forma visível, e cita o Telegram como o caso ruim
Faz sentido, né? Portão de aprovação que ninguém vê é só um timeout esperando pra acontecer
Passo a passo para revisar a entrega do Hermes Agent
A ordem importa: você começa pelo que mudou no disco e só depois vai pro que o agente guardou pra usar no futuro
- Olhe o diff da sessão antes de qualquer aceite
/diff
Esse comando funciona tanto na CLI quanto no gateway de mensagens
O erro comum deste passo é aceitar pelo resumo que o próprio agente escreveu, o resumo é a versão dele da história, o diff é o que foi pro arquivo
- Compare contra o snapshot
/rollback
/rollback diff 1
O /rollback sozinho lista os checkpoints e o /rollback diff <N> pré-visualiza o que vai mudar antes de restaurar qualquer coisa
O store é um repositório git sombra compartilhado em ~/.hermes/checkpoints/store/, então o .git real do seu projeto não é alterado
O erro comum aqui é descobrir na hora H que os checkpoints estavam desligados, lembra que o padrão é off
- Audite o que o agente de fato fez, não o que ele contou
A ferramenta session_search devolve as mensagens reais do banco, sem sumarização por LLM e sem truncar
Todas as sessões de CLI e gateway ficam gravadas em SQLite no ~/.hermes/state.db, com busca full-text FTS5
E tem uma coisa MUITO útil aí: o /rewind trunca o transcript por soft delete, então o conteúdo rebobinado continua visível pro session_search e pra auditoria
O erro comum é achar que o que sumiu do contexto ativo sumiu do banco, não sumiu 🙂
- Revise o que ficou gravado pras próximas sessões
/memory pending
/memory approve <id>
/memory reject <id>
O /memory pending lista as escritas em espera, e as que o próprio agente gravou aparecem sinalizadas como automáticas, tanto approve quanto reject aceitam all
As memórias vivem em ~/.hermes/memories/ e são injetadas no system prompt como um snapshot congelado no início da sessão
O erro comum deste passo é pular ele por parecer inofensivo, memória ruim aprovada hoje é resposta torta amanhã
- Revise as skills escritas na sessão
/skills pending
/skills diff <id>
/skills approve <id>
/skills reject <id>
O /skills pending traz a lista com um resumo de uma linha cada e o /skills diff <id> mostra o diff unificado completo
As pendências ficam em ~/.hermes/pending/skills/ e sobrevivem a reinício, e cada skill mora em ~/.hermes/skills/, um diretório com seu SKILL.md mais arquivos de apoio opcionais
O erro comum é aprovar pelo resumo de uma linha, o resumo cabe em uma linha justamente porque ele não mostra tudo
- Cheque o ambiente fora da sessão
hermes checkpoints
hermes dump
O hermes checkpoints inspeciona o store sombra (tamanho total, contagem de projetos e detalhamento por projeto), roda com segurança a qualquer momento e não exige o agente em execução, e ainda tem hermes checkpoints prune e hermes checkpoints clear
Já o hermes dump imprime um resumo compacto em texto puro de toda a configuração, feito pra colar no Discord, numa issue do GitHub ou no Telegram quando você for pedir ajuda
Erros que passam despercebido na revisão
Esses são os casos em que a saída PARECE certa
O contexto não bate com o disco depois de rebobinar
Sintoma: você rebobinou, o agente segue falando de um estado que os arquivos não têm mais, ou o contrário
Causa: /rewind trunca só o transcript, ele descarta do contexto ativo as mensagens, chamadas de ferramenta e turnos posteriores, e não mexe nos arquivos
Correção: quando o que você quer é voltar os dois juntos, use /rollback, que restaura arquivos e desfaz o último turno da conversa, justamente pra deixar o contexto coerente com o sistema de arquivos
Efeito colateral fora do arquivo que você abriu
Sintoma: o arquivo revisado está impecável e alguma outra coisa quebrou
Causa: /diff mostra o texto, o checkpoint mostra o conjunto, e a sua atenção foi pro arquivo que você já esperava ver mudar
Correção: rode /rollback diff <N> pra ver o pacote inteiro, e se só um arquivo estiver errado dá pra restaurar apenas ele de um checkpoint, sem afetar o resto do diretório
Memória automática gravando uma conclusão errada
Sintoma: na sessão de hoje tudo certo, na de amanhã o agente começa insistindo numa decisão que ninguém tomou
Causa: as memórias entram como snapshot congelado no início da sessão, então uma escrita automática ruim só aparece DEPOIS
Prevenção: o portão, /memory approval on, e a checagem do /memory pending como parte da revisão, não como faxina de fim de mês
Skill nascida torta
Sintoma: uma skill que ninguém escreveu à mão começa a guiar o agente pro lugar errado
Causa: o /learn destila uma skill reutilizável a partir do que você descrever, um diretório, uma URL, o fluxo que você acabou de percorrer ou notas coladas, e o agente reúne as fontes e escreve o SKILL.md
É ótimo, e é exatamente por ser fácil que passa batido
Correção: /skills diff <id> antes de aprovar, sempre
Comando perigoso rodando porque a sessão estava em YOLO
Sintoma: um comando que você jamais autorizaria simplesmente rodou
Causa: o modo YOLO desliga as checagens de comando perigoso da sessão, mantendo só a blocklist hardline, e ele entra por hermes --yolo, hermes chat --yolo ou digitando /yolo na sessão
Ele avisa, viu: faixa vermelha no início da sessão e um fragmento de aviso YOLO na barra de status
Prevenção: approvals.deny, que bloqueia antes de qualquer modo permissivo, e quando o risco for real trocar o backend do terminal:
hermes config set terminal.backend docker
A partir daí cada comando de shell e execução de Python roda num container novo que é descartado depois, o que muda bastante a régua de conter o estrago de um erro antes que ele aconteça
Pesquisa com fonte que ninguém abriu
Sintoma: a resposta vem redondinha, com citação e tudo, e a citação não sustenta a frase
Contexto: a release v0.20.0, de 3 de agosto de 2026, trouxe pesquisa fundamentada com citações verificáveis e checagem de fatos
Correção: o papel do revisor continua sendo abrir a citação, citação verificável é convite pra verificar, não dispensa 😀
Quando mandar refazer e quando corrigir na mão
O critério é simples: dá pra apontar a instrução exata onde o rumo torceu?
Se dá, refaz
Se o diff está quase certo e você consegue arrumar em menos tempo do que levaria pra reexplicar, corrige na mão e segue
| Situação | Decisão | Comando |
|---|---|---|
| O rumo errou a partir de uma mensagem específica | Refazer dali | /rewind |
| Arquivos e conversa precisam voltar juntos | Refazer do checkpoint | /rollback <N> |
| Só um arquivo saiu errado | Restaurar pontual | restauração de arquivo único do checkpoint |
| Diff quase certo, ajuste pequeno | Corrigir na mão | edição direta |
| A sessão longa já está atrapalhando a revisão | Enxugar ou recomeçar | /compress ou /new |
E tem a manutenção da biblioteca, que é o que evita revisão futura em cima de skill zumbi
O curator é uma passagem em segundo plano sobre as skills criadas pelo agente: ele acompanha quantas vezes cada skill foi vista, usada e corrigida, e move as sem uso pelos estados active, stale e archived
Skill sem uso por stale_after_days (30) vira stale, e sem uso por archive_after_days (90) vai pra ~/.hermes/skills/.archive/
Os arquivos são recuperáveis e a exclusão automática nunca acontece, então pode respirar
Pra espiar sem mexer em nada:
hermes curator run --dry-run
hermes journey
O --dry-run mostra o que o curator faria e produz o mesmo relatório de revisão sem alterar a biblioteca
Já o hermes journey (que atende também por hermes learning e hermes memory-graph) renderiza no terminal a linha do tempo do aprendizado, com --play pra animar a construção, --width e --height pra forçar o tamanho, --no-color e --json pra despejar o payload bruto do grafo
O próximo passo
Revisar saída do Hermes Agent é menos sobre desconfiar do agente e mais sobre ter deixado as travas ligadas quando ainda dava tempo
Quem só lembra da conferência depois da entrega revisa com uma mão amarrada: sem checkpoint não tem comparação, sem portão de aprovação a memória e a skill já valeram
Então o próximo passo é bem concreto
Liga --checkpoints na próxima sessão, coloca approvals.mode em manual no ~/.hermes/config.yaml, ativa /memory approval on e põe skills.write_approval: true
Depois roda o roteiro na primeira entrega que aparecer: /diff, /rollback diff <N>, session_search, /memory pending e /skills pending
Cinco checagens, e você deixa de aceitar coisa no escuro
até o próximo post!
Perguntas frequentes
Como saber se os checkpoints estão ativados numa sessão do Hermes Agent?
Checkpoints são opt-in e vêm desligados por padrão, só entram habilitando por sessão com a flag –checkpoints. Dentro da sessão, rode /rollback: se a lista vier vazia, é sinal de que eles não foram ligados dessa vez.
Qual a diferença entre /rewind e /rollback no Hermes Agent?
/rewind trunca o transcript por soft delete, descartando do contexto ativo as mensagens e turnos posteriores, mas não toca nos arquivos do projeto. /rollback restaura os arquivos a partir do checkpoint em git sombra e ainda desfaz o último turno da conversa, deixando o contexto coerente com o filesystem restaurado.
Onde ficam salvas as conversas do Hermes Agent para auditoria?
Todas as sessões de CLI e gateway ficam gravadas em SQLite no arquivo ~/.hermes/state.db, com busca full-text via FTS5. A ferramenta session_search devolve as mensagens reais do banco, sem sumarização por LLM e sem truncar nada.
Dá para revisar uma skill antes que o Hermes Agent grave ela de vez?
Dá, ativando skills.write_approval: true no ~/.hermes/config.yaml, o que deixa toda escrita de skill_manage em espera. A revisão é feita com /skills pending e /skills diff <id>, e a decisão sai com /skills approve <id> ou /skills reject <id>.
É seguro usar aprovação de escrita no gateway do Telegram?
A própria documentação de segurança recomenda não ativar aprovação em um gateway que não consiga exibir o prompt de forma visível, e cita o Telegram como caso ruim. Um portão de aprovação que ninguém vê é só um timeout esperando pra acontecer.
Como conferir a configuração do Hermes Agent sem abrir uma sessão?
O comando hermes checkpoints inspeciona o store sombra de checkpoints (tamanho total, contagem de projetos e detalhamento) e roda com segurança a qualquer momento, sem precisar do agente em execução. Já o hermes dump imprime um resumo compacto em texto puro de toda a configuração, pronto pra colar no Discord, numa issue do GitHub ou no Telegram.
Formações
Formação Vibe Coding
Do Prompt ao Produto: Crie Software Real com IA
- 474 aulas
- 20 projetos
- 39h 27min
Blog | Mais populares
Hermes Agent é gratuito para usar em trabalho de cliente?
Hermes Agent é licenciado em MIT: uso comercial liberado sem taxa. Veja o que isso cobre, o que fica de fora e as regras para trabalho de cliente.
Como testar o Hermes Agent em ambiente controlado antes de dar acesso ao que importa?
Aprenda a testar o Hermes Agent em ambiente controlado: perfil isolado, container descartável, aprovação manual e skills sob revisão antes do acesso real.
Hermes Agent e Claude Code: onde cada um entra no fluxo de quem programa?
Hermes Agent e Claude Code fazem coisas diferentes: veja onde cada um entra no fluxo de quem programa e como a skill claude-code liga os dois.
