Agente Watchdog: un proprietario, nuove prove, lavoro verificato

Un osservatore agent è un osservatore separato che segue la corsa di un altro agente, decide se sta funzionando, in attesa legittima, bloccato, incerto, fallito o finito, e verifica il risultato dichiarato. Il default utile è un cane di guardia con un contratto di locazione, una cadenza lenta basata sulle prove e nessuna autorità di mutazione automatica. Il processo è vivo e il lavoro richiesto è corretto sono verdetti separati. Tale definizione risolve anche un'ambiguità nei risultati di ricerca attuali. Watchdog può significare un vecchio daemon di riavvio dell'infrastruttura, un prodotto di sicurezza AI o un agente che supervisiona un altro agente. In questa guida si parla del terzo significato. L'attuale abilità agent watchdog di Builder.io descrive la stessa consegna concreta: aspettare un altro agente, ricostruire la richiesta, quindi controllare le richieste in base a differenze, file, test, CI, screenshot e stato di revisione. Il suo modo di riparazione è separato e richiede l'autorizzazione. Questa separazione è il giusto punto di partenza. Date esattamente un cane da guardia di proprietà Un cane da guardia ha bisogno di una propria identità e di un contratto di locazione. Senza di loro, due controlli pianificati possono entrambi concludere che possiedono la stessa corsa. Anche se entrambe le diagnosi sono corrette, due spingimenti, un nuovo tentativo o un nuovo avviamento possono produrre effetti duplicati. Usa un disco come questo: runId lega l'osservatore ad un solo pezzo di lavoro. watchdogId identifica il proprietario. La scadenza costringe la rielezione dopo un osservatore caduto, invece di lasciare la proprietà permanente. observedAt dice quanto sia recente il verdetto; non è intercambiabile con lastProgressAt . Un osservatore può tenere un record di progressi recenti mentre la sua stessa connessione è diventata obsoleta. Prima di ogni verdetto, applicare tre regole di proprietà: 1. Dev'esserci esattamente un contratto di locazione non scaduto per la corsa. 2. L'osservatore deve aggiornare le prove prima di classificare o raccomandare un intervento. 3. Il contratto di locazione precedente può essere sostituito solo dopo la scadenza del contratto di locazione precedente o dopo la sua esplicita liberazione. Se esistono due ID, restituisci conflict . Non permettere che entrambi contribuiscano solo a diventare una politica implicita di concurrenza. Separate porte di osservazione, intervento e risultato Kubernetes documenta le sonde di avvio, preparazione e vitalità separatamente perché rispondono a domande diverse e scatenano azioni diverse. La sua documentazione avverte anche che una cattiva regola di vita può trasformare i riavviamenti sotto carico in un fallimento in cascata. Un agente di controllo AI ha bisogno di una separazione equivalente, con un cancello di uscita aggiuntivo. V porta di osservazione: Le prove sono abbastanza fresche per classificare la corsa? Controlla il timestamp dell'osservatore, la disponibilità dell'agente, la ricevuta del progresso, i metadati in attesa e lo stato attuale del terminal. Un intervallo di tempo o un campione mancante dà uncertain ; non dimostra stuck . Porta di intervento: È giustificata e autorizzata un'azione? Un cane di guardia che può solo leggere può segnalare una credenziale obsoleta, un'attesa senza proprietà, o dieci minuti senza progressi utili. Potrebbe non indurre il permesso di riavviare, cancellare, modificare file, inviare messaggi o spendere più budget. Date a ciascuna azione consentita il suo nuovo tentativo, il suo tempo e il suo limite di costo. O porta di uscita: Il lavoro richiesto ha superato il suo verificatore? Uno stato di processo terminale è solo prova di attività. Per un compito di codice, la ricevuta potrebbe combinare un impegno previsto, un test mirato pulito e uno screenshot richiesto. Per un compito di pubblicazione, potrebbe richiedere la parità API, una pagina HTTP 200, l'inclusione di sitemap e le risorse rendered. Per un effetto collaterale esterno, può essere necessario un registro di rilevazione o di idempotenza di destinazione. Le linee guida SRE di Google fanno la stessa distinzione pratica da un'altra direzione: i segnali della casella bianca spiegano gli interni, mentre i controlli della casella nera espongono contenuti sbagliati che uno stato di protocollo di successo non può rilevare. Il cane da guardia dovrebbe preservare entrambi. I registri possono spiegare il motivo per cui l'esecuzione è stata interrotta; la ricevuta del risultato determina se la richiesta dell'utente è stata soddisfatta. Utilizzare una regola statale che preservi l'incertezza L'ordine seguente è importante. La proprietà e la freschezza vanno prima del progresso. Un auto rapporto terminale viene fornito prima di un timer generico, ma non bypass la verifica. La freschezza dell'osservazione di due minuti e la finestra di progresso di dieci minuti sono valori fissi, non predefiniti universali. Derivati dal flusso di lavoro. Una implementazione che normalmente produce una pietra miliare ogni quarant' minuti ha bisogno di una finestra di progresso diversa da una corsa di codifica interattiva che cambia file ogni minuto. Esercitare la regola contro i casi che variano una condizione alla volta: Caso Modifica delle prove Verdicto La prossima azione è limitata . Freschi progressi Nuova pietra miliare di prova working Osservate più tardi . Attesa di proprietà Proprietario e termine futuro waiting Notifica di scadenza avvicinata Aspettare senza proprietà Nessun proprietario o scadenza needs human Assegna entrambi Corso in ritardo Nessun progresso per 18 minuti. stuck Preparare una diagnosi Osservatore stale L' ultima osservazione è di quattro minuti. uncertain Raggiornare le prove Cani da guardia duplicati Due documenti di guardia dal vivo . conflict Scegliere un proprietario Rapporto fatto Nessun ricevimento di risultato audit required Verificare l'artefatto Verificato eseguito Passe di ricevimento complete Affitto di rilascio Nel sistema eseguibile utilizzato per questo articolo, tutte le otto classificazioni attese sono state approvate. Due paragoni sono particolarmente utili. Il nuovo progresso con un osservatore vivo è working ; la stessa prova con due ID di osservatore vivo è conflict . Un auto riporto compilato con una ricevuta mancante è audit required ; aggiungere una ricevuta verificata è l'unica modifica necessaria per raggiungere complete . Scegliere la cadenza dai cambiamenti attesi delle prove Il voto più veloce non rileva necessariamente il fallimento prima. Può creare costi, rumore, pressione limite di tariffa e ripetuti giudizi su dati invariati. Determina la cadenza delle variazioni attese e le conseguenze del ritardo. Per una lunga ricerca, un'osservazione di cinque minuti può essere ragionevole se le pietre miliari arrivano normalmente ogni quindici minuti. Un'eventuale necessità di consegna pianificata verifica intorno alla sua data prevista di inizio e di scadenza, non un sondaggio costante tutto il giorno. Un'attesa di approvazione umana ha bisogno di un proprietario nominato e di una scadenza per l'escalation; le richieste ripetute non aggiungono alcuna informazione. Un programma utile ha quattro numeri: intervallo di osservazione quando aggiornare la disponibilità e lo stato; limite di freschezza quando le prove dell'osservatore diventano inutilizzabili; finestra di progresso il più lungo intervallo normale tra pietre miliari significative; Azione raffreddamento il ritardo minimo prima di un altro intervento autorizzato. Registrare l'ultima prova e il timestamp. Nuove linee di registro non sono necessariamente nuovi progressi. Una chiamata ripetitiva di strumento, un fallimento di prova inalterato o un progetto identico rigenerato non dovrebbero riimpostare l'orologio di progresso solo perché il processo è attivo. Il default di recupero ragionevole è ancora report first. Se la corsa è stuck , preparare una diagnosi o uno spinto limitato. Se si tratta di waiting , indirizzare la decisione al proprietario nominato. Se si tratta di uncertain , raccogliere prove migliori. Se si tratta di conflict , rimuovere i supervisori aggiuntivi. Solo una politica approvata separatamente dovrebbe consentire un riavvio reversibile, e l'organismo di vigilanza deve verificare ulteriormente i progressi utili. Mantenete il cane da guardia più piccolo del lavoro Un agente di sorveglianza non dovrebbe diventare un secondo runtime, un recensore illimitato, e un fissatore autonomo in una volta. I suoi input utili minimi sono la richiesta originale, le successive modifiche di ambito, un'identità di esecuzione stabile, nuove prove di progresso, proprietà in attesa, lo stato del terminal e un verificatore di risultati specifico per il compito. Tutto il resto dovrebbe guadagnare il costo della raccolta. Questa progettazione ha un limite: la telemetria generica non può dimostrare un prodotto arbitrario. Qualcuno deve definire cosa significa "fare" per il compito. Quando non esiste un controllo deterministico, il guardiano può indirizzare il risultato a un umano o a un giudice di scope ristretto, preservare le prove e etichettare la fiducia. Non dovrebbe produrre uno stato verde. Il territorio di destinazione del prodotto Sidewisp è lo strato di salute attorno agli agenti esistenti: accessibilità, progressi utili, attesa, strumenti, risultati e confini di recupero sicuri. Sidewisp è attualmente in anteprima privata. Il suo motore di monitoraggio della produzione e gli adattatori del tempo di esecuzione non vengono generalmente spediti, quindi il contratto di cui in questo articolo è un modello operativo che puoi implementare nel tuo tempo di esecuzione attualenon è una affermazione che Sidewisp stia già osservando o riparando gli agenti dal vivo. Inizia con una corsa e un osservatore. Chiedere un contratto di locazione, tenere l'osservazione legata principalmente, preservare uncertain e definire la ricevuta del risultato prima dell'inizio del lavoro. Questo è sufficiente per rendere utile un agente di sorveglianza senza lasciare che la supervisione diventi un'altra fonte di fallimento. Fonti Builder.io agente guardiere README al commit 51bb048 Kubernetes: vivacità, preparazione e sonde di avvio Google SRE Book: monitoraggio dei sistemi distribuiti