Heathrow Hallie：机场客服智能体如何接住旅客高峰

先把能查证的事实摆清楚，再谈判断。据 Salesforce 于 2025 年 6 月 11 日发布的新闻稿，以及其官方客户案例页面，英国 Heathrow 机场在 Salesforce Agentforce 平台上上线了一个面向旅客的服务智能体，取名 Hallie。它目前的主入口是 WhatsApp：旅客在对话框里问路、问登机口、问航站楼里的设施位置、问自己那趟航班的状态，Hallie 直接作答。Salesforce 把它描述为一个『数字旅行同伴』，并给出了扩展路线——后续将从 WhatsApp 延伸到航站楼内的自助终端，以及 Heathrow 官网与移动端。

Hallie 背后连着一批系统，这一点比它的对话界面更关键。据同一批材料与行业媒体 diginomica 的报道，它调用 Service Cloud 里的知识库、Data Cloud 里的旅客数据，以及一组实时 API——其中包括机场地图、航班状态数据，还有来自航空公司的第三方供应商数据。Heathrow 的知识底座本身是多年沉淀的结果：CRM、Rewards 会员计划、机场 Wi-Fi、数字化预订这些触点上的数据被统一汇入 Salesforce Data Cloud，构成一个共享的旅客视图。为了让 Hallie 有东西可答，Heathrow 的呼叫中心团队亲手上传并整理了约 800 篇知识文章，并参与了它的训练。这个细节值得单独记下：一个智能体在旅客眼里显得『懂』，很大程度上是内容工程与数据整合的产物，是那 800 篇文章与统一旅客视图的产物，模型本身的强弱只占其中很小一部分。据 Heathrow 披露，机场早在 2023 年就开始测试 Salesforce 的生成式与智能体产品，Hallie 面向旅客的正式露面是在 2025 年，前后隔着约两年的打磨。

再看公开的数字，以及它们各自能站住的边界。Salesforce 披露的核心指标是 90%：约九成会话可以在不转人工的情况下被 Hallie 解决，换句话说，需要人介入的会话只占大约一成，有的材料把这个人工比例说到 5%。其余几个数字性质就不一样了。Heathrow『预期』把数字触点的效率提升最多 40%，把复杂案例的实时聊天时长缩短约 30 秒，把案例摘要的准确率做到『预期的』95%，并让达成解决所需的会话轮次下降超过 50%。这里必须做边界标注：90% 是厂商口径下宣称的已实现结果，而 40%、95%、30 秒、50% 更接近目标或预期，全部属于 Salesforce 与 Heathrow 的自我披露，未经独立审计，也没有第三方复核过它们的分母与统计窗口。另据 Dealroom 转述的一组数据，Heathrow 的电话咨询占比在上线后约一年内从 70% 降到 10%——这是二手转述，缺原始运营口径，只能当作方向性参考，不能当作精确指标。Heathrow 方面出面表态的是营销与数字总监 Peter Burns，他把 Agentforce 描述为『那个把你接进整个生态的人性化界面』。还有一层商业动机值得记下：Salesforce 的客户案例把这套部署放在『agent-first experiences』和『增长收入』的框架里叙述，也就是说 Heathrow 的目标并不止于降低客服成本，还包括在旅客旅程中承接引导、推荐与转化。这提醒我们，Hallie 的效率数字背后，还叠着一层商业化诉求，读这些指标时要把这一层动机一并纳入考量。最后补一个体量背景：Heathrow 每年吞吐约 8,300 万至 8,400 万旅客，是英国最大的机场。这个量级意味着，任何客服机制的真正压力测试，都发生在极端规模上，平峰再顺，也说明不了它在需求高峰时的成色。

很多人看到 Hallie，第一反应是『机场也上了个聊天机器人』。这个直觉抓错了重点，因此值得先把重点掰正。

