Déploiement d'agent AI: demandez cinq reçus avant la production

Un déploiement d'agent AI n'est prêt que lorsque cinq preuves indépendantes conviennent de la même version: le temps d'exécution est atteignable, son identité a exactement les autorisations requises par la tâche, le travail programmé a un calendrier explicite et une sémantique dupliquée, une version précédente peut être restaurée et un canary a produit le livrable promis. Une conclusion saine ne prouve que le premier de ces faits. Utilisez une passerelle bloquée par défaut. Lier chaque reçu à un digeste de libération immuable, enregistrer quand il a été vérifié, et arrêter la promotion quand les preuves sont manquantes, obsolètes, contradictoires, ou appartient à une autre construction. Ne donnez pas une moyenne des cinq contrôles dans un score de préparation. Un champ d'écriture manquant et un artefact client manquant sont des échecs différents avec différents propriétaires. Ce guide transforme cette règle en un manifeste compact et un dispositif exécutable à huit cas. Il est intentionnellement neutre en temps d'exécution: adapter les noms de champs à Kubernetes, une plateforme sans serveur, un planificateur d'agent natif ou un processus hôte, mais garder les cinq questions séparées. Faire du déploiement une décision de preuve liée à la version Le déploiement de production n'est pas seulement le moment où une image ou une fonction atteint une plateforme d'hébergement. L'orientation de l'agent de production de Google identifie l'état de la session, la mémoire persistante, l'authentification et les autorisations des outils, l'enregistrement et le déploiement de sandbox à canary en phase avec la production comme des problèmes spécifiques à l'agent. Ce sont des ingrédients utiles, mais une décision de libération a encore besoin de preuves de la construction exacte qui est promue. Commencez par un identifiant stable tel qu'une digestion d'image, un commande Git, un hash de paquet ou un identifiant de sortie signé. Mettez cet identifiant dans chaque reçu. Une route peut répondre de la libération v27 alors qu'une sonde d'autorisation ou un résultat canarien a été collecté de v26 ; joindre ces enregistrements sans clé de libération crée un faux vert. La santé des infrastructures a une signification plus étroite. Le Documentation de la sonde Kubernetes distingue la vitesse, qui peut déclencher un redémarrage, de la préparation, qui contrôle si un conteneur reçoit le trafic. Un processus prêt peut accepter une demande alors que sa carte d'identité de l'outil est expirée, que son planificateur pointe vers une ancienne commande ou que son vérificateur de sortie n'a aucun artefact à inspecter. Le manifeste de libération peut rester petit: L'exemple stocke des hashes et des identifiants plutôt que des invites, du contenu des transcriptions, des secrets ou des charges utiles d'outils bruts. Les éléments de preuve doivent être suffisants pour décider, et non pas une excuse pour copier un matériau sensible dans un système de libération. Rassemblez cinq reçus qui répondent à différentes questions. Les cinq reçus ne sont délibérément pas interchangeables. Résumé Les preuves requises Ce qu'il ne prouve pas Accès à l'information La libération exacte accepte le travail sur la route prévue L' agent peut terminer une tâche. Autorisations L'identité de l'exécution a tous les champs déclarés et uniquement, avec expiration utilisable Un effet d'outil est arrivé. Le calendrier Le fuseau horaire, la prochaine occurrence, la date limite de défaut, la concomitance et la protection en double sont explicites. L'événement a donné son résultat Retour en arrière Une cible connue a été rétablie et son résultat pertinent vérifié La nouvelle version est correcte. Le résultat Un canary a créé l'état de destination attendu Les courses futures resteront saines Pour obtenir des autorisations, comparez des ensembles au lieu de demander si l'authentification a réussi. Le Définition du privilège le plus faible du NIST limite un processus aux autorisations et aux ressources minimales nécessaires à sa fonction. L'absence d'autorité bloque la tâche; l'excès d'autorité élargit l'effet d'une mauvaise instruction ou d'une nouvelle tentative. Les deux devraient bloquer la promotion jusqu'à ce que le contrat déclaré et l'identité déployée correspondent. Pour les agents programmés, enregistrez la véritable sémantique du planificateur. Kubernetes documente .spec.timeZone , startingDeadlineSeconds et concurrencyPolicy , puis prévient qu'un CronJob peut créer deux emplois ou aucun emploi dans certaines circonstances. Son Documentation CronJob recommande donc des emplois idempotents. Un autre planificateur peut utiliser des noms différents, mais la porte de sortie a toujours besoin d'une réponse pour les démarrements tardifs, les chevauchements, les duplicates, la suspension et l'événement suivant attendu. Un reçu de retour est plus fort qu'un code de sortie de commande. Le Documentation de déploiement de Kubernetes expose l'état de déploiement, les déploiements bloqués et le retour à une révision antérieure. Ça confirme l'état de la plateforme. Pour un agent, ajoutez une autre vérification: après avoir restauré la digestion précédente, réinitialisez un canary sûr ou inspectez un résultat connu spécifique à la tâche. Dans le cas contraire, le retour en arrière peut restaurer un processus sans restaurer de travail utile. La réception des résultats devrait utiliser le plus fort oracle pratique: un objet à sa destination, une ligne de base de données avec la clé d'idempotence attendue, un test de réussite lié à la libération ou un enregistrement de décision humaine suivi d'un progrès observable. Un message de l'agent disant done est une preuve d'activité, pas un livrable. Remplissez la porte contre les échecs inconvenients. Le deployment readiness fixture.json qui l'accompagne contient huit versions. Tous les rapports sont prêts. Seul un cas a cinq reçus frais liés à sha256:agent v27 ; les sept autres isolent une défaillance différente: une vérification de la facilité d'accès périmée; un reçu d'autorisation de la publication précédente; une portée requise manquante; un champ d'application de l'administrateur des excédents; un calendrier sans protection contre le double effet; un retrait qui n'a pas permis de restaurer le résultat attendu; un canary qui a rapporté un succès sans un artefact. Exécuter le classifiant et ses affirmations: Le résultat observé est de huit terminaux accessibles, une libération READY et sept libérations bloquées. La passerelle renvoie le premier état actionable plutôt qu'un pourcentage: Cette priorité compte. Si un reçu appartient à un digeste plus ancien, l'inspection détaillée de son résultat peut être une perte de temps car les preuves ne sont pas admissibles pour la publication actuelle. Une fois l'identité et la fraîcheur passées, l'opérateur peut agir sur la limite spécifique: ajuster une portée, réparer un horaire, redémarrer l'entraînement de retour ou mettre en œuvre un vérificateur de destination. Ne pas transformer unknown en passe. Si un système externe n'est pas disponible pendant les canaries, le résultat est BLOCKED OUTCOME UNVERIFIED , pas un succès supposé. Si la tâche ne peut pas être vérifiée déterministiquement, utilisez un examen humain limité et conservez le reçu de décision, l'autorité de l'examen, la libération du digeste et le temps. Promouvoir en étapes sans affaiblir le contrat de preuve Le Guide des agents de production de Google Cloud recommande de passer de la boîte à sable à la canarie à la production. Gardez les mêmes cinq reçus à chaque étape; modifiez l'exposition autorisée, pas le sens de prêt. Dans une boîte à sable, le reçu d'autorisation peut utiliser des comptes synthétiques et le résultat peut cibler une destination jetable. Dans les canaries, envoyer une petite cohorte limitée, interdire des actions irréversibles à moins d'être approuvées séparément, et collecter le même reçu au niveau de destination. Avant la promotion complète, renouvellez les vérifications d'état actuel et confirmez que l'objectif de retrait reste disponible. Choisissez les fenêtres de fraîcheur à partir du risque opérationnel. Une réception de la disponibilité ou de l'autorisation peut expirer en quelques minutes; un exercice de retour peut rester valable pendant des jours si ni le mécanisme de déploiement ni le contrat de destination ne sont modifiés. Réinitialisez l'exercice lorsque le temps d'exécution, l'autorité de l'outil, le schéma d'état ou le chemin de retour changent. Enregistrer la règle à côté du timestamp afin que fresh soit inspectable plutôt que subjectif. Après la promotion, ces reçus deviennent des entrées de surveillance, mais la décision de déploiement et la santé continue ne sont pas le même système. Une sortie qui a été passée à 21h00 peut perdre une carte d'identité à 22h00 ou rater une course prévue à 23h00. Préserver le manifeste de libération, puis évaluer les nouveaux événements et les résultats dans leurs propres délais. Gardez les limites honnêtes Ce dispositif teste la logique de décision, pas une plateforme en nuage en direct. Les noms d'autorisation, les champs de planification, les fenêtres de fraîcheur, la sécurité des canaries, la durée du roulement et les oracles de résultats doivent être adaptés à l'environnement réel. La structure des cinq reçus est utile parce que ces adaptations restent explicites. Sidewisp est actuellement en préversion privée. Ses adaptateurs de surveillance de la production et ses systèmes de récupération ne sont généralement pas expédiés. La passerelle de préparation décrite ici est une pratique opérationnelle locale que les équipes peuvent mettre en œuvre aujourd'hui, et non une affirmation selon laquelle Sidewisp déploie actuellement des agents, surveille les émissions en direct ou effectue des retours en arrière. La question pertinente de l'aperçu privé est de savoir si les preuves sanitaires futures peuvent maintenir la disponibilité, l'autorité, les horaires, la récupération et les résultats vérifiés séparéssans transformer une vérification du processus vert en un verdict de production.