---

背景痛点：传统客服系统到底卡在哪？

去年我帮一家做跨境电商的小公司维护老客服后台，每天高峰 3k+ 咨询，客服小姐姐们疯狂敲字，而机器人却“装傻”——

1. 意图识别全靠正则，用户把“退货”说成“想退”，机器人直接宕机
2. 上下文靠 session 里硬编码字段，用户中途改口“算了不退了”，机器人还在追问快递单号
3. 并发一上来就 502，后端是单体 PHP，MySQL 扛不住 200 并发就锁表

痛定思痛，我决定用 Python 重新搭一套能扛大促、还能让运营自己改话术的“智能客服 Agent”。下文把踩过的坑、跑的调优、压测数据全部摊开，尽量让跟我一样半路出家的 Pythoner 也能一次跑通。

技术选型：规则引擎 vs 机器学习

先放结论：

• 规则引擎（Rule-Based）响应快、可控，但维护成本随 FAQ 数量指数级上升
• 机器学习（ML）前期需要标注数据，一旦模型收敛，后期几乎零维护

我对比了两种方案在同一台 4C8G 云主机上的表现：

| 指标 | 规则引擎（ES+正则） | Rasa ML | 备注 | |----||------------------|---------|------| | 平均响应 | 60 ms | 120 ms | ML 需模型加载 | | 新增意图 | 改代码+发版 | 标注 20 条语料重训 | 运营可自己标 | | 并发 2k TPS | CPU 100%+ 丢请求 | 70% CPU 平稳 | 见后文压测图 |

最终选型：Rasa 3.3 + Redis 持久化 + FastAPI 封装微服务，既保留 ML 的泛化，又通过缓存把响应压到 90 ms 以内。

核心实现：Rasa 模块化架构

1. 项目骨架

bot/
 ├─ actions/          # 自定义动作（退货、查物流）
 ├─ data/
 │  ├─ nlu.yml        # 意图、实体标注
 │  └─ stories.yml    # 多轮对话脚本
 ├─ models/           # 训练产出
 ├─ tests/            # Locust 压测脚本
 └─ docker-compose.yml

2. NLU+Core 训练

一条样本示例：

# data/nlu.yml
nlu:
- intent: request_return
  examples: |
    - 我想退货
    - 能退吗
    - 不想要了，怎么退

训练命令：

rasa train --fixed-model-name customer_service

产出 models/customer_service.tar.gz，含 DIETClassifier（意图+实体）与 TEDPolicy（对话策略）。

3. 对话状态机（DST）持久化

默认 Rasa 把状态放内存，重启即丢。这里用 Redis 做 TrackerStore：

# endpoints.yml
tracker_store:
  type: redis
  url: redis://redis:6379/0
  record_exp: 18000  # 5 h 过期，防内存泄漏

关键代码（符合 PEP8，附时间复杂度）：

# actions/return_action.py
from typing import Any, Dict, List, Text
from rasa_sdk import Action, Tracker
from rasa_sdk.executor import CollectingDispatcher
import redis
import json

class ActionReturnGoods(Action):
    def name(self) -> Text:
        return "action_return_goods"

    def run(self,
            dispatcher: CollectingDispatcher,
            tracker: Tracker,
            domain: Dict[Text, Any]) -> List[Dict[Text, Any]] figured:
        # O(1) 拿取 slots
        order_id = tracker.get_slot("order_id")
        if not order_id:
            dispatcher.utter_message(text="请提供订单号")
            return []

        # O(1) 写 Redis 防重
        r = redis.Redis(host='redis', port=6379, db=1)
        key = f"return_lock:{order_id}"
        if r.exists(key):
            dispatcher.utter_message(text="该订单已申请退货，请勿重复提交")
            return []
        r.setex(key, 3600, "1")

        dispatcher.utter_message(text=f"订单 {order_id} 退货申请已受理，预计 1-3 个工作日退款")
        return [SlotSet("return_status", "pending")]

4. 微服务化部署

docker-compose.yml 片段：

version: "3.9"
services:
  rasa-server:
    build: .
    ports:
      - "5005:5005"
    environment:
      - REDIS_URL=redis://redis:6379/0
    depends_on:
      - redis
  action-server:
    build: ./actions
    ports:
      - "5055:5055"
  redis:
    image: redis:7-alpine
    volumes:
      - redis_data:/data
volumes:
  redis_data:

一键启动：

docker-compose up -d

性能优化：压测、超时、隔离

1. Locust 2000 TPS 压测脚本

# tests/locustfile.py
from locust import HttpUser, task, between

class ChatUser(HttpUser):
    wait_time = between(0.5, 2.0)

    @task(10)
    def ask_return(self):
        self.client.post("/webhooks/rest/webhook",
                         json={"sender": "test_user", "message": "我想退货"})

运行：

locust -f tests/locustfile.py --host=http://localhost:5005 -u 2000 -r 100

压测结果：P99 响应 140 ms，错误率 0.2%，CPU 68%，满足大促要求。

2. 对话超时与会话隔离

• 超时：在 domain.yml 里加 session_config: session_expiration_time: 60 即可，60 s 无交互自动清槽位
• 隔离：Redis 不同 db 号区分测试/正式，防止压测脏数据污染线上

避坑指南：血泪总结

1. 降级方案
   不要把意图识别全部交给云端 BERT API！我曾在双 11 前 1 小时目睹阿里云宕 5 min，直接回退本地 DIET 模型，命中率掉 8%，但至少能跑。
   做法：在 FastAPI 加 @cache 与 circuit breaker，第三方超时 200 ms 立即切本地模型。

2. 敏感日志脱敏
   用户会发手机号、身份证，日志必须过滤。统一封装：

import re
def mask_sensitive(text: str) -> str:
    text = re.sub(r"\d{11}", "", text)
    text = re.sub(r"\d{15,18}", "🆔", text)
    return text

Filebeat → Elasticsearch 前先过一遍，省得被 GDPR 罚款。

代码规范小结

• 全项目 black + isort 自动格式化，CI 里加 --check
• 函数级注释写清时间复杂度，如 O(n log)
• 单元测试覆盖 80% 以上，Merge Request 必须绿

互动环节：跨渠道会话同步怎么做？

目前机器人只在网页端，老板要求 App、微信小程序、钉钉群聊三端同时接入，且用户换设备能继续刚才的对话。
如何设计一套跨渠道会话同步方案？

• 是否继续用 Redis？
• 消息顺序与乱序怎么保证？
• 不同渠道消息格式差异如何兼容？

欢迎在 GitHub 提 Issue 或 PR，分享你的思路，我会把优秀方案合并到示例仓库并注明作者。

写在最后

整套方案从 0 到 1 花了我 3 周，其中 1 周都在踩压测的坑。Rasa 不是银弹，但胜在开源、社区活跃，配合 Redis+Docker 能快速撸出高可用原型。
如果你也在维护“人工智障”客服，希望这篇笔记能帮你把“智障”进化成“智能”，让客服小姐姐安心喝口咖啡。祝训练顺利，线上无事故！

---