机场客服真正难的地方，在于需求本身极度不平稳。平峰时段旅客问登机口这类问题，一个写得好的静态 FAQ 页面就能应付，构不成挑战。绝大多数时间里，客服通道波澜不惊，问询稀稀拉拉、类型简单；可一旦航班延误、天气恶化、航站楼系统故障，或者机场部分乃至全面关闭，咨询量会在几十分钟里翻上数倍，而且问题类型会同时变复杂——此刻旅客要问的，是『我的航班取消了怎么改签』『我的行李现在在哪』『你们管不管我今晚住哪』这类随实时状态变化的问题。需求的高度、宽度和难度在同一时刻一起抬升，这才是机场客服的真正考题。

所以理解 Hallie，正确的框架是把机场客服的处理容量看成一条水管。传统的人工坐席，是一条口径固定的硬管：无论上游来多少水，管子就那么粗，一旦峰值超过口径就会溢出，表现为电话打不进、在线排长队、投诉在事后堆积。这种溢出还有一个隐蔽的代价：它往往发生在旅客情绪最紧张、最需要被安抚的时刻，于是一次运营中断很容易顺势升级成一次品牌事件。旅客智能体如果真的成立，它的意义在于把这条硬管换成一条能伸缩的软管：平峰时用得着的容量不多，异常来临时容量能跟着需求一起放大，把突发的咨询峰值吸收下去，而不至于让旅客又整批地涌回本就人手吃紧的人工班组。这套容量在峰值时能不能撑住，才是这个案例值得盯的地方，也是它区别于一次普通聊天机器人升级的分界。

这里要防一个常见的误读，就是把这种伸缩理解成『反正是软件，加机器就能无限扩容』。它并不无限。智能体的容量上限，受制于它背后那些实时接口在高峰时的吞吐、受制于大模型推理的并发成本、也受制于知识与数据覆盖到的问题类型。它能弹性放大的，是那些可被数据回答的标准化咨询；对于知识与数据都没覆盖到的问题，再多的算力也变不出答案。所以这种伸缩性是有条件、有边界的，谈论它的价值时，得把这些条件一并说清楚，否则很容易滑向一种对智能体的过度乐观。

从这个角度看，Hallie 里真正称得上分水岭的地方，是它被要求接进真实的运营数据：航班状态、机场地图、会员身份，以及原则上可以延伸到改签的航司数据。会用自然语言对话的机器人早已遍地都是，那一层不构成门槛。一个只会背 800 篇知识文章的机器人，平峰能答得像模像样，异常时段却会立刻失灵，因为旅客在那种时刻要问的，恰恰是那些随实时状态分秒变化的东西。把运营数据绑进来，才是让处理容量在高峰时还输得出正确答案的前提。而 Heathrow 那 8,000 多万的年吞吐量意味着，它的每一次异常，都是在极端规模上给这套容量做压力测试。

把 Hallie 拆开看，它的价值几乎全押在数据绑定的深度上，对话是否流畅反倒是次要的。据 Salesforce 与 diginomica 的描述，Hallie 的数据面大致可以分成三层，理解这三层如何耦合，就能判断这套系统在峰值下会不会塌。

第一层是静态知识：呼叫中心整理的约 800 篇文章，覆盖设施位置、指引流程、常见问答，这一层回答的是『不随时间变的事』——某个休息室在哪、某项服务怎么办理。第二层是实时状态：航班状态数据、机场地图与实时寻路，回答的是『此刻的事』——你的航班现在改在几号登机口、有没有延误、从你当前的位置怎么走过去。第三层是旅客身份与上下文：来自 CRM、Rewards 会员、Wi-Fi 登录、数字化预订并汇入 Data Cloud 的画像，让 Hallie 原则上知道自己正在跟谁说话、这位旅客的行程和会员权益是什么。

