Monitoraggio degli agenti AI: una politica di segnalazione silenziosa per i fallimenti reali

Il monitoraggio dell'agente AI dovrebbe interrompere una persona solo quando può indicare un guasto in corso, mostrare le prove e indicare una prossima azione limitata. Una chiamata di strumento, un token spike o una lunga traccia possono aiutare a spiegare un problema; nessuna di queste prove dimostra che l'agente ha smesso di fornire un lavoro utile. Per una prima politica pratica, monitorare tre cose separatamente: 1. Runtime freshness: ha iniziato la corsa programmata, e il suo battito cardiaco è ancora attivo? 2. Usuoso progresso: le prove specifiche delle attività sono cambiate entro la finestra prevista? 3. O verifica dei risultati: esiste il consegnabile promesso e riesce a superare il controllo di accettazione? Allora indirizza il risultato. Pagina per un fallimento persistente e rilevante per l'utente. Creare un biglietto o una notifica del proprietario per un'attesa legittima o un'indagine lenta. Supprimere un singolo campione cattivo e un lavoro sano. Questo articolo trasforma questa regola in un contratto di piccoli eventi e in un sistema eseguibile di otto casi. La pagina dovrebbe indicare la promessa rotta Un agente può essere online mentre il suo lavoro è sbagliato. Può anche essere silenzioso perché sta correttamente aspettando l'approvazione. Per questo il funzionamento dei processi è troppo debole per il monitoraggio degli agenti e nessuna chiamata di strumenti recente è troppo rumorosa per la paging. Il capitolo Monitoraggio dei sistemi distribuiti di Google trae una linea utile tra le prove della scatola bianca e i sintomi della scatola nera. La telemetria interna è essenziale per la diagnosi, ma una pagina dovrebbe rappresentare un chiaro guasto che colpisce il servizio. Il capitolo osserva anche che una risposta protocollare di successo può comunque essere un errore quando il contenuto restituito è sbagliato. Per un agente, il fallimento corrispondente è una corsa che dice completed mentre l'artefatto richiesto è assente o invalo. Inizia scrivendo un contratto di monitoraggio per flusso di lavoro: Campo del contratto Esempio per un agente di deposito Perché esiste Inizio previsto I giorni feriali alle 09:00 UTC, grazia di cinque minuti Rilevare un programma mancato Ritmo cardiaco Osservazione del tempo di esecuzione non superiore a dieci minuti rilevare una corsa irraggiungibile o morta Evidenza del progresso Nuovo commit, cambiamento del risultato del test o blocco registrato Movimento separato dall'attività ripetuta L'attesa legittima Identificazione di omologazione più proprietario responsabile Continuare a aspettare lavoro fuori dalla pagina della bancarella Richiesta di completamento Lo stato di esecuzione è completed Registrare quello che l' agente ha dichiarato Predicato di risultato Il ramo bersaglio contiene il passaggio dei controlli commit e richiesti Verificare indipendentemente il risultato promesso L'ultima riga dovrebbe essere deliberatamente specifica. Una risposta generata può essere sufficiente per un'attività di chat. Ha creato un file non è sufficiente per un compito di rilascio se il file è invalido, non pubblicato o allegato alla destinazione sbagliata. Il monitor non può dedurre questo contratto da un intervallo; il proprietario del flusso di lavoro deve definirlo. Strumento la corsa senza trattare le spensioni come il completamento Le convenzioni semantiche generative AI definiscono ora le operazioni di agente e di flusso di lavoro come invoke agent , invoke workflow , plan e execute tool . L'attuale Documento di spesa di agente fornisce anche campi come gen ai.agent.id , gen ai.agent.name , gen ai.agent.version e error.type . Questi sono utili campi di correlazione e di diagnosi. Non sono uno schema di risultato. Il documento è contrassegnato Development , quindi è importante fissare una versione. Esso avverte anche che i messaggi di input e output catturati possono contenere informazioni sensibili. Puoi implementare la politica di allarme qui sotto senza memorizzare richieste, risposte, segreti o carichi utili di strumenti. Un evento compatto può sembrare così: Mantenere runId stabile attraverso il programmatore, la telemetria del tempo di esecuzione e il controllo degli esiti. Conservare un agente di bassa cardinalità o un nome di flusso di lavoro per l'aggregazione. Mettete gli identificatori diagnostici dietro l'allarme piuttosto che dentro la sua identità. Altrimenti, ogni nuovo tentativo può creare un nuovo incidente per la stessa promessa rotta. La pista superiore dell'illustrazione è occupata ma circolare. La pista inferiore cambia di stato e produce un risultato verificabile. Questa distinzione è al centro della politica: l'attività è la prova del debug; i progressi e i risultati decidono la salute. Testare la politica con otto casi inconvenienti L'artefatto che accompagna questo articolo utilizza un record NDJSON per ogni corsa osservata. Esso comprende il completamento verificato, il falso successo, un programma mancato, un tempo di esecuzione irraggiungibile, un'attesa legittima di approvazione, una corsa persistente senza progressi, un campione negativo transitorio e un lavoro attivo sano. Eseguilo dalla directory degli artefatti: Prodotto atteso: L'evaluatore utilizza una priorità fissa. Un risultato fallito vince la telemetria obsoleta perché il risultato rotto è già noto. Un programma mancato vince quando la corsa non è mai iniziata. Un tempo di esecuzione irraggiungibile vince una diagnosi senza progresso perché il monitor manca di prove di esecuzione fresche. Una esplicita attesa vince la regola dello stall. Solo allora un timestamp di progresso obsoleto diventa stuck . Questo impedisce ad un registro di aprire tre incidenti. Inoltre rende ogni decisione esplicabile: l'output può indicare la condizione, il timestamp della prova e la soglia che è stata superata. Le soglie incluse sono esempi, non default universali: cinque minuti dopo l'inizio previsto; dieci minuti senza battito cardiaco; quindici minuti senza progressi utili; due campioni negativi consecutivi per le condizioni della pagina; tre campioni negativi consecutivi per un biglietto senza progresso. Un agente di codifica che esegue una correzione di due minuti e un agente di ricerca che legge documenti per un'ora non dovrebbero condividere quei numeri. La parte importante è la sequenza e il requisito di persistenza, non la durata particolare. Aggiungere persistenza prima dell'escalation Le regole di allarme di Prometheus forniscono due meccaniche pertinenti. La clausola for documentata mantiene in sospeso una nuova condizione attiva fino a quando non è rimasta attiva per un periodo di tempo. keep firing for può mantenere aperto un allarme dopo l'ultimo campione di corrispondenza per ridurre il flapping o la risoluzione falsa causata da dati mancanti. Le stesse idee si applicano anche se non si utilizza Prometheus: richiedono ripetute osservazioni prima di richiedere il silenzio; registrare il primo periodo di violazione separatamente dall'ultimo campione; segnalazioni di gruppo per flusso di lavoro e promessa non rispettata, non per ripetizione o tracciamento; mantenere aperto l'incidente fino a quando nuove prove confermano il recupero; ri pagina solo quando la gravità o i risultati interessati cambiano. Non mettere tutte le condizioni dietro lo stesso ritardo. Un'affermazione di completamento il cui artefatto richiesto non riesce a verificare la determinazione è una prova più forte di un battito cardiaco mancato. Al contrario, un punteggio di qualità LLM vicino a una soglia è una prova più debole e può appartenere a una coda di revisione piuttosto che a un pager. Una tavola di routing tranquilla è più utile di un lungo inventario metrico: Condizione osservata Rota predefinita Condizione chiara Completamento richiesto; il controllo dei risultati richiesto non riesce dopo la sua grazia di verifica Pagina quando rilevante per l'utente, altrimenti biglietto Il risultato è corretto La corsa non è iniziata dopo due controlli. Pagina quando la corsa ha un obbligo corrente Iniziazioni di esecuzione o aspettativa di pianificazione è modificata esplicitamente Il battito cardiaco è stagnato per due controlli. Pagina quando il lavoro attivo è influenzato Un battito cardiaco fresco e un nuovo campione di salute . L'approvazione di nome, la decisione segreta o irreversibile è in sospeso Avvisare il proprietario responsabile o creare un biglietto La dipendenza viene fornita o il lavoro viene cancellato L'attività continua ma la prova del compito non è cambiata per tre controlli Biglietto d'inchiesta Si registrano cambiamenti di progresso o una legittima attesa Un campione obsoleto o mancante Nessuna notifica umana Rivalutazione sul campione successivo Lavorare le casse di bordo prima di scegliere uno strumento Gli errori delle politiche di allarme si verificano solitamente ai confini, non nel sentiero felice. Verifica ritardo: Un editore può segnalare il completamento secondi prima di aggiornamenti di CDN o di indici di ricerca. Date al risultato un periodo di grazia documentato, poi verificate di nuovo. Non trattare un sonno arbitrario come prova; il secondo controllo deve ispezionare la vera destinazione. Human waits: memorizza sia la dipendenza che il suo proprietario. waitingOn: "approval" senza un responsabile nasconde semplicemente la bancarella. Una attesa può rimanere sana per l'agente creando un compito umano in ritardo. Lungo lavoro silenzioso: una fase di ricerca o di compilazione può essere sana senza frequenti eventi con gli strumenti. Scegli prova di progresso che il tempo di esecuzione possa emettere in modo sicuro: un shard completato, un hash di contenuto modificato, una nuova fase di prova o una scadenza di fase limitata esplicita. Retries: riprovazioni possono mascherare i guasti dei fornitori mentre gonfiano attività e costi. Gruppiarli sotto la stessa corsa e registrare il tentativo di contare come contesto diagnostico. Un nuovo tentativo non deve riimpostare il tempo di prima violazione, a meno che non produca un utile progresso. Signali sconosciuti: la telemetria mancante non è verde. Segnalatelo come non disponibile ed evitare il recupero automatico quando il monitor non può distinguere tra bloccato e disconnesso. Una diagnosi incerta dovrebbe richiedere l'ispezione, non eseguire una correzione distruttiva. Recovery: chiudere un incidente perché un comando di riavvio restituito zero ripete il problema di falso successo. Utilizzare lo stesso risultato o progresso predicate che ha aperto l'incidente. Il recupero è completo solo quando le nuove prove dimostrano che il lavoro si sta muovendo o che esiste il risultato promesso. Che cosa questo esperimento dimostra e cosa non dimostra La cornice rende falsificabile una tesi ristretta: con la precedenza documentata e le soglie, gli otto casi forniti producono esattamente tre pagine, due biglietti e tre notifiche soppresse. Puoi modificare un timestamp o un numero di violazioni e vedere il cambiamento di percorso. Non dimostra che le soglie si adattino al tuo carico di lavoro. I casi sono sintetici e l'evaluatore legge i documenti già normalizzati. Le vere integrazioni devono gestire la distorsione dell'orologio, la consegna duplicata, i campioni in ritardo, la politica del programmatore, i fuso orario e le interruzioni del collezionista. Hanno anche bisogno di un limite di privacy per qualsiasi cosa derivante da richieste o chiamate di strumento. La politica non sostituisce le tracce, le valutazioni o i registri del tempo di esecuzione. Questi segnali spiegano il motivo per cui un risultato è fallito. Inoltre non garantisce che un predicato specifico per un'attività catturi ogni problema di qualità. Alcuni risultati sono deterministici, come un file hash o un risultato di test; altri richiedono campionamento, revisione o un processo di valutazione con un livello di incertezza esplicito. Il più importante è che la politica non dovrebbe autorizzare il recupero autonomo. Un monitor può consigliare un ripetizione limitata o preparare un passo di riparazione, ma azioni irreversibili, accesso segreto e diagnosi incerte richiedono ancora autorità umana. Trasformare il dispositivo in una prova di accettazione Prima di collegare una destinazione di allarme reale, sostituire i casi sintetici con esempi recenti di un flusso di lavoro: 1. Definire l'inizio atteso e il ritardo accettabile. 2. Scegli un battito cardiaco prodotto al di fuori della risposta del modello. 3. Cita la più piccola prova di un utile progresso. 4. Registrare i legittimi motivi di attesa e i proprietari. 5. Implementare il predicato di risultato alla destinazione effettiva. 6. Riproduci noti casi sani, in attesa, bloccati, mancati, irraggiungibili e falsi. 7. Eseguire la politica silenziosamente abbastanza a lungo da rivedere pagine false e incidenti mancati. Solo dopo tale revisione dovrebbe essere attivato un percorso di pagina. Tenere la prova grezza, la decisione, la versione della soglia e la verifica della risoluzione ispezionabili in modo che l'operatore possa capire perché il monitor ha parlato. Sidewisp è progettato attorno a questo limite di salute: rilevare, spiegare, chiedere autorità quando necessario, e verificare il risultato. Sidewisp è attualmente in anteprima privata. Gli adattatori di monitoraggio della produzione e il motore di recupero non sono generalmente spediti oggi. Se questo approccio corrisponde al modo in cui si operano gli agenti, si può descrivere Partecipa alla visualizzazione privata e i casi di esecuzione e di guasto che si devono coprire.