Une approche de débogage unifiée via la synergie multi-agents basée sur LLM : vérifier la réparation

Une approche de débogage unifiée via une synergie multi agents basée sur LLM n'est utile que lorsque ses agents laissent des preuves qui survivent à leur propre conversation. Un localisateur peut sembler certain, un réparateur peut émettre un correctif et un réviseur peut l'approuver alors que la panne d'origine n'a jamais été reproduite ou que le cas limite décisif n'a jamais été testé. La valeur par défaut raisonnable est donc la suivante : laissez les agents spécialisés proposer et contester une réparation, mais promouvoir le correctif uniquement après qu'un reçu lié prouve la reproduction, la lignée, la couverture des tests, la qualité Oracle et l'examen. Cette règle de fonctionnement suit l'architecture du article FixAgent sans confondre les résultats de la recherche avec une garantie de production. Le document sépare la localisation des pannes, la génération de correctifs et l'analyse post erreur entre les agents spécialisés. Il distingue également un correctif plausible qui réussit les tests disponibles d'un correctif correct établi par vérification manuelle. Cette distinction est la frontière de la santé. Ce que le résultat FixAgent prouve et ce qu'il ne prouve pas La conception publiée de FixAgent est plus spécifique que « demander à plusieurs modèles de déboguer ». Sa méthodologie utilise un localisateur, un réparateur et un revisiteur, ainsi qu'un agent de création d'entrées pour des tests supplémentaires. Les agents expliquent leur raisonnement, suivent les variables importantes et transmettent les résultats des étapes précédentes en aval. Si le correctif généré échoue, l’étape de réparation peut être à nouveau échantillonnée avec un retour de test. L'article rapporte des résultats solides sur QuixBugs, Codeflaws et ConDefects. Il s’agit de résultats de recherche basés sur les ensembles de données, les modèles, les invites et la procédure de vérification de l’article. Ils n’établissent pas qu’un correctif de référentiel arbitraire peut être fusionné en toute sécurité. Deux détails provenant de la source principale modifient la décision opérationnelle : 1. Le document définit un correctif plausible comme un correctif qui réussit les tests écrits par des humains, tandis que son exactitude nécessite une vérification manuelle distincte. 2. Sa section sur les limitations indique que l'agent d'entrée de test supplémentaire ne peut pas calculer lui même les résultats attendus. Une entrée générée sans un oracle digne de confiance n'est pas un test complet. La implémentation Rudra publiée rend la limite inspectable. Son coureur multi tours traite aucun cas de défaillance observé comme une réparation réussie et renvoie ce drapeau au lanceur. Cela est approprié pour la boucle de test d’une expérience. Un opérateur doit toujours demander quelles suites ont été exécutées, si son oracle est digne de confiance, si le résultat appartient à ce correctif et si un réviseur a accepté la différence réelle. La leçon n’est pas que l’examen des agents est inutile. Un désaccord entre spécialistes peut révéler une mauvaise localisation ou un patch faible. La leçon est que le texte d’un agent ne doit pas être la seule preuve consommée par le suivant. Liez chaque étape de débogage avec un reçu de réparation Un reçu de réparation minimale peut être sans contenu. Il n'a pas besoin d'invites, de code source, de résultats de test ou de raisonnement de modèle. Cela nécessite des identités et des verdicts stables qui permettent à une porte humaine ou déterministe de reconstruire la frontière : Limite Champs minimum de reçu L'échec il attrape Reproduction ID d'exécution, hachage de commande, échec d'origine observé Un patch pour un bug qui n'a jamais été reproduit Localisation ID d'exécution, révision de la source, horodatage des preuves Un résultat de localisateur réutilisé à partir d'une autre révision Patch hachage du correctif, révision parent, nombre de lignes modifiées Une réparation vide, périmée ou sans rapport Validation ID de suite requis, ID de suite observés, nombre d'échecs « Tous les tests réussissent » lorsqu'une suite requise n'a jamais été exécutée Oracle vérifié, inconnu ou contesté Cas générés sans résultat attendu digne de confiance Revue attente approuvée, rejetée ou détenue Accord modèle confondu avec une autorité de fusion Résultat demande d'achèvement et reçu de destination Une exécution terminée dont le correctif n'a pas été vérifié ou livré L’ID d’exécution est particulièrement important. Une réponse de localisation de run old ne doit pas justifier silencieusement un correctif de run 42 . Le hachage du patch est tout aussi important : un enregistrement de test vert pour une différence ne peut pas être attaché à un rééchantillonnage ultérieur. Il s’agit d’une lignée ordinaire, mais les flux de travail des agents la perdent souvent car le contexte conversationnel donne l’impression que les messages proches sont liés. Voici la forme utilisée par le luminaire qui l'accompagne : Les chaînes sont des identifiants et non du contenu stocké. Dans un système réel, les hachages doivent être calculés sur les entrées et les artefacts canoniques, et l'enregistrement de test doit inclure la version de l'outil, la révision de la configuration, l'heure de début, l'heure de fin et la provenance de la sortie. Les secrets, les invites, le contenu des fichiers et les arguments bruts des outils doivent rester en dehors du reçu de santé. Rejouez neuf états gênants avant de faire confiance au vert L'artefact de l'article contient neuf cas synthétiques et un classificateur Node.js classé par priorité. Exécutez le à partir du répertoire du rapport d'article : Le résultat observé est : Les cas sont volontairement peu pratiques : UNREPRODUCED arrête le flux de travail avant qu'un correctif fiable ne puisse masquer une ligne de base manquante. LOCALIZATION DRIFT détecte un reçu de localisateur provenant d'une autre exécution. NO EFFECTIVE PATCH refuse un hachage manquant ou un changement de ligne zéro. TEST GAP signale une suite d'intégration requise qui n'a jamais été exécutée, même lorsque les suites observées sont vertes. ORACLE UNCERTAIN préserve l'incertitude lorsque les entrées générées n'ont pas de sorties attendues vérifiées. REVIEW REJECTED empêche un patch techniquement vert de devenir un patch approuvé. WAITING représente une dépendance légitime uniquement lorsque le reçu nomme un propriétaire et une date limite. FALSE COMPLETE surpasse une déclaration d'achèvement lorsqu'un test observé échoue toujours. VERIFIED REPAIR nécessite que toutes les limites précédentes soient d'accord. La commande compte. Une déclaration d’achèvement ne peut pas remplacer un test ayant échoué. Un compteur zéro échec ne peut pas remplacer une suite manquante. Un cas limite généré ne peut pas établir l'exactitude sans un oracle. Une attente de révision ne doit pas être classée comme un décrochage lorsqu'elle a un propriétaire et une date limite. Cette expérience montre également pourquoi un seul score de santé est un mauvais artefact de débogage. Les cas suite gap et verified repair ne signalent aucun échec de test, mais leurs états opérationnels diffèrent car aucun d'entre eux n'a jamais exécuté la suite d'intégration requise. Les preuves manquantes sont plus importantes que le pion vert. Ajoutez la porte d'entrée à un véritable workflow d'agent de codage Commencez par une petite limite de promotion plutôt que de reconstruire la structure de l'agent : 1. Gèlez la révision d'entrée. Enregistrez la validation du référentiel ou l'instantané de l'espace de travail avant la localisation. 2. Reproduisez l'échec. Stockez un hachage de commande/configuration et un résultat structuré. Si la reproduction est floconneuse, étiquetez la comme incertaine et ne considérez pas une éventuelle passe verte comme une preuve de réparation. 3. Liez chaque transfert. Exigez que les reçus du localisateur, du réparateur et du réviseur fassent référence à la même exécution et à la même révision parent. 4. Rééchantillonnage lié. La boucle de rétroaction du document FixAgent est utile, mais les nouvelles tentatives consomment du budget et peuvent modifier le correctif. Donnez à chaque nouveau patch son propre hachage, plafonnez les tentatives et invalidez les preuves de test précédentes lorsque la différence change. 5. Déclarez les suites requises avant l'exécution. Sinon, un agent peut redéfinir « tous les tests » après avoir vu les résultats. 6. Séparez l'exécution des tests de l'autorité Oracle. Les entrées générées peuvent améliorer la couverture, mais une personne, une spécification, une implémentation de référence ou une règle déterministe indépendante doivent fournir le résultat attendu. 7. Gardez l'autorité de fusion ou de déploiement sous contrôle humain. Un reçu approuvé peut préparer la décision ; cela ne devrait pas élargir la permission de l’agent. 8. Vérifiez la destination. Si la tâche consistait à ouvrir une demande d'extraction, à mettre à jour un problème ou à produire un artefact de version, vérifiez cette destination indépendamment. Un correctif local est une activité, pas nécessairement le résultat demandé. Pour une pause d'approbation, utilisez un enregistrement explicite : N'effectuez pas de recherche simplement parce que l'agent est silencieux alors que cet enregistrement est à jour. Escaladez lorsque le délai expire, que le propriétaire est absent ou que la reprise de l'exécution ne produit aucune nouvelle preuve. L'attente n'est pas bloquée ; une activité répétée sans un delta de résultat n’est pas un progrès. La limite pour Sidewisp La thèse défendable est étroite : le débogage multi agents devient opérationnellement fiable lorsque les résultats des spécialistes sont associés à des preuves de réparation déterministes, et le vert est refusé lorsque les preuves de lignée, de couverture, de qualité d'oracle, de révision ou de résultat sont manquantes. Le montage à neuf cas falsifie le raccourci « zéro panne observée signifie réparation vérifiée » car deux cas de zéro panne aboutissent à des verdicts différents. Il s'agit d'un modèle de fonctionnement et non d'une affirmation selon laquelle Sidewisp exécute actuellement FixAgent ou surveille les réparations des agents de codage. Sidewisp est actuellement en préversion privée. Il s'agit d'une plate forme de santé d'agent IA, mais le moteur de surveillance de la production, les adaptateurs d'exécution et l'exécuteur de récupération ne sont généralement pas livrés. La couche de santé prévue est pertinente ici car elle distingue les progrès utiles, l'attente légitime, les faux achèvements et les preuves incertaines tout en laissant l'autorité de fusion avec l'humain. Utilisez d’abord le reçu sur un workflow de débogage répété. S'il ne peut pas distinguer une suite manquante d'une réparation vérifiée sans lire la transcription, le contrat de preuve est encore trop faible.