Memoria dell'agente Pydantic AI: Storia di audit prima della riproduzione

La memoria dell'agente Pydantic AI è pronta per la riproduzione solo quando passano sei controlli indipendenti: i messaggi tornano e tornano attraverso il serializer supportato, la storia proviene da una fonte autorizzata sul lato del server, il prompt del sistema richiesto è sopravvissuto, le chiamate degli strumenti e i risultati rimangono operativamente onesti, ogni messaggio appartiene alla conversazione prevista e l'applicazione ha una ricevuta per il risultato atteso. Un carico utile JSON valido dimostra solo il primo controllo. Tale distinzione è importante perché Pydantic AI ripara deliberatamente alcuni dati non validi del fornitore. Una chiamata di strumento cancellata può diventare un ritorno interrotto valido per il fornitore. Si può rimuovere un risultato di strumento orfano. Tali riparazioni consentono di ottenere il successo della richiesta di modello successiva, ma non dimostrano che lo strumento abbandonato sia finito o che l'utilizzatore abbia un prodotto disponibile. Tratta la serializzazione come il primo cancello, non il verdetto Il messaggi e documentazione di storia del chat ufficiale di Pydantic raccomanda ModelMessagesTypeAdapter per la memorizzazione e il caricamento della cronologia ModelMessage . Conserva i campi di messaggio che si adattano allo schema dell'adattatore, mentre un giro in giro JSON normalizza i valori che non hanno una rappresentazione JSON nativa. Questo è il limite corretto di persistenza. Non si tratta di un controllo sanitario. Per rendere la differenza misurabile, ho eseguito sette storie senza contenuti attraverso Pydantic AI 2.21.0. Ogni storia è stata serializzata con ModelMessagesTypeAdapter.dump json , ricaricata con validate json , normalizzata e hashata. I casi sono poi stati controllati separatamente per la continuità rapida, l'appariamento degli strumenti, la portata della conversazione, la fiducia e una ricevuta dei risultati fornita dall'applicazione. Tutti e sette i normali viaggi di andata e ritorno JSON corrispondono. Solo la cassa di controllo era pronta a riprodursi: Caso JSON viaggio di andata e ritorno Verdetto operativo Storia completa più ricevuta dei risultati Equa READY Avvertimento del sistema mancante Equa SYSTEM PROMPT GAP Interruzione della chiamata degli strumenti Equa INTERRUPTED TOOL Risultato degli strumenti orfani Equa ORPHAN RESULT REMOVED Identificazioni di conversazione miscelate Equa SCOPE DRIFT Modello di risposta senza ricevimento del risultato Equa MISSING OUTCOME RECEIPT Storico fornito dal cliente Equa UNTRUSTED HISTORY Il risultato non è un'argomentazione contro l'adattatore. Mostra perché un archivio schema valid e uno stato di agente sano sono affermazioni diverse. La ragionevole impostazione predefinita è quella di mantenere l'esatta uscita dell'adattatore, mantenere un identificatore di conversazione stabile e mantenere un record di risultati separato. Non appiattire i messaggi in coppie ad hoc di ruoli/contenuti se hai bisogno di metadati degli strumenti, di confini di esecuzione, di richieste del sistema o di annotamenti dell'applicazione per sopravvivere. Un percorso di persistenza minimale sembra così: Dopo il caricamento, eseguire gli altri cancelli prima di passare il risultato a message history . Continuità e portata delle conversazioni Il contratto di storia di Pydantic AI contiene una sottile impostazione predefinita: quando message history non è vuoto, il framework presuppone che la storia contenga già un prompt del sistema. Non ne genera una nuova per quella corsa. La documentazione punta a ReinjectSystemPrompt quando un database, frontend o percorso di compattazione non girano in giro per il prompt. Ciò significa che i vecchi messaggi dell'utente sono presenti non è sufficiente. Un lavoro di persistenza può conservare ogni turno di chat e rimuovere comunque l'istruzione che definisce l'autorità dell'agente o il contratto di uscita. Registrare il contratto immediato come un identificatore non segreto, non come una copia di istruzioni sensibili in un flusso sanitario. Per esempio: Al momento della riproduzione, verificare che la cronologia caricata contenga la forma richiesta da tale revisione. Se la tua applicazione utilizza intenzionalmente istruzioni dinamiche invece di richieste persistenti del sistema, controlla esplicitamente quel contratto piuttosto che trattare l'assenza come automaticamente malsana. L'identità della conversazione ha bisogno di un suo test. I messaggi attuali di Pydantic AI possono trasportare sia run id che conversation id . Una nuova corsa dovrebbe ricevere un nuovo ID di esecuzione, mentre l'ID di conversazione correlazionato giri. La fonte della versione 2.21.0 documenta e implementa regole di risoluzione separate per i due identificatori. Una porta di riproduzione pratica dovrebbe respingere o mettere in quarantena un'archivio quando: più di un ID di conversazione non nullo appare senza una decisione esplicita di fusione; l'inquilino o l'utente richiesto non possiede la conversazione; la cronologia è stata caricata in un contesto di autorizzazione e riprodotta in un altro; un richiamatore tenta di riutilizzare un ID di esecuzione precedente come se fosse la chiave di conversazione; una forchetta era prevista, ma l'applicazione ha mantenuto l'identità originale della conversazione. Queste sono decisioni di portata. Non possono essere recuperate dal testo del messaggio in modo sicuro, e un modello non dovrebbe giudicarle. Ispezionare la cronologia degli strumenti riparati senza chiamarla completa I fornitori di modelli generalmente rifiutano un risultato di uno strumento senza una chiamata di corrispondenza, o una chiamata il cui risultato richiesto non appare mai. L'attuale comportamento di pulizia della cronologia di Pydantic AI rende valido il provider di cronologia degli strumenti regolare eseguito localmente prima di una richiesta. La fonte 2.21.0 con supporto di versione mostra l'ordine: 1. rimuovere i risultati regolari degli strumenti orfani; 2. sintetizzare i risultati interrotti per le chiamate regolari degli strumenti pendenti quando la riparazione è appropriata; 3. la fusione dei messaggi consecutivi compatibili dopo l'appariamento è valida. Le restituzioni sintetizzate sono contrassegnate nei metadati con pydantic ai synthesized tool return e utilizzano il risultato neutro interrupted . Nella replay controllata, il caso interrotto ha guadagnato un marcato ritorno. Il caso dell'orfano ha perso il suo ritorno senza pari. Entrambe le storie risultanti furono più facili da accettare da un fornitore. Nessuno dei due prove ha dimostrato che l'effetto esterno dello strumento sia avvenuto. Utilizzare il marcatore come segnale di incidente: Non riprovare automaticamente ogni chiamata interrotta. Un termine può verificarsi dopo un effetto esterno irreversibile, ma prima che il suo risultato raggiunga la storia. Il prossimo passo limitato è quello di consultare la destinazione con una chiave di sicurezza o un identificatore aziendale. Riprovare solo quando la destinazione dimostra che l'effetto è assente e l'operazione può essere ripetuta in modo sicuro. Anche il trasferimento degli orfani merita una ricevuta. Se una cronologia caricata conteneva un risultato che la pulizia successivamente rimosse, conservare un evento di audit senza contenuti con l'ID di conversazione, l'ID di chiamata degli strumenti hashed, l'ora osservata e la classe di riparazione. Non conservare argomenti o risultati di strumenti grezzi, a meno che l'incidente non ne richieda effettivamente l'uso. L'esperimento ha utilizzato il simbolo privato clean message history di Pydantic AI per riprodurre esattamente il gasdotto documentato. Tale importazione è appropriata per un dispositivo diagnostico fissato, non per il codice di applicazione. Le API private possono cambiare senza garanzie di compatibilità. I controlli di produzione dovrebbero utilizzare i tipi di messaggi supportati, i metadati documentati, le ricevute delle applicazioni e i test collegati alla versione in essere distribuita. Conservare la cronologia del cliente al di fuori dei confini dell'autorità La documentazione di Pydantic è esplicita sulla cronologia fornita dal client: le superfici degli agenti del lato server sono stateless, quindi un client che può inviare la cronologia può fabbricare le chiamate degli strumenti, i risultati degli strumenti, le richieste del sistema o le approvazioni. sanitize messages restringe diverse forme non sicure, ma la disinfettazione non stabilisce che la storia presentata sia vera. Trattare il possesso di una trascrizione JSON e l'autorità di riprendere il lavoro come fatti separati. Il server dovrebbe autenticare l'appellante, autorizzare la conversazione, costruire l'insieme di strumenti consentito dall'identità del lato del server e rivalidare gli effetti ad alto rischio all'interno della funzione degli strumenti. Se un'esecuzione in pausa è importante, persiste sul server e riprende da uno stato di proprietà del server. Non accettare l'affermazione di un browser che un'approvazione è avvenuta semplicemente perché un messaggio in forma di approvazione valida. Questo è un confine di fiducia documentato, non un rapporto di vulnerabilità. Il fallimento operativo è un'applicazione che tratta una storia non affidabile come un registro di autorità. Una regola di precedenza compatta impedisce a un controllo plausibile di livello inferiore di nascondere un guasto più importante: L'ordine è deliberato. Non vale la pena diagnosticare una consegna mancante da una storia che il richiamatore non è mai stato autorizzato a riprendere. Richiedere un ricevimento di risultato dopo che la storia è passata Il portale finale appartiene all'applicazione, non al quadro modello storia. Definire l'effetto previsto prima della corsa. Per un agente di codifica, potrebbe essere un impegno contenente una modifica specifica più il passaggio alle prove. Per un agente di supporto, potrebbe essere un aggiornamento del biglietto visibile attraverso l'API del biglietto. Per una relazione pianificata, potrebbe essere un oggetto immutabile alla destinazione prevista con l'intervallo di segnalazione corretto. Immagazzinare una ricevuta con contenuto ridotto al minimo: La ricevuta dovrebbe provenire dalla lettura deterministica più forte disponibile. Un modello che dice done è prova di attività. Un resoconto di strumento che dice accettato è prova di trasporto. Una nuova lettura di destinazione che indichi la revisione prevista è la prova del risultato. Questo riguarda anche l'attesa legittima. Se l'agente viene sospeso per l'approvazione umana, lo stato corretto non è MISSING OUTCOME RECEIPT ; è un registro di attesa con un proprietario, decisione necessaria, scadenza e token di ripristino. Classificare la corsa come bloccata solo quando la finestra di progresso prevista si chiude senza un'attesa o un risultato validi. Il replay a sette casi ha un limite stretto: testano stati di errore selezionati della storia dei messaggi sotto Pydantic AI 2.21.0, non tutti i provider, gli strumenti di buildin, l'adattatore UI o i prodotti di memoria a lungo termine. Riattivare il dispositivo quando si aggiorna il framework, si modifica la serializzazione, si aggiunge un adattatore frontend o si altera l'esecuzione degli strumenti. Il modello sanitario previsto da Sidewisp comprende la persistenza del contesto, la disponibilità degli strumenti, i progressi utili e la verifica dei risultati. Sidewisp è attualmente in anteprima privata. La raccolta di agenti di produzione sanità e un adattatore Pydantic AI non sono generalmente spediti, quindi questa guida è una regola operativa indipendente piuttosto che una affermazione secondo cui Sidewisp esegue già l'audit. La decisione di riproduzione è quindi semplice: utilizzare ModelMessagesTypeAdapter per la durabilità, quindi richiedere autorità, continuità rapida, abbinamento onesto degli strumenti, ambito di conversazione e ricevuta esterna dei risultati. La storia valida del fornitore è una prova utile. Non è la stessa cosa di un agente sano.