Que se passerait-il si le protocole A2A de Google et le protocole MCP d'Anthropic devenaient la norme de communication en or pour le développement des agents AI web3 ? L'impression immédiate est celle d'un "malaise culturel". À mon avis, l'environnement auquel les agents AI web3 sont confrontés est nettement différent de l'écosystème web2, et les défis auxquels le protocole de communication central doit faire face sont également totalement différents :
Rupture de maturité des applications : A2A et MCP peuvent se répandre rapidement dans le domaine web2, car ils servent des scénarios d'application suffisamment matures, étant essentiellement des "amplificateurs de valeur" plutôt que des créateurs de valeur. En revanche, les agents AI web3 en sont souvent au stade initial de publication d'agent en un clic, manquant de scénarios d'application approfondis (DeFAI, GameFAi, etc.), ce qui rend ces protocoles difficiles à utiliser directement pour en tirer de la valeur.
Par exemple, lorsque les utilisateurs écrivent du code dans Cursor, ils peuvent utiliser le protocole MCP comme connecteur, ce qui leur permet de mettre à jour et de publier le 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 exécutent des transactions sur la chaîne avec des stratégies ajustées localement dans un environnement web3, ils pourraient se retrouver perdus en essayant d'analyser les données sur la chaîne.
Puits de connaissances manquants en infrastructure : 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, le protocole A2A dans un environnement web2 permet à l'Agent de facilement appeler 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ù l'utilisateur indique à l'Agent AI "acheter sur Uniswap lorsque le prix de l'ETH est inférieur à 1600 dollars et vendre lorsque le prix remonte". Bien que cela semble être une opération simple, l'Agent doit simultanément résoudre une série de problèmes spécifiques au web3 tels que l'analyse en temps réel des données sur la chaîne, l'optimisation dynamique des frais de Gas, le contrôle du slippage et la protection contre le MEV. En revanche, un Agent AI du web2 n'a qu'à appeler des API standardisées pour réaliser la coopération fonctionnelle, le niveau de maturité de ses infrastructures étant totalement différent par rapport à celui de l'environnement web3.
Construire des besoins différenciés pour l'IA web3 : Si l'agent IA web3 se contente d'appliquer simplement les protocoles et les modèles de fonctions du web2, il sera difficile de tirer parti des caractéristiques des transactions sur la chaîne, en particulier des 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, l’utilisateur demande 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 somme, ce que je veux exprimer, c'est que la valeur de A2A et de MC est indéniable, mais on ne peut pas s'attendre à ce qu'ils s'adaptent directement au secteur des agents AI web3 sans transformation. Ce vide dans le déploiement de l'infrastructure n'est-il pas l'opportunité des 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.
Les trois "zones de mort" de l'Agent AI Web3 avec le protocole A2A et MCP.
Que se passerait-il si le protocole A2A de Google et le protocole MCP d'Anthropic devenaient la norme de communication en or pour le développement des agents AI web3 ? L'impression immédiate est celle d'un "malaise culturel". À mon avis, l'environnement auquel les agents AI web3 sont confrontés est nettement différent de l'écosystème web2, et les défis auxquels le protocole de communication central doit faire face sont également totalement différents :
Par exemple, lorsque les utilisateurs écrivent du code dans Cursor, ils peuvent utiliser le protocole MCP comme connecteur, ce qui leur permet de mettre à jour et de publier le 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 exécutent des transactions sur la chaîne avec des stratégies ajustées localement dans un environnement web3, ils pourraient se retrouver perdus en essayant d'analyser les données sur la chaîne.
Imaginez un scénario où l'utilisateur indique à l'Agent AI "acheter sur Uniswap lorsque le prix de l'ETH est inférieur à 1600 dollars et vendre lorsque le prix remonte". Bien que cela semble être une opération simple, l'Agent doit simultanément résoudre une série de problèmes spécifiques au web3 tels que l'analyse en temps réel des données sur la chaîne, l'optimisation dynamique des frais de Gas, le contrôle du slippage et la protection contre le MEV. En revanche, un Agent AI du web2 n'a qu'à appeler des API standardisées pour réaliser la coopération fonctionnelle, le niveau de maturité de ses infrastructures étant totalement différent par rapport à celui de l'environnement web3.
Si l’on prend l’exemple des transactions d’intention, dans l’environnement web2, l’utilisateur demande 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 somme, ce que je veux exprimer, c'est que la valeur de A2A et de MC est indéniable, mais on ne peut pas s'attendre à ce qu'ils s'adaptent directement au secteur des agents AI web3 sans transformation. Ce vide dans le déploiement de l'infrastructure n'est-il pas l'opportunité des Builders ?