Memória Partilhada para Frilas de Agentes: hermes-memory-pgvector
Quando executa mais do que um agente de IA — um minion de marketing, um minion de trading, um minion de resposta a incidentes — cada um precisa de memória. A ferramenta de memória integrada dá a cada agente a sua própria. Isso é suficiente até querer que partilhem, ou até querer recordar o que o agente aprendeu há seis semanas sem pagar uma viagem de ida e volta a um LLM só para procurar.
hermes-memory-pgvector é um plugin pequeno de Postgres + pgvector que replica as escritas de memória dos agentes numa loja partilhada, com embeddings e consultável. Versão atual no PyPI: v1.0.0.
Novidades na v1.0.0 — uma superfície estável
A 1.0.0 declara a superfície pública estável sob versionamento semântico: chaves de configuração, nomes de ferramentas, comandos CLI e códigos de saída, e nomes de tabelas. Chega após uma revisão de pré-lançamento com várias passagens que corrigiu um bug de perda de dados e um conjunto de problemas menores, sem alterações de esquema desde a 0.6.0. Desde a v0.5.0, um simples pip install regista o fornecedor através de um entry point, pelo que o shim de descoberta descrito abaixo só é necessário em hosts mais antigos. Detalhes: hermes-memory-pgvector 1.0: Uma Superfície de Memória Estável.
Novidades na v0.4.2 — instalação nativa via pip
O hermes-agent descobre fornecedores de memória ao analisar diretórios de plugins (plugins/memory/<nome>/ incluído, $HERMES_HOME/plugins/<nome>/ do utilizador) — nunca procura em site-packages, pelo que um pip install isolado deixava o plugin corretamente instalado e completamente invisível. A v0.4.2 colmata essa lacuna: o pip install coloca o código na máquina, e um comando hermes-pgvector install gera o shim de descoberta que a framework efetivamente lê.
Novidades na v0.4.1 — recuperação híbrida (vetorial + texto integral)
recall_memory e recall_conversation fundem agora o ranking de cosseno HNSW com um ranking de texto integral do PostgreSQL usando Reciprocal Rank Fusion (k=60). Uma linha surge se qualquer dos rankers a gostar, o que corrige os dois pontos cegos da pesquisa puramente vetorial: correspondências léxicas exatas que o cosseno esbate (códigos de erro, nomes de hosts, flags, identificadores raros), e linhas só de texto com um embedding NULL — escritas enquanto o endpoint de embeddings estava em baixo — que o índice vetorial não consegue ver de todo. A recuperação híbrida funciona também como recuperação best-effort para essas linhas até à próxima execução de backfill.
O que a v0.4.0 adicionou
Essa versão manteve a regra "sem LLM no caminho crítico" e adicionou quatro capacidades na camada de armazenamento:
- Governação de identidade. As chaves de sessão de mensagens diretas colapsam num único bucket seguro em termos de privacidade — sem dispersão de temas por contacto, sem PII — o tráfego de benchmark é colocado em quarentena, e uma allow-list opcional encaminha nomes de temas com erros ortográficos para um padrão seguro em vez de criar silenciosamente um novo.
- Atribuição e delegação de agentes. Um novo registo e arestas de proveniência registam que agente delegou o quê a quem, consultável através de uma vista de base de dados. Proveniência pura de quem/quando — nunca uma fact store.
- Backfill de embeddings. Linhas escritas apenas como texto durante uma falha do endpoint de embeddings deixam de ficar encalhadas: um comando idempotente volta a aplicar embeddings para que voltem a ser pesquisáveis.
- TTL de conversação e controlos de custo. Um prune executado pelo operador apaga turnos de chat antigos (as memórias duráveis nunca são tocadas), e uma política de embeddings ajusta o custo de embeddings para cima ou para baixo.
Tudo isto é distribuído através de uma CLI de manutenção (hermes-pgvector) cujos comandos destrutivos têm dry-run por defeito. A linha 0.4.x é uma atualização drop-in a partir da v0.3.x — aplique as migrações aditivas e os novos hooks ativam-se; ignore-as e tudo o resto corre inalterado.
O que faz na prática
Numa frase: "uma camada de armazenamento que dá ao modelo de memória integrado um suporte durável, multi-tenant e pesquisável por semântica, sem LLM no caminho crítico."
Duas tabelas, ambas com índices vetoriais HNSW. memory_entries replica escritas nos ficheiros MEMORY.md/USER.md do agente. conversations armazena turnos de chat substanciais (≥40 caracteres, boilerplate filtrado). Os embeddings têm 768 dimensões, calculados por um endpoint externo — Ollama, compatível com OpenAI, à sua escolha. O agente nunca bloqueia à espera: as escritas devolvem em microssegundos e o worker de embeddings trata do resto numa fila em segundo plano.
Temas por agente por defeito
Cada pedido traz um cabeçalho X-Hermes-Session-Key que limita os dados por agent_identity. As notas do marketing não poluem a recuperação do trading. Quando quer efetivamente pesquisa cross-theme, passe scope='all' explicitamente. O padrão é o seguro.
Porque autónomo e não um fork
O hermes-agent fechou a sua lista interna de fornecedores de memória por política, pelo que isto vive como uma análise separada de diretórios /plugins em vez de um fork upstream. Coloque-o ao lado do agente, defina algumas chaves de configuração, reinicie. O rollback é simétrico: desative o fornecedor, opcionalmente elimine as tabelas. Não há estado de longa duração para migrar, nem patches de kernel para manter.
O que não é
Não é um substituto do Honcho. Não é um grafo de conhecimento. Não é uma framework RAG. É, intencionalmente, uma camada fina que faz uma coisa — transformar a ferramenta de memória integrada numa loja partilhada, durável e pesquisável por vetores — e sai do caminho. Sem derivador LLM, sem loop dialético, sem opinião sobre como deve chunk ou rerank. Apenas matemática vetorial.
Obtenha-o
pip install hermes-memory-pgvector
hermes-pgvector install
Código-fonte, migração e configuração no GitHub: