قال بعض الأصدقاء أن الانخفاض المستمر في أهداف web3 AI Agent مثل#ai16zو $arc ناجم عن بروتوكول MCP الشهير مؤخرًا؟ عندما سمعتها لأول مرة، شعرت ببعض الحيرة. ما أهمية هذا الأمر؟ لكن بعد التفكير في الأمر بعناية، وجدت أن هناك بالفعل منطقًا معينًا: لقد تغير منطق التقييم والتسعير لوكيل الذكاء الاصطناعي web3 الحالي، ويجب تعديل اتجاه السرد ومسار وصول المنتج بشكل عاجل. وهنا آرائي الشخصية:

١) MCP (بروتوكول سياق النموذج) هو بروتوكول معياري مفتوح المصدر مصمم لتمكين مختلف برامج/وكلاء الذكاء الاصطناعي من الاتصال بسلاسة بمختلف مصادر البيانات والأدوات. وهو يُعادل واجهة USB "العالمية" التي تعمل بنظام التوصيل والتشغيل، مُستبدلًا بذلك طريقة التغليف "المحددة" السابقة من البداية إلى النهاية.

بعبارة بسيطة، كانت تطبيقات AI فيما بينها تعاني جزرًا بياناتية واضحة. ولتحقيق التواصل بين الوكلاء/LLM، يحتاج كل طرف إلى تطوير واجهات API الخاصة به. هذا لا يجعل سير العمل معقدًا فقط، بل يفتقر كذلك إلى وظائف تفاعل ثنائي الاتجاه. وعادةً ما يكون لدى كل طرف وصول إلى نماذج وصلاحيات محدودة نسبيًا.

ظهور MCP يعادل توفير إطار موحّد، بحيث يمكن لتطبيقات الذكاء الاصطناعي التخلص من حالة الجزر البيانية السابقة (data silos)، وتحقيق إمكانية الوصول “الديناميكي” إلى البيانات والأدوات الخارجية، ما يقلل بشكل كبير تعقيد التطوير وكفاءة التكامل. كما يدعم ذلك أوجه مثل تنفيذ المهام الآلية، والاستعلام عن البيانات في الوقت الحقيقي، والتعاون عبر المنصات. وبما أننا وصلنا إلى هنا، كثيرون سيُفكّرون فورًا: إذا استخدمنا إطار MCP مفتوح المصدر لتسهيل تكامل Manus متعدد الوكلاء (Multi-Agent) المبتكر، فهل يصبح الأمر “لا يُهزم”؟

صحيح، إن Manus + MCP هما المفتاح وراء الصدمة التي تعرض لها وكلاء AI في web3.

2) لكن ما لا يصدَّق هو أنه سواء كان Manus أو MCP موجَّهًا إلى أطر وبروتوكولات web2 الخاصة بـ LLM/Agent، فإن ما يحلّانه هو مشاكل تبادل البيانات والتعاون بين خوادم مركزية. كما أن صلاحيات الوصول والتحكم فيها تعتمد على “الانفتاح النشط” من كل عقدة خادم. وبعبارة أخرى: إنه مجرد سمة أداة مفتوحة المصدر.

من حيث المبدأ، فهي تتعارض تمامًا مع الأفكار الجوهرية التي يسعى إليها وكيل AI في web3 مثل “الخوادم الموزعة، التعاون الموزع، التحفيز الموزع”... فكيف يمكن للمدفع الإيطالي المركزي أن يفجر القلاع اللامركزية؟

السبب في ذلك يعود إلى أن وكلاء AI في web3 في المرحلة الأولى أصبحوا “web2化” أكثر من اللازم. من جهة، لأن كثيرًا من الفرق جاءت من خلفية web2، ولا تملك فهمًا كافيًا للاحتياجات الأصلية لـweb3 Native. على سبيل المثال، كان إطار ElizaOS في بدايته عبارة عن إطار تغليف يساعد المطورين على النشر السريع لتطبيقات وكلاء AI، وهو بالضبط ما يقوم بتكامل Twitter وDiscord وغيرها من المنصات، ومع بعض واجهات API مثل OpenAI وClaude وDeepSeek… كما غلّف بشكل مناسب بعض أطر Memory وCharater العامة، لمساعدة المطورين على تطوير تطبيقات وكلاء AI بسرعة. لكن إذا التدقيق أكثر: ما الفرق بين إطار الخدمة هذا وأدوات open-source في web2؟ وأين تكمن ميزة التمايز الحقيقية؟

إيه، هل الميزة هي وجود آلية Tokenomics تحفيزية؟ ثم استخدام إطار عمل يمكن لاستبداله بالكامل عبر web2، لتحفيز مجموعة من وكلاء AI موجودين أساسًا لإصدار عملات جديدة؟ مرعب... وبناءً على هذا المنطق، تتضح لك لماذا يستطيع Manus + MCP إحداث صدمة لوكلاء web3 للذكاء الاصطناعي (AI). لأن أطر وخدمات وكلاء AI في web3 التي ظهرت للتو كانت تَحل فقط احتياجات التطوير السريع والتطبيق لوكلاء AI من فئة web2، لكنها لا تواكب سرعة ابتكار web2 من ناحية الخدمات التقنية والمعايير والميزة التمايزية؛ لذلك قامت السوق/رأس المال بإعادة تقييم وتسعير دفعة سابقة من وكلاء AI في web3.

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

خذ منصات خدمات مثل الحوسبة السحابية الموزعة والبيانات والخوارزميات مثالًا: من الناحية السطحية، تبدو هذه التجميعات للقدرة الحاسوبية والبيانات بداعي “موارد متاحة غير مستخدمة”. في الأجل القصير، لا تستطيع تلبية احتياجات الابتكار عبر الهندسة. لكن في الوقت الذي يشارك فيه عدد كبير من نماذج LLM في سباق عسكري لكسر الأداء عبر الحوسبة المركزية، فإن نموذج خدمة يتخذ شعار “موارد غير مستخدمة بتكلفة منخفضة” كجاذبية سيجعل مطوري web2 وفرق VC الكبيرة ينظرون إليه باستخفاف.

