إذا أصبح بروتوكول A2A الذي أطلقته Google وبروتوكول MCP الخاص بـ Anthropic هو معيار الاتصال الذهبي لتطوير وكلاء الذكاء الاصطناعي في web3، ماذا سيحدث؟ الإحساس البديهي هو "عدم التكيف". في رأيي، البيئة التي يواجهها وكلاء الذكاء الاصطناعي في web3 تختلف بشكل واضح عن النظام البيئي في web2، والتحديات التي تواجه تنفيذ بروتوكول الاتصال الرئيسي مختلفة تمامًا:
فجوة نضج التطبيقات: يمكن أن تنتشر A2A وMCP بسرعة في مجال ويب 2 لأنهما يخدمان سيناريوهات التطبيقات التي نضجت بما فيه الكفاية، وبالأساس هما "مكبرات القيمة" وليس خلق القيمة. بينما لا يزال معظم وكلاء الذكاء الاصطناعي في ويب 3 في المرحلة الأولية من نشر الوكيل بنقرة واحدة، مما يفتقر إلى سيناريوهات تطبيق عميقة (DeFAI، GameFAi، إلخ)، مما يجعل من الصعب استخدام هذه البروتوكولات بشكل مباشر لتحقيق القيمة.
على سبيل المثال، يمكن للمستخدمين في Cursor كتابة الشفرة، ويمكنهم استخدام بروتوكول MCP كموصل، دون الحاجة للخروج من بيئة العمل الحالية، لتحديث الشفرة ونشرها على Github بنقرة واحدة، حيث يلعب بروتوكول MCP دورًا مهمًا. ولكن إذا كان المستخدم في بيئة web3، واستخدم استراتيجية معدلة محليًا لتنفيذ المعاملات على السلسلة، فقد يجد صعوبة في فهم وتحليل البيانات على السلسلة عندما يمد يده بعيدًا.
نقص البنية التحتية: لكي يتمكن وكيل الذكاء الاصطناعي في ويب 3 من بناء نظام بيئي كامل، يجب أولاً سد الفجوات الكبيرة في البنية التحتية الأساسية، بما في ذلك طبقة البيانات الموحدة، وطبقة أوركل، وطبقة تنفيذ النوايا، وطبقة الإجماع اللامركزية، وغيرها. غالبًا ما يمكن للبروتوكول بين الوكلاء في بيئة ويب 2 أن يستدعي بسهولة واجهات برمجة التطبيقات الموحدة لتحقيق التعاون الوظيفي، ولكن في بيئة ويب 3، يواجه إجراء بسيط مثل عملية التحكيم عبر DEX تحديات هائلة.
تخيل سيناريو حيث يوجه المستخدم وكيل الذكاء الاصطناعي "لشراء من Uniswap عندما يكون سعر ETH أقل من 1600 دولار وبيعه بعد ارتفاع السعر"، يبدو أن هذه العملية البسيطة تتطلب من الوكيل حل مجموعة من المشاكل الخاصة بـ web3 مثل تحليل البيانات على السلسلة في الوقت الفعلي، وتحسين رسوم الغاز الديناميكية، والتحكم في الانزلاق، والحماية من MEV. بينما يحتاج وكيل الذكاء الاصطناعي في web2 فقط لاستدعاء واجهات برمجة التطبيقات القياسية لتحقيق التعاون الوظيفي، فإن درجة اكتمال البنية التحتية له مقارنة ببيئة web3 تختلف تمامًا.
بناء متطلبات متميزة للويب 3 AI: إذا كان وكيل الويب 3 AI مجرد تطبيق بسيط لبروتوكولات ووظائف الويب 2، فسيكون من الصعب الاستفادة من خصائص نماذج المعاملات على السلسلة، خاصةً مع وجود مشاكل معقدة مثل ضوضاء البيانات، دقة المعاملات، وتنوع أجهزة التوجيه.
كمثال على التداول القائم على النية، في بيئة web2، يوجه المستخدم "احجز أرخص رحلة"، يمكن لبروتوكول A2A أن يتيح لعدة وكلاء التعاون بسهولة لإكمال ذلك؛ ولكن في بيئة web3، عندما يتوقع المستخدم "نقل USDC الخاص بي عبر السلاسل إلى سولانا بأقل تكلفة والمشاركة في تعدين السيولة"، ليس فقط أنه يحتاج إلى فهم نية المستخدم، ولكن أيضًا يجب موازنة الأمان والذرة والتكلفة، وتنفيذ سلسلة من العمليات المعقدة على السلسلة. بعبارة أخرى، إذا كانت العملية التي تبدو مريحة تجعل المستخدم يتحمل مخاطر أمان أكبر، فإن تجربة الراحة هذه تصبح بلا معنى، وبالتالي فإن الطلب يكون طلبًا زائفًا.
أعلاه.
باختصار، ما أريد أن أعبر عنه هو: إن قيمة A2A و MCP لا جدال فيها، ولكن لا يمكن توقع أن تتوافق مباشرة مع مسار وكيل الذكاء الاصطناعي web3 دون أي تعديل. ألا تمثل الفجوة في نشر البنية التحتية هذه فرصة للـ Builder؟
المحتوى هو للمرجعية فقط، وليس دعوة أو عرضًا. لا يتم تقديم أي مشورة استثمارية أو ضريبية أو قانونية. للمزيد من الإفصاحات حول المخاطر، يُرجى الاطلاع على إخلاء المسؤولية.
أهم "المناطق الميتة" الثلاثة لوصول A2A وبروتوكول MCP لوكيل الذكاء الاصطناعي Web3
إذا أصبح بروتوكول A2A الذي أطلقته Google وبروتوكول MCP الخاص بـ Anthropic هو معيار الاتصال الذهبي لتطوير وكلاء الذكاء الاصطناعي في web3، ماذا سيحدث؟ الإحساس البديهي هو "عدم التكيف". في رأيي، البيئة التي يواجهها وكلاء الذكاء الاصطناعي في web3 تختلف بشكل واضح عن النظام البيئي في web2، والتحديات التي تواجه تنفيذ بروتوكول الاتصال الرئيسي مختلفة تمامًا:
على سبيل المثال، يمكن للمستخدمين في Cursor كتابة الشفرة، ويمكنهم استخدام بروتوكول MCP كموصل، دون الحاجة للخروج من بيئة العمل الحالية، لتحديث الشفرة ونشرها على Github بنقرة واحدة، حيث يلعب بروتوكول MCP دورًا مهمًا. ولكن إذا كان المستخدم في بيئة web3، واستخدم استراتيجية معدلة محليًا لتنفيذ المعاملات على السلسلة، فقد يجد صعوبة في فهم وتحليل البيانات على السلسلة عندما يمد يده بعيدًا.
تخيل سيناريو حيث يوجه المستخدم وكيل الذكاء الاصطناعي "لشراء من Uniswap عندما يكون سعر ETH أقل من 1600 دولار وبيعه بعد ارتفاع السعر"، يبدو أن هذه العملية البسيطة تتطلب من الوكيل حل مجموعة من المشاكل الخاصة بـ web3 مثل تحليل البيانات على السلسلة في الوقت الفعلي، وتحسين رسوم الغاز الديناميكية، والتحكم في الانزلاق، والحماية من MEV. بينما يحتاج وكيل الذكاء الاصطناعي في web2 فقط لاستدعاء واجهات برمجة التطبيقات القياسية لتحقيق التعاون الوظيفي، فإن درجة اكتمال البنية التحتية له مقارنة ببيئة web3 تختلف تمامًا.
كمثال على التداول القائم على النية، في بيئة web2، يوجه المستخدم "احجز أرخص رحلة"، يمكن لبروتوكول A2A أن يتيح لعدة وكلاء التعاون بسهولة لإكمال ذلك؛ ولكن في بيئة web3، عندما يتوقع المستخدم "نقل USDC الخاص بي عبر السلاسل إلى سولانا بأقل تكلفة والمشاركة في تعدين السيولة"، ليس فقط أنه يحتاج إلى فهم نية المستخدم، ولكن أيضًا يجب موازنة الأمان والذرة والتكلفة، وتنفيذ سلسلة من العمليات المعقدة على السلسلة. بعبارة أخرى، إذا كانت العملية التي تبدو مريحة تجعل المستخدم يتحمل مخاطر أمان أكبر، فإن تجربة الراحة هذه تصبح بلا معنى، وبالتالي فإن الطلب يكون طلبًا زائفًا.
أعلاه.
باختصار، ما أريد أن أعبر عنه هو: إن قيمة A2A و MCP لا جدال فيها، ولكن لا يمكن توقع أن تتوافق مباشرة مع مسار وكيل الذكاء الاصطناعي web3 دون أي تعديل. ألا تمثل الفجوة في نشر البنية التحتية هذه فرصة للـ Builder؟