Un ami a dit que la chute continue des titres des agents AI web3 comme #ai16z, $arc est causée par le protocole MCP qui a récemment explosé en popularité ? À première vue, ça semble un peu confus, quel rapport y a-t-il ? Mais en y réfléchissant, il y a une certaine logique : la logique de valorisation des agents AI web3 existants a changé, la direction du récit et la feuille de route des produits doivent être ajustées. Voici mon point de vue personnel :

1) MCP (Model Context Protocol) est un protocole standardisé open source visant à permettre à divers AI LLM/Agent de se connecter sans couture à diverses sources de données et outils, équivalant à un port USB 'universel' plug-and-play, remplaçant les méthodes d'emballage 'spécifiques' de bout en bout du passé.

En termes simples, les applications AI avaient des îlots de données évidents, et pour que les Agents/LLM communiquent entre eux, ils devaient chacun développer des interfaces API d'appel correspondantes, rendant le processus opérationnel complexe, sans parler du manque de fonctionnalité d'interaction bidirectionnelle, généralement avec un accès modèle et des restrictions d'autorisation relativement limitées.

L'apparition de MCP équivaut à offrir un cadre unifié, permettant aux applications AI de se libérer de l'état d'îlot de données du passé, réalisant la possibilité d'accès 'dynamique' aux données et outils externes, ce qui peut considérablement réduire la complexité de développement et augmenter l'efficacité d'intégration, notamment dans l'exécution automatisée des tâches, les requêtes de données en temps réel et la collaboration inter-plateformes. À ce sujet, beaucoup de gens pensent immédiatement que si on utilise le Manus innovant avec une coopération multi-agent intégrant ce cadre open source MCP qui favorise la coopération multi-agent, cela ne serait-il pas imbattable ?

Exactement, Manus + MCP sont la clé de l'impact subi par les agents AI web3.

2) Cependant, ce qui est incroyable, c'est que tant Manus que MCP sont des cadres et des normes de protocole destinés aux LLM/Agents web2, résolvant des problèmes d'interaction et de collaboration des données entre serveurs centralisés, leur contrôle d'accès et leurs permissions dépendent encore de l'ouverture 'active' de chaque nœud serveur. En d'autres termes, ce n'est qu'un outil open source.

En théorie, cela va à l'encontre de l'idée centrale que les agents AI web3 poursuivent, tels que 'serveurs distribués, collaboration distribuée, incitation distribuée', etc. Comment une arme centralisée, comme un canon italien, pourrait-elle détruire un bastion décentralisé ?

La raison en est que, durant la première phase, les agents AI web3 étaient trop 'web2', d'une part en raison du fait que de nombreuses équipes proviennent de l'environnement web2 et manquent d'une compréhension suffisante des besoins natifs web3. Par exemple, le cadre ElizaOS était à l'origine un cadre d'emballage aidant les développeurs à déployer rapidement des applications d'agents AI, intégrant en fait des plateformes telles que Twitter, Discord, ainsi que certaines interfaces API d'OpenAI, Claude, DeepSeek, et encapsulant certains cadres généraux de mémoire et de caractère pour aider les développeurs à développer rapidement des applications d'agents AI. Mais en réalité, quelle différence y a-t-il entre ce cadre de service et les outils open source de web2 ? Quels avantages différenciés a-t-il ?

Euh, est-ce que l'avantage réside dans un système de Tokenomics incitatif ? Et ensuite, utiliser un cadre web2 qui peut être complètement remplacé, pour inciter un groupe d'AI Agent qui existent principalement pour émettre de nouvelles pièces ? C'est effrayant... En suivant cette logique, vous comprendrez pourquoi Manus + MCP peuvent avoir un impact sur les agents AI web3. Les nombreux cadres et services des agents AI web3 n'ont résolu que les besoins de développement et d'application rapides similaires aux agents AI web2, mais ils ne parviennent pas à suivre la vitesse d'innovation de web2 en termes de services techniques, de normes et d'avantages différenciés. Par conséquent, le marché/le capital ont réévalué et redéfini la valeur des derniers agents AI web3.

3) En disant cela, je pense que vous avez probablement trouvé le problème, mais comment le résoudre ? Il n'y a qu'une seule voie : se concentrer sur la création de solutions natives web3, car le fonctionnement des systèmes distribués et l'architecture incitative sont les véritables avantages différenciés de web3.

