TL;DR
Voici mes réflexions personnelles :
1) MCP (Model Context Protocol) est un protocole open-source et standardisé conçu pour permettre des connexions transparentes entre divers modèles de langage LLM (Large Language Models) et des agents avec des sources de données et des outils variés. Pensez-y comme une interface USB "universelle" plug-and-play, remplaçant les anciennes méthodes d'emballage "spécifiques" rigides de bout en bout.
En termes simples, il y a eu des silos de données clairs entre les applications d'IA. Pour l'interopérabilité entre les agents/LLMs, chacun devait développer ses propres interfaces API. Cela rendait le processus complexe et manquait de capacités d'interaction bidirectionnelle. De plus, ces modèles avaient souvent un accès et des autorisations limités.
L'arrivée de MCP fournit un cadre unifié, permettant aux applications d'IA de se libérer des silos de données passés et d'accéder dynamiquement aux données et outils externes. Cela réduit considérablement la complexité du développement et améliore l'efficacité de l'intégration, notamment en automatisant les tâches, en interrogeant les données en temps réel et en permettant la collaboration interplateforme. Dès que j'ai mentionné cela, beaucoup ont immédiatement pensé : si Manus, une innovation dans la collaboration multi-agent, intègre MCP, un cadre conçu pour renforcer une telle collaboration, ne serait-il pas imbattable ?
En effet, Manus + MCP est le facteur clé derrière la perturbation actuelle dans l'espace des agents AI Web3.
2) Cependant, ce qui est vraiment déconcertant, c'est que Manus et MCP sont tous deux des cadres et des normes de protocole conçus pour le web2 LLM/Agent, résolvant les problèmes liés à l'interaction des données et à la collaboration entre les serveurs centralisés. Leurs autorisations et leur contrôle d'accès dépendent toujours de l'ouverture "active" de chaque nœud de serveur. En d'autres termes, ils fonctionnent davantage comme des attributs d'outils open-source plutôt que d'embrasser pleinement les principes décentralisés.
En droit, cela va à l'encontre des valeurs fondamentales de l'agent d'IA web3, telles que les « serveurs distribués, la collaboration distribuée et les incitations distribuées ». Comment un canon italien centralisé pourrait-il abattre une forteresse décentralisée ?
Le problème vient du fait que, dans ses premières étapes, web3 AI Agent a été trop "web2-centric". Beaucoup des équipes impliquées viennent d'un environnement web2 et manquent d'une compréhension approfondie des besoins natifs de web3. Prenez par exemple le framework ElizaOS, initialement créé pour aider les développeurs à déployer rapidement des applications AI Agent. Il a intégré des plateformes comme Twitter et Discord, ainsi que des API comme OpenAI, Claude, et DeepSeek, fournissant des frameworks pour la mémoire et le développement de personnage pour accélérer le déploiement de l'AI Agent. Mais en y regardant de plus près, en quoi ce framework de service diffère-t-il des outils open-source web2? Quels avantages uniques offre-t-il?
L'avantage supposé réside dans son système d'incitation à la tokenomie. Mais essentiellement, c'est un cadre qui pourrait facilement être remplacé par web2, pilotant des agents d'IA qui se concentrent principalement sur l'émission de nouvelles pièces. C'est inquiétant. Si vous suivez cette logique, vous comprendrez pourquoi Manus + MCP peuvent perturber les agents d'IA web3 : de nombreux cadres existants d'agents d'IA web3 se contentent de reproduire les besoins de développement et d'application rapides des agents d'IA web2 sans progresser dans les services techniques, les normes ou la différenciation. En conséquence, le marché et le capital ont réévalué et recalibré les premiers agents d'IA web3.
3) Maintenant, ayant identifié l'essence du problème, que peut-on faire pour le résoudre? La réponse est simple: se concentrer sur la création de solutions réellement natives de web3. L'avantage unique de web3 réside dans ses systèmes distribués et ses structures d'incitation.
Considérez les plates-formes de services de cloud computing, de données et d'algorithmes distribués. Bien qu'à première vue, il puisse sembler que l'agrégation de ressources inutilisées pour fournir de la puissance de calcul et des données ne satisfasse pas immédiatement les besoins en innovation en ingénierie, la réalité est que, alors que de nombreux LLM IA se lancent dans une course à la performance, l'idée d'offrir des “ressources inutilisées à faible coût” devient un modèle de service attrayant. Initialement, les développeurs et les VC web2 pourraient rejeter cela, mais à mesure que l'innovation des agents IA web2 dépasse la performance et entre dans l'expansion des applications verticales, le peaufinage et l'optimisation des modèles, les avantages des ressources IA web3 deviendront clairs.
En fait, une fois que l'IA web2 a atteint le sommet grâce aux monopoles des ressources, il sera de plus en plus difficile de renverser la tendance et d'utiliser une stratégie de "campagne-entoure-ville" pour aborder des applications segmentées et de niche. C'est à ce moment-là qu'une abondance de développeurs d'IA web2, combinée aux ressources d'IA web3, fera vraiment avancer les choses.
Ainsi, l'opportunité pour les Agents d'IA web3 est claire : avant que la plateforme de ressources d'IA web3 ne soit inondée de développeurs web2 cherchant des solutions, nous devons nous concentrer sur le développement d'un ensemble de solutions réalisables, natives de web3. Au-delà du simple déploiement rapide de style web2, de la collaboration multi-agent et des modèles de monnaie basés sur la tokenomie, il existe de nombreuses directions innovantes propres à web3 pour les Agents d'IA web3 qui méritent d'être explorées :
Par exemple, un cadre de collaboration de consensus distribué serait nécessaire, en considérant les caractéristiques du calcul hors chaîne de modèle LLM large et du stockage d'état sur chaîne. Cela nécessite de nombreux composants adaptables :
Un système de vérification d'identité DID décentralisé : Cela permettrait aux agents d'avoir des identités vérifiables sur la chaîne, de manière similaire à la génération d'une adresse unique pour un contrat intelligent par une machine virtuelle en cours d'exécution. Ce système est principalement utilisé pour le suivi continu et l'enregistrement des statuts ultérieurs ;
Un système Oracle décentralisé : Ce système est responsable de l'acquisition et de la vérification fiable des données hors chaîne. Contrairement aux Oracles traditionnels, ce système adapté aux Agents IA pourrait nécessiter une architecture combinée, comprenant des couches de collecte de données, des couches de consensus décisionnel et des couches de retour d'exécution. Cela garantit que les données nécessaires à l'agent sur chaîne, ainsi que les calculs et décisions hors chaîne, peuvent être consultés en temps réel.
Un système de stockage DA décentralisé : Comme l'état de la base de connaissances pendant le fonctionnement d'un agent IA est incertain et que les processus de raisonnement sont temporaires, il est nécessaire d'enregistrer la bibliothèque d'états clés et les chemins de raisonnement derrière le LLM. Ces éléments doivent être stockés dans un système de stockage distribué avec un mécanisme de preuve de données contrôlé par coût pour garantir la disponibilité des données lors de la vérification de la chaîne publique ;
Une couche de calcul de confidentialité de preuve de connaissance nulle (ZKP) : Cela peut s'intégrer à des solutions de calcul de confidentialité comme TEE (Trusted Execution Environment) et FHE (Fully Homomorphic Encryption), permettant le calcul de confidentialité en temps réel et la vérification de la preuve des données. Cela permet aux agents d'accéder à un plus large éventail de sources de données verticales (par exemple, médicales, financières), conduisant à l'émergence d'agents de service plus spécialisés et personnalisés.
Un protocole d'interopérabilité inter-chaînes : Cela ressemblerait au cadre défini par le protocole open-source MCP. Cependant, cette solution d'interopérabilité nécessite des mécanismes de relais et de planification de la communication qui s'adaptent aux opérations de l'Agent, à la transmission et à la vérification. Il garantit les transferts d'actifs et la synchronisation des statuts entre différentes chaînes, en particulier pour des états complexes tels que le contexte de l'Agent, les invites, la base de connaissances, la mémoire, etc.
……
À mon avis, le défi principal pour les agents d'IA Web3 est d'aligner les 'flux de travail complexes' des agents d'IA avec le 'flux de vérification de confiance' de la blockchain aussi étroitement que possible. Ces solutions incrémentielles pourraient émerger de la mise à niveau de projets existants ou être réimaginées au sein de nouveaux projets dans la piste narrative des agents d'IA.
Il convient que les agents d'IA Web3 visent à se développer, en s'alignant sur l'écosystème innovant fondamental dans le cadre du récit macroéconomique de l'IA + Crypto. S'il n'y a pas d'innovation ou d'établissement de barrières concurrentielles différenciées, chaque changement dans la voie de l'IA Web2 pourrait perturber le paysage de l'IA Web3.
Avertissement :
- Cet article est reproduit à partir de [GateLa souscription de Haotian-CryptoInsight sur Substack], le droit d'auteur appartient à l'auteur original [@haotiancryptoinsight]. Si vous avez des objections à la réimpression, veuillez contacter Gate Learnl'équipe, l'équipe le traitera dès que possible selon les procédures pertinentes.
- Avertissement : Les points de vue et opinions exprimés dans cet article ne représentent que les opinions personnelles de l'auteur et ne constituent aucun conseil en investissement.
- Les autres versions linguistiques de l'article sont traduites par l'équipe Gate Learn et ne sont pas mentionnées dans Gate.com, l'article traduit ne peut être reproduit, distribué ou plagié.
