آزمون جولای بر روی ۲۰۰ رستوران در آمستردام نشان داد که دستیاران هوش مصنوعی فعلی نمی‌توانند فرآیند رزرو میز را تکمیل کنند، زیرا ویجت رزرو درون یک iframe پنهان شده است.

چرا iframe مانع از فعالیت عامل‌ها (agents) می‌شود

اکثر ابزارهای رزرو آنلاین به صورت یک iframe تعبیه‌شده ارائه می‌شوند. بازدیدکننده روی دکمه «Reserve» کلیک می‌کند، تقویمی ظاهر می‌شود و کاربر یک بازه زمانی را انتخاب می‌کند. برای یک انسان، این فرآیند به درستی کار می‌کند؛ اما برای یک عامل هوش مصنوعی (AI agent)، فرآیند متوقف می‌شود.

  • عامل صفحه اصلی HTML را تجزیه (parse) می‌کند.
  • دکمه رزرو به یک URL در یک دامنه متفاوت اشاره دارد.
  • مرورگر آن URL را درون یک iframe بارگذاری می‌کند و آن را از صفحه اصلی جدا می‌سازد.

از آنجایی که سیاست «هم‌منشأ» (same-origin policy) مانع از آن می‌شود که اسکریپت‌های صفحه اصلی بتوانند DOM مربوط به iframe را بخوانند یا فراخوانی‌های شبکه آن را رهگیری کنند، یک عامل هوش مصنوعی که محتوای صفحه را می‌خواند و درخواست‌های HTTP ارسال می‌کند، فقط دکمه را می‌بیند. این عامل هرگز تقویم، بازه‌های زمانی یا فرآیند تأیید را مشاهده نمی‌کند. حتی اگر روی دکمه کلیک کند، باز هم باید کپچاها (captchas) را حل کند، خود را با تغییرات چیدمان تطبیق دهد یا از لایه‌های دفاعی ضد اتوماسیون که بسیاری از سرویس‌های رزرو به کار می‌گیرند، عبور کند.

فقدان لینک قابل خواندن توسط ماشین

یک حسابرسی جداگانه از ۱۶۳ سایت فعال رستوران نشان داد که تنها ۹ سایت اطلاعات رزرو قابل خواندن توسط ماشین را ارائه داده‌اند. آن ۹ سایت، اطلاعات پایه شامل نام و آدرس را با استفاده از نشانه‌گذاری schema.org فهرست کرده بودند، اما هیچ‌کدام شامل اقدامات رزروی (reservation actions) نبودند که یک عامل بتواند آن‌ها را فراخوانی کند. Schema.org انواع مختلفی مانند ReserveAction را برای این منظور تعریف کرده است، با این حال اکثر سایت‌ها تنها متادیتای توصیفی منتشر می‌کنند، نه دستورالعمل‌های عملیاتی.

در عمل، یک دستیار به دنبال داده‌های ساختاریافته‌ای می‌گردد که به او بگوید چگونه یک وظیفه را انجام دهد، نه اینکه فقط بگوید آن وظیفه چیست. بدون یک ReserveAction یا یک نقطه پایانی (endpoint) مشابه، عامل ناچار است به تقلید از کلیک انسان متوسل شود که همان‌طور که در بالا توضیح داده شد، غیرقابل اعتماد است.

یک راهکار عملی بدون تغییر ساختار رابط کاربری (UI)

  1. انتشار یک API رزرو – یک نقطه پایانی (endpoint) سبک HTTP ایجاد کنید که درخواست‌های JSON را برای پرس‌وجوی موجود بودن و ایجاد رزرو بپذیرد. این API فیلدهایی مانند تاریخ، زمان، تعداد نفرات و کد تأیید را برمی‌گرداند. هر عاملی می‌تواند بدون نیاز به رندر کردن صفحه، از آن استفاده کند.
  2. قابلیت کشف API را فراهم کنید – یک نشانگر در مکانی شناخته‌شده مانند /.well-known/booking قرار دهید یا یک ورودی ReserveAction را در نشانه‌گذاری schema.org صفحه بگنجانید. این کار به عامل‌ها می‌گوید «یک راه برنامه‌نویسی‌شده برای رزرو در اینجا وجود دارد» بدون اینکه نیاز به استخراج داده (scraping) باشد.
  3. به‌کارگیری پروتکل زمینه مدل (Model Context Protocol یا MCP) – پروتکل MCP به دستیارها اجازه می‌دهد تا مستقیماً ابزارهای خارجی را فراخوانی کرده، ورودی‌ها را ارسال و خروجی‌های ساختاریافته را دریافت کنند. ارائه‌دهندگان بزرگ هوش مصنوعی در حال حاضر از MCP پشتیبانی می‌کنند، بنابراین رستورانی که یک نقطه پایانی سازگار با MCP را پیاده‌سازی کند، می‌تواند توسط عامل‌ها به‌گونه‌ای فراخوانی شود که گویی یک تابع داخلی است.

این مراحل اجازه می‌دهند iframe بصری برای کاربران انسانی باقی بماند، در حالی که مسیری تمیز و قابل اعتماد برای دسترسی عامل‌ها به همان داده‌های رزرو فراهم می‌شود.

نتیجه‌گیری

تعبیه کردن تقویم درون یک iframe، جریان بصری را برای انسان‌ها حفظ می‌کند اما دستیاران هوش مصنوعی را کور نگه می‌دارد. افزودن یک API رزرو ساده و مستند، و تبلیغ آن از طریق متادیتای استاندارد یا MCP، بدون نیاز به بازطراحی کل وب‌سایت، کانال رزرو جدیدی را باز می‌کند. این تلاش باعث افزایش دیده شدن در نسل بعدی دستیاران دیجیتال می‌شود و ریسک آن را می‌توان با همان کنترل‌های امنیتی که در حال حاضر در رابط کاربری موجود استفاده می‌شود، مدیریت کرد.