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