Brian Chesky 谈 AI agents：它们需要操作系统，而不是又一个聊天机器人

Brian Chesky 对 AI agents 的看法，比他早先对聊天机器人的警告更为尖锐：支撑消费级 agents 的底层软件层仍然缺失。Airbnb CEO 认为，可靠的 agents 需要共享权限、更丰富的界面，以及真正的操作系统。

他的这番评论发布之际，Airbnb 刚推出首个由 AI 驱动的房源搜索功能，并承诺将在 2027 年推出更广泛的 agent。不过，Chesky 仍认为，今天的消费级 agents 无法很好地处理 Airbnb 的场景，尤其是在一次旅行需要地图、比较、身份核验、支付以及多人协作时。

这一立场让 Airbnb 站到了消费级 AI 领域“聊天机器人优先”路径的对立面。OpenAI、Meta、agent 创业公司和新兴应用平台正越来越希望让一个助手成为用户的主要界面。Chesky 认为，在基础设施尚无法保留专业产品核心功能之前，这种模式就已将专业产品压缩进一个对话窗口。

这一论点的重要性不止于旅行领域。如果他说得对，消费级 AI 的下一阶段将较少依赖单一主导型助手，而更取决于 agents、应用和操作系统能否在不牺牲控制权、上下文或信任的前提下协同运作。

Airbnb 的 AI 搜索是起点，而非终点

Airbnb 已从讨论消费级 AI，转向在旅行中最重要的决策之一里进行实际测试。

该公司在 9 月底的秋季产品更新中加入了 AI 搜索。用户可以通过自然语言文本或语音提示搜索房源，然后获得根据其明确需求定制的筛选条件。

例如，搜索家庭旅行的用户可以提到婴儿。Airbnb 随后可展示与婴儿床、游乐场、儿童读物或玩具相关的筛选项。该界面还可突出显示相关房源细节，并通过 AI 生成的摘要比较已收藏的房源。

这并非自主预订 agent。它仍是 Airbnb 现有应用内的引导式搜索体验，保留了用户熟悉的房源、筛选器、地图、心愿单和结账控件。

这种区别是有意为之。Chesky 对 TechCrunch 表示，加入 AI 搜索相对容易，而在大型市场中保护转化率则更难。根据 Chesky 此前对投资者的表态，Airbnb 平台处理的交易额超过 1,000 亿美元。

因此，该公司不能把搜索质量当成展示项目。一个看似合理却不准确的推荐，可能影响一个家庭的住宿安排、房东的收入，或涉及取消和保险规则的交易。

Airbnb 的 AI 搜索推出 展示了该公司试图如何控制这种风险。模型负责理解意图，但成熟的产品控件仍在塑造最终决策。

这种混合结构也体现了 Chesky 长期以来对基于聊天的旅行规划的反对意见。旅行者很少只想得到一个答案。人们会浏览照片、比较地点、查看地图、核查无障碍设施细节、协调日期，并与他人讨论取舍。

线性的对话会把这些比较隐藏在不断延伸的聊天记录中。视觉界面则能让多个候选项同时可见，并让用户直接操作筛选条件。

这款新搜索产品仍处于早期测试阶段。Airbnb 尚未发布独立证据，证明其能提升预订满意度或缩短搜索时间。Chesky 也曾警告，实施不当的 AI 功能可能损害转化率。

不过，这次推出创造了一个真正的验证场。Airbnb 现在可以观察基于语言的搜索在哪些方面有帮助、用户会在何处回归传统控件，以及哪些决策仍需要人工审核。

这也为公司计划于 2027 年推出的 agent 铺平了道路。Chesky 已公开承诺这一发布窗口，并将未来体验描述为比聊天机器人更丰富的产品。

因此，当前产品最好被理解为通过实际使用探索基础设施。Airbnb 正在学习旅行中的哪些环节可以变得 agentic，同时又不放弃那些让复杂选择更易理解的界面。

Brian Chesky 谈 AI agents：争夺焦点转向操作系统

Chesky 的核心主张是，消费级 agents 的构建方式像应用程序，却缺少可靠应用所需的操作系统服务。

操作系统负责协调硬件、应用、权限、文件、身份和通信。Chesky 希望为 AI agents 建立相应的基础，尽管他尚未发布相关技术规范。

在他看来，如今的公司是在 iOS、macOS 和 Windows 上部署 AI 应用，而不是构建让 agents 以一等系统组件身份运行、并遵循一致规则的环境。

