AI Osservabilità dell'agente: Misurare i progressi utili, non solo l'attività

L'osservabilità degli agenti AI è la capacità di spiegare ciò che un agente ha fatto da prove esterne: tracce, registri, metriche, eventi degli strumenti, chiamate di modello, latenza, token e costo. Questa prova e' necessaria, ma non e' un verdetto sanitario. Una traccia può essere completa mentre il file richiesto manca. Una chiamata agli strumenti può avere successo mentre l'agente ripete lo stesso passo. Una corsa tranquilla può essere in attesa di approvazione. La risposta pratica è mantenere la telemetria e aggiungere un piccolo strato di decisione sopra di essa. Per ciascun compito, osservare cinque cose insieme: raggiungibilità, delta di progresso utile, dipendenze dichiarate, controlli deterministici degli esiti e costi sulla stessa finestra. Valutateli in quell'ordine prima di avvertire o recuperare qualcosa. Questa guida trasforma quella regola in un sistema eseguibile a cinque casi. È intenzionalmente neutrale nel tempo di esecuzione: lo stesso ragionamento può essere posto al di sopra degli intervalli di OpenTelemetry, degli eventi di Claude Code, di un registro di esecuzione OpenClaw o di un agente personalizzato. Una traccia dimostra cosa è andato, non cosa è cambiato. L'attuale Convenzioni semantiche OpenTelemetry per gli ambiti degli agenti GenAI definisce le operazioni per la creazione e l'invocazione di agenti, l'invocazione di flussi di lavoro, la pianificazione e l'esecuzione di strumenti. Il documento è contrassegnato come Development , il che è importante quando si progetta uno schema di lunga durata: utilizzare le convenzioni dove si adattano, ma isolare attributi sensibili alla versione dietro il proprio livello di normalizzazione. La telemetria in tempo di esecuzione sta già diventando dettagliata. Documentazione di monitoraggio di Claude Code descrive metriche, eventi e tracce distribuite beta. Il suo tracciato può includere un'interazione, richieste di modello, chiamate di strumento, blocco di tempo su una decisione dell'utente e esecuzione dello strumento. I campi documentati includono durata, token, costo stimato, dimensione del risultato degli strumenti e success . Questi campi rispondono a importanti domande: Il tempo di corsa ha risposto? Quale modello e quali strumenti funzionano? Un corpo di utensili specifico ha restituito un errore? Quanto tempo ci è voluto per aspettare il permesso e l'esecuzione? Quanti token e dollari ha consumato la corsa? Non definiscono il successo del tuo compito. Un comando shell che restituisce il codice di uscita 0 dimostra che il comando è stato completato secondo il proprio contratto. Non dimostra che un articolo sia pubblico, che una sitemap contenga il suo URL, che una richiesta di pull passa IC o che un registro del cliente è stato raggiunto nel sistema previsto. Le applicazioni possono aggiungere tali controlli, ma un campo generico di successo degli strumenti non può inventarli. L'attività e il progresso possono quindi muoversi in direzioni opposte. 19 chiamate di successo senza delta di uscita possono essere un loop. Due chiamate di strumento seguite dal silenzio possono essere una salutare attesa per un recensore. Un ultimo messaggio che dice done potrebbe essere un falso successo se l'artefatto promesso è assente. Costruire una finestra di salute da cinque segnali Scegli una finestra di osservazione specifica per la attività prima di guardare il risultato. Cinque minuti possono essere sufficienti per una piccola modifica di codice; un'ora può essere ragionevole per un lavoro di ricerca programmato. Evitare una soglia globale che etichettasse ogni lunga operazione come bloccata. All'interno di quella finestra, raccogliete cinque segnali: Segnale Minime prove Che cosa impedisce Raggiudicabilità età del battito cardiaco, risposta al processo/sessione, o ricevuta di esecuzione del programmatore trattare un tempo di corsa irraggiungibile come un fallimento di ragionamento Progresso utile un delta monotono specifico per le attività confondere l'attività ripetuta con movimento Dipendenze motivo di attesa, proprietario e tempo di scadenza riprovare un lavoro che richiede legittimamente una persona o un sistema esterno Risultato predicato deterministico per il risultato promesso accettare un messaggio di completamento senza un consegnabile Costo token, chiamate, tempo o denaro nella stessa finestra ignorando costosi tentativi di ripresa che non producono progressi Progressi utili devono essere concreti. Per un agente di codifica potrebbe essere un risultato di prova modificato, un nuovo impegno o un numero ridotto di test falliti non trasmessi a un terminale. Per un'agenzia editrice potrebbe essere un documento di identificazione del progetto CMS, poi una corrispondenza API pubblica, poi un URL dal vivo nella sitemap. Per un agente di supporto potrebbe essere una transizione di biglietto convalidata piuttosto che un altro modello di risposta. Preferisco un predicato deterministico di risultato quando esiste uno: Utilizzare un valutatore solo quando il risultato non può essere verificato meccanicamente, e memorizzare la rubrica, la versione e l'incertezza. Non raccogliere una catena nascosta di pensieri come scorciatoia. La selezione degli strumenti, i piani espliciti, le uscite, i timestamp e i cambiamenti di stato forniscono prove operative senza richiedere ragionamenti privati. Il costo appartiene alla finestra, ma il costo da solo non è la salute. Si possono aspettare dieci dollari che producano una migrazione verificata. Cinquanta centesimi spesi per ripetere una ricerca invariata possono essere l'anomalia. Una misura derivata utile è: La max evita la divisione per zero; non rende il progresso sano zero. Avviso separato quando progress delta == 0 e il costo continuano ad aumentare. Classificare il lavoro, l'attesa, il bloccato, l'irraggiungibile e il falso successo L'ordine decisionale è importante. Controlla prima la disponibilità. Allora rispetta una dipendenza esplicita che è ancora in tempo. Controllare un compimento dichiarato con il predicato di risultato prima di accettarlo. Solo allora interpretare il progresso e il tempo trascorso. Ecco un dispositivo completo di NDJSON. Salva come health window fixture.ndjson : Eseguire questo classificatore con Node.js: Prodotto atteso: Il dispositivo rende la tesi falsificabile. Una regola ingenua come tool calls 0 segna come attiva sia run stuck che run false success . Una regola basata solo sul silenzio segna run waiting come insalubre. La regola dei cinque segnali li separa perché conserva la dipendenza e le prove dei risultati. L'esempio è uno scheletro decisionale, non un modello di punteggio universale. Il codice di produzione ha anche bisogno di freschezza, fiducia, identità sorgente e di un percorso uncertain quando i segnali non sono d'accordo. Mappa di ogni stato per una risposta limitata La classificazione esiste per prevenire l'azione sbagliata, non per decorare una dashboard. Stato Richiesta di prove Risposta predefinita Lavorare recente raggiungibilità e progressi positivi delta lascialo in pace; campione di nuovo più tardi In attesa dipendenza tipografata, proprietario e tempo di scadenza non scaduto avvisare una volta la persona responsabile; non riprovare il passo bloccato Inchiodato . accessibile, oltre la sua finestra, nessuna dipendenza, nessun delta di progresso ispezionare il passaggio ripetitivo; preparare un nuovo tentativo reversibile o spingere entro i limiti Falso successo completamento dichiarato, risultato deterministico fallito riaprire il compito e segnalare il predicato mancante; non definirlo completo Non raggiungibile battito cardiaco stagnato o fallito contatto in tempo di esecuzione controllare la disponibilità dell'host/il tempo di esecuzione prima di modificare le richieste Incertezza prove mancanti o contraddittorie raccogliere il segnale assente o chiedere; non automatizzare il recupero Questa separazione ha un precedente utile al di fuori dei sistemi AI. Kubernetes distingue le sonde di avvio, vitalità e preparazione perché il processo esiste e il servizio dovrebbe ricevere traffico sono decisioni diverse. La sua documentazione avverte anche che le sonde di vita mal progettate possono causare guasti in cascata attraverso riavviamenti inutili. L'analogia ha un limite: un agente AI non è un Pod, e il progresso utile è dipendente dal compito. La lezione trasferibile è più stretta: non lasciare che un segnale verde o rosso ambiguo autorizza ogni intervento. Per il recupero attivo, aggiungere limiti all'azione: una prova di ripetizione, non un ciclo di ripetizione illimitato; un tempo e un costo massimi trascorsi; un passo reversibile; un limite esplicito di omologazione per azioni distruttive o esterne; un controllo post azione dei progressi o dei risultati. Il completamento del comando non significa recupero. Elimina l'incidente solo dopo che il stato previsto cambia. Strumento del contratto, non ogni pensiero Una cartella di salute compatta e normalizzata può stare accanto ai dati di traccia esistenti: Tenere i riferimenti alle prove controllati dall'accesso e modificare segreti, richieste, carichi utili di strumenti grezzi e percorsi locali assoluti, a meno che non siano strettamente richiesti. La cartella sanitaria dovrebbe indicare ciò che è stato controllato e dove gli operatori autorizzati possono controllarla; non dovrebbe diventare una seconda copia di telemetria sensibile. Versione quattro cose esplicitamente: 1. l'adattatore runtime che ha normalizzato le prove; 2. la definizione del progresso; 3. il predicato di risultato; 4. le norme e le soglie del classificatore. Senza queste versioni, un comando di prova modificato o un prodotto di consegna rinominato può sembrare una regressione improvvisa dell'agente. Sapere dove si ferma il metodo La parte difficile e' non raccogliere un'altra spina. Sta definendo onestamente i progressi utili e il risultato promesso. Alcuni compiti non hanno una misura monotona di progresso. Un agente di ricerca può scartare un'ipotesi debole e tornare a una fase precedente; questo può essere un lavoro prezioso anche se un contatore cade. Alcune dipendenze non rivelano un tempo di scadenza affidabile. Alcuni risultati richiedono un giudizio piuttosto che una somma di controllo. In tali casi, conservare le prove e segnalare uncertain . Non produrre precisione con un punteggio sanitario universale. Inoltre separare i controlli sanitari online dalla valutazione offline. I set di dati offline possono rivelare se una nuova versione dell'agente è più accurata in casi noti. La finestra di salute in diretta risponde a una domanda diversa: questa particolare corsa è raggiungibile, in movimento, in attesa legittima, o manca il suo risultato ora? Di solito hai bisogno di entrambi. Inizia con un flusso di lavoro consecutivo. Definire un delta di progresso e un predicato di risultato deterministico. Riproduci noti casi di lavoro, attesa, bloccati, irraggiungibili e falsi. Solo dopo che le classificazioni corrispondono alla realtà dovrebbe dipendere da esse un allarme o un'azione di recupero limitato. Sidewisp è attualmente in anteprima privata. Il suo sito pubblico e il suo sistema di articoli sono in diretta, ma la raccolta dell'agente di produzione sanità, gli adattatori runtime e il recupero non sono generalmente spediti. La direzione del prodotto è uno strato di salute che rende più facile agire sui limiti di prova, freschezza, fiducia e approvazione senza sostituire il tempo di esecuzione dell'agente. Referenze primarie OpenTelemetry: Convenzioni semantiche per l'agente e gli ambiti del quadro GenAI ritirato il 24 luglio 2026; stato del documento: Sviluppo. Codice Claude: monitoraggio campi e configurazione ufficiali di telemetria, recuperati il 24 luglio 2026. Kubernetes: vivacità, preparazione e sonde di avvio Scopi ufficiali di indagine e avvertenze di recupero, ritirato il 24 luglio 2026.