AI Agent 客服实战：我用 OpenClaw 搭建了一套 7×24 智能客服系统

TechFind
13 阅读1分钟

AI Agent 客服实战：我用 OpenClaw 搭建了一套 7×24 智能客服系统

上个月，一个做跨境电商的朋友找我吐槽：客服团队 5 个人，每天处理 300+ 条咨询，80% 都是重复问题——"发货了吗"、"怎么退货"、"有没有优惠券"。人力成本每月 4 万，但客户满意度只有 72%。

我花了一个周末，用 OpenClaw 帮他搭了一套 AI Agent 客服系统。上线一个月后，结果是这样的：

  • 自动解决率：78%（300 条/天中 234 条不需要人工介入）
  • 响应时间：从平均 8 分钟降到 3 秒
  • 客户满意度：从 72% 升到 89%
  • 人力成本：从 5 人减到 2 人，月省 2.4 万

这篇文章完整复盘这个项目的技术方案，包括踩过的坑和最终的架构设计。

为什么选 OpenClaw 而不是直接调 API

很多人的第一反应是：直接用 OpenAI API + 几个 Prompt 不就行了？

我一开始也这么想。但实际跑下来发现三个致命问题：

问题一：纯 LLM 无法处理业务逻辑

客户问"我的订单到哪了"，你不能让 AI 瞎编。它必须去查 ERP 系统的物流数据，拿到真实的快递单号和状态，再组织语言回复。这需要工具调用（Tool Calling）能力。

问题二：多轮对话的上下文管理

客户先问退货政策，然后说"那我要退"，接着问"退款多久到账"——这三轮对话是一个完整流程。你需要状态机来管理会话状态，不能每轮都从零开始。

问题三：兜底机制

AI 不是万能的。遇到投诉升级、情绪激动的客户、或者 AI 连续两轮都没理解用户意图的情况，必须无缝转接人工。这需要可靠的路由机制。

OpenClaw 的 Agent 架构天然支持这三点：工具注册、会话状态管理、多 Agent 协同。所以它是这类场景的理想框架。

系统架构设计

整个系统由四个核心 Agent 组成：

用户消息
    ↓
┌─────────────┐
│  Router Agent │  ← 意图识别 + 路由分发
└──────┬──────┘
       ├──→ FAQ Agent（常见问题，占 60%）
       ├──→ Order Agent（订单查询/退货，占 25%）
       ├──→ Promotion Agent（优惠活动，占 10%）
       └──→ Human Escalation（人工兜底，占 5%）

Router Agent：交通警察

Router 是整个系统的入口。它的职责很简单：判断用户意图，把消息分发给对应的专业 Agent。

# router-agent.yaml
name: customer-router
model: gpt-4o-mini  # 路由用小模型就够，省成本
system_prompt: |
  你是客服路由器。根据用户消息判断意图类别：
  - FAQ: 通用问题（退货政策、运费、支付方式等）
  - ORDER: 涉及具体订单（查物流、退货申请、修改地址）
  - PROMO: 优惠券、活动、折扣相关
  - HUMAN: 投诉、情绪激动、连续未解决
  只输出类别名称，不要解释。
tools: []
max_tokens: 10

为什么路由要单独一个 Agent？因为专业化。每个 Agent 只做一件事，Prompt 更短、准确率更高、token 消耗更少。Router 用 gpt-4o-mini 就够了，每次调用成本不到 ¥0.001。

FAQ Agent：知识库问答

FAQ Agent 处理最高频的 60% 问题。它的核心是 RAG（检索增强生成）：

# faq-agent.yaml
name: faq-handler
model: gpt-4o-mini
system_prompt: |
  你是专业客服。基于以下知识库内容回答用户问题。
  规则：
  1. 只基于知识库回答，不要编造
  2. 如果知识库没有答案，回复"让我帮您转接专员"
  3. 语气友好专业，用"您"称呼客户
  4. 回答控制在 100 字以内
tools:
  - name: search_knowledge_base
    description: 搜索客服知识库
    parameters:
      query: string

知识库用向量数据库（我们选的 Milvus）存储，灌入了店铺的退货政策、运费规则、常见问题等 200+ 条知识。命中率在 92% 左右。

Order Agent：业务操作

Order Agent 是最复杂的，因为它需要调用外部系统：

# order-agent.yaml
name: order-handler
model: gpt-4o
system_prompt: |
  你是订单处理专员。可以查询订单状态、申请退货、修改收货地址。
  规则：
  1. 操作前必须验证用户身份（手机号后4位）
  2. 退货申请需确认原因和商品状态
  3. 修改地址只能在"待发货"状态
  4. 每次操作后告知用户预期处理时间
tools:
  - name: query_order
    description: 查询订单状态和物流信息
    parameters:
      order_id: string
  - name: apply_return
    description: 申请退货
    parameters:
      order_id: string
      reason: string
  - name: update_address
    description: 修改收货地址
    parameters:
      order_id: string
      new_address: string

