Memória do Agente Hermes Explicada: Limites e Compromissos

Oi, eu sou a Lena. Eu tinha uma pergunta que ficava adiando sobre a memória do Agente Hermes. Toda vez que alguém a descrevia como "o agente que aprende", eu pausava por um momento. Aprende o quê, exatamente? E lembra onde estava? Voltei aos documentos algumas vezes antes de sentir que tinha nem metade da resposta. Isso é o que percebi.

Estou escrevendo isso não como alguém que construiu o Hermes, mas como alguém que observou o sistema tempo suficiente para ver onde sua memória faz o que as pessoas esperam — e onde silenciosamente não faz. A lacuna entre esses dois pontos é maior do que a linguagem de marketing sugere, e vale a pena ser honesto sobre isso.

O que a memória do Hermes realmente armazena

A primeira coisa que tive que desaprender: o Hermes não tem um único sistema de memória. Ele tem vários, e eles não fazem o mesmo trabalho. A maior parte da confusão que vi vem de tratá-los como uma única coisa.

MEMORY.md, USER.md e snapshots de sessão congelados

A camada interna consiste em dois arquivos markdown que vivem em ~/.hermes/memories/. Segundo a documentação oficial da memória do Hermes, MEMORY.md é limitada a cerca de 2.200 caracteres (aproximadamente 800 tokens) e mantém fatos do ambiente, convenções do projeto e lições que o agente acha que valem a pena guardar. USER.md é menor — cerca de 1.375 caracteres, aproximadamente 500 tokens — e armazena preferências sobre você.

Ambos são carregados no início da sessão como um snapshot congelado injetado no prompt do sistema. Essa palavra — congelado — é a parte que eu continuava perdendo na primeira leitura. Escritas durante a sessão são persistidas no disco imediatamente, mas o snapshot no prompt ativo não é atualizado até que a próxima sessão comece.

Fiquei um tempo refletindo sobre isso. Explica um comportamento que eu tinha visto e não conseguia identificar: o agente salva algo, diz que salvou, e então prossegue como se ainda não tivesse realmente. Isso não é um bug — é o modelo de snapshot. Quando entendi isso, algumas pequenas inconsistências deixaram de parecer inconsistentes.

O que "persistente" significa na prática

"Persistente" aqui faz um trabalho real, mas de uma forma mais limitada do que a palavra de marketing sugere. Os arquivos sobrevivem entre as sessões. Eles são curados pelo agente, não gravados pelo agente — o LLM decide o que vale a pena salvar. E eles têm limite de propósito: um prompt de sistema pequeno e estável é o que torna o cache de prefixo eficiente, e o cache de prefixo é parte do motivo pelo qual o agente parece responsivo.

Então, quando alguém diz que Hermes "lembra", o que geralmente querem dizer, mais precisamente: um pequeno caderno deliberadamente limitado é recarregado no início de cada sessão, e um arquivo pesquisável separado de conversas passadas existe ao lado dele. Duas coisas diferentes, com dois padrões de acesso diferentes.

Para o que a memória do Hermes é boa

Quero ser justo aqui. O sistema incorporado é genuinamente útil — apenas não é o que a maioria das pessoas imagina inicialmente.

Preferências, fatos do ambiente, contexto recorrente

O ponto ideal são fatos pequenos, duráveis e frequentemente relevantes. Coisas como:

"O projeto do usuário é um serviço web em Rust usando Axum + SQLx"
"O usuário prefere respostas concisas, não gosta de explicações verbosas"
"Esta máquina roda Ubuntu 22.04, tem Docker instalado"

Esse tipo de contexto pertence ao prompt do sistema toda vez, e o Hermes lida bem com isso. O agente salva automaticamente quando julga algo que vale a pena guardar e consolida quando as entradas se acumulam — mesclando, por exemplo, três linhas "projeto usa X" em uma única descrição do projeto. Em sessões curtas ou focadas, você pode não ver nada escrito — isso é uma funcionalidade, não uma falha. A maioria das tarefas curtas não deveria poluir seu caderno de longo prazo.

Também há uma etapa de verificação de segurança nas entradas de memória para capturar tentativas de injeção de prompt, algo que gostei de notar no código-fonte do Hermes no GitHub. É um detalhe pequeno, mas do tipo de detalhe que mostra que alguém pensou sobre o que poderia dar errado quando um LLM está encarregado de escrever sua própria memória.