Prenons comme exemple une plateforme de services de calcul cloud distribué, de données, d'algorithmes, etc. À première vue, il semble que ce type de calcul et de données agrégés à partir de ressources inutilisées ne puisse pas satisfaire à court terme les besoins d'innovation d'ingénierie, mais alors que de nombreux LLM AI sont en pleine course à l'armement pour des percées de performance en centralisant la puissance de calcul, un modèle de service basé sur des 'ressources inutilisées à bas coût' sera naturellement méprisé par les développeurs et les équipes de VC de web2.

Mais une fois que les agents AI web2 ont passé la phase d'innovation de performance, ils chercheront inévitablement à étendre les scénarios d'application verticaux et à optimiser les modèles par des ajustements fins. Ce n'est qu'à ce moment-là que les avantages des services de ressources AI web3 commenceront vraiment à apparaître. En effet, lorsque les AI web2, qui ont atteint une position de monopole des ressources, ne peuvent plus revenir à une pensée où la campagne de circonscription de la ville par le village se fait scène par scène, c'est alors que les développeurs AI web2 excédentaires et les ressources AI web3 s'uniront pour faire avancer les choses.

Ainsi, l'espace d'opportunité pour les agents AI web3 est désormais clair : avant d'avoir des clients de développeurs web2 débordants sur la plateforme de ressources AI web3, explorer et mettre en œuvre une solution et un chemin réalisables qui ne peuvent pas être décentralisés en web3. En effet, les agents AI web3, en dehors de la mise en œuvre rapide de la configuration + du cadre de communication de coopération multi-agent de web2 + de la narration d'émission de Tokenomic, ont de nombreuses directions d'innovation natives web3 qui valent la peine d'être explorées.

Par exemple, équipé d'un cadre de collaboration de consensus distribué, en tenant compte des caractéristiques du calcul hors chaîne des grands modèles LLM + stockage d'état sur chaîne, il nécessite de nombreux composants d'adaptation.

1) Un système de vérification d'identité DID décentralisé, permettant aux agents d'avoir une identité vérifiable sur chaîne, semblable à l'adresse unique générée par une machine virtuelle pour les contrats intelligents, principalement pour le suivi et l'enregistrement continus des états ultérieurs.

2) Un système Oracle décentralisé, principalement responsable de l'acquisition et de la validation de données hors chaîne de manière fiable. Contrairement aux Oracle précédents, ce système Oracle adapté aux agents AI pourrait également nécessiter une combinaison de plusieurs agents à travers des niveaux de collecte de données, de consensus décisionnel et de retour d'exécution, afin que les données nécessaires aux agents soient accessibles en temps réel tant sur la chaîne qu'en dehors.

3) Un système de stockage DA décentralisé, en raison de l'incertitude de l'état de la base de connaissances pendant l'exécution des agents AI, et le processus de raisonnement étant également temporaire, il faut un système qui enregistre et stocke les bibliothèques d'état clés et les chemins de raisonnement derrière les LLM dans un système de stockage distribué, tout en fournissant un mécanisme de preuve de données à coût contrôlable pour garantir la disponibilité des données lors de la validation sur la chaîne publique.

4) Un niveau de calcul de confidentialité ZKP à connaissance zéro, pouvant interagir avec des solutions de calcul de confidentialité telles que TEE et FHE, permettant un calcul de confidentialité en temps réel + validation de preuve de données, afin que les agents puissent disposer d'une source de données verticales plus large (santé, finance), entraînant l'émergence de plus de services agents spécialisés et personnalisés.

5) Un protocole d'interopérabilité inter-chaînes, similaire au cadre défini par le protocole open source MCP, la différence étant que cette solution d'interopérabilité nécessite un mécanisme de relais et de planification de communication adapté au fonctionnement, à la transmission et à la validation des agents, afin de résoudre les problèmes de transfert d'actifs et de synchronisation d'état des agents entre différentes chaînes, en particulier ceux incluant le contexte des agents, les prompts, les bases de connaissances, la mémoire et d'autres états complexes.

……

À mon avis, le véritable point de rupture des agents AI web3 devrait être de savoir comment faire coïncider le 'flux de travail complexe' des agents AI avec le 'flux de validation de confiance' de la blockchain autant que possible. Quant à ces solutions incrémentales, qu'elles soient issues d'une mise à jour des anciens projets narratifs ou de nouveaux projets sur la piste narrative des agents AI, il y a des possibilités.

C'est dans cette direction que les agents AI web3 devraient s'efforcer de construire, car cela correspond aux fondamentaux de l'écosystème d'innovation sous le grand récit macro AI + Crypto. Si aucune innovation pertinente et aucune barrière de concurrence différenciée ne sont établies, alors chaque mouvement du marché des agents AI web2 pourrait bouleverser le paysage des agents AI web3.