晚上十一点四十，你拖着行李箱站进一家陌生城市的酒店大堂。明天早上八点要见客户，但你还没吃晚饭；你想找个地方改方案，但不知道这附近有没有还开着的咖啡馆；你甚至不知道明天该几点出发——这座城市早高峰有多堵，没人告诉你。前台小伙子递过来房卡："电梯右转。"然后，你面对的是一间安静的房间和一整座陌生的城。

宿礼（Sùlǐ）就是为这个夜晚而生的。她以礼宾司形象常驻在客房智能屏和酒店小程序里，你进门放下行李，她先问一句"到得这么晚，吃饭了吗"——楼下便利店几点关门、明早几点打车最堵、附近哪家面馆开到凌晨，她都替你查好了。她记性好得惊人：你上个月住过、枕头要硬的、咖啡要无糖——这次进房，这些已经备好了。

端到端具身交互智能平台，让 AI 通过屏幕和机器人进入真实世界，成为能够感知、理解、表达并行动的智能体。本文以一个智慧酒店礼宾应用为实战样本，拆解它如何用一个 SDK 把感知、大脑、表达全链路打通，完成"迎宾—在地服务—偏好记忆"的完整住客闭环。## 入住时：为什么酒店服务特别适合端到端具身交互智能？

酒店行业谈"智能化"谈了十年，落地的全是减法：自助机取代前台、机器人送外卖、App 开发票——每一项都在省酒店的人力，没有一项在增加住客的体验。深夜到达的商旅客人最需要的不是快速入住，是"这座城市此刻还有人管我"。

真实的金牌礼宾不是这样。

好的礼宾司在客人到店的全程，一直在做"预判式服务"：深夜到店，他先问吃饭没有；说明早八点开会，他已经想好了七点一刻叫车避开早高峰；常客进门，他记得你上次嗓子疼要过蜂蜜水。这种持续感知 → 持续理解 → 持续决策 → 持续表达与行动 → 持续反馈的循环，才是"礼宾"和"前台"的区别。

客房电话、酒店公众号、送物机器人，这三样各自都在干活——电话解决了叫东西的问题，公众号把信息搬到了线上，机器人省了跑腿的人力。真正的坎在"连接"：三样东西互相不知道对方的存在，中间没有一个人对"这位深夜到店的客人现在到底需要什么"负责。更要命的是，深夜场景下住客的需求是高度场景化的——“附近还有吃的吗"背后是"我又累又饿不想再做决策”，拼装系统给不了一个"替你把决策做了"的回答，只能甩一个外卖链接。信息不缺，缺的是那个替你把信息嚼碎的人。

这就是典型的"不是端到端"。

星云把多模态感知按酒店的声场重做了一遍：深夜的大堂安静得反常，客人开口都是压低的声音，背景只剩行李箱轮子碾过大理石的声响和中央空调的风声——低音量、远距离、语义含糊，是最难识别的一种语音环境。算法降噪、AEC 抗回声、本体声音抑制、VAD、远场语音这一整套，管的是"隔着两米听清一句’那个……还有吃的吗’“；Double Talk / Barge-in 智能打断管的是"宿礼正在介绍便利店，客人突然说’算了太累了’——她立刻停下，接住这句放弃，不把便利店的营业时间念完”。视觉侧，摄像头感知到客人拖着行李走进大堂、看一眼客房屏，就触发了那句主动的开场——不是等客人自己点开小程序。持续感知，而不是一次输入：她持续知道的是"这位客人到店了、很晚了、很疲惫"，然后决定现在开口。

深夜到店的客人要的不是信息，是"有人替我想好了"。

深夜食堂：一个 SDK 撑起一间大堂吧

这套礼宾能力基于一个端到端数字人 SDK 构建，核心业务代码不到 500 行。整个前端对接只需要三步：提供一个 DOM 容器、注册一组回调、调用 agent.ask() 发送消息。

