Hy Memory 2.0 dá aos agentes três formas de preservar o contexto

A Tencent publicou o hy-memory==2.0.1, um SDK Python para conservar e recuperar o contexto de sessões de conversa, trabalho e programação. O código é público; a aplicação complementar MemHub continua na fase de código-fonte, à espera de artefactos de lançamento públicos. Os programadores que estejam a avaliar uma camada de memória partilhada já podem utilizar o SDK, mas têm de fornecer endpoints de modelos e embeddings e decidir que registos de sessão cada agente pode ler.

O registo de alterações do projeto atribui ao Hy Memory 2.0.1 a data de 16 de outubro de 2026. O PyPI regista o carregamento do pacote em 15 de outubro, e o artigo sobre o modelo associado foi submetido nesse dia. São registos distintos de publicação, e não prova de que o produto para computador tenha sido lançado.

A grande mudança

• O que mudou: O SDK publicado disponibiliza caminhos de memória separados para conversas, trabalho e programação através de add() e search(), com filtros de origem e de espaço de trabalho que a aplicação responsável pela integração pode utilizar.
• Como funciona: O fluxo de conversas organiza diálogos em camadas de memória. O de trabalho extrai de um rasto de ferramentas um facto da sessão e, quando se justifica, experiências reutilizáveis. O de programação acrescenta uma cadeia de versões para as alterações de código. Quem faz a chamada fornece o material de origem, as identidades, a configuração de armazenamento e os serviços de modelos.
• Porque é importante: O sistema que aloja um agente pode recuperar um registo compacto de conversas ou decisões sobre tarefas anteriores, em vez de transmitir todo o histórico a cada nova sessão. A precisão, a autorização e a utilidade desse registo continuam a depender do que o sistema envia e de que memórias permite reinserir no prompt.

Escolha o fluxo antes de integrar

O README do SDK descreve três valores de scene. O chat aceita texto simples ou arrays de mensagens e devolve os canais de recuperação profile, normal e proactive. No modo lite, guarda texto em bruto para pesquisa por embeddings, sem extração por LLM. O pro acrescenta extração e reconciliação; o ultra pode executar uma passagem adicional de evolução através de evolve().

Para working, a entrada tem de conter um rasto de chamadas de ferramentas. Uma sessão produz um facto sobre a tarefa, a abordagem e o resultado, além de zero ou mais experiências reutilizáveis que ultrapassem o limiar de valor do motor. O coding utiliza as mesmas duas camadas e acrescenta uma cadeia de evolução de versões para o código alterado. Segundo o README, a cadeia pode utilizar diferenças locais do Git se MEMORY_CODING_CHAIN_REPO_ROOT estiver definido, ou ações determinísticas de substituição no rasto de ferramentas. No modo lite, o SDK ignora a distinção entre os cenários de trabalho e programação e guarda memória em bruto.

Estas estruturas de saída servem perguntas diferentes. Uma preferência expressa numa conversa pertence a chat; uma tarefa concluída com resultados de ferramentas pertence a working; uma alteração de código cuja revisão anterior possa ser relevante pertence a coding. É uma distinção de encaminhamento documentada, não um teste de desempenho do BIG CHANGE.

Um caminho documentado para utilizar o SDK

A sequência seguinte baseia-se no guia de início rápido do repositório e no guia de configuração do SDK do MemHub. O BIG CHANGE não executou o pacote nem fez chamadas a modelos.

Utilize Python 3.9 ou posterior e instale a versão fixa do SDK:

pip install hy-memory==2.0.1

ChromaDB e Kuzu fazem parte das dependências principais; Qdrant, FAISS, Neo4j, a cache MySQL e um modelo local de reordenação têm extras separados. O ambiente de desenvolvimento do código-fonte do MemHub é diferente: exige Node.js 24, pnpm 11, Python 3.12 e uv.

Configure um endpoint de LLM e outro de embeddings antes de inicializar o cliente. O README lista MEMORY_LLM_API_KEY, MEMORY_LLM_BASE_URL, MEMORY_LLM_MODEL e as variáveis correspondentes MEMORY_EMBEDDER_*, além de MEMORY_EMBEDDING_DIMS; também documenta a utilização por predefinição de OPENAI_API_KEY. Forneça os seus próprios URLs de endpoints, nomes de modelos, chaves e dimensões de embeddings compatíveis. São interfaces compatíveis com OpenAI, não uma exigência de utilizar o modelo separado Hy-Memory-30B da Tencent. Mantenha as credenciais fora dos rastos guardados.

O exemplo de conversa seguinte utiliza as APIs documentadas MemoryConfig.from_env(), HyMemoryClient, add() e search(). A aplicação que faz a chamada tem de fornecer authorized_messages como texto simples ou mensagens no formato OpenAI, um identificador user_id estável e autorizado, além de query. O exemplo mostra o valor devolvido, sem alegar um resultado específico:

from hy_memory import HyMemoryClient, MemoryConfig

