Memória OpenClaw: Verifique a Escreva, Índice, Pesquisa e Reinicialização

A memória OpenClaw só é saudável quando quatro alegações diferentes são verdadeiras: o registro pretendido foi escrito para armazenamento duradouro, o índice atual cobre o que escreve, a recuperação retorna a âncora fonte certa e uma sessão nova ainda aplica a decisão corretamente. Um arquivo Markdown no disco prova apenas a primeira alegação. Uma pesquisa bem sucedida prova apenas que algumas peças indexadas coincidem. Use uma auditoria de conteúdo minimizado que mantém o texto de memória no host. Registre IDs opacos, resultados de comparação locais, timestamps e ancoragens de fonte; não exporte instruções, conteúdo de notas, caminhos absolutos ou fragmentos de pesquisa em bruto. O operador deve ser capaz de distinguir uma escrita faltante, índice obsoleto, recuperação errada e decisão perdida em vez de desmoronar os quatro em memória quebrada. Tratar a memória OpenClaw como quatro provas separadas O OpenClaw visão geral da memória atual descreve a memória como um simples Markdown no espaço de trabalho do agente. O MEMORY.md é a camada curada a longo prazo, enquanto os arquivos datados sob o memory/ mantêm um contexto diário detalhado. O modelo lembra o que chega ao disco; não há estado durável oculto que salve uma escrita omitida. Esse projeto cria pontos de inspecção úteis: 1. Escreva prova: o arquivo esperado existe e seu conteúdo local corresponde à versão que deveria persistir. 2. Index proof: o backend da memória indexou o snapshot da fonte atual em vez de um anterior. 3. Retrieval proof: uma consulta retorna o arquivo esperado e o intervalo de linhas, não apenas uma frase plausível de outro lugar. 4. Prova de decisão: Após um limite de sessão real, o agente segue a decisão salvada e seu limite de ação. Estas provas falham independentemente. Uma nota pode existir enquanto o índice permanece sujo. O índice pode ser atual enquanto uma consulta cai abaixo da pontuação configurada. A recuperação pode encontrar a passagem correta enquanto uma nova sessão ignora a sua condição de expiração ou o proprietário. Por outro lado, uma sessão pode responder corretamente porque o mesmo fato ainda existe no contexto da conversa, mesmo que a escrita duradoura nunca tenha acontecido. O incumprimento razoável é, portanto, um veredicto em fase. Parem na primeira camada falhada e reparem apenas essa camada. Não reescreva a memória quando o índice estiver obsoleto, e não reconstruia um índice quando o registro nunca foi persistido. Prova a escrita sem exportar a memória Dê a cada registro sensível à ação uma identificação opaca, como decision 7f3b , além dos campos necessários para agir com segurança mais tarde: proprietário, estado efetivo, condição de expiração ou desbloqueio e ação proibida. A identificação não é um segredo e não revela a decisão. Na fonte, calcular se o registro atual corresponde à versão local esperada. Exportar apenas a comparação: Não envie um resumo crudo de uma nota curta ou sensível a um serviço de saúde remoto. O texto de baixa entropia pode ser adivinhado e hashado. Mantenha a digestão no hospedeiro, use um HMAC teclado quando uma impressão digital estável deve deixar o limite do processo, ou relate apenas a comparação booleana e um ID de registro opaco. Um sistema de arquivos escrever retornando sucesso não é suficiente. Leia o registro do arquivo durável, e depois compare os bytes que foram realmente armazenados. Se a escrita é esperada para sobreviver a uma reinicialização do host, confirme que o local de armazenamento é persistente para essa implantação; um espaço de trabalho local de contêiner pode desaparecer mesmo que a chamada de escrita tenha sido bem sucedida. A mesma regra aplica se ao truncamento MEMORY.md . O OpenClaw mantém um arquivo de grande tamanho intacto enquanto a cópia injetada no contexto do bootstrap pode ser truncada. A presença do arquivo ainda passa, mas a prova de decisão pode falhar porque a entrada necessária não chegou à nova sessão. A visão geral da memória recomenda verificar os detalhes do contexto ou a saída do médico quando estão envolvidos limites de bootstrap. Prove a frescura do índice antes de confiar na recuperação OpenClaws documentação de busca de memória explica que o backend incorporado pode combinar semelhança vetorial com a correspondência de palavras chave BM25. Também documenta a sincronização automática no início da sessão, na pesquisa e através de um monitor de arquivos. Esses mecanismos reduzem as janelas obsoletas; não tornam a frescura inobservável. Comece com o status: A sonda deep verifica o provedor de incorporação e o caminho de pesquisa semântica, para que possa fazer uma chamada ao provedor. Inspectar pelo menos: se a loja está suja; Número de arquivos indexados e de peças; fornecedor e modelo selecionados; Disponibilidade de FTS; Disponibilidade de armazenamento de vetores e de pesquisa semântica; problemas de digitalização e identidade de índice. No caso do OpenClaw 2026.7.1 2 , uma sonda ao vivo de somente leitura durante esta investigação relatou uma identidade de índice integrada válida e caminhos léxicos e semânticos disponíveis, mas também o dirty: true . Essa combinação é importante: uma sonda de inserção em funcionamento não prova que a nota mais recente seja indexada. Quando a fonte estiver correta mas a loja estiver suja, execute uma sincronização incremental com: Reservar uma reconstrução forçada para uma identidade inválida, mudança de configuração de fragmentação ou incorporação, corrupção ou sincronização incremental que não pode convergir: O Memória OpenClaw Memória CLI referência distingue estas operações: o status index reindexa quando sujo, enquanto o index force realiza uma reconstrução completa. Tratar uma interrupção do fornecedor como search unavailable , não como uma memória vazia. O comportamento documentado é deliberadamente explícito quando um fornecedor de incorporação configurado falha; não deve tornar se silenciosamente prova de que não existe registro relevante. Cruzar o limite de reinicialização com uma sonda de decisão Procure uma chave de recuperação opaca que seja exclusiva do registo de ensaio, e, em seguida, precise um resultado ancorado: Uma prova de recuperação de passagem contém o tipo de fonte esperado, a referência de arquivo e o intervalo de linhas. Não passe porque o texto do resultado soa certo. A pesquisa híbrida pode retornar notas semânticamente relacionadas, e entradas diárias repetidas podem colocar uma versão mais antiga acima da decisão atual. Agora atravessem um limite de sessão genuíno. Uma segunda solicitação na mesma conversa não é um teste de reinicialização porque a instrução original pode ainda estar no contexto. Inicie uma nova sessão através do mecanismo normal da sessão runtime, peça uma sonda de decisão limitada e compare o comportamento com o contrato guardado. Por exemplo, se a nota duradoura diz que uma migração permanece apenas de projeto até a aprovação A 42 , a sonda deve perguntar se a implementação pode começar agora. O resultado esperado é um código de decisão, como o WAIT FOR A 42 , e não uma citação literal da nota privada. Registo: Isto testa a continuidade útil em vez de teatro de recordação. Um modelo pode parafrasear uma nota ao mesmo tempo em que deixa cair o limite de autoridade que a torna segura. Também pode produzir a decisão certa acidentalmente. Mantém a sonda estreita, repita a após alterações de configuração relevantes e inclua um caso negativo cuja condição de desbloqueio não tenha sido cumprida. Reproduzir uma auditoria de nove casos sem conteúdo O dispositivo memory health cases.json que acompanha não contém texto de memória. Fornece nove observações sintéticas ao evaluate openclaw memory health.mjs , uma para cada estado terminal: O resumo reproduzido é o seguinte: O classificador usa uma ordem rigorosa. Verifica a existência duradoura e a igualdade local antes do estado do índice; o estado do índice antes da disponibilidade da pesquisa; a disponibilidade da pesquisa antes da recuperação; e a recuperação antes de uma decisão de nova sessão. Isto evita reparações enganosas. A reindexação não pode criar um registro faltante. Reescrever um registro não pode restaurar um fornecedor de inserção falhado. Um golpe de alta pontuação não pode provar a continuidade de reiniciação. Adaptar a fixação com IDs opacos reais e booleanos locais. Adicione casos para um espaço de trabalho apenas para leitura, um índice construído a partir de um digesto antigo, um resultado da nota com data errada, um arquivo de arranque truncado, um fornecedor de incorporação indisponível, um fallback apenas para palavras chave e uma decisão cuja aprovação expirou. Mantenha a nota bruta e o resultado da pesquisa bruto fora da telemetria compartilhada. Use um estado desconhecido explícito A regra de funcionamento compacta é: A memória de marca OpenClaw só é verificada quando o registro duradouro corresponde localmente, o índice atual o cobre, a recuperação se ancora à fonte esperada e uma nova sessão produz a decisão limitada esperada. Tudo o resto deve manter um estado não verde específico. O search unavailable não é o retrieval miss . O restart unverified não é o continuity failed . Um desconhecido explícito é mais útil do que um status vermelho genérico porque identifica o próximo teste seguro sem convidar o agente a inventar o contexto faltante. Esta auditoria ainda tem limites. Uma comparação local só pode validar registros incluídos no conjunto de ensaio. Um anfitrião comprometido pode falsificar a nota e as provas. Uma sonda de recuperação mede uma consulta e uma configuração de classificação. Um código de decisão correspondente não prova que todas as nuances sobreviveram, e as sondas repetidas consomem modelo e orçamento de incorporação. Use verificações deterministas para armazenamento e indexação, em seguida, gaste chamadas de modelo apenas no comportamento que não pode ser verificado a partir de arquivos e estado de banco de dados. A Sidewisp está atualmente em prévia privada. Pretende se fornecer uma camada de saúde em torno dos tempos de execução dos agentes existentes, mas os adaptadores OpenClaw de produção, a coleta de agentes vivos saúde e a recuperação automática não são enviados no repositório atual do site. A auditoria de quatro provas é um padrão executado pelo operador que você pode implementar agora, não uma alegação de que o Sidewisp atualmente monitora ou repara a memória OpenClaw. Se esta separação entre armazenamento, recuperação e saúde de decisão coincidir com a forma como você deseja operar agentes, junte se à pré visualização privada Sidewisp. Até então, mantenha a comparação local, torne a reinicialização real e deixe que a evidência faltante permaneça desconhecida.