Protocolli degli agenti AI: scegliere in base alle prove che presentano

Scegli i protocolli degli agenti AI secondo il limite che standardizzano, non secondo il quale l'acronimo appare più spesso. Utilizzare MCP quando un host ha bisogno di strumenti o contesto. Utilizzare A2A quando un agente opaco delega un compito di stato ad un altro. Trattare l'ACP come un input migratorio, perché il progetto ACP dice ora che fa parte dell'A2A. Aggiungere protocolli più ristretti solo per obblighi più ristretti, come l'autorizzazione al pagamento o alla cassa. Poi aggiungi un verificatore di risultati sopra ogni protocollo: una stretta di mano, un risultato di uno strumento, un compito terminale o un ricevimento di pagamento sono prove, ma nessuna prova necessariamente che il lavoro previsto dall'utente sia corretto. Questa regola evita due errori costosi. Il primo è chiedere a un protocollo di risolvere la scoperta, l'esecuzione, il monitoraggio, l'autorizzazione e la verifica aziendale. Il secondo è l'impilamento di protocolli che attraversano lo stesso limite, creando più adattatori senza creare più prove. Inizia con il limite, poi controlla le ricevute. Gli attuali protocolli sono più facili da considerare come strati. MCP attraversa il confine tra host e tool. Il Specifica del MCP datata 2025 11 25 definisce host, client e server; negoziazione delle capacità; risorse, richieste e strumenti; oltre agli utili per il progresso, la cancellazione, gli errori e il logging. Questo è un ottimo adattamento quando un host agente ha bisogno di scoprire uno strumento di database, leggere una risorsa o invocare una funzione esterna attraverso un contratto comune. MCP non rende il server un agente remoto con un ciclo di vita delle attività duraturo e portatile. Una richiesta JSON RPC può essere correlata e uno strumento può restituire contenuti strutturati, ma un'applicazione deve comunque preservare l'identità operativa che è importante per l'azienda. Se uno strumento di posta elettronica si esaurisce, un errore di trasporto non vi dice se la destinazione ha accettato il messaggio. Riprovare dal solo risultato del protocollo può duplicare l'effetto. A2A attraversa il confine tra agente e agente. L'attuale Specificativa A2A 1.0 definisce le schede degli agenti per la scoperta delle capacità, le attività con ID e stato stabili, i messaggi, gli artefatti, gli aggiornamenti di streaming, le notifiche push, il recupero e l'annullamento. Sostene esplicitamente il lavoro a lungo termine e umano in the loop tra agenti che possono mantenere la loro memoria interna e gli strumenti opaci. Questo ciclo di vita extra è una prova significativa di salute. Un cliente può distinguere un compito che sta ancora funzionando da uno che sta aspettando input, completato, fallito, cancellato o rifiutato. Può recuperare il compito dopo che un flusso si disconnette e ispezionare gli artefatti invece di trattare la chiusura della connessione come il completamento. Eppure un A2A COMPLETED segnala ancora quello che l'agente remoto crede sia successo. Il richiedente deve verificare che l'artefatto soddisfi il contratto originale. ACP è ora una questione di migrazione. Il Ripositorio ACP documenta ancora gli agenti manifestati, eseguite, sessioni, streaming, richieste di attesa, uscite e errori. La sua nota attuale prominente dice anche: ACP è ora parte di A2A nell'ambito della Linux Foundation. Per un servizio ACP esistente, inventariare la semantica su cui si affida e mapparla in A2A. Per un limite di greenfield remote agent, trattare ACP e A2A come scommesse concorrenti indipendenti ignorerebbe l'annuncio di convergenza del progetto. I protocolli di dominio aggiungono ricevute di dominio. L'attuale Guida per gli sviluppatori ai protocolli degli agenti di Google separa l'accesso agli strumenti MCP e la collaborazione A2A dall'autorizzazione al pagamento UCP e AP2. Questa composizione è difendibile perché gli strati rispondono a domande diverse. UCP può strutturare un'operazione commerciale. AP2 può legare l'autorizzazione ad un'intenzione e produrre una ricevuta di pagamento. Nessun ricevimento dimostra che la merce sia arrivata o abbia risolto il problema dell'utente. Il risarcimento ragionevole è pertanto: scegliere il MCP per gli strumenti e il contesto; scegliere A2A per le attività di agente remoto; migrare ACP piuttosto che avviare un secondo standard agente agente; aggiungere un protocollo di dominio solo quando le sue ricevute digitate corrispondono a un obbligo di dominio reale; non lasciare mai che il successo del protocollo sostituisca la verifica dei risultati. Punteggio di sei campi di prova, non conteggio di caratteristiche Un confronto di protocollo diventa operativo quando ogni riga risponde a sei domande: 1. Il richiamatore può scoprire la sua capacità e il suo contratto attuale? 2. C'è un'identità che sopravvive ai tentativi di ripetizione, riconnette e lavori asincroni? 3. Il richiamatore può distinguere tra stato di funzionamento, di attesa, di fallimento e di terminale? 4. L'annullamento è rappresentato e l'effetto può essere verificato? 5. C'e' prova che l'effetto collaterale esterno sia avvenuto esattamente come previsto? 6. C'è prova che il risultato promesso dall'utente sia presente e valido? Le prime quattro sono a forma di protocollo. Le ultime due sono solitamente incrociate in applicazione e stato di attività. Il confine Perfetto adattamento corrente Forte prove native La prova è ancora dovuta. Ospitare gli strumenti o il contesto MCP Negoziazione delle capacità, richieste, progresso, cancellazione, errori, risultati degli strumenti identità dell'attività commerciale duratura, riconciliazione degli effetti esterni, risultato finale Agente opaco a agente opaco A2A 1.0 Cartolina dell'agente, ID della missione, ciclo di vita, storia, artefatti, streaming, cancellazione convalida semantica degli artefatti e prova dei risultati dell'utente Servizio di agenti ACP esistente Migri verso A2A manifestare, eseguire, sessione, attendere, output, errore nel contratto di eredità Parità di migrazione, test di attuazione, risultato finale Autorizzazione al commercio e al pagamento UCP più AP2 tipo di cassa, intenzione e mandato di pagamento, ricevuta di pagamento la consegna, l'accettazione, l'utilità e qualsiasi lavoro non commerciale Native non significa che ogni implementazione abilita o implementa una funzione correttamente. Una carta di agente può essere obsoleta. Un server può pubblicizzare lo streaming e non gestire le connessioni. Un risultato di uno strumento può essere sintaticamente valido ma si riferisce al cliente sbagliato. Trattare la capacità pubblicata, il comportamento di trasporto osservato, l'effetto registrato e il risultato verificato come ricevute separate. Anche questa separazione non fa sembrare un fallimento. A2A ha un vocabolario protocollo per il lavoro a lungo termine e l'ingresso umano. MCP dispone di strutture per l'elicitazione e il progresso. Il tuo livello di salute ha ancora bisogno di un proprietario, di una scadenza, di un percorso di ripresa e di una regola di freschezza. Un'attesa valida senza proprietario è operativamente abbandonata anche se lo stato del protocollo è legale. Eseguire l'audit del debito di prova prima di scegliere un adattatore L'artefatto di accompagnamento codifica quattro scenari e i sei campi di prova in protocol health matrix.json . La sua revisione non premia un singolo vincitore. Seleziona il protocollo che corrisponde al limite e segnala ricevute parziali o mancanti. Fate partire con: Il dispositivo fisso restituisce: Ogni riga richiede un verificatore di risultati. Questo è il risultato importante, non un protocollo di classificazione. Per lo strumento database, l'enveloppo potrebbe registrare un ID di operazione stabile, set di righe atteso, ambito di autorizzazione e una query postcondition. Per la ricerca delegata, potrebbe convalidare che ogni domanda richiesta ha una risposta citata e che l'artefatto è stato generato dopo la richiesta. Per una migrazione ACP, essa dovrebbe riprodurre i casi di attesa, streaming, cancellazione e errore con entrambe le implementazioni prima che il traffico si muova. Per un acquisto, essa dovrebbe conciliare l'autorizzazione firmata e la ricevuta di pagamento, verificando separatamente l'accettazione e la consegna dell'ordine. L'audit segna deliberatamente alcune prove come parziali. L'annullamento di MCP può interrompere il lavoro del protocollo senza invertire una scrittura esterna. L'annullamento A2A può produrre un'attività annullata mentre un sistema a valle rimane attivo. L'AP2 può produrre una ricevuta di pagamento senza provare la soddisfazione. Questi non sono difetti del protocollo. Sono fatti di confine che un'attuazione deve rendere visibili. Tenere il completamento del protocollo e il completamento del risultato separati Modellare i due verdetti esplicitamente: Questo disco rifiuta un falso verde. L'agente remoto ha completato il suo protocollo e ha fornito un artefatto. Il lavoro dell'utente non è completo perché mancano una risposta richiesta e i controlli della fonte. La prossima azione più sicura è non riavviare automaticamente l'intero compito. Si tratta di richiedere le prove mancanti limitate, preservare la missione originale e le identità degli artefatti, e verificare il delta. Utilizzare la stessa divisione per le chiamate degli strumenti. Trasporto di richiesta di registrazione separatamente dalla riconciliazione degli effetti. Se lo strumento è stato temporizzato dopo aver inviato una scrittura, consulta la destinazione con la chiave di funzionamento stabile prima di riprovare. Se il protocollo non riesce a esporre una chiave duratura, crearla al confine dell'applicazione. Il completamento del comando è un'attività; un stato di destinazione verificato è una prova. La freschezza appartiene a entrambi i verdetti. Una capacità scoperta ieri potrebbe essere scomparsa oggi. Un compito completato può indicare un artefatto che è stato successivamente sostituito. Una ricevuta di pagamento può essere valida finché la consegna è in ritardo. Conservare la fonte, il tempo di osservazione, l'intervallo di aggiornamento previsto e la fiducia per ogni segnale decisivo. Una regola di selezione compatta Utilizzare questo ordine durante la revisione architettonica: 1. Nomi il confine in una frase. 2. L'operatore deve distinguere le indicazioni di guasto. 3. Selezionare il protocollo corrente più stretto che espone questi stati. 4. Segna ogni ricevuta richiesta come originaria, parziale o scomparsa. 5. Aggiungere la prova dell'applicazione solo per i campi parziali e mancanti. 6. Test di riconnessione, attesa, cancellazione, consegna duplicata, scoperta obsoleta, e casi false completate. 7. Riprendi il lavoro solo dopo che il risultato promesso ha superato il suo contratto. Non combinare MCP e A2A solo perché entrambi sono popolari. Componeli quando un agente remoto A2A ha bisogno di strumenti MCP: A2A possiede lo stato di delega e attività, mentre MCP possiede il limite degli strumenti di quell'agente. Tenete i loro documenti collegati ma distinti. Non aggiungere UCP o AP2, a meno che il flusso di lavoro non contenga effettivamente obblighi di pagamento o di pagamento. La matrice è un audit a livello di specifica, non una prova che un determinato SDK o server interagisce correttamente. Le funzionalità opzionali, le estensioni, l'autenticazione, l'autorizzazione, il comportamento di riconnessione e la conservazione della telemetria richiedono test di implementazione. I protocolli si evolvono anche; si inserisce la versione delle specifiche utilizzata da ciascun adattatore e si ripete l'audit prima dell'aggiornamento. Sidewisp è attualmente in anteprima privata. La sua direzione è quella di rendere più chiara la salute dell'agente, le prove, gli stati di attesa e la verifica sicura nei tempi di esecuzione esistenti; gli adattatori di monitoraggio della produzione e i sistemi di recupero non vengono generalmente spediti. Il principio utile oggi è indipendente da qualsiasi prodotto: scegliere il protocollo per il limite, mantenere le ricevute che può fornire, e rendere impossibile ignorare la prova di risultato mancante.