Debug e gestione interattivi di sistemi IA multi-agente: Gate Every Reset

Il debug e la gestione interattivi dei sistemi di intelligenza artificiale multi agente non dovrebbero essere trattati come modifica della trascrizione. Un ripristino sicuro crea un nuovo ramo con il proprio lignaggio, prove dello stato ripristinato, record di autorità e ricevuta dei risultati. Se un browser, un'area di lavoro, una coda, una credenziale o una destinazione esterna non possono essere ripristinati o riconciliati, lo stato corretto è incerto, non "pronto". Questa è la lezione pratica da cui trarre insegnamentoDebug e gestione interattivi di sistemi di intelligenza artificiale multi agente, il documento CHI 2025 alla base dell'open source di MicrosoftAGDebugger. La ricerca rende il riavvolgimento e la modifica utilizzabili per il debug multi agente. Una distribuzione operativa necessita di un ulteriore limite: un ripristino può ricreare uno stato interno abbastanza fedelmente da testare un’ipotesi, ma non può annullare automaticamente un’e mail, ripristinare un ticket, annullare la pubblicazione di una pagina o dimostrare che il nuovo ramo ha completato l’attività dell’utente. Il valore predefinito ragionevole è una ricevuta di governo con sei porte: 1. il genitore e il ramo hanno identità distinte; 2. il checkpoint copre ogni agente richiesto e chiave di stato dello strumento; 3. gli effetti dopo il checkpoint vengono ripristinati o riconciliati; 4. l'operatore è autorizzato ad effettuare l'intervento; 5. la configurazione dell'agente è bloccata per il nuovo ramo; 6. la filiale ripresa ottiene una nuova ricevuta di esito. Solo i primi cinque formano un ramo pronto a riprendere . Il sesto lo rende verificato . Un ripristino è un ramo, non un riavvolgimento Il paper di AGDebugger parte da un problema concreto. Cinque sviluppatori di agenti hanno descritto difficoltà nel localizzare gli errori in conversazioni lunghe, controlli di debug interattivi mancanti e iterazione lenta delle configurazioni degli agenti. Gli autori hanno creato un sistema che consente allo sviluppatore di scorrere i messaggi, ripristinare un punto precedente, modificare un messaggio precedente e confrontare i rami della conversazione risultanti. Uno studio in due parti con 14 partecipanti ha poi esaminato la diagnosi e le strategie di guida. Si tratta di un'interazione più forte rispetto alla ricerca nei log. Uno sviluppatore può porre due domande falsificabili al limite dell'errore: cosa succede se lo stesso stato viene eseguito di nuovo e cosa succede se un messaggio specifico cambia? L'articolo riporta tre forme comuni di guida nel suo studio: aggiungere dettagli, semplificare un compito e modificare un piano. Ma i dettagli dell’implementazione contano più delle possibilità di editing. Lo stato dell'agente dei checkpoint AGDebugger prima dell'elaborazione di un messaggio. Al ripristino, ripristina il checkpoint corrispondente e crea una nuova sessione. Messaggi e checkpoint prima del fork rimangono condivisi; nuovi messaggi e checkpoint appartengono al ramo. Questo è il lignaggio, anche se l'interfaccia sembra un riavvolgimento. Trattare l'operazione come un ramo fornisce all'operatore tre utili invarianti: la corsa originale fallita rimane ispezionabile; il punto esatto della biforcazione è immutabile; la modifica e ogni effetto successivo appartengono ad una nuova sessione. Senza queste invarianti, una trascrizione modificata può riscrivere le prove utilizzate per diagnosticare l’incidente. La risultante "esecuzione riuscita" potrebbe essere impossibile da riprodurre perché nessuno è in grado di dire quale cronologia, prompt, schema dello strumento o configurazione del modello l'ha prodotta. Il record del ramo non necessita del contenuto del messaggio: Gli identificatori hash e le classi di modifica grossolana sono sufficienti per tracciare prove. Non esportare prompt, argomenti dello strumento, segreti o dati utente semplicemente per dimostrare che esiste un fork. Ripristinare la copertura statale prima di modificare il piano L'eliminazione dei messaggi da una trascrizione non è un ripristino dello stato. Il documento afferma che gli agenti AGDebugger implementano metodi di salvataggio e caricamento dello stato. Lo stato di un agente web può includere un URL e la posizione del viewport; altri agenti potrebbero aver bisogno di uno stato diverso. Descrive inoltre la policy del checkpoint come “abbastanza buona”, poiché il ripristino completo del JavaScript del browser e dello stato dell'applicazione remota può essere poco pratico o impossibile. Questa limitazione dovrebbe trovarsi accanto al pulsante di ripristino, non in un'autopsia. Definire le chiavi di stato richieste dal flusso di lavoro prima dell'avvio di un'esecuzione. Per un piccolo team di ricerca e pubblicazione potrebbero essere: Questo checkpoint è incompleto perché manca la coda di approvazione. Una ripetizione della trascrizione potrebbe indurre la filiale a chiedere nuovamente, a saltare una decisione esistente o ad agire come se l'autorità fosse trasferita. L'operatore dovrebbe vedere restore uncertain , non un controllo di ripristino verde. La copertura è necessaria ma non sufficiente. Per ogni chiave di stato, registra una revisione o un'impronta digitale priva di contenuto e un risultato di ripristino: Chiave di stato Prove prima del ripristino Test di ripristino obbligatorio Memoria dell'agente revisione e hash del checkpoint la revisione caricata corrisponde al fork Navigatore origine, hash del percorso e classe di sessione locale il percorso previsto è raggiungibile e la classe della sessione è valida Spazio di lavoro commit del repository e digest dello stato sporco revisione esatta più modifiche locali intenzionali Registro degli strumenti hash dello schema e conteggio delle capacità vengono riconosciute le corrispondenze o le deviazioni del registro correnti Coda di approvazione ID e stato della ricezione della decisione le decisioni pendenti e risolte vengono conservate Un sistema remoto attivo potrebbe essersi spostato dopo il checkpoint. Questo non è sempre un fallimento. È un motivo per etichettare le prove. Se il browser può tornare alla pagina registrata ma il record sottostante della pagina è cambiato, la fedeltà dell'istantanea è parziale. L'operatore può comunque eseguire un ramo diagnostico, ma non deve presentarlo come una riproduzione esatta. La configurazione fa parte dello stato. Blocca i ruoli dell'agente, gli identificatori del modello, il set di strumenti, i prompt di sistema e le regole di instradamento utilizzate dalla filiale. Altrimenti una modifica riuscita dimostra solo che qualche combinazione sconosciuta ha funzionato. Mantieni immutabile la configurazione originale e registra il delta intenzionale. Riconciliare gli effetti prima di riprodurre una chiamata strumento Un checkpoint ripristina lo stato sotto il controllo del debugger. Non inverte il mondo esterno. Supponiamo che il ramo madre abbia creato un ticket dopo il checkpoint e poi non sia riuscito a produrre il rapporto pubblico promesso. Il ripristino prima della chiamata dello strumento e la riproduzione possono creare un secondo ticket. L'assenza di risposta non prova che la prima chiamata non abbia avuto effetto. Prima di riprendere, enumerare tutte le operazioni successive al checkpoint con un effetto esterno e classificarle: reverted : l'effetto originale è stato annullato senza problemi; reconciled : l'effetto rimane e il nuovo ramo lo riutilizzerà o lo salterà; pending : manca la prova della destinazione; irreversible : l'effetto non può essere annullato e necessita di una nuova decisione umana. Nulla pending O irreversible blocca la riproduzione automatica a quel confine. Utilizzare tasti operativi stabili laddove la destinazione li supporta. Per un'operazione di pubblicazione, interroga la destinazione tramite un ID bozza immutabile prima di crearne un'altra. Per un'e mail, conservare l'ID messaggio del provider senza il corpo del messaggio. Per una modifica del repository, confronta il commit previsto o l'hash dell'albero. Per un ticket, recupera il ticket tramite la chiave di idempotenza della richiesta. L’intervento dell’operatore necessita anche di un confine di autorità. La modifica di un piano è a basso rischio quando la filiale è limitata a un apparecchio locale. La situazione è sostanzialmente diversa quando la modifica cambia destinatari, budget, autorizzazioni, obiettivi di produzione o azioni distruttive. Indirizza tali modifiche a un proprietario autorizzato e mantieni il ramo needs approval fino all'arrivo della ricevuta della decisione. L'attesa di quella decisione non è bloccata. La ripresa ripetuta mentre l'autorità o lo stato di destinazione sono sconosciuti rappresenta l'errore. Esegui la ricevuta di governo per i casi scomodi L'artefatto associato è un dispositivo privo di contenuto e un classificatore deterministico. Non esegue AGDebugger né pretende di riprodurre il proprio studio sugli utenti. Mette alla prova la decisione operativa che circonda un ripristino. Eseguilo localmente: L'apparecchio contiene otto rami. Il classificatore ha prodotto: Il test aggiunge una nona asserzione: un ramo il cui ID è uguale al genitore viene rifiutato come invalid lineage . La precedenza è intenzionale. I blocchi di stato mancanti influenzano l’interpretazione perché l’operatore non può stabilire il punto di partenza del ramo. Gli effetti non riconciliati bloccano la ripresa prima che venga presa in considerazione l'approvazione. L'approvazione e una configurazione bloccata rendono il ramo pronto, non integro. Dopo la ripresa, il risultato finale previsto necessita ancora di un verificatore deterministico. Modifica un campo e il risultato dovrebbe spostarsi in modo prevedibile. Aggiungi la chiave della coda di approvazione mancante al ripristino parziale e potrai avanzare. Contrassegnare un effetto ticket pendente riconciliato e la filiale potrà raggiungere il varco dell'autorità. Impostato outcomeVerified su falso dopo una risposta finale fluente e il risultato rimane false success . Ciò produce un’importante distinzione operativa: "Pronto per riprendere" significa che il confine di intervento è controllato. "Verificato" significa che la nuova filiale ha completato il lavoro previsto. Non unire questi stati in un unico badge verde. Ciò che l'esperimento non dimostra L'artefatto convalida una regola decisionale, non la fedeltà dello snapshot. Non può dimostrare che un browser sia stato ripristinato esattamente, che un LLM seguirà lo stesso percorso o che non si sia mai verificato un effetto collaterale non documentato. Una vera integrazione necessita di adattatori di stato e query di destinazione specifici del runtime. Anche lo studio AGDebugger ha una portata limitata: cinque intervistati formativi, 14 partecipanti allo studio, due compiti di studio e un prototipo di ricerca costruito su AutoGen. I suoi risultati giustificano il modello di interazione; non stabiliscono una riduzione del tasso di incidenti per ogni architettura multi agente. Il documento stesso identifica le sfide aperte, tra cui il disaccoppiamento della guida dall’implementazione di un agente e la determinazione se una modifica abbia avuto un effetto. Tali limiti rafforzano la regola operativa. Utilizza il reset interattivo per isolare un'ipotesi, non per creare certezza. Preservare il genitore, biforcare esplicitamente, ripristinare ciò che può essere dimostrato, etichettare ciò che non può, riconciliare gli effetti esterni, richiedere autorità e verificare il nuovo risultato a destinazione. Sidewisp è attualmente in anteprima privata.Gli adattatori di monitoraggio della produzione e l'esecutore di ripristino generalmente non vengono spediti. Il metodo qui è un modello operativo ispezionabile, non un'affermazione secondo cui Sidewisp controlla già i checkpoint o guida i team di agenti dal vivo. La direzione del prodotto Sidewisp mantiene l’autorità umana, le prove e la verifica dei risultati al centro di un recupero sicuro. Se oggi gestisci sistemi multi agente, inizia con un flusso di lavoro soggetto a guasti. Definire le chiavi di stato e il registro degli effetti esterni prima del prossimo incidente. Il primo checkpoint utile non è quello che può riprodurre più storia; è lui che può spiegare esattamente cosa è stato ripristinato, cosa è rimasto cambiato, chi ha autorizzato la filiale e come è stato verificato il risultato finale.