هل يمكن أن يصبح A2A وMCP المعيار الذهبي لوكلاء Web3 AI؟

المؤلف: هاوتيان 

ماذا سيحدث إذا أصبح بروتوكول A2A من Google وبروتوكول MCP من Anthropic المعيار الذهبي للاتصالات لتطوير وكلاء الذكاء الاصطناعي على الويب 3؟ الشعور البديهي "غير متأقلم". في رأيي، تختلف البيئة التي يواجهها وكيل الذكاء الاصطناعي web3 بشكل كبير عن النظام البيئي web2، والتحديات التي يواجهها تنفيذ بروتوكولات الاتصال الأساسية مختلفة تمامًا أيضًا:

1) فجوة نضج التطبيق: يمكن نشر A2A وMCP بسرعة في مجال web2 لأنهما يخدمان سيناريوهات تطبيق ناضجة بدرجة كافية. إنهم في الأساس "مضخمون للقيمة" وليسوا منشئي القيمة. ومع ذلك، لا تزال معظم وكلاء الذكاء الاصطناعي web3 في المرحلة الأساسية من إصدار الوكيل بنقرة واحدة وتفتقر إلى سيناريوهات التطبيق المتعمقة (DeFAI، GameFAi، وما إلى ذلك)، مما يجعل من الصعب استخدام هذه البروتوكولات بشكل مباشر في سلسلة لتحقيق قيمتها.

على سبيل المثال، عندما يقوم المستخدمون بتجميع الكود في Cursor، يمكنهم استخدام بروتوكول MCP كموصل ونشر تحديثات الكود على Github بنقرة واحدة دون مغادرة بيئة العمل الحالية. يضيف بروتوكول MCP لمسة من الفخامة إلى الكعكة. ومع ذلك، إذا استخدم المستخدمون استراتيجية التغذية والضبط الدقيق المحلية لتنفيذ المعاملات على السلسلة في بيئة web3، فقد يصابون بالارتباك عند محاولة تحليل البيانات الموجودة على السلسلة. 2) عيوب نقص البنية الأساسية: إذا أراد وكيل الذكاء الاصطناعي web3 بناء نظام بيئي كامل، فيجب عليه أولاً ملء البنية الأساسية الأساسية المفقودة بشدة، بما في ذلك طبقة البيانات الموحدة، وطبقة Oracle، وطبقة تنفيذ النية، وطبقة الإجماع اللامركزية، وما إلى ذلك. في بيئة web2، غالبًا ما يسمح بروتوكول A2A للوكلاء باستدعاء واجهات برمجة التطبيقات القياسية بسهولة لتحقيق التعاون الوظيفي، ولكن في بيئة web3، تواجه عملية التحكيم البسيطة عبر DEX تحديات ضخمة.

تخيل سيناريو حيث يطلب المستخدم من وكيل الذكاء الاصطناعي "الشراء من Uniswap عندما يكون سعر ETH أقل من 1600 دولار وبيعه بعد تعافي السعر". تتطلب هذه العملية البسيطة ظاهريًا من العميل حل سلسلة من المشكلات الخاصة بـ web3 مثل التحليل الفوري للبيانات على السلسلة، والتحسين الديناميكي لرسوم الغاز، والتحكم في الانزلاق، وحماية MEV، وما إلى ذلك. يحتاج وكيل الذكاء الاصطناعي web2 فقط إلى استدعاء واجهات برمجة التطبيقات القياسية لتحقيق التعاون الوظيفي، ومستوى الكمال في بنيته التحتية يختلف تمامًا عن بيئة web3. 3) بناء احتياجات متباينة لـ web3 AI: إذا قام وكيل web3 AI ببساطة بتطبيق البروتوكولات والأوضاع الوظيفية لـ web2، فسيكون من الصعب إعطاء اللعب الكامل لخصائص تنسيقات المعاملات على السلسلة، وخاصة القضايا المعقدة مثل ضوضاء البيانات ودقة المعاملات وتنوع جهاز التوجيه.

خذ معاملات النية كمثال. في بيئة web2، عندما يطلب المستخدم "حجز أرخص رحلة"، يسمح بروتوكول A2A لعدة وكلاء بالتعاون بسهولة لإكمال المهمة. ومع ذلك، في بيئة web3، عندما يتوقع المستخدم "ربط USDC الخاص بي بـ Solana بأقل تكلفة والمشاركة في تعدين السيولة"، فمن الضروري ليس فقط فهم نوايا المستخدم، ولكن أيضًا تقييم الأمان والذرية والتكلفة والتآكل، وإجراء سلسلة من العمليات المعقدة على السلسلة. بعبارة أخرى، إذا كانت عملية تبدو مريحة تعرض المستخدمين لمخاطر أمنية أكبر، فإن هذه التجربة المريحة لا معنى لها والطلب عليها هو طلب زائف.

أعلاه. باختصار، ما أريد التعبير عنه هو: إن قيمة A2A وMCP لا شك فيها، ولكن لا يمكننا أن نتوقع أن يتم تكييفها بشكل مباشر مع مسار web3 AI Agent دون أي تعديل. أليس هذا الفراغ في نشر البنية التحتية فرصة للمطورين؟