Protocoles d'agents AI: choisissez en fonction des preuves qu'ils exposent

Choisissez les protocoles d'agent AI selon la limite qu'ils normalisent, et non selon l'acronyme qui apparaît le plus souvent. Utilisez MCP lorsqu'un hôte a besoin d'outils ou de contexte. Utilisez A2A lorsqu'un agent opaque délègue une tâche d'état à un autre. Traiter l'ACP comme une entrée migratoire, car le projet ACP fait maintenant partie de l'A2A. Ajouter des protocoles plus restreints uniquement pour des obligations plus restreintes, telles que l'autorisation de paiement ou de paiement. Ensuite, ajoutez un vérificateur de résultats au dessus de chaque protocole: une poignée de main réussie, un résultat d'outil, une tâche terminale ou un reçu de paiement sont des preuves, mais aucune ne prouve nécessairement que le travail prévu par l'utilisateur est correct. Cette règle évite deux erreurs coûteuses. Le premier est de demander à un protocole de résoudre la découverte, l'exécution, la surveillance, l'autorisation et la vérification des affaires. Le second est de mettre en pile des protocoles qui franchissent la même frontière, créant plus d'adaptateurs sans créer plus de preuves. Commencez par la limite, puis inspectez les reçus. Les protocoles actuels sont plus faciles à raisonner en tant que couches. MCP traverse la frontière de l'hôte à l'outil. Le Spécification du PCM datée de 2025 à 11 à 25 ans définit les hôtes, les clients et les serveurs; la négociation des capacités; les ressources, les invites et les outils; plus les utilitaires pour la progression, l'annulation, les erreurs et le dépistage. C'est un bon ajustement lorsqu'un agent hôte doit découvrir un outil de base de données, lire une ressource ou invoquer une fonction externe par un contrat commun. MCP ne fait pas du serveur un agent distant doté d'un cycle de vie durable et portable des tâches. Une demande JSON RPC peut être corrélée et un outil peut retourner un contenu structuré, mais une application doit toujours préserver l'identité opérationnelle qui est importante pour l'entreprise. Si un outil de messagerie est désactivé, une erreur de transport ne vous indique pas si la destination a accepté le message. Une nouvelle tentative à partir du seul résultat du protocole peut dupliquer l'effet. A2A traverse la frontière agent agent. Le Spécification A2A 1.0 actuel définit les cartes agent pour la découverte de capacités, les tâches avec des identifiants et un état stables, les messages, les artefacts, les mises à jour en streaming, les notifications push, la récupération et l'annulation. Il soutient explicitement le travail à long terme et humain en boucle entre les agents qui peuvent garder leur mémoire interne et les outils opaques. Ce cycle de vie supplémentaire est une preuve significative de santé. Un client peut distinguer une tâche qui fonctionne encore de celle qui attend l'entrée, l'achèvement, l'échec, l'annulation ou le rejet. Il peut récupérer la tâche après la déconnexion d'un courant et inspecter les artefacts au lieu de considérer la fermeture de la connexion comme terminée. Pourtant, une tâche A2A COMPLETED rapporte toujours ce que l'agent à distance croit avoir eu lieu. L'appelant doit vérifier que l'artefact satisfait au contrat original. ACP est désormais une question de migration. Le Référentiel ACP continue de documenter les manifestes d'agent, les exécutions, les sessions, le streaming, les demandes d'attente, les sorties et les erreurs. Son avis actuel éminent indique également: ACP fait désormais partie d'A2A dans le cadre de la Fondation Linux. Pour un service ACP existant, faites un inventaire des sémantiques sur lesquelles vous vous appuyez et tracez les à A2A. Pour une frontière de l'agent à distance de champ vert, traiter ACP et A2A comme des paris concurrents indépendants ignorerait l'avis de convergence du projet lui même. Les protocoles de domaine ajoutent des reçus de domaine. Le guide des développeurs sur les protocoles des agents actuel de Google sépare l'accès aux outils MCP et la collaboration A2A de la vérification UCP et de l'autorisation de paiement AP2. Cette composition est défendable parce que les couches répondent à des questions différentes. UCP peut structurer une opération commerciale. AP2 peut lier l'autorisation à une intention et produire un reçu de paiement. Aucun reçu ne prouve que les marchandises sont arrivées ou que le problème de l'utilisateur a été résolu. Le défaut raisonnable est donc: choisir le MCP pour les outils et le contexte; choisir A2A pour les tâches d'agent à distance; migrer ACP plutôt que de lancer une deuxième norme agent agent; ajouter un protocole de domaine uniquement lorsque ses reçus typés correspondent à une obligation de domaine réelle; Ne laissez jamais le succès du protocole remplacer la vérification des résultats. Score six champs de preuve, pas le nombre de caractéristiques Une comparaison de protocoles devient opérationnelle lorsque chaque ligne répond à six questions: 1. L'appelant peut il découvrir la capacité et son contrat actuel ? 2. Y a t il une identité qui survit à des essais répétitifs, une reconnexion et un travail asynchrone ? 3. L'appelant peut il faire la distinction entre les états de travail, d'attente, d'échec et de terminaison? 4. L'annulation est elle représentée et son effet peut il être vérifié? 5. Y a t il des preuves que l'effet secondaire externe s'est produit exactement comme prévu ? 6. Y a t il des preuves que le résultat promis par l'utilisateur est présent et valable? Les quatre premiers sont en forme de protocole. Les deux derniers passent généralement en application et en état d'affaires. La frontière Meilleur ajustement au courant Des preuves natives solides Des preuves encore à déposer L'hôte des outils ou du contexte MCP négociation des capacités, demandes, progrès, annulation, erreurs, résultats de l'outil identité durable de l'exploitation commerciale, réconciliation des effets externes, résultat final L'agent opaque à l'agent opaque A2A 1.0 Carte d'agent, identifiant de mission, cycle de vie, historique, objets, streaming, annulation validation sémantique de l'artefact et preuve de résultats utilisateur Service d'agent ACP existant migrer vers A2A manifeste, exécute, session, attend, sortie, erreur dans le contrat hérité Parité de migration, tests de mise en œuvre, résultat final Autorisation du commerce et des paiements UCP plus AP2 type de paiement, mandat d'intention et de paiement, reçu de paiement la livraison, l'acceptation, l'utilité et tout travail non commercial Native ne signifie pas que chaque déploiement permet ou implemente correctement une fonctionnalité. Une carte d'agent peut être obsolète. Un serveur peut faire de la publicité en streaming et gérer mal les connexions. Un résultat d'outil peut être syntaxiquement valide mais se référer au mauvais client. Traiter la capacité annoncée, le comportement de transport observé, l'effet enregistré et le résultat vérifié comme des reçus distincts. Cette séparation n'arrête pas d'attendre de paraître un échec. A2A possède un vocabulaire de protocole pour le travail à long terme et l'apport humain. MCP dispose de facilités d'obtention et de progrès. Votre couche de santé a encore besoin d'un propriétaire, d'une date limite, d'un parcours et d'une règle de fraîcheur. Une attente valide sans propriétaire est opérationnellement abandonnée même si l'état du protocole est légal. Exécuter l'audit de la dette de preuve avant de choisir un adaptateur L'artefact d'accompagnement encode quatre scénarios et les six champs de preuve dans protocol health matrix.json . Son audit ne décerne pas un seul gagnant. Il sélectionne le protocole qui correspond à la limite et rapporte des reçus partiels ou manquants. Faites le avec: L'appareil fixe renvoie: Chaque ligne nécessite un vérificateur de résultats. C'est le résultat important, pas un protocole de classement. Pour l'outil de base de données, l'enveloppe peut enregistrer un identifiant d'opération stable, un ensemble de lignes attendues, la portée des autorisations et une requête postcondition. Pour la recherche déléguée, elle pourrait valider que chaque question requise a une réponse citée et que l'artefact a été généré après la demande. Pour une migration ACP, elle devrait revoir les cas d'attente, de diffusion en continu, d'annulation et d'erreur contre les deux mises en œuvre avant le déplacement du trafic. Pour un achat, il doit concilier l'autorisation signée et le reçu de paiement, puis vérifier séparément l'acceptation et la livraison de la commande. L'audit marque délibérément certaines preuves comme partielles. L'annulation de MCP peut arrêter le travail du protocole sans inverser une écriture externe. L'annulation A2A peut entraîner l'annulation d'une tâche alors qu'un système en aval reste actif. AP2 peut produire un reçu de paiement sans prouver la réalisation. Ce ne sont pas des défauts de protocole. Il s'agit de faits limités que la mise en œuvre doit rendre visibles. Garder séparément l'achèvement du protocole et l'achèvement du résultat Modélisez les deux verdicts explicitement: Ce disque refuse un faux vert. L'agent distant a terminé sa tâche de protocole et a fourni un artefact. Le travail de l'utilisateur n'est pas complet car une réponse requise et les vérifications de source manquent. La prochaine étape la plus sûre est de ne pas redémarrer la tâche automatiquement. Il s'agit de demander les preuves manquantes limitées, de préserver la tâche originale et les identités des artefacts, et de vérifier le delta. Utilisez la même fraction pour les appels à l'outil. Le transport de demande d'enregistrement séparément de la réconciliation des effets. Si l'outil a expiré après l'envoi d'une écriture, consultez la destination avec la clé d'opération stable avant de réessayer. Si le protocole ne peut pas exposer une clé durable, créez en une à la limite de l'application. L'achèvement de la commande est une activité; un état de destination vérifié est une preuve. La fraîcheur appartient aux deux verdicts. Une capacité découverte hier pourrait disparaître aujourd'hui. Une tâche accomplie peut indiquer un artefact qui a ensuite été remplacé. Un reçu de paiement peut être valable tant que la livraison est retardée. Conservez la source, le temps d'observation, l'intervalle de rafraîchissement attendu et la confiance pour chaque signal décisif. Une règle de sélection compacte Utilisez cet ordre lors de l'examen de l'architecture: 1. Nommez la limite en une phrase. 2. La liste des états de défaillance doit être distinguée par l'opérateur. 3. Sélectionnez le protocole courant le plus étroit qui expose ces états. 4. Marquez tous les reçus requis comme originaux, partiels ou manquants. 5. Ajouter des preuves d'application uniquement pour les champs partiels et manquants. 6. Reconnexion de test, attente, annulation, livraison dupliquée, découverte obsolète et cas faux complets. 7. Éliminez l'œuvre seulement après que le résultat promis ait passé son propre contrat. Ne composez pas MCP et A2A simplement parce que les deux sont populaires. Les composer lorsqu'un agent A2A distant lui même a besoin d'outils MCP: A2A possède l'état de délégation et de tâche, tandis que MCP possède la limite de l'outil de cet agent. Gardez leur identité liée mais distincte. N'ajoutez pas UCP ou AP2 à moins que le flux de travail ne comporte effectivement des obligations de paiement ou de paiement. La matrice est une vérification au niveau des spécifications, et non une preuve qu'un SDK ou un serveur particulier interagit correctement. Les fonctionnalités facultatives, les extensions, l'authentification, l'autorisation, le comportement de reconnexion et la rétention de télémétrie nécessitent des tests de mise en œuvre. Les protocoles évoluent également; fixez la version de spécifications utilisée par chaque adaptateur et répétez l'audit avant la mise à niveau. Sidewisp est actuellement en préversion privée. Son objectif est de rendre la santé des agents, les preuves, les états d'attente et la vérification sûre plus clairs au cours des délais de fonctionnement existants; les adaptateurs de surveillance de la production et les systèmes de récupération ne sont généralement pas expédiés. Le principe utile aujourd'hui est indépendant de tout produit: choisir le protocole pour la limite, conserver les reçus qu'il peut fournir, et rendre impossible d'ignorer la preuve du résultat manquant.