ولكن عندما يمر وكلاء AI في web2 بمرحلة الابتكار المرتكزة على مزاحمة الأداء (拼性能)، فسيبدأ حتمًا السعي إلى توسيع سيناريوهات التطبيقات الرأسية والتوجه نحو ضبط دقيق للموديلات (fine-tuning) في ذلك الوقت ستظهر فعليًا ميزة خدمات موارد web3 AI. في الواقع، عندما يصعد web2 AI إلى موقع العمالقة عبر الاحتكار في الموارد ويصل إلى مرحلة معينة، يصبح من الصعب الرجوع لاستخدام فكرة “مُحاصرة المدن من الريف” (أي مهاجمة تدريجيًا من الأطراف). عندها يأتي وقت العمل الجماعي: مطورو web2 AI الذين يعانون من فائض + موارد web3 AI ليعملوا معًا بقوة.

لذلك، مساحة الفرصة لوكلاء AI في web3 واضحة الآن: قبل أن تمتلك منصات موارد AI في web3 طلب عملاء من مطوري web2 فائضين، استكشف وطبّق مسارًا وحلًا لا بديل عنه سوى بنية موزعة غير خاصة بـweb3. في الواقع، إضافةً إلى إطار النشر السريع لـweb2 + إطار تواصل التعاون متعدد الوكلاء، وسردية Tokenomic لإصدار العملات، توجد العديد من اتجاهات الابتكار التي تخص web3 Native تستحق الاستكشاف:

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

1، نظام تحقق هوية DID لا مركزي، بحيث يمتلك الوكيل AI هوية سلسلة يمكن التحقق منها؛ مثل العنوان الفريد الذي تولّده آلة افتراضية (VM) لعقود ذكية. والهدف الأساسي هو تتبع الحالة وتسجيلها بشكل مستمر لاحقًا؛

2، نظام Oracle تنبؤات لا مركزي (Oracle) وهو عبارة عن: بشكل أساسي مسؤول عن الحصول الموثوق على بيانات خارج السلسلة والتحقق منها. والاختلاف عن Oracle السابق هو أن Oracle المكيّف لوكلاء AI قد يحتاج أيضًا إلى تكوين تركيبي يضم عدة وكلاء (Agent) مثل: طبقة جمع البيانات، طبقة توافق/اتفاق على القرار، وطبقة حلقة ملاحظات التنفيذ، وذلك لكي يتمكن الوكيل من الوصول الفوري إلى بيانات السلسلة المطلوبة وكذلك حسابات القرار خارج السلسلة على نحو لحظي؛

3، نظام تخزين موزع لا مركزي (DA). نظرًا لوجود عدم يقين في حالة قاعدة المعرفة وقت تشغيل وكيل AI، ولأن عملية الاستدلال مؤقتة نسبيًا، فنحتاج إلى آلية لتسجيل “حالة القاعدة المعرفية الأساسية خلف LLM” ومسار الاستدلال وحفظهما في نظام تخزين موزع، وتوفير آلية إثبات قابلة للتحكم في التكلفة لضمان قابلية البيانات للاستخدام عند التحقق على السلسلة العامة (public chain)؛

4، طبقة حوسبة خصوصية لحسابات إثباتات المعرفة الصفرية (ZKP)؛ يمكنها الربط مع حلول حوسبة خصوصية تشمل TEE وFHE وغيرها، لتتحقق “حوسبة خصوصية فورية + تحقق من إثبات البيانات”. وبهذا يمكن للوكيل AI الحصول على مصادر بيانات رأسية أوسع (الطب، التمويل)، ومن ثم تظهر فوق ذلك خدمات أكثر تخصيصًا واحترافية لوكلاء AI؛

5، بروتوكول قابلية التشغيل البيني عبر السلاسل (cross-chain)؛ يشبه إلى حد ما الإطار الذي يعرّفه بروتوكول MCP مفتوح المصدر. والاختلاف هو أن حل قابلية التشغيل البيني هذا يحتاج إلى آليات relay وجدولة اتصال مناسبة لتشغيل الوكلاء ونقلهم والتحقق منهم، بحيث يمكن معالجة مشكلات نقل الأصول وتزامن الحالة بين سلاسل مختلفة. والأهم أنه يتضمن حالات معقدة مثل سياق الوكيل (Agent context) وPromopt وقاعدة المعرفة وMemory وغيرها.

...

في رأيي، نقطة الاختراق الحقيقية لوكلاء AI في web3 يجب أن تكون في كيفية جعل “سير العمل المعقّد” لوكيل AI يتوافق قدر الإمكان مع “مسار التحقق من الثقة” الخاص بسلسلة البلوكشين. أما هذه الحلول الإضافية، سواء جاءت من ترقية وتطوير مشاريع سرديات قديمة، أو من إعادة صياغة مشاريع جديدة داخل مسار سرديات وكلاء AI، فكل ذلك ممكن.

هذا هو الاتجاه الذي يجب على وكلاء AI في web3 أن يسعوا للبناء عليه؛ وهو الأساس الذي يتوافق مع أساس النظام الإيكولوجي للابتكار ضمن السردية الكبرى لـAI + Crypto. إذا لم تُبنَ ابتكارات ذات صلة ولا حواجز منافسة تمايزية، فقد يؤدي كل نفَس/تأثير في سوق مسار AI في web2 إلى قلب عالم AI في web3 رأسًا على عقب.