当外部 agent 尝试完成 Airbnb 预订时，这一区别便显现出来。agent 所需的不只是房源数据，还可能需要已认证的身份、实时可订状态、消息功能、支付授权、位置上下文、取消政策以及多名旅行者的同意。

传统操作系统已经为应用程序调解了类似的边界。它们决定软件是否可以访问麦克风、读取文件、使用位置或通过网络通信。

消费级 AI 尚未拥有同样成熟的委托操作层。每个 agent 提供商都可以自行定义工具、审批界面、记忆行为和认证流程。每项服务随后还必须决定开放多少能力。

Chesky 将如今的竞争描述为争当“quarterback”的竞赛，也就是成为用户访问其他服务的主要助手。这一策略能让胜出的 agent 掌控发现流程和客户关系。

Airbnb 有理由抵制这种安排。如果一个通用助手选择房源、总结房源详情并完成交易，Airbnb 就可能沦为另一家公司界面背后不可见的供应商。

不过，Chesky 仍将外部 agents 视为潜在的获客渠道。在 Airbnb 2 月的财报电话会议上，他表示，聊天机器人带来的流量转化率高于 Google 流量，尽管 Airbnb 并未提供详细方法论。

这形成了本文的核心张力。Airbnb 希望 agents 能发现并使用其市场平台，但不希望一个通用助手将 Airbnb 压缩成一个数据库。

该公司的答案是互操作性，即不同软件系统可以通过既定规则交换请求与能力。Chesky 表示，Airbnb 预计将通过 Model Context Protocol，即 MCP，连接 agents。

MCP 是一项用于将 AI 应用与工具及数据源连接起来的标准。它可帮助 agent 发现外部系统所提供的能力，但协议本身并不能构成操作系统。

完整的 agent 平台还需要身份、支付控制、持久化权限、审计记录、恢复机制，以及清晰的责任边界。它必须知道谁授权了某项操作，以及当执行中途失败时应如何处理。

以团体预订为例。一个人可能让 agent 寻找房屋，另一个人则控制支付方式。第三名旅行者可能否决地点，而房东也可能要求经过验证的身份。

在 agents 之间传递房源数据只解决了第一层问题。系统还必须保留授权关系、解释冲突，并防止某位参与者的助手越权行事。

Chesky 的 agent 访谈 将此定位为行业层面的问题。他认为，Apple、Google 或其他平台提供商需要支持这一更深层的转变。

这一观察也限制了 Airbnb 的掌控力。该公司可以让其服务更适配 agents，但无法独立为手机、助手、支付提供商和竞争市场建立系统级的权限规则。

丰富界面挑战通用聊天机器人模式

真正的竞争并非 Airbnb 对阵某一家 AI 公司，而是专业化界面对“一个对话能取代所有应用程序”这一理念的挑战。

当用户有明确需求并想要简洁结果时，聊天效果很好。“查找我的预订”或“解释这条取消规则”都能自然地融入对话。

旅行发现则不同。人们常常在尚未确定目的地、房源类型或行程时开始搜索。他们的偏好是在浏览过程中逐渐形成的。

一张照片就能改变决定。房源在地图上的位置、距离交通站点的远近，或卧室与共享空间之间的关系，也同样如此。

这些选择很难压缩进按顺序呈现的文本。用户需要同时看到各种替代方案，并直接操作筛选标准。

协作又增加了一层复杂性。Chesky 将所需的体验称为“multiplayer AI”，即多人可以在规划过程中与同一个智能系统协作。

大多数个人助手都从个人账户、私密上下文和一段对话历史出发。团体旅行则需要共享状态，同时不泄露某位参与者告诉 agent 的所有内容。

一个有用的团体 agent 必须能区分私密偏好与集体决定，还必须显示谁批准了日期、预算和付款承诺。

Airbnb 计划在 Chesky 10 月采访后的三到六个月内探索这些协作界面。这一时间表使多人规划成为检验其论点最明确的近期测试之一。

Airbnb 并非唯一质疑纯聊天软件的公司。Wabi 推广过一种生成式界面：当用户需要特定控件时，这些界面会即时出现。其创始人认为，人们仍希望点击、滚动和检查软件，而不是持续输入文字。

生成式界面是由 AI 为当前任务组装的屏幕，而非完全预先固定的界面。它们承诺带来灵活性，但也可能使控件变得更不可预测。

若结账按钮在不同会话中改变位置或含义，用户可能会感到困惑。生成的披露内容也可能遗漏经过设计的流程始终会呈现的信息。

