住中服务的多轮编排是怎么设计的？

AI 在酒店住中场景里要接的往往是一串事：送水、修空调、延迟退房、叫车，往往还夹着「顺便」。多轮编排要做的，是把这些零散表达拆成可执行的任务，排好顺序，并在中途出岔子时知道往哪退。

这类场景的特点是：请求短、意图杂、时效强，且用户就在现场，等不了太久。

住中场景为什么难

第一是表达碎片化，客人常说「房间有点冷」而不说「请调高空调温度」，需要推断真实诉求；第二是任务跨部门，送物归客房、维修归工程、叫车归礼宾，一个请求可能要拆给三方；第三是容错低，送错房间或修错时间，客人当场就能感知。

所以编排的重点不在话术，而在任务状态管理：每一件事到哪一步、由谁接、超时怎么办，都要有明确记录。

意图识别与槽位

一次请求先识别意图，再抽取槽位。意图是「送物」，槽位包括房号、物品、数量、期望时间。槽位缺失时要追问，但追问要有节制，一次只问最关键的一个。

很多系统失败在追问上：连着问四个问题，客人不耐烦直接打电话。更好的做法是先做能做的，比如知道房号就先派单，物品不明再补问一句，别让流程卡在信息收集上。

两种编排结构：流程式与自主式

流程式编排把常见请求写成固定步骤，稳定、可预测，适合送物、报修这类标准化任务；自主式编排让模型自行决定调用哪个工具、按什么顺序，灵活但不可控，适合处理复合请求。

实践里多是混合：主干用流程式保证确定性，遇到流程覆盖不到的请求再交给自主式兜底，并把结果记下来，作为后续补流程的素材。扣子（Coze）这类平台适合搭前者，节点清晰、状态好追。

失败与转人工

失败分几种：识别不出意图、槽位补不齐、下游系统无响应、任务超时未完成。每种都要有对应动作，而不是统一回一句「稍后再试」。

转人工要带上下文。把已识别的问题、已确认的房号、已尝试的动作一起推给前台，前台就不用从头问一遍。腾讯元宝在生成交接摘要上比较顺手，但摘要字段要事先定好，否则推过去的仍是一段废话。

转接时还要告诉客人大概等多久。一句「已通知前台，预计五分钟内联系您」，比「正在为您转接」更能让人安心，也能减少重复催问。

上下文怎么续

住中对话常常中断：客人放下手机去开门，十分钟后回来说「刚才那个」。系统要能在多轮之间保留状态，包括未完成的任务编号和最近的意图。

状态要有过期时间。一小时前的送水请求不该在半小时后被当成新请求重复派单。设定合理的有效期，并在过期时给一句明确提示，比默默丢弃更让人安心。

跨天续接要更谨慎。客人第二天再提同一件事，多半是新需求而不是旧任务，系统应重新确认房号与诉求，别自作聪明地把昨天的单子捞出来接着办。

住中编排四问

• 意图能否从模糊表达里推断出来
• 槽位缺失时是否只追问最关键的一项
• 失败是否有分类型的处置动作
• 转人工是否带着完整上下文

四问里最后一条最影响体验，前台少问一句，客人就少等一分钟。

相关机制：问卷怎么避免引导性提问与本文的追问设计相通；政务问答的口径管理同样要处理多轮一致性；客服质检的全量覆盖可以回看这些对话的质量；内容风控的分级提供了分级处置的参照。

住中服务编排快问快答三则

• 所有请求都要走多轮吗？：不必。信息齐全的单轮请求直接派单，多轮只用在表达不完整的情形。
• 自主式编排会不会乱调用工具？：会，所以要限定可用工具集，并对高风险动作加确认。
• 客人说错房号怎么办？：派单前复述一次房号让对方确认，比送错后再改成本低得多。