Osservabilità dell'agente per la fame in coda

L'osservabilità dell'agente non dovrebbe definire una coda malsana solo perché è lunga. Dovrebbe chiedersi quanto tempo ha atteso il compito runnable più antico, se un lavoratore è raggiungibile, se un slot è libero e se i risultati verificati sono ancora in arrivo. Tali fatti distinguono una legittima dipendenza da una capacità insufficiente, da un lavoratore morto, da un compito avvelenato o da un dispatcher che ha smesso di assegnare un lavoro. Il default pratico è quello di registrare eligibleAt per ciascuna attività e di avvisare quando now eligibleAt supera l'obiettivo iniziale di tale classe di attività. Non avviare l' orologio mentre è ancora valido un ritardo dichiarato di dipendenza o di ripetizione. La profondità della coda rimane un contesto utile, ma l'età di corsa è il segnale decisionale. La profondità della coda è il contesto, non una diagnosi. Un conteggio compressa a differenza degli stati. Dieci compiti possono essere in attesa di approvazione umana, pronti a iniziare, già affittati ai lavoratori, ritardati da backkoff o ripetutamente falliti. Trattare tutti e dieci come un unico arretrato fa sembrare un'affollata coda rotta e può nascondere un vecchio compito dietro un piccolo conto. Gli stessi servizi di coda rivelano la limitazione. Amazon SQS pubblica sia ApproximateNumberOfMessagesVisible che ApproximateAgeOfOldestMessage , e etichetta molti valori approssimativi a causa della sua architettura distribuita. Google Pub/Sub è più esplicito nella sua orientamenti di monitoraggio: il numero assoluto di messaggi non riconosciuti non è necessariamente significativo, mentre un piccolo arretrato costante con un'età di messaggi più vecchia in costante crescita può indicare messaggi bloccati. Per il lavoro degli agenti, l'età dei messaggi grezzi e' ancora troppo grossa. Un compito in coda alle ore 09:00 ma bloccato dall'approvazione fino alle ore 10:00 non deve spendere un'ora del suo bilancio iniziale prima di essere ammissibile. Definire: Lasciare assente eligibleAt mentre è aperta una dipendenza limitata. Registrare separatamente il tipo di dipendenza, il proprietario e la scadenza. Se non esistono prove di ammissibilità né una dipendenza valida, restituire uncertain ; non convertire i dati mancanti in uno zero sano. Costruire un libro maggiore di ammissibilità Un record minimo può rimanere privo di contenuti: Campo Domanda operativa taskId Quale sicurezza opaca è influenzata dall'identità di attività? eligibleAt Quando un lavoratore potrebbe iniziare legittimamente? dependency Chi o cosa è il proprietario della sala d'attesa, e fino a quando? deliveryAttempts Il compito ha esaurito la sua politica di riprova limitata? workerHeartbeatAt È possibile raggiungere almeno un lavoratore compatibile? slots e active La capacità è occupata o disponibile? lastVerifiedProgressAt I risultati sono ancora in movimento? Questo e' deliberatamente piu' piccolo di una traccia. Il OpenAI Agents SDK documentazione di tracciamento descrive generazioni, chiamate di funzione, guardrails, consegne e eventi personalizzati. Tali documenti aiutano a spiegare l'esecuzione, ma non indicano quando un compito in fila è diventato idoneo o se il risultato previsto è stato osservato. Unire tracce dettagliate al libro maggiore con un identificatore di esecuzione sicura; non fare in modo che l'attività di traccia interrompa il progresso della coda. Utilizzare un ordine decisionale che preservi la causa: 1. Mancano prove di idoneità e di dipendenza: uncertain . 2. Nessuna attività eseguibile più un affittamento di dipendenza valido è waiting . 3. L'età correttiva all'interno dell'obiettivo di partenza è healthy . 4. Un compito più antico oltre il suo budget di consegna è poisoned head . 5. Il vecchio lavoro di corsa più i battiti cardiaci dei lavoratori obsoleti sono worker unreachable . 6. Vecchio lavoro in esecuzione, tutte le slot occupate, e il nuovo progresso verificato è capacity bound . 7. Un vecchio lavoro in esecuzione più un nuovo lavoratore e una slot libera è dispatcher stuck . L'ordine e' importante. Se un compito ha già esaurito il suo budget di tentativo, l'aggiunta di lavoratori non è la prima riparazione. Se nessun lavoratore è raggiungibile, incolpare la spedizione è prematuro. Se tutte le slot sono occupate e i risultati arrivano ancora, il sistema è lento contro il suo obiettivo ma non immobile. Riproduci sette stati di coda L'artefatto di accompagnamento congela il tempo di osservazione a 2026 07 26T04:50:00Z , imposta una finestra di 120 secondi di freschezza dei lavoratori e un obiettivo di partenza di 300 secondi, quindi valuta sette code sintetiche. La corsa prodotta: dispatcher gap è il caso decisivo. Il suo compito più antico ha aspettato 900 secondi, il battito cardiaco del lavoratore ha solo 20 secondi e entrambe le slot sono libere. Una maggiore capacità non sarebbe d'aiuto; occorre controllare le prove di assegnazione o di rotta. Al contrario, all slots busy ha un'età di esercizio di 840 secondi, nessun slot libero, e un risultato verificato 80 secondi fa. L'obiettivo di tale sistema prevede un limite di capacità. bounded dependency è stato sequestrato prima di entrambi i casi, ma è waiting : l'approvazione ha un proprietario nominato e una scadenza futura, quindi non c'è un orologio in esecuzione da violare. silent worker mantiene il vecchio lavoro pronto separato dal fallimento di accessibilità. poisoned oldest impedisce che una quinta consegna fallita scompaia all'interno di una coda che sembra normale. missing eligibility rimane incerto. L'esperimento dimostra la regola decisionale, non la prevalenza. Un caso sintetico per stato non può stabilire soglie di produzione e non modella l'inversione di priorità, le code divisi, la pregiudizia dell'orologio o i vincoli di affinità tra attività. Addizione dell'età con movimenti di capacità e risultati L'età correttiva diventa praticabile solo accanto alla capacità e al progresso. Un vecchio compito con ogni slot compatibile occupato suggerisce una decisione di scalare o di plasmare il carico di lavoro. La stessa età con un slot aperto punti di spedizione, routing, affinità di attività, o un affitto perso. Evitate tre scorciatoie tentanti: Non avvertirti la fame. Un ritardo di inizio medio basso può coesistere con un compito che non viene mai eseguito. Segui l'età più antica e un percentil per classe di attività. Non mescolare lavori bloccati e eseguibili. Mantenere visibile l'età della dipendenza, ma escludendola dall'obiettivo iniziale fino a quando la dipendenza non si risolve o il suo contratto di locazione scade. Non dedurre il progresso da contratti di locazione o richieste di strumenti. La capacità è realmente in movimento solo quando un artefatto specifico per un'attività, un controllo di accettazione o una ricevuta di destinazione cambiano. Scegli l'obiettivo iniziale dalla promessa del lavoro. Un'attività di codifica interattiva, un rapporto programmatico e una riconciliazione notturna non dovrebbero condividere 300 secondi perché il dispositivo lo fa. Misurare il normale tempo di ammissibilità per l'avvio, fissare un obiettivo rilevabile con un buffer e versionarlo. Partizione per pool di lavoratori o classe di attività compatibili in modo che una coda non correlata non possa mascherare la fame. Quando il termine di dipendenza passa, non lo prolungare in silenzio. Calcolare l'ammissibilità a partire dalle prove che hai e informare il proprietario nominato. Quando il battito cardiaco di un lavoratore è obsoleto, verificare la connettività prima di riprovare lavori che potrebbero ancora essere in esecuzione altrove. Quando un compito avvelenato raggiunge il suo budget di consegna, la quarantena o la richiesta di revisione piuttosto che permettergli di monopolizzare il capo della coda. Mantenere la diagnosi separata dall' intervento L'età corretta ti dice che una promessa operativa è in ritardo; i fatti combinati suggeriscono il perché. Non autorizzano una riparazione automatica. Un verdetto dispatcher stuck può preparare un controllo di spedizione limitato. capacity bound può aprire una revisione della capacità. worker unreachable può richiedere un controllo di accessibilità. Nessuno di questi stati da solo consente di riavviare un host, duplicare un effetto collaterale, cambiare le credenziali o spendere oltre un limite di ripetizione. Dopo qualsiasi azione approvata, richiedere nuove prove: il compito ha ricevuto un contratto di locazione, un'impronta digitale del progresso è stata modificata o il risultato previsto è stato verificato in modo indipendente. Un comando che restituisce zero è attività, non recupero. Ci sono dei confini importanti. Le metriche dell'età del fornitore possono essere approssimative. La skew dell'orologio può creare età negative impossibili, quindi confrontare il tempo del collezionista e del produttore prima di utilizzare il risultato. Le code di priorità possono legittimamente far invecchiare il lavoro a basse priorità; esporre la politica piuttosto che definirla sana per caso. Un compito può anche mantenere un slot di apparenza libera attraverso un contratto di locazione non osservato, quindi la mancanza di dati sul contratto di locazione dovrebbe ridurre la fiducia. La regola risolta è ristretta: iniziare l'orologio quando il lavoro è effettivamente eseguibile, avvertire l'attività eseguibile più antica contro un obiettivo specifico per la missione, quindi utilizzare la freschezza del lavoratore, i posti di lavoro gratuiti, il bilancio di riprova e il movimento verificato degli esiti per classificare la causa. Sidewisp è attualmente in anteprima privata. Il suo sito pubblico e la sua biblioteca di articoli sono in diretta, ma la raccolta dell'agente di produzione sanità, gli adattatori runtime e il recupero non sono generalmente spediti. Sidewisp è destinato a funzionare insieme ai tempi di esecuzione esistenti, non a sostituirli o a fungere da fissatore autonomo. Se le prove di età in corso rendono più facile giudicare le operazioni degli agenti, è possibile accedere all'accesso anticipato mentre si tratta del prodotto come preview piuttosto che di monitoraggio distribuito.