Un approccio di debug unificato tramite sinergia multi-agente basata su LLM: verifica della riparazione

Un approccio di debug unificato tramite la sinergia multi agente basata su LLM è utile solo quando i suoi agenti lasciano prove che sopravvivono alla loro stessa conversazione. Un localizzatore può sembrare certo, un riparatore può emettere una patch e un revisore può approvarla mentre il guasto originale non è mai stato riprodotto o il caso limite decisivo non è mai stato testato. L'impostazione predefinita ragionevole è quindi: lasciare che gli agenti specializzati propongano e contestino una riparazione, ma promuovano la patch solo dopo che una ricevuta collegata dimostri la riproduzione, la discendenza, la copertura del test, la qualità dell'oracolo e la revisione. Questa regola operativa segue l'architettura del documento FixAgent senza confondere i risultati della ricerca con una garanzia di produzione. Il documento separa la localizzazione dei guasti, la generazione delle patch e l'analisi post errore tra agenti specializzati. Distingue inoltre una patch plausibile che supera i test disponibili da una patch corretta stabilita tramite verifica manuale. Questa distinzione è il confine della salute. Cosa dimostra il risultato FixAgent e cosa no Il design pubblicato di FixAgent è più specifico di "chiedere a diversi modelli di eseguire il debug". La sua metodologia utilizza un localizzatore, un riparatore e un rivisitatore, oltre a un agente di creazione di input per test aggiuntivi. Gli agenti spiegano il loro ragionamento, tengono traccia delle variabili importanti e trasmettono a valle i risultati della fase precedente. Se la patch generata fallisce, è possibile ripetere la fase di riparazione con il feedback del test. L'articolo riporta ottimi risultati su QuixBugs, Codeflaws e ConDefects. Questi sono i risultati della ricerca nell’ambito dei set di dati, dei modelli, dei suggerimenti e della procedura di verifica del documento. Non stabiliscono che sia sicuro unire una patch arbitraria del repository. Due dettagli della fonte primaria cambiano la decisione operativa: 1. Il documento definisce una patch plausibile come quella che supera i test scritti da esseri umani, mentre la correttezza richiede una verifica manuale separata. 2. La sua sezione limitazioni afferma che l'agente di input di test aggiuntivo non può calcolare da solo gli output previsti. Un input generato senza un oracolo affidabile non è un test completo. L'implementazione Rudra rilasciata rende il confine ispezionabile. Il suo corridore multi round tratta zero casi di guasto osservati come una riparazione riuscita e restituisce il flag al lanciatore. Ciò è appropriato per il ciclo di test di un esperimento. Un operatore deve ancora chiedere quali suite sono state eseguite, se il loro oracolo è affidabile, se il risultato appartiene a questa patch e se un revisore ha accettato la differenza effettiva. La lezione non è che la revisione degli agenti sia inutile. Il disaccordo tra specialisti può rivelare una cattiva localizzazione o una patch debole. La lezione è che il testo di un agente non deve essere l’unica prova consumata da quello successivo. Collega ogni fase di debug con una ricevuta di riparazione Una ricevuta di riparazione minima può essere priva di contenuto. Non necessita di suggerimenti, codice sorgente, output di test o ragionamento del modello. Ha bisogno di identità stabili e di verdetti che permettano a una porta umana o deterministica di ricostruire il confine: Confine Campi minimi dello scontrino Il fallimento cattura Riproduzione ID esecuzione, hash del comando, errore originale osservato Una patch per un bug che non è mai stato riprodotto Localizzazione ID esecuzione, revisione del codice sorgente, timestamp della prova Un risultato del localizzatore riutilizzato da un'altra revisione Toppa hash della patch, revisione principale, conteggio delle righe modificate Una riparazione vuota, obsoleta o non correlata Convalida ID suite richiesti, ID suite osservati, conteggio non riuscito "Tutti i test superano" quando una suite richiesta non è mai stata eseguita Oracolo verificato, sconosciuto o contestato Casi generati senza risultati attesi attendibili Recensione approvato, rifiutato o di proprietà attendere Modello di accordo scambiato per autorità di fusione Risultato richiesta di completamento e ricevuta di destinazione Un'esecuzione completata la cui patch non è stata verificata o consegnata L'ID della corsa è particolarmente importante. Una risposta sulla localizzazione da parte di run old non deve giustificare silenziosamente una patch da parte di run 42 . L'hash della patch è altrettanto importante: un record di test verde per un differenziale non può essere allegato a un ricampionamento successivo. Si tratta di una derivazione ordinaria, ma i flussi di lavoro degli agenti spesso la perdono perché il contesto conversazionale fa sì che i messaggi vicini sembrino correlati. Ecco la forma utilizzata dal dispositivo di accompagnamento: Le stringhe sono identificatori, non contenuto archiviato. In un sistema reale, gli hash dovrebbero essere calcolati su input e artefatti canonici e il record del test dovrebbe includere la versione dello strumento, la revisione della configurazione, l'ora di inizio, l'ora di fine e la provenienza di uscita. Segreti, istruzioni, contenuto dei file e argomenti relativi agli strumenti non elaborati dovrebbero rimanere fuori dalla ricevuta sanitaria. Riproduci nove stati scomodi prima di fidarti del verde L'artefatto dell'articolo contiene nove casi sintetici e un classificatore Node.js in ordine di precedenza. Eseguilo dalla directory del rapporto dell'articolo: Il risultato osservato è: I casi sono volutamente scomodi: UNREPRODUCED interrompe il flusso di lavoro prima che una patch sicura possa nascondere una linea di base mancante. LOCALIZATION DRIFT rileva una ricevuta del localizzatore da un'esecuzione diversa. NO EFFECTIVE PATCH rifiuta un hash mancante o una modifica della riga zero. TEST GAP segnala una suite di integrazione richiesta che non è mai stata eseguita, anche quando le suite osservate sono verdi. ORACLE UNCERTAIN preserva l'incertezza quando gli input generati non hanno output attesi verificati. REVIEW REJECTED impedisce a una toppa tecnicamente verde di diventare approvata. WAITING rappresenta una dipendenza legittima solo quando la ricevuta nomina un proprietario e una scadenza. FALSE COMPLETE supera una richiesta di completamento quando qualsiasi test osservato continua a fallire. VERIFIED REPAIR richiede che tutti i confini precedenti siano d'accordo. L'ordine conta. Una richiesta di completamento non può sovrascrivere un test fallito. Un contatore con zero guasti non può sovrascrivere una suite mancante. Un caso limite generato non può stabilire la correttezza senza un oracolo. Un'attesa di revisione non dovrebbe essere classificata come stallo quando ha un proprietario e una scadenza. Questo esperimento mostra anche perché un singolo punteggio di integrità è un artefatto di debug scadente. Entrambi i casi suite gap e verified repair riportano zero test falliti, ma i loro stati operativi differiscono perché non è mai stata eseguita la suite di integrazione richiesta. Le prove mancanti sono più importanti del segnalino verde. Aggiungi il gate a un flusso di lavoro con agente di codifica reale Inizia con un piccolo limite di promozione anziché ricostruire la struttura dell'agente: 1. Blocca la revisione dell'input. Registra il commit del repository o lo snapshot dell'area di lavoro prima della localizzazione. 2. Riprodurre l'errore. Memorizzare un hash di comando/configurazione e un risultato strutturato. Se la riproduzione è instabile, etichettala come incerta e non considerare un'eventuale corsa verde come prova di riparazione. 3. Collegare ciascun trasferimento. Richiedere che le ricevute del localizzatore, del riparatore e del revisore facciano riferimento alla stessa esecuzione e revisione principale. 4. Ricampionamento vincolato. Il ciclo di feedback del documento FixAgent è utile, ma i tentativi consumano budget e possono modificare la patch. Assegna a ogni nuova patch il proprio hash, limiti i tentativi e invalida le prove dei test precedenti quando la differenza cambia. 5. Dichiarare le suite richieste prima dell'esecuzione. Altrimenti un agente può ridefinire "tutti i test" dopo aver visto i risultati. 6. Esecuzione separata del test dall'autorità Oracle. Gli input generati possono migliorare la copertura, ma una persona, una specifica, un'implementazione di riferimento o una regola deterministica indipendente devono fornire il risultato atteso. 7. Mantenere l'autorità di fusione o di distribuzione sotto controllo umano. Una ricevuta approvata può preparare la decisione; non dovrebbe ampliare il permesso dell’agente. 8. Verificare la destinazione. Se l'attività consisteva nell'aprire una richiesta pull, aggiornare un problema o produrre un artefatto di rilascio, verificare la destinazione in modo indipendente. Una patch locale è un'attività, non necessariamente il risultato richiesto. Per una pausa di approvazione, utilizza un record esplicito: Non eseguire il cercapersone semplicemente perché l'agente è silenzioso mentre il record è aggiornato. Effettuare l'escalation quando la scadenza scade, il proprietario manca o l'esecuzione ripresa non produce nuove prove. L'attesa non è bloccata; l'attività ripetuta senza un delta dei risultati non è un progresso. Il confine per Sidewisp La tesi sostenibile è ristretta: il debug multi agente diventa affidabile dal punto di vista operativo quando i risultati specialistici vengono uniti a prove di riparazione deterministica e il verde viene negato quando mancano la derivazione, la copertura, la qualità dell'oracolo, la revisione o le prove dei risultati. Il dispositivo a nove casi falsifica la scorciatoia “zero guasti osservati significa riparazione verificata” perché due casi con zero guasti raggiungono verdetti diversi. Questo è uno schema operativo, non un'affermazione secondo cui Sidewisp attualmente esegue FixAgent o monitora le riparazioni dell'agente di codifica. Sidewisp è attualmente in anteprima privata. È una piattaforma di integrità dell'agente AI, ma il motore di monitoraggio della produzione, gli adattatori di runtime e l'esecutore di ripristino non vengono generalmente spediti. Il livello di salute previsto è rilevante qui perché distingue il progresso utile, l'attesa legittima, il falso completamento e le prove incerte lasciando l'autorità di fusione con l'umano. Utilizzare prima la ricevuta in un flusso di lavoro di debug ripetuto. Se non riesce a distinguere una suite mancante da una riparazione verificata senza leggere la trascrizione, le prove del contratto sono ancora troppo deboli.