目录
- 一、先回答你的直觉问题：要不要加「售后 Intent」？
- 短答案
- 为什么？
- 二、你这 5 类 Intent 的真实“覆盖边界”
- 「我要退货」
- 三、那为什么你会“感觉不够用”？问题出在哪？
- 因为你现在在用 Intent 承担两件事：
- 四、正确的工程拆法（关键）
- ✅ Intent 不扩展
- ✅ 增加一个正交维度：
SESSION_PHASE
- 五、把「退货流程」完整跑一遍（你关心的点）
- 用户说：
- Intent 判断
- Coordinator 决策（不是 Intent 决策）
- 六、售后不是“对话”，是“流程状态机”
- AfterSalesFlowAgent 的职责不是“聊天”，而是：
- 所以你真正需要的是：
- 1️⃣ 流程定义（而不是 Intent）
- 2️⃣ Flow State（而不是用户意图）
- 七、为什么「售后强行加 Intent」是反模式？
- 八、一个非常实用的判断公式（你可以写进设计文档）
- 九、你这套体系的最终形态（我帮你总结一下）
- 1️⃣ Intent（认知层）——你已经有了，且是对的
- 2️⃣ Phase（业务阶段）——你需要补
- 3️⃣ Flow（执行层）——售后的核心
- 4️⃣ State（系统记忆）
- 十、一句非常重要的架构判断（送你）
结论先行：
这 5 类意图在“成交前 + 下单当刻”是完全够用的，但在「成交后 / 售后」阶段，语义上够，工程上不够。
不过重点是——
你不应该为售后再加一堆 Intent。
正确做法是：Intent 不变，阶段变。
下面我分三层把这件事讲清楚。
一、先回答你的直觉问题：要不要加「售后 Intent」？
短答案
不建议新增诸如：
- AFTER_SALES
- RETURN_REQUEST
- REFUND
- COMPLAINT
这类 Intent。
为什么？
因为售后场景的问题本质不是「用户想干嘛」，而是：
系统已经进入一个“确定流程”，需要收集字段并推进状态机。
而这件事，不应该由 Intent 数量解决。
二、你这 5 类 Intent 的真实“覆盖边界”
我们换个角度看，你现在的 Intent 不是按业务域划分的，而是按：
用户“认知与决策状态”划分的
| Intent | 覆盖的是 |
|---|---|
| FACT / KNOWLEDGE | 信息获取 |
| DECISION_SUPPORT | 判断未完成 |
| OBJECTION | 判断已负向 |
| FLOW_ADVANCE | 判断完成，进入执行 |
⚠️ 注意一句非常关键的话：
售后流程里，用户是“已经做过判断的”。
所以在语义层面：
「我要退货」
这句话本质是：
FLOW_ADVANCE
不是新 Intent。
三、那为什么你会“感觉不够用”？问题出在哪？
因为你现在在用 Intent 承担两件事：
- 用户在想什么（你现在做得很好）
- 系统下一步要做什么（这里开始吃力）
售后问题的复杂度来自第二点。
四、正确的工程拆法（关键）
✅ Intent 不扩展
✅ 增加一个正交维度：SESSION_PHASE
SESSION_PHASE =
- PRE_SALES
- IN_ORDER
- AFTER_SALES
Intent × Phase，才是完整路由键。
五、把「退货流程」完整跑一遍（你关心的点）
用户说：
“我要退货”
Intent 判断
{"intent": "FLOW_ADVANCE","phase": "AFTER_SALES"
}
Coordinator 决策（不是 Intent 决策）
IF phase == AFTER_SALES AND intent == FLOW_ADVANCE
→ 路由到 AfterSalesFlowAgent
六、售后不是“对话”，是“流程状态机”
AfterSalesFlowAgent 的职责不是“聊天”，而是：
1. 确认订单是否存在
2. 判断是否在退货期限内
3. 判断商品是否支持退货
4. 收集必要字段
5. 驱动状态推进
所以你真正需要的是：
1️⃣ 流程定义（而不是 Intent）
RETURN_FLOW = [CHECK_ORDER,CHECK_ELIGIBILITY,COLLECT_REASON,COLLECT_EVIDENCE, // 可选CONFIRM_REFUND_METHOD,SUBMIT
]
2️⃣ Flow State（而不是用户意图）
{"flow": "RETURN","step": "CHECK_ORDER","required_fields": ["order_id"]
}
七、为什么「售后强行加 Intent」是反模式？
如果你加：
- RETURN_REQUEST
- REFUND_QUERY
- WARRANTY_CLAIM
你会遇到三个工程灾难：
- Intent 数爆炸
- 同一句话在不同阶段语义相同但 Intent 不同
- Coordinator 路由复杂度指数级上升
而且：
售后成功率 ≠ 意图识别准确率
售后成功率 = 流程完成率
八、一个非常实用的判断公式（你可以写进设计文档）
如果用户的问题：
- 目标是“推进一个确定流程”
- 系统需要“收集字段 / 校验状态”→ 不新增 Intent
→ 用 Phase + Flow State 解决
九、你这套体系的最终形态（我帮你总结一下）
1️⃣ Intent（认知层）——你已经有了，且是对的
FACT / KNOWLEDGE / DECISION / OBJECTION / FLOW
2️⃣ Phase（业务阶段）——你需要补
PRE_SALES / IN_ORDER / AFTER_SALES
3️⃣ Flow（执行层）——售后的核心
RETURN / REFUND / WARRANTY / EXCHANGE
4️⃣ State（系统记忆）
{"intent": "FLOW_ADVANCE","phase": "AFTER_SALES","flow": "RETURN","step": "COLLECT_ORDER_ID"
}
十、一句非常重要的架构判断（送你）
Intent 用来“理解人”，
Flow 用来“驱动系统”。
你现在已经把「理解人」这件事做对了。
下一步如果你愿意，我们可以直接：
- 设计 AfterSalesFlow DSL
- 或把 售前 Funnel + 售后 Flow 放进一个统一 Coordinator
这一步，基本就是「从智能客服，迈到真正可规模化的智能销售系统」了。