Airbnb 的“公司大脑”要学会什么：组织经验、智能体效率与旅行信任

一、嘉宾背景

这期 The TWIML AI Podcast 访谈约 51 分钟，由主持人 Sam Charrington 对话 Airbnb 首席技术官 Ahmed Aldaleh，讨论这家连接房客与房东的平台，如何将智能体用于内部工作和旅行服务。主持人在开场介绍中提到，Ahmed 曾参与 Apple 初代 iPhone 的开发，并领导 Meta 的 Llama 团队。这些经历与他对产品、模型和工程系统的讨论相关，但本期重点并非回顾其职业生涯。

作为 Airbnb 的技术负责人，Ahmed 将公司的 AI 工作分为三个方向：提高工程生产力，在后台改善平台交易的信任与质量，以及改善房客和房东的体验。他将推进速度的提升，部分归因于既有的 AI、机器学习基础设施，以及智能体编程能力开始可用的时机。他的介绍同时涉及已部署的系统、正在测试的方案和仍待解决的问题；主持人的个人需求与双方对未来的设想，也需要与当前部署情况区分开来。

二、本期主要内容

Project Everest 是访谈的重要切入点。Ahmed 将它称为“公司大脑”：从员工使用 AI 的工作流中收集组织经验，包括任务通常如何推进、哪些惯例尚未写入文档，以及处理领域问题需要哪些上下文，再将这些经验汇入可共享的上下文。Everest 最初面向产品工程师，如今已扩展到 Airbnb 内部称为 product marketers 的产品经理群体。设计团队参与，以及覆盖全公司工作流的上下文图谱，仍是未来方向，尚未实现公司级覆盖。

在工具层，Airbnb 保留了多种选择。Ahmed 介绍，内部 AirChat 将公司的 MCP 工具接入其他智能体运行框架，让工程师选择适合自己的工具；面向产品的系统则同时使用自建框架和经过修改的开源方案。模型也采用开放与封闭并用的方式。部分客服基础设施是在外部替代方案较少时自建的；如果出现更好的开源方案，他表示愿意考虑迁移并作出贡献。这些选择反映出，公司仍在根据可用能力调整组合，并未把某个模型或框架确定为永久标准。

AI 也可能改变跨职能协作的方式。Ahmed 认为，工程、设计、产品、法务和政策人员可以围绕代码原型直接讨论实现，减少各职能依次交接不同文档和产物的过程。可运行、可讨论的原型，让各方更早面对同一个对象。变化因此不只涉及代码编写速度，也涉及不同职能何时参与、如何形成共同判断。不过，访谈没有提供这一协作方式的独立效果测量。

面向用户的部署中，客服给出了最具体的数字。Ahmed 报告，AI 已独立解决约 50% 的支持聊天，明确不包括人工客服借助 AI 完成处理的情况。但他在相邻表述中又使用了“所有工单”，因此，全部支持渠道的统计分母仍不清楚。客服智能体会说明自己的 AI 身份，回答信息问题，并提供可直接操作的卡片；聊天用户提出要求时，会被转接至人工。主持人提到的帮助中心流程，与这一支持聊天入口有所区别。

搜索部分则呈现了旅行决策的不同节奏。Ahmed 描述，有些预订会持续数周，用户反复搜索、收藏、返回查看，与同行者讨论，并协调交通和时间。他以一万美元的团体旅行说明这类决策的分量，这只是情境示例，并非平均消费统计。Sam 随即指出，另一些行程只需要尽快找到首个符合条件的房源。同属旅行搜索，任务所需的探索程度和适合交给系统的工作却可能不同。

三、核心观点：推理、例子与边界

Everest 要解决的核心问题，是让跨领域工作也能获得组织内部积累的判断依据。Ahmed 的支付案例说明，产品工程师能够生成代码，还需要理解支付系统的复杂性与监管约束，才能提交一份支付专家可以合理评审的 PR。定价规则案例则把这一要求转化为评测任务：定价工程师在工作中积累了政策和惯例之后，其他工程师能否借助这些上下文，更快、更准确地完成定价规则修改？真正需要衡量的，是领域任务的完成质量，而不是知识库增加了多少内容。

