AI Agente osservabilità: attesa di approvazione separata dalle bancarelle

Un agente che ha smesso di produrre eventi non è necessariamente bloccato. Potrebbe essere fare esattamente la cosa sicura: aspettare una persona prima di inviare un messaggio, cambiare stato di produzione o spendere denaro. La domanda operativa non è: "Da quanto tempo il processo è stato silenzioso?" Si tratta di sapere se la richiesta di approvazione è ancora rilevante, si è rivolta a qualcuno autorizzato a decidere e può riprendere la stessa corsa interrotta. Questo dà una regola più solida all'osservabilità dell'agente AI. Una pausa è valida solo se sono valide quattro prove: l'azione proposta non è cambiata o scaduta; la richiesta ha un percorso verificato; il richiedente conserva una maniglia di continuazione duratura; e, dopo aver approvato o respinto, una ricevuta dimostra che la corsa ha consumato la decisione. Un timer è utile solo dopo che questi fatti sono stati conosciuti. Un'attesa valida ha quattro prove. La maggior parte del monitoraggio fa crollare l'approvazione in un solo stato come pending approval . Quella etichetta nasconde i fallimenti con proprietari diversi e rimedi diversi. Considerate un agente di esportazione in attesa di un proprietario di rilascio. Il processo non ha rilasciato richieste di strumenti per 25 minuti. Se l'esatta azione di esportazione è ancora in corso, il proprietario di rilascio ha ricevuto la richiesta e la corsa può riprendere dalla sua interruzione salvata, l'inattività è legittima attesa. Riprendere la procedura sarebbe dannoso: la nuova esecuzione potrebbe generare un'altra richiesta o perdere il contesto decisionale. Ora cambiate un fatto alla volta. La selezione dei dati è cambiata dopo la creazione della richiesta. La vecchia richiesta è stale , anche se qualcuno la approva. La notifica non è stata consegnata e non è allegato alcun approvatore. La richiesta è unroutable , non solo lenta. La scheda di approvazione esiste, ma la corsa interrotta non ha un manuale di ripresa duraturo. La richiesta è orphaned . L'approvazione è arrivata, ma la corsa non l'ha consumata entro il periodo di grazia dichiarato. L'agente è stuck dopo la decisione . La persona ha rifiutato. La richiesta è closed , non in ritardo. Questa separazione segue il flusso di controllo esposto dalle strutture attuali dell'agente. La Confronto SDK di OpenAI Agents elenca lo stato di esecuzione e i flussi di omologazione di riprese come capacità distinte. L'OpenAIs lista di controllo di convalida della migrazione è più esplicito sul ciclo di vita: un'azione approvata deve essere sospesa, superare un'interruzione e quindi riprendere o respingere in modo pulito. L'approvazione esiste dimostra solo la metà di quella sequenza. La quarta prova è importante perché una decisione umana non è il risultato previsto. E' il permesso per la corsa di continuare, o un rifiuto che la corsa deve gestire. L'osservabilità dovrebbe pertanto registrare sia un evento decisionale che la ricezione successiva di una continuazione. Senza quest'ultimo, un distintivo di approvazione verde può nascondere un agente fermo. Registrare un ciclo di vita decisionale, non un ciclo modale Il record più piccolo e utile è deliberatamente noioso. Ha bisogno di identità e timestamp stabili, non di una trascrizione del ragionamento del modello. requestId deduce le notifiche e le risposte. Il processo di azione lega la decisione ad un effetto specifico proposto; dovrebbe cambiare quando cambiano argomenti materiali, obiettivo, autorità o ambito di applicazione. approverRef indica un ruolo o un soggetto politico piuttosto che copiare i dati privati di una persona nella telemetria. La maniglia del curriculum indica l'interruzione duratura. Il ricevimento del curriculum dice che il richiedente ha accettato la decisione e si è trasferito nel suo prossimo stato. Il vocabolario decisionale deve anche preservare ciò che la persona ha fatto. La Specifica per l'ottenimento del MCP distingue tra accept , decline e cancel . Il declino è una risposta esplicita. Annullare è licenziare senza lo stesso impegno. Trattando entrambi come no response invitiamo un sistema automatizzato a chiedere di nuovo dopo che la persona ha già detto di no. La stessa specifica dice che i server non devono richiedere informazioni sensibili attraverso l'elicitazione, e i clienti dovrebbero rendere chiaro il server richiedente e lo scopo. Questo limite vale anche per le prove sanitarie. Conservare i campi minimi necessari per stabilire lo stato. Un riferimento di percorso, un digest di azione e un codice di decisione possono diagnosticare la maggior parte dei fallimenti di approvazione senza mantenere segreti, indicazioni grezzi o il contenuto della risposta. C'è un limite importante: delivered: true è la prova del trasporto. Non dimostra che una persona abbia visto, compreso o accettato la richiesta. Per le azioni ad alto rischio, aggiungere un riconoscimento o utilizzare una politica che richieda una decisione esplicita prima della scadenza. Non reinterpretare in silenzio la consegna come consenso informato. Un audit a sei richieste modifica la coda degli incidenti L'apparecchio di accompagnamento fissa il tempo di valutazione a 2026 07 26T16:30:00Z , consente cinque minuti per la ripresa di una corsa decisiva e tratta un battito cardiaco del richiedente come fresco per dieci minuti. Contiene sei istantanee. Eseguire l'audit con: Il risultato è intenzionalmente uno di ciascuno stato: Quattro documenti inizialmente sembrano approvazioni senza risposta. Solo la loro età non spiega cosa fare. La richiesta di esportazione è una buona attesa. La richiesta di cancellazione è scaduta. La richiesta di rotazione non ha percorso verificato. La richiesta di fattura non può essere ripristinata perché manca la maniglia di continuazione. Una stringa di stato avrebbe messo tutti e quattro nella stessa coda di allarme. Il registro di dispiegamento rivela il fallimento meno ovvio. La sua decisione umana è già presente, quindi misurando il tempo in attesa di approvazione, il rapporto sarebbe zero. Eppure non è arrivata alcuna ricevuta per il curriculum durante il periodo di grazia di cinque minuti. Questo incidente dovrebbe andare al proprietario del tempo di esecuzione, non a quello che lo approva. Chiedere alla persona di approvare di nuovo avrebbe aggiunto rumore, lasciando intatta la continuazione fallita. La richiesta di rifiuto del messaggio dimostra perché l'ordine di valutazione è importante. Le decisioni del terminal vengono controllate prima dei tempi di uscita. L'audit chiude la richiesta piuttosto che aumentarla o generare un'altra richiesta. Questo non è solo un'UX educata; conserva i confini dell'autorità umana. Le soglie del campione non sono universali. Un'anteprima di contenuti a basso rischio potrebbe riprendersi in pochi secondi. Una modifica di produzione controllata può deliberatamente attendere una finestra di manutenzione dopo l'approvazione. Imposta la grazia del curriculum a partire dal comportamento documentato del runtime e dalla politica operativa dell'azione. Registrare la soglia scelta accanto al verdetto in modo che l'operatore possa sapere se stuck è derivato da prove o da un default arbitrario. Agire per lo stato, non per il silenzio. Una volta che gli stati sono separati, la risposta agli incidenti diventa limitata. Stato Le prove Sicuro , prossima mossa . WAITING Azione attuale, percorso verificato, continuazione in diretta, nessuna decisione Lasciare in pausa la corsa; notificare solo in base alla politica di escalation concordata STALE REQUEST Richiesta scaduta o modifica dell'azione Annulla la vecchia richiesta e crea una nuova solo se l'azione attuale ha ancora bisogno di autorizzazione UNROUTABLE WAIT Mancata approvazione o mancata consegna Riparazione del percorso o aumento al titolare della polizza; non riavviare l'azione ORPHANED WAIT Manca maniglia di curriculum o richiedente obsoleto Conservare il registro della decisione, poi recuperare la corsa con esplicita autorità STUCK AFTER DECISION Decisione presente, ricezione di riprese assenza dopo la grazia Investigare il percorso di continuazione; non richiedere di nuovo la stessa approvazione CLOSED BY DECLINE Declino esplicito Fermare l'azione o offrire un'alternativa non distruttiva Il recupero automatico dovrebbe rimanere ristretto. La riprova di una notifica può essere reversibile quando l'ID della richiesta rimane stabile. Ricreare una richiesta modificata può essere sicuro dopo l'annullamento della vecchia. Ripartire l'azione sottostante è diverso: può duplicare gli effetti, aggirare l'ambito originale o separare l'eventuale risposta umana dalla nuova esecuzione. Quando le prove sono incomplete, segna l'incertitudine e chiedi prima di agire. La conclusione pratica è semplice: il silenzio non è il segnale di salute. Un'attesa valida di approvazione è un contratto in diretta tra un'azione proposta, un percorso autorizzato e una corsa ripresa. Una decisione mette fine alla fase di attesa, ma solo una ricevuta di continuazione dimostra il progresso operativo. Sidewisp è attualmente in anteprima privata. Il suo modello di salute pianificato include la diagnosi di attesa contro la bloccata e i confini espliciti di approvazione, ma la raccolta dell'agente di produzione e della salute, gli adattatori di runtime, la gestione cron, l'analisi dei costi dei token e il recupero non vengono generalmente spediti. Sidewisp non è un sistema di sostituzione del tempo di esecuzione, un gateway obbligatorio, un prodotto di tracciamento grezzo, un piano di controllo aziendale o un fissatore autonomo. Se questo modello di prova corrisponde a un fallimento che operate oggi, unirsi alla preview privata è il prossimo passo restritto.