这三层的耦合方式，直接决定系统在高峰下的命运。只挂着第一层的机器人，本质是一个会话式 FAQ，平峰好用，异常时段无能为力；把第二层、第三层接上，它才可能在延误潮里，对一个具体旅客给出具体的、当下的、可执行的答案，跳出放之四海皆准的模板话术。值得注意的是，这三层里最难维护的往往是中间那层实时状态。知识文章写好了就相对稳定，会员画像也主要随注册和消费缓慢累积；唯独航班状态与地图寻路是分秒刷新的活数据，它依赖机场自有系统和航司第三方接口在高峰时仍能稳定供数。一旦某个上游接口在异常高峰下超时或返回滞后的状态，Hallie 给出的答案就会从『准确』悄悄退化成『看起来准确但已过时』，而旅客很难当场察觉。这也是为什么，把运营数据接进来只是第一步，真正的工程难点在于让这些接口在最需要它们的时刻仍然不掉链子。Salesforce 还提到 Hallie 能生成可操作的案例摘要，其『预期』准确率为 95%，并借此把复杂案例的实时聊天缩短约 30 秒。这类指标指向的是人机协作的另一种形态：Hallie 未必亲自解决最复杂的案例，但它把散落的上下文整理成一份摘要递给人工坐席，让人的时间集中花在真正需要判断的环节，省去反复向旅客核对基本信息的那段工夫。

Heathrow 走到这一步是花了时间的。据其披露，机场在 2023 年就开始测试 Salesforce 的生成式与智能体产品，Hallie 面向旅客的正式上线在 2025 年，背后是一段跨越多个 Salesforce 云、以数据统一为地基的多年数字化改造。这条时间线本身就是一个信号：能在高峰时输出正确答案的智能体，其前置成本主要花在把分散的运营与旅客数据接通、清洗、维护上，挑一个更强的基础模型只是次要变量。把这层数据底座做扎实的团队，它的智能体在异常时段才不至于露馅——这大概是这个案例给同行最朴素也最容易被忽略的一课。

90% 会话不转人工，是这个案例里最抢眼的一个数字。但对运营负责人来说，更该盯的问题是它的另一半：剩下那约 10%，到底是哪 10%。

有一种可能是健康的：被留给人工的，恰好是最复杂、最需要人来判断、也最集中在异常时段的那批咨询。若真如此，Hallie 承接了平峰与简单问询的日常水量，把坐席的注意力腾出来，专门处理改签、赔付、特殊协助这类高价值、高情绪、高个性化的场景，人机分工是各得其所的。还有一种可能则相反：平峰时那 90% 解决得相当顺，可一旦异常来临、咨询量暴涨，Hallie 处理不了的比例陡然上升，大量会话在最需要它顶上的时刻被推回人工，而此时人工班组同样被高峰淹没，整套容量又缩回固定的老样子。这两种情形，在平峰的月度报表上看起来可能相差无几，差别只在峰值时刻才会暴露出来。

这里还藏着一个容量弹性的关键变量：人工那一端本身是不伸缩的。呼叫中心的坐席数量在短时间内基本固定，招不来、也培训不出临时的熟练工。这意味着，如果 Hallie 在高峰时把大量它处理不了的会话原样丢回人工，那点伸缩性其实是假的——它只是把溢出从机器人这端推到了人工那端，总容量并没有变大。真正让容量弹性成立的，是 Hallie 在高峰时不仅要多接住简单会话，还要对那些它无法独立完成的复杂会话做有效的预处理，让每一位坐席在单位时间里能处理更多的人。案例摘要正是这种预处理的一种形态。

Salesforce 披露的案例摘要能力，暗示 Heathrow 至少在往第一种分工靠：Hallie 把上下文整理成摘要交给人，理论上让那 10% 的人工处理更快、更省事，等于间接放大了人工端的有效容量。这是个积极的信号。但要看清全貌，公开材料留下了一个关键缺口——它没有给出任何异常时段的分时数据。我们不知道在一场延误潮里，Hallie 的解决率是否仍守得住 90%，还是会一路滑落；不知道它转人工的会话，是不是正好在人工也顶不住的那几个小时里集中爆发。这个缺口恰恰是判断这套系统究竟是运营层还是聊天框的分界线。值得补充的是，转人工本身并不是失败，恰恰相反，一个懂得在合适时机干净转人工的智能体，比一个死撑着不转、硬答到底的智能体要成熟得多。真正的问题落在转人工的曲线长什么样：如果它在平峰平稳、在异常高峰陡升，说明系统在最关键的时刻恰好失去了承载力；如果它在异常高峰依然平稳，才说明容量真的跟着需求一起长大了。这条曲线，才是判断这套系统成色的核心证据，可惜它至今不在任何公开材料里。

