AI 结账需要什么：价格、库存、配送、退货

晚上十点，一家做户外家具的出海团队收到一条下单失败通知：美国买家让助手买一张折叠露营桌，报价页写着现货、两天送达，确认时却只退回一个笼统的错误。第二天追问才知道，那个邮编属于偏远地区，运费要另加；仓库里真正可售的只有一件展示样品。买家没有再试，助手已经换了一家。

AI 结账不是把购物车交给 agent，而是在几十秒内连续回答四个问题：这个地址到手多少钱、现在能不能锁货、哪天能到、不想要了怎么退；任何一项只能给出“大概”，agent 就会在确认前退出。

结账是三次数据交换，不是一次页面跳转

Agent 不会“打开结账页点下一步”。它发三次请求：报价、锁货、确认。三次之间可能隔几十秒，也可能因超时重试，所以每一次都要能独立成立。

报价问的是“这个地址、这个数量、这个时间，到手多少”；锁货问的是“这批货能不能先留给我”；确认问的是“订单成不成立，承诺是什么”。三次各要一组字段，任何一次拿不到确定值，前面都作废，重试只会放大错误。

这也是它和“页面能下单”的区别。页面允许人边看边猜：运费结账时算，到货写 3–7 天，退货点进政策页慢慢读。Agent 没有这个耐心，也没有这个权限，它只把算得清的方案报给买家。三次交换怎么和协议、支付、履约对齐，见Agentic Commerce 的 readiness里的五层图，本文只处理其中数据这一层。

四个字段族，缺一项就断

把四族字段当成页面元素，是这类项目最常见的起点错误。它们在 agent 眼里是四个独立问题，各有各的失败方式。

数据族	agent 问的那句	响应里必须带	拿不到时它会怎么做
价格	这个地址、这个数量，到手多少钱	单价、币种、税、运费、折扣与有效期	加一句“以商家页面为准”，换品牌
库存	现在能不能锁住这一件	可售数量、状态、预留窗口	退回“可能无货”，放弃下单
配送	哪一天能到，送不送得到	邮编可达性、服务等级、到达区间	只报“标准配送”，不给日期
退货	不想要了怎么办	窗口、退货运费谁付、拆封条件、最终销售标记	报告“退货政策不明”，把风险推给买家

价格与库存最常被当成页面字段，其实是交易字段：改一次价，页面、结构化数据、feed 与结账四处都要跟着动。配送与退货最常被当成政策文案，其实是决策字段：买家问“能不能退”，agent 要的是一个可比较的条件，不是一段免责声明。

时效是四族字段之外的第五个变量。库存有效期以你能锁住的时长为上限，报价有效期以你能兑现价格的时长为上限。写着十分钟有效、缓存却挂一小时，等于每六次里就有一次报出过期价。

异常状态才是主战场

一次成功下单证明不了什么，异常状态的处理方式才决定 agent 敢不敢继续把订单交给你。

三种失败最常见。静默修改：价格变了直接按新价下单，库存不够就换型号。笼统报错：所有问题共用一个失败码，agent 分不清是地址还是库存，只能整体重试或放弃。假装成功：缺货时返回“备货中”，页面照常可下单。

反例值得写清楚：某品牌的库存接口在缺货时返回成功，前台照常可下单，后台排产要四周。Agent 记了一次成交，买家四周后取消，退款、差评和客服成本都落在品牌头上。这种“看起来成功”的失败，比明确报错贵得多。

方向是让错误可解释、可行动。每个异常返回一个稳定代码，再附一个能立刻执行的替代：拆单、转预订、换承运商、换自提点、明确不可售。Agent 拿到替代方案才有机会把订单救回来；只拿到一个 500，它只会换一家。退货尤其如此，条件与窗口要能被机器读到，配送与退货政策不只是一页给人看的说明。

五步：把三次交换变成可测的契约

步骤	做什么	谁来做	怎么算过
1 画时刻表	列出报价、锁货、确认各要哪些字段，标出谁依赖谁	产品与工程	每个字段能指到一个系统
2 定单源与时效	四族字段由同一服务给出，有效期写进契约	工程	改价或改库存后，下一次请求就变
3 写异常字典	代码、含义、可选动作、谁兜底	工程与客服	每个代码都有对应文案与替代方案
4 沙盒演练	二十个 SKU 乘边缘场景：偏远邮编、最后一件、折扣到期	工程与增长	失败能被脚本稳定复现
5 上线监控	按失败原因分组看转化与退款	增长	能说出最贵的那个失败原因

第 3 步决定项目能不能收敛。异常字典不是错误码列表，而是一份承诺：出现这个状态时，系统会给出哪个下一步。

第 4 步是唯一能提前证伪的环节。演练脚本要像 agent 一样先报价、再锁货、最后确认，并在中间改一次库存或等过报价有效期。跑不出失败，通常不是系统稳，而是脚本太客气。失败原因的分组口径，可以和AI 可见度基线共用一套记录表。

示例：一张折叠桌的三次请求

示例（假设场景，不含真实品牌与数据）。

09:14，报价返回 129 USD，现货，两天送达。09:15，agent 锁货，接口回“已预留”，但预留的是目录库存，不是可售库存。09:16，确认，地址在偏远邮编，运费要加 38，报价里没有这个字段，接口直接报错。09:17，重试两次，还是同一个通用错误，agent 放弃，改买竞品。

复盘三条：报价没算目的地附加费；锁货锁的是账面数字；错误没有代码，也没有替代动作。

改法对应三条。报价按邮编算运费，并把有效期写进响应；库存只返回可售数量与预留窗口，锁不到就明确说锁不到；异常分成三类——地址不可达、价格已变、数量不足——每类附一个可执行动作；确认失败时给一条人工结账链接，而不是空白页。

验收不看单次成功，看同一批 SKU 改动前后的脚本结果：失败原因有没有从“通用错误”收敛到具体类别，对应的退款是否下降。

边界：什么时候不该建这套接口

第一，agent 下单还只占很小比例。先把商品页与 feed 修对，接口投入按订单量摊，别为了一个还没发生的渠道重建报价系统。

第二，成交集中在平台内。平台接口与规则不由你定，自建接口没有入口，能改的是后台库存、履约指标和退货设置。

第三，定制、报价、B2B 批发。没有固定价就不要假装即时报价，给“提交需求、人工确认、有效期”三步，比编一个会被引用的数字安全。

第四，支付、分期与保修。这些属于信任层，另有交易信任要处理；本文只管四族数据，别把支付失败也算进数据问题。

第五，退货口径不是工程能定的。各地撤回权、最终销售、跨境退运成本要法务与市场确认，接口的职责是如实返回，不是替业务做决定。

第六，闪购与高频动态定价。报价有效期短到没有意义时，明确写“价格浮动”，不要给一个会被原样引用的假精确值。

这个月先做一件事：挑十个在售 SKU，用脚本按“报价、锁货、确认”跑一遍，把四族字段里答不出的那一项标出来；先修出现最多的那个异常状态，给它一个代码和一个替代动作，再接进监控。这条线归在技术底座主题页。