做电商的都懂一个场景：平时订单少，一个人盯得住；一到大促或者爆单，改地址、催发货、要退款的消息就堆成一片。真正麻烦的不是这些请求本身，而是它们散落在聊天、后台、邮件三个地方，没人能保证每一条都被处理到。
这篇讲怎么用 OpenClaw 把「订单这笔单子」的异常识别和售后处置接过来。先把边界说清楚：AI Agent 客服怎么搭 讲的是对话侧——怎么跟客户聊、怎么转人工；客服质检 管的是回复质量；自动记账与对账 管的是钱。这一篇管的是中间那段：一笔订单从下到完成之间，状态出了偏差该怎么办、谁来办、办完怎么留痕。
一、先划边界：哪些能自动，哪些必须人
动手之前先把这条线画出来，能省掉后面 80% 的麻烦。判断标准其实就一条：这个动作做错了，能不能低成本撤回？
- 能自动（可逆、低影响）：查订单状态、推送物流信息、按规则打标签、生成待办、把异常单归到对应队列。这些做错了改一下就行。
- 待确认（涉及客户利益）：改收货地址、改配送方式、同意退款、补发/换货。这类必须有人点头，或者至少在动作前告知客户。
- 必须人（不可逆、涉及金额）：确认具体退款金额、处理投诉定性、涉及赔付的判定。AI 可以提供材料，但决定得人来做。
把这条线画清楚，后面所有的分流规则才有地方落。
二、订单要从哪几个字段看起
Agent 判断异常，靠的是字段。先把订单的标准字段列出来，缺的补齐，这是整个流程的地基：
- 身份类：订单号、买家标识、下单渠道。
- 商品类：SKU、数量、单价、实付金额。
- 履约类：收货人、联系电话、收货地址、配送方式。
- 状态类：当前状态、状态更新时间、支付状态。
- 时间类：下单时间、承诺发货时间、承诺送达时间。
- 轨迹类：物流单号、物流节点、最近的异常标记。
两个细节特别值得注意：一是时间戳一定要统一时区，不然后面所有超时判断都会错；二是地址要结构化（省市区/详细地址/邮编分开存），不然后面做地址校验和物流对接全是坑。
三、五类最常见的异常与分流
实际跑下来，90% 的麻烦集中在五类，逐类定规则比一锅炖强得多：
- 地址问题。地址不完整、明显笔误、超区不配送。这类可逆，可以自动补全建议 + 发一条确认给客户，客户不回复就不动。
- 库存问题。下单后缺货、部分缺货。要能自动给出「等货 / 换同款 / 退款」三个选项，而不是让客服每次手写。
- 改单改址。客户改地址、改配送时间。这个动作只在未发货前允许，发货后要走物流改址流程，两条路千万别混。
- 退款退换。要区分「未发货退款」（通常直接走）和「已发货退货」（要等签收、要验货），路径完全不同。
- 超时未发货。承诺时间内没发货，这是最容易变成投诉的一类，必须提前预警而不是等客户来问。
四、三档处置与转人工
分流之后要有明确的出口，别让单子悬着：
- 自动处理：规则明确、动作可逆的，直接办完并给客户一条通知。
- 待确认：生成一条带上下文的待办，谁处理、什么时候前处理完都写清楚。
- 转人工：涉及金额争议、投诉、多次反复的，直接进人工队列。转人工队列怎么设 里那条「带上优先级和时限」的原则在这里尤其重要——退款类单子挂久了，客户情绪是会上来的。
还有一个容易被忽略的点：同一个人短时间内反复提交同一类请求，要能识别出来并合并，别让客户等三份一模一样的回复。
五、高危动作要卡在确认之后
改地址和同意退款，是售后里风险最高的两个动作——一个可能把货寄丢，一个可能被恶意利用。三条硬要求：
- 动作前必须让客户可见。Agent 要先把「改到哪个地址、退多少钱」明明白白展示出来，客户确认了才执行。这和 客户可见动作怎么管 里讲的原则完全一致：凡是客户能感知到的动作，都必须有最后一道确认。
- 高频或大额要二次审批。同一天改址超过几次、退款金额超过多少，自动升级到人工复核，别让一条自动化路径变成被刷的入口。
- 退款金额只能从系统取，不能由模型算。金额是硬数据，让模型「理解」金额等于埋雷。
六、超时预警：提前一点，投诉少一半
售后里性价比最高的一件事，就是在客户来问之前先动。做法是按承诺时限设几档提前量：
- 距离承诺发货还有半天 → 提醒仓库或供应商。
- 已经超时 → 自动生成一条安抚通知，说明原因和预计时间，而不是等客户来骂。
- 物流长时间不更新 → 主动触发查件，必要时提前准备补发方案。
这套「按剩余时间分档预警」的思路和 SLA 风险预警 是一回事：先算还差多少时间，再决定要不要鸣笛，而不是出了问题才告警。
七、留痕与对账：每一单都要说得清
订单处置是业务动作，出了纠纷要能复盘。最低要求有三条：
- 每次处置都要落一条记录：什么时候、因为什么、谁批的、结果是什么。
- 关键节点要存原始数据：改址前的原地址、退款前的金额和依据，不能改完就没了。
- 和账目要对得上：退款、补发的动作要和记账对账那条线打通，否则财务月底永远对不平。
字段怎么设计可以参考 审计查询字段怎么设计；如果担心自动化动作质量下滑，也可以加一道发布前的质量门禁思路，见 AI Agent 质量门禁怎么设。
八、五个常见的坑
- 一上来就想全自动。先把可逆动作自动化，不可逆的留给确认，比一步到位稳得多。
- 地址不做结构化。后面地址校验、物流对接、区域统计全是麻烦。
- 改址和退款不设门槛。这两条路径是羊毛党最喜欢钻的口子。
- 不区分未发货和已发货。两张流程混在一张表里，必然出错。
- 不留痕。客户投诉、平台介入、财务对账的时候，拿不出记录就只能认赔。
九、适合谁用
适合：日订单量已经超过一个人能盯住、售后请求散在多个渠道的中小电商团队；也适合有固定履约流程、但异常处理全靠人工记忆的业务。大促期间的订单洪峰，正是这套流程最划算的时候。
不太适合：订单量很小、一天几单的场景（人工更省事）；以及履约流程本身还没理清楚的团队——流程都没定，自动化只会把混乱放大。先把流程和字段理顺，再上 Agent。
总结
用 OpenClaw 管电商订单与售后，核心不是「回得快」，而是把每类异常都接到一个明确的出口，把不可逆的动作卡在确认之后，把过程留成能复盘的记录。边界先划清、字段先理齐、超时提前预警，这三件事做完，售后才算真的从「靠人盯」变成了「靠流程跑」。
