Tipos de memória de agente de IA: faça um teste de saúde para cada um

A resposta útil para “de que tipo de memória de agente de IA eu preciso?” não é “todos eles”. Escolha a menor memória que ultrapasse os limites exigidos pela sua tarefa e, em seguida, aplique a essa memória seu próprio teste de aceitação. Um objetivo atual que deve sobreviver à próxima etapa do gráfico é a memória de trabalho . Um fato que deve permanecer disponível durante as sessões é a memória semântica . Uma tentativa passada que é valiosa por causa do que aconteceu é a memória episódica . Uma regra que muda a forma como o trabalho futuro é executado é a memória processual . Esses quatro trabalhos falham de maneira diferente. Uma verificação genérica “a pesquisa vetorial retornou um resultado” pode perder um ponto de verificação perdido, um fato obsoleto, um episódio sem resultado ou um procedimento não aprovado. O padrão operacional é, portanto: 1. declare o limite que a memória deve cruzar; 2. reter um recibo de escrita e leitura sem conteúdo; 3. verificar escopo, atualidade, procedência e ativação; 4. aplique um invariante específico do tipo; 5. verifique a tarefa externa separadamente. Este artigo transforma a taxonomia comum de tipos de memória de agente de IA nesse contrato testável. Comece com o limite, não com o banco de dados O Arquitetura CoALA separa a memória de trabalho de curto prazo da memória episódica, semântica e processual de longo prazo. Também distingue a recuperação, que lê a memória de longo prazo na memória de trabalho, do raciocínio dentro da memória de trabalho e da aprendizagem que escreve a memória de longo prazo. Essa separação é mais útil operacionalmente do que uma lista de produtos de armazenamento. Uma linha PostgreSQL, um arquivo JSON, um vetor e um ponto de verificação podem implementar mais de um tipo de memória. O armazenamento de dados não informa quais falhas são importantes. Documentação de memória do LangGraph torna concreta a distinção de escopo: o estado de curto prazo é anexado a um thread, enquanto os itens de longo prazo podem residir em namespaces personalizados e threads cruzados. A mesma documentação descreve a memória semântica como fatos, a memória episódica como experiências e a memória processual como regras ou instruções. São contratos diferentes, mesmo quando uma loja detém todos os três. Use uma pergunta para escolher o primeiro limite: O que ainda deve estar disponível, em que âmbito, em que decisão futura? “Lembrar o resultado atual da ferramenta durante esta execução” precisa de um contrato menor do que “lembrar a preferência do cliente no próximo mês”. “Recuperar um incidente semelhante” é mais fraco do que “ativar apenas o procedimento de recuperação aprovado”. Adicionar memória de longo prazo onde o estado de funcionamento seria suficiente cria obrigações extras de retenção, exclusão, privacidade e recuperação. Guia de implementação atual do Redis recomenda começar com as necessidades de curto e longo prazo e adicionar memória especializada quando seu valor operacional justificar a complexidade. Esse é um bom padrão, independentemente de o Redis ser a loja escolhida. Dê a cada tipo de memória um teste de aceitação diferente Os quatro tipos podem partilhar um envelope de provas, mas não devem partilhar a sua regra de veredicto final. Tipo de memória Trabalho Limite para provar Falha específica do tipo Trabalhando Carregue metas ativas, resultados intermediários e dependências A próxima etapa necessária, ponto de verificação ou reinicialização controlada O item foi escrito e lido, mas não ultrapassou o limite de continuidade exigido Semântico Forneça fatos e conceitos atuais O escopo pretendido de locatário, usuário, projeto ou agente entre sessões O fato recuperado está obsoleto, substituído ou está no escopo errado Episódico Reutilize uma experiência passada De uma tentativa registrada a uma decisão posterior que precisa de seu resultado O episódio carece de um resultado observado, então o agente não consegue diferenciar o sucesso da atividade Processual Controle como o trabalho é executado De uma versão aprovada ao prompt ativo, regra, caminho de código ou comportamento do modelo O procedimento ativo não é aprovado, não tem versionamento ou não tem reversão limitada Memória de trabalho: prove continuidade Memória de trabalho não é sinônimo de “tudo o que cabe no contexto do modelo”. CoALA descreve o como as variáveis ​​ativas disponíveis para o ciclo de decisão atual. Em um tempo de execução, esse estado pode ser montado a partir de mensagens, um ponto de verificação de gráfico, metadados de tarefas, resultados de ferramentas ou um registro de estado externo. Teste o com um canário opaco vinculado a um limite obrigatório: escreva o ID da meta ativa e a versão do ponto de verificação; avançar um passo real ou executar a reinicialização controlada, o tempo de execução promete sobreviver; leia o estado no mesmo thread esperado ou execute o escopo; confirme se o ID da meta e a dependência pendente ainda estão disponíveis; comprovar o valor restaurado entrou na próxima decisão. A última verificação é importante. Um ponto de verificação pode conter o canário enquanto o prompt assembly o omite silenciosamente. O armazenamento é verde; comportamento não é. Memória semântica: prove atualidade e escopo A memória semântica armazena fatos em vez de um evento específico. Uma leitura saudável precisa de mais do que semelhança. Retenha o ID da memória opaca, a versão de origem, o hash de escopo, o tempo de gravação, o tempo de leitura e o status de invalidação. Em seguida, verifique se o fato efetivo é atual para o momento da decisão e pertence ao namespace esperado. Uma pontuação de similaridade alta não pode tornar atual um endereço substituído ou uma permissão revogada. A resposta segura a fatos contraditórios geralmente é incerta , e não “escolher o vetor mais próximo”. Resolva a proveniência ou pergunte a um humano antes de permitir que o fato conduza a uma ação irreversível. Memória episódica: prove o resultado Um episódio é útil porque conecta uma situação, uma ação e o que se seguiu. Um log de eventos contendo muitas chamadas de ferramentas não é automaticamente uma memória episódica. Para um agente de resposta a incidentes, um episódio como “tentativa de exportação novamente” está incompleto. O registo útil também indica se o destino recebeu exactamente uma exportação válida, se a nova tentativa esgotou o seu orçamento e se um humano interveio. O recibo sem conteúdo pode manter um ID de episódio, hash de classe de ação, ID de recebimento de resultado, carimbos de data/hora e estado de verificação. Teste a recuperação com um caso conhecido cujo resultado altera a próxima ação correta. Se o episódio for retornado mas o resultado estiver ausente, classifique o como OUTCOMELESS EPISODE . Não deixe que a atividade se disfarce de experiência. Memória processual: prove autoridade A memória processual inclui as regras usadas para executar tarefas. O CoALA inclui procedimentos implícitos nos pesos do modelo e procedimentos explícitos no código do agente; O guia do LangGraph também inclui código, pesos de modelo e prompts nesta categoria. Esta é a memória de maior risco de mudança porque altera o comportamento futuro. Seu recebimento deverá incluir: a versão do procedimento ativo; a versão aprovada; o ator ou política que autorizou a promoção; um conjunto de testes ou referência de avaliação; um tempo de ativação; uma referência de reversão; o escopo em que o procedimento pode ser executado. Se as versões ativas e aprovadas forem diferentes, a integridade da recuperação será irrelevante. O veredicto correto é UNSAFE PROCEDURE , e o próximo passo é uma autoridade ou decisão de liberação – não uma reescrita automática. Use um recibo sem conteúdo O envelope compartilhado abaixo registra evidências operacionais sem armazenar o fato, episódio, prompt ou conteúdo do usuário: Sete verificações formam o caminho comum: 1. Disponível: O subsistema de memória foi observável ou o veredicto é desconhecido? 2. Escrever: A loja pretendida reconheceu a gravação? 3. Leia: Uma decisão posterior recuperou o mesmo item opaco? 4. Escopo: Os identificadores de escopo esperados e observados correspondem? 5. Atualidade: a evidência estava dentro do orçamento de idade declarado? 6. Proveniência: O sistema consegue identificar a origem deste item ou versão? 7. Ativação: o item entrou na decisão pretendida, em vez de simplesmente aparecer nos resultados da pesquisa? Em seguida, aplique a regra específica do tipo: continuidade para memória de trabalho, moeda de origem para memória semântica, ligação de resultados para memória episódica ou aprovação e reversão para memória processual. A ordem evita veredictos enganosos. Por exemplo, uma incompatibilidade de escopo deve interromper a avaliação antes da ativação. Uma leitura perdida não deve ficar “não ativada”, porque a primeira camada com falha é a recuperação. Execute o classificador de nove casos O artefato de publicação inspecionável contém memory health cases.json e classify memory health.mjs . A precedência de decisão é pequena o suficiente para ser reproduzida em qualquer tempo de execução: O dispositivo cobre um caso de memória de trabalho saudável, além de perda de continuidade, dados semânticos obsoletos, violação de escopo, episódio sem resultado, episódio recuperado, mas não ativado, procedimento não aprovado, falha de recuperação e evidência indisponível. Correr: O resultado registrado para este artigo foi: Essa aprovação prova que o classificador segue sua precedência declarada. Isso não prova que um back end de memória ativa está íntegro. Separe a saúde da memória do sucesso da tarefa Um recibo de memória pode provar que um item opaco ultrapassou o limite declarado. Não pode provar que um facto é verdadeiro, que o episódio recordado é o melhor precedente, ou que um procedimento aprovado terá sucesso em todos os ambientes. Mantenha um segundo recibo de resultado determinístico sempre que possível. Um agente de suporte pode recuperar corretamente a preferência de envio atual de um cliente e ainda assim não conseguir atualizar o pedido. Um agente de codificação pode restaurar o objetivo ativo exato após reiniciar e ainda omitir o arquivo solicitado. Um agente de recuperação pode ativar o runbook aprovado e ainda assim produzir um efeito externo duplicado. O estado operacional deve refletir ambos os livros: memória saudável, resultado verificado: elimine o problema relacionado à memória; memória íntegra, resultado ausente: investigue a execução ou verificação de destino; falha na memória, resultado verificado: registre uma dependência degradada; a corrida pode ter sido bem sucedida por meio de reserva; falha na memória, resultado ausente: corrija a primeira camada de memória com falha antes de confiar em uma nova tentativa; evidências indisponíveis: permanecer incerto em vez de fabricar de forma ecológica. Esta separação também limita a recolha de dados. As evidências de saúde podem reter hashes, IDs, versões, carimbos de data/hora, escopos, booleanos e veredictos. Texto imediato, fatos pessoais, conteúdo do episódio, argumentos de ferramentas e segredos não precisam sair do apresentador apenas para mostrar que um contrato foi aprovado. Escolha o menor contrato que pode funcionar Para um novo agente, comece com o resultado e trabalhe de trás para frente: 1. Se a informação for necessária apenas durante o ciclo de decisão atual, mantenha a na memória de trabalho. 2. Se um fato precisar cruzar sessões, adicione memória semântica com regras de origem, escopo, atualização e invalidação. 3. Se uma tentativa passada influenciar uma escolha posterior, adicione memória episódica apenas quando a tentativa tiver um resultado. 4. Se o comportamento em si precisa mudar, trate essa mudança como memória processual e coloque promoção, aprovação, testes e reversão em torno dela. Não adicione um tipo de memória porque um framework oferece uma classe com esse nome. Adicione o quando um limite de tarefa observável exigir. Não chame isso de saudável porque a loja responde. Chame o de saudável quando a evidência correta foi escrita, recuperada no escopo correto, ainda atual, ativada na decisão pretendida e passada a invariante específica para aquele tipo. A Sidewisp está atualmente em prévia privada. Seu modelo de integridade pretendido inclui leituras ou gravações de memória ausentes, persistência com falha, sincronização obsoleta e decisões perdidas, mas a coleta de integridade do agente de produção e os adaptadores de tempo de execução não são enviados hoje. O recibo deste artigo é um design que você pode executar localmente agora; não é uma afirmação de que Sidewisp atualmente monitora ou repara seus agentes.