أظهر اختبار أُجري في شهر يوليو على 200 مطعم في أمستردام أن مساعدي الذكاء الاصطناعي الحاليين لا يمكنهم إتمام عملية حجز طاولة لأن أداة الحجز مخفية داخل إطار (iframe).

لماذا يعيق الـ iframe الوكلاء

تُقدم معظم أدوات الحجز عبر الإنترنت كإطار مدمج (iframe). ينقر الزائر على زر "حجز" (Reserve)، فتظهر تقويم، ويختار المستخدم فترات زمنية محددة. بالنسبة للإنسان، تسير العملية بسلاسة؛ أما بالنسبة لوكيل الذكاء الاصطناعي، فتتوقف العملية.

  • يقوم الوكيل بتحليل صفحة HTML الرئيسية.
  • يشير زر الحجز إلى رابط (URL) في نطاق (domain) مختلف.
  • يقوم المتصفح بتحميل ذلك الرابط داخل iframe، مما يعزله عن الصفحة الأصلية.

نظرًا لأن سياسة الأصل نفسه (same-origin policy) تمنع البرامج النصية (scripts) في الصفحة الأصلية من قراءة الـ DOM الخاص بالـ iframe أو اعتراض طلبات الشبكة الخاصة به، فإن وكيل الذكاء الاصطناعي الذي يقرأ محتوى الصفحة ويرسل طلبات HTTP لا يرى سوى الزر. إنه لا يرى التقويم، أو الفترات الزمنية، أو مسار التأكيد أبدًا. وحتى لو نقر على الزر، فإنه لا يزال مضطرًا لحل اختبارات الكابتشا (captchas)، أو التكيف مع تغييرات التنسيق، أو تجنب دفاعات مكافحة الأتمتة التي تستخدمها العديد من خدمات الحجز.

الرابط المفقود القابل للقراءة آليًا

وجد تدقيق منفصل لـ 163 موقعًا لمطاعم عاملة أن تسعة مواقع فقط هي التي كشفت عن أي بيانات حجز قابلة للقراءة آليًا. وقد أدرجت هذه المواقع التسعة معلومات أساسية — الاسم والعنوان — باستخدام ترميز schema.org، ولكن لم يتضمن أي منها إجراءات حجز يمكن للوكيل استدعاؤها. يحدد schema.org أنواعًا مثل ReserveAction لهذا الغرض، ومع ذلك تنشر معظم المواقع بيانات وصفية (metadata) فقط، وليس تعليمات قابلة للتنفيذ.

من الناحية العملية، يبحث المساعد عن بيانات منظمة تخبره كيفية تنفيذ المهمة، وليس فقط ما هي المهمة. وبدون ReserveAction أو نقطة نهاية (endpoint) مماثلة، يلجأ الوكيل إلى محاكاة نقرة الإنسان، وهو أمر غير موثوق به كما هو موضح أعلاه.

حل عملي لا يتطلب تغيير واجهة المستخدم بالكامل

  1. نشر واجهة برمجة تطبيقات (API) للحجز – إنشاء نقطة نهاية HTTP خفيفة الوزن تقبل طلبات JSON للاستعلام عن التوافر وإنشاء الحجوزات. تعيد الـ API حقولاً مثل التاريخ، والوقت، وحجم المجموعة، ورمز التأكيد. يمكن لأي وكيل استهلاكها دون الحاجة إلى عرض الصفحة.
  2. جعل الـ API قابلة للاكتشاف – وضع مؤشر في موقع معروف، مثل /.well-known/booking ، أو تضمين إدخال ReserveAction في ترميز schema.org الخاص بالصفحة. يخبر هذا الوكلاء بأن "هناك طريقة برمجية للحجز هنا" دون الحاجة إلى كشط البيانات (scraping).
  3. اعتماد بروتوكول سياق النموذج (Model Context Protocol - MCP) – يتيح MCP للمساعدين استدعاء الأدوات الخارجية مباشرة، مع تمرير المدخلات واستلام مخرجات منظمة. يدعم مزودو الذكاء الاصطناعي الرئيسيون بالفعل بروتوكول MCP، لذا يمكن للوكلاء استدعاء المطعم الذي يطبق نقطة نهاية متوافقة مع MCP كما لو كانت وظيفة مدمجة.

تسمح هذه الخطوات ببقاء الـ iframe المرئي للمستخدمين البشر، مع منح الوكلاء مسارًا نظيفًا وموثوقًا للوصول إلى نفس بيانات الحجز.

الخلاصة

إن تضمين تقويم داخل iframe يحمي التدفق المرئي للبشر ولكنه يترك مساعدي الذكاء الاصطناعي في حالة عمى. إن إضافة واجهة برمجة تطبيقات (API) بسيطة وموثقة جيدًا للحجز والإعلان عنها من خلال البيانات الوصفية القياسية أو بروتوكول MCP يفتح قناة حجز جديدة دون الحاجة إلى إعادة بناء الموقع بالكامل. يعزز هذا الجهد من الظهور أمام الجيل القادم من المساعدين الرقميين، ويمكن إدارة المخاطر باستخدام نفس ضوابط الأمان المستخدمة بالفعل في واجهة المستخدم الحالية.