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.