Osservabilità multi-agente: verifica della topologia di coordinamento

L’osservabilità multi agente dovrebbe rispondere a una domanda più rigorosa di “ogni intervallo registrato è terminato?” Dovrebbe indicare se gli agenti che hanno effettivamente partecipato e i percorsi effettivamente utilizzati corrispondono al progetto di coordinamento approvato per questa esecuzione. L'impostazione predefinita pratica è a contratto di topologia con versione : un piccolo manifest degli agenti consentiti, degli archi diretti consentiti e degli archi previsti nella fase di esecuzione corrente. Unisci quel manifest alle ricevute di interazione senza contenuti. Una traccia riuscita può quindi essere classificata come funzionante, in attesa, incompleta, non sicura, ambigua o falsamente completa invece di diventare verde per impostazione predefinita. Questo è importante perché una traccia registra ciò che è accaduto. Non può contenere un intervallo per una delega obbligatoria che non si è mai verificata. Inoltre, non può decidere che un percorso diretto osservato sia stato vietato a meno che non venga fornito il grafico previsto. La stessa distinzione appare nelle attuali linee guida sull’architettura: Microsoft architettura di riferimento multi agente richiama i flussi di messaggi tra agenti e i modelli di coordinamento come segnali di osservabilità speciali, mentre il Azure Architecture Center avverte che l'orchestrazione multi agente aggiunge un sovraccarico di coordinamento e nuove modalità di errore. Utilizzare la complessità più bassa che soddisfi in modo affidabile il compito; quando sono giustificati più agenti, rendere testabile la loro topologia. Una traccia non può dimostrare la topologia prevista API di tracciamento di OpenTelemetry fornisce le giuste primitive di correlazione: identità traccia e span, parentela, collegamenti, eventi, timestamp, attributi e stato. Tali primitive possono descrivere un albero delle chiamate osservato o una relazione asincrona. Non dichiarano quali agenti erano autorizzati, quale versione del percorso era attiva o quale bordo avrebbe dovuto apparire ma non è apparso. Supponiamo che un orchestratore deleghi la ricerca, il ricercatore consegni le prove a un verificatore e il verificatore emetta un verdetto. Ogni evento osservato può avere status: "ok" in almeno cinque brutte situazioni: la corsa ha utilizzato la politica di routing di ieri; il ricercatore ha chiamato direttamente un editore, ignorando la revisione; un agente non registrato è entrato nel grafico; l'orchestratore ha delegato due volte la stessa route di proprietà; il genitore ha dichiarato il completamento prima che il verificatore restituisse. Una query "tutti gli eventi OK" non rileva errori in tali record. Un controllo della topologia confronta invece due insiemi: Mantieni questo livello privo di contenuti. Una ricevuta necessita di identità di esecuzione e agente stabili, tipo di percorso, versione della topologia, identità dell'evento, tempo di osservazione e stato locale. Non necessita di prompt, risposte, segreti, argomenti di strumenti o percorsi di file assoluti. Il contratto è deliberatamente separato da un quorum di completamento fan out. Un quorum chiede se i rami richiesti sono stati restituiti. Un grafico di attesa chiede quale dipendenza sta bloccando il progresso. Una ricevuta di trasferimento durevole chiede se la responsabilità è sopravvissuta a una coda o al limite di riavvio. La conformità della topologia pone una domanda preliminare: è proprio questo il grafico di coordinazione che intendevamo eseguire? Costruisci un contratto di coordinamento con versione Inizia con identità esplicite e bordi diretti. Non dedurre il grafico consentito da quanto apparso nell'ultima traccia; questo semplicemente benedice la deriva dopo il fatto. L'insieme consentito non è uguale all'insieme previsto. Una fase di sola ricerca potrebbe prevedere due deleghe e nessun vantaggio da parte dell'editore. Una fase di pubblicazione completa potrebbe prevedere il trasferimento della ricerca, la restituzione del verificatore, la delega dell'editore e la restituzione dell'editore. Blocca quel set specifico della fase quando inizia la corsa. Altrimenti, un vantaggio opzionale può tranquillamente diventare obbligatorio nel bel mezzo di un fallimento, oppure un vantaggio richiesto può scomparire dalla definizione prima che qualcuno se ne accorga. Un classificatore compatto può utilizzare questa precedenza: 1. contratto stantio — la versione dell'evento è diversa dalla versione fissata; 2. agente sconosciuto — uno dei due endpoint è esterno all'insieme di identità approvato; 3. bordo proibito — non sono ammessi il percorso diretto e la tipologia di interazione; 4. percorso ambiguo — lo stesso vantaggio posseduto appare più di una volta senza un'esplicita regola di molteplicità; 5. falso completo — un genitore terminale è privo del bordo atteso o della ricevuta dell'esito verificato; 6. in attesa — un arco atteso è assente, la dipendenza denominata è esplicita e la scadenza non è passata; 7. incompleto — un fronte atteso è ancora assente dopo la sua scadenza; 8. sano o funzionante — l’insieme osservato corrisponde al piano attuale, con “sano” riservato per un risultato finale verificato. Ordinare è importante. Se un agente ombra utilizza un percorso proibito e anche il genitore è in ritardo, "incompleto" è troppo debole: l'operatore deve prima contenere una topologia non approvata. Al contrario, un’attesa dichiarata prima della scadenza non è uno stallo. È uno stato di dipendenza sano che dovrebbe raggiungere il proprietario corretto senza innescare un ripristino distruttivo. Il routing dinamico è la limitazione principale. Un sistema può legittimamente scegliere tra agenti specializzati in fase di esecuzione. Rappresenta quella scelta come una classe di bordi delimitati o produci l'esatto piano di esecuzione prima dell'invio. Un carattere jolly come orchestrator è facile da mantenere ma rimuove la maggior parte del valore diagnostico. Le modifiche alla versione dovrebbero essere verificabili e un'esecuzione non dovrebbe mai adottare silenziosamente una nuova versione a metà. Il campionamento è un altro confine. È possibile campionare tracce pesanti, ma le ricevute della topologia compatta utilizzate per le decisioni sanitarie non possono scomparire con la stessa politica. Se una ricevuta richiesta non è disponibile, segnalarlo uncertain O incomplete ; non ricostruire il verde da una traccia parziale. Riproduci la deriva prima di fidarti del completamento Ho riprodotto nove casi privi di contenuto contro il contratto di cui sopra. Il dispositivo includeva un completamento corretto, lavoro corrente, un'attesa legittima, un limite mancato dopo la scadenza, una topologia obsoleta, un percorso diretto proibito, un agente sconosciuto, proprietà duplicata del percorso e un terminale principale senza ricevuta di ritorno. L'audit deterministico ha soddisfatto tutti i nove stati attesi. Una regola ingenua: esiste almeno un evento, lo stato di ogni evento locale lo è ok e l'elemento principale non è fallito: contrassegnato tutti e nove i casi verdi . Solo uno era sano. Sei di questi nove verdi ingenui erano non sicuri, incompleti, obsoleti, ambigui o falsi completi; i restanti due stavano lavorando e aspettando, afferma che non dovrebbe crollare in completa salute. Caso Tutti gli eventi registrati sono OK? Verdetto di topologia Significato dell'operatore : Grafico completo più ricevuta esito SÌ healthy Il grafico pianificato e il risultato finale vengono verificati Bordi pianificati attuali SÌ working Il lavoro utile può continuare; non intervenire Mancata restituzione prima della scadenza SÌ waiting Notifica o osserva la dipendenza denominata Stesso reso mancante dopo la scadenza SÌ incomplete Esaminare il primo bordo atteso assente Vecchia versione della topologia SÌ stale contract Smetti di confrontare la corsa con il design sbagliato Percorso diretto non approvato SÌ forbidden edge Contenere il percorso prima di ritentare il lavoro Partecipante sconosciuto SÌ unknown agent Verificare identità e autorità Percorso di proprietà duplicato SÌ ambiguous route Riconciliare proprietà e possibili effetti duplicati Terminale genitore, reso assente SÌ false complete Riaprire la corsa; al completamento mancano le prove richieste Puoi riprodurre la decisione con una piccola funzione sui tasti laterali normalizzati: Esegui i controlli della topologia prima del punteggio di avanzamento, qualità o risultato. Quindi mantieni espliciti i confini del verdetto: la conformità della topologia dimostra solo che è stata osservata la forma di coordinazione approvata; working richiede nuove prove di movimento utile, non semplicemente più eventi; waiting richiede una dipendenza denominata e una scadenza; healthy il completamento richiede una destinazione deterministica o una ricevuta consegnabile quando disponibile; le prove incerte devono rimanere incerte; qualsiasi ripristino attivo necessita di autorità limitata, visibilità e verifica post azione. Ciò fornisce all'operatore una regola di adozione ristretta: non fidarsi del completamento di più agenti finché la topologia bloccata dell'esecuzione, la fase corrente e la ricezione del risultato finale non concordano. Un grafico corrispondente è una prova necessaria, non una prova che la risposta sia corretta. Sidewisp è attualmente in anteprima privata. Il sito pubblico ad accesso anticipato e la dimostrazione interattiva sono attivi, ma non vengono forniti un adattatore di monitoraggio multi agente di produzione, un raccoglitore di dati sanitari in tempo reale e un esecutore di ripristino automatizzato. Il ruolo previsto di Sidewisp è quello di aggiungere un livello di integrità ai runtime esistenti e rendere più facili da ispezionare le prove, la gravità, l'incertezza e l'azione successiva più sicura, non per sostituire il runtime o agire senza l'autorità umana.