Meta Muse 把旅行拆成两条路：机票走 Duffel API，酒店靠浏览器

Meta 于 9 月 8 日推出 Muse，定位为能预订旅行的个人 AI 智能体；但一天后 Skift 发表的一篇技术调查揭示了一件该公司在发布时没有强调的事：Muse 用两种截然不同的方式处理旅行交易，而其中只有一种给旅游业留下了明确的位置。机票方面，Muse 直接接入 Duffel 的基础设施 API，从 500 多家航空公司拉取实时库存，并通过 Stripe 的一次性虚拟卡付款，完成真实的预订。酒店、租车和其他大部分旅行品类，Muse 则打开一个浏览器，像人一样去逛面向消费者的网站 —— 供应商与 Meta 之间没有建立任何商业关系，也无法控制这个智能体搜索的频率。

这种区别对酒店和度假租赁行业有立竿见影的后果。被 Muse 访问页面的供应商，要承受一个 AI 智能体反复查询其定价系统所带来的基础设施负载，却得不到通常伴随一个预订渠道而来的数据、佣金安排或直接关系。相比之下，机票这条路提供的是一套结构化的 API 关系，配有退改处理、票价校验，以及 Duffel 的 7×24 人工支持。

Duffel 机票集成究竟怎么运作

Duffel 是一家在伦敦注册的旅行基础设施公司，它的 API 介于预订应用与航空公司订座系统之间。开发者不必逐一与各家航司谈分销协议，Duffel 把接入 NDC 的航空公司和传统内容聚合到一次 API 调用之下。NDC —— 国际航协（IATA）发布的新分销能力标准 —— 让航空公司可以通过现代 Web API 直接分发内容，而不必经过 Amadeus、Sabre、Travelport 这类传统全球分销系统（GDS）中间商。NDC 票价可以包含拆分出售的附加服务，比如升舱、餐食和行李，这些往往是 GDS 系统承载不了的。

当 Muse 用户要订机票时，智能体向 Duffel 的 API 查询实时报价，在聊天界面里呈现选项，并在得到用户批准后完成预订，出一张真实的机票。Duffel 的博客确认，这项集成负责完整的交易生命周期：票价校验、预订、取消和航班异常处理。在机票交易中，Duffel 充当记录商户（merchant of record），扮演的就是任何在 Expedia 或 Google Flights 上订过票的人都熟悉的在线旅行社（OTA）角色。该公司的年化总交易额最近突破了 10 亿美元，而 AI 平台如今是其增长最快的客户群之一。

付款经由Stripe 面向智能体的 Link 完成 —— 这是 Stripe 在 2026 年早些时候推出的产品，让 AI 智能体可以在整个消费互联网上完成交易。在接受 Link 的商户那里（目前超过一百万家），Muse 可以用用户保存的支付方式结账。在不支持 Link 的网站上，Stripe 会签发一张仅限该笔已批准金额的一次性虚拟卡。任何交易在 Muse 完成之前，用户都必须在聊天界面中直接批准；智能体始终看不到真实的卡号或账户信息。Meta 表示，对于符合条件的商品，Muse 的预订享有 Link 的购物保障，包括商品损坏或丢失、降价补差以及免费退货。

支付与凭据安全背后的架构

要理解 Muse 为什么能处理付款而不暴露财务数据，就得先理解 Muse Secure VM —— Meta 专门为这个智能体搭建的云计算环境。每个用户的 Muse 都运行在 Meta 云中一台专属的虚拟机里，而不是共享的多租户环境。在虚拟机内部，智能体本身运行在一个 systemd-nspawn 容器里：容器内的 root 权限映射为宿主机上的一个无特权用户，io_uring 系统调用被从内核接口中过滤掉，CAP_SYS_PTRACE 和 CAP_NET_ADMIN 这类敏感能力也被移除。数据库、凭据存储和安全分类器作为独立服务运行在容器之外，通过带有内核认证对端凭据的 Unix 域套接字与智能体通信。