Chesky 预计，确定性组件和生成式组件将共存。确定性界面预先设计、行为可预测，而生成式元素则响应用户当前的请求。

Airbnb 的新搜索正说明了这种组合。AI 将灵活的请求转化为相关选项，但市场平台仍呈现易于识别的筛选器、卡片、地图和预订步骤。

这一模式为通用聊天机器人提供了务实的替代方案。agent 可以理解意图，而不必成为唯一可见的界面。

Airbnb 计划中的宏观 agent 将把这种方法扩展至发现、客户服务和其他服务领域。该公司已经在客服中使用专门的 AI，并预计语音将变得更加重要。

5 月，Chesky 表示，Airbnb 的客户支持 AI 无需升级处理即可解决 40% 的问题，高于 2026 年早些时候约三分之一的水平。该公司还表示，其工程师在第一季度产出的代码中，有 60% 由 AI 生成。

这些数据是公司声明，而非独立的性能评估。不过，它们仍显示了 Airbnb 在何处发现了更明确的价值：受约束的客服工作流和受监督的软件开发。

Airbnb 扩大 前沿模型访问权限的举措进一步印证了这种分化。该公司在工程、搜索、欺诈检测、客服和保险理赔等领域使用 OpenAI 模型。

Airbnb 表示，其开发团队交付的功能数量比一年前增加了约 80%。这一说法并未将 AI 单独归为唯一原因，但表明该公司将模型视作生产基础设施。

消费者自主性仍是更难实现的目标。在工程师监督下编写代码，与花费旅行者资金或挑选陌生住所并不是一回事。

以聊天机器人为先的模式，往往将界面视为围绕能力日益增强的模型搭建的临时支架。Chesky 的模式则将界面设计视为系统智能的一部分。

这种差异将决定哪些公司能够保留与客户的直接关系。若专业应用仍然不可或缺，通用智能体就需要可靠的交接机制和内嵌控制。

如果聊天已足够满足需求，市场平台即使仍提供库存和交易，也可能失去对界面的掌控。Airbnb 当前的策略旨在从智能体流量中获益，同时避免接受这种结果。

互操作性本身无法解决信任问题

如果 AI 智能体操作系统连接服务的速度快于其界定责任的速度，它就会失败。

互操作性之所以吸引人，是因为它能减少一次性集成。Airbnb 智能体可以与日历智能体、航空公司服务、支付提供商以及另一位旅行者的助手进行通信。

然而，每一项连接都会带来授权问题。旅行智能体能读取用户的完整日历，还是只能读取已声明的休假日期？它能预订房源，还是还能提交付款？

操作系统的类比在这里很有帮助。现代移动平台要求应用请求特定权限，用户也可以在之后撤销这些权限。

智能体需要类似的控制机制，但任务更为困难，因为其行为会跨越多个服务展开。一条指令就可能触发搜索、协商、身份验证、支付和消息传递。

因此，权限必须同时附着于数据和操作。知道旅行者护照上的姓名，并不意味着有权向每一项服务分享身份证明文件。

智能体还需要可审计的记录。用户应能看到它请求了什么、哪个服务作出了响应、哪些信息发生了流转，以及哪项承诺最终具有约束力。

这对旅行尤为重要，因为情况会发生变化。航班延误可能影响入住时间；房东可能取消预订。智能体或许会尝试重新预订，但用户未必批准了不同的街区或取消政策。

恢复机制是另一个尚未解决的问题。传统操作系统可以终止失败进程或恢复文件；智能体却无法总是撤销付款、消息或预订。

平台必须知道哪些操作可逆，以及何时应请求确认。它还需要建立处理智能体之间，或智能体与人类参与者之间争议的程序。

Airbnb 的市场平台还拥有自身的信任层。Chesky 表示，该平台拥有 2 亿个经过验证的身份，且 90% 的预订客人会发送消息。

他还表示，Airbnb 已处理超过 1000 亿美元的付款。这些数字说明，可见的应用只是产品的一部分。

其余部分包括反欺诈控制、房东工具、多语言支持、保险流程、身份系统和市场规则。外部智能体必须在不削弱这些系统的前提下与之交互。

Airbnb 的财报电话会议记录将这套基础设施视为公司抵御 AI 去中介化的防线。这种防线可信，但并非永久有效。

有能力的智能体平台可以随着时间推移将复杂服务标准化。在线旅行社此前已将航空公司和酒店的搜索与预订标准化，即使供应商各自拥有不同系统。

