Débogage interactif et Pilotage des systèmes d'AI Multi-Agents: Gate à chaque réinitialisation

Le débogage et le pilotage interactifs des systèmes d'AI multi agents ne doivent pas être traités comme une édition de transcription. Une réinitialisation sécurisée crée une nouvelle branche avec sa propre lignée, ses preuves d'état restaurées, son dossier d'autorité et sa réception des résultats. Si un navigateur, un espace de travail, une file d'attente, des informations d'identification ou une destination externe ne peuvent pas être restaurés ou rapprochés, l'état correct est incertain—pas “prêt".” C'est la leçon pratique à tirer de Débogage et Pilotage Interactifs des Systèmes d'AI Multi Agents, le document CHI 2025 derrière l'open source de Microsoft AGDebugger. La recherche rend le rembobinage et l'édition utilisables pour le débogage multi agents. Un déploiement opérationnel nécessite une limite supplémentaire: une réinitialisation peut recréer un état interne suffisamment proche pour tester une hypothèse, mais elle ne peut pas automatiquement annuler un e mail, annuler un ticket, annuler la publication d'une page ou prouver que la nouvelle branche a terminé la tâche de l'utilisateur. Le défaut raisonnable est un reçu de direction avec six portes: 1. le parent et la branche ont des identités distinctes; 2. le point de contrôle couvre toutes les clés d'état d'agent et d'outil requises; 3. les effets après le point de contrôle sont annulés ou réconciliés; 4. l'opérateur est autorisé à effectuer l'intervention; 5. la configuration de l'agent est épinglée pour la nouvelle branche; 6. la succursale reprise reçoit un nouveau reçu de résultat. Seuls les cinq premiers font une branche prêt à reprendre . Le sixième le fait vérifié . Une réinitialisation est une branche, pas un rembobinage Le papier AGDebugger part d'un problème concret. Cinq développeurs d'agents ont décrit des difficultés à localiser les erreurs dans les longues conversations, des contrôles de débogage interactifs manquants et une itération lente sur les configurations d'agents. Les auteurs ont construit un système qui permet à un développeur de parcourir les messages, de revenir à un point antérieur, de modifier un message précédent et de comparer les branches de conversation résultantes. Une étude en deux parties avec 14 participants a ensuite examiné les stratégies de diagnostic et de pilotage. C'est une interaction plus forte que la recherche de journaux. Un développeur peut poser deux questions falsifiables à la limite de l'échec: que se passe t il si le même état s'exécute à nouveau et que se passe t il si un message spécifique change? Le document fait état de trois formes courantes de pilotage dans son étude: l'ajout de détails, la simplification d'une tâche et la modification d'un plan. Mais les détails de la mise en œuvre comptent plus que l'accessibilité de l'édition. AGDebugger vérifie l'état de l'agent avant qu'un message ne soit traité. Lors de la réinitialisation, il restaure le point de contrôle correspondant et crée une nouvelle session. Les messages et les points de contrôle avant le fork restent partagés; les nouveaux messages et points de contrôle appartiennent à la branche. C'est la lignée, même si l'interface ressemble à un rembobinage. Traiter l'opération comme une branche donne à l'opérateur trois invariants utiles: l'exécution échouée d'origine reste inspectable; le point de bifurcation exact est immuable; l'édition et tous les effets ultérieurs appartiennent à une nouvelle session. Sans ces invariants, une transcription modifiée peut réécrire les preuves utilisées pour diagnostiquer l'incident. L ' “exécution réussie” qui en résulte peut être impossible à reproduire car personne ne peut dire quel historique, invite, schéma d'outil ou configuration de modèle l'a produit. L'enregistrement de branche n'a pas besoin de contenu de message: Les identifiants de hachage et les classes d'édition grossière suffisent pour une piste de preuves. N'exportez pas d'invites, d'arguments d'outil, de secrets ou de données utilisateur simplement pour prouver qu'un fork existe. Restaurer la couverture de l'état avant de changer de plan La suppression de messages d'une transcription n'est pas une restauration d'état. Le document indique que les agents AGDebugger implémentent des méthodes de sauvegarde et de chargement d'état. L'état d'un agent Web peut inclure une URL et une position de fenêtre; d'autres agents peuvent avoir besoin d'un état différent. Il décrit également la stratégie de point de contrôle comme "assez bonne", car la restauration complète du JavaScript du navigateur et de l'état de l'application distante peut être peu pratique, voire impossible. Cette limitation devrait se trouver à côté du bouton de réinitialisation, pas dans une autopsie. Définissez les clés d'état requises par le workflow avant le démarrage d'une exécution. Pour une petite équipe de recherche et de publication, ils pourraient être: Ce point de contrôle est incomplet car la file d'attente d'approbation est manquante. Une relecture de la transcription pourrait amener la direction générale à demander à nouveau, à ignorer une décision existante ou à agir comme si l'autorité était reportée. L'opérateur devrait voir restore uncertain , pas un contrôle de reprise vert. La couverture est nécessaire mais pas suffisante. Pour chaque clé d'état, enregistrez une empreinte de révision ou sans contenu et un résultat de restauration: Clé d'état Preuve avant réinitialisation Test de restauration requis Mémoire d'agent hachage de révision et de point de contrôle la révision chargée correspond au fork Navigateur origine, hachage de route et classe de session locale l'itinéraire attendu est accessible et la classe de session est valide Espace de Travail validation du référentiel et résumé de l'état sale révision exacte plus modifications locales intentionnelles Registre d'outils hachage de schéma et nombre de capacités les correspondances de registre actuelles ou la dérive sont reconnues File d'attente d'approbation identifiants et statut des reçus de décision les décisions en attente et résolues sont conservées Un système distant actif peut s'être déplacé depuis le point de contrôle. Ce n'est pas toujours un échec. C'est une raison pour étiqueter les preuves. Si le navigateur peut revenir à la page enregistrée mais que l'enregistrement sous jacent de la page a changé, la fidélité de l'instantané est partielle. L'opérateur peut toujours exécuter une branche de diagnostic, mais ne doit pas la présenter comme une rediffusion exacte. La configuration fait partie de l'état. Épinglez les rôles d'agent, les identifiants de modèle, l'ensemble d'outils, les invites système et les règles de routage utilisées par la succursale. Sinon, une édition réussie prouve seulement qu'une combinaison inconnue a fonctionné. Gardez la configuration d'origine immuable et enregistrez le delta intentionnel. Réconcilier les effets avant de rejouer un appel d'outil Un point de contrôle restaure l'état sous le contrôle du débogueur. Cela n'inverse pas le monde extérieur. Supposons que la branche parente ait créé un ticket après le point de contrôle, puis n'ait pas réussi à produire le rapport public promis. La réinitialisation avant l'appel de l'outil et la relecture peuvent créer un deuxième ticket. L'absence de réponse ne prouve pas que le premier appel n'a eu aucun effet. Avant de reprendre, énumérez chaque opération post point de contrôle avec un effet externe et classifiez la: reverted : l'effet d'origine a été annulé en toute sécurité; reconciled : l'effet reste et la nouvelle branche le réutilisera ou l'ignorera; pending : la preuve de destination est manquante; irreversible : l'effet ne peut être annulé et nécessite une nouvelle décision humaine. N'importe quoi pending ou irreversible bloque la relecture automatique à cette limite. Utilisez des clés de fonctionnement stables lorsque la destination les prend en charge. Pour une opération de publication, interrogez la destination par un ID de brouillon immuable avant d'en créer un autre. Pour un e mail, conservez l'identifiant du message du fournisseur sans le corps du message. Pour un changement de référentiel, comparez le commit ou le hachage d'arbre attendu. Pour un ticket, récupérez le ticket par la clé d'idempotence de la requête. L'intervention de l'opérateur nécessite également une limite d'autorité. La modification d'un plan est peu risquée lorsque la succursale est confinée à un appareil local. Il en va matériellement différemment lorsque la modification modifie les destinataires, le budget, les autorisations, les objectifs de production ou les actions destructrices. Acheminez ces modifications vers un propriétaire autorisé et conservez la succursale needs approval jusqu'à ce que le reçu de décision arrive. Attendre cette décision n'est pas bloqué. La reprise répétée alors que l'autorité ou l'état de destination est inconnu est l'échec. Exécutez le reçu de direction contre les cas gênants L'artefact qui l'accompagne est un appareil sans contenu et un classificateur déterministe. Il n'exécute pas AGDebugger et ne prétend pas reproduire son étude utilisateur. Il teste la décision opérationnelle qui entoure une réinitialisation. Exécutez le localement: Le luminaire contient huit branches. Le classificateur produit: Le test ajoute une neuvième assertion: une branche dont l'identifiant est égal à son parent est rejetée comme invalid lineage . La préséance est délibérée. L'état manquant bloque l'interprétation des effets car l'opérateur ne peut pas établir le point de départ de la branche. Les effets non rapprochés bloquent la reprise avant que l'approbation ne soit envisagée. L'approbation et une configuration épinglée rendent la branche prête, pas saine. Après la reprise, le livrable attendu a encore besoin d'un vérificateur déterministe. Modifiez un champ et le résultat devrait se déplacer de manière prévisible. Ajoutez la clé de file d'attente d'approbation manquante à la restauration partielle et elle peut avancer. Marquez un effet de ticket en attente réconcilié et la succursale peut atteindre la porte d'autorité. Ensemble outcomeVerified à faux après une réponse finale fluide et le résultat reste false success . Cela produit une distinction opérationnelle importante: "Prêt à reprendre" signifie que la limite d'intervention est contrôlée. "Vérifié" signifie que la nouvelle succursale a terminé les travaux prévus. Ne fusionnez pas ces États en un seul badge vert. Ce que l'expérience ne prouve pas L'artefact valide une règle de décision, pas la fidélité de l'instantané. Il ne peut pas prouver qu'un navigateur a été restauré exactement, qu'un LLM empruntera le même chemin ou qu'un effet secondaire non documenté ne s'est jamais produit. Une véritable intégration nécessite des adaptateurs d'état spécifiques à l'exécution et des requêtes de destination. L'étude AGDebugger a également une portée limitée: cinq personnes interrogées formatrices, 14 participants à l'étude, deux tâches d'étude et un prototype de recherche construit sur AutoGen. Ses résultats justifient le modèle d'interaction; ils n'établissent pas de réduction du taux d'incidents pour chaque architecture multi agents. Le document lui même identifie les défis ouverts, y compris le découplage du pilotage de la mise en œuvre d'un agent et la détermination de l'effet d'une modification. Ces limites renforcent la règle de fonctionnement. Utilisez la réinitialisation interactive pour isoler une hypothèse, pas pour fabriquer une certitude. Préservez le parent, bifurquez explicitement, restaurez ce qui peut être prouvé, étiquetez ce qui ne peut pas, réconciliez les effets externes, exigez l'autorité et vérifiez le nouveau résultat à sa destination. Sidewisp est actuellement en préversion privée. Ses adaptateurs de surveillance de la production et son exécuteur de récupération ne sont généralement pas livrés. La méthode ici est un modèle de fonctionnement inspectable, pas une affirmation selon laquelle Sidewisp contrôle déjà les points de contrôle ou dirige les équipes d'agents en direct. L'orientation produit de Sidewisp maintient l'autorité humaine, les preuves et la vérification des résultats au cœur de la récupération en toute sécurité. Si vous exploitez des systèmes multi agents aujourd'hui, commencez par un flux de travail sujet aux pannes. Définissez ses clés d'état et son registre d'effets externes avant le prochain incident. Le premier point de contrôle utile n'est pas celui qui peut rejouer le plus d'historique; c'est celui qui peut expliquer exactement ce qui a été restauré, ce qui est resté modifié, qui a autorisé la succursale et comment le résultat final a été vérifié.