凭据永远不会到达模型。当用户连接某项服务 —— 邮箱、日历或购物账户 —— 认证凭据会进入那个独立的隔间。智能体经手的只是一个替代令牌，一个即便被窃取也毫无价值的占位符。Sentinel 是一个运行在容器之外、宿主机一侧的独立代理，它会在每一个出站网络请求离开虚拟机之前将其拦截。据Meta 自己的安全工程博客，Sentinel 会检查目标主机名、解析出的 IP 地址、端口、HTTP 方法、URL 路径以及解码后的请求体。未经 Sentinel 批准，任何东西都出不了虚拟机。当 Sentinel 判定需要用户明确批准时 —— 发送邮件之前、完成购买之前 —— 它会中止执行，并把一个批准对话框直接推送到客户端界面，完全绕开对话流程。

Meta 还在内核层面实现了基于 eBPF 的污点追踪，用来区分涉及用户数据的请求与干净的请求，并对前者施加更严格的批准要求。负责网页会话的浏览器子智能体看到的是页面的无障碍树（accessibility tree）而不是原始 DOM，也不能直接执行 JavaScript —— 这一设计选择限制了一类提示词注入攻击。

延伸阅读：Meta 的 Muse Spark 1.3 在 DeepSWE 编程基准上登顶，价格还低于对手

酒店缺口：没有商业基础设施的浏览器自动化

Duffel 机票路径与酒店、租车路径之间的反差，正是这件事对旅行商业最尖锐的含义所在。Skift 的调查发现，Muse 订酒店的方式是打开浏览器，访问面向消费者的在线旅行社网站 —— Expedia、Hotels.com 以及类似平台 —— 和人类旅行者的做法一模一样。由智能体来选择去哪个网站搜索、考虑哪些结果、在哪里下单。供应商对这些活动既看不见，也控制不了。

从经济角度看，这造成了一种会随 Muse 用户规模一起放大的失衡。酒店本来就要为经由在线旅行社平台而来的预订，向这些平台支付可观的推荐费或佣金。当一个 AI 智能体为了在每晚 350 到 450 美元的预算内找到房间而把 Expedia 搜上十遍时 —— Skift 的测试就发现 Muse 这么做过 —— 即便最终没有成交，酒店的搜索基础设施也要承担这份负载。以 Meta 旗下应用每日 35.8 亿活跃人数的规模，Muse 的旅行功能哪怕只有温和的采用率，也可能在整个酒店业实质性地推高「浏览—预订比」。IDC 预测，到本十年末，智能体 AI 将驱动大约三分之一的国际旅行预订；如果在那种情境下酒店供应商仍只是被动的网站，这道商业缺口就会不断叠加。

这里可以类比谷歌早期的网页抓取时代：网站不得不承担搜索引擎的索引成本，却未必能得到成比例的流量。区别在于，一家房间被 Muse 搜过却没被预订的酒店，依然实打实地响应了一次实时价格查询 —— 通常是对订房系统的一次昂贵 API 调用 —— 却没有得到任何补偿。

Duffel CEO Steve Domin 在 Muse 的发布博客里，直白地描述了他的公司所解决的问题：旅行是「AI 智能体的终极压力测试」，因为「它是动态的、复杂的、极其个人化的，而一旦出错，后果是真实的」。言下之意是，没有结构化基础设施层的酒店路径，基本上把这些后果留在了无人管理的状态。

Muse 在消费级智能体竞争中的位置

Meta 的 Muse 进入的是一个 OpenAI 的 ChatGPT、Anthropic 的 Claude 电脑操作工具和谷歌的浏览器自动化智能体都已在运营的市场。具体到机票，Muse 与 Duffel 的 API 集成比其他智能体所用的浏览器自动化方式更结构化 —— 主要的竞品消费级智能体中，还没有一家公开宣布与旅行分销平台建立了类似的直接 API 关系。

