Một thử nghiệm vào tháng 7 đối với 200 nhà hàng tại Amsterdam cho thấy các trợ lý AI hiện nay không thể hoàn tất việc đặt bàn vì tiện ích đặt chỗ (booking widget) bị ẩn bên trong một iframe.

Tại sao iframe lại ngăn cản các agent

Hầu hết các công cụ đặt chỗ trực tuyến đều được cung cấp dưới dạng một iframe nhúng. Khách truy cập nhấp vào nút “Reserve”, một lịch hiện ra và người dùng chọn một khung giờ. Đối với con người, quy trình này hoạt động bình thường; nhưng đối với một AI agent, nó bị đình trệ.

  • Agent phân tích cú pháp trang HTML chính.
  • Nút đặt chỗ trỏ đến một URL trên một domain khác.
  • Trình duyệt tải URL đó bên trong một iframe, cô lập nó khỏi trang cha.

Vì chính sách cùng nguồn gốc (same-origin policy) ngăn chặn các script ở trang cha đọc DOM của iframe hoặc chặn các cuộc gọi mạng (network calls) của nó, nên một AI agent thực hiện đọc nội dung trang và gửi các yêu cầu HTTP sẽ chỉ nhìn thấy mỗi cái nút. Nó không bao giờ thấy được lịch, các khung giờ hay quy trình xác nhận. Ngay cả khi nhấp được vào nút, nó vẫn phải giải captcha, thích nghi với các thay đổi về bố cục hoặc né tránh các cơ chế chống tự động hóa mà nhiều dịch vụ đặt chỗ đang áp dụng.

Mối liên kết có thể đọc được bằng máy còn thiếu

Một cuộc kiểm tra riêng biệt trên 163 trang web nhà hàng đang hoạt động cho thấy chỉ có 9 trang cung cấp bất kỳ dữ liệu đặt chỗ nào có thể đọc được bằng máy. 9 trang này liệt kê các thông tin cơ bản—tên và địa chỉ—bằng cách sử dụng đánh dấu schema.org, nhưng không trang nào bao gồm các hành động đặt chỗ (reservation actions) mà một agent có thể thực hiện. Schema.org định nghĩa các loại như ReserveAction cho mục đích này, tuy nhiên hầu hết các trang web chỉ công bố siêu dữ liệu (metadata) mang tính mô tả, chứ không phải các hướng dẫn có thể thực thi.

Trong thực tế, một trợ lý sẽ tìm kiếm dữ liệu có cấu trúc để cho nó biết cách thực hiện một tác vụ, chứ không chỉ là tác vụ đó là gì. Nếu không có ReserveAction hoặc một endpoint tương đương, agent sẽ phải quay lại cách mô phỏng cú nhấp chuột của con người, điều mà như đã mô tả ở trên, là không đáng tin cậy.

Một giải pháp thực tế mà không cần phá bỏ UI

  1. Công bố một booking API – Tạo một HTTP endpoint nhẹ nhàng chấp nhận các yêu cầu JSON để truy vấn tình trạng trống và tạo đặt chỗ. API này trả về các trường như ngày, giờ, số lượng khách và mã xác nhận. Bất kỳ agent nào cũng có thể sử dụng nó mà không cần render trang web.
  2. Giúp API có thể được khám phá – Đặt một con trỏ ở một vị trí quen thuộc, chẳng hạn như /.well-known/booking, hoặc nhúng một mục ReserveAction vào đánh dấu schema.org của trang. Điều này thông báo cho các agent rằng “có một cách lập trình để đặt chỗ tại đây” mà không cần phải cào dữ liệu (scraping).
  3. Áp dụng Model Context Protocol (MCP) – MCP cho phép các trợ lý gọi trực tiếp các công cụ bên ngoài, truyền đầu vào và nhận đầu ra có cấu trúc. Các nhà cung cấp AI lớn đã hỗ trợ MCP, vì vậy một nhà hàng triển khai endpoint tương thích với MCP có thể được các agent gọi như thể đó là một hàm tích hợp sẵn.

Các bước này cho phép iframe trực quan vẫn tồn tại cho người dùng là con người, đồng thời cung cấp cho các agent một lộ trình sạch sẽ, đáng tin cậy để tiếp cận cùng một dữ liệu đặt chỗ.

Bài học rút ra

Việc nhúng một lịch vào trong iframe giúp bảo vệ luồng trải nghiệm trực quan cho con người nhưng lại khiến các trợ lý AI bị "mù". Việc bổ sung một booking API khiêm tốn, được tài liệu hóa tốt và quảng bá thông qua siêu dữ liệu tiêu chuẩn hoặc MCP sẽ mở ra một kênh đặt chỗ mới mà không cần đại tu toàn bộ website. Nỗ lực này giúp tăng khả năng hiển thị đối với thế hệ trợ lý kỹ thuật số tiếp theo, và rủi ro có thể được quản lý bằng chính các biện pháp kiểm soát bảo mật hiện đang được sử dụng trên UI hiện tại.