语音代理须以回读记录确认预订成功

语音代理说了「预订成功」，餐厅系统里却可能没有对应记录。dev.to 的这篇文章提出，把预订平台中的记录作为验收依据：核对门店、日期、当地时间、人数和联系方式，获得用户明确同意后写入，再回读比对。遇到写入超时且结果无法核实时，代理应告知尚未确认，并转人工或提供可验证的后续步骤。

目前能确认什么

作者给出的流程是：提取初步请求，按餐厅所在时区解析相对日期，检查余位，向用户复述规范化后的字段，获得明确授权，创建预订，再查询记录并比对关键字段，最后确认。

这里有个常见的分布式系统问题：请求超时，不代表写入失败。服务端可能已经保存记录，只是响应没能返回。直接重试可能重复预订，直接报成功也缺乏依据。

口头确认不能超出预订平台能够证明的状态。

如果平台区分待处理、候补、拒绝和未知，代理也必须保留这些区别。只有创建接口，却没有持久 ID、外部引用或写后查询路径的集成，无法支撑可靠的成功确认。

文章提供的是手写场景组成的合成验收材料，没有真实通话、实际预订或成功率测量，不能据此判断生产效果。

我的判断

对程序员最有用的，是把测试终点从「代理回答得对不对」推进到「记录和回答是否一致」。即便对话转录完全正确，数据库里存错日期，流程仍然失败。

实现时，模型负责理解和追问，应用代码负责字段校验与写入授权，预订平台负责最终状态。工具调用没有抛异常，也不足以判定完成。

接入前要查清三个问题：超时后能否定位原请求、如何避免重复创建、查询结果是否包含明确的预订状态。节选没有交代这些 API 细节；缺少相应能力时，产品应定位为收集预订请求，或安排人工回电。