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