从FAQ机器人到客服Agent：如何用“状态机＋大模

型”构建可控的智能客服流程

摘要

传统FAQ机器人主要依赖关键词匹配、意图分类和固定话术，适合处理“怎么修改密码”“在哪里查看订

单”等简单问题。但在退款申请、故障报修、订单变更等场景中，机器人不仅需要回答问题，还需要收集信

息、判断条件、调用业务接口，并根据执行结果继续对话。

这类任务更适合由客服Agent处理。

不过，完全依赖大模型自主决策也会带来流程不可控、参数遗漏和错误调用接口等问题。本文介绍一种相对稳

妥的实现思路：使用大模型理解用户意图和提取参数，使用状态机控制业务流程，再通过工具调用完成具体操

作。

一、FAQ机器人为什么难以处理复杂客服任务

传统智能客服通常由三个部分组成：

1. 用户问题分类；
2. 知识库检索；
3. 固定答案返回。

例如，用户询问：

如何修改账号密码？

系统识别出“修改密码”意图后，从知识库中找到对应答案并回复即可。

但用户提出下面的问题时，处理过程就会复杂很多：

我昨天买的商品还没有发货，能帮我取消订单吗？

系统至少需要完成以下步骤：

• 识别用户要取消订单；

• 获取订单号；

• 查询订单状态；

• 判断订单是否允许取消；

• 调用取消订单接口；

• 将处理结果反馈给用户；

• 如果取消失败，决定是否转人工处理。

这已经不再是简单的“问题—答案”匹配，而是一个需要持续判断和执行的任务流程。

1二、客服Agent的核心不是聊天，而是完成任务

从工程角度看，客服Agent可以拆分为四层：

1. 对话理解层

负责理解用户当前表达，包括：

• 用户意图；

• 业务对象；

• 关键参数；

• 上下文关系；

• 用户情绪。

例如：

上次那个订单我不想要了。

系统需要结合历史对话判断“那个订单”具体指哪一笔订单，而不是只分析当前一句话。

1. 流程控制层

流程控制层决定下一步应该做什么，例如：

• 继续询问订单号；

• 查询订单状态；

• 调用取消接口；

• 解释无法取消的原因；

• 转接人工客服。

这一层不建议完全交给大模型自由决策。对于退款、报修、投诉和账户操作等关键场景，最好通过状态机或工

作流进行约束。

1. 工具执行层

工具执行层负责调用真实业务系统，例如：

• 查询订单；

• 查询物流；

• 创建工单；

• 修改预约时间；

• 发送短信；

• 查询会员信息。

大模型本身不能直接修改订单，它只能决定是否应该调用某个工具，并生成工具所需要的参数。

1. 回复生成层

业务系统返回结果后，大模型将结构化数据转换成自然语言。

例如，订单接口返回：

2{

"order_id": "A20260712001",

"status": "shipped",

"cancelable": false

}

客服Agent可以生成回复：

这笔订单已经发货，目前无法直接取消。你可以在收到商品后申请退货，或者由人工客服帮你进

一步确认物流拦截情况。

三、为什么需要“状态机＋大模型”

大模型擅长理解自然语言，但不擅长稳定执行严格的业务规则。

例如，在取消订单流程中，企业可能有以下规则：

• 未支付订单可以直接关闭；

• 已支付但未发货订单可以申请取消；

• 已发货订单不能直接取消；

• 特殊商品不支持无理由退货；

• 高金额订单需要人工审核。

如果把所有规则都放进提示词中，大模型可能出现以下问题：

• 漏掉某个判断条件；

• 没有收集完整参数就调用接口；

• 在不同轮次给出不一致的答案；

• 错误理解接口返回结果；

• 对不允许执行的操作做出承诺。

因此，可以让大模型负责“理解”，状态机负责“控制”。

一个简化的订单取消状态可以设计为：

START

↓

IDENTIFY_INTENT

↓

COLLECT_ORDER_ID

↓

QUERY_ORDER

↓

CHECK_CANCEL_RULE

├─ 可以取消 → EXECUTE_CANCEL

├─ 不可取消 → EXPLAIN_REASON

└─ 信息异常 → TRANSFER_TO_HUMAN

每个状态只允许执行有限的动作，从而降低流程失控的概率。

3四、一个简化的实现示例

下面用伪代码描述基本流程：

class CustomerServiceAgent:

def init(self):

self.state = "START"

self.context = {}

def handle_message(self, message):

if self.state == "START":

intent = recognize_intent(message)

if intent == "cancel_order":

self.state = "COLLECT_ORDER_ID"

return "请提供需要取消的订单号。"

return search_knowledge_base(message)

if self.state == "COLLECT_ORDER_ID":

order_id = extract_order_id(message)

if not order_id:

return "我暂时没有识别到订单号，请重新输入。"

self.context["order_id"] = order_id

self.state = "QUERY_ORDER"

return self.query_order()

def query_order(self):

result = order_api.get_order(

self.context["order_id"]

)

if not result:

self.state = "TRANSFER_TO_HUMAN"

return "没有查询到对应订单，我帮你转接人工客服。"

self.context["order"] = result