这里有个关键设计：身份验证前置。Order Agent 在执行任何操作前，必须先验证用户身份。我们通过手机号后 4 位 + 订单号的组合来验证，防止信息泄露。

Human Escalation：人工兜底

兜底机制的触发条件：

  1. Router 判断为 HUMAN 类别（投诉/情绪激动）
  2. 任何 Agent 连续 2 轮未能解决问题
  3. 用户主动要求"转人工"
  4. 涉及金额 > 500 元的退款操作
# escalation.py
class EscalationManager:
    def should_escalate(self, conversation):
        # 情绪检测
        if conversation.sentiment_score < -0.5:
            return True, "negative_sentiment"
        
        # 连续未解决
        if conversation.unresolved_turns >= 2:
            return True, "unresolved"
        
        # 高金额操作
        if conversation.pending_refund > 500:
            return True, "high_value"
        
        # 用户主动要求
        if "转人工" in conversation.last_message:
            return True, "user_request"
        
        return False, None

转人工时，系统会自动把完整的对话历史和用户诉求摘要推送到企业微信群，人工客服接手后可以无缝继续。

实战踩坑记录

坑 1：意图识别准确率不够

最初 Router 的准确率只有 81%。主要问题是边界 case：比如"我买的东西有问题想退"，既涉及订单又涉及退货。

解决方案：引入 Few-shot 示例。在 Router 的 Prompt 中加了 20 个边界 case 的分类示例，准确率提升到 94%。

坑 2：多轮对话丢失上下文

用户第一轮说"查一下 2024030001 的物流"，第二轮说"帮我改个地址"——第二轮没有订单号，但应该复用第一轮的。

解决方案：OpenClaw 的会话状态管理。每个会话维护一个 context 对象，包含已识别的订单号、用户身份等信息，跨轮次复用。

坑 3：成本控制

最初所有 Agent 都用 GPT-4o，一天的 API 费用接近 200 元。

解决方案：分级用模型。Router 和 FAQ 用 gpt-4o-mini（便宜 15 倍），只有 Order Agent 用 gpt-4o（需要复杂推理）。优化后日均成本降到 30 元。

成本核算

项目月成本
GPT-4o API（Order Agent）¥600
GPT-4o-mini API（Router + FAQ）¥200
Milvus 向量数据库¥150
服务器（2C4G）¥100
合计¥1,050

对比之前 5 人客服团队月成本 4 万，节省了 97%。即使算上剩余 2 人的人力成本 1.6 万，总成本仍然从 4 万降到 1.7 万，年省 27.6 万。

部署方案

整个系统跑在一台 2C4G 的云服务器上。推荐用腾讯云轻量应用服务器，年付不到 1000 元。

部署步骤：

# 1. 安装 OpenClaw
curl -fsSL https://get.openclaw.com | bash

# 2. 配置 Agent
openclaw init customer-service
cd customer-service

# 3. 创建上面的 Agent 配置文件
# router-agent.yaml, faq-agent.yaml, order-agent.yaml

# 4. 导入知识库
openclaw knowledge import --source ./faq-data.csv

# 5. 启动服务
openclaw serve --port 8080

# 6. 对接企业微信/飞书 Webhook
openclaw connect --platform wecom --webhook-url YOUR_WEBHOOK

OpenClaw 原生支持企业微信和飞书的 Webhook 对接，配置一个 URL 就能跑起来，不需要自己写消息解析代码。

效果和后续优化

上线一个月的数据：

指标上线前上线后变化
日均处理量300 条300 条—
自动解决率0%78%+78%
平均响应时间8 分钟3 秒-99.4%
客户满意度72%89%+17%
月人力成本¥40,000¥16,000-60%
月技术成本¥0¥1,050—

接下来计划优化的方向：

  1. 主动触达：客户下单 3 天未确认收货，自动发关怀消息
  2. 情感分析：实时检测客户情绪，负面情绪自动提升服务等级
  3. 自动学习：人工客服解决的新问题自动入库，持续扩充知识库

总结

AI Agent 客服不是"未来趋势"，而是"现在就该做"的事。核心是三点：

  1. 专业化分工：每个 Agent 只做一件事，准确率才高
  2. 人机协同：AI 处理 80% 的重复问题，人工专注 20% 的复杂场景
  3. 渐进部署：先跑 FAQ，再上订单，最后做主动触达

完整代码和配置模板已开源，需要的可以参考 OpenClaw 官方文档。

如果你也在考虑用 AI Agent 改造客服，可以先看看 OpenClaw 部署成本指南，评估一下投入产出比。

关于作者：TechFind，AI 产品工程师，专注 AI Agent 在企业场景的落地实践。更多实战案例和技术分享，欢迎关注。

avatar
文章
阅读
粉丝