一个诚实的说法是：现有数字证明了 Hallie 在常态下能挡住绝大部分问询，这本身有价值；但机场客服真正的考题从来在异常高峰里，常态答得再好也回答不了这个问题。

要检验一套客服容量是否真能伸缩，最好的样本是一场真实的需求高峰。Heathrow 恰好在近期提供了一个——尽管公开材料并没有把它和 Hallie 直接挂钩，这一点必须先说清楚。

据 CNBC 与公开记录，2025 年 3 月 20 日深夜至 21 日，位于 Hayes 的 North Hyde 变电站起火，切断了机场供电，Heathrow 全天关闭约 16 小时。这是它十五年来首次完全停摆，超过 1,000 架次航班被取消或打乱，受影响的旅客行程据不同口径估计在 20 万到 27 万之间。可以想象，那一夜涌向机场各个客服触点的咨询量，远不是平峰能类比的：几十万人几乎在同一时间要问同一类高度紧急、又高度个性化的问题——我的航班到底怎么办、我今晚人在哪儿过夜、我的钱和行李怎么处理。这正是需求的高度、宽度、难度在同一瞬间一起冲顶的极端情形。

这类事件，恰恰是前面那套容量伸缩逻辑的终极压力测试。一个健康的旅客智能体应当在这种时刻把容量放大数倍，把其中可标准化的部分——航班已取消的确认、改签入口的引导、酒店与地面交通的信息——批量吸收下去，只把真正需要人来判断和安抚的留给坐席。而一个仅仅接了 API 的聊天框，会在这种时刻原地卡住：知识库里没有为这场特定中断预先写好的文章，实时数据接口在高峰下可能超时或返回陈旧状态，旅客最终拿到的还是一段套话，然后全部涌向电话和柜台。这两种系统在平峰几乎无从分辨，只有在这样的夜晚才见真章。

值得留意的是这场停摆的性质：它是一次此前十五年都没发生过的黑天鹅式全域中断，远超出常规延误可以事先演练的范畴。对客服智能体来说，这类事件最刁钻的地方在于，知识库里根本不可能预先备好针对『整个机场断电关闭 16 小时』的标准答案，因为没人料到会这样。旅客要问的很多问题，是这套系统在设计时压根没见过的。此时能救场的，不是背得多熟的知识文章，而是它能否实时读到『航班已取消』这个状态、能否把旅客准确地引导到官方的改签与安置通道，以及在自己确实答不上来时能否体面地承认边界、干净地转接。若它反过来硬编一段听起来合理却是错的话，把幻觉当自信，这种时刻造成的伤害，比没有智能体还大。

需要再次强调边界：公开材料并未披露 Hallie 在这场 3 月事件中的实际表现，它究竟接住了多少、又在哪里滑落，我们无从得知；甚至无法确认 Hallie 在那个时间点是否已经全面投用。但这场关闭精确地画出了这个案例真正的考题所在：不在 8,300 万旅客平峰时的日常问路，就在这样的 16 小时里——容量能不能跟着需求峰值一起长出来。把这次停摆当作参照系，读者对 90% 这个数字会有更清醒的估价：它是一个在风平浪静时测出来的成绩，而机场客服的真正战场从来在风浪里。

把这些数字放回它们各自能站住的范围里，是读懂这个案例的关键一步。营销口径下的高百分比最容易被整段引用，也最容易被误读。

