AI Agente Osservabilità: impronte digitali ogni corsa

La risposta più breve e utile è: allegare un'impronta digitale run manifest a ogni esecuzione dell'agente, quindi confrontare la salute solo dopo aver saputo se il tempo di esecuzione, lo snapshot del modello, il prompt, la politica, lo schema degli strumenti e l'immagine di distribuzione erano gli stessi. Una traccia ti dice cosa ha fatto una corsa. Il manifesto ti dice quale versione del sistema l'ha fatto. Quella impronta non è un punteggio di salute e non prova il motivo del fallimento. E' una chiave di ramificazione. Se una regressione appare sotto una nuova impronta digitale, controllare prima la deriva di configurazione. Se appare sotto l'antica impronta digitale, cercare ambienti non registrati, dipendenza, fornitore, dati o modifiche delle autorizzazioni. Un nome di agente stabile può nascondere un sistema diverso. Supponiamo che support triage compia due biglietti correttamente il venerdì e manchi un'escalation richiesta il lunedì. Entrambe hanno lo stesso nome dell'agente. Entrambi emettono battiti cardiaci. Entrambi gli strumenti di chiamata. Il raggruppamento di questi elementi sembra naturale e può essere sbagliato. Tra quelle gare, una di queste potrebbe essere cambiata: Componente manifesto Registrazione Evitare la registrazione Tempo di esecuzione nome e versione esatta o commit percorso host, token di accesso Modello fornitore e istantanea fissata, se disponibile chiave API, risposta completa In fretta SHA 256 del pacchetto di richieste esaminato il cliente grezzo o il sistema immediato Politica hash o revisione immutabile Valori segreti incorporati nella politica Strumenti schema canonica hash credenziali, carichi utili di strumenti Sviluppo digestione dell'immagine o commit di fonte password di registro Questo segue un'idea di osservabilità stabilita piuttosto che inventare un secondo formato di traccia. La SDK delle risorse OpenTelemetry descrive una risorsa come una rappresentazione immutabile dell'entità che produce la telemetria. Per un'esecuzione di un agente, la configurazione di esecuzione fa parte di quella identità. Conservare l'ID traccia per un'esecuzione e l'impronta digitale manifesto per la versione che l'ha prodotto; nessuno sostituisce l'altro. Un manifesto utile è deliberatamente noioso. Contiene identificatori stabili, non osservazioni come latenza, conteggio dei token, stato di uscita o risultato. Quelli appartengono al lato della Manifestazione. Mettendoli nel hash creerebbe una nuova impronta digitale per ogni corsa e distruggerebbe il confronto. C'è anche un confine di privacy: hash un prompt o una politica localmente, ma non caricare l'originale solo per spiegare la sua identità. Gli hash possono ancora filtrare informazioni quando l'input proviene da un piccolo set prevedibile, quindi usa ID di rilascio opaci o un digest locale a chiave quando quella minaccia conta. Non mettere mai le credenziali nel manifesto, nemmeno prima di hashare l'intero oggetto. Canonicalizza prima di hashing Hashing raw JSON è una trappola perché l'ordine delle chiavi oggetti e le scelte di serializzazione insignificanti possono differire mentre la configurazione rappresentata rimane la stessa. La Schema di canonicalizzazione JSON nella RFC 8785 definisce la serializzazione deterministica, compresa la classificazione delle proprietà ricorsive. Il codice di produzione dovrebbe utilizzare un'implementazione JCS riveduta quando si tratta di interoperabilità. Per un esperimento locale compatto, la seguente funzione Node.js è sufficiente per i normali valori finiti JSON: L'esperimento ha usato Node.js v22.23.1 . È intenzionalmente più ristretto della RFC 8785: classifica le chiavi di oggetto in modo ricorrente e respinge i numeri non finiti, ma non è un'affermazione di completa conformità JCS translinguale. Tale limitazione appartiene al fianco del codice, non in una nota a piè di pagina dopo che un lettore l'ha copiato. Il manifesto stesso può rimanere piccolo: I valori di posizionamento di cui sopra sono identificatori di dispositivi, non rivendicazioni del fornitore. In un vero collezionista, derivati sul host da rilasci fissati. Il principio più ampio è simile a provenienza SLSA: conservare informazioni verificabili su dove, quando e come è stata prodotta una cosa. Un manifesto di corsa prende in prestito questo principio per la diagnosi; non è automaticamente un attestato SLSA. Una riproduzione di sei giri espone sia il valore che il limite Ho testato la regola contro sei registri sintetici di NDJSON per un agente. Le corse 101 e 102 contengono gli stessi valori manifestati in diversi ordini di chiavi JSON. Eseguire 103 cambia solo il hash prompt, 104 cambia solo lo snapshot del modello e 105 cambia solo il hash schema strumento. L'esecuzione 106 fallisce a causa di un'interruzione di dipendenza che il manifesto di installazione non rappresenta. Il comando di audit era: Il risultato deterministico: Due osservazioni sono più importanti dei conti. In primo luogo, un nome dell'agente nascondeva quattro configurazioni registrate. In secondo luogo, i due oggetti di base ordinati in modo diverso hanno prodotto la stessa impronta digitale SHA 256, quindi l'ordine di serializzazione non ha creato una falsa deriva. L'esempio contrario è la parte importante: run 106 ha fallito con l'impronta digitale di base. Un'impronta digitale invariata non ha reso la corsa sana e non ha dimostrato che l'ambiente fosse invariato. Ha mostrato solo che i campi di configurazione registrati erano invariati. L'indagine successiva dovrebbe esaminare le prove al di fuori della disponibilità del fornitore, dei dati di ingresso, del percorso della rete, dello stato di autorizzazione e della freschezza della dipendenza. Il dispositivo è sintetico, quindi dimostra la meccanica e falsifica una pretesa eccessiva; non stima la frequenza con cui la deriva di configurazione provoca veri incidenti. Ciò richiederebbe dati di produzione con emissioni controllate e risultati verificati. Trasformare l'impronta digitale in una decisione di triage Utilizzare l'impronta digitale solo dopo che la corsa ha un risultato osservabile. L'attività da sola tokens emessi, strumenti chiamati o un processo ancora vivo non stabilisce progressi utili. Evidenza dei risultati Confronto delle impronte digitali Primo ramo Passato Lo stesso di linea di base Conserva come riferimento sano paragonabile Fallito Modificato Differe i campi del manifesto modificati; prendere in considerazione un rollback o una riproduzione limitati Fallito Lo stesso. Controllare le dipendenze, le autorizzazioni, gli input, lo stato del fornitore e la copertura manifesto mancante Non conosciuto E' una delle due. Raccogliere o definire il risultato atteso prima di diagnosticare la deriva Tre regole operative mantengono questo onesto: 1. Freeze the comparison point. Scegli una corsa verificata con successo per la stessa classe di attività, non solo lo stato verde più recente. 2. Guardare una mappa a livello di campo modificata. Il hash del manifesto intero dice different. I singoli digesti di componenti dicono dove ispezionare senza rivelare il contenuto. 3. Verificare l'esito dopo l'intervento. Un comando di ritorno successivo è attività. Il recupero significa l'apertura prevista, il passaggio della prova o il passaggio di un altro controllo deterministico di accettazione. Non rimettere automaticamente ogni impronta digitale modificata. Un rilascio può essere intenzionale e un guasto può derivare dall'input piuttosto che dal rilascio. Utilizzare il cambiamento come prova per una revisione, preservare l'approvazione umana per le azioni conseguenti, e registrare ciò che è accaduto dopo l'azione. Quando questo si inserisce nel monitoraggio della salute degli agenti L'impronta digitale di una prova collega tre questioni di salute che le sole tracce non possono risolvere in modo pulito: una politica decisionale è cambiata, un contratto di strumento è cambiato e la qualità dei risultati è diminuita sotto lo stesso sistema registrato? Migliora anche le consegne di incidente perché un altro operatore può confrontare l'esatta identità di rilascio senza ricevere richieste, segreti o carichi utili di strumenti grezzi. Il modello di salute previsto da Sidewisp comprende l'esecuzione, la memoria e il contesto, gli strumenti, i risultati, la disponibilità e il costo. Un futuro adattatore del lato ospitante potrebbe utilizzare un manifesto modificato come prova a sostegno di tali diagnosi, ma questo è territorio pianificatonon un'affermazione di monitoraggio spedita. Sidewisp è attualmente in anteprima privata. Il sito pubblico e il sistema di articoli sono in diretta; la raccolta dell'agente di produzione e della salute, gli adattatori di tempo di esecuzione e il recupero automatico non sono generalmente disponibili. Se questo modello di prova corrisponde a un fallimento operativo attuale, il prossimo passo restritto è quello di unirsi alla lista d'attesa di anteprima privata e descrivere il controllo del tempo di esecuzione e degli esiti che è necessarionon presumere che Sidewisp lo raccolga già.