面试：怎么设计客服 Agent对话状态机的？
这个问题问得好，我结合我们当时的设计思路具体讲讲。
对话状态机的核心设计思路
客服场景的状态机和其他业务系统不太一样——它既要处理业务状态（订单走到哪一步了），又要处理对话状态（用户在哪个节点、槽位填了多少），还得处理语义状态（用户意图有没有歧义）。这三个维度得分开管，不能混在一起。
我们当时用的是三层状态模型：
第一层：业务状态（最关键）
这块是权威数据，必须以 API 返回为准，Agent 自己不能"记错"。
拿退款的业务流程来说，状态流转是这样的：
INIT → AUTH(验证身份) → CHECK(检查订单是否符合退款条件) → CONFIRM(用户确认) → EXECUTE(执行退款) → COMPLETE每个状态只关注自己该管的事。CHECK 状态只管检查，不关心用户之前说了什么。好处是什么？状态流转清晰，出问题好排查。我们之前用纯对话历史管理退款流程，有次线上炸了——用户说"我要退款"，Agent 调了退款接口，但后端其实已经在处理了，导致重复退款。后来改成显式状态机，状态转换全部打日志，才定位到问题。
高风险操作必须走状态机，不能让 LLM 自由发挥。
第二层：对话状态（维护上下文）
这个层负责维护"对话走到哪了"，核心概念是槽位填充（Slot Filling）<