def write_and_recall(authorized_messages, user_id, query):
    config = MemoryConfig.from_env()  # Caller supplies LLM and embedding settings.
    client = HyMemoryClient(config=config, mode="pro")
    try:
        client.add(authorized_messages, user_id=user_id)
        return client.search(query, user_ids=[user_id], limit=10)
    finally:
        client.close()

Para trabalho ou programação, transmita um rasto de mensagens que contenha uma chamada de ferramenta ou uma entrada role="tool" e defina scene explicitamente. Defina workspace_id para isolar o material do projeto; branch depende desse valor. Defina source nas escritas e include_sources ou exclude_sources nas pesquisas quando os limites da aplicação que faz a chamada forem importantes. A pesquisa de conversas devolve canais de memória; a pesquisa de trabalho ou programação devolve facts e experiences, com chain_block para programação. Inspecione os registos devolvidos antes de os entregar ao sistema que aloja o agente. As funções list_memories, get, update e delete permitem gerir registos individualmente.

Uma integração bem-sucedida teria um registo guardado a partir de uma entrada autorizada e um resultado de pesquisa com âmbito definido que respondesse à pergunta de recuperação pretendida. O README documenta os campos devolvidos, mas não observámos uma execução que nos permita afirmar que a extração ou a recuperação funcionou. Se uma pesquisa de trabalho ou programação estiver vazia, confirme primeiro que a escrita incluiu resultados de ferramentas e utilizou pro ou ultra; depois, verifique os mesmos valores de user_id, workspace_id, branch e os filtros de origem. Ao alterar o modelo ou as dimensões dos embeddings, o guia de configuração do MemHub avisa que uma coleção existente não pode simplesmente ser reutilizada com uma largura de vetor diferente.

MemHub e o modelo são escolhas separadas

O MemHub é o produto proposto para computador e CLI construído sobre o SDK. O seu README descreve um ambiente de execução local gerido, conectores de origem e integrações com sistemas anfitriões. O seu registo de alterações é mais específico quanto à disponibilidade: existe a versão de código-fonte 1.0.0, build 4, mas a publicação no npm e os artefactos de lançamento no GitHub continuam pendentes. O guia de instalação indica Linux e macOS como plataformas de destino e informa que Windows não é suportado; a sua sequência de instalação via npm depende da publicação desses artefactos. Por agora, trate-a como um caminho de instalação planeado.

Armazenamento local também não significa que todas as etapas de processamento permaneçam locais. O documento de privacidade do MemHub separa a permissão para ler uma fonte de conversa, a permissão para enviar material autorizado a um serviço de modelos de terceiros escolhido e a permissão para o sistema que aloja um agente recuperar memória. Informa que as provas de origem em bruto ficam no diretório de dados local e que, quando um serviço externo de modelos é escolhido, recebe o conteúdo autorizado necessário à tarefa selecionada. Quem integra diretamente o SDK tem de implementar os seus próprios controlos de consentimento de origem, acesso a modelos e recuperação pelo sistema anfitrião; o guia de integração do MemHub explica que a ponte do produto acrescenta essas etapas de governação, em vez de se limitar a chamar o SDK.

A Tencent lançou também o Hy-Memory-30B-A3B, um modelo treinado para escrever memórias, com um relatório técnico submetido em 15 de outubro. O relatório alega uma vantagem sobre os sistemas comparados em subamostras fixas de benchmarks. É uma avaliação do modelo comunicada pelo fornecedor, não uma prova independente de que este SDK ou o MemHub melhorem as respostas de um agente em utilização. O SDK aceita outros serviços de modelos compatíveis.

O atual ficheiro de licença do repositório e os metadados do projeto indicam Apache-2.0. O registo de alterações informa que esta licença foi adotada depois do carregamento de 2.0.1, cujos metadados imutáveis do PyPI continuam a indicar MIT. O pacote pode ser descarregado gratuitamente, mas o serviço de modelos ou embeddings escolhido pode cobrar pelos pedidos; o lançamento não documenta um preço de funcionamento universal. A decisão prática é, portanto, que caminho de memória e que limite de autorização integrar, medindo os custos do fornecedor e a qualidade da recuperação no próprio ambiente do programador.

Fontes e leituras adicionais

• Repositório e início rápido do Hy-Memory — cenários atuais do SDK, exemplos de API, modos, opções de armazenamento e filtros de origem.
• Registo de alterações do lançamento e PyPI 2.0.1 — datas distintas de lançamento do SDK, requisitos do pacote, estado do MemHub e divergência nos metadados de licença.
• README do MemHub, guia de integração do SDK e documento de privacidade — arquitetura do produto na fase de código-fonte, configuração e limites de autorização.
• Guia de instalação do MemHub — plataformas previstas e caminho condicional para os artefactos de lançamento.
• Relatório do Hy-Memory-30B-A3B — preprint e avaliação do modelo comunicada pelos autores; não valida esta integração em utilização real.