Hermes Agent e um segundo cérebro: dê contexto ao agente, não a sua memória

A memória do Hermes Agent não é o seu segundo cérebro, e o fato de as duas coisas serem arquivos markdown em disco é exatamente por que o pessoal confunde uma com a outra. O MEMORY.md tem um limite de cerca de 2.200 caracteres. Sua base de conhecimento não deveria ter limite nenhum. Uma coisa são as notas do agente sobre ele mesmo. A outra é o seu julgamento sobre o que importa, e o agente deveria ler isso, não ser o dono disso.

Eu rodo o Hermes Agent em produção, com o meu segundo cérebro como algo que ele lê para contexto, não um lugar onde ele escreve. Este é o mapa: o que o Hermes realmente lembra por conta própria, a skill embutida que dá a ele um workflow de Obsidian baseado em filesystem, o único arquivo de contexto que ele carrega por projeto, e a fronteira que eu mantenho entre um vault que eu curo e a memória que o agente escreve sobre si mesmo.

Integração do Hermes Agent com o Obsidian: uma skill embutida, não um plugin

O Hermes vem com uma skill embutida chamada obsidian que dá a ele acesso baseado em filesystem a um vault do Obsidian: ler uma nota, listar notas, buscar por nome de arquivo ou conteúdo, criar uma nota, anexar a uma nota com um patch ancorado, e adicionar [[wikilinks]] quando cria algo novo. O caminho do vault vem de uma variável de ambiente OBSIDIAN_VAULT_PATH, com fallback para ~/Documents/Obsidian Vault se não estiver definida.

Releia essa lista e note o que está faltando. Não tem chamada à REST API do Obsidian, não tem plugin instalado dentro do próprio Obsidian, nada que converse com o app de verdade. O Hermes lê e escreve arquivos markdown num diretório. O Obsidian é o editor que, por acaso, renderiza [[wikilinks]] como um grafo e transforma frontmatter YAML em queries do Dataview em cima desses mesmos arquivos. A skill funciona com o Obsidian aberto ou fechado, porque o vault é só uma pasta de texto, e esse é o ponto inteiro: markdown mais git é a camada real de interoperabilidade, o Obsidian é só um visualizador muito bom para ela.

O llm wiki que vem com o Hermes Agent, e o que você deveria realmente rodar

O Hermes também vem com uma segunda skill relacionada, chamada llm-wiki, construída sobre o padrão de llm wiki do Andrej Karpathy: uma base de conhecimento persistente e cumulativa de arquivos markdown interligados, com uma divisão de trabalho explícita. Você cura as fontes e direciona a análise. O agente resume, faz referências cruzadas, e arquiva páginas nas pastas entities/, concepts/ e comparisons/, com um catálogo index.md e um log.md só de anexação. Diferente do RAG, que reconstrói uma resposta do zero em cada consulta, a wiki compila o conhecimento uma vez e mantém as referências cruzadas anexadas.

Essa skill é um motivo legítimo para deixar um agente escrever na sua wiki, e não é a mesma coisa que o loop de memória autoaprendiz escrevendo sobre si mesmo. A skill llm-wiki só roda quando você pede para ela ingerir uma fonte ou responder uma pergunta a partir de uma wiki existente. Ela nunca dispara num timer. As três operações que ela oferece (ingest, query, lint) são um bom formato para um corpus de pesquisa que você está construindo ativamente com a ajuda do agente: fontes, páginas de entidade, uma passada de lint para páginas órfãs e links quebrados.

O que vem por padrão, checado contra a v0.21.5

2.200

caracteres, limite do MEMORY.md≈800 tokens, as próprias notas do agente

1.375

caracteres, limite do USER.md≈500 tokens, o que ele salvou sobre você

7

provedores externos de memóriaHoncho, mem0 e mais cinco, um ativo por vez

2

skills de vault embutidasobsidian (filesystem) e llm-wiki (padrão Karpathy)

Rode seu próprio vault de pesquisa através da skill embutida se você quer o agente construindo ele ativamente com você. Rode um vault que você já curou como contexto puro, e a regra muda: mantenha o agente fora do caminho de escrita, e deixe ele só ler.

Se você roda as duas skills contra o mesmo vault, a documentação diz para apontar as duas para o mesmo diretório, em vez de manter duas cópias das suas notas:

Apontar as duas skills de vault para um diretório

1. Skill do Obsidian

   $ echo 'OBSIDIAN_VAULT_PATH=/home/me/vault' >> ~/.hermes/.env

2. Skill do llm-wiki

   $ echo 'WIKI_PATH=/home/me/vault' >> ~/.hermes/.env

Um arquivo de contexto por projeto, e o SOUL.md sempre

