WebMCP — عندما تصبح مواقع الإنترنت جاهزة للتعامل مباشرة مع وكلاء الذكاء الاصطناعي

 WebMCP — عندما تصبح مواقع الإنترنت جاهزة للتعامل مباشرة مع وكلاء الذكاء الاصطناعي

تخيّل أن تطلب من وكيل ذكاء اصطناعي:

«ابحث لي عن الرحلة المناسبة واملأ بيانات الحجز.»

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

لكن ماذا لو كان الموقع نفسه يستطيع أن يخبر وكيل الذكاء الاصطناعي مباشرة:

هذه هي الوظائف التي أستطيع تنفيذها، وهذه البيانات المطلوبة لكل وظيفة؟

هذه هي الفكرة وراء WebMCP، وهو مقترح تقني جديد يهدف إلى جعل مواقع الويب أكثر استعدادًا للتعامل مع وكلاء الذكاء الاصطناعي. وفي 2026 بدأت التقنية مرحلة تجريبية في Chrome، لذلك نحن نتحدث عن تقنية ناشئة فعلًا وليست مجرد تصور للمستقبل. 

لماذا يحتاج الإنترنت إلى WebMCP؟

مواقع الإنترنت صُممت أساسًا للبشر.

نحن نرى زرًا يحمل عبارة «إرسال» أو «شراء» ونعرف غالبًا ماذا نفعل به، لكن وكيل AI يحتاج إلى تحليل واجهة الموقع وتحديد العنصر الصحيح ثم تنفيذ الإجراء.

هذه الطريقة يمكن أن تعمل، لكنها ليست دائمًا الأكثر موثوقية.

WebMCP يقترح تغيير العلاقة.

فبدل أن يحاول الوكيل تخمين طريقة استخدام الموقع، يستطيع الموقع توفير أدوات منظمة يستطيع الوكيل فهمها واستخدامها مباشرة. وتوضح وثائق Chrome أن الهدف هو تحسين سرعة ودقة وموثوقية تنفيذ الوكلاء للمهام داخل المواقع. 

مثال بسيط: حجز رحلة

لنفترض أن موقعًا للسفر يحتوي على نموذج للبحث عن الرحلات.

بالطريقة التقليدية يحتاج الوكيل إلى التعرف على:

مدينة المغادرة، والوجهة، والتاريخ، وعدد المسافرين، ثم زر البحث.

مع WebMCP يستطيع الموقع تعريف وظيفة منظمة للبحث عن الرحلات وتحديد المعلومات التي تحتاج إليها.

وهكذا يصبح الحوار بينهما أقرب إلى:

الوكيل: أريد البحث عن رحلة.

الموقع: أحتاج إلى مدينة المغادرة والوجهة والتاريخ.

الوكيل: هذه المعلومات.

الموقع: هذه النتائج.

وهذا يختلف جذريًا عن جعل الذكاء الاصطناعي يحاول تفسير كل بكسل وزر في الشاشة.

كيف يعمل WebMCP؟

يتيح WebMCP للموقع تعريف Tools أو أدوات تمثل الإجراءات التي يستطيع الوكيل تنفيذها.

وتوثق Chrome طريقتين أساسيتين لذلك.

الأولى Declarative API، ويمكن من خلالها الاستفادة من نماذج HTML وتعريفها بطريقة تساعد الوكيل على معرفة الغرض منها.

والثانية Imperative API، التي تسمح للمطور بتعريف وظائف أكثر تخصصًا باستخدام JavaScript. 

وهذا يعني أن الموقع قد يقدم أدوات مثل:

البحث عن منتج، إضافة عنصر إلى السلة، البحث في قاعدة معلومات، ملء نموذج أو تنفيذ وظيفة خاصة بالموقع.

هل WebMCP هو نفسه MCP؟

رغم تشابه الاسمين، لا.

وهذه نقطة مهمة جدًا.

Model Context Protocol أو MCP يستخدم لربط تطبيقات الذكاء الاصطناعي بالأدوات ومصادر البيانات والخدمات.

أما WebMCP فيركز على شيء مختلف: مساعدة الوكيل الموجود في المتصفح على فهم الوظائف التي يوفرها الموقع الذي يتفاعل معه حاليًا.

وتوضح Google صراحة أن WebMCP ليس بديلًا لـMCP ولا امتدادًا له، ويمكن استخدام التقنيتين معًا لأن لكل منهما وظيفة مختلفة. 