如何存储和调用这些经验，仍未定型。Ahmed 明确表示，Everest 尚处早期，数据库、Markdown 文件，以及由智能体运行框架管理的目录结构，都在探索之中。他怀疑仅靠向量搜索能否支撑全公司使用，也担心 Markdown 会把过时或原本就错误的经验保存下来，供系统反复调用。他倾向于探索混合检索，并逐步提供上下文：先让模型获得推进下一步所需的信息，再按需继续查询。这一思路关注知识如何进入决策，但访谈并未证明它已经解决知识污染或规模扩展问题。

工程提速也要接受质量约束。Ahmed 强调工程品质（craft）、缺陷比例和可靠性，并区分 PR 产出与有用产出：PR 增加，不等于实际价值增加。他因此关注路线图的交付周期能否缩短，但也承认主持人提出的问题——PR 拆分粒度、路线图范围的变化，都会影响指标的解释。目前仍没有一个完美的业务影响指标，能够直接给出 AI 的净贡献。token 消耗同样不能单独说明问题。完全不使用 AI 的员工可能需要支持；高消耗则既可能来自低效配置，也可能是在完成有价值的迁移。因此，他不赞成按 token 用量排名，也不赞成一刀切地设限。他设想使用最高思考档的前沿模型、调动所有子智能体、执行 10,000 次工具调用，是为了讨论成本与速度的排查方式，并非在描述一次已经发生的事故。

评测工具本身也需要检验。Ahmed 介绍，任务由资深工程师和跨团队参与者设计，再通过校准后的虚拟评审，比较模型的执行质量、成本与性能。他举例说，当分数集中在约 92%—93% 时，需要追问任务是否足够难、评审是否能够识别实现之间的差异，同时也不能排除模型确实已经做得足够好。分数接近，可能意味着能力接近，也可能意味着测量缺乏区分度。这个数字不是系统成功率，更不能替代对任务和评审标准的检查。

客服中的难题，则不只在于模型能否理解语言。Ahmed 描述，后台智能体可以离线、大规模地帮助识别支付争议、欺诈、质量问题和旅途中的不良体验，无须都配备面向用户的界面。但发现问题与裁决问题之间，仍有很长的距离。在房客与房东的财务争议中，双方可能追求相反的结果，平台无法直接核实现场情况，照片也可能经过 AI 修改。即使图片看起来足以支持某种判断，其真实性仍未必可核验。与此同时，平台还必须公平执行不可退款等政策。最难的多方调解仍处于研发阶段，当前模型尚不足以处理，仍需人工判断。普通信息查询的自动化能力，不能直接延伸为处理事实、利益与规则冲突的能力。

模型能够回答，也不代表用户愿意接受 AI 回答。Ahmed 口头估计，有“百分之几十”的用户，即使只是查询简单信息，也会立即要求人工；他将这一现象部分归因于心理偏好。访谈没有给出精确测量，也没有验证这一解释。不过，这仍提示了一个独立的产品问题：系统的能力与用户对入口的接受程度，需要分别观察。

搜索讨论中，用户自主权同样关键。Sam 希望个人智能体记住偏好，减少每次重新筛选的负担；Ahmed 则指出，房源图片、评论和其他上下文中，存在设施列表和显式筛选条件无法完整表达的匹配信号。但他也报告，搜索实验发现，持续通过文字来回对话可能增加摩擦。因此，Airbnb 正在测试让用户用自然语言描述目的地、同行者、出行目的和需求，同时保留多个结果供用户比较和选择。访谈没有公布实验样本或效果数据，也不足以否定所有聊天式搜索。它更具体地说明，理解需求、呈现结果和作出选择，是需要分别设计的环节。

外部智能体接入的讨论，也围绕这些环节展开。Sam 提议通过 Airbnb MCP 接口，让个人智能体筛选房源，并认为 computer use 正在削弱限制访问入口的实际作用。Ahmed 没有承诺提供 MCP 服务，而是提出应逐案判断接入后的体验。他强调，旅行信任不仅依赖图片等多模态房源展示，还涉及支付、保险、客服，以及从预订到出行之间的服务。Sam 随后澄清，他希望智能体根据偏好辅助筛选，并非自动完成预订。双方讨论留下的是筛选与后续服务如何衔接的问题，不能据此认定 Airbnb 已发布接口或承诺自动交易。

