SO de memória do agente AI: audite cada transição de nível

Um sistema operacional de memória para um agente de IA é íntegro somente quando o operador pode seguir uma versão de memória por meio de armazenamento, atualização, recuperação e geração sob o mesmo escopo de usuário e assistente. Uma resposta coerente é um resultado útil, mas não é evidência de que todas as transições anteriores tenham sido cometidas. O padrão prático é, portanto, simples: anexar um recibo de linhagem sem conteúdo a cada fronteira. Mantenha o conteúdo da memória no host. Registre apenas identificadores estáveis, escopo, versão de origem, nível de destino, carimbos de data/hora, status de transição e a versão usada para geração. Se um limite estiver faltando ou for contraditório, informe waiting , at risk , stale ou uncertain em vez de verde. Essa regra é importante para a arquitetura específica por trás da consulta de pesquisa memory os of ai agent . O documento MemoryOS define três níveis de armazenamento e quatro módulos funcionais. Sua implementação também expõe uma janela estreita de falhas que um benchmark de qualidade de resposta não consegue identificar. O que o MemoryOS estabelece O Papel MemoryOS descreve quatro módulos: 1. Armazenamento organiza a memória de curto prazo (STM), a memória de médio prazo (MTM) e a memória pessoal de longo prazo (LPM). 2. Atualização move as páginas de diálogo do STM para o MTM e, em seguida, deriva um perfil de maior duração ou material de conhecimento do MTM. 3. Recuperação seleciona material relevante das camadas. 4. Geração cria uma resposta a partir do contexto atual e recuperado. O artigo é extraordinariamente concreto sobre o movimento entre níveis. A atualização STM para MTM usa um processo FIFO de cadeia de diálogo. A atualização MTM para LPM usa páginas segmentadas com seleção baseada em calor. Isso é estrutura suficiente para definir limites de transição observáveis, em vez de tratar a “memória” como um banco de dados opaco. Os autores relatam melhorias médias de 49,11% em F1 e 46,18% em BLEU 1 em relação às suas linhas de base no LoCoMo com GPT 4o mini. Esses são os resultados de referência dos autores; Não executei novamente o LoCoMo para esta auditoria. Mais importante ainda, a correção e a coerência das respostas respondem a uma questão diferente da integridade operacional. Uma pontuação alta não prova que: um registo STM estava presente de forma duradoura antes do despejo; um destino MTM confirmado antes do desaparecimento da fonte; o mesmo escopo de usuário e assistente sobreviveu a cada transição; a recuperação retornou a versão mais recente esperada; a geração final na verdade dependia dessa versão. A arquitetura do artigo fornece os limites. A operadora ainda precisa de recibos para eles. O intervalo de risco aparece antes do commit de destino Inspecionei o projeto no commit fixado 587ed7755c7aed179965792830ff1b5ad9a6fa92 . A fixação é importante: o repositório está ativo e uma conclusão operacional sem uma versão fonte se tornará ambígua após a próxima alteração. O caminho add memory atual verifica se o deque de curto prazo está cheio e executa a promoção antes de anexar outro item. A fonte rotula isso explicitamente como uma correção para evitar o despejo automático de deque silencioso ( memoryos.py , linhas 226–244). Esta é uma salvaguarda útil, mas não torna a promoção transacional. A sequência da promoção é importante: 1. process short term to mid term chama pop oldest enquanto o STM está cheio ( updater.py , linhas 100–105). 2. pop oldest remove o registro e salva imediatamente o deque STM mais curto ( short term.py , linhas 33–37). 3. O atualizador então chama funções de continuidade e resumo apoiadas por LLM. 4. A inserção do MTM e seu salvamento final ocorrem posteriormente ( updater.py , linhas 130–207). Esse fluxo de controle cria um intervalo de origem em risco. Se o processo for encerrado ou uma operação downstream não capturada falhar após o salvamento do STM, mas antes do commit do MTM, o operador não terá nenhuma prova de promoção concluída. Esta é uma janela de falha derivada da fonte, não uma afirmação de que toda implantação do MemoryOS perde dados. O estado de saúde correto é simplesmente não verde até que o recibo de destino exista ou a origem seja mostrada como recuperável. Existe um segundo limite de continuidade mais estreito. last evicted page for continuity inicia como um valor None na memória, é transportado para o próximo lote e atualizado após o processamento ( updater.py , linhas 35 e 115–158). Uma reinicialização do processo redefine essa dica de transferência específica. Outras lógicas de similaridade MTM ainda podem reconectar o material, portanto isso não é prova de perda total de continuidade. É um motivo para registrar a página anterior ou a versão fonte no recibo de transição, em vez de presumir que o processo a lembrou. Use um recibo sem conteúdo em todas as camadas O recibo não precisa de instruções, respostas, resumos, incorporações ou fatos pessoais. Um evento mínimo pode ser assim: Leve seis campos em cada estágio: runId junta se a uma tentativa de armazenamento até geração sem revelar conteúdo. userScope e assistantScope detectam erros entre locatários ou assistentes compartilhados. version identifica o estado de memória esperado. sourceVersion fixa o contrato de implementação ou adaptador. status separa started , waiting , committed , verified e falha no trabalho. atUtc permite que o verificador expire evidências obsoletas. O MemoryOS já cria arquivos de curto, médio e longo prazo específicos do usuário e um arquivo separado de longo prazo específico do assistente ( memoryos.py , linhas 71–78). O recibo deve preservar ambas as dimensões porque “usuário correto, assistente compartilhado errado” ainda é um conflito de escopo. Para geração, adicione dependsOnVersion e um outcomeReceipt . dependsOnVersion informa qual versão da memória recuperada entrou no prompt final. outcomeReceipt deve identificar uma verificação de resultado determinística sempre que possível: um hash de arquivo, identificador de linha, resultado de teste, pesquisa de destino ou outra prova de que o trabalho pretendido existe. Não deve ser uma mistura de conteúdo de conversa sensível apenas para fazer o registro parecer rigoroso. Repetir estados inconvenientes antes de confiar no verde Eu construí e executei um acessório de oito caixas sem conteúdo. O classificador retornou todos os oito estados esperados: Caso Evidência Estado Linhagem completa Escopo, versão, atualização, confirmações de nível, recuperação e acordo de recebimento de geração healthy Limite de capacidade não atingido STM é durável e a janela de espera declarada está aberta waiting STM removido, MTM não confirmado Fonte desapareceu antes da prova de destino source at risk STM mantido, sem evento de promoção A transição MTM esperada nunca apareceu promotion missing Mudanças de usuário durante a promoção Um evento pertence a um escopo diferente scope conflict A recuperação retorna v21 , esperado v22 Existe uma memória real, mas está obsoleta stale retrieval Resposta fluente, sem recebimento de dependência Geração concluída sem linhagem verificada generation unverified Nenhuma versão de implementação As evidências não podem ser interpretadas com segurança uncertain A distinção importante é entre espera e ausência . Um registro STM que permaneça durável enquanto um limite de capacidade documentado não for atingido não será bloqueado. Uma origem removida sem confirmação de destino não está aguardando; está em risco. Os campos timestamp e source presence tornam essa diferença inspecionável. Use precedência explícita para que um sucesso posterior não possa ocultar um conflito anterior: Esta ordem é deliberadamente conservadora. O conflito de escopo supera uma resposta bem sucedida. O risco de origem supera a atividade posterior. Uma recuperação obsoleta não é resgatada pela geração fluente. As evidências faltantes permanecem incertas em vez de serem convertidas em saudáveis. Transforme o recibo em um portão operacional Comece com uma memória canário que não contenha conteúdo pessoal ou de produção. Dê a ele um identificador aleatório e uma versão esperada e, em seguida, exercite o caminho real de armazenamento, promoção, recuperação e geração. Antes da adoção ou após uma atualização do sistema de memória: 1. Fixar a implementação. Registre a versão do pacote ou commit do repositório e a configuração que altera os limites de capacidade, calor, similaridade ou recuperação. 2. Prove o isolamento do escopo. Execute dois escopos de usuário e, se aplicável, dois escopos de assistente. Cruze cada consulta deliberadamente e não exija recuperação na via errada. 3. Forçar transições de capacidade. Preencha o STM até o limite configurado. Verifique se cada remoção de origem possui um commit MTM correspondente. 4. Exercite o substituto. O atualizador tem um substituto de resumo geral quando a saída de vários resumos não está disponível. Rotule esse caminho como degradado e verifique a recuperação separadamente, em vez de tratar a conclusão do fallback como qualidade normal. 5. Reiniciar entre lotes. Verifique a continuidade após o reinício do processo porque a transferência na memória não é uma evidência durável. 6. Recibos expirados. Uma promoção que estava íntegra ontem não estabelece que o processo, índice ou arquivos atuais estão íntegros agora. 7. Verifique o resultado. O sucesso da recuperação indica que uma memória foi retornada. Não diz que o agente usou a versão correta ou concluiu a tarefa pretendida. Não tente novamente automaticamente uma promoção de origem em risco se a atualização já tiver sido parcialmente confirmada. Primeiro reconcilie origem e destino por runId e versão. A repetição cega pode transformar a incerteza em páginas duplicadas ou fatos conflitantes de longo prazo. A limitação é igualmente importante: este recibo comprova verificações de linhagem de transição, escopo, atualização e resultados determinísticos. Isso não prova que um resumo de autoria do LLM seja semanticamente correto. Isso requer uma avaliação separada, uma revisão humana de fatos pessoais de alto impacto ou uma comparação determinística específica da tarefa. O limite de saúde do Sidewisp Esta auditoria se ajusta ao modelo de memória e integridade de contexto do Sidewisp: leituras ou gravações ausentes, persistência com falha, sincronização obsoleta, redefinições inesperadas e decisões perdidas devem ser visíveis em vez de inferidas de um processo verde. A Sidewisp está atualmente em prévia privada. Seu site público e sistema de artigos estão ativos, enquanto a coleta de integridade do agente de produção, os adaptadores de tempo de execução e a execução de recuperação geralmente não são enviados. O recibo acima é um padrão de operador que você pode implementar agora; não é uma afirmação de que o Sidewisp monitore atualmente o MemoryOS. A regra resolvida é estrita, mas utilizável: confiar no sistema de memória somente quando a mesma versão com escopo definido for armazenada, promovida, recuperada, usada e verificada de forma durável. Uma resposta fluente pode ser encorajadora. Não pode substituir o recibo faltante.