先看 90% 的会话解决率。它能证明的是：在 Heathrow 的常态问询分布下，Hallie 挡住了绝大多数会话。它不能证明的是：这个比例在延误潮、天气事件或机场部分关闭时是否还守得住。厂商披露的解决率通常按会话总量来统计，而异常时段的会话在全年总量里占比并不大——即便峰值时刻的解决率明显下滑，摊进整年的平均数仍然可以很好看。这是所有『平均解决率』类指标的结构性盲点：它天然对占比小、却最要命的那部分会话不敏感。

再看另外几个数字。40% 的数字触点效率提升、95% 的案例摘要准确率、30 秒的聊天缩短、超过 50% 的会话轮次下降——它们的性质更弱。多数是『预期』或目标，来自 Salesforce 与 Heathrow 的联合口径，未经独立审计，也没有第三方复核过它们的分母与统计窗口。电话占比从 70% 降到 10% 的说法则是二手转述，缺原始运营口径，我们甚至无法确定它衡量的是不是同一批旅客、同一类咨询、同一个时间区间。这些都不意味着数字造假，只意味着此刻它们只能被当作厂商与客户未经独立审计的自我披露来读，还够不上被审计过的事实这一档。

还有一层容易被好看数字盖住的风险，值得单独点出。把咨询从电话赶到 WhatsApp，效率类指标会立刻变好看，但如果被赶走的旅客其实没得到解决、只是放弃了，或者转身跑到社交媒体上公开抱怨，那么『数字触点效率』的提升就只是把问题从一个通道挪到了另一个通道，并没有真的把它解决掉。电话占比从 70% 降到 10% 这个数字尤其要小心：它衡量的只是通道分布的变化，与问题被解决的比例是两回事。旅客不再打电话，可能是因为 Hallie 替他解决了，也可能只是因为他放弃了电话这个通道、改用了别的方式表达不满。同一个数字，两种截然相反的因果，报表上看不出来。要判断到底是哪一种，靠解决率是不够的，得看异常时段的旅客满意度、二次联系率与转人工率，而这三项，恰恰是目前完全没有公开的部分。缺了它们，90% 与 70%→10% 都只是未经独立审计的入口指标，谈不上是终局的证据。

需要公允地补一句：这些披露上的空白，在企业营销语境里相当常见，并不构成对 Heathrow 或 Salesforce 诚信的指控。厂商发布的本就是营销材料，它有权先讲能讲的那部分。问题只在于，作为读者和潜在的效仿者，我们不能把营销口径当成审计结论来引用，尤其不能拿平峰的解决率去回答一个关于异常高峰的问题。

设想另一种做法，用来对照 Hallie 的路线，能把这条分水岭看得更清楚。

假设一家机场或航司同样上了个对话智能体，但它把力气几乎全花在平峰体验上：知识库整理得完整，语气亲切，问路、问设施、问值机流程都答得顺滑，上线首个季度的满意度和解决率报表都相当好看。它没有做的，是把实时航班状态、会员上下文、改签入口这些运营数据真正接进去，也没有为异常场景做过容量放大与服务降级的设计。从演示和早期数据看，它和 Hallie 几乎难以区分。

但这套系统会在两个地方相继失败。第一个是异常时段：延误一旦来临，旅客问的全是随实时状态变化的问题，而它答不上来，只能给模板，解决率断崖式下跌，会话整批转人工，此刻人工也同样被淹，旅客体验反而比没上智能体时更糟，因为他们先在机器人那里白白耗了一轮。第二个是可信度上的连锁反应：旅客一旦在最需要帮助的时刻被它敷衍过一次，就不再信任它，下一次连平峰的简单问题也宁愿直接打电话——前面辛苦攒下的数字触点迁移，会被这一次糟糕的异常体验反噬掉一大截。

这条对照线说明了一件事：平峰满意度是一个危险的成功指标。它最容易做上去，也最容易让人误以为系统已经成熟。真正区分『运营层智能体』和『高级 FAQ』的那道分水岭，只在异常时段才会显形，而项目上线初期往往还没赶上一场像样的高峰，于是决策者容易在错误的信号上过早庆功。

