Plugin de memória OpenClaw: Escolha com um portão de cinco testes

O padrão mais seguro é não instalar o plugin de memória OpenClaw mais capaz. Comece com o back-end, escreva o requisito que não pode cumprir e vá apenas quando um candidato passar por cinco testes: persistência, recuperação, privacidade, comportamento de falha e recuperação. Essa regra produz escolhas diferentes para problemas diferentes. Use o motor de construção para uma pequena memória local Markdown. Considere o QMD quando um grande corpo local precisa de re-ranqueamento ou diretórios mais indexados. Considere o memory-lancedb quando a captura automática e o recall vetorial justificam uma dependência de banco de dados nativa. Considere o Honcho quando a modelagem automática do usuário e a memória com serviço de sessão cruzada são o requisito real. Trate o memory-wiki como uma camada de conhecimento de companhia, não como um substituto do backend da memória ativa. Este artigo utiliza o contrato de documentação OpenClaw 2026.7.1-2 e um dispositivo de seleção executável. Não alega que a fixação seja de referência para a qualidade da recuperação. O ponto é mais estreito: rejeitar uma arquitetura cujos limites operacionais não se pode verificar antes de possuir memória duradoura. Decida primeiro qual é a camada que está a substituir. O plugin de memória esconde duas decisões diferentes. O backend da memória ativa possui memória. OpenClaw visão geral da memória diz que memory search e memory get vêm do plugin de memória ativa, com memory-core como padrão. Só um plugin possui esse espaço de memória ativa de cada vez. A alteração do slot altera a dependência do tempo de execução. Uma camada companheira adiciona outra representação sem tomar esse espaço. O memória-wiki em conjunto compila alegações, evidências, proveniência, painéis de controle e páginas wiki ao lado do backend ativo. Lembrar, indexar, promover e sonhar permanecem com o plugin de memória ativa. Instalar-se para "melhorar a pesquisa" é, portanto, uma decisão errada se o verdadeiro requisito é um motor de recuperação de substituição. As escolhas documentadas têm limites materialmente diferentes: - O Builtin armazena um índice SQLite por agente sobre o MEMORY.md e o memory/ .md . Ele suporta pesquisa de palavras-chave, vetores e híbridos. O Documentação do motor de construção diz que a pesquisa de palavras-chave permanece disponível quando nenhum provedor de incorporação é configurado. É a linha de base porque não adiciona nenhum sidecar ou serviço separado. - O QMD é um sidecar local-primeiro com BM25, pesquisa de vetores, re-ranking, expansão de consulta e diretórios extras. O Documentação QMD também documenta a queda para o motor de construção se o QMD falhar completamente. Este retrocesso é uma vantagem operacional concreta, não apenas outra característica. - memory-lancedb é um plugin externo que possui o slot de memória. O seu Documentação oficial descreve o recall automático, a captura automática opcional, uma dependência de incorporação, propriedade por agente e um pacote nativo @lancedb/lancedb . A mesma página observa uma limitação de plataforma para Intel macOS e não promete um retrocesso automático de backend. - Honcho persiste conversas para um serviço dedicado e constrói modelos de usuário e agente. O Documentação de integração de Honcho suporta operação gerenciada ou auto-hospedada e diz que a memória local Markdown pode permanecer ao lado dele. O serviço, o seu limite de retenção e a sua disponibilidade tornam-se parte da saúde da memória. - memory-wiki é para síntese rica em origem e páginas de conhecimento mantidas. É uma boa resposta para Como mantemos as reivindicações e as fontes inspecionáveis? Não é a resposta para Qual backend ativo deve ter o recall? No hospedeiro de ensaio, o openclaw --version notificou o 2026.7.1-2 . O openclaw plugins list --json mostrou o memory-core enrolado e carregado, o memory-wiki enrolado, mas desativado, e nem o LanceDB nem o Honcho instalados. Essa observação não é uma recomendação universal. Ele ilustra por que a seleção deve começar com o inventário atual em vez de uma captura de tela do mercado. Fazer cinco testes com casos deliberadamente inconvenientes Uma instalação bem-sucedida só prova que um comando foi concluído. Não prova que a memória necessária tenha sobrevivido, possa ser encontrada, mantida privada, degrada-se com segurança ou possa ser restaurada. 1. Persistência: nome do proprietário duradouro Crie um fato sintético com uma identificação única de canário num agente de ensaio descartável. Registre onde a fonte da verdade mora, onde o índice mora e se um plugin armazena uma segunda cópia. Reinicie o Gateway, reconstruir o índice se o backend o exigir e recuperar o canário. Um passe precisa de todos os três fatos: - O registo de origem ainda existe; - O backend ativo relata um índice ou conexão saudável; - O canário é recuperável após a reinicialização. Não use uma credencial real, nome de cliente ou conversa privada como canário. Um resultado que apenas ainda está presente no contexto atual não prova nada de persistência. 2. Recuperação: falhas de medida, nenhum sucesso Construa um pequeno dispositivo com identidades exatas, decisões parafraseadas, duas revisões conflitantes e um item que não deve coincidir. Teste a pesquisa exata, a pesquisa semântica, a recência, o tratamento de contradições e a eliminação. Registre o caminho de fonte esperado ou o ID antes de executar a consulta. O padrão razoável é a aceitação determinista: cada item necessário é encontrado, a revisão obsoleta não supera a atual e o controle negativo permanece ausente. Uma consulta de demonstração com uma resposta plausível não pode distinguir a recuperação de coincidência. 3. Privacidade: provar o predito de isolamento Use dois agentes descartáveis e dois canários. Cada agente deve recuperar o seu próprio canário e não recuperar o outro. Então, inspecione o que sai do hospedeiro: - Que texto está incorporado; - Se um serviço hospedado recebe mensagens brutas ou observações derivadas; - onde existem credenciais da API; - Se a exclusão remover as cópias de origem, índice e serviço; - Se os registos incluem conteúdo de memória. A documentação do LanceDB descreve explicitamente um predicado de proprietário aplicado antes da classificação de vetores. Honcho muda deliberadamente as conversas para um serviço dedicado, a menos que seja auto-anfitrião. São limites diferentes de confiança. Nenhum deles deve ser inserido numa caixa de verificação genérica suporta privacidade. 4. Falha: interrupção da dependência Colocar o fornecedor de integração indisponível, remover o sidecar do PATH num ambiente de ensaio ou bloquear o ponto final de serviço. Então, pergunte-lhes, a quem se sabe a resposta. O resultado necessário não é necessariamente uma resposta correta. É um estado honesto: disponível através de um fallback documentado, indisponível com um erro útil, ou degradado de uma forma que o operador pode ver. Returnar um resultado vazio como se nenhuma memória existisse é um falho falso. As fronteiras documentadas são importantes aqui. A pesquisa integrada pode reter a pesquisa de palavras-chave sem incorporações. A QMD pode voltar a ser construída. Uma carga nativa ou falha de inserção do LanceDB precisa de sua própria manipulação. Um plug-in com suporte de serviço adiciona a disponibilidade de rede e serviço ao envelope de saúde. 5. Recuperação: restauração, reindexação e verificação Tome uma foto verificada antes da migração. Após o teste de falha, restabeleça-o em um ambiente descartável, reconstrua qualquer índice derivado e reinicie o dispositivo de recuperação. A recuperação só ocorre quando os itens esperados, a propriedade, o estado de exclusão e a revisão atual concordarem. As sondas úteis de somente leitura dependem do caminho selecionado: O QMD deve revelar se o sidecar está pronto ou se o retrocesso está ativo. LanceDB adiciona openclaw ltm stats . Honcho adiciona openclaw honcho status . Memória Wiki adiciona openclaw wiki doctor e openclaw wiki status . Realizar a sonda relevante após a recuperação; não deduzir a saúde apenas pela disponibilidade do processo. O que o portão executável realmente selecionou O equipamento acompanhado codificou as capacidades documentadas como requisitos difíceis, depois avaliou cinco perfis. O resultado foi: A saída é útil porque cada escolha também carrega uma declaração de retrocesso e uma sonda de recuperação. Não é intencionalmente um cartão de pontuação. Adicionar pontos para cada recurso faria com que o candidato mais complexo ganhasse, mesmo quando o leitor precisa apenas de um local durável Markdown. A fixação também expõe um limite importante. O memory-wiki ganha o perfil de proveniência, mas permanece fora da faixa de retrocesso ativo. Honcho ganha a modelagem automática do usuário, mas introduz um limite de serviço. O LanceDB ganha a captura de vetores locais automática, mas introduz dependências de incorporação e pacotes nativos. A QMD ganha o grande perfil local do corpo porque é necessária uma nova classificação. A Builtin ganha o default porque nenhum desses requisitos extras existe. Você pode reproduzir a regra sem confiar na conclusão: 1. Lista o requisito em termos observáveis. 2. Marque as restrições de privacidade e plataforma não negociáveis. 3. Rejeita candidatos que não possam satisfazer todas as restrições duras. 4. Preferimos o candidato sobrevivente com a menor superfície de falha. 5. Faça os cinco testes com dados descartáveis antes da migração. É também aqui que as páginas de recursos deixam de ser evidências suficientes. A fixação é baseada na documentação atual, e não num índice de referência de recuperação compartilhado. Se dois candidatos sobreviverem, teste os dois contra o seu corpus, consultas, orçamento de latência e modos de falha. O desconhecido permanece desconhecido. Mantenha o retrocesso disponível até que o novo caminho se prove Uma migração de memória não é completa quando os registros são copiados. Ele é completo quando o novo backend recupera a decisão correta atual após a reinicialização, mantém os limites do agente intactos, expõe falhas e pode ser retrocedido sem perder gravações. Usar um corte em fase: - congelar o aparelho, e não toda a memória de produção; - tomar uma imagem instantânea do conteúdo e gravar o seu hash; - população do candidato num agente isolado; - Realizar os cinco testes; - consultas representativas de sombra contra caminhos antigos e novos; - Classificar os desentendimentos antes de trocar o espaço ativo; - manter intacta a fonte anterior através de uma janela de estabilidade; - remover o caminho de retorno somente após o teste de restauração. A captura automática merece uma cautela especial. Pode reduzir as notas perdidas, mas também altera o limite de ingestão. Teste se os metadados de transporte, o contexto injetado, os segredos e os duplicados são rejeitados. Confirme quais tipos de mensagens se qualificam, como funciona a eliminação e se uma captura falhada é visível. A conveniência não substitui a proveniência. O mesmo princípio aplica-se ao retrocesso. A falha documentada do QMD preserva um caminho de pesquisa, mas a qualidade do resultado e a cobertura do corpo podem mudar. Esse é um estado degradado, não um verde automático. Se o backend selecionado não tiver fallback documentado, torne explícita a indisponibilidade e mantenha um rollback testado. Use uma regra de liberação, não um plugin favorito Escolha a menor arquitetura que satisfaça o requisito e passe nos cinco testes. Migração de bloco quando o proprietário duradouro não está claro, uma recuperação requerida é omitida, o isolamento entre agentes falha, uma interrupção parece que nenhuma memória encontrada, ou o instantâneo não pode ser restaurado. Essa regra resolve a questão original: - Fique em pé para o caso local comum. - Adicionar QMD para escala local de corpus, re-ranqueamento ou caminhos extras. - Escolha LanceDB apenas quando a memória vetorial automática valha a pena a sua incorporação e dependência nativa. - Escolha o Honcho quando a modelagem de usuários entre sessões apoiada pelo serviço é o objetivo e seu limite de dados é aceitável. - Adicione a memória-wiki quando for necessária uma compilação de conhecimento rica em proveniência; não confundir com o backend ativo. A Sidewisp está atualmente em prévia privada. Atualmente não inspeciona, seleciona, migra ou recupera os fundos de memória OpenClaw. Sua direção de produto é tornar visíveis evidências de saúde do agente, incerteza e limites de recuperação seguros; o portal de cinco testes acima é um método que você pode usar hoje sem afirmar que a capacidade é enviada.