ماذا سيتغير بالنسبة للمستخدم؟

إذا انتشرت الفكرة، فقد يتغير أسلوب استخدامنا للويب تدريجيًا.

بدلًا من زيارة خمسة مواقع وتنفيذ عشرات النقرات بأنفسنا، يمكن أن نعطي وكيل AI هدفًا، ثم يتعامل مع الخدمات المتوافقة لإنجازه.

فمثلًا يمكن أن تقول:

«ابحث عن الخيارات المناسبة لهذه المواصفات وقارن بينها.»

فيتعامل الوكيل مع الأدوات التي توفرها المواقع بدل محاولة التنقل بينها بالطريقة نفسها التي يستخدمها الإنسان.

وبالتالي قد يصبح الإنترنت مستقبلًا موجهًا إلى نوعين من المستخدمين:

البشر الذين يستخدمون واجهة الموقع، والوكلاء البرمجيون الذين يستخدمون أدواته المنظمة.

هل ستختفي المواقع وواجهاتها؟

على الأرجح لا.

الإنسان ما زال يحتاج إلى مشاهدة المنتجات والمقالات والصور والنتائج واتخاذ القرارات بنفسه.

لكن قد تظهر طبقة إضافية خلف الموقع مخصصة للوكلاء.

يمكن تشبيه الأمر بمطعم له واجهة أمامية للزبائن، وفي الوقت نفسه لديه نظام منظم لاستقبال الطلبات إلكترونيًا.

الاثنان يؤديان إلى الخدمة نفسها، لكن طريقة التواصل مختلفة.

ماذا يعني هذا لأصحاب المواقع؟

هذه النقطة تجعل WebMCP موضوعًا مهمًا لأصحاب المواقع والمدونات والمتاجر.

في عصر محركات البحث كان السؤال:

هل يستطيع Google فهم موقعي؟

ومع ظهور البحث التوليدي أصبح السؤال أيضًا:

هل يستطيع الذكاء الاصطناعي العثور على محتواي وفهمه؟

أما في الويب الوكيلي فقد يظهر سؤال ثالث:

هل يستطيع وكيل الذكاء الاصطناعي استخدام موقعي؟

ولهذا بدأت Chrome بالفعل بإضافة أدوات للمطورين تساعدهم على تقييم مدى استعداد المواقع للتصفح الوكيلي، ومنها فئة خاصة بالتصفح الوكيلي في Lighthouse.

 

لكن ماذا عن الأمن؟

هنا توجد إحدى أكبر العقبات.

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

كما تحذر وثائق Chrome من هجمات Prompt Injection غير المباشرة، حيث يمكن لمحتوى ضار داخل موقع أو بيانات خارجية محاولة التأثير في تعليمات الوكيل. 

ولهذا يحتاج هذا النوع من الويب إلى ضوابط قوية للصلاحيات والموافقة البشرية والتحقق من الإجراءات الحساسة.

وهنا يوجد ارتباط جميل مع المقال السابق عن الهوية الرقمية للوكلاء دون أن يكون الموضوعان مكررين: الأول يسأل من هو الوكيل وما صلاحياته؟، وهذا المقال يسأل كيف سيصبح الموقع نفسه قابلًا للاستخدام بواسطة ذلك الوكيل؟

هل WebMCP أصبح معيارًا نهائيًا؟

لا، وهذه نقطة يجب توضيحها حتى لا نبالغ في وصف التقنية.

حتى 2026 ما زال WebMCP مقترحًا لمعيار ويب وتقنية قيد التطوير والتجربة، وقد دخل التجارب الأصلية في Chrome، وبالتالي قد تتغير بعض تفاصيله قبل وصوله إلى مرحلة نضج أوسع. 

لكن ظهوره يكشف اتجاهًا أكبر بكثير:

الويب لم يعد يستعد فقط لكي يقرأه الذكاء الاصطناعي، بل لكي يتعامل معه وينفذ المهام داخله.

الخلاصة

على مدار عقود كان تصميم المواقع يدور حول سؤال واحد:

كيف نجعل الموقع سهل الاستخدام للإنسان؟

عصر وكلاء الذكاء الاصطناعي يضيف سؤالًا جديدًا:

كيف نجعل الموقع مفهومًا وقابلًا للاستخدام بواسطة الذكاء الاصطناعي أيضًا؟

WebMCP محاولة للإجابة عن هذا السؤال.

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