Mémoire de l'agent de Pydantic AI: vérifier l'historique avant la répétition

La mémoire de l'agent Pydantic AI n'est prête à être reproduite que lorsque six contrôles indépendants sont effectués: les messages font demi tour à travers le sérialisateur pris en charge, l'historique provient d'une source autorisée du côté du serveur, l'interrogatoire système requis a survécu, les appels à l'outil et les résultats restent opérationnellement honnêtes, chaque message appartient à la conversation prévue et l'application a un reçu pour le résultat attendu. Une charge utile JSON valide ne prouve que le premier contrôle. Cette distinction est importante parce que Pydantic AI répare délibérément certains dossiers invalides des fournisseurs. Un appel à l'outil annulé peut devenir un retour interrompu valide pour le fournisseur. Un résultat d'outil orphelin peut être retiré. Ces réparations permettent de réussir la demande de modèle suivante, mais elles ne prouvent pas que l'outil abandonné est terminé ou que le délivrable de l'utilisateur existe. Traitez la sérialisation comme la première porte, pas le verdict Le messages et documentation de l'historique du chat officiel de Pydantic recommande le ModelMessagesTypeAdapter pour le stockage et le chargement de l'historique du ModelMessage . Il préserve les champs de message qui correspondent au schéma de l'adaptateur, tandis qu'un JSON rend normal les valeurs qui n'ont pas de représentation JSON native. C'est la limite correcte de persistance. Il ne s'agit pas d'un contrôle de santé de l'application. Pour faire la différence mesurable, j'ai couru sept histories sans contenu à travers Pydantic AI 2.21.0. Chaque histoire a été sérialisée avec ModelMessagesTypeAdapter.dump json , rechargée avec validate json , normalisée et hashée. Les cas ont ensuite été vérifiés séparément pour la continuité rapide, la mise en paire des outils, la portée de la conversation, la confiance et un reçu des résultats fourni par l'application. Tous les sept voyages normaux JSON se sont accordés. Seule la boîte de contrôle était prête à être reprise: Le cas de l'accusé JSON Voyage aller et retour Verdict opérationnel L'historique complet et le reçu des résultats Égalité READY Retour du système manquant Égalité SYSTEM PROMPT GAP Appel à l'outil interrompu Égalité INTERRUPTED TOOL Résultat des outils orphelins Égalité ORPHAN RESULT REMOVED Identifiants de conversation mixtes Égalité SCOPE DRIFT Modèle de réponse sans réception du résultat Égalité MISSING OUTCOME RECEIPT Les antécédents fournis par le client Égalité UNTRUSTED HISTORY Le résultat n'est pas un argument contre l'adaptateur. Il montre pourquoi une archive valide du schéma et un état d'agent sain sont des revendications différentes. Le défaut raisonnable est de maintenir la sortie exacte de l'adaptateur, de conserver un identifiant de conversation stable et de conserver un enregistrement séparé des résultats. Ne pas aplanir les messages en paires de rôles/contenus ad hoc si vous avez besoin de métadonnées de l'outil, de limites d'exécution, de requêtes système ou d'annotations d'application pour survivre. Une trajectoire de persistance minimale ressemble à ceci: Après chargement, procédez aux autres portes avant de transmettre le résultat à message history . La continuité et la portée des conversations d'audit Le contrat d'historique de Pydantic AI contient un défaut subtil: lorsque message history n'est pas vide, le cadre suppose que l'historique contient déjà un prompt système. Il ne génère pas de nouveau pour cette course. La documentation pointe vers ReinjectSystemPrompt lorsqu'une base de données, un frontend ou un chemin de compaction ne fait pas le tour du prompt. Cela signifie que les anciens messages utilisateurs sont présents est insuffisant. Un travail de persistance peut retenir chaque tour de chat et toujours supprimer l'instruction qui définit l'autorité de l'agent ou le contrat de sortie. Enregistrer le contrat immédiat comme un identifiant non secret, et non comme une copie d'instructions sensibles dans un flux de santé. Par exemple: Au moment de la lecture, vérifiez que l'historique chargé contient la forme requise par cette révision. Si votre application utilise intentionnellement des instructions dynamiques au lieu de demandes persistantes du système, vérifiez explicitement ce contrat plutôt que de considérer l'absence comme automatiquement malsaine. L'identité de la conversation a besoin de son propre test. Les messages actuels de Pydantic AI peuvent contenir à la fois run id et conversation id . Une nouvelle course devrait recevoir une nouvelle ID de course, tandis que l'ID de conversation corrélate les tours. La source de la version 2.21.0 documente et met en œuvre des règles de résolution distinctes pour les deux identifiants. Une passerelle de répétition pratique doit rejeter ou mettre en quarantaine un historique lorsque: Plus d'un identifiant de conversation non nul apparaît sans décision de fusion explicite; le locataire ou l'utilisateur requis n'est pas le propriétaire de la conversation; l'historique a été chargé dans un contexte d'autorisation et reproduit dans un autre; un appelant tente de réutiliser un identifiant d'exécution antérieur comme s'il s'agissait de la clé de conversation; une fourchette était prévue, mais l'application a conservé l'identité de conversation originale. Ce sont des décisions de portée. Ils ne peuvent pas être récupérés en toute sécurité du texte du message, et un modèle ne devrait pas les juger. Inspecter l'historique des outils réparés sans l'appeler complet Les fournisseurs de modèles rejettent généralement un résultat de l'outil sans appel correspondant ou un appel dont le résultat requis n'apparaît jamais. Le comportement actuel de nettoyage d'historique de Pydantic AI rend le fournisseur d'historique d'outils régulier, exécuté localement, valide avant une demande. Le source 2.21.0 en version intégrée affiche l'ordre suivant: 1. supprimer les résultats des outils ordinaires orphelins; 2. synthétiser les résultats interrompu pour les appels réguliers d'outils suspendus lorsque la réparation est appropriée; 3. la fusion de messages consécutifs compatibles après l'accouplement est valide. Les retours synthétisés sont marqués dans les métadonnées avec pydantic ai synthesized tool return et utilisent le résultat neutre interrupted . Dans la répétition contrôlée, l'affaire interrompue a obtenu un retour marqué. L'orphelinat a perdu son retour inégalé. Les deux antécédents résultants ont été plus faciles à accepter par un fournisseur. Aucun n'a prouvé que l'effet extérieur de l'outil s'était produit. Utilisez le marqueur comme signal d'incident: Ne réessayez pas automatiquement chaque appel interrompu. Un délai peut survenir après un effet extérieur irréversible mais avant que son résultat n'atteigne l'histoire. La prochaine étape limitée consiste à consulter la destination avec une clé d'identité ou un identifiant d'entreprise sécurisé. Ne réessayez que lorsque la destination prouve l'absence de l'effet et que l'opération peut être répétée en toute sécurité. La déportation des orphelins mérite aussi un reçu. Si un historique chargé contenait un résultat que le nettoyage a ensuite supprimé, préservez un événement d'audit sans contenu avec l'identifiant de conversation, l'identifiant d'appel d'outil haché, le temps observé et la classe de réparation. Ne conservez pas les arguments ou les résultats de l'outil brut, sauf si l'incident les nécessite réellement. L'expérience a utilisé le symbole privé clean message history de Pydantic AI pour reproduire exactement le pipeline documenté. Cette importation est appropriée pour un dispositif de diagnostic fixé, et non pour le code d'application. Les API privées peuvent changer sans garantie de compatibilité. Les contrôles de production doivent utiliser des types de messages pris en charge, des métadonnées documentées, des reçus d'application et des tests fixés à la version déployée. Conserver l'historique du client en dehors des limites de l'autorité La documentation de Pydantic est explicite sur l'historique fourni par le client: les surfaces d'agents côté serveur sont sans état, de sorte qu'un client qui peut soumettre l'historique peut fabriquer des appels d'outils, des résultats d'outils, des invites système ou des approbations. sanitize messages restreint plusieurs formes dangereuses, mais la désinfection ne prouve pas que l'historique soumis est vrai. Traiter la possession d'une transcription JSON et l'autorisation de reprendre le travail comme des faits distincts. Le serveur doit authentifier l'appelant, autoriser la conversation, construire l'ensemble d'outils autorisé à partir de l'identité côté serveur et révalider les effets à haut risque à l'intérieur de la fonction d'outil. Si une exécution en pause est importante, persistez sur le serveur et reprenez la à partir de l'état propriétaire du serveur. N'acceptez pas l'affirmation d'un navigateur selon laquelle une approbation s'est produite simplement parce qu'un message en forme d'approbation est valide. Il s'agit d'une limite de confiance documentée, pas d'un rapport de vulnérabilité. L'échec opérationnel est une demande qui traite un historique non fiable comme un dossier d'autorité. Une règle de priorité compacte empêche un contrôle plausible de niveau inférieur de cacher une défaillance plus importante: L'ordre est délibéré. Il n'y a aucune valeur à diagnostiquer une livraison manquante d'un historique que l'appelant n'a jamais pu reprendre. Exiger un reçu de résultat après l'historique est passé La passerelle finale appartient à l'application et non au cadre modèle historique. Définir l'effet attendu avant la course. Pour un agent de codage, il peut s'agir d'un engagement contenant un changement spécifique plus des tests passés. Pour un agent de support, il peut s'agir d'une mise à jour du ticket visible via l'API du ticket. Pour un rapport prévu, il peut s'agir d'un objet immuable à la destination attendue avec l'intervalle de déclaration correct. Conserver un reçu réduit au minimum: Le reçu doit provenir de la lecture déterministique la plus forte disponible. Un modèle qui dit done est une preuve d'activité. Un retour d'outil indiquant "accepté" est une preuve de transport. Une nouvelle lecture de destination montrant la révision prévue est la preuve du résultat. Il s'agit aussi d'une attente légitime. Si l'agent est suspendu pour l'approbation humaine, l'état correct n'est pas MISSING OUTCOME RECEIPT ; c'est un enregistrement d'attente avec un propriétaire, une décision nécessaire, une date limite et un jeton de reprise. Ne classer la course comme bloquée que lorsque la fenêtre de progression attendue se ferme sans attendre ou obtenir de résultats valides. La répétition de sept cas a une limite étroite: elle teste des états de défaillance de l'historique des messages sélectionnés sous Pydantic AI 2.21.0, pas tous les fournisseurs, l'outil intégré, l'adaptateur UI ou le produit de mémoire à long terme. Retournez le fichier lors de la mise à niveau du framework, de la modification de la sérialisation, de l'ajout d'un adaptateur de frontend ou de l'exécution de l'outil. Le modèle de santé prévu par Sidewisp comprend la persistance du contexte, l'accessibilité des outils, les progrès utiles et la vérification des résultats. Sidewisp est actuellement en préversion privée. La collecte des agents de production et de santé et un adaptateur Pydantic AI ne sont généralement pas expédiés, ce guide est donc une règle d'exploitation indépendante plutôt qu'une affirmation selon laquelle Sidewisp effectue déjà l'audit. La décision de répétition est donc simple: utilisez ModelMessagesTypeAdapter pour la durabilité, puis demandez autorité, continuité rapide, pairing d'outils honnête, champ de conversation, et un reçu de résultat externe. L'historique valide du fournisseur est une preuve utile. Ce n'est pas la même chose qu'un agent sain.