Osservabilità degli agenti: catturare il falso successo con un contratto di risultato

L'osservabilità dell'agente dovrebbe rispondere a una domanda più difficile di ha concluso l'esecuzione?: esiste il risultato atteso, appartiene a questa esecuzione, e passa il suo controllo di accettazione? Il default pratico è definire quel risultato prima dell'esecuzione, osservarlo al di fuori del messaggio di completamento dell'agente e registrare una ricevuta compatta di risultato. Un evento terminale può innescare la verifica; non può sostituire la verifica. Questa distinzione cattura il falso successo senza richiedere un secondo modello per rileggere l'intera trascrizione. Essa evita anche l'errore opposto: trattare un'approvazione legittima come un'attesa rotta. La ricevuta descritta di seguito registra un identificatore opaco dell'artefatto, la freschezza, un contenuto digestivo se del caso e un risultato di validatore deterministico. Le prove mancanti rimangono unverified o uno stato di insufficienza specifico invece di essere arrotondati fino a essere sani. Un evento terminale è la prova dell'esecuzione, non della consegna Le tracce sono il posto giusto per capire come funzionava il lavoro. Non costituiscono automaticamente la prova che lo stato esterno richiesto esista ora. L'attuale Convenzioni semantiche OpenTelemetry per gli ambiti degli agenti GenAI descrive operazioni come invoke agent , plan e execute tool , oltre agli attributi di agente, fornitore, modello, timing e errore. Il documento è esplicitamente contrassegnato Sviluppo. Questi segnali possono indicare che un'operazione è avvenuta e se ha segnalato un errore. Non possono sapere che la sua fattura in particolare è stata memorizzata, che la richiesta di ritiro contiene la modifica richiesta o che il suo rapporto corrisponde a uno schema approvato. Tale regola di accettazione appartiene alla domanda. La OpenAI Agents SDK riferimento di tracciamento produce lo stesso cemento di confine. La sua traccia predefinita può includere generazioni di modelli, chiamate di funzione, guardrails, manovra e spazi personalizzati. Questa è una ricca prova di esecuzione. L'SDK avverte inoltre che gli intervalli di generazione e di funzione possono contenere input e output sensibili e consente agli operatori di disabilitare tale cattura. Una ricevuta di risultato può quindi essere più ristretta e più decisiva: conservare la prova necessaria per giudicare il prodotto consegnabile, non una seconda copia di ogni servizio e carico utile degli strumenti. Un buon modello operativo utilizza entrambe le caratteristiche seguenti: la traccia spiega il percorso, i retest, gli strumenti e la posizione del fallimento; il ricevimento del risultato dimostra il risultato previsto o indica la prova mancante; un segnale di attesa registra una conosciuta dipendenza o approvazione, piuttosto che pretendere di aver completato il compito; un segnale di progresso mostra un movimento utile mentre il lavoro è ancora attivo. La confusione di questi segnali crea cattivi allarmi. L'attività non è un progresso utile. Un evento terminale pulito non è un risultato verificato. Un'attesa dichiarata non è una sosta. Scrivere il contratto di risultato prima della corsa Un contratto risultante è sufficientemente piccolo da rivedere alla creazione del compito e sufficientemente rigoroso da valutare senza chiedere all'agente cosa significava. Inizia con il controllo deterministico più economico che corrisponda al risultato reale. Campo Scopo Esempio artifact id Indica il risultato atteso senza rivelare un percorso segreto o assoluto monthly report run started at Stabilire il limite di freschezza 2026 07 25T14:00:00Z observed at Indica quando sono state raccolte le prove 2026 07 25T14:08:12Z modified at Rifiuta un artefatto lasciato da una corsa precedente 2026 07 25T14:07:55Z expected sha256 Pini precisi byte quando byte importa identità una digestione di 64 caratteri validator Nome del controllo di accettazione report schema v3 validator exit code Registra il verdetto deterministico 0 evidence source Dice da dove viene l'osservazione local file stat Non richiedere ogni campo per ogni lavoro. Una migrazione di database potrebbe richiedere una query schema piuttosto che un file digest. Una pagina distribuita può richiedere lo stato HTTP, il contenuto canonico e un'affermazione del browser. Un compito di approvazione umana dovrebbe rimanere waiting fino all'arrivo dell'evento dell'autorità. Il contratto dovrebbe rappresentare il risultato, non costringere ogni carico di lavoro a un modello a forma di file. L'ordine di classificazione predefinito è importante. Controlla prima l'assenza di prove, poi l'identità, la freschezza, la digestione e il risultato del validatore. Questo produce stati attuabili: 1. missing non esistono artefatti osservati; 2. wrong artifact l'osservazione appartiene a un obiettivo diverso; 3. stale l'artefatto precede la corsa; 4. hash mismatch sono stati richiesti e differiscono byte esatti; 5. validator failed l'artefatto esiste ma non soddisfa i criteri di accettazione; 6. unverified il controllo richiesto non è stato eseguito o le sue prove non sono disponibili; 7. verified tutte le condizioni richieste sono state superate. Tieni la ricevuta al minimo. Gli identificatori opaci sono più sicuri dei nomi dei clienti o dei percorsi del file system. Un digest può dimostrare l'identità di byte, ma un semplice hash non nasconde un segreto prevedibile dall'elenco. Utilizzare un HMAC con chiave quando il valore è sensibile e di bassa entropia, o evitare di mantenere il valore interamente. La raccolta delle prove dovrebbe avvenire vicino all'artefatto in modo che il contenuto grezzo non debba lasciare l'ospite. Eseguire il test di fallimento di sei casi Ho testato la regola contro un dispositivo sintetico a sei giri. Ogni corsa porta lo stesso stato terminale di esecuzione: completed . Due osservazioni sono fresche e valide. Quattro rappresentano una diversa modalità di falso successo: nessun artefatto, un artefatto più vecchio della corsa, una incompatibilità di contenuti e un fallimento del validatore. Il classificatore è deliberatamente noioso. Essa valuta i fatti in ordine fisso: L'esecuzione dell'apparecchio incluso produce: L'affermazione falsificabile è ristretta: per questo dispositivo fornito, una regola di status terminale accetta sei esecuzioni, mentre il contratto risultante ne verifica due e respinge quattro con specifici elementi di prova. Questo non è un tasso di guasto della produzione misurato. Si tratta di un test di confine che dimostra che gli stessi stati terminali possono nascondere risultati sostanzialmente diversi. La metrica utile non è percentuale delle esecuzioni che sono state completate. È verified outcomes / runs expected to deliver an outcome , riportato accanto alla copertura dei controlli. Se solo la metà dei tuoi tipi di attività ha validatori deterministici, mostra quella limitazione. Non classificare in silenzio la metà senza strumenti come sana. Legare la verifica al limite di completamento La ricevuta funziona meglio quando il tempo di esecuzione espone un limite di completamento, ma lo assegno stesso rimane indipendente. A quel confine, raccogliere le prove, eseguire il validatore, persistere la ricezione, e solo poi aggiornare lo stato operativo. Il codice Claude fornisce un punto di applicazione concreto. La sua corrente annunci di riferimento dice che TaskCompleted viene eseguito quando un compito è segnato completo. Un gancio di comando può uscire con il codice 2 per impedire il completamento e restituire il feedback quando i test o un altro controllo di accettazione falliscono. Questo rende possibile un cancello deterministico senza fidarsi di una affermazione in prosa. Si tratta di un meccanismo specifico di Claude Code, non di uno standard universale di agente, e un gancio che ha funzionato con successo ha ancora bisogno di testare l'artefatto giusto. Per i tempi di esecuzione senza un gancio di completamento di blocco, utilizzare una transizione di stato a due fasi: Non riprovare automaticamente ogni stato non verificato. missing dopo un ritardo noto di caricamento può avere bisogno di una finestra di osservazione limitata breve. validator failed può giustificare un tentativo di riparazione reversibile se l'utente lo ha già autorizzato. unverified significa che il canale di prova è fallito; non dimostra che il prodotto consegnabile sia cattivo. Un compito in attesa di una decisione irreversibile appartiene a waiting o needs human , non a un ciclo di recupero. Anche separare il successo del comando dal successo del risultato. Un processo di validatore che esce da 0 dimostra solo ciò che quel validatore effettivamente verifica. Versione del nome del validatore, registrazione della sua fonte di prova e del tempo di osservazione e revisione del contratto quando il consegnabile cambia. Una vecchia regola di accettazione può produrre un falso positivo perfettamente documentato. Escalare l'incertezza; non costruire il successo Un contratto risultante è completo solo quanto le sue aspettative dichiarate. Può mancare un artefatto non elencato, accettare un validatore debole, o leggere da una fonte di prove obsoleta. Queste sono ragioni per rivelare la copertura e la fiducia, non motivi per aggiungere un giudice modello per impostazione predefinita. Utilizzare una valutazione LLM solo per criteri che non possono essere verificati deterministicamente, mantenere visibili la sua rubrica e la sua versione e evitare di lasciare che lo stesso agente produca e classifichi in modo conclusivo il proprio lavoro. Quando le prove sono in conflitto, preferire uncertain e chiedere autorità prima di cambiare stato esterno. Sidewisp è attualmente in anteprima privata. Il sito pubblico e la libreria di articoli sono in diretta; la raccolta dell'agente di produzione salute, gli adattatori runtime e il recupero non sono generalmente spediti. Sidewisp è destinato a essere uno strato di salute insieme ai tempi di esecuzione esistenti, non a sostituire il tempo di esecuzione o il fissatore autonomo. La regola di funzionamento è semplice: lasciare che l'evento terminale runtime inizi il controllo, lasciare che le prove esterne decidano l'esito e lasciare che le prove mancanti rimangano sconosciute. Se quel modello di salute corrisponde al modo in cui si gestiscono gli agenti, l'iscrizione in anteprima privata è il passo successivo appropriato.