尚未回答的问题是谁来定义标准。Apple 和 Google 控制主要移动操作系统，而 OpenAI 和其他助手提供商则希望掌控对话层。

Airbnb 等市场平台掌握专业库存、交易历史和运营规则。理论上，用户掌握同意权，尽管界面设计会强烈影响这种同意如何表达。

Chesky 的提议并未解决这场权力博弈。AI 原生操作系统既可能保护专业应用，也可能让其所有者对访问和分发拥有更大的控制权。

MCP 也面临同样的模糊性。开放标准可以降低集成成本，但具体实现仍决定哪些工具会出现、哪些请求能获得批准。

随着智能体获得更多权限，安全问题也更加棘手。提示注入、被操纵的房源、遭入侵的工具或误导性内容，都可能改变智能体的行为方向。

仅提供选项建议的旅行智能体带来的风险处于一个层级。获授权向房东发送消息并花费资金的智能体，则带来高得多的风险。

可靠的智能体必须将外部内容视为不可信输入。它们还需要在为任务收集的信息与用户授权的指令之间设置严格边界。

对于知识工作者而言，当智能体连接笔记、电子邮件、日历和文档时，同样的原则也适用。当上下文可用时，个人知识库才会发挥价值，但访问权限应始终经过审慎授权且可追溯。

Chesky 对基础设施缺失的判断颇具说服力。但他尚未证明，操作系统模式能够让平台所有者、应用和用户围绕一套权限框架达成一致。

在此之前，“对智能体友好”将描述一组集成，而非可靠的消费者计算环境。

三个信号将检验 Airbnb 的智能体论点是否成立

下一个考验并非 Airbnb 是否会添加更多 AI 标签，而是该公司能否将 Chesky 的架构论点转化为可观察的产品行为。

第一个信号是 Airbnb 的多人协作规划界面。Chesky 在 10 月采访后预计，协作式 AI 将在三到六个月内推出。

一项可信的发布应让多位旅行者贡献偏好、比较房源并批准共同决策。它还应将私密上下文与群组可见信息区分开来。

如果 Airbnb 推出这些控制机制且用户实际使用，它将强化其对抗纯聊天式规划的论点。延期或仅对群聊进行轻微改造，则会削弱这一论点。

第二个信号是 2027 年的 Airbnb 智能体。Chesky 对时间表作出了不同寻常的明确表态，向行业受众表示公司将在明年推出其智能体。

这一项 2027 年承诺为观察者提供了具体基准。关键问题将是该智能体会获得何种权限。

能提供推荐的搜索助手代表渐进式进展。能够协调搜索、群组批准、消息、服务与预订的智能体，则将检验更广泛的操作系统论点。

Airbnb 还必须展示该智能体如何处理错误。清晰的批准机制、交易日志、恢复路径和人工升级处理，将比精致的演示更重要。

第三个信号是 Airbnb 之外更深层的互操作性。Chesky 预计，未来的宏观智能体将能通过 MCP 等方式与其他智能体通信。

证据应包括与具有实际意义服务之间可正常运作的交接，而不只是一个返回房源信息的连接器。身份、日历、付款和行程变更才是困难层。

如果智能体能够在这些边界之间携带经用户批准的上下文，那么 Brian Chesky 对 AI 智能体的看法将更像一项实施计划，而非批评。

如果 Apple、Google 或某家主要 AI 提供商率先推出通用的权限与执行框架，Airbnb 就必须适应他人的平台规则。

还有一项商业指标值得关注。Airbnb 表示，聊天机器人带来的引荐流量转化率已高于 Google 流量，但尚未公布足够的数据来判断其规模或持久性。

来自智能体的预订持续增长，将支持 Chesky 的观点：外部助手能够扩大用户发现范围。直接互动减少则意味着，这些助手正在夺取 Airbnb 希望保留的用户关系。

Airbnb 的做法刻意保持谨慎，但谨慎并不能消除竞争压力。通用智能体正在进步，界面初创公司正在试验，旅行平台也在打造自己的助手。

该公司如今必须证明，其更丰富的界面比单纯对话更有用，同时又不会比它所取代的体验更复杂。

Brian Chesky 对 AI 智能体的讨论，最终为每一个消费者平台提出了一个实际问题：当软件开始代表用户行动时，什么必须保持可见？

关注 Airbnb 的协作规划工具、其 2027 年智能体的权限范围，以及首批严肃的跨智能体交易。这些发布将揭示，AI 操作系统是否正在形成，还是当下的应用只是在获得更聪明的助手。