按用户分配虚拟机的架构，在竞争上也值得一提。OpenAI 的 ChatGPT 智能体和 Anthropic 的 Claude 电脑操作工具在会话层面运行，配有权限与数据保留控制，但两者都没有公开描述过 Meta 为 Muse 搭建的那种 systemd-nspawn 容器隔离、Sentinel 出站代理和 eBPF 污点追踪。Meta 把这定位为一项差异化的安全主张，并以最高 30 万美元的漏洞赏金计划为其背书。这套架构在实践中是否真的更优，取决于它最薄弱的一环 —— Sentinel 的批准对话框，一旦用户不再细读就可能沦为习惯性点击 —— 能否在真实使用中守住。

Muse 推出时有三档定价：免费档每周最多支持 1 亿 token（据扎克伯格在 Threads 上的说法），Power 档每月 20 美元，Maximum 档每月 100 美元。即便是免费档也要求绑定一张支付卡，这反映出 Muse 被设计成一个可以代表用户进行交易的智能体。每周 1 亿 token 的额度，按消费级 AI 的标准来说很大 —— Gizmodo 的测试发现，做几个游戏加一个网站只用掉了约 11% 的周额度 —— 不过智能体任务消耗 token 的方式与对话不同，规划步骤、工具调用以及用户看不到的浏览器状态快照都会额外消耗 token。

尚未证实的部分，以及边界在哪里

发布材料中有几项重要主张仍属公司自述，未经独立验证。Meta 称 Muse Spark 1.3 对直接越狱以及包括提示词注入在内的间接攻击有很强的抵抗力 —— 考虑到一个在开放网络上浏览的个人智能体可能遇到被恶意构造的页面，这是一项重要的主张。审阅过其架构文档的独立安全研究者指出，Sentinel 是在网络边界上抵御提示词注入的主要防线，而模型层面的抵抗力是最薄弱的一层，且只建立在 Meta 自己的评估之上。这些模型层面的抵抗力主张尚未被独立复现。

Muse 当前的安全保证还附带一个 Meta 自己披露的重要限定：它的安全博客承认，这套机制「并不妨碍 Meta 在为支持、保护或运营该服务所必需时访问数据」。政策禁止访问，但技术上的访问路径是存在的。计划中的 Muse Confidential VM —— 将用密码学手段让这种访问连 Meta 自己都无法实现 —— 据称要到 2026 年晚些时候才会推出，并不是用户今天拿到的东西。在那之前，免费档的默认训练设置意味着，除非用户主动选择退出，经过脱敏处理的 Muse 会话轨迹可被用于改进 Meta 的模型 —— 同样的做法在 2026 年 7 月被用于另一款 Muse 产品（Muse Image）时，曾引发强烈的公众反弹。

Shop Pay 和 1Password 的集成已宣布即将推出。前者上线后，Muse 能不借助 Stripe 虚拟卡机制完成交易的网站会更多；1Password 的支持则会把安全的凭据处理延伸到用户已有账户的网站。

双路径架构对智能体商业意味着什么

Muse 的分叉架构，反映出一个行业尚未解决的真实基础设施现状。要打造一个能大规模可靠预订旅行的 AI 智能体，要么谈判或接入结构化的 API 连接 —— 就像 Duffel 为航空公司提供的那样 —— 要么接受浏览器自动化的脆弱性：它依赖随时可能在不经通知的情况下改版的消费者网站布局，也不为被逛的供应商提供任何商业框架。

对于旅行科技开发者和供应商来说，Muse 的发布是一个比迄今多数智能体商业演示都更清楚的概念验证。机票路径证明，一个消费级智能体可以在不暴露用户凭据的前提下，可靠地执行预订、处理异常和管理付款。它也表明，旅游业现有的分销基础设施 —— NDC、Duffel 的聚合层、Stripe 的虚拟卡通道 —— 只要建好了恰当的集成，在技术上就足以支撑由智能体发起的大规模交易。

酒店与租车路径则同样清楚地展示了没建好集成时会发生什么。酒店集团、在线旅行社和租车公司多快能建起结构化的智能体接口 —— 或者会不会谈判加入某个相当于 Duffel 聚合层的东西 —— 将决定 AI 旅行智能体究竟会成为一个为它们带来收入的渠道，还是只是一笔它们眼看着订单流向别处、却还得自己承担的基础设施成本。