AI Agente Osservabilità: fermare il verde stale con una prova di freschezza

Il verdetto sanitario dell'agente AI deve scadere. Se una scheda di controllo dice salute senza mostrare quando le sue prove decisive sono state osservate, può mantenere un green runtime disconnesso molto tempo dopo che i fatti sono cambiati. Il default pratico è un certificato di freschezza valutato in un momento esplicito. Per ogni segnale richiesto, tenere il tempo dell'evento sorgente, il tempo di osservazione del collettore, una sequenza in aumento monotono e un'età massima specifica per l'attività. Marcare la corsa salutare solo quando ogni segnale richiesto è presente, fresco, non riprodotto e coerente con il risultato dichiarato. Se le prove richieste scadono, il verdetto diventa unknown non sano e non fallisce automaticamente. Questo articolo rende questa regola verificabile. La cornice di cinque casi che accompagna non cambia il modello, il venditore di traccia o l'agente. Cambiano solo l'età, l'orario di arrivo, la sequenza o il valore di risultato e mostrano perché uno stato verde memorizzato non può essere affidabile da solo. Un verdetto sanitario ha bisogno di un termine di scadenza I sistemi di osservabilità sono buoni nel mantenere l'ultimo valore. La salute dell'agente richiede di sapere se quel valore è ancora ammissibile. Immaginate un agente di ricerca con tre campi verdi: battito cardiaco: ok ; progresso utile: 3 sources accepted ; controllo dei risultati: brief schema valid . Questi valori descrivono diverse promesse. Un battito cardiaco potrebbe scadere dopo due intervalli di raccolta. Il progresso può ragionevolmente rimanere invariato durante una fase di lettura limitata. Una ricevuta di risultato può rimanere valida per sempre per la corsa specifica, ma deve comunque essere unita a quella corsa piuttosto che ereditata da ieri. Un singolo timestamp globale ultimo aggiornato cancella tali distinzioni. Il certificato più sicuro contiene una scadenza per ogni fatto richiesto: Il minimo conta. Un nuovo ricevimento di risultato non può dimostrare che il tempo di esecuzione è attualmente raggiungibile; un nuovo battito cardiaco non può dimostrare che l'artefatto promesso esiste. Quando il primo segnale richiesto scade, il verdetto sano combinato scade con esso. Questo non è un requisito innovativo inventato per i Master in Giurisprudenza. Kubernetes utilizza l'API Lease per i battiti cardiaci dei nodi: ogni kubelet aggiorna un Leases spec.renewTime , e il piano di controllo utilizza quel timestamp per determinare la disponibilità dei nodi. La Kubernetes Documentazione di locazione alla revisione sorgente 9a8df52 ufficiale è utile qui perché tratta la disponibilità come una pretesa temporanea, non come una proprietà permanente dell'ultimo aggiornamento con successo. Prometeo rende esplicito un confine correlato. Il suo documentazione di consultazione alla revisione ab225f6 descrive un lookback predefinito di cinque minuti e un comportamento di serie obsoleta. Che cinque minuti di default è una regola di query di Prometheus, non un tempo limite universale appropriato per gli agenti. Il principio trasferibile è che un vecchio campione deve alla fine smettere di rispondere a una domanda corrente. Utilizzare due orologi e un tempo di valutazione Un evento può avere almeno due momenti rilevanti: quando la fonte dice che è avvenuto e quando il sistema di raccolta l'ha osservato. Tieni entrambi. La stabilità OpenTelemetry Logs Modello di dati alla revisione f62b146 definisce Timestamp come il tempo misurato dall'orologio di origine e ObservedTimestamp come l'ora in cui il sistema di raccolta ha osservato l'evento. Dice anche che il timestamp della fonte potrebbe essere assente. Questa separazione impedisce a un campo sovraccarico di pretendere di rispondere all'ordine degli eventi, ritardare il trasporto e monitorare la freschezza in una volta. Per un certificato sanitario, valutare l'età in un dominio di orologio: Utilizzare source time per ordinare gli eventi sorgente solo quando si conosce il limite di sincronizzazione dell'orologio sorgente. Sottoprendere un orologio host da un orologio collettore e chiamare la latenza di rete risultante è ingiustificato senza tale limite. Se un orologio portatile è veloce di quattro minuti, un battito cardiaco appena raccolto può sembrare provenire dal futuro; se è lento, un agente vivo può sembrare obsoleto. collector time ha un significato più ristretto ma affidabile: il monitor aveva questa prova in quel momento. Non può dimostrare quando l'azione sottostante è realmente avvenuta, ma può dimostrare se la visione del monitor è recente. Il ritardo della raccolta delle registrazioni separatamente quando la fonte fornisce orologi affidabili o ricevuta di trasporto. Un tempo di valutazione è altrettanto importante. Senza evaluated at , un certificato non può essere riprodotto in una revisione di prova o di incidente. Fresh now non è una dichiarazione verificabile. Fresco a 2026 07 26T00:42:00Z in base alla politica freshness v1 è. Costruire un certificato, non una cache di valore ultimo Il record più piccolo utile è deliberatamente semplice: Ogni campo chiude una specifica lacuna: Campo Che cosa impedisce run id accettare il risultato di un'altra corsa evaluated at un movimento, irriproducibile ora collector time conservazione delle prove dopo la finestra di freschezza del monitor source time perdendo l'ordine dell'evento sorgente quando l'orologio è affidabile sequence accettare un battito cardiaco riprodotto o fuori ordine come nuovo max age s applicazione di un tempo arbitrario a segnali diversi required trattare in silenzio la mancanza di prove decisive come facoltativa policy cambiamento delle soglie senza un percorso di revisione Non dedurre il progresso dalla sequenza dei battiti cardiaci. Un ciclo può emettere battiti cardiaci perfetti senza produrre alcun cambiamento utile. Dategli il battito cardiaco, il progresso, la dipendenza dall'attesa e i risultati dei loro record di prove. L'omologazione denominata può essere nuova e valida mentre il progresso è intenzionalmente sospeso; il certificato deve classificare quelle in esecuzione come waiting , non bloccate. La precedenza del verdetto dovrebbe preservare l'incertezza: 1. un nuovo guasto deterministico produce attention ; 2. un risultato di segnale richiesto mancante, obsoleto, in arrivo futuro o riprodotto unknown ; 3. una nuova dipendenza denominata dà waiting ; 4. solo prove complete, fresche e correnti possono produrre healthy . Questo ordine non nasconde il fallimento della telemetria mancante. Un nuovo risultato fallito e' una prova piu' forte di un battito cardiaco stagnato. Al contrario, solo le prove obsolete non dimostrano che l'agente abbia fallito; dimostrano che il monitor non può attualmente sostenere un'affermazione sana. Conduci cinque contro esempi Il dispositivo che accompagna questo articolo contiene cinque piste valutate contemporaneamente: fresh run ha tre segnali freschi, avanzati e di successo; stale green porta ancora heartbeat: ok , ma il collezionista l'ha visto per l'ultima volta 240 secondi fa contro un limite di 120 secondi; delayed batch contiene una registrazione dei progressi il cui tempo di raccolta è dopo il tempo di valutazione, in modo che le prove non fossero ancora disponibili; replayed sequence ripete una sequenza di risultato piuttosto che procedere all'avanzamento; failed outcome ha nuove prove che il controllo degli artefatti richiesto non è riuscito. Eseguire il classificatore Node.js 20+: La sua uscita esatta è: La tesi falsificabile è ristretta: modificare solo l'ammissibilità delle prove deve essere in grado di revocare un verdetto verde. fresh run e stale green contengono entrambi heartbeat: ok ; differiscono solo le età del collezionista. Se una scheda di controllo presenta ancora entrambi i dati come sani al momento della valutazione, viene visualizzato un valore memorizzato in cache piuttosto che una conclusione attuale sulla salute. Il caso delayed batch gestisce un errore più sottile. La telemetria ricaricata può migliorare la diagnosi storica, ma non deve riscrivere ciò che il monitor sapeva al momento della decisione precedente. Confrontare collector time con evaluated at mantiene la riproduzione dell'incidente onesta. Il controllo della sequenza blocca una falsa freschezza diversa. Una riconnessione in coda può ridire l'ultimo battito cardiaco con un nuovo tempo di arrivo del trasporto. Se il monitor aggiorna l'età utilizzando solo l'arrivo, la riproduzione fa sembrare corrente una fonte morta. Richiede una sequenza sorgente, un identificatore di avvio o un altro token monotono in cui il runtime possa fornire uno. Attraverso i riavviamenti, abbinare la sequenza con un ID di incarnazione in modo che un reset legittimo non sia scambiato per riproduzione. L'apparecchio è un set di contrasemplari ispezionabile, non un punto di riferimento di produzione. Non stima i tassi falsi positivi, non conta ogni fila o non dimostra che i limiti esemplari si adattano al tuo carico di lavoro. Il suo valore è che ogni verdetto ha una spiegazione di un campo e può essere modificato modificando un timestamp o una sequenza. Calibrare la freschezza intorno alle promesse Scegliere i limiti dal comportamento previsto del flusso di lavoro, non da un pannello di controllo universale predefinito. Per un intervistato che si aspetta ogni 60 secondi, un limite di battito cardiaco potrebbe essere due intervalli mancati più il nervosismo misurato. Per una fase del compilatore che dovrebbe funzionare in silenzio per otto minuti, il progresso può utilizzare una scadenza di fase piuttosto che una regola di cambiamento di 60 secondi. Per una ricevuta di risultato legata in modo immutabile a una corsa e a un hash di artefatto, la freschezza può significare che appartiene a questa corsa e è stata verificata dopo il suo inizio, non è stata creata negli ultimi cinque minuti. Testare questi confini prima di allarmare: normale agitazione del programmatore; riavvio del collezionatore e backlog della coda; la distorsione dell'orologio ospitante; la consegna duplicata e fuori ordine; riavvio del tempo di esecuzione con una sequenza di ripristino; una legittima attesa di approvazione umana; un comando completato il cui controllo di destinazione fallisce; un'interruzione del monitor mentre l'agente continua a lavorare. Registrare la prima violazione separatamente dall'ultima osservazione. Occorre perseverare quando le prove sono rumorose, ma non lasciare che un nuovo battito cardiaco ripresenti un orologio di progresso obsoleto. Elimina un incidente solo con nuove prove che rispondano alla condizione che l'ha aperto. Un processo ripreso non è la prova che la relazione mancante esiste ora. C'è un costo per questo rigore: più campi, politica per flusso di lavoro e uno stato esplicito di unknown . Il vantaggio è quello di evitare uno stato di fiction green più costoso supportato da prove che il monitor non ha più il diritto di utilizzare. Inizia con i tre segnali che possono cambiare l'azione: accessibilità, progresso utile o dipendenza e verifica dei risultati. Mantenere i limiti della diagnosi e delle affermazioni sui prodotti Un certificato di freschezza si trova sopra i registri, le tracce, le metriche, i registri degli scheduratori e i controlli di destinazione. Non li sostituisce. Essa registra quali prove sono state ammissibili per una decisione sanitaria e quando essa scade. Inoltre, non dovrebbe innescare da solo un recupero irreversibile. unknown chiede il ripristino delle prove o l'ispezione umana. attention può giustificare una raccomandazione limitata, ma segreti, cambiamenti distruttivi e diagnosi incerte richiedono ancora autorità esplicita. Il recupero è completo solo dopo un nuovo progresso o l'osservazione del risultato previsto. Questo risolve la domanda originale: l'osservabilità dell'agente AI non dovrebbe mai mantenere lo stato sano indefinitamente. Date a ogni segnale decisivo un timestamp del collezionista, l'età massima connessa alla politica, l'identità attuale e la guardia di replay; valutateli in un istante nominato; e scadere il verdetto combinato al limite richiesto più presto. Sidewisp è attualmente in anteprima privata. Il suo ruolo previsto è uno strato di salute al fianco dei tempi di esecuzione degli agenti esistenti, con prove visibili e limiti di approvazione umana. La raccolta dell'agente di produzione, gli adattatori runtime, il recupero automatico, la gestione cron e l'analisi dei costi dei token non sono generalmente spediti oggi. Se le prove di freschezza corrispondono ai guasti che devi catturare, puoi Partecipa alla visualizzazione privata.