تأمل في انخفاض وكلاء الذكاء الاصطناعي في الويب3: هل من Manus + MCP القشة الأخيرة؟

TL;DR

أدناه تفكيراتي الشخصية:

1) MCP (Model Context Protocol) هو بروتوكول مفتوح المصدر وموحد مصمم لتمكين الاتصالات السلسة بين مختلف نماذج اللغة الكبيرة (LLMs) والعملاء مع مصادر بيانات وأدوات متنوعة. اعتبره واجهة USB "عالمية" قابلة للتوصيل والتشغيل، تحل محل الأساليب القديمة والصارمة "محددة" نهاية إلى نهاية للتعبئة والتغليف.

ببساطة، كانت هناك بيانات معزولة واضحة بين تطبيقات الذكاء الاصطناعي. للتشغيل المشترك بين الوكلاء/LLMs، كان كل واحد منهم بحاجة لتطوير واجهات برمجة تطبيقات خاصة به. هذا جعل العملية معقدة وناقصة لقدرات التفاعل ذو الاتجاهين. علاوة على ذلك، كانت لهذه النماذج في كثير من الأحيان وصول وأذونات محدودة.

وصول MCP يوفر إطار موحد، مما يتيح لتطبيقات الذكاء الاصطناعي أن تتحرر من البيانات المعزولة في الماضي والوصول بشكل ديناميكي إلى البيانات والأدوات الخارجية. وهذا يقلل بشكل كبير من تعقيد التطوير ويحسن كفاءة التكامل، خاصة في أتمتة المهام، واستعلام البيانات في الوقت الحقيقي، وتمكين التعاون عبر الأنظمة الأساسية. فور ذكري لهذا، فكر العديد على الفور: إذا كان Manus، الابتكار في التعاون بين العملاء المتعددين، يدمج MCP - إطار مصمم لتعزيز مثل هذا التعاون - فلن يكون له مثيل؟

بالفعل، Manus + MCP هو العامل الرئيسي وراء الاضطراب الحالي في مجال وكلاء الذكاء الاصطناعي في Web3.

2) ومع ذلك ، فإن الأمر المحير حقا هو أن كلا من Manus و MCP عبارة عن أطر عمل ومعايير بروتوكول مصممة ل web2 LLM / Agent ، مما يحل المشكلات المتعلقة بتفاعل البيانات والتعاون بين الخوادم المركزية. لا تزال أذوناتهم والتحكم في الوصول يعتمدون على الفتح "النشط" لكل عقدة خادم. بمعنى آخر ، تعمل بشكل أكبر كسمات أداة مفتوحة المصدر بدلا من تبني المبادئ اللامركزية بالكامل.

بحق، يتعارض هذا مع القيم الأساسية لوكيل الذكاء الاصطناعي الويب3، مثل "الخوادم الموزعة، والتعاون الموزع، والحوافز المووزعة." كيف يمكن لمدفع إيطالي مركزي إسقاط قلعة لامركزية؟

المشكلة تنبع من حقيقة أنه، في مراحله الأولى، كان وكيل الذكاء الاصطناعي web3 موجهًا جدًا نحو web2. العديد من الفرق المعنية تأتي من خلفية web2 وتفتقر إلى فهم عميق للاحتياجات الأصلية لـ web3. خذ إطار ElizaOS على سبيل المثال - الذي تم إنشاؤه أصلا لمساعدة المطورين على نشر تطبيقات وكلاء الذكاء الاصطناعي بسرعة. لقد دمجت منصات مثل Twitter و Discord، وكذلك واجهات برمجة التطبيقات مثل OpenAI و Claude و DeepSeek، وذلك لتوفير إطارات للذاكرة وتطوير الشخصيات لمساعدة في تسريع نشر وكلاء الذكاء الاصطناعي. ولكن عندما يتم فحصه، كيف يختلف إطار الخدمة هذا عن أدوات مصدر مفتوح web2؟ ما هي المزايا الفريدة التي يقدمها؟

