生活服务类AI智能体接单前，商户侧要先打通哪四类业务数据

当生活服务类 AI 智能体开始替用户查询、比较并尝试下单时，商户真正要面对的并不是“模型会不会聊天”，而是它能不能拿到一份当下仍然有效的业务状态。门店还有没有名额、当前价格能否使用、订单处于什么履约阶段、出现问题后如何处理，这些信息只要有一类不准确，智能体就可能给出看似合理、实际无法兑现的承诺。

先判断：智能体拿到的是“商品信息”，还是“可交易状态”

传统商品接口往往只描述名称、图片、规格和基础价格，但生活服务的交易对象通常还带有时间、地点、人员、资源和服务条件。用户问“今晚能不能预约”“这个价格现在还能用吗”“下单后多久有人上门”，这些问题都不能靠静态商品资料回答。

因此，商户侧的数据准备重点，不是把更多字段塞进知识库，而是让智能体能够读取业务系统中的实时状态，并知道哪些状态可以直接用于决策，哪些状态必须再次确认。更重要的是，一次错误写入或异常变更不能永久影响后续订单，关键操作需要具备撤销、补偿或回滚路径。

第一类：库存与档期数据

到店和到家业务中的“库存”不一定是实物数量，也可能是桌位、服务人员、车辆、房间、设备或某个时间段的可预约容量。商户需要把资源总量、已占用数量、暂时锁定数量和最终可售数量区分开，不能只返回一个模糊的“有货”或“没货”。

档期数据还要能表达服务地点、可预约时间、服务时长、提前预约要求以及临时关闭等状态。对于到家服务，同一名服务人员在不同区域的可服务时间可能不同；对于到店服务，空闲名额也可能因门店、场次或服务项目而变化。

如果这一类数据缺失或延迟，典型错单是智能体告诉用户“可以预约”，但用户付款时名额已经被人工订单或其他渠道占用。更隐蔽的情况是，系统成功接单，却没有同步锁定资源，最终只能改期、拆单或人工解释。

上线前至少要确认：

• 可售资源是否有统一的唯一标识；




• 库存和档期是否能区分“可售、锁定、已占用、不可用”；




• 查询结果是否带有更新时间或有效期；




• 下单时能否再次校验并原子锁定资源；




• 取消、超时未支付和改期后，资源能否正确释放或恢复。

第二类：价格规则数据

生活服务价格很少只有一个固定数值。门店可能同时存在时段价、套餐价、会员价、渠道价、起步价、服务范围附加费和优惠使用条件。智能体如果只能读取一个“当前价格”，却拿不到适用条件，就无法判断这个价格是否真的能用于当前用户和当前订单。

价格数据应当拆成可判断的规则，而不是只保存营销文案。至少要明确适用的服务项目、门店或区域、时间范围、用户条件、数量限制、是否可叠加，以及最终结算时由谁确认价格。对于需要人工报价的服务，也应明确“预估价格”和“最终价格”的区别，避免智能体把估算值说成确定成交价。

缺少价格规则时，常见错单包括：把不可叠加的优惠组合在一起，把仅限特定时段的价格用于其他时间，或者把一个地区的到家费用套用到另一个地区。用户看到的是低价承诺，商户执行时却必须补差价或取消订单，信任成本往往高于少收的一笔费用。

价格规则上线前应检查规则是否结构化、是否有生效和失效时间、是否能返回命中的具体条件，以及订单确认时能否重新计算。规则发生调整时，还要明确已下单订单按照旧规则还是新规则处理，不能只覆盖原值而不保留变更记录。

第三类：履约状态数据

用户完成支付后，智能体还要能够回答“订单现在到哪一步”。这要求商户提供从接单、确认、备货或派单，到服务进行、完成、取消、异常处理等阶段的状态定义。每个状态都应有清晰的进入条件和可执行动作，不能让不同系统用不同含义的“处理中”互相覆盖。

履约状态最好包含订单当前状态、最近一次更新时间、预计下一步、责任方和异常原因。例如，“已接单”不等于“已安排服务”，“已派单”也不等于“服务人员已经到达”。对于存在多个子任务的订单，还要说明是整体状态还是某个门店、商品或服务环节的局部状态。

这类数据不完整时，智能体可能在商户尚未确认资源的情况下告诉用户订单已生效，也可能在服务已经延误后仍然重复承诺原定时间。到店业务中，状态错误会造成用户白跑；到家业务中，则可能出现无人接单、重复派单或配送与服务人员互相等待。

上线前要做一次状态机核对：每个状态是否有唯一含义，状态变化是否能够实时推送或主动查询，异常是否有专门编码，订单取消和退款是否会同步更新履约状态。凡是智能体可以对用户作出承诺的状态，都应当有明确的数据依据。

第四类：售后政策数据

售后不是订单完成后的附属说明，而是智能体决定“能不能接单、该不该推荐”的前置条件。不同服务项目可能有不同的取消时间、改期条件、退款方式、未履约处理和争议判定标准。若政策只存在于客服话术或长篇页面中，智能体很难稳定地把它用于交易判断。

商户应把售后政策拆解为可执行条件，例如由谁发起、在什么时间点发起、订单处于什么状态、是否已经开始服务、需要提供哪些凭证，以及系统能够执行退款、改期还是转人工处理。政策还要标记适用范围，避免把某个套餐或某家门店的规则泛化到全部订单。

缺少售后数据时，最典型的错单是智能体承诺“随时可以取消”或“无法使用可以全额退款”，但实际规则要求提前申请，或者订单已经进入不可撤销阶段。另一种风险是售后入口存在，但系统没有记录原始承诺和规则版本，发生争议后无法判断当时用户看到的到底是哪一套政策。

四类数据要同时满足三个条件

这四类数据并不是各自接入就算完成。真正影响智能体可靠性的，是它们能否同时做到以下三点。

第一是可机读。字段、枚举、时间、金额、适用范围和状态变化要有明确格式，不能把关键条件藏在图片、自然语言备注或客服经验里。自然语言可以作为展示层，但不应成为唯一判断依据。

第二是可实时。库存、档期、价格和履约状态都可能在短时间内变化。查询结果应带有更新时间或有效期限；在最终确认前，系统还需要重新校验关键状态，而不是完全依赖智能体之前读到的结果。

第三是可回滚。锁定资源、应用优惠、创建订单、触发退款或变更预约等操作，都应定义失败后的处理方式。接口超时不等于操作失败，重复请求也不应造成重复扣库存或重复退款。商户需要保留操作记录，并能通过撤销、补偿或人工介入恢复业务状态。

上线前的数据就绪清单

可以把验收重点放在一条完整交易链路上，而不是分别检查四套接口：

• 用户提出需求后，智能体能否查到符合条件的资源和档期；




• 返回的价格是否同时说明适用条件，而不是只给一个数字；




• 用户确认前，系统能否再次校验库存、档期和价格；




• 创建订单后，资源锁定、订单状态和履约任务是否一致；




• 任一环节超时或失败时，是否有明确的释放、撤销或补偿动作；




• 用户取消、改期、退款或投诉时，智能体能否读取适用政策；




• 规则调整后，已存在订单是否仍能追溯到当时的价格和售后版本；




• 无法自动判断时，是否能把完整上下文交给人工，而不是让用户重复描述。

对于本地生活商户，智能体上线的第一步通常不是扩大它能回答的问题，而是收窄它可以承诺的范围。只有当库存与档期、价格规则、履约状态、售后政策四类数据都具备可机读、可实时、可回滚的基础，智能体才适合从“推荐和问答”进一步进入预约、下单与售后流程。