self.state = "CHECK_CANCEL_RULE"

return self.check_cancel_rule()

def check_cancel_rule(self):

order = self.context["order"]

if order["status"] == "unpaid":

return self.execute_cancel()

if order["status"] == "paid_not_shipped":

return self.execute_cancel()

4if order["status"] == "shipped":

self.state = "EXPLAIN_REASON"

return "订单已经发货，暂时无法直接取消。"

self.state = "TRANSFER_TO_HUMAN"

return "订单状态比较特殊，我帮你转接人工客服。"

def execute_cancel(self):

result = order_api.cancel_order(

self.context["order_id"]

)

if result["success"]:

self.state = "FINISHED"

return "订单已经取消成功。"

self.state = "TRANSFER_TO_HUMAN"

return "系统暂时无法完成取消操作，我帮你转接人工客服。"

在真实项目中， recognize_intent() 和 extract_order_id() 可以由大模型完成，而订单查询、状态判断和取

消操作仍由确定性的程序控制。

五、大模型应该输出结构化结果

为了方便系统解析，不建议让大模型直接返回一段自由文本，而是要求它输出固定JSON结构。

例如：

{

"intent": "cancel_order",

"confidence": 0.96,

"entities": {

"order_id": "A20260712001"

},

"missing_fields": [],

"suggested_action": "query_order"

}

系统可以根据这些字段决定下一步动作。

提示词可以包含以下约束：

你是客服意图识别模块，只负责识别意图和提取参数。

要求：

1. 不直接回答用户问题；
2. 不虚构订单信息；
3. 缺少参数时写入 missing_fields；
4. 只能从给定意图列表中选择；
5. 必须返回合法JSON。

这种方式比让大模型同时负责理解、决策、执行和回复更容易调试。

六、工具调用需要设置哪些限制

客服Agent连接业务系统后，风险会明显高于普通问答机器人，因此工具调用至少需要设置以下限制。

1. 参数校验

调用接口前，检查订单号、手机号、时间和金额等字段是否合法。

1. 权限校验

查询订单和修改订单的权限应该分开，不能因为Agent拥有查询权限，就默认允许执行修改操作。

1. 幂等控制

如果用户重复发送消息，系统不能重复创建工单、重复退款或重复取消订单。

1. 超时和重试

业务接口超时时，应限制重试次数，避免连续调用导致业务系统压力增加。

1. 操作日志

记录以下信息：

• 用户原始请求；

• 大模型识别结果；

• 状态流转过程；

• 调用的工具名称；

• 输入参数；

• 接口返回结果；

• 最终回复内容。

发生异常时，才能判断问题出在模型、流程还是业务接口。

七、知识库问答和业务执行应该分开

客服系统通常同时存在两类请求。

第一类是知识问答：

• 营业时间是什么？

• 如何修改密码？

• 保修期是多久？

6第二类是业务办理：

• 帮我取消订单；

• 帮我修改预约时间；

• 帮我创建维修工单。

知识问答可以采用RAG流程：

用户问题

→ 问题改写

→ 知识检索

→ 相关性排序

→ 生成答案

业务办理则需要进入Agent工作流：

用户请求

→ 意图识别

→ 参数收集

→ 规则判断

→ 工具调用

→ 结果确认

如果不区分这两类请求，系统可能把业务办理问题当成知识问答，只告诉用户“如何操作”，却没有真正帮助

用户完成操作。

八、上线前应该重点测试什么

客服Agent上线前，不能只测试标准问题，还需要覆盖异常情况。

例如：

• 用户没有提供订单号；

• 用户一次提供多个订单号；

• 用户中途改变诉求；

• 接口返回空数据；

• 接口响应超时；

• 用户重复提交同一请求；

• 用户要求执行无权限操作；

• 用户使用口语、错别字或模糊指代；

• 大模型输出的JSON格式错误；

• 对话过程中突然要求转人工。

测试时可以重点观察几个指标：

• 意图识别准确率；

• 参数提取完整率；

• 工具调用成功率；

• 任务完成率；

7• 错误调用率；

• 转人工率；

• 平均对话轮数；

• 单次任务处理时长。

其中，任务完成率通常比单纯的回答命中率更能反映客服Agent是否真正有效。

九、实践总结

从FAQ机器人升级到客服Agent，并不是简单地接入一个大模型接口。

真正需要解决的是三个问题：

第一，大模型能否准确理解用户当前想完成什么任务。

第二，系统能否按照企业业务规则控制执行过程。

第三，Agent能否安全调用订单、工单、CRM等业务系统。

在实际工程中，一种相对可靠的分工方式是：

• 大模型负责意图理解、参数提取和自然语言生成；

• 状态机负责流程控制和状态流转；

• 规则引擎负责业务条件判断；

• 工具接口负责执行具体业务动作；

• 人工客服负责处理异常和高风险情况。

大模型提高了客服系统理解自然语言的能力，但流程是否稳定，仍然取决于状态管理、接口设计、权限控制和

异常处理。

对于需要真正办理业务的客服场景，“可控地完成任务”通常比“生成一段听起来正确的回答”更加重要。