الميزة المفترضة تكمن في نظام التحفيز الخاص بها. ولكن في الأساس، إنه إطار يمكن استبداله بسهولة بواسطة web2، الذي يقود وكلاء الذكاء الاصطناعي الذين يركزون أساسًا على إصدار عملات جديدة. هذا مقلق. إذا تبعت هذا المنطق، ستفهم لماذا يمكن لـ Manus + MCP تعطيل وكلاء الذكاء الاصطناعي لـ web3: إطارات وكلاء الذكاء الاصطناعي الحالية في web3 تقوم ببساطة بتكرار احتياجات التطوير السريع والتطبيق لوكلاء الذكاء الاصطناعي في web2 دون التقدم في الخدمات الفنية أو المعايير أو التمييز. نتيجة لذلك، أعادت السوق والرأسمال تقييم وإعادة ضبط وكلاء الذكاء الاصطناعي في web3 السابقين.

3) الآن، بعد تحديد نقطة الضعف في المشكلة، ماذا يمكن فعله لحلها؟ الجواب بسيط: التركيز على إنشاء حلول حقاً متوافقة مع web3. الميزة الفريدة لـ web3 تكمن في أنظمتها الموزعة وهياكل التحفيز.

اعتبر منصات خدمات الحوسبة السحابية الموزعة والبيانات والخوارزميات. على الرغم من أنه قد يبدو على السطح أن تجميع الموارد الخاملة لتوفير القدرة الحسابية والبيانات لن يرضي احتياجات الابتكار الهندسي الفورية، إلا أن الواقع يقول بأنه مع اشتراك العديد من نماذج الذكاء الاصطناعي في سباق التحسين، فإن فكرة تقديم "الموارد الخاملة بتكلفة منخفضة" تصبح نموذج خدمة مجذر. في البداية، قد يتجاهل مطورو الويب2 ورؤساء الشركات المستثمرة هذا الأمر، ولكن مع تقدم الابتكار المتعلق بوكلاء الذكاء الاصطناعي من ويب2 بعيدًا عن الأداء ويدخل في توسيع التطبيقات الرأسية، وضبط الدقة، وتحسين النموذج، ستصبح مزايا موارد الذكاء الاصطناعي في ويب3 واضحة.

في الواقع، بمجرد أن يصل الذكاء الاصطناعي في الويب2 إلى القمة من خلال احتكار الموارد، سيصبح من الصعب تزايداً عكس الاتجاه واستخدام استراتيجية "القرية تحيط المدينة" للتعامل مع التطبيقات المتخصصة والمقسمة. هذا هو الوقت الذي سيدفع فيه وفرة من مطوري الذكاء الاصطناعي في الويب2، جنباً إلى جنب مع موارد الذكاء الاصطناعي في الويب3، بشكل حقيقي إلى الأمام.

لذلك، فإن الفرصة لوكلاء الذكاء الاصطناعي web3 واضحة: قبل أن تُغمر منصة موارد الذكاء الاصطناعي web3 بمطوري web2 الذين يبحثون عن حلول، يتعين علينا التركيز على تطوير مجموعة من الحلول القابلة للتنفيذ والموجهة نحو web3. بعيدًا عن النشر السريع بنمط web2 فقط، والتعاون بين العملاء المتعددين، ونماذج العملات المستندة إلى الرموز، هناك اتجاهات مبتكرة كثيرة تستحق استكشافها لوكلاء الذكاء الاصطناعي web3.

على سبيل المثال، سيكون هناك حاجة إلى إطار تعاون توافق موزع يأخذ في الاعتبار خصائص الحوسبة خارج السلسلة الكبيرة LLM وتخزين حالة داخل السلسلة. هذا يتطلب العديد من المكونات القابلة للتكيف:

1. نظام التحقق من الهوية DID اللامركزي: سيتيح هذا للوكلاء امتلاك هويات قابلة للتحقق على السلسلة، على غرار كيفية توليد عنوان فريد لعقد ذكي من قبل جهاز تنفيذ افتراضي. يستخدم هذا النظام بشكل رئيسي لتتبع المستمر وتسجيل الحالات التالية؛

