Ciclo dell'agente SDK AI: dimostra perché si è interrotto

UNAI SDKil loop dell'agente non è integro semplicemente perché è tornato. Un ritorno dimostra che un percorso del flusso di controllo è terminato: il modello è terminato senza un'altra chiamata allo strumento, uno strumento non è stato eseguito, era necessaria l'approvazione o è stata attivata una condizione di arresto configurata. Nessuno di questi fatti prova che la fattura sia stata creata, che il ticket sia stato aggiornato o che il report sia arrivato a destinazione. L'impostazione predefinita pratica consiste nel mantenere il ciclo limitato dell'SDK, registrare una causa di interruzione esplicita e verificare separatamente il risultato esterno previsto. Considera una richiesta di approvazione come un'attesa, un passaggio o un limite di budget come un arresto limitato e una conclusione naturale senza una ricevuta di risultato come un falso completamento. Questa guida fissa il comportamento al rilascio [email protected] pacchetto eNode.js22.23.1. La riproduzione priva di contenuti di accompagnamento ha esercitato le effettive funzioni di condizione di arresto esportate in undici casi operativi. Tutte le undici classificazioni e le quattro asserzioni dirette dell'SDK sono state superate. L'SDK può interrompersi per diversi motivi legittimi ILGuida al controllo del loop dell'SDK AInomina quattro percorsi terminali: 1. il modello restituisce un motivo di fine diverso da tool calls ; 2. uno strumento chiamato non ha n execute funzione; 3. la chiamata di uno strumento necessita di approvazione; 4. una condizione di arresto configurata restituisce vera. Questi percorsi non dovrebbero confluire in uno solo completed: true campo. Implicano diverse azioni dell'operatore. Una finitura naturale non utensile può essere perfettamente valida per una risposta di ricerca, ma incompleta per un flusso di lavoro il cui contratto richiede un file nell'archivio oggetti. Uno strumento senza execute può deliberatamente agire come una struttura strutturata done segnale, ma il segnale contiene ciò che il modello affermava, non una prova indipendente del successo di un effetto collaterale. Una richiesta di approvazione è una pausa intenzionale. Un limite di passaggio indica che il limite di sicurezza ha funzionato, non che l'attività non è riuscita o è riuscita. La documentazione attuale dice ToolLoopAgent il valore predefinito è isStepCount(20) . Sostituendolo con isLoopFinished() rimuove la condizione di arresto del conteggio dei passi. Ciò può essere ragionevole per un esperimento locale strettamente controllato, ma rimuove anche un semplice limite alle chiamate dei modelli e ai costi. Se l'applicazione non è in grado di spiegare la scadenza, il budget e i controlli di cancellazione indipendenti, mantenere il limite predefinito è la decisione più sicura. Tre piccoli dettagli implementativi cambiano la diagnosi La versione bloccatafonte della condizione di arrestoè abbastanza breve da poter essere controllato direttamente: isStepCount(n) è vero quando steps.length === n , non quando il conteggio è maggiore o uguale a n . hasToolCall(name) controlla le chiamate allo strumento nel passaggio completato più recente. isLoopFinished() Restituisce sempre false come condizione di arresto, lasciando la terminazione naturale, uno strumento non eseguito o l'approvazione per terminare il ciclo. Questa semantica è importante quando si ricostruisce un incidente. Supponiamo che in un'applicazione persistano solo il testo finale e il conteggio totale dei passaggi. Una corsa in tre fasi che ha chiamato done nella sua seconda fase non può dimostrarlo successivamente hasToolCall("done") ha causato la terminazione, perché la condizione rilevante controlla l'ultimo passaggio. Allo stesso modo, un’osservazione di 21 passaggi non lo dimostra isStepCount(20) licenziato; è la prova che la policy configurata, il conteggio registrato o il limite di esecuzione differiscono dal presupposto. Mantieni gli input delle condizioni e la versione della policy selezionata con l'esecuzione. Non dedurli da una dashboard dopo il fatto. Costruisci una ricevuta di stop prima di scegliere uno stato di salute Una ricevuta utile è piccola. Non necessita di prompt, risposte di modelli o payload di strumenti grezzi: IL stopCause dovrebbe provenire dal confine dell’integrazione, non da un’ipotesi basata sulla prosa finale. Registra se l'esecuzione ha raggiunto una finitura non legata allo strumento, ha soddisfatto una condizione di arresto denominata, ha emesso una richiesta di approvazione, ha richiamato uno strumento di completamento non eseguito, è stata interrotta, è scaduta o non è riuscita nell'esecuzione dello strumento. Quindi applica una regola di precedenza: Prova Stato Decisione dell'operatore L'esecuzione dello strumento non è riuscita FAILED Diagnosticare il confine dello strumento; non riprovare ciecamente un effetto collaterale incerto. L'approvazione è in sospeso con proprietario, scadenza e token di ripresa WAITING Instradare la decisione e preservare la ripristinabilità. L'approvazione è in sospeso senza dati di instradamento WAITING UNROUTED Aggiungi un proprietario e un percorso di escalation prima che l'attesa diventi invisibile. Timeout scaduto senza progressi utili STUCK Esamina gli ultimi progressi durevoli e scegli un recupero limitato. Passaggio, token o limite di interruzione utente attivato BOUNDED STOP Conservare il lavoro parziale; decidere se una nuova corsa limitata è giustificata. Finitura naturale o esplicita done più ricevuta esito VERIFIED COMPLETE Chiudi la corsa. Finitura naturale o esplicita done senza ricevuta di esito FALSE COMPLETE Verificare la destinazione o riaprire l'attività. I segnali non sono d'accordo oppure la causa non è stata registrata UNCERTAIN Chiedi prima di agire. L'ordine conta. Un timeout al quarto passo è comunque un timeout anche se il conteggio dei passi risulta essere uguale a quattro. Una richiesta di approvazione dovrebbe rimanere in attesa anziché essere trascinata in uno stato generico incompleto. Una finitura naturale senza risultati finali dovrebbe rimanere falsamente completa anche quando il testo sembra sicuro. Riproduci la politica senza chiamare un modello L'audit ha importato quanto rilasciato isStepCount , hasToolCall , E isLoopFinished funzioni. Passava array privi di contenuto di record di passaggi completati e univa il loro output al classificatore di ricevute. Non era necessaria alcuna chiamata di modello, prompt, segreto o effetto di strumenti esterni. Quattro asserzioni stabiliscono il confine dell'SDK: Il dispositivo a undici casi ha poi coperto la finitura naturale con e senza esito, done con e senza risultato, limite di passaggio, budget del token, approvazione instradata e non instradata, errore dello strumento, timeout e interruzione dell'utente. Le coppie rivelatrici non erano fallimenti esotici. Entrambi gli apparecchi con finitura naturale avevano identiche cause di flusso di controllo; divenne solo quello con la ricevuta di destinazione VERIFIED COMPLETE . La stessa divisione è apparsa per il done attrezzo. Questo è il risultato falsificabile principale: se la sola terminazione del loop si fosse rivelata un completamento utile, quei dispositivi accoppiati avrebbero dovuto ricevere lo stesso sano verdetto. Non l'hanno fatto. Verificare la destinazione dopo l'interruzione del flusso di controllo ILRiferimento a ToolLoopAgentespone i passaggi completati sul risultato generato e accetta abortSignal e controlli di timeout. Questi campi sono prove utili, ma l'applicazione possiede ancora la definizione di successo. Scegli il controllo deterministico più economico che risponde alla richiesta effettiva dell'utente: per un file, verificare il percorso previsto o la chiave dell'oggetto, il tipo di contenuto, la dimensione minima e un hash o uno schema specifico dell'attività; in caso di mutazione del database, leggere il record di destinazione e confrontare i campi previsti; per un messaggio, conservare la ricevuta del fornitore e l'identità del destinatario; per una distribuzione, verificare la versione immutabile, la risposta sanitaria pubblica e il percorso rivolto all'utente; per un'analisi, convalidare le sezioni richieste, la copertura della fonte e l'output leggibile dalla macchina prima di accettare la prosa. Non rendere la ricevuta dell'esito una seconda copia dell'affermazione del modello. {"status":"done"} emesso dallo stesso circuito non è una verifica indipendente. La ricevuta dovrebbe provenire dalla destinazione, da un validatore deterministico o da una decisione umana quando il risultato non può essere controllato in modo sicuro tramite codice. Anche l'approvazione necessita di un confine separato. La documentazione dell'SDK mostra che una richiesta di approvazione può essere raccolta, aggiunta alla conversazione come risposta di approvazione e passata a una chiamata successiva. Operativamente, ciò significa che l’attesa deve conservare un contesto sufficiente per riprendere la stessa decisione. Un proprietario senza token di curriculum crea lavori di ricostruzione manuale; un token senza proprietario crea una coda invisibile. Ciò che questa replica non dimostra L'esperimento non ha invocato un modello di provider, non ha trasmesso in streaming output parziali né ha eseguito uno strumento esterno. Pertanto non stabilisce il comportamento del motivo di fine specifico del provider, i tempi di cancellazione della rete o l'idempotenza degli effetti collaterali. Questi appartengono ai test di integrazione attorno al modello, agli strumenti e alla destinazione effettivi. Inoltre, non consiglia un passaggio universale o un limite di token. Una ricerca in quattro passaggi e una migrazione in quaranta passaggi hanno inviluppi diversi. Il requisito operativo è che i limiti selezionati siano espliciti, registrati e legati ad un'azione sicura quando raggiunti. La regola è più ristretta e più duratura: preservare il motivo per cui il ciclo si è interrotto, distinguere le attese legittime dai fallimenti e richiedere prove della destinazione prima di dichiarare il completamento utile. Sidewispè una piattaforma per l'integrità degli agenti IA destinata a semplificare l'ispezione di prove, stati di attesa, recupero limitato e verifica dei risultati nei runtime esistenti. Raccolta agente salute di produzione eAI SDKil monitoraggio non viene generalmente spedito oggi. Sidewisp è attualmente in anteprima privata. Se questa ricevuta di risoluzione corrisponde a una modalità di errore nei tuoi agenti, la lista d'attesa per l'anteprima privata è il luogo appropriato per condividere il tempo di esecuzione e il limite delle prove di cui hai bisogno.