O que a memória do Hermes não resolve

É aqui que tive que desacelerar. Muitas expectativas se quebram aqui, e não acho que seja porque o sistema esteja fazendo algo errado — acho que é porque a palavra memória está carregando trabalho demais.

Memória limitada, reinícios de sessão, nenhuma validação automática de comportamento aprendido

Algumas coisas merecem ser honestas:

A memória é limitada. ~2.200 caracteres para o ambiente, ~1.375 para o usuário. Quando o limite é alcançado, o agente precisa consolidar ou remover entradas antes de adicionar novas. Especificidades nuances podem ser comprimidas durante esse processo. Esta é a surpresa mais comum — as pessoas supõem que a memória cresce; não cresce. Um orçamento pequeno e fixo é o design.

As escritas no meio da sessão não aparecem na mesma versão. O modelo de snapshot congelado significa que o agente age sobre o que carregou no início, mesmo depois de escrever novas entradas. Reiniciar a sessão e eles estão no contexto. Se você precisar que o agente aja sobre algo que ele acabou de escrever, faça referência explicita na conversa — não espere que apareça automaticamente.

O agente precisa decidir salvar. A memória embutida é baseada em julgamento. Não há transcrição automática. Um nudge_interval configurável periodicamente faz o agente refletir, mas em sessões curtas você pode realmente ver arquivos vazios. Talvez eu esteja interpretando demais nisso, mas acho que é a parte menos comunicada do design.

Não há validação automática. Se o agente salva uma "lição aprendida" e a lição estava realmente errada, nada sinaliza isso. O fato permanece no instantâneo até que algo o substitua. Memória não é o mesmo que conhecimento verificado — é apenas o que um modelo achava, em algum momento, que valia a pena manter.

Memória não é a mesma coisa que capacidade reutilizável

Essa é a parte que precisei reler minhas próprias anotações. O Hermes também tem skills — documentos de markdown em ~/.hermes/skills/ que capturam procedimentos, ferramentas usadas e etapas que funcionaram. As skills são criadas reativamente após tarefas complexas (tipicamente 5+ chamadas de ferramenta) e carregadas sob demanda usando divulgação progressiva: o Nível 0 é apenas uma lista de nomes de habilidades e breves descrições, o Nível 1 carrega todo o conteúdo de uma habilidade específica quando necessário.

Memória e habilidades são coisas diferentes, mesmo que ambas pareçam arquivos markdown**.**

Memória é "o que esse usuário prefere e em que ambiente estamos." Habilidades são "como fazer esse tipo de tarefa." Preferência não diz ao agente como depurar um fluxo OAuth; uma habilidade pode. Confundir os dois é, eu acho, a maior fonte de confusão quando as pessoas dizem "o agente não está aprendendo." Pode ser que esteja aprendendo — só não na camada que estão verificando.

Recordação entre sessões, busca por sessões e onde as pessoas se confundem

Além do MEMORY.md e USER.md, o Hermes armazena todas as sessões de CLI e mensagens em SQLite at ~/.hermes/state.db com busca em texto completo do FTS5. O agente pode chamar uma ferramenta session_search para recuperar conversas passadas, que são então resumidas usando um pequeno modelo.

Dois detalhes que valem a pena saber.

FTS5 é baseado em palavras-chave. É um índice poderoso e bem projetado — a documentação do SQLite FTS5 descreve como ele tokeniza o conteúdo e faz correspondência com esses tokens — mas ele corresponde a tokens exatos, não ao significado. Se uma sessão anterior disse "o microsserviço de autenticação usa Redis", perguntar "o que eu te disse sobre o serviço de autenticação?" pode não recuperar essa informação. O agente precisa saber chamar session_search, e usar os termos corretos da consulta. Não há resolução de entidade, não há rastreamento de relacionamento, não há reformulação semântica.

A busca por sessão não é automática. É uma ferramenta que o agente decide usar. Se o agente não pensar em chamá-la antes de responder, a conversa passada não é consultada. Isso é uma lacuna de comportamento, não de armazenamento — os dados estão lá, apenas a recuperação não aconteceu.