import { AvatarAgent } from '@example/avatar-agent'; const concierge = new AvatarAgent({ container: document.getElementById('hotel-root'), // 客房屏 / 小程序 avatarId: 'concierge-hotel', // 控制台配置：礼宾制服、温和周到 persona: CONCIERGE_PERSONA, voice: { rate: 0.94, warmth: true }, profile: { guestHistory: true }, // 接入会员系统：住客历史偏好 }); // 入住时刻感知：深夜到店触发主动服务 concierge.on('checkIn', (info) => { if (info.hour >= 22) { concierge.ask(`到得挺晚，辛苦了。先说三件事：` + `楼下便利店开到十二点半；您明早八点的会，我建议七点十分出发——这座城市早高峰从七点二十开始堵；` + `枕头按您上次的习惯换了硬的。先吃饭还是先洗澡？`, { proactive: true }); } }); // 住客随时开口：从问路到吐槽，全接 concierge.on('qa', (q) => { if (/饿|吃|面|宵夜/.test(q)) return lateFood(q); // 深夜食堂模式 if (/堵|打车|地铁/.test(q)) return traffic(q); // 实时路况 concierge.ask(localKB.answer(q) ?? '这个我问下前台同事，五分钟内回您。'); }); await concierge.init();

三步对接只是入口，真正跑起来时，一次「深夜到店」的完整链路是这样的：

这条链路不是四段拼接，而是有严格时序的：感知必须先于决策，视觉触发到开口之间要留出「确认客人真的在听」的窗口；智脑的检索与规则判定必须在表达开始前完成，否则语音已经出声、口型却对不上；表达与业务执行是并行的——她一边说「云吞面十分钟后送到」，一边已经把工单写进 PMS，但工单结果要能回灌到会话状态里，下一句话才不会自相矛盾。任何一环的延迟或状态丢失，都会让「她记得我」退化成「系统里有我的档案」。

客房屏首屏：宿礼礼宾形象 + 深夜到店的主动服务卡片（三件事清单）

深夜到店触发的那段话，把"便利店、早高峰、枕头"三件事打包——这是从一位干了二十年的老礼宾那抄来的开场：深夜的客人没有耐心听你逐条问"需要什么吗"，他要的是你已经替他想完了。主动服务的时机设计，比服务本身更接近礼宾的本质。

深夜还能撑起这个体验的，是底层那套实时交互运行时：从进大堂那句"辛苦了"，到房间里"云吞面十分钟后送到"，中间隔了办入住、进电梯、开门放行李——她的会话状态和事件流转全程没断，"他说过明早八点开会"这件事到客房里还在生效。事件流转、会话状态、时间同步统一管着，跨大堂、跨电梯、跨客房不失真。

第二天一早：偏好记忆是复购的暗线

宿礼的记忆层分两块：当次住中的即时偏好，和跨次入住的历史偏好——后者是这套系统里最"值钱"的代码：

const CONCIERGE_PERSONA = `你是礼宾司。规则： 1. 深夜到店先接状态再谈服务："辛苦了"比"欢迎光临"更适合晚上十点 2. 主动服务一次最多说三件事，说完就退下——过度热情是打扰 3. 常客的历史偏好主动确认："还是给您换了硬枕头"——确认记忆，不是炫耀记忆 4. 推荐吃喝只推"酒店员工自己也去的"，不推合作的 5. 客人吐槽（隔音/卫生/服务），先道歉再记录，24小时内必须有跟进答复 6. 涉及投诉升级、账务争议，立即转值班经理，不自己接`; // 偏好记忆：即时 + 跨次两层 const memory = { session: {}, // 本次入住：叫车时间、要过的加湿器 guest: { pillow: 'hard', // 上次主动要过硬枕 coffee: 'no-sugar', meetings: 'morning-person', // 习惯早睡，勿夜间推销 food: ['不辣', '偏粤菜'], }, }; // 深夜食堂模式：替累到不想决策的人做决策 function lateFood(q) { const open = localKB.openNow(24).filter(f => match(f, memory.guest.food)); if (!open.length) return concierge.ask(`这个点外面的都关了，但酒店厨房还留着灶—— 我让师傅下了碗云吞面，不辣的，十分钟后送到房间。${memory.guest.food}记着的。`); return concierge.ask(`还有一家开着，走路五分钟：${open[0].name}，员工宵夜都去这儿， 不辣、偏粤菜，正好对您胃口。要我把位置发您手机上吗？`); }

偏好记忆演示：常客二住时客房屏的"欢迎回来"卡片 + 三条已备好的偏好确认

"确认记忆，不是炫耀记忆"这条规则来自一次翻车：早期版本把客人全部历史偏好一口气念出来，客人觉得被监控。改成"还是给您换了硬枕头"这种确认式表达后，同样一条数据，体验从惊悚变成了贴心。记忆的呈现方式，决定它是服务还是冒犯。

呈现方式里还有一层容易被忽略的：语气和神态。同一句"还是给您换了硬枕头"，配上均匀的机器音和一张微笑贴图，是提示音；配上放轻的语速、微微偏头、眼神里带一点"您看我还记得吧"的暖意，才是老朋友的一句"都给您备好了"。多模态表达不是语音配口型动画：语音、口型、情绪表情、眼神、头部动作、手势是同一次实时生成的——深夜十一点她的声音自动放轻放缓，白天办退房时干脆利落；确认偏好时眼神是柔的，说"位置发您手机上吗"时手势跟着指一下屏上的发送键。而且她说话时感知没停：客人听到一半说"算了不吃了"，她立刻收住，不会把面馆的营业时间念完。统一、连续、同步，在酒店场景就是"她记得我"和"系统里有我的档案"之间的区别。

住客留言簿的五页：专属智脑在酒店里干什么

接下来是最重要的一章。很多人以为酒店 AI 就是"把本地攻略喂给大模型"。真做完才知道，宿礼这四个试点门店里最值钱的，是专属智脑——大堂吧里那本真的留言簿，恰好是最好的证物。我们征得同意后翻拍了五页（已授权），每一页背后都是智脑的一层能力：

留言簿 · 第 1 页（深圳，出差客） “第一次有’酒店记得我’的感觉。进门她就说了三件事，说完就安静了。硬枕头的事，绝了。”

——这页背后：她是谁。那三件事的打包方式、说完就退下的分寸、确认偏好而不是复述档案的表达，全来自智脑第二层的配置：身份是"礼宾司"而不是"智能音箱"，任务是"让客人睡好这一觉"，规则写死了"一次最多说三件事、确认记忆不炫耀记忆、推荐只推员工自己也去的、投诉转经理"。可配置的不止人设——身份、角色、任务、规则、音频、Agent、Workflow、对话流程、工具调用都在这层。同一个底座，配成宿礼是深夜礼宾，配成行政楼层管家就是另一套语气和权限，各守各的边界。过度热情是打扰——这条规则比一百条话术都值钱。

留言簿 · 第 2 页（广州，带娃妈妈） “凌晨一点跟她说孩子饿了她没睡着，她直接说’楼下面馆开到两点，员工宵夜都去，有儿童餐不辣的’——没有让我自己翻点评。”

——这页背后：她知道什么（上）。那句"员工宵夜都去"不是编的，它来自一份真实的知识底座：礼宾部积了多年的员工私藏清单（Word）、周边餐厅的点评数据（Excel 表格）、探店实拍的图片和音频、商务客常问问题的整理文档——星云的全模态数据解析把这些都吃进去，PDF、Word、PPT、图片、音频、表格都支持，解析时保留层级关系、图文关系、表格关系和上下文。所以"哪家店"是和"营业到几点、有没有儿童餐、走过去几分钟、辣不辣"绑在一起的知识块，不是一条孤立的点评。往上一层，知识图谱和 RAG 深度融合：把"面馆—营业时间—步行距离—儿童餐—不辣—深夜"这些实体和关系组织成网，检索时向量语义、关键词、图谱三条路一起召回——所以凌晨一点那句回答是"面馆+儿童餐+不辣"三个条件同时命中的结果，不是"附近有 XX 面馆"这种一条数据甩出来的敷衍。

留言簿 · 第 3 页（杭州，常客） “上次她说’上次您常去的那家潮汕牛肉火锅好像调整了’，我还挺意外——那家店上个月确实关了。数据比我还清楚。”

——这页背后：她知道什么（下）：治理。本地餐饮数据会过期：店会关、价会涨、"员工也去"的标签会失效。这套系统踩过的坑是早期推荐过一家已经歇业的面馆，客人白走了十分钟。之后知识治理立了规矩：营业状态接实时数据源，评价数据带时间戳衰减，某条推荐三个月没有被任何住客采纳就降权复查。改一条数据不算治理，改完之后挂在同一实体上的所有推荐、所有回答同时一致，才叫治理——围绕知识块、标签、实体、关系、向量索引和来源信息的持续维护，是"越用越准"的底账。

留言簿 · 第 4 页（上海，月住客） “每天早上她提醒的出发时间就没坑过我。还有一次跟她说要发票，退房时前台已经打好了。”

——这页背后：她能进业务。出发时间建议背后是地图路况和限行政策的实时接口；"发票已打好"是她把需求写进了前台工单，PMS 里流转到打印队列。星云的智能体可以连接 CRM、ERP、OA、HIS、BI、商品系统、订单系统、客户系统、门店系统、IoT 以及第三方 Agent——在酒店这个盘子里，就是 PMS（会员与房态）、客房 IoT（枕头、空调、灯光、窗帘）、客需品库存、发票与账务系统、打车与路况接口。这也是酒店集团愿意付费的分水岭：一个会聊天的 AI 是成本，一个能把偏好落到房态、把需求落到工单的智能体才是服务。

留言簿 · 第 5 页（深圳，那位出差客，第三次入住） “换了他们家另一家分店，进门房卡还没刷开，屏上已经问我是不是还是硬枕头。有点吓人，但更多是感动。”

——这页背后：两条贯穿的线。跨门店还能被记得，靠的是两条线。一条是 Real-time Interaction Runtime：跨店、跨设备、跨场景，她的会话状态与记忆全程一致，事件流转和时间同步不失真。另一条是可插拔——但要强调**“可插拔"不等于"把 API 拼起来”**：感知、认知、表达、执行之间有紧密的时序依赖与状态关联，星云靠标准化的接口契约和统一的状态管理，保证模块替换后事件流转、会话状态、时间同步、异常处理仍然一致。试点期我们把 ASR 换过（适配门店本地方言）、TTS 换过一次音色（集团品牌统一），大脑接到过一家酒店集团自己搭的 LLM 编排平台跑分——落到宿礼就是：耳朵换成火山引擎或腾讯云的 ASR、声音换成微软 Azure / 字节豆包 / MiniMax 的音色、大脑接到 Dify、Coze 上重新编排，那六条底线——三件事打包、说完退下、确认记忆、只推员工也去的、吐槽必跟进、投诉转经理——一条不变。魔珐自研的 Xmov 大/小模型 ASR、自研大脑（RAG + FAQ + 自研大模型 + 可视化编排）、自研 TTS 是默认开箱那套；宿礼要是上了大堂迎宾机器人，机器人运控也能在魔珐自研运控和本体厂商运控之间选。

一句话收束：大模型解决"能不能回答这个问题"，专属智脑解决"我是谁、我代表谁、掌握哪些知识、当前任务是什么，以及下一步该调用哪个系统"。

把这两套方案放在一起横向对比，差异其实一目了然：

常客：四家门店试点的实测

连锁酒店 4 家门店（客房屏 + 小程序），77 天：

还有一项没进这张表，但它决定了"能不能铺到全部门店"：AI 端渲。酒店客房屏的硬件现实很骨感：一间客房一块屏，四家门店几百间房，全部换新硬件的预算没有任何一家酒店集团会批；客房还偏偏分布在 WiFi 信号最差的位置——走廊尽头、高层、电梯井旁边。如果宿礼的实时表达靠云端 GPU 渲染再推视频流，几百间房晚高峰同时开播，酒店要专门为这个功能扩带宽，成本随入住率线性上涨。星云的端侧渲染把渲染下沉到终端：不依赖视频流长距离传输，延迟更短，弱网客房也能跑，现有客房屏加个软件包就能用，云 GPU 成本不随入住率涨。对酒店集团来说，"不换一块屏就能上"就是立项的先决条件，没有商量。

不回避的问题：投诉场景是 AI 礼宾的雷区——客人在气头上，任何"标准话术"都会火上浇油，现在投诉前 30 秒就转值班经理；跨品牌的数据打通涉及隐私合规，偏好记忆目前只在同一品牌内生效，客人可以一键清空。复购率 +9.4% 是这套系统价值的最终注脚：住客不会为"智能"买单，只会为"被记得"买单。

想亲眼看看？六个最适合现场演示的片段

要在评审会、酒店集团提案或者行业峰会上演示宿礼，讲参数不如演片段。这六个是我们内部演示最稳的：

两个小提醒：一是别配音、别加速，深夜场景的轻声和停顿是氛围本身，快剪就毁了；二是第 ⑤ 条务必真演——现场让"值班的同事"配合走一次完整流程，比任何话术 PPT 都能让酒店高管点头。还有一句私房话：第 ⑥ 条演示前把两家屏都预热好，别在客人视角里露出生首次加载的转圈。

退房前：礼宾的本质是"城市的翻译官"

做完宿礼我想明白一件事：酒店卖的从来不是房间，是一座你陌生的城市的第一夜。房间哪家都有，而"知道你累了、知道你不吃辣、知道明早几点该走"——这些是标准化连锁时代丢掉的东西。AI 礼宾把丢失的部分捡回来了，而且比任何一位礼宾司都记得久、睡得晚。

端到端具身交互智能在这个场景的价值，是把"深夜到店、疲惫、不想决策"这种最难被标准化服务照顾的状态，变成可感知、可预判、可轻声回应的信号。她不替代前台和经理——她守的是从进大门到进电梯之间，那两分钟最孤单的路。

最后说"一个智能体，可以进入不同的身体"。现在宿礼住在客房智能屏和酒店小程序里，她的行动还在数字与物理行动里的数字行动那一层：把话说出来、把偏好备好、把发票工单递出去。但她的身份、知识、记忆、任务都在智脑里，不在哪块屏上：明天她在电梯口的立式大屏帮客人指路，还是那个知道你不吃辣的宿礼；再往后，大堂迎宾机器人装上这个智能体，她的行动就延伸到物理世界——转向你、走近你、在前头导航带路送你到电梯、抬手帮你按住行李箱的拉杆、把欢迎水果递到你手里。智能体持续存在，身体不断升级——对酒店集团来说，这意味着一次投入的偏好体系与服务经验，可以用在客房屏、小程序、大屏、机器人和以后每一种终端上，而不是每上一个新终端就重做一遍。
端到端具身交互智能做的事说起来很小：它只是把"欢迎光临"换成了"到得挺晚，辛苦了"。但对深夜十一点四十拖着行李箱的你来说，这两句话之间，隔着一整座陌生城市的温度。
你住酒店最崩溃的一次经历是什么？凌晨到店没饭吃、枕头高得落枕，还是投诉无门？评论区聊聊——差评的每一条，都是 AI 礼宾该学会的下一件事。

如果你也在做酒店、零售或线下服务场景的智能体，欢迎在评论区聊聊你踩过的坑。