模型选择也取决于具体任务。Ahmed 认为，严格的延迟要求和较高的搜索每秒请求量（QPS），使小模型的专门化值得投入。通过后训练、强化学习环境和蒸馏，可以优先改善政策遵守等业务能力，同时接受数学等与任务无关的能力退化。他认为，这类模型在狭窄任务上可能超过前沿模型，但没有提供模型规模、延迟或性能对照数据。结尾谈到 Brian 本机上的文档与通信上下文图谱时，他也没有将个人使用经验视为组织级记忆已经可靠的证明：Everest 是否有用、扩展后是否会污染、架构是否需要重写，仍是未决问题。行程分享与协作同样存在设计难题，而客服达到 100% 自动解决率，被提出为未来挑战，并非当前成果。

四、学习与应用

建设组织知识系统，可以先从一个能够由领域专家评审的跨领域任务入手，再决定需要怎样的记忆。沿用访谈中的定价规则案例，可以比较非领域工程师获得不同上下文后，是否更准确地遵守政策、是否更容易提交可评审的 PR，以及完成任务的实际耗时。支付案例则说明，监管约束和专业评审要求也应进入评价标准。验证的重点是知识能否帮助完成工作；模型成功读取文件，并不足以证明组织经验已经正确传递。

知识维护应与检索方式一起试验。针对 Ahmed 提出的知识污染风险，可以为待积累的经验保留来源和适用条件，由领域人员核查容易变化的规则，再用同一组任务检查更新的影响。这些属于根据访谈风险推导出的实施建议，并非 Airbnb 已披露的现有机制。逐步提供上下文也可以纳入比较：先给出局部信息，再允许模型继续查询，观察它是否比一次性输入大量材料更有效。分批查询可能增加交互步骤，因此需要同时衡量信息遗漏、完成质量和耗时，不能把任何存储格式本身视为可靠性的保证。

评估 AI 的采用情况，需要把消耗、产出、质量和交付放在一起看。面对高 token 消耗，先确认任务目的：如果是在推进有价值的迁移，应结合结果判断；如果大量调用固定使用最昂贵的配置，则应检查模型选择和任务拆分是否合适。PR 吞吐量上升后，还要核实拆分粒度是否变化、缺陷和可靠性是否恶化、路线图范围是否调整。虚拟评审分数过于集中时，应先检查任务难度与评审标准，再比较模型优劣。这些诊断需要额外工作，却有助于避免把使用量直接解释成业务收益。

客服应用可以根据问题需要何种判断，分层推进。信息查询和规则明确的操作，可以参考回答与操作卡片相结合的方式；涉及双方财务利益、现场事实或可疑证据时，则需要人工判断路径。说明 AI 身份、允许用户主动转人工，也应纳入完整流程。报告自动解决率时，应交代渠道、统计分母和是否包含人工辅助，避免将 Ahmed 对支持聊天的口头数字扩展为全渠道结论。

旅行搜索可以先明确，系统承担的是辅助筛选，还是代替用户作决定。对于目的明确、流程较短的任务，可以测试用户一次表达需求后直接展示候选结果；对于多人参与、持续时间较长的旅行规划，则需要保留收藏、比较、返回查看和共同讨论的空间。尝试个人智能体接入时，应验证长期偏好如何与图片、评论共同用于筛选，并明确支付和后续支持由何处承接。筛选步骤减少，不代表用户已经授权自动预订；本期对话也不能作为 Airbnb 已提供外部 MCP 服务的依据。

小模型优化则适合边界明确、质量可评测，且延迟与调用规模确实重要的任务。先确定必须保留的业务能力，以及可以接受退化的无关能力，再比较候选模型。访谈没有提供可直接复用的性能参数，具体部署仍需本地验证。组织记忆的扩展也需要保留重新设计的余地：个人“第二大脑”的经验可以启发试验，但多人共享后的知识污染、实际效用和规模问题，仍须单独评测。

来源

• 原始节目：Airbnb Is Building a ‘Company Brain’ for AI Agents