Monitoraggio dell'agente dopo una correzione: ripristino in cinque fasi

Un agente AI non viene recuperato solo perché un riavvio, un nuovo tentativo o un spinto è stato restituito con successo. Il default pratico per il monitoraggio di agent è quello di verificare il recupero in cinque fasi: registrare l'intervento autorizzato, confermare la disponibilità e la disponibilità, osservare i progressi specifici della missione, verificare indipendentemente il risultato promesso e controllare una finestra di stabilità per la ricaduzione. Fino a quando non è superato il controllo più rigoroso applicabile, mantenere lo stato come recovering , uncertain o needs human non sano. Questa distinzione è importante perché il comando di riparazione e il lavoro dell'utente vivono in strati diversi. Un processo può essere riavviato finché la sua credenziale rimane scaduta. Un battito cardiaco può riprendere mentre l'agente ripete la stessa chiamata. Un agente può dichiarare il completamento mentre il file, il biglietto, il messaggio o la distribuzione sono ancora assenti. Il recupero e' un'affermazione di prova, non un evento di attività. Sbarazzare un incidente con una scala di verifica Utilizzare una scala invece di uno stato verde. Ogni passo risponde a una domanda diversa e dovrebbe conservare il proprio tempo, la sua fonte e la sua fiducia. Passo Interrogazione Minime prove Indicare in caso di fallimento Intervento L'azione limitata è stata autorizzata e eseguita? riferimento di omologazione, tipo di azione, ID di tentativo, risultato di uscita o API needs human o intervention failed Raggiudicabilità Il tempo di esecuzione è contabile e pronto per il suo compito? battito cardiaco fresco più un controllo di preparazione per le attività unreachable o alive only Progresso Il lavoro utile è cambiato dopo l'intervento? artefatto monotono, unità completata, cursore, delta di prova o modifica di destinazione alive only o recovering Risultato Esiste il risultato promesso e soddisfa il suo controllo deterministico? ricerca, digestione, test, revisione o ricevimento in paese di destinazione false recovery , recovering o uncertain Stabilità Il fallimento diagnosticato è rimasto assente abbastanza a lungo da ricorrere? una finestra di osservazione specifica per il carico di lavoro senza sintomi ripetuti relapsed o recovered Il default ragionevole è conservativo: un agente che è raggiungibile ma non ha spostato un lavoro utile è alive only ; uno che ha ripristinato il lavoro misurabile ma non ha raggiunto il suo risultato è recovering ; solo le prove di risultato fresche che sopravvivono alla finestra di stabilità guadagnano recovered . Kubernetes utilizza una separazione correlata per i contenitori. Il suo documentazione della sonda dà a startup, vitalità e preparazione diversi compiti: vitalità può innescare un riavvio, mentre preparazione controlla se un contenitore dovrebbe ricevere traffico. Avverte anche che le sonde di vita incorrete possono causare fallimenti in cascata. L'analogia ha un limite: il compito dell'agente non è un Pod, ma il trasferimento delle lezioni di funzionamento: il processo deve essere riavviato e il lavoro è pronto non deve essere lo stesso test. Una finestra di stabilità non è un sonno arbitrario di cinque minuti. Scegli l'intervallo più breve in cui il fallimento originale ha avuto una giusta possibilità di ritorno. Per un ciclo che ripete ogni due chiamate di strumento, osservare almeno due opportunità di chiamate di strumento pulite. Per un'editrice programmata, aspetta fino alla data di scadenza del prossimo risultato. Per un fallimento della credenziale, esercitare il permesso interessato una volta con un controllo non distruttivo. La finestra dovrebbe essere abbastanza lunga da falsificare la riparazione, ma non così lunga da mantenere l'incidente ambiguo dopo l'esistenza di prove decisive. Registrare un tentativo di recupero, non una sequenza di comandi sciolta Legate la diagnosi, l'autorità, l'intervento e la verifica ad un unico identificatore di tentativo immutabile. Altrimenti, il monitor può unire un battito cardiaco da un riavvio manuale successivo a un impulso automatico precedente e segnalare un recupero che nessuno può spiegare. Un evento limitato alla privacy può sembrare così: Questo evento non richiede richieste, risposte, segreti, carichi utili di strumenti grezzi o percorsi assoluti. Ha bisogno dei limiti dell'azione e dei limiti delle prove. Mantenere action completed come ricevuta, non come verdetto di recupero. Questa regola è particolarmente importante per le API asincroni. RFC 9110 sezione 15.3.3 dice che una risposta HTTP 202 Accepted significa che il trattamento non è stato completato e potrebbe non verificarsi mai; la risposta dovrebbe descrivere lo stato attuale e indicare un monitor di stato. Se un adattatore di recupero dell'agente riceve 202 , segui quel monitor o consulta la destinazione. Non tradurre accettato in fisso. Le tracce hanno lo stesso limite di portata. OpenTelemetry definisce un span come un'unità di lavoro e il suo status come lo stato dell'operazione che segue. Un intervallo pulito restart agent dimostra che l'operazione non ha segnalato un errore. Non definisce se un rapporto sia stato prodotto, un biglietto è arrivato o una distribuzione serve alla revisione prevista. Legare la durata dell'intervento ai progressi successivi e alle prove dei risultati; non sovraccaricare il suo stato. Anche l'autorità deve essere registrata. Se un riavvio, un aggiornamento delle credenziali, l'invio di messaggi o il ritorno richiedono l'approvazione e non esiste alcuna approvazione valida, il monitor deve emettere needs human . Non deve tentare l'azione e poi chiedere il permesso retrospettivo. Il recupero richiede anche un nuovo tentativo e un budget di tempo. Un secondo intervento dopo il fallimento del primo è una nuova decisione, non un'invisibile estensione del comando originale. Riproduci il battito cardiaco falso positivo L'apparecchio di accompagnamento contiene otto casi sintetici post intervento: mancanza di autorità, errore di azione, attività solo a battito cardiaco, ripristino dei progressi, recupero stabile verificato, ricaduta, prove obsolete da verificatori e completamento dichiarato dall'agente con risultato di destinazione mancante. Eseguire il classificatore dalla directory degli artefatti: Il risultato decisivo è: La regola ingenua è stata completata e il battito cardiaco è presente. La scala riporta uno. Questo non è perché la scala è pessimista. Uno dei casi è veramente recovering : i progressi utili sono stati ripristinati e il risultato è ancora in attesa. Un altro ha nuove prove di risultati ma poi ripete il fallimento diagnosticato, quindi è relapsed . Un terzo ha un risultato che sembra verificato e che ha dieci minuti in un contratto di freschezza di due minuti, quindi è uncertain , non è fallito o sano. La soglia di freschezza di 120 secondo del dispositivo è illustrativa, non è una norma di produzione. La freschezza delle prove appartiene al verificatore. Una digestione dei file sul magazzino locale può essere decisiva immediatamente. Un indice di ricerca coerente potrebbe avere bisogno di un ritardo documentato. Se il verificatore stesso non è disponibile, conservare il uncertain e esporre il segnale mancante. Non riavviare l'agente solo per far diventare verde il cruscotto. Il capitolo Monitoraggio dei sistemi distribuiti di Google separa i sintomi dalle cause e la scatola nera dalle prove della scatola bianca. Essa tratta anche una risposta protocollare di successo con contenuti sbagliati come un errore che può richiedere test end to end. In questa scala di recupero, la ricevuta dell'intervento e la telemetria in tempo di esecuzione sono prove di causa in casella bianca; il controllo dei risultati nativi della destinazione è il test dei sintomi in casella nera. Entrambe sono utili, ma solo quest'ultima risolve ciò che l'utente ha effettivamente perso. Trasformare la verifica del recupero in un contratto operativo Per ciascuna classe di attività monitorata, definire la scala prima di un incidente: le dichiarazioni di mancato intervento che consentono un intervento limitato; la persona o la politica autorizzata ad approvare ciascuna azione; l'azione reversibile e i suoi limiti di impegno, di tempo e di costi; il controllo della prontezza in tempo di esecuzione dopo l'azione; un campo di progresso utile con una direzione attesa; il verificatore deterministico dei risultati, la sua scadenza e il suo limite di freschezza; l'opportunità di ricorrenza che chiude la finestra di stabilità; il percorso di rottura o di escalation quando il tentativo fallisce. Tenete il vocabolario del verdetto piccolo. Needs human significa mancanza di autorità, segreto o decisione irreversibile. Intervention failed significa che l'azione approvata non è stata completata. Alive only significa che il tempo di esecuzione è pronto, ma non c'è un utile progresso. Recovering significa che il progresso è stato ripristinato mentre il controllo di risultato o di stabilità rimane aperto. Uncertain significa che mancano o non esistono prove decisive. False recovery significa il termine di scadenza del risultato trascorso senza il risultato promesso. Relapsed significa che il sintomo originale è stato restituito. Recovered significa che l'esito specifico dell'attività è verificato e che la finestra di ricorrenza è rimasta pulita. Ci sono dei limiti onesti. Alcuni risultati non possono essere verificati in modo deterministico. Il cliente ha accettato l'analisi può richiedere una decisione umana; il riassunto è buono può richiedere una rubrica la cui affidabilità viene misurata. Una destinazione può anche commettere un effetto collaterale prima del termine di risposta. Riconciliarsi con una chiave idempotency o una ricerca indipendente prima di riprovare. Quando le prove non possono risolvere lo stato, mantenete visibile l'incertezza. Sidewisp è attualmente in anteprima privata. Gli adattatori di monitoraggio della produzione, le analisi dei costi dei token e l'esecuzione del recupero non vengono generalmente spediti. La direzione prevista è uno strato di salute accanto ai tempi di esecuzione esistenti che rende esplicita la diagnosi, l'autorità, la freschezza delle prove, i progressi utili e la verifica dei risultati. Non dovrebbe diventare un gateway modello obbligatorio o un fissatore autonomo. Se quel modello operativo si adatta ai tuoi agenti, Unisciti all' anteprima privata. Fonti Kubernetes: vivacità, preparazione e sonde di avvio Google SRE Book: monitoraggio dei sistemi distribuiti RFC 9110: HTTP Semantics, 202 Accettato OpenTelemetry: Tracce