Memória do agente Pydantic AI: histórico de auditoria antes da reprodução

A memória do agente Pydantic AI está pronta para reprodução somente quando seis verificações independentes passam: as mensagens passam de ida e volta pelo serializador compatível, o histórico vem de uma fonte autorizada do lado do servidor, o prompt do sistema necessário sobreviveu, as chamadas de ferramenta e os resultados permanecem operacionalmente honestos, cada mensagem pertence à conversa pretendida e o aplicativo tem um recibo para o resultado esperado. Uma carga JSON válida comprova apenas a primeira verificação. Essa distinção é importante porque o Pydantic AI repara deliberadamente alguns históricos inválidos do provedor. Uma chamada de ferramenta cancelada pode se tornar um retorno interrompido válido pelo fornecedor. Um resultado de ferramenta órfã pode ser removido. Esses reparos ajudam a solicitação do próximo modelo a ser bem sucedida, mas não provam que a ferramenta abandonada foi concluída ou que a entrega do usuário existe. Trate a serialização como a primeira porta, não o veredicto Oficial do Pydantic documentação de mensagens e histórico de bate papo recomenda ModelMessagesTypeAdapter para armazenar e carregar o histórico ModelMessage . Ele preserva os campos de mensagem que se ajustam ao esquema do adaptador, enquanto um percurso de ida e volta JSON normaliza valores que não possuem representação nativa JSON. Esse é o limite de persistência correto. Não é uma verificação de integridade do aplicativo. Para tornar a diferença mensurável, executei sete históricos sem conteúdo por meio do Pydantic AI 2.21.0. Cada histórico foi serializado com ModelMessagesTypeAdapter.dump json , recarregado com validate json , normalizado e com hash. Os casos passaram então por verificações separadas para continuidade do prompt, emparelhamento de ferramentas, escopo da conversa, confiança e um recibo de resultado fornecido pelo aplicativo. Todas as sete viagens de ida e volta normalizadas do JSON corresponderam. Apenas o caso de controle estava pronto para ser reproduzido: Caso JSON ida e volta Veredicto operacional Histórico completo mais recibo de resultado Igual READY Faltando prompt do sistema Igual SYSTEM PROMPT GAP Chamada de ferramenta interrompida Igual INTERRUPTED TOOL Resultado de ferramenta órfã Igual ORPHAN RESULT REMOVED IDs de conversa mistos Igual SCOPE DRIFT Resposta do modelo sem recebimento de resultado Igual MISSING OUTCOME RECEIPT Histórico fornecido pelo cliente Igual UNTRUSTED HISTORY O resultado não é um argumento contra o adaptador. Isso mostra por que um arquivo com esquema válido e um estado de agente íntegro são declarações diferentes. O padrão razoável é persistir a saída exata do adaptador, reter um identificador de conversação estável e manter um registro de resultado separado. Não nivele as mensagens em pares ad hoc de função/conteúdo se precisar de metadados de ferramenta, limites de execução, prompts do sistema ou anotações de aplicativo para sobreviver. Um caminho de persistência mínimo é assim: Após o carregamento, execute as outras portas antes de passar o resultado para message history . Continuidade do prompt de auditoria e escopo da conversa O contrato de histórico de Pydantic AI contém um padrão sutil: quando message history não está vazio, a estrutura assume que o histórico já contém um prompt do sistema. Ele não gera um novo para essa execução. A documentação aponta para ReinjectSystemPrompt quando um banco de dados, frontend ou caminho de compactação não percorre o prompt. Isso significa que “as mensagens antigas do usuário estão presentes” é insuficiente. Um trabalho de persistência pode reter cada turno do chat e ainda remover a instrução que definiu a autoridade do agente ou o contrato de saída. Registre o contrato imediato como um identificador não secreto, e não como uma cópia de instruções confidenciais em um fluxo de saúde. Por exemplo: No momento da reprodução, verifique se o histórico carregado contém o formato de prompt exigido por aquela revisão. Se o seu aplicativo usar intencionalmente instruções dinâmicas em vez de prompts persistentes do sistema, verifique esse contrato explicitamente, em vez de tratar a ausência como automaticamente não saudável. A identidade da conversa precisa de seu próprio teste. As mensagens Pydantic AI atuais podem transportar run id e conversation id . Uma nova execução deve receber um novo ID de execução, enquanto o ID de conversação correlaciona os turnos. A fonte da versão 2.21.0 documenta e implementa regras de resolução separadas para os dois identificadores. Um replay gate prático deve rejeitar ou colocar em quarentena um histórico quando: mais de um ID de conversa não nulo aparece sem uma decisão de mesclagem explícita; o locatário ou usuário solicitado não é o proprietário da conversa; o histórico foi carregado em um contexto de autorização e reproduzido em outro; um chamador tenta reutilizar um ID de execução anterior como se fosse a chave de conversação; pretendia se uma bifurcação, mas o aplicativo manteve a identidade original da conversa. Estas são decisões de escopo. Eles não podem ser recuperados do texto da mensagem com segurança e um modelo não deve julgá los. Inspecione o histórico da ferramenta reparada sem considerá la concluída Os provedores de modelos geralmente rejeitam um resultado de ferramenta sem uma chamada correspondente ou uma chamada cujo resultado exigido nunca aparece. O comportamento atual de limpeza de histórico do Pydantic AI torna o provedor de histórico de ferramentas executado localmente válido antes de uma solicitação. O fonte 2.21.0 fixada na versão mostra a ordem: 1. remover resultados de ferramentas regulares órfãos; 2. sintetizar resultados interrompidos para chamadas regulares de ferramentas pendentes quando o reparo for apropriado; 3. mesclar mensagens consecutivas compatíveis após o emparelhamento ser válido. Os retornos sintetizados são marcados nos metadados com pydantic ai synthesized tool return e usam o resultado neutro interrupted . No replay controlado, o caso interrompido ganhou uma volta marcada. O caso órfão perdeu seu retorno incomparável. Ambas as histórias resultantes foram mais fáceis de serem aceitas pelo fornecedor. Nenhum dos dois se tornou evidência de que o efeito externo da ferramenta aconteceu. Use o marcador como um sinal de incidente: Não tente novamente automaticamente todas as chamadas interrompidas. Um tempo limite pode ocorrer após um efeito externo irreversível, mas antes que seu resultado chegue à história. A próxima etapa limitada é consultar o destino com uma chave de idempotência segura ou identificador comercial. Tente novamente somente quando o destino provar que o efeito está ausente e que a operação pode ser repetida com segurança. A remoção de órfãos também merece recibo. Se um histórico carregado continha um resultado que a limpeza removeu posteriormente, preserve um evento de auditoria sem conteúdo com o ID de conversa, o ID de chamada de ferramenta com hash, o tempo observado e a classe de reparo. Não preserve argumentos ou resultados brutos da ferramenta, a menos que o incidente realmente os exija. O experimento usou o símbolo clean message history privado de Pydantic AI para reproduzir exatamente o pipeline documentado. Essa importação é apropriada para um dispositivo de diagnóstico fixado, não para código de aplicativo. APIs privados podem ser alterados sem garantias de compatibilidade. As verificações de produção devem usar tipos de mensagens compatíveis, metadados documentados, recibos de aplicativos e testes fixados na versão que está sendo implantada. Mantenha o histórico do cliente fora dos limites da autoridade A documentação do Pydantic é explícita sobre o histórico fornecido pelo cliente: as superfícies do agente do lado do servidor não têm estado, portanto, um cliente que pode enviar o histórico pode fabricar chamadas de ferramentas, resultados de ferramentas, prompts do sistema ou aprovações. sanitize messages restringe diversas formas inseguras, mas a higienização não estabelece que o histórico enviado seja verdadeiro. Trate a posse de uma transcrição JSON e a autoridade para retomar o trabalho como fatos separados. O servidor deve autenticar o chamador, autorizar a conversa, construir o conjunto de ferramentas permitido a partir da identidade do lado do servidor e revalidar os efeitos de alto risco dentro da função da ferramenta. Se uma execução pausada for importante, persista a no servidor e retome a do estado de propriedade do servidor. Não aceite a afirmação de um navegador de que uma aprovação ocorreu apenas porque uma mensagem em formato de aprovação foi validada. Este é um limite de confiança documentado, não um relatório de vulnerabilidade. A falha operacional é uma aplicação que trata um histórico não confiável como um registro de autoridade. Uma regra de precedência compacta evita que uma verificação plausível de nível inferior esconda uma falha mais importante: A ordem é deliberada. Não há valor em diagnosticar uma entrega perdida em um histórico que o chamador nunca teve permissão para retomar. Exigir um recibo de resultado após a passagem do histórico A porta final pertence ao aplicativo, não à estrutura do histórico do modelo. Defina o efeito esperado antes da execução. Para um agente de codificação, pode ser um commit contendo uma mudança específica além de passar nos testes. Para um agente de suporte, pode ser uma atualização de ticket visível através do ticket API. Para um relatório programado, pode ser um objeto imutável no destino esperado com o intervalo de relatório correto. Armazene um recibo com conteúdo minimizado: O recibo deve vir da leitura determinística mais forte disponível. Um modelo dizendo “pronto” é uma evidência de atividade. Um retorno de ferramenta dizendo “aceito” é uma evidência de transporte. Uma nova leitura do destino mostrando a revisão pretendida é uma evidência do resultado. Isso também lida com a espera legítima. Se o agente estiver pausado para aprovação humana, o estado correto não será MISSING OUTCOME RECEIPT ; é um registro de espera com proprietário, decisão necessária, prazo e token de retomada. Somente classifique a execução como travada quando a janela de progresso esperada fechar sem uma espera ou resultado válido. A repetição de sete casos tem um limite estreito: ela testa estados de falha selecionados no histórico de mensagens no Pydantic AI 2.21.0, não em todos os provedores, ferramentas integradas, adaptadores de UI ou produtos de memória de longo prazo. Execute novamente o fixture ao atualizar a estrutura, alterar a serialização, adicionar um adaptador frontend ou alterar a execução da ferramenta. O modelo de integridade pretendido do Sidewisp inclui persistência de contexto, acessibilidade de ferramenta, progresso útil e verificação de resultados. A Sidewisp está atualmente em prévia privada. A coleção de integridade do agente de produção e um adaptador Pydantic AI geralmente não são enviados, portanto, este guia é uma regra operacional independente, em vez de uma afirmação de que Sidewisp já realiza a auditoria. A decisão de repetição é, portanto, simples: usar ModelMessagesTypeAdapter para durabilidade e, em seguida, exigir autoridade, continuidade do prompt, emparelhamento honesto de ferramentas, escopo de conversação e recebimento de resultado externo. O histórico válido pelo provedor é uma evidência útil. Não é a mesma coisa que um agente saudável.