多订单场景下，为什么 AI 客服不能靠最近订单猜答案

“什么时候发货？”看起来是客服系统里最简单的问题之一。但当一位买家同时有多笔待发货订单时，真正的问题不是如何生成一句回复，而是：这句话到底在问哪一笔订单？

如果订单关联错了，后面的知识检索、物流查询和 AI 回复都会建立在错误事实之上。对客服 Agent 而言，相关订单选择必须是一个可解释的事实判断，而不是语言模型的猜测。

本文使用脱敏的通用示例说明设计原则，不包含真实买家、订单、商品或平台接口数据。

为什么“最近订单”不是答案

一个很常见的简化策略是：买家没有提供订单号时，直接选择最近付款的订单。这个策略看似提高了自动处理率，但会带来两个问题：

• 买家可能在问较早的一笔订单，付款时间不能证明关联关系；
• 相同输入在不同订单排序或数据刷新时可能得到不同结果，客服无法解释“为什么是这笔”。

更严重的是，一旦把这个选择交给 LLM，选择逻辑就会变成不可稳定复现的提示词行为。模型可以帮助理解问题，但不应该成为订单事实的裁决者。

设计目标：先确定事实，再生成答案

项目将订单选择拆成一个独立的确定性模块。它只负责回答四件事：

1. 买家在问哪类问题？
2. 是否存在唯一、可信的关联订单？
3. 如果不能确定，是否必须向买家澄清？
4. 客服应该看到哪些候选，以及系统为何没有自动选择？

最终输出不是一段自然语言，而是一份可审计的选择结果：

• intent：如发货、物流、售后、订单状态、商品咨询或未知；
• selected_order_id：唯一可确认时才有值；
• needs_clarification：是否需要客服或买家补充信息；
• candidate_orders：最多展示少量候选，方便人工理解；
• reason_codes：稳定的机器可读理由，用于审计和前端解释。

只有这一步完成后，知识链路和回复生成才会继续执行。

第一步：只接受可信的订单事实

订单数据并不天然可靠。客户端诊断缓存、组件节点标识、页面上的临时数据，都可能看起来像订单，却不应该进入正式决策。

因此，系统只允许经过精确来源校验的订单响应更新正式订单上下文；不符合来源和结构规则的数据只保留为诊断信息，不会污染客服事实库。

这条约束非常重要：宁可没有订单可选，也不能让脏数据变成“唯一订单”。

第二步：强证据优先于业务推断

选择器按证据强度逐层判断：

1. 明确订单号唯一命中；
2. SKU 标识唯一命中；
3. 商品名、SKU 名称或规格值唯一命中；
4. 当前意图下，业务优先级只有一笔合理订单；
5. 以上都不满足时，不选中订单。

例如，买家问“珍珠白那款什么时候发货”，两笔订单只有颜色规格不同。规格值属于强证据，可以唯一关联到对应订单；但如果买家只说“什么时候发货”，且有两笔待发货订单，就不能因为其中一笔更近而假定它是目标订单。

伪代码可以概括为：

if 唯一强证据命中:
    选中订单
elif 当前意图下只有一笔业务优先级最高的合理订单:
    选中订单
else:
    不选中，进入澄清

第三步：让业务状态参与判断，但不让它替代证据

不同意图对应不同的业务状态：

买家意图	选择器优先关注的订单状态
发货咨询	待发货、待出库等未履约状态
物流咨询	已发货且存在物流状态的订单
售后咨询	已有售后记录或符合售后条件的订单
订单状态	仍处于有效订单流程中的订单

这层业务优先级可以排除明显不合理的订单。例如买家问物流时，一笔待发货订单和一笔已发货订单同时存在，已发货订单更符合问题语义。

但这仍然不是“多笔同类订单时任选一笔”的理由。若两笔订单在同一意图下同样合理，系统会失败关闭，要求澄清。

付款时间的正确位置：排序，不是证据

付款时间仍有价值，但它只能解决展示顺序问题。

当多个候选订单同优先级且没有强证据时，系统使用付款时间、下单时间和最近发现时间对候选排序，方便客服或买家快速确认；但 selected_order_id 保持为空，needs_clarification=true。

两笔待发货订单
        ↓
都没有订单号、商品名或 SKU 证据
        ↓
按时间排序展示候选
        ↓
不自动选择，向买家澄清

这条规则看似保守，却让系统的行为稳定：付款时间只是同级候选的排序字段，永远不能单独构成选中证据。

“不确定”也应当是正式结果

传统系统常把“不确定”当成异常分支，而在 Agent 系统中，它应该是一等公民。

当订单不明确时，系统不会偷偷使用历史订单或随机候选，而是输出清晰状态：

• 未选中订单；
• 需要澄清；
• 候选订单摘要；
• 可解释的原因码。

上层回复策略因此可以生成一条安全的澄清草稿，例如请买家提供商品名称、规格或订单信息，而不是输出带有具体发货承诺的答案。

如何把规则做成可回归的工程能力

订单选择器的价值不只在规则本身，更在于它可以被独立测试。项目覆盖了以下典型情况：

• 单笔关联订单可以被选中；
• 无订单意图的普通消息不会误关联；
• 发货、物流、售后等意图会优先匹配合理业务状态；
• 商品名与 SKU 规格能够唯一定位订单；
• 多笔同级订单即使付款时间不同，也必须要求澄清；
• 订单晚于消息到达时，会刷新既有会话上下文；
• 旧数据库升级后，选择结果字段能够安全回填。

这些测试让“最近订单不能单独作为选中证据”不只是文档约定，而是可持续验证的行为契约。

对 Agent 设计的启发

订单选择器解决的是一个更通用的问题：当 Agent 需要依赖业务事实时，先把对象识别从生成模型中剥离出来。

无论是客服订单、企业合同、工单、设备还是项目资料，都可以采用类似模式：

可信数据源 → 确定性对象选择 → 证据与理由 → LLM 生成或工具调用

模型擅长理解自然语言和组织表达；系统规则擅长保证权限、事实和一致性。把两者分工清楚，才能在提升自动化效率的同时，避免“回答很好，但答错对象”的隐蔽风险。