7 月对阿姆斯特丹 200 家餐厅进行的一项测试显示，目前的 AI 助手无法完成订座，因为预订组件隐藏在 iframe 中。

为什么 iframe 会阻碍智能体

大多数在线预订工具都以嵌入式 iframe 的形式提供。访客点击“预订”按钮，随后弹出日历，用户选择一个时间段。对于人类来说，这个过程很顺畅；但对于 AI 智能体（agent）来说，它却卡住了。

  • 智能体解析主 HTML 页面。
  • 预订按钮指向另一个域名的 URL。
  • 浏览器在 iframe 内部加载该 URL，从而将其与父页面隔离。

由于同源策略（same-origin policy）阻止了父页面中的脚本读取 iframe 的 DOM 或拦截其网络调用，因此，一个通过读取页面内容并发送 HTTP 请求的 AI 智能体只能看到按钮。它永远看不到日历、时间段或确认流程。即使它点击了按钮，仍然必须解决验证码、适应布局变化，或者躲避许多预订服务所采用的反自动化防御措施。

缺失的机器可读链接

对 163 个功能完备的餐厅网站进行的另一项审计发现，只有 9 个网站提供了任何机器可读的预订数据。这 9 个网站使用 schema.org 标记列出了基本信息（名称和地址），但没有一个包含智能体可以调用的预订操作。Schema.org 为此定义了诸如 ReserveAction 之类的类型，但大多数网站仅发布描述性元数据，而非可执行的指令。

在实践中，助手寻找的是能够告知其“如何”执行任务的结构化数据，而不仅仅是任务“是什么”。如果没有 ReserveAction 或类似的端点（endpoint），智能体就会退而求其次，模仿人类的点击行为，而正如上文所述，这种方式是不可靠的。

一种无需重构 UI 的实用修复方案

  1. 发布预订 API – 创建一个轻量级的 HTTP 端点，接受用于查询可用性和创建预订的 JSON 请求。该 API 返回日期、时间、人数和确认码等字段。任何智能体都可以在无需渲染页面的情况下使用它。
  2. 提高 API 的可发现性 – 在已知位置（例如 /.well-known/booking）放置一个指针，或者在页面的 schema.org 标记中嵌入 ReserveAction 条目。这可以告知智能体“这里有程序化的预订方式”，而无需进行网页抓取。
  3. 采用 Model Context Protocol (MCP) – MCP 让助手能够直接调用外部工具，传递输入并接收结构化输出。主流 AI 提供商已经支持 MCP，因此，实现 MCP 兼容端点的餐厅可以像调用内置函数一样被智能体调用。

这些步骤可以让视觉上的 iframe 保留给人类用户，同时为智能体提供一条通往相同预订数据的、简洁且可靠的路径。

总结

将日历嵌入 iframe 虽然保护了人类用户的视觉流程，却让 AI 助手变得“盲目”。通过添加一个简单且文档齐全的预订 API，并通过标准元数据或 MCP 进行推广，可以在不彻底改造网站的情况下开辟一个新的预订渠道。这一举措可以提升在下一代数字助手中的可见度，且其风险可以通过现有 UI 已使用的相同安全控制措施来进行管理。