# Comment reproduire l'échec d'un agent de code entre plusieurs versions de modèle ? > Capturez l'exécution complète sous forme de fixture versionnée, puis rejouez le même prompt, commit, contrat d'outils, environnement et règles d'arrêt avec des ID de modèle figés. Comparez les événements structurés et l'état final du dépôt, pas seulement le texte de l'assistant. # Comment reproduire l'échec d'un agent de code entre plusieurs versions de modèle ? Une reproduction utile est une expérience exécutable, pas une transcription copiée. Partez de l'état défaillant du dépôt, figez chaque entrée observable par l'agent et définissez l'échec par une assertion vérifiable par machine. Rejouez ensuite la fixture plusieurs fois avec des versions de modèle figées. Une exécution combine modèle, outils, fichiers, réseau, orchestration et timing. Si l'un change, un résultat différent ne prouve pas que le modèle a causé ou corrigé le problème. ## Définir l'échec comme une assertion Écrivez la plus petite condition observable qui sépare échec et réussite : test encore rouge, fichier modifié par erreur, commande interdite, migration absente ou patch qui compile mais change le comportement. Évitez « la réponse semble moins bonne ». Une réparation peut exiger : * le test de régression initial passe ; * tous les tests existants passent encore ; * aucun fichier hors liste autorisée ne change ; * l'agent s'arrête dans un nombre d'appels fixé ; * le diff final ne contient ni secret généré ni dérive du lockfile. ## Capturer l'enveloppe complète d'exécution Le prompt n'est qu'une entrée. Stockez avec la fixture : | Couche | Élément à figer | Pourquoi le résultat change | |---|---|---| | Dépôt | Commit, sous-modules, patch sale, fichiers non suivis | L'agent raisonne sur ce code exact | | Instructions | Prompt système, règles, tâche utilisateur | Un petit changement modifie le plan | | Modèle | Fournisseur, ID immuable, paramètres | Alias et valeurs par défaut évoluent | | Outils | Noms, schémas JSON, droits, délais | Les possibilités façonnent le plan | | Environnement | Image, OS, architecture, verrous | Commandes et tests peuvent différer | | Données externes | HTTP simulé, horloge, aléa | Les services actifs dérivent | | Orchestrateur | Limite de boucles, tentatives, compression | Le même modèle peut recevoir un autre historique | Supprimez les secrets, mais conservez l'existence et la portée des identifiants. ## Enregistrer des événements structurés Stockez chaque requête et réponse du modèle, appel et résultat d'outil, tentative et décision d'arrêt comme événement ordonné. Ajoutez un hash aux grosses sorties et conservez l'artefact original à part. ```json { "run_id": "agent-regression-042", "fixture": "sha256:...", "model": "provider/model-version", "event": "tool_result", "tool": "run_tests", "exit_code": 1, "stdout_sha256": "..." } ``` Vous verrez ainsi si le nouveau modèle a choisi un autre outil, compris différemment la même erreur ou reçu une autre preuve. ## Figer les versions et éliminer la variance en direct Utilisez des ID datés ou immuables. Ne comparez pas un échec historique à `latest`, qui peut déjà pointer vers une autre version. Exécutez dans un conteneur ou une VM propre. Remplacez recherches et registres de paquets changeants par des réponses enregistrées ou snapshots internes. Figez l'horloge si la date compte. Si le réseau est nécessaire, enregistrez chaque réponse et marquez le test comme partiellement contrôlé. Une graine aide, mais ne fige pas l'inférence distribuée, les délais d'outils ni les changements fournisseur. ## Rejouer une matrice, pas une seule paire Une exécution par version ne sépare pas régression et variance. Gardez la fixture fixe : | Version du modèle | Répétitions | Taux de réussite | Médiane d'appels | Signature d'échec | |---|---:|---:|---:|---| | ID de référence figé | 5 | 4/5 | 9 | Test limite oublié | | ID candidat figé | 5 | 1/5 | 13 | Fichier généré modifié | | Candidat avec ancien prompt | 5 | 1/5 | 12 | Même signature | Cinq répétitions sont un bon début. Augmentez-les pour les échecs intermittents ou critiques. Gardez temperature et autres contrôles identiques sauf si vous les testez. ## Comparer décisions et état du dépôt Comparez séparément : * événements normalisés du modèle et des outils ; * commandes et codes de sortie ; * arborescence finale et patch ; * tests d'acceptation et ressources. Le raisonnement textuel n'a pas à être identique. Des chemins différents peuvent produire des patchs équivalents, tandis qu'un texte similaire peut masquer des commandes différentes. ## Réduire la fixture après reproduction Une fois l'échec répété, retirez un à un fichiers, outils, paragraphes et appels externes sans rapport. Une petite fixture est plus rapide et expose mieux la frontière causale. Conservez le rejeu complet pour l'audit et le cas minimal pour l'évaluation continue. Ajoutez ce dernier au contrôle de mise à niveau du modèle. ## Utiliser un adaptateur de modèle portable Une passerelle comme Atlas Cloud peut placer plusieurs modèles derrière un client compatible OpenAI, mais la compatibilité n'implique pas un comportement identique. Placez ID et options dans l'adaptateur ; le banc commun gère fixtures, événements, tentatives et assertions. La même reproduction peut alors s'exécuter entre fournisseurs sans réécrire l'évaluation. ## Conclusion Figez l'enveloppe d'exécution, rejouez plusieurs fois des modèles fixés et jugez des résultats exécutables. Si toutes les conditions de l'incident ne sont pas reproductibles, déclarez les entrées encore actives et présentez le résultat comme une comparaison, pas comme la preuve d'une régression. ## FAQ ### Que faut-il capturer pour reproduire l'échec d'un agent de code ? Capturez commit et patch non validé, prompts et instructions, ID et paramètres du modèle, schémas et résultats d'outils, image d'environnement, fichiers de verrouillage, politiques d'identifiants et réseau, ainsi que l'assertion exacte de réussite. ### Faut-il rejouer l'échec avec un alias latest ? Non. Utilisez un ID immuable ou daté. Un alias latest peut changer pendant le test et rendre l'attribution d'une réussite ou d'un échec impossible. ### Pourquoi une graine aléatoire fixe ne suffit-elle pas ? Elle ne fige ni l'infrastructure du fournisseur, ni le timing des outils, ni les résultats de recherche, ni les révisions du modèle. C'est un contrôle parmi d'autres, pas une garantie de déterminisme. ### Quel est le meilleur signal de réussite pour un agent de code ? Privilégiez des assertions exécutables : tests, lint, différences de fichiers attendues, contrôles de fichiers interdits et codes de sortie. La similarité textuelle est généralement insuffisante. ### Combien de répétitions faut-il par version ? Exécutez-en assez pour distinguer une régression déterministe de la variance. Cinq est un bon point de départ ; un échec critique peut justifier vingt essais ou davantage. ### Le même banc peut-il comparer plusieurs fournisseurs ? Oui, si vous normalisez requête, contrat d'outils, événements et assertions. Isolez les options propres au fournisseur dans des adaptateurs.