Que se passerait-il si le protocole A2A de Google et le MCP d'Anthropic devenaient la norme de communication en or pour le développement des agents IA web3 ? L'impression immédiate est celle d'un « décalage culturel ». À mon avis, l'environnement auquel les agents IA web3 font face est clairement différent de l'écosystème web2, et les défis auxquels le protocole de communication central doit faire face sont également radicalement différents :
Faille de maturité des applications : A2A et MCP se sont rapidement répandus dans le domaine du web2, car ils servent des cas d'utilisation suffisamment matures, étant essentiellement des « amplificateurs de valeur » plutôt que des créateurs de valeur. En revanche, les agents AI du web3 sont majoritairement à un stade précoce de publication d'agent en un clic, manquant de cas d'application approfondis (DeFAI, GameFAi, etc.), ce qui rend difficile l'utilisation directe de ces protocoles pour en tirer de la valeur.
Par exemple, lorsque les utilisateurs écrivent du code dans Cursor, ils peuvent utiliser le protocole MCP comme connecteur, leur permettant de publier des mises à jour de code sur Github d'un simple clic sans quitter leur environnement de travail actuel, le protocole MCP apporte une valeur ajoutée. Cependant, si les utilisateurs, dans un environnement web3, exécutent des transactions sur la chaîne avec des stratégies ajustées localement, ils pourraient se retrouver perdus en essayant d'analyser les données de la chaîne.
Puits sans fond d'infrastructure manquante : Pour qu'un agent AI Web3 puisse construire un écosystème complet, il est impératif de combler les infrastructures de base gravement manquantes, y compris la couche de données unifiée, la couche Oracle, la couche d'exécution des intentions, la couche de consensus décentralisé, etc. Souvent, dans un environnement Web2, un protocole A2A permet à l'agent d'appeler facilement des API standardisées pour réaliser une collaboration fonctionnelle, mais dans un environnement Web3, une simple opération d'arbitrage inter-DEX fait face à d'énormes défis.
Imaginez un scénario où un utilisateur demande à un agent d’IA « d’acheter auprès d’Uniswap lorsque le prix de l’ETH est inférieur à 1 600 $ et de le vendre une fois que le prix s’est redressé », le fonctionnement apparemment simple de l’agent doit résoudre une série de problèmes spécifiques au web3 en même temps, tels que l’analyse en temps réel des données on-chain, l’optimisation dynamique des frais de gaz, le contrôle du glissement et la protection MEV. Les agents d’IA Web2, quant à eux, n’ont besoin que d’appeler des API standardisées pour obtenir une collaboration fonctionnelle, et leur infrastructure est très différente de celle des environnements Web3.
Construire des besoins différenciés en web3 AI : si l'agent web3 AI ne se contente que d'appliquer simplement les protocoles et les modèles de fonctionnalités du web2, il sera difficile de tirer parti des caractéristiques du modèle commercial basé sur la chaîne, notamment les problèmes complexes tels que le bruit des données, l'exactitude des transactions et la diversité des routeurs.
Si l’on prend l’exemple des transactions d’intention, dans l’environnement web2, les utilisateurs demandent de « réserver le vol le moins cher », et le protocole A2A permet à plusieurs agents de collaborer facilement. Mais dans l’environnement web3, lorsque les utilisateurs s’attendent à « cross-chain mon USDC vers Solana et à participer à l’extraction de liquidités au coût le plus bas », ils doivent non seulement comprendre l’intention de l’utilisateur, mais aussi peser la sécurité, l’atomicité et l’usure des coûts, et effectuer une série d’opérations complexes sur la chaîne. En d’autres termes, si une opération apparemment pratique expose l’utilisateur à des risques de sécurité plus importants, alors une telle expérience pratique n’a aucun sens, et la demande est également une pseudo-demande.
C'est tout.
En résumé, ce que je veux exprimer, c'est que la valeur de A2A et MCP est indéniable, mais on ne peut pas s'attendre à ce qu'ils s'adaptent directement au domaine des agents AI web3 sans aucune transformation. Le vide de déploiement infra qui en résulte n'est-il pas une opportunité pour les Builders ?
Le contenu est fourni à titre de référence uniquement, il ne s'agit pas d'une sollicitation ou d'une offre. Aucun conseil en investissement, fiscalité ou juridique n'est fourni. Consultez l'Avertissement pour plus de détails sur les risques.
A2A et MCP peuvent-ils devenir la norme d'or pour les agents AI Web3 ?
Auteur : Haotian
Que se passerait-il si le protocole A2A de Google et le MCP d'Anthropic devenaient la norme de communication en or pour le développement des agents IA web3 ? L'impression immédiate est celle d'un « décalage culturel ». À mon avis, l'environnement auquel les agents IA web3 font face est clairement différent de l'écosystème web2, et les défis auxquels le protocole de communication central doit faire face sont également radicalement différents :
Par exemple, lorsque les utilisateurs écrivent du code dans Cursor, ils peuvent utiliser le protocole MCP comme connecteur, leur permettant de publier des mises à jour de code sur Github d'un simple clic sans quitter leur environnement de travail actuel, le protocole MCP apporte une valeur ajoutée. Cependant, si les utilisateurs, dans un environnement web3, exécutent des transactions sur la chaîne avec des stratégies ajustées localement, ils pourraient se retrouver perdus en essayant d'analyser les données de la chaîne.
Imaginez un scénario où un utilisateur demande à un agent d’IA « d’acheter auprès d’Uniswap lorsque le prix de l’ETH est inférieur à 1 600 $ et de le vendre une fois que le prix s’est redressé », le fonctionnement apparemment simple de l’agent doit résoudre une série de problèmes spécifiques au web3 en même temps, tels que l’analyse en temps réel des données on-chain, l’optimisation dynamique des frais de gaz, le contrôle du glissement et la protection MEV. Les agents d’IA Web2, quant à eux, n’ont besoin que d’appeler des API standardisées pour obtenir une collaboration fonctionnelle, et leur infrastructure est très différente de celle des environnements Web3.
Si l’on prend l’exemple des transactions d’intention, dans l’environnement web2, les utilisateurs demandent de « réserver le vol le moins cher », et le protocole A2A permet à plusieurs agents de collaborer facilement. Mais dans l’environnement web3, lorsque les utilisateurs s’attendent à « cross-chain mon USDC vers Solana et à participer à l’extraction de liquidités au coût le plus bas », ils doivent non seulement comprendre l’intention de l’utilisateur, mais aussi peser la sécurité, l’atomicité et l’usure des coûts, et effectuer une série d’opérations complexes sur la chaîne. En d’autres termes, si une opération apparemment pratique expose l’utilisateur à des risques de sécurité plus importants, alors une telle expérience pratique n’a aucun sens, et la demande est également une pseudo-demande.
C'est tout.
En résumé, ce que je veux exprimer, c'est que la valeur de A2A et MCP est indéniable, mais on ne peut pas s'attendre à ce qu'ils s'adaptent directement au domaine des agents AI web3 sans aucune transformation. Le vide de déploiement infra qui en résulte n'est-il pas une opportunité pour les Builders ?