هل حركة هبوطية. تستمر في مثل هذه الأوقات بسبب بروتوكول MCP الذي انفجر مؤخرًا مثل #ai16z و arc وغيرها من عوامل توجيه الذكاء الاصطناعي في web3؟ عند النظر الأول، قد يكون الأمر غامضًا قليلاً، هل هناك علاقة؟ ولكن بعد التفكير العميق، يبدو أن هناك منطقًا معينًا: تغييرت منطقيات تقييم قيمة عوامل توجيه الذكاء الاصطناعي في web3 الموجودة بالفعل، وتحتاج الرواية واتجاه المنتج وخط سير التنفيذ إلى تعديلات عاجلة! فيما يلي بعض الآراء الشخصية:
MCP (Model Context Protocol) هو بروتوكول قياسي مفتوح المصدر مصمم لربط جميع أنواع الذكاء الاصطناعي LLM/Agent بمصادر البيانات والأدوات المختلفة بسلاسة، مما يعادل واجهة USB "عامة" قابلة للتوصيل والفصل، ويحل محل الطريقة السابقة التي كانت تتطلب "تغليفًا" نهاية إلى نهاية "محددًا".
ببساطة، كانت هناك جزر بيانات واضحة بين تطبيقات الذكاء الاصطناعي الأصلية، وكان من الضروري للوكيل/LLM تطوير واجهة API للاتصال المتبادل بينهما. لم تكن عمليات التشغيل معقدة فحسب، بل كانت تفتقر أيضًا إلى وظيفة التفاعل ثنائي الاتجاه، وكانت عادة ما تكون لديها وصولًا محدودًا نسبيًا إلى النماذج وقيود الصلاحيات.
ظهور MCP يعني توفير إطار موحد، مما يتيح لتطبيقات الذكاء الاصطناعي التخلص من حالة الجزيرة البيانات السابقة، وتحقيق إمكانيات "ديناميكية" للوصول إلى البيانات الخارجية والأدوات، مما يمكن أن يقلل بشكل كبير من تعقيد التطوير وكفاءة الاندماج، خصوصًا في تنفيذ المهام الآلية واستعلامات البيانات الحية والتعاون عبر المنصات.
ومن المعروف أن العديد من الأشخاص يفكرون على الفور في إذا كان استخدام تكامل Manus الذي يعتمد على التعاون المتعدد للوكلاء في إطار MCP de الخاص بالتعاون المتعدد للوكلاء يمكن أن يكون لا يقهر؟
نعم، Manus + MCP هما المفتاح لتعرض وكيل الذكاء الاصطناعي web3 للصدمة هذه المرة.
ومع ذلك ، فمن غير المعقول أن كلا من Manus و MCP عبارة عن أطر عمل موجهة نحو web2 LLM / Agent ومعايير بروتوكول ، والتي تحل مشكلة تفاعل البيانات والتعاون بين الخوادم المركزية ، وتعتمد أذوناتها والتحكم في الوصول أيضا على الفتح "النشط" لكل عقدة خادم ، بمعنى آخر ، إنها مجرد سمة أداة مفتوحة المصدر.
من المفترض أن تكون بمثابة الطلقة الايطالية المركزية كيف يمكن لمدفع إيطالي مركزي أن يفجر الحصن غير المركزي؟
السبب في ذلك هو أن الوكيل الذكي لـ web3 في المرحلة الأولى كان يحمل طابعًا جدًا "web2"، يعود ذلك جزئيًا إلى أن العديد من الفرق قد جاءت من خلفية web2، وتفتقر إلى فهم كامل لاحتياجات web3 Native الأصلية، على سبيل المثال، كانت إطار ElizaOS في البداية، إطار تغليفي لمساعدة المطورين على نشر تطبيقات الوكيل الذكي للذكاء الاصطناعي بسرعة، وقد دمجت منصات مثل Twitter و Discord وبعض واجهات برمجة التطبيقات مثل OpenAI و Claude و DeepSeek، وقد قامت بتغليف بعض الإطارات العامة مثل Memory و Charater بشكل مناسب، لمساعدة المطورين على تطوير تطبيقات الوكيل الذكي بسرعة. ولكن إذا قورنت، ما هي الفروقات بين هذا الإطار الخدمي وأدوات الشفرة المفتوحة لـ web2؟ وما هي المزايا التنافسية؟
اه، هل الفائدة هي وجود نظام حوافز Tokenomics؟ ثم استخدام إطار يمكن أن يحل محله بالكامل بواسطة web2، وتحفيز مجموعة أكبر من وكلاء AI الذين موجودون لإطلاق عملات معماة جديدة؟ مخيف.. اتبع هذه المنطقية، وستفهم تقريبًا لماذا يمكن لـ Manus + MCP أن يؤثر على وكلاء web3 AI.
نظرًا لأن الكثير من إطارات وخدمات ويب 3 للذكاء الاصطناعي حلت فقط مشاكل تطوير وتطبيق الويب 2 AI Agent بسرعة، ولكن لم تتمكن من مواكبة سرعة الابتكار في تقديم الخدمات التقنية والمعايير والمزايا التفاضلية للويب 2، لذا قامت السوق/الرأسمال بإعادة تقييم وتسعير الدفعة السابقة من ويب 3 AI Agent.
3）ومن المحتمل أن تكونت نقطة الضعف بشكل كبير في هذه النقطة، ولكن كيف يمكننا حل هذه المشكلة؟ هناك طريق واحد فقط: التركيز على حلول web3 الأصلية، لأن نظام الحوكمة الموزعة والبنية التحتية للتحفيز هي المزايا المطلقة لـ web3.
على سبيل المثال، عند النظر السطحي إلى منصة خدمات السحابة الموزعة القائمة على الطاقة الحاسوبية والبيانات والخوارزميات، يبدو أن هذا الحاسوب السحابي والبيانات التي تم جمعها بناءً على موارد غير مستخدمة لا يمكنها في الواقع تلبية احتياجات الابتكار الهندسي على المدى القصير. ومع ذلك، عندما يكون العديد من خوادم الذكاء الاصطناعي في طور التجميع المركزي للقوة الحاسوبية لتحقيق اختراق في أداء المعدات، فإن نمط الخدمة الذي يعتمد على "الموارد غير المستخدمة والتكلفة المنخفضة" سيجعل من مطوري الويب2 وفرق رأس المال الاستثماري يتجاهلونه بشكل طبيعي.
ولكن بمجرد أن ينتهي وكيل AI الخاص بـ web2 من مرحلة تحسين الأداء ، فإنه سيسعى بالضرورة إلى توسيع سيناريوهات التطبيق العمودية وضبط النماذج الدقيقة وغيرها من الاتجاهات ، وسيظهر حقًا مزايا خدمات موارد AI الخاصة بـ web3 في ذلك الوقت.
في الواقع، عندما يصل الذكاء الاصطناعي في web2 إلى مرحلة معينة بطريقة احتكار الموارد ويتسلق إلى موقع العملاق، من الصعب العودة مرة أخرى إلى فكرة حاصر المدينة بالريف، وتفتيت الحالات تدريجيًا، في ذلك الوقت سيكون هناك تعاون مكثف بين مطوري الذكاء الاصطناعي في web2 وتكتل الموارد للذكاء الاصطناعي في web3.
في الواقع، يوجد العديد من الاتجاهات الابتكارية القيمة في web3 Native تستحق الاستكشاف، بالإضافة إلى إطار النشر السريع والتعاون متعدد الوكلاء في web2 + توكينوميك إصدار العملة الرقمية.
على سبيل المثال، مع توفير إطار تعاوني موزع للاتفاق، مع مراعاة خصائص حسابات LLM الكبيرة على السلسلة الفرعية + تخزين الحالة على السلسلة، تحتاج إلى العديد من المكونات التكيفية.
نظام التحقق من الهوية DID غير المركزي الذي يتيح للوكيل امتلاك هوية قابلة للتحقق على السلسلة، مثل العنوان الفريد الذي يتم إنشاؤه لعقود الذكاء الاصطناعي بواسطة الجهاز الظاهري، يتم تتبع وتسجيل الحالة اللاحقة بشكل رئيسي؛
2، نظام أوراق الباركود اللامركزي، المسؤول الرئيسي عن الحصول على البيانات تحت السلسلة والتحقق من مصداقيتها، وبخلاف Oracle السابقة، قد تحتاج هذه النظام المتوافق مع وكيل الذكاء الاصطناعي إلى هيكل مكون من عدة وكلاء بما في ذلك طبقة جمع البيانات، وطبقة توافق القرارات، وطبقة ردود الفعل التنفيذية، لضمان وصول بيانات السلسلة المطلوبة للوكيل والحساب واتخاذ القرارات تحت السلسلة في الوقت الفعلي؛
3、نظام تخزين DA غير مركزي، بسبب عدم التأكد من حالة مكتبة المعرفة أثناء تشغيل وكيل الذكاء الاصطناعي، وكذلك عملية الاستنتاج مؤقتة بشكل أكبر، فإنه من الضروري توفير نظام لتسجيل مكتبة الحالة الرئيسية ومسارات الاستنتاج الخلفية LLM وتخزينها في نظام تخزين موزع، وتوفير آلية تأكيد البيانات قابلة للتحكم من حيث التكلفة، لضمان توفر البيانات عند التحقق من السلسلة العامة؛
4، طقم إثبات المعرفة الصفرية ZKP طبقة الحساب الخصوصية، يمكن أن تتفاعل مع حلول الحساب الخصوصية بما في ذلك TEE و FHE، لتحقيق الحساب الخصوصي في الوقت الحقيقي + التحقق من دليل البيانات، مما يتيح للوكيل الحصول على مصادر بيانات عمودية أوسع (الرعاية الصحية، الخدمات المالية)، مما يؤدي بدوره إلى ظهور المزيد من الخدمات المخصصة المتخصصة أعلى من ذلك.
5، بروتوكول تشغيل مشترك عبر السلاسل، ويشبه إلى حد ما الإطار المحدد من بروتوكول MCP مفتوح المصدر، لكن الاختلاف يكمن في حل هذا الحل العابر للقابلية للتشغيل، حيث يتطلب وجود وكيل تكييف يقوم بتشغيل ونقل وتحقق من المرسل وآلية الاتصال، ويمكنه إتمام تحويل الأصول ومزامنة الحالة للوكيل بين سلاسل مختلفة، وخاصة عندما يتعلق الأمر بتضمين سياق الوكيل والمرشد ومستودع المعرفة والذاكرة وما إلى ذلك.
……
في رأيي، ينبغي أن يكون التركيز الرئيسي لوكيل AI الحقيقي web3 على كيفية جعل 'تدفق العمل المعقد' لوكيل AI و 'تدفق التحقق من الثقة' للبلوكشين يتناسبان قدر الإمكان. بالنسبة لهذه الحلول التكميلية، فإنه من الممكن أن تأتي من ترقيات المشاريع السردية القديمة الموجودة، أو من مشاريع جديدة على مسار السرد لوكيل AI.
هذا هو الاتجاه الذي يجب على وكيل الذكاء الاصطناعي web3 أن يعمل بجد لبنائه، وهو الذي يتفق مع الأسس الأساسية للبيئة الابتكارية تحت سرد القصص الكبرى للذكاء الاصطناعي والعملات المشفرة. إذا لم يكن هناك استكشاف وابتكار ذي صلة وإقامة حواجز تنافسية مختلفة، فإن كل حركة في مضمار سباق الذكاء الاصطناعي web2 قد تؤدي إلى اضطراب كبير في عالم الذكاء الاصطناعي web3.
المحتوى هو للمرجعية فقط، وليس دعوة أو عرضًا. لا يتم تقديم أي مشورة استثمارية أو ضريبية أو قانونية. للمزيد من الإفصاحات حول المخاطر، يُرجى الاطلاع على إخلاء المسؤولية.
رمز الذكاء الاصطناعي Agent ينخفض إلى ما لا نهاية ، هل MCP ساخن جدا؟
هل حركة هبوطية. تستمر في مثل هذه الأوقات بسبب بروتوكول MCP الذي انفجر مؤخرًا مثل #ai16z و arc وغيرها من عوامل توجيه الذكاء الاصطناعي في web3؟ عند النظر الأول، قد يكون الأمر غامضًا قليلاً، هل هناك علاقة؟ ولكن بعد التفكير العميق، يبدو أن هناك منطقًا معينًا: تغييرت منطقيات تقييم قيمة عوامل توجيه الذكاء الاصطناعي في web3 الموجودة بالفعل، وتحتاج الرواية واتجاه المنتج وخط سير التنفيذ إلى تعديلات عاجلة! فيما يلي بعض الآراء الشخصية:
ببساطة، كانت هناك جزر بيانات واضحة بين تطبيقات الذكاء الاصطناعي الأصلية، وكان من الضروري للوكيل/LLM تطوير واجهة API للاتصال المتبادل بينهما. لم تكن عمليات التشغيل معقدة فحسب، بل كانت تفتقر أيضًا إلى وظيفة التفاعل ثنائي الاتجاه، وكانت عادة ما تكون لديها وصولًا محدودًا نسبيًا إلى النماذج وقيود الصلاحيات.
ظهور MCP يعني توفير إطار موحد، مما يتيح لتطبيقات الذكاء الاصطناعي التخلص من حالة الجزيرة البيانات السابقة، وتحقيق إمكانيات "ديناميكية" للوصول إلى البيانات الخارجية والأدوات، مما يمكن أن يقلل بشكل كبير من تعقيد التطوير وكفاءة الاندماج، خصوصًا في تنفيذ المهام الآلية واستعلامات البيانات الحية والتعاون عبر المنصات.
ومن المعروف أن العديد من الأشخاص يفكرون على الفور في إذا كان استخدام تكامل Manus الذي يعتمد على التعاون المتعدد للوكلاء في إطار MCP de الخاص بالتعاون المتعدد للوكلاء يمكن أن يكون لا يقهر؟
نعم، Manus + MCP هما المفتاح لتعرض وكيل الذكاء الاصطناعي web3 للصدمة هذه المرة.
من المفترض أن تكون بمثابة الطلقة الايطالية المركزية كيف يمكن لمدفع إيطالي مركزي أن يفجر الحصن غير المركزي؟
السبب في ذلك هو أن الوكيل الذكي لـ web3 في المرحلة الأولى كان يحمل طابعًا جدًا "web2"، يعود ذلك جزئيًا إلى أن العديد من الفرق قد جاءت من خلفية web2، وتفتقر إلى فهم كامل لاحتياجات web3 Native الأصلية، على سبيل المثال، كانت إطار ElizaOS في البداية، إطار تغليفي لمساعدة المطورين على نشر تطبيقات الوكيل الذكي للذكاء الاصطناعي بسرعة، وقد دمجت منصات مثل Twitter و Discord وبعض واجهات برمجة التطبيقات مثل OpenAI و Claude و DeepSeek، وقد قامت بتغليف بعض الإطارات العامة مثل Memory و Charater بشكل مناسب، لمساعدة المطورين على تطوير تطبيقات الوكيل الذكي بسرعة. ولكن إذا قورنت، ما هي الفروقات بين هذا الإطار الخدمي وأدوات الشفرة المفتوحة لـ web2؟ وما هي المزايا التنافسية؟
اه، هل الفائدة هي وجود نظام حوافز Tokenomics؟ ثم استخدام إطار يمكن أن يحل محله بالكامل بواسطة web2، وتحفيز مجموعة أكبر من وكلاء AI الذين موجودون لإطلاق عملات معماة جديدة؟ مخيف.. اتبع هذه المنطقية، وستفهم تقريبًا لماذا يمكن لـ Manus + MCP أن يؤثر على وكلاء web3 AI.
نظرًا لأن الكثير من إطارات وخدمات ويب 3 للذكاء الاصطناعي حلت فقط مشاكل تطوير وتطبيق الويب 2 AI Agent بسرعة، ولكن لم تتمكن من مواكبة سرعة الابتكار في تقديم الخدمات التقنية والمعايير والمزايا التفاضلية للويب 2، لذا قامت السوق/الرأسمال بإعادة تقييم وتسعير الدفعة السابقة من ويب 3 AI Agent.
3）ومن المحتمل أن تكونت نقطة الضعف بشكل كبير في هذه النقطة، ولكن كيف يمكننا حل هذه المشكلة؟ هناك طريق واحد فقط: التركيز على حلول web3 الأصلية، لأن نظام الحوكمة الموزعة والبنية التحتية للتحفيز هي المزايا المطلقة لـ web3.
على سبيل المثال، عند النظر السطحي إلى منصة خدمات السحابة الموزعة القائمة على الطاقة الحاسوبية والبيانات والخوارزميات، يبدو أن هذا الحاسوب السحابي والبيانات التي تم جمعها بناءً على موارد غير مستخدمة لا يمكنها في الواقع تلبية احتياجات الابتكار الهندسي على المدى القصير. ومع ذلك، عندما يكون العديد من خوادم الذكاء الاصطناعي في طور التجميع المركزي للقوة الحاسوبية لتحقيق اختراق في أداء المعدات، فإن نمط الخدمة الذي يعتمد على "الموارد غير المستخدمة والتكلفة المنخفضة" سيجعل من مطوري الويب2 وفرق رأس المال الاستثماري يتجاهلونه بشكل طبيعي.
ولكن بمجرد أن ينتهي وكيل AI الخاص بـ web2 من مرحلة تحسين الأداء ، فإنه سيسعى بالضرورة إلى توسيع سيناريوهات التطبيق العمودية وضبط النماذج الدقيقة وغيرها من الاتجاهات ، وسيظهر حقًا مزايا خدمات موارد AI الخاصة بـ web3 في ذلك الوقت.
في الواقع، عندما يصل الذكاء الاصطناعي في web2 إلى مرحلة معينة بطريقة احتكار الموارد ويتسلق إلى موقع العملاق، من الصعب العودة مرة أخرى إلى فكرة حاصر المدينة بالريف، وتفتيت الحالات تدريجيًا، في ذلك الوقت سيكون هناك تعاون مكثف بين مطوري الذكاء الاصطناعي في web2 وتكتل الموارد للذكاء الاصطناعي في web3.
في الواقع، يوجد العديد من الاتجاهات الابتكارية القيمة في web3 Native تستحق الاستكشاف، بالإضافة إلى إطار النشر السريع والتعاون متعدد الوكلاء في web2 + توكينوميك إصدار العملة الرقمية.
على سبيل المثال، مع توفير إطار تعاوني موزع للاتفاق، مع مراعاة خصائص حسابات LLM الكبيرة على السلسلة الفرعية + تخزين الحالة على السلسلة، تحتاج إلى العديد من المكونات التكيفية.
نظام التحقق من الهوية DID غير المركزي الذي يتيح للوكيل امتلاك هوية قابلة للتحقق على السلسلة، مثل العنوان الفريد الذي يتم إنشاؤه لعقود الذكاء الاصطناعي بواسطة الجهاز الظاهري، يتم تتبع وتسجيل الحالة اللاحقة بشكل رئيسي؛
2، نظام أوراق الباركود اللامركزي، المسؤول الرئيسي عن الحصول على البيانات تحت السلسلة والتحقق من مصداقيتها، وبخلاف Oracle السابقة، قد تحتاج هذه النظام المتوافق مع وكيل الذكاء الاصطناعي إلى هيكل مكون من عدة وكلاء بما في ذلك طبقة جمع البيانات، وطبقة توافق القرارات، وطبقة ردود الفعل التنفيذية، لضمان وصول بيانات السلسلة المطلوبة للوكيل والحساب واتخاذ القرارات تحت السلسلة في الوقت الفعلي؛
3、نظام تخزين DA غير مركزي، بسبب عدم التأكد من حالة مكتبة المعرفة أثناء تشغيل وكيل الذكاء الاصطناعي، وكذلك عملية الاستنتاج مؤقتة بشكل أكبر، فإنه من الضروري توفير نظام لتسجيل مكتبة الحالة الرئيسية ومسارات الاستنتاج الخلفية LLM وتخزينها في نظام تخزين موزع، وتوفير آلية تأكيد البيانات قابلة للتحكم من حيث التكلفة، لضمان توفر البيانات عند التحقق من السلسلة العامة؛
4، طقم إثبات المعرفة الصفرية ZKP طبقة الحساب الخصوصية، يمكن أن تتفاعل مع حلول الحساب الخصوصية بما في ذلك TEE و FHE، لتحقيق الحساب الخصوصي في الوقت الحقيقي + التحقق من دليل البيانات، مما يتيح للوكيل الحصول على مصادر بيانات عمودية أوسع (الرعاية الصحية، الخدمات المالية)، مما يؤدي بدوره إلى ظهور المزيد من الخدمات المخصصة المتخصصة أعلى من ذلك.
5، بروتوكول تشغيل مشترك عبر السلاسل، ويشبه إلى حد ما الإطار المحدد من بروتوكول MCP مفتوح المصدر، لكن الاختلاف يكمن في حل هذا الحل العابر للقابلية للتشغيل، حيث يتطلب وجود وكيل تكييف يقوم بتشغيل ونقل وتحقق من المرسل وآلية الاتصال، ويمكنه إتمام تحويل الأصول ومزامنة الحالة للوكيل بين سلاسل مختلفة، وخاصة عندما يتعلق الأمر بتضمين سياق الوكيل والمرشد ومستودع المعرفة والذاكرة وما إلى ذلك.
……
في رأيي، ينبغي أن يكون التركيز الرئيسي لوكيل AI الحقيقي web3 على كيفية جعل 'تدفق العمل المعقد' لوكيل AI و 'تدفق التحقق من الثقة' للبلوكشين يتناسبان قدر الإمكان. بالنسبة لهذه الحلول التكميلية، فإنه من الممكن أن تأتي من ترقيات المشاريع السردية القديمة الموجودة، أو من مشاريع جديدة على مسار السرد لوكيل AI.
هذا هو الاتجاه الذي يجب على وكيل الذكاء الاصطناعي web3 أن يعمل بجد لبنائه، وهو الذي يتفق مع الأسس الأساسية للبيئة الابتكارية تحت سرد القصص الكبرى للذكاء الاصطناعي والعملات المشفرة. إذا لم يكن هناك استكشاف وابتكار ذي صلة وإقامة حواجز تنافسية مختلفة، فإن كل حركة في مضمار سباق الذكاء الاصطناعي web2 قد تؤدي إلى اضطراب كبير في عالم الذكاء الاصطناعي web3.