É aqui que vejo as pessoas ficarem mais frustradas. Elas viram o agente discutir algo há três semanas e assumem que isso surgirá naturalmente. Às vezes acontece. Frequentemente não, porque nada acionou a busca. A Vectorize tem uma análise útil desses modos de falha em seu artigo de solução de problemas sobre a memória Hermes, ao qual voltei duas vezes.

Conselhos práticos de design para workflows Hermes de longa duração

Tenho receio de dar conselhos — sou apenas um ponto de dados. Mas algumas coisas se destacaram ao observar isso por um tempo.

Trate a memória interna como um pequeno caderno, não como um banco de dados. Qualquer coisa que precise escalar com o comprimento da conversa não pertence lá. Use-a para fatos estáveis que devem sempre estar no contexto, e aceite que detalhes serão comprimidos quando o orçamento se esgotar.

Seja explícito quando algo importa. "Lembre-se que meu banco de dados de produção roda na porta 5433" funciona melhor do que esperar que o agente destaque isso sozinho. A memória interna é curada, não gravada — e o julgamento do agente sobre o que importa nem sempre corresponderá ao seu.

Recorra a um provedor externo quando precisar de recordação estruturada. A página de provedores de memória Hermes lista oito opções plugáveis — Honcho, OpenViking, Mem0, Hindsight, Holographic, RetainDB, ByteRover e Supermemory. Elas se posicionam adicivamente sobre MEMORY.md e USER.md, que continuam funcionando inalteradas. A camada interna não desaparece; a externa preenche o que ela não consegue fazer.

Para modelagem de usuário entre sessões especificamente, Honcho adota uma abordagem baseada em pares — usuário e IA são ambos modelados como pares, cada um com sua própria representação que atualiza a partir das observações ao longo do tempo. É uma filosofia de design diferente de um armazenamento de fatos plano, e ainda estou descobrindo onde recorreria a isso em comparação a um armazenamento vetorial mais simples. Mas o raciocínio dialético multi-passe é interessante, especialmente a distinção entre início frio e sessão quente.

Não confunda memória com capacidade. Se você quer que o agente faça algo melhor da próxima vez, provavelmente quer uma habilidade, não uma entrada de memória. E se quiser que fique correta da próxima vez, nem memória nem habilidades vão validar isso para você — você tem que validar. Essa é a parte à qual sempre volto.

! [imagem] (https://uploads.evomap.ai/blog/12c84a7281199cf3.png)

FAQ

A memória do Agente Hermes** fica mais inteligente com o tempo?**

Os arquivos acumulam fatos. Se isso constitui "mais inteligente" depende do que você quer dizer. O agente usa o que está no snapshot, mas não raciocina sobre o histórico das edições de memória a menos que você tenha adicionado um provedor externo que o faça. Eu tomaria cuidado com a palavra aprenda aqui.

Por que MEMORY.md** está vazio depois de várias sessões?**

Muito provavelmente o agente nunca avaliou nada que valesse a pena salvar — sessões curtas ou focadas em tarefas geralmente não produzem escritas específicas. Verifique sua configuração nudge_interval ou procure um provedor externo se quiser captura automática sem depender do julgamento do agente.

Posso só aumentar o limite?

Você pode. Os limites de caracteres são configuráveis em ~/.hermes/config.yaml. Mas o limite existe por um motivo — snapshot maior, menos espaço para conversa real e benefícios de prefixo cache mais fracos. Maior não é grátis.

O que acontece com a memória no meio da reunião?

As gravações vão para o disco. O prompt ativo só atualiza na próxima sessão. Isso é esperado, e tentar confiar em atualizações de memória dentro da sessão vai te custar tempo de depuração.

A busca de sessão é a mesma coisa que memória?

Não. Memória é o snapshot sempre carregado. A busca de sessão é uma busca por palavra-chave sob demanda sobre conversas passadas. Mecanismos diferentes, latência diferente, modos de falha diferentes.

Ainda não estou pronto para fechar este caso. Há muita coisa na pilha de memória do Hermes Agent que quero continuar acompanhando — especialmente como os provedores externos se comportam depois que um perfil tem meses de dados por trás. Por enquanto, é aqui que meu entendimento está.