AI Agent Dashboard: sei segnali che rivelano la salute operativa

Una AI il dashboard dell'agente deve rispondere a una domanda operativa prima di disegnare un grafico di token: Questa corsa ha bisogno di attenzione ora? La riga più piccola utile combina sei segnali: freschezza del collettore, puntualità del programma, attività cardiaca, progresso utile, esplicita dipendenza dall'attesa e verifica dei risultati. Applicali in ordine fisso, in modo che un silenzioso atteso di approvazione non sia confuso con una stalla e un ciclo di tentativo occupato non sia confuso con un lavoro sano. Tenere latenza, modelli di chiamate, chiamate di strumento, token, costo e tracce. Sono prove diagnostiche preziose. Non dimostrano, da soli, che una corsa programmata è iniziata, che un rapporto è cambiato, che un'approvazione è in attesa o che esiste il prodotto promesso. Inizia con una riga di stato, non un muro di grafici Il default ragionevole per un dashboard di applicazioni LLM è la telemetria di servizio. Il pannello di controllo ufficiale AI Agents di Sentry, ad esempio, include le esecuzioni degli agenti, le chiamate LLM, la durata, l'uso del modello, i token, le chiamate degli strumenti, gli errori e i dettagli di traccia. Questi pannelli aiutano a rispondere a cosa è successo all'interno di questa esecuzione e quale dipendenza è diventata lenta o costosa? L'operatore che si trova ad affrontare venti percorsi autonomi o pianificati ha una decisione precedente: quale aprire? Una riga di stato compatto può rispondere: Campo Esempio Decisione che sostiene Agente e flusso di lavoro researcher / weekly brief Quale lavoro è influenzato? Stato waiting:human approval Ha bisogno di un intervento, di un percorso o di pazienza? Età della prova collector 14s ago Il verdetto si basa su dati freschi? Ultimi progressi utili 3 sources added, 4m ago Il risultato si muove, non solo il processo? Il prossimo evento atteso approval by owner Cosa succederà dopo? Controllo dei risultati brief.md schema: pending Cosa deve essere vero prima che il complesso sia credibile? Lo stato e' un verdetto derivato dalle prove, non una copia dell'ultima stringa di stato del runtime. Metti le prove decisive al suo fianco. Stuck senza finestra di progresso è un'opinione; nessuna modifica della fonte per 13 minuti mentre i battiti cardiaci sono rimasti freschi è verificabile. Questa separazione ha un precedente utile nei sistemi di agenti esterni. Kubernetes non fa crollare l'avvio, la vitalità e la prontezza in una sonda perché la risposta corretta è diversa: aspettare l'avvio, riavviare dopo un vero fallimento della vitalità o interrompere il traffico di routing quando un carico di lavoro non è pronto. La sua documentazione avverte anche che una sonda di vita mal progettata può creare fallimenti in cascata. Un dashboard di agenti ha lo stesso problema di controllo: un'etichetta è sicura solo quando implica la giusta prossima azione. Raccogliere sei segnali con esplicita freschezza I sei segnali qui sotto costituiscono un contratto sanitario compatto. Essi possono essere memorizzati come campi su un record di esecuzione o calcolati a partire da eventi di esecuzione. Ognuno ha bisogno di un timestamp, di una fonte e di uno stato non disponibile. 1. Freschezza del collezionista Registrare quando la scheda di controllo ha raggiunto l'orario di esecuzione per l'ultima volta o ha ricevuto un evento di fiducia. Se il collettore è obsoleto, classificare la corsa come unreachable o uncertain prima di interpretare i battiti cardiaci e il progresso più vecchi. Altrimenti un ospite disconnesso può sembrare pacificamente inattivo. Utilizzare una soglia legata alla cadenza di raccolta. Un limite di freschezza di 120 secondi è ragionevole per un intervistatore di un minuto in un esempio; è assurdo per un lavoro che si sincronizza ogni ora. Indicare sia l'età osservata che il limite configurato. 2. Orari di calendario Immagazzina l'inizio previsto, l'inizio effettivo, il fuso orario, la finestra di grazia e la politica di programmazione. Nessuna corsa significa poco senza quei campi. Un programma può essere sospeso, una politica di sovrapposizione può intenzionalmente saltare un inizio o una finestra di ritardo può rinviare il lavoro mancato. La documentazione Temporal's Schedule rende concrete queste distinzioni: gli orari possono essere interrotti; le politiche di sovrapposizione possono saltare, tamponare, annullare, terminare o consentire esecuzioni simultanee; le finestre di recupero decidono quali azioni mancate vengono eseguite dopo un'interruzione. Altri tempi di esecuzione usano nomi diversi, ma la dashboard deve comunque preservare la politica che spiega il divario. 3. Attività cardiaca Un battito cardiaco dimostra un recente contatto o un'attività di esecuzione. È utile per separare un tempo di esecuzione irraggiungibile da un processo in diretta. Non dovrebbe far avanzare l'orologio del progresso. Rendere l'evento stretto: heartbeat at , source , e forse una sequenza monotonicamente crescente. Non chiamate la corsa sana solo perché la sequenza continua a cambiare. 4. Progresso utile Definire un delta specifico per un'attività. Un agente di codifica potrebbe modificare la digestione del patch o aumentare il numero di test di passaggio. Un agente di ricerca potrebbe aggiungere una fonte primaria accessibile o spostare un breve da schema invalido a schema valid. Un agente di supporto potrebbe creare il biglietto promesso. Il record di progresso richiede last progress at , una breve descrizione del delta e una versione verificatrice. Evitare contatori vagi come passaggi completati a meno che ogni passo non indichi il risultato. 5. La dipendenza in attesa Rappresentare esplicitamente l'attesa legittima: human approval , credential , rate limit , external job o un'altra dipendenza denominata. Aggiungi un proprietario, l'azione richiesta e la scadenza quando è nota. Questo campo cambia l'azione. Una corsa in attesa di approvazione ha bisogno di un percorso verso la persona autorizzata, non di un riavvio. Un'attesa al limite del tasso può richiedere pazienza. Una credenziale mancante ha bisogno di un essere umano che possa fornirla senza rivelare il segreto al cruscotto. 6. Verificazione dei risultati Scrivi il predicato di completamento prima dell'inizio della corsa. Esempi sono: report exists, parses, and contains two reachable primary sources ; pull request exists and named checks pass ; ticket ID was returned and can be fetched ; scheduled export contains the expected date partition . Immagazzinare declared complete separatamente da outcome verified . Il secondo dovrebbe essere true , false o unavailable , con il verificatore e il tempo di controllo. Un comando di successo è l'attività. L'artefatto previsto è il risultato. Applicare un ordine di priorità Il cruscotto non deve mettere tutti gli avvertimenti possibili sulla stessa riga. Valutare prima lo stato più sicuro e più esplicativo: 1. collettore stale → unreachable ; 2. l'inizio previsto al di là della sua finestra di grazia → missed schedule ; 3. dipendenza denominata → waiting:<dependency ; 4. dichiarato completo senza risultato verificato → false success ; 5. battito cardiaco fresco più stadio, progresso zero → stuck ; 6. risultato verificato → complete ; 7. delta del progresso positivo → working ; 8. prove insufficienti o in conflitto → uncertain . L'ordine è una decisione del prodotto, non una legge della natura. E' ancora meglio che permettere a tre avvisi indipendenti di affermare che la stessa corsa disconnessa è simultaneamente bloccata, in ritardo e manca il suo risultato. Conservare i segnali sottostanti per l'indagine, ma dare all'operatore uno stato primario e un'azione successiva. Il dispositivo di accompagnamento mette a prova sei casi contro limiti esposti espliciti: freschezza del collezionista di 120 secondi, grazia del programma di 300 secondi, freschezza del battito cardiaco di 60 secondi e un tempo di progresso di 600 secondi. Eseguire con Node.js 20 o più recente: L' output esatto è: La coppia più importante è approval wait contro retry loop . Entrambi hanno battiti cardiaci freschi, nessun delta di progresso, e vecchi progressi. La dipendenza nominata rende la prima legittima l'attesa; l'assenza di una dipendenza rende la seconda candidata bloccata dopo il suo termine. Il caso false success ha un recente progresso e una pretesa di completamento, ma il verificatore di risultati è falso, quindi la pretesa di completamento non guadagna fiducia. Mettere le diagnosi dietro il verdetto Una volta che la riga di stato identifica una corsa che vale la pena aprire, la visualizzazione dettagliata può spiegare il perché. Organizzalo attorno alla transizione fallita piuttosto che attorno alla fonte di telemetria più facile da tracciare. Per missed schedule , indicare l'espressione del programma, il fuso orario, lo stato abilitato, le partenze attese e effettive, la politica di sovrapposizione e la cronologia di esecuzione recente. Per waiting , indicare la dipendenza, il proprietario, l'autorità richiesta, l'età e un'azione di richiamo limitato. Per stuck , mostrare la cadenza del battito cardiaco accanto alla prova di progresso e le firme ripetute dello strumento. Per false success , indicare la pretesa di completamento accanto al predicato fallito. Poi aggiungi traccia, latenza, token, costo, modello e pannelli utensili. Un picco di token collegato a un'operazione bloccata è applicabile; lo stesso picco collegato a un risultato verificato può essere un elemento di revisione dei costi piuttosto che un incidente. La ripetizione della chiamata per lo strumento può spiegare un impasse, ma le chiamate identiche non sono la prova di un ciclo fino a quando la prova del progresso del compito non smette di cambiare. Utilizzare una linea temporale per la causalità: Questo punto di vista rende comprensibili i periodi di silenzio. Inoltre dà a ogni allarme un'età delle prove. Se un adattatore smette di segnalare dopo le 12:03, il cruscotto dovrebbe passare a unreachable o uncertain invece di mantenere per sempre uno stato verde. Trattare le soglie e la raccolta dei dati come limiti del prodotto Il dispositivo è un insieme di contrasemplari, non un punto di riferimento di produzione. Dieci minuti senza cambiare file possono essere normali per un'analisi approfondita e disastrosi per un lavoratore in coda di un minuto. Calibra le finestre per il flusso di lavoro, poi registra la configurazione accanto al verdetto. Il progresso è il segnale più difficile. Preferiscono prove deterministiche come un digest, il numero di righe, il codice di stato, il risultato del test o la verifica dello schema. Quando il risultato è qualitativo, un valutatore con versione può fornire prove, ma il suo punteggio è incerto. Tenere unavailable come uno stato reale; non trasformare le prove mancanti in sane. Raccogliere il minimo necessario per stabilire la salute. Una riga di stato di solito non ha bisogno di richieste, risposte, segreti, carichi utili di strumenti grezzi o percorsi locali assoluti. Un identificatore di esecuzione opaco, timestamp, piccoli contatori, risultati del verificatore e classi di dipendenza modificate possono guidare la prima decisione. Le tracce più ricche possono avere regole separate di conservazione e di accesso. Infine, non collegare direttamente lo stato primario all'automazione irreversibile. L' avvertimento sulla vitalità di Kubernetes è rilevante qui: un test sanitario eccessivamente sicuro può peggiorare la guarigione. Un dashboard può raccomandare un'impostazione limitata, una pausa o un promemoria, ma l'azione dovrebbe rispettare l'autorità, la repetizione, il tempo e i limiti di costoe il problema dovrebbe essere chiarito solo dopo un utile progresso o l'osservazione del risultato atteso. Dove si inserisce Sidewisp La direzione del prodotto di Sidewisp è una visione della salute intorno agli agenti che le persone eseguono già: accessibilità, progresso utile, accesso alla memoria e agli strumenti, prove degli esiti, segnali di costo e recupero controllato con confini espliciti di approvazione. Non è destinato a sostituire il runtime, il scheduler, il model gateway o il sistema di tracciamento grezzo. Tale descrizione è la direzione del prodotto e non un'affermazione di monitoraggio generalmente disponibile. Sidewisp è attualmente in anteprima privata. Il sito pubblico, la dimostrazione interattiva e il sistema di articoli sono in diretta; la raccolta dell'agente di produzione, gli adattatori runtime, il recupero automatico, la gestione cron e l'analisi dei costi dei token non vengono generalmente spediti. Unisciti all'anteprima privata se questo contratto del cruscotto a sei segnali corrisponde al problema operativo che devi risolvere. Fonti primarie Centrina AI Agenti Dashboard campi ufficiali per le run, le chiamate LLM, la durata, i modelli, i token, gli strumenti, gli errori e le tracce. Sonde Kubernetes vitalità, preparazione e avvio separazione ufficiale dei controlli sanitari, delle reazioni, delle soglie e delle avvertenze di guasto. Orari temporali programma ufficiale, pausa, sovrapposizione, aggiornamento e semantica della politica di fallimento.