2. نظام الأوراق المالية المفcentralized: يتحمل هذا النظام مسؤولية الحصول والتحقق الموثوق من البيانات خارج السلسلة. على عكس الأوراق المالية التقليدية، قد يتطلب هذا النظام المتكيف مع وكلاء الذكاء الاصطناعي هندسة مجتمعة، بما في ذلك طبقات جمع البيانات، طبقات قرار الاجماع، وطبقات ردود الفعل في التنفيذ. يضمن هذا أن البيانات التي يحتاجها الوكيل في السلسلة، والتفاضلات والقرارات خارج السلسلة، يمكن الوصول إليها في الوقت الحالي؛

3. نظام تخزين DA غير المركزي: نظرًا لأن حالة قاعدة المعرفة أثناء عمل وكيل الذكاء الاصطناعي غير مؤكدة، وعمليات التفكير تميل إلى أن تكون مؤقتة، من الضروري تسجيل مكتبة الحالة الرئيسية ومسارات التفكير وراء LLM. يجب تخزين هذه في نظام تخزين موزع يحتوي على آلية دليل بيانات تحكم في التكلفة لضمان توفر البيانات أثناء التحقق من سلسلة الكتل العامة؛

4. طبقة الحوسبة الخاصة بإثبات العلم الصفري (ZKP): يمكن أن تتكامل مع حلول الحوسبة الخاصة بالخصوصية مثل TEE (البيئة الموثوقة للتنفيذ) و FHE (التشفير المتكامل تمامًا)، مما يمكن من الحوسبة الخاصة بالخصوصية في الوقت الحقيقي والتحقق من دليل البيانات. يتيح ذلك للوكلاء الوصول إلى مجموعة أوسع من مصادر البيانات الرأسية (على سبيل المثال، البيانات الطبية، البيانات المالية)، مما يؤدي إلى ظهور المزيد من الوكلاء الخدميين المتخصصين والمخصصين.

5. بروتوكول توافق السلاسل الجانبية: سيشبه هذا الإطار الذي حدده بروتوكول MCP مفتوح المصدر. ومع ذلك، تتطلب هذه الحلول القابلة للتوافق آليات الإعادة وجدولة الاتصال التي تتكيف مع عمليات الوكيل ونقل البيانات والتحقق. إنه يضمن نقل الأصول ومزامنة الحالة عبر سلاسل مختلفة، خاصة للحالات المعقدة مثل سياق الوكيل، والتلميحات، وقاعدة المعرفة، والذاكرة، إلخ.

……

في رأيي، التحدي الأساسي لوكلاء الذكاء الاصطناعي في Web3 هو مواءمة "سير العمل المعقدة" لوكلاء الذكاء الاصطناعي مع "سير التحقق من الثقة" للبلوكشين بأقرب ما يكون. يمكن أن تنشأ هذه الحلول التدريجية إما من ترقية المشاريع الحالية أو من خلقها من جديد ضمن مشاريع جديدة في مسار سرد وكلاء الذكاء الاصطناعي.

يجب على وكلاء الذكاء الاصطناعي في Web3 أن يهدفوا إلى التطور، متماشين مع النظام البيئي المبتكر الأساسي تحت السرد الكبير للذكاء الاصطناعي + العملات المشفرة. إذا لم يكن هناك ابتكار أو إنشاء لعوائق تنافسية مختلفة، فإن كل تحول في مسار الذكاء الاصطناعي في Web2 يمكن أن يعطل المشهد الخاص بالذكاء الاصطناعي في Web3.

تنصل:

1. يتم استنساخ هذا المقال من [ نشرة Haotian-CryptoInsight Substack], حقوق الطبع والنشر تنتمي إلى الكاتب الأصلي [@haotiancryptoinsightإذا كان لديك أي اعتراض على إعادة النشر، يرجى التواصل علىبوابة تعلمالفريق، سيتولى الفريق التعامل معه في أقرب وقت ممكن وفقا للإجراءات ذات الصلة.
2. تنويه: الآراء والآراء التي تم التعبير عنها في هذه المقالة تمثل آراء الكاتب فقط ولا تشكل أي نصيحة استثمارية.
3. تتم ترجمة الإصدارات الأخرى للمقال بواسطة فريق Gate Learn ولا يتم ذكرها فيGate.io, قد لا يُسمح بإعادة إنتاج أو توزيع أو سرقة المقال المترجم.