Aponte o Hermes para um diretório de projeto e exatamente um arquivo de contexto carrega, o primeiro que bater vence: .hermes.md (ou HERMES.md, percorrido até a raiz do git), depois uma cadeia de AGENTS.md da raiz do git até o working directory, depois CLAUDE.md, depois .cursorrules e .cursor/rules/*.mdc. O SOUL.md, de dentro de HERMES_HOME, carrega de forma independente e sempre, porque esse slot é identidade, não contexto de projeto (agent/prompt_builder.py). Essa é a regra exata que eu uso para decidir o que um vault expõe para um agente trabalhando dentro dele: um AGENTS.md na raiz do vault, ou um .hermes.md se eu quiser que o Hermes especificamente veja algo que os outros runtimes não deveriam.

O que uma pasta de projeto pode entregar ao agente

• seu vault ou repo/// só um destes carrega, o primeiro encontrado vence
  • .hermes.md1º// percorrido até a raiz do git
  • AGENTS.md2º// da raiz do git até o cwd
  • CLAUDE.md3º
  • .cursorrules4º
• ~/.hermes/// independente do projeto, sempre incluído
  • SOUL.mdsempre// identidade, não contexto de projeto

Essa regra de arquivo único é uma feature, não uma limitação. Ela significa que o vault decide, num único lugar, o que um agente vê quando trabalha ali, em vez da resposta depender de qual arquivo um runtime específico prefere por acaso. Isso é context engineering no ponto mais simples possível: um arquivo, uma decisão, tomada uma vez, por você.

Memória do Hermes vs uma wiki que você cura

A memória embutida é pequena de propósito. MEMORY.md e USER.md vivem dentro de ~/.hermes/memories/, injetados no system prompt como um snapshot congelado no início da sessão, e nenhum dos dois faz auto-compactação: uma escrita que passa do limite de caracteres retorna um erro em vez de descartar silenciosamente uma entrada antiga, então o agente precisa consolidar ou remover algo por conta própria antes que o fato novo caiba. Sete provedores externos de memória, Honcho e mem0 entre eles, estendem isso com modelagem de usuário entre sessões ou busca semântica, um ativo por vez junto com os arquivos embutidos. Além disso, toda sessão já rodada é buscável através de full-text search sobre SQLite, com um índice FTS5 e um tokenizer CJK.

Nada disso é uma base de conhecimento. São as notas de trabalho do agente sobre ele mesmo e sobre você, limitadas de propósito para continuarem baratas de injetar em todo turno.

Dois trabalhos diferentes que, por acaso, são os dois markdown

Os dois são arquivos que o Hermes consegue ler. Só um deles é o seu julgamento.

	Memória do Hermes	Uma wiki que você cura
Quem escreve	O agente, sobre ele mesmo e sobre você	Você, com a ajuda do agente quando pedida
Tamanho	Limitada: 2.200 e 1.375 caracteres	Sem limite, dividida em quantas páginas precisar
Quando muda	Em todo turno, via a ferramenta de memória, automaticamente	Quando você ingere uma fonte ou roda uma passada de worklog
Sobrevive a uma troca de modelo	Sim, mas é pequena e autorreferente	Sim, e é a parte que vale a pena manter para sempre

Meu setup: um motor, duas wikis, contexto não memória

Eu rodo uma LLM wiki pessoal e um vault de trabalho separado no mesmo motor, com markdown e git por baixo dos dois, com skills para ingest, captura de worklog, lint e query. Depois de uma reunião, uma passada de worklog extrai decisões e ideias da conversa e arquiva elas no vault. Os agentes leem o vault como contexto. Eles não decidem o que entra nele.

No meu trabalho, um cron job do Hermes escreve meu briefing diário sobre o que está acontecendo na empresa, organizado por um framework de seis sentidos que é meu: o que já funcionou, o que outros estão fazendo, para onde a demanda está indo, o que acabou de ser lançado em outro lugar, o que o pessoal está pedindo, e o que quem depende de mim realmente precisa. Eu detalhei a mecânica em o texto do briefing diário, incluindo o detalhe que torna concreto o argumento inteiro deste artigo: uma execução de cron é uma sessão nova e isolada, sem memória da execução do dia anterior. Ela não acumula nada do jeito que o MEMORY.md acumula. Tudo que ela sabe sobre quem é quem e quais projetos importam, ela precisa pegar lendo o meu segundo cérebro de novo, do zero, toda santa manhã, através do único arquivo de contexto para o qual este texto não para de voltar.

A parte que importa aqui: o job lê meu segundo cérebro só como contexto, e lê o estado em tempo real da empresa através de servidores MCP para Slack, Google Workspace, Git e o issue tracker. Ele nunca escreve uma linha de volta no vault. O vault decide o que o briefing já sabe antes de começar. O briefing nunca pode revisar isso, e a execução de amanhã também não vai lembrar da de hoje.

Por que o agente deveria ler sua wiki, não escrever nela

Aqui está a distinção que vale manter clara, porque a skill embutida llm-wiki realmente deixa um agente escrever numa wiki, e isso não contradiz nada do que foi dito até aqui.

Uma wiki mantida pelo agente

1. 01Você pede para ele ingerir uma fonte, explicitamente, toda vez
2. 02O agente sintetiza, faz referências cruzadas e arquiva páginas
3. 03Bom para um corpus de pesquisa que vocês estão construindo juntos ativamente
4. 04As passadas de ingest e lint da skill llm-wiki mantêm tudo honesto

Um vault só de contexto

1. 01Você cura ele; uma passada de worklog, não o agente de trabalho, atualiza ele
2. 02O agente lê para saber quem é quem, o que importa
3. 03Bom para o julgamento que um job diário não deveria poder revisar
4. 04O arquivo de contexto na raiz do projeto decide o que carrega, não o agente

O erro não é deixar um agente escrever numa wiki. O erro é deixar o mesmo loop sem supervisão que escreve o MEMORY.md sobre si mesmo, em todo turno, sem ser pedido, também decidir o que entra na base de conhecimento onde você colocou o seu julgamento. Uma coisa são notas processuais de si mesmo com um teto de 2.200 caracteres. A outra é a coisa que você realmente quer que ainda seja verdade no ano que vem. Mantenha a fronteira no arquivo de contexto do projeto: um AGENTS.md ou um .hermes.md que o próprio vault já traz, decidindo de uma vez o que qualquer agente vê ali, em vez de confiar numa ferramenta de memória por turno para acertar a linha por acidente.

Definir OBSIDIAN_VAULT_PATH ou WIKI_PATH não impõe nada disso por conta própria. As duas skills são baseadas em filesystem: uma vez que o diretório está definido, write_file e patch funcionam contra ele exatamente como qualquer outro caminho que o agente alcança. A fronteira vive no que você diz a ele, não na env var.

Como falar com um agente sentado em cima de um vault

1. 01

   Diga ingest, não só "usa minhas notas", quando quiser que ele escreva.

   Uma instrução vaga, somada a um modelo que já tem write_file e patch, tende a resolver sendo prestativo: arquivando uma página que ninguém pediu.

   Em vez de

   Só usa minhas notas para contexto.

   Digite isto

   Trate o vault como pano de fundo apenas. Não crie, edite ou anexe a nenhum arquivo ali a menos que eu diga ingest isto, explicitamente.

2. 02

   Diga a um job de leitura apenas para continuar de leitura apenas, além do workdir.

   --workdir decide qual arquivo de contexto carrega. Isso não impede, por conta própria, que ferramentas de arquivo escrevam nesse mesmo diretório se uma instrução disser para elas fazerem isso.

   Digite isto

   Este job é somente leitura. Nunca chame write_file, patch ou skill_manage contra nada dentro deste workdir.

Antes de apontar o Hermes para um vault

• ✓Obrigatório:
  Decida somente leitura vs ingest habilitado antes de definir a env var.OBSIDIAN_VAULT_PATH e WIKI_PATH só apontam para um diretório; nada impede nenhuma das duas skills de escrever lá.
• ✓Obrigatório:
  Coloque a fronteira no arquivo de contexto do projeto, não num prompt.Um AGENTS.md ou .hermes.md na raiz do vault carrega uma vez e decide para toda sessão.
• ✓Obrigatório:
  Mantenha o MEMORY.md só para as notas do próprio agente, nada mais.Ele tem um limite de 2.200 caracteres de propósito. Não lute contra o limite; respeite para que ele serve.
• ✓Obrigatório:
  Deixe uma passada de worklog atualizar o vault, não o agente que consome ele.A superfície que lê o seu contexto e a superfície que escreve nele não deveriam ser o mesmo loop sem supervisão.
• ✓Obrigatório:
  Versione o vault no git de qualquer jeito.Uma wiki que um agente consegue tocar é uma wiki para a qual você quer um diff e um revert.

Hermes Agent, memória e segundo cérebro, respostas rápidas

O Hermes Agent funciona com o Obsidian?+

Sim, através de uma skill embutida chamada obsidian que lê e escreve arquivos do vault direto: notas, busca, wikilinks. Ela conversa com o filesystem, não com um plugin do Obsidian, então funciona com o Obsidian aberto ou fechado.

O que é a skill de llm wiki do Hermes Agent?+

Uma skill embutida baseada no padrão de llm wiki do Andrej Karpathy: uma base de conhecimento persistente em markdown com páginas de entidade, conceito e comparação, um índice e uma passada de lint. Você cura as fontes; o agente sintetiza e faz referências cruzadas quando pedido.

A memória do Hermes Agent é a mesma coisa que um segundo cérebro?+

Não. MEMORY.md e USER.md têm limite de 2.200 e 1.375 caracteres, escritos pelo agente sobre ele mesmo e sobre você, em todo turno, automaticamente.

Um segundo cérebro é uma wiki que você cura, sem teto de tamanho, que o agente lê para contexto e na qual só escreve quando você pede.

Qual arquivo decide o que o Hermes carrega para um projeto?+

Exatamente um: .hermes.md primeiro (percorrido até a raiz do git), depois uma cadeia de AGENTS.md, depois CLAUDE.md, depois .cursorrules. O SOUL.md, de dentro de HERMES_HOME, carrega de forma independente e sempre, como identidade, não como contexto de projeto.

O Claude Code e o Hermes Agent conseguem ler o mesmo vault?+

Sim. Os dois leem markdown puro e os dois resolvem um arquivo de contexto de projeto (AGENTS.md nos dois, entre outros), então um vault que você cura para um funciona para o outro sem converter nada, desde que o arquivo de contexto na raiz dele diga o que cada runtime deveria ver.