AI 大模型时代,很多企业开始探索用 LLM+工具化的方式提升客服效率。
今天我用一个典型场景“电信客服”举例,介绍下如何用 Qwen-Agent 框架快速搭建一个支持多业务查询的智能客服,当然很多内容也是现学现用。
场景需求
用户常见的咨询问题包括:
- 💰 话费查询
- 📴 停机原因定位
- 📡 网络故障诊断
- 📦 套餐内容查询
- 📈 流量使用查询
- 📝 业务办理进度查询
... 多达几十类,几百项指标。
问题是:如何优雅地支持这些动态查询?
系统设计思路
核心思路很简单:
用户提问
↓
Agent 通过大模型理解意图
↓
选择调用对应的 Tool(函数)
↓
Tool 执行(查实时数据)
↓
模型生成自然语言回复
系统结构图
┌──────────────┐
│ 用户提问 │
└────┬─────────┘
↓
┌─────────────────────────────┐
│ Qwen-Agent 主体 │
│ ┌──────────────┐ │
│ │ Large Model │ 理解意图 │
│ └─────┬────────┘ │
│ ↓ │
│ Tool Router ⟶ 工具调度器 │
│ ┌──────────────┐ │
│ │ 话费查询 Tool │ │
│ │ 停机诊断 Tool │ │
│ │ 网络排查 Tool │ │
│ │ 套餐查询 Tool │ │
│ └──────────────┘ │
│ ↓ 知识库兜底回答 │
└─────────────────────────────┘
↓
⟶ 回复生成 ⟶ 用户
Tool 是什么?为什么不是用知识库?
很多朋友误解以为所有信息都写入知识库,其实并不是。
作用 | 适合用 Tool | 适合用知识库 |
---|---|---|
动态实时数据 | ✅ 查询话费、流量、停机状态 | ❌ |
静态规则 | ❌ | ✅ 资费标准、套餐规则 |
需要查数据库/API | ✅ | ❌ |
固定文档类回答 | ❌ | ✅ |
举例:话费查询
class QueryUserBill(Tool):
name = "query_user_bill"
description = "查询用户本月话费总额、余额、是否欠费"
def call(self, user_id: str) -> str:
# 假设 API 查询
data = get_user_bill_from_api(user_id)
return f"您当前欠费 {data['due']} 元,余额 {data['balance']} 元。"
知识库用例
# 停机规则
- 未及时缴费 → 停机
- 缴费不足 → 停机
- 流量封顶 → 停止数据服务
如何知道模型调用哪个 Tool?
关键设计:
Qwen-Agent 通过 Tool 的 name 和 description 让大模型理解 Tool 的功能。
用户提问后,模型智能匹配最适合的 Tool 调用。
例如:
agent = Agent(
llm=QwenLLM(model_name="qwen-plus"),
tools=[
QueryUserBill(),
QueryStopReason(),
QueryPackageInfo(),
DiagnoseNetworkIssue(),
],
)
用户问:“我这个月话费多少?” → 自动调用 query_user_bill
。
用户问:“我为什么停机了?” → 自动调用 query_stop_reason
。
不需要手写 if-else,模型智能调度。
流程完整示意图
graph TD;
用户提问 --> Agent;
Agent --> LLM理解意图;
LLM理解意图 --> ToolRouter;
ToolRouter -->|选择Tool| 查询话费Tool;
ToolRouter -->|选择Tool| 停机诊断Tool;
ToolRouter -->|选择Tool| 套餐查询Tool;
ToolRouter -->|选择Tool| 网络排查Tool;
查询话费Tool --> 返回结果;
知识库兜底回答 --> 返回结果;
返回结果 --> 生成回复 --> 用户;
小结
通过 Qwen-Agent 的设计理念,可以轻松实现:
✅ 不同业务功能拆分成独立 Tool
✅ 模型智能决定调用哪个 Tool
✅ 静态规则通过知识库兜底
✅ 无需人工硬编码 if-else
✅ 系统可以快速扩展几十上百个指标查询
一句话:LLM 做智能大脑,Tool 提供业务能力,知识库补充解释。