一句话要拆成四件事：腾讯云 ADP 的酒店 Agent 只公开了两项线上数字

一句话要拆成四件事：腾讯云 ADP 的酒店 Agent 只公开了两项线上数字

腾讯云 ADP 团队在 2026 年 9 月 11 日记录了酒店智能体怎么进经营现场。ADP（Agent Development Platform）是腾讯云的智能体开发平台。这篇不是基准榜，而是三条落地链路和一组护栏：华住会把一句话拆成四个并发任务，尚美数智按角色分权限，美住美宿用 Text2SQL 查经营数。全文只给出两项实测，而且没有分母。

先承认两道断点，再选范式

酒店被写成服务密集、系统密集、角色密集。系统已经有 PMS、OTA、会员、客控和内部 OA，新问题是入口仍然散。住客一句「送两把牙刷、空调调到 24 度、明早几点退房」，后面是政策知识库、配送机器人、客房 IoT、工单和房态。店长问昨日客源，要接 PMS、经营看板、会员和渠道。区域管理者看售卡、营收和异常门店，还要过组织权限、品牌层级和数据口径。

断点有两道。住客端入口割裂：前台大量时间耗在退房、早餐楼层、WiFi 这类重复问答上，真实诉求又经常是复合句。关键词客服能查出退房规则，驱动不了机器人和温控。管理端数据和权限复杂：总部看制度、审批和办事入口，店长看客源、房态、SOP 和竞对房价，区域看跨品牌大盘。一个对话框承接不了不同岗位的权限。

对应的做法被写成四句：RAG 接高频问答，工作流编排多系统办理，角色化 Agent 适配总部、区域和门店，Text2SQL 把经营数据变成可追问的分析。

华住会：四个子任务并发，两项自述成绩

华住会的 24 小时数字管家做在华住会 APP 里，面向会员和在店住客，用可视化工作流、多系统 API 和向量 RAG 接咨询和客需。例子是：「送两把牙刷，空调调到 24 度，明早几点退房？」复合意图节点把它拆成四个并发子任务：

1. 知识检索：从政策库取退房时间、早餐规则和配套服务。
2. 实物派单：调配送机器人或房态工单，生成牙刷任务。
3. 设备调控：对接客房 IoT，把空调目标设为 24℃。
4. 结果聚合：汇总各接口状态，回一条确认。

文中的确认句是：牙刷已安排机器人配送，订单含双早，最晚 14:00 退房，空调已调至 24℃。这是场景示例，不是从日志里抽出的唯一标准答案。

实测只写了两句：该场景首 Token 可控制在 5 秒内，常见客需准确率达 95% 以上。原文没有给出样本量、标注人、什么叫「常见客需」，也没有给出失败时的分布。前台压力缓解同样没有工时对照。

尚美数智：5000 家店按角色切开，不共用一个入口

青岛尚美数智覆盖雅高瑞享、兰欧、品睿、尚客优等 20 个品牌、5000 余家开业酒店。三级矩阵是尚小美、生意通、城区通。

尚小美面向集团员工，接企业微信、内部 OA 和人事制度库。问差旅报销时，除了制度，还展示「直接上级、部门预算负责人、财务 BP」的审批链，并在消息卡片下给出办理链接。

生意通面向店长。问「昨日客源分布」时，连接门店 PMS 和数据看板，输出直销会员、线下会员、分销渠道的客房间数和占比。每天清晨抓周边竞对房价并推预警，辅助调价，不是直接改价。

城区通面向区域管理者。问今日售卡时，按组织层级穿透，输出售卡金额、总卡数、百房售卡比、出单门店数，并把 0 售卡门店高亮，方便下发巡店。这三级都没有单独的准确率。

美住美宿：能查数，但缺数据时必须说要人工复核

美住美宿把 Text2SQL 嵌进产品后台。原先店长要从 PMS 和 OTA 导出 Excel 再做透视表。接入后可以直接问上周各渠道营收占比、差评集中在哪些房型和服务环节，以及本周 OCC（入住率）、ADR（平均房价）、RevPAR（每间可售房收入）为什么变化。系统把问题解析成 SQL，查经营库，再生成营收、评论和市场热度三类报告。

动态调价有置信度护栏：外部竞对数据或历史因子缺失时，必须提示「需人工复核」，不许输出失真的定价指令。原文没有给出护栏触发率，也没有给出 SQL 执行正确率。

场景和范式要配对，不能一套架构打全部

文中的对照表把场景、范式和组件绑在一起：

• 规则、设施、早餐政策：标准智能体，LLM 加 RAG，用向量库、关键词检索和人设。案例是华住会。
• 一句话送物、温控、退房：工作流，做意图拆解、API 调度和异步聚合。案例仍是华住会。
• 总部、门店、区域分层：Multi-Agent 和权限空间，做角色隔离和企业微信接入。案例是尚美数智。
• 经营指标即问即查：工作流加数据库连接器，做 Text2SQL、SQL 校验和图表卡片。案例是美住美宿和尚美数智。
• 竞对房价早间推送：定时任务和消息通道，用 Cron 和移动端推送。案例是尚美数智。
• 涉外公寓多语种接待：多语言模型，做语种识别、多语言检索和拒答。案例只写成「某酒旅与物业管理平台」，没有点名，也没有语种准确率。

推进顺序和三道护栏

建议是小步、先内后外。单店和中小连锁先做前台高频问答（WiFi、退房、停车）和每日经营简报，因为指标好量化、对接短。大型连锁先梳理角色，先做店长查数和总部审批导办，再做区域大盘。SaaS 厂商优先把 Text2SQL 报表嵌进已有后台。

三道护栏是这篇的质量约束：

• 知识护栏：退改、押金、会员权益必须限定在检索范围内。没检索到就拒答或转人工，不许模型自由发挥。
• 执行护栏：调设备网关和送物机器人时要有超时重试和状态回显。接口失败就降级成线下前台工单。
• 经营护栏：调价、留房量等收益建议必须人工确认，避免自动改价。

文末的 Hy4 preview、新客 5000 万 Token 和 1M 上下文是试用资源，不是评测结果，不能和 5 秒、95% 放在同一张成绩单里。

读的时候只保留原文给得出的边界：95% 以上和 5 秒没有样本量和统计口径；5000 余家、20 个品牌是尚美的门店规模，不是 5000 个 Agent 都测过；0 售卡高亮和审批链是功能描述；调价建议在数据缺失时必须人工复核。

出处：腾讯云 ADP，腾讯云 ADP 团队，腾讯云 ADP 落地酒店全链路：用智能体贯通 5000+ 门店，2026-09-11，https://adp.tencent.com/zh/blog/tencent-cloud-adp-hotel-ai-agent-practice