面试：怎么设计客服 Agent对话状态机的？

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