Osservabilità dell'agente durante il ripristino: il modello di ricevimento delle consegne

L'osservabilità dell'agente risponde di solito a quello che e' successo all'interno di una corsa. Questo è utile, ma non è sufficiente quando un agente delega il lavoro, esce, riprende o aspetta un altro agente. La soluzione pratica è una ricevuta di trasmissione duratura : un piccolo registro scritto al di fuori di entrambi i processi che indica chi ha accettato il lavoro, quale risultato è atteso e quali prove lo chiuderanno. Tieni tracce per il debug. Aggiungi ricevute per la continuità. Una traccia può dimostrare che uno strumento di consegna è stato restituito con successo; la ricevuta informa l'operatore se il destinatario ha accettato l'incarico e se l'artefatto promesso è stato successivamente verificato. La risposta breve: osservare il limite, non solo la corsa Una trasmissione è sana solo quando si possono distinguere quattro eventi diversi: 1. il mittente ha delegato un compito limitato; 2. il destinatario ha riconosciuto lo stesso compito; 3. è stato registrato un utile progresso o una legittima attesa; 4. il risultato atteso è stato verificato. Tali eventi possono verificarsi in diversi processi e tracce diverse. Potrebbero essere separati da un ritardo di coda, da un riavvio dell'ospite o da un'approvazione umana. Trattarli come un solo intervallo di memoria crea una fragile dipendenza: il contesto che spiega il lavoro può scomparire con il processo. OpenTelemetry descrive la propagazione del contesto come meccanismo che consente di assemblare tracce provenienti da diversi processi. Esso fornisce anche collegamenti di span per le operazioni assincrone causalmente correlate in cui il lavoro successivo non può essere un semplice span bambino. Questo risolve la correlazione. Non definisce le regole di promessa, di accettazione o di verifica dei risultati della domanda. La ricevuta riempie quel vuoto. È deliberatamente più piccolo di una trascrizione e più esplicito di una linea di registro. Dove una traccia ordinaria smette di aiutare Considerate un agente di ricerca che incarica un secondo lavoratore di verificare le fonti. Il mittente registra un successo di handoff span e uscite. Dieci minuti dopo il lavoratore inizia un nuovo processo, trova una fonte inaccessibile e aspetta l'approvazione per utilizzare un'alternativa. Ora tre stati possono sembrare ingannevolmente simili: il compito è ancora in fila e non è mai stato accettato; il lavoratore l'ha accettata e sta legittimo attendere; il lavoratore ha completato un comando ma non ha mai presentato il fascicolo di prova richiesto. La distanza che ha avvolto la consegna non può decidere tra di loro. La sua fine riuscita significa che l'operazione di consegna è ritornata senza errore. OpenTelemetry è esplicito che lo stato di span descrive l'operazione tracciata da quel span. Non è la prova che esista un risultato commerciale successivo. Il SDK OpenAI Agents illustra lo stesso confine da un'altra direzione. È registrazioni di tracciamento incorporate di esecuzioni, chiamate di strumenti, consegne, cornici di guardia e eventi personalizzati. Una group id può associare più tracce, e una handoff span può mostrare delega. L'SDK osserva inoltre che l'esportazione di tracce è in serie e può richiedere un esplicito flush quando si tratta di consegne immediate. Il ricco tracciamento migliora le prove disponibili per il debugging; ha ancora bisogno di una regola esterna per l'ispezione passata. Questo è il motivo per cui l'osservabilità dell'agente non dovrebbe far crollare il completamento del comando nel completamento del risultato. Un contratto di ricevuta minima di consegna Mantenere un solo registro di aggiunta per ogni transizione di stato. Lo storage può essere una tabella di database, un registro di coda duratura o un file NDJSON su un singolo host. La proprietà importante è che nessuno dei processi partecipanti possiede l'unica copia. Ecco una forma compatta dell'evento: Sei campi contengono la maggior parte del valore: operation id è l'identità duratura del lavoro visibile all'utente. Sopravvive ai tentativi di riavvio e riavvio. handoff id identifica un tentativo di delega. Un nuovo tentativo ottiene un nuovo documento d'identità, invece di sovrascrivere la storia. event è uno di delegated , accepted , progress , waiting , completed o outcome verified . expected artifact indica un obiettivo di verifica deterministica. Può anche indicare un test, una condizione API o una decisione di revisione. trace id indica la telemetria dettagliata senza rendere la ricevuta dipendente da tale telemetria. reason spiega un fallimento di attesa, rifiuto o verifica in termini operativi limitati. Non inserire richieste, credenziali, output di modello o carichi utili di utensili grezzi in questo registro. Una ricevuta è un indice e una macchina di stato, non un secondo backend di tracciamento. Il default ragionevole è solo le transizioni di aggiunta più uno stato corrente derivato. Aggiornare una riga mutabile è tentabile, ma distrugge le prove necessarie per distinguere un riconoscimento ritardato da una mancante. Riproduci i casi di guasto prima di scegliere gli avvisi Il supporto di questo articolo contiene quattro operazioni: una consegna verificata, una delegazione non riconosciuta, un'attesa legittima di approvazione e un falso completamento senza artefatto verificato. Il classificatore è intenzionalmente deterministico. Fate partire con: Il risultato atteso è: Due osservazioni sono state rese fuori da questo piccolo test. In primo luogo, la latenza del riconoscimento e la verifica dei risultati sono indipendenti. op 101 può essere accettato rapidamente e ancora fallire in seguito; op 102 è già malsano prima che inizi una chiamata di modello o l'esecuzione degli strumenti. Un dashboard tracciato che inizia all'esecuzione del destinatario non vedrà l'orfano. In secondo luogo, l'attesa ha bisogno di una dipendenza dichiarata. op 103 non ha avuto progressi recenti, ma trattarlo come bloccato sarebbe sbagliato perché la ricevuta indica l'approvazione di cui ha bisogno. L'assenza di attività diventa attuabile solo se combinata con lo stato e l'aspettativa. Il limite di riconoscimento di 120 secondi nel dispositivo è un esempio, non una soglia universale. Impostalo in base alla latenza di consegna osservata della coda e all'urgenza del compito. Il lavoro in batch potrebbe tollerare minuti; una manovra interattiva potrebbe tollerare secondi. L'invariante è la transizione, non il numero. Conserva la causalità senza trasformare i metadati in una perdita Utilizzare l'ID di traccia come indicatore e propagare solo gli identificatori che i lavoratori a valle hanno effettivamente bisogno. OpenTelemetrys Guida per il bagaglio avverte che il bagaglio viene comunemente inviato in intestazioni HTTP, può raggiungere terzi non intenzionali e non ha controlli di integrità integrati. Ciò rende gli obiettivi grezzi, il testo del cliente, i percorsi del file system e le credenziali valori di propagazione particolarmente scarsi. Un confine più sicuro sembra così: propagare un operation id opaco e un handoff id opaco; creare un collegamento tra tra la traccia ricevitrice e la traccia delegatrice quando il tempo di esecuzione lo supporta; mantenere l'artefatto atteso e lo stato di omologazione in uno stoccaggio affidabile e duraturo; risolvere gli identificatori per contesti sensibili solo all'interno del confine dell'ospite autorizzato; Autenticare gli autori delle ricevute, perché i metadati di correlazione non sono la prova di identità. C'è un compromesso. Una ricevuta minima non può spiegare perché un modello ha scelto uno strumento o ricostruire un'intera conversazione. E' intenzionale. Utilizzare tracce e registri per indagini dettagliate, fatte salve le vostre regole di conservazione e privacy. Utilizzare le ricevute per rispondere in modo affidabile a una domanda operativa minore: si è spostata la responsabilità e si è osservato il risultato promesso? Convertire le ricevute in stati di operatore Evitare un solo status rosso o verde. La cronologia delle ricevute sostiene cinque stati con risposte diverse: Working : accettato con recenti progressi utili. Non interrompere. Waiting : una dipendenza esterna o una decisione umana nominata è in sospeso. Invia la richiesta invece di riprovare. Stuck : accettato, non in attesa e senza progressi utili all'interno della finestra di prova del compito. Preparate un recupero limitato. Uncertain : i documenti non sono d'accordo, l'autore non è fidato o le prove richieste non sono disponibili. Chiedi prima di recitare. Resultato fallito : esecuzione completata, ma il controllo dell'artefatto non è riuscito o non è mai avvenuto. Riaprire il risultato, non tutta la traccia. Il limite di recupero e' importante. Una consegna orfanica può giustificare la consegna di nuovo se l'azione è impotente e il limite di ripetizione è noto. Una consegna in attesa non deve essere riprovata solo perché è scaduto un timer. Un stato di falso successo dovrebbe eseguire il verificatore mancante o richiedere l'artefatto mancante; riprodurre l'intero agente può duplicare gli effetti collaterali. Per ogni risposta automatizzata, registrare l'autorità, i tentativi massimi, il costo o il limite di tempo, e le prove che segneranno il recupero come successo. Il comando di ritiro è uscito da zero non è sufficiente quando la promessa originale era un rapporto pubblicato, una modifica fusa o un messaggio consegnato. Ciò significa per Sidewisp Questo modello di ricevimento corrisponde alle domande operative che Sidewisp sta progettando per chiarire: se un agente sta lavorando, aspettando, bloccato, incerto o manca il suo risultato promesso. Essa rispetta anche un limite di prodotto necessario: la diagnosi avviene prima di qualsiasi recupero e le azioni conseguenti richiedono un'autorizzazione esplicita. Sidewisp è attualmente in anteprima privata. Il suo sito pubblico e il suo sistema di articoli sono in diretta, mentre la raccolta dell'agente di produzione sanità, gli adattatori runtime e il recupero automatico non vengono generalmente spediti. Il modello di cui sopra è quindi un progetto neutro nel tempo di esecuzione che si può attuare e testare oggi, non una affermazione che Sidewisp già raccoglie queste ricevute. Se le consegne incrociate sono il punto in cui i tuoi agenti diventano opaci, unisciti alla visualizzazione privata e descrivi il tempo di esecuzione, il deposito delle ricevute e il limite di approvazione di cui hai bisogno. Tale prova è più utile di una richiesta generica di più tracce.