更微妙的是，这两条路线在预算表上的差异也会误导人。只优化平峰的方案，前期投入低、上线快、演示效果立竿见影，季度汇报很好交代；而绑定运营数据的方案，前期要花大量时间去接通、清洗、维护那些分散在不同系统里的实时数据，短期内几乎看不到亮眼的对话演示，容易在立项阶段就被砍掉。换句话说，正确的路线在商业上恰恰是更难被批准的那一条，因为它的回报要等到第一场真正的高峰才兑现，而高峰什么时候来，没人能预约。Hallie 把赌注押在运营数据的绑定上，方向是对的；但方向对不等于已经验证。验证只能来自它在真实高峰里的分时表现，而这部分，至今没有公开。

把镜头转向新加坡樟宜、区域航空公司与东南亚旅游业，Hallie 值得抄的和不值得抄的，需要分开来说。

值得抄的是那条容量伸缩的思路，而不是那块 WhatsApp 聊天界面。樟宜同样是高吞吐、多系统、强实时的场景，东南亚还额外叠加了几个放大异常频率的因素：季风季节的天气延误、区域内密集而互相牵连的短途航线、以及多语言、多国籍的旅客结构。对这些玩家，正确的立项问题不该是『我们要不要也做个旅客聊天机器人』，而应该是『当一场季风延误把咨询量在半小时里推高数倍时，我们的处理容量能不能跟着放大，而且给出的答案仍然绑定真实的航班、地图、会员与改签数据』。这个问题一旦摆正，前置投入的方向就清楚了——它应该压在数据整合与异常降级设计上，像 Heathrow 那样，先用几年时间把 CRM、会员、预订、实时状态接通，再去谈对话体验的打磨。多语言在东南亚是一道硬门槛，绝非可有可无的附加项：一个只在英语平峰跑得好的智能体，在区域旅客的真实高峰里，约等于没有上线。

但不要把它当成一种必然趋势来推广，这里需要克制。旅客智能体会不会真正成为运营层，取决于它在异常高峰里的实测表现，而这类证据眼下还很稀薄。所以更负责任的做法，是给这个前景配上一个明确的反向信号，作为随时准备推翻自己的触发条件。

该盯的反向信号很具体：如果一套旅客智能体上线后，平峰问答的满意度与解决率一路走高，可每逢真实的延误、天气或机场中断事件，异常时段的转人工率不降反升、二次联系率同步上扬、社交媒体上的投诉集中爆发——那就说明它只是把常态问询搬上了一个更顺手的对话框，并没有真正成为能吸收需求峰值的运营层。触发条件是下一次区域性的大面积延误；要盯的信号，是那几个小时里的分时转人工率与旅客满意度，季度平均报表上那几个营销口径的百分比说明不了问题。这个信号一旦出现，再好看的年度指标都该被重新解读：它至多证明聊天框做得好，还不足以证明容量真的能伸缩。反过来，如果在一场真正的高峰里，异常时段的解决率没有崩、转人工率没有暴涨、投诉没有失控，那才是这套容量确实能伸缩的第一份硬证据；在那之前，一切都还只是方向正确的假设。

对区域市场的决策者，这意味着一条务实的行动建议：不要用平峰的演示效果去立项和验收，而要在合同和内部指标里，明确写入异常时段的分时可观测口径——延误事件下的分时解决率、分时转人工率、二次联系率与旅客满意度。把这些指标提前定义好、埋点好，等下一场区域性延误真正到来时，才有据可依地判断，自己买到的究竟是一条能在风浪里撑住的运营层水管，还是一个只在风平浪静时好看的对话框。这个判断几乎没有捷径，只能等一场真正的高峰来验。在立项之初就把这套可观测口径埋进系统的团队，等高峰过后，才有据可依地谈论自己的智能体到底成没成；没埋的团队，届时手上只有一堆平峰时测出的营销口径数字，和一个无从回答的问题。