企业官网建设流程全解析

让 AI 客服从"会聊"到"会干活"：Function Calling 工程实践

为什么纯大模型客服只能陪聊

大模型进客服系统之后，对话流畅度是质的飞跃——客户不用按关键词问，口语化、带情绪它都能接住。

但有个问题：纯生成式客服只会"生成回答"，不会"做动作"。

客户问"我的快递到哪了"，它如果没去查物流系统，就只能编一个"预计明天送达"——这就是幻觉，直接等于客诉。客户说"帮我申请退款"，它回"好的已为您处理"，实际上什么都没做。

所以真正能上生产的客服 AI，必须让模型从"生成文本"升级到"调用工具"：查物流、建工单、查库存、查订单，都是真实动作。这一步跨过去，才叫 Agent 化，才从"陪聊"变成"生产力"。

下面把我们在客服系统生产环境里做 Function Calling 的关键设计拆开讲。

整体架构

四步闭环：

1. 意图识别：判断用户要做什么（查物流 / 退款 / 查库存 / 闲聊）。

1. 工具路由：把意图映射到具体工具，拼参数。

1. 工具执行：调用后端服务（带超时、重试、降级）。

1. 结果回填：把真实结果塞回对话，模型据此生成自然语言答复。

模型只负责"决定调哪个工具 + 怎么用结果说话"，不负责"凭空给事实"。

一、工具定义：用 Schema 约束模型输出

先把每个工具定义成结构化 Schema，模型按 Schema 填参数，避免自由发挥。

Schema 里的description很关键——模型靠它判断是否该调这个工具。描述写清楚"做什么 + 要什么参数"，误调率能降一大截。

二、路由与执行：调度器

模型返回"要调哪个工具 + 参数"后，调度器负责真正执行，并做超时与重试。

两个工程要点：

• 缺参数不猜：订单号没拿到，宁可转人工问用户，也不拿个假单号去查。

• 失败不编造：工具调不通，直接降级转人工，绝对不能让模型"编一个结果"回给用户。

三、结果回填：把真实数据喂回对话

工具拿到真实结果后，要把它作为"唯一证据"塞进下一轮 prompt，模型只能基于它作答。

这一层是防幻觉的最后一道闸：模型生成的每一句事实，都必须能在toolResult里找到出处。如果工具失败了，prompt 直接引导它"转人工"，而不是硬编。

生产环境数据

调度器上线后的几个指标（统计周期 2026 年 Q1，单区域集群）：

数据来源：团队客服系统生产环境监控

几个优化点：

• 工具按风险分级：查物流/库存是只读，失败了降级即可；退款/改单是写操作，必须二次确认 + 留痕。

• 高频工具加本地缓存（如库存 5 秒 TTL），避免打爆下游。

• 模型返回的工具调用先做"语义校验"：参数格式对，但值明显异常（如订单号位数不对）也要拦。

总结

AI 客服从"会聊"到"会干活"，关键不是模型多大，而是把动作从生成里拆出来：

1. 用 Schema 约束工具调用——模型只填参数，不自由发挥；

1. 缺参数不猜、失败不编——宁可转人工，也不拿假数据骗用户；

1. 结果回填当唯一证据——防幻觉的最后一道闸；

1. 按风险分级处理——只读可降级，写操作必确认；

1. 工具调用率与成功率要监控——这是 AI 客服"能不能干活"的硬指标。

做好这几步，客服 AI 才真正从"陪聊机器人"变成"能处理业务的同事"。以上是我们团队在客服系统生产环境里的 Function Calling 实践，欢迎评论区交流踩坑。

（数据来自团队生产环境监控，具体以各厂商官方最新说明为准。）