我打算用 12 天搭一套 AI 客服系统（企业级实战，附源码）

本文首发于同名公众号，欢迎点赞收藏转发
这一章不写代码，纯粹给大家做个"行前培训"。先聊聊这个项目到底是干什么的、为什么值得做，再花点时间把后续章节会反复提到的一些 AI 名词过一遍。已经是大佬的朋友可以跳过扫盲部分，直接从第一章开始。

---

1. 这个项目到底在做什么

说白了，就是用 AI 搭一个智能客服系统。

大家平时网购、点外卖、用 SaaS 产品，遇到问题第一反应是什么？找客服。但现实情况是：

• 下班之后、凌晨三点，客服没人在线
• 排了半天队，接通之后问了半天，最后告诉你"这个问题我帮您转一下"
• 明明 FAQ 里有写，客服就是不按那个答，每次说法还不一样

这些问题，AI 客服可以很好地解决------不是那种智障的"关键词匹配"机器人，而是真的能理解用户在说什么、能查知识库、能判断情绪、能自动建工单的智能系统。

这套课程要搭的东西，长这样：

用户发了一条消息
        │
        ▼
  ┌─────────────┐
  │  AI 先理解一下│ ← 这条消息什么意思？用户什么情绪？
  └──────┬──────┘
         │
    ┌────┼────┐
    │    │    │
    ▼    ▼    ▼
  开心  正常  生气
  直接  查知识  赶紧转人工
  回答  库回答  +建工单
    │    │    │
    └────┼────┘
         │
         ▼
  ┌─────────────┐
  │  记录 + 复盘  │  ← 每条对话都存，定期回顾服务质量
  └─────────────┘

学完这套课程，大家能拿到什么？

• 一套从简单到完整的 11 章代码，每章都能独立运行
• 一个能接入公司知识库的 RAG 系统，AI 回答基于真实资料，不瞎编
• 一个自动识别用户情绪的路由系统，该转人工就转，不让用户越聊越火
• 一个工单管理系统，复杂问题自动建单，形成售后闭环
• 一个复盘仪表盘，对话存档 + 质量评分，哪里有问题一目了然
• 最后打包成 FastAPI + Streamlit，直接给业务团队用

---

2. 为什么现在值得学这个

可能有人会觉得："AI 客服不是早就有了吗？"

对，但之前那批和现在这批完全是两个时代的东西。

老一代客服机器人（大概 2015-2020 年）：

• 基于关键词匹配 + 决策树，"您好，请问您想咨询什么？1. 物流 2. 售后 3. 其他"
• 只能走预设的流程，用户说点意料之外的话就傻了
• 维护成本极高，每加一个新业务场景都要改一大堆规则

新一代 AI 客服（现在）：

• 基于大语言模型（LLM），能真正理解用户说的自然语言
• 不需要预设几万条规则，把知识库丢进去就能用
• 能识别情绪、判断意图、自己决定走什么流程
• 维护起来简单很多------知识库更新了，AI 自动就知道新内容

2024-2025 年这波浪潮之后，AI 客服已经从"能用"变成了"好用"，而且成本一直在降。现在学这个，正好赶上落地的窗口期。

---

3. AI 名词扫盲

后面的章节会频繁提到一些术语。这里给大家集中过一遍，不追求严谨定义，重点是建立直觉------知道它大概是干啥的就行。

3.1 LLM --- 大语言模型

一句话解释：就是 ChatGPT 背后那种"很会说话的 AI"。

稍微展开说：它是一个用海量文本数据训练出来的模型，学会了人类语言的规律。你给它一段文字，它能续写、能回答问题、能翻译、能总结、能帮你写代码。

大家平时接触到的 GPT-4、Claude、DeepSeek、文心一言，底层都是 LLM。可以把它理解成一个读过全世界书的人------不一定什么都精通，但什么都能聊两句，而且聊得还挺像那么回事。

在咱们项目里：LLM 是整个客服系统的"大脑"，负责理解用户说的话，然后生成合适的回复。

3.2 Prompt --- 提示词

一句话解释：你跟 AI 说的那段话，告诉它你想要什么。

举个例子：

你是一个专业的客服人员，请用亲切的语气回答用户的问题。
用户的问题是：我的耳机连不上手机了，怎么办？

这段话就是一个 Prompt。Prompt 写得好不好，直接决定 AI 输出的质量。后面第二章和第四章会花不少篇幅讲怎么写好 Prompt。

类比 ：Prompt 就像给新员工写的操作手册。手册写得越清晰，新员工干得越好。

3.3 Token

一句话解释：AI 处理文字的最小单位，可以粗略理解成"半个到一个词"。

中文大概 1-2 个字算一个 Token，英文大概 3-4 个字母算一个 Token。GPT-4 的上下文窗口是 128K Token，大概相当于一本 300 页的书。

为什么要在意这个 ：因为 Token 跟钱直接挂钩。API 调用是按 Token 计费的，输入多少 Token、输出多少 Token，都会算钱。后面做 RAG 的时候，为什么要把文档"切片"而不是整篇丢进去，一个重要原因就是控制 Token 数量。

3.4 Embedding --- 向量/嵌入

一句话解释：把一段文字变成一串数字，让计算机能算"两段话有多像"。

这是整个 RAG 系统的基础概念，稍微多解释两句。

人类理解"退款流程"和"退货办法"意思差不多，但计算机只知道这是一堆字符，看不出语义关系。Embedding 就是解决这个问题------它把每段文字映射成一个高维空间里的点（比如 1536 个数字组成的向量），意思相近的文字，对应的点在空间里离得近。

"退款流程" ──→ [0.12, -0.34, 0.56, ..., 0.78]    ← 向量 A
"退货办法" ──→ [0.11, -0.33, 0.55, ..., 0.76]    ← 向量 B（和 A 很接近）

"天气怎么样" ──→ [-0.45, 0.67, -0.23, ..., 0.12]  ← 向量 C（离 A、B 很远）

在咱们项目里：知识库里的每段资料都会被转成 Embedding 向量，存到 Milvus 里。用户问了一个问题，先把问题也转成向量，然后在 Milvus 里找"离得最近"的几段资料，拿回来喂给 LLM，这样 AI 就能基于真实资料回答了。

3.5 向量数据库

一句话解释：专门存和查 Embedding 向量的数据库。

普通数据库（MySQL、MongoDB）擅长精确查询："找出 status = 'active' 的订单"。但向量数据库擅长的是相似度查询："找出跟这段文字语义最接近的 5 条记录"。

常见的向量数据库有 Milvus、Pinecone、Weaviate、Qdrant 等。咱们项目选的是 Milvus，因为它开源、功能强、国内用的人多，而且有 Milvus Lite 这种开发模式，本地跑零部署，后面上生产再切 Milvus Server 或 Zilliz Cloud 就行。

3.6 RAG --- 检索增强生成

一句话解释：先从知识库里查资料，再让 AI 基于查到的资料来回答。

RAG 是这三个英文单词的缩写：Retrieval-Augmented Generation。

没有 RAG 的时候，AI 只能靠自己的"记忆"来回答，知识有截止日期，也不知道你公司内部的信息。有了 RAG，流程变成了这样：

用户提问："StarPods Pro 怎么连接电脑？"
        │
        ▼
  ┌──────────────┐
  │  第一步：检索   │  去向量数据库里搜跟这个问题最相关的资料
  │  (Retrieval)  │  找到："StarPods Pro 支持 Bluetooth 5.3..."
  └──────┬───────┘
         │
         ▼
  ┌──────────────┐
  │  第二步：增强   │  把用户问题 + 搜到的资料一起丢给 LLM
  │  (Augmented)  │  "请根据以下资料回答用户问题：..."
  └──────┬───────┘
         │
         ▼
  ┌──────────────┐
  │  第三步：生成   │  LLM 基于资料，生成准确、有据可查的回答
  │  (Generation) │  "StarPods Pro 连接电脑很简单..."
  └──────────────┘

为什么这很重要：因为没有 RAG 的 AI 容易"幻觉"------自信满满地胡编乱造。加上 RAG 之后，AI 的回答就有了"出处"，可靠程度大幅提升。这是第三章的核心内容。

3.7 Agent --- 智能体

一句话解释 ：不只是"一问一答"的 AI，而是能自己思考、自己决定下一步做什么的 AI。

普通 LLM 对话：你问一句，它答一句，到此为止。

Agent 对话：你提一个需求，它会自己拆解任务、自己选择工具、自己判断做到什么程度算完成。

打个比方：

• 普通 LLM 像一个只会按指令干活的实习生------你让他查订单，他就查订单，你不说下一步他就等着
• Agent 像一个有经验的客服主管------你跟他说"有个客户投诉耳机有问题"，他会自己判断：先查订单信息 → 确认是否在保修期 → 评估是换货还是维修 → 自动建工单 → 安排跟进

在咱们项目里：整个智能客服就是一个 Agent。它会根据用户的消息，自己判断该走哪个流程------直接回答、查知识库、转人工、还是建工单。

3.8 LangChain

一句话解释：一个帮你快速搭建 AI 应用的 Python 框架。

直接调用 OpenAI API 当然可以，但一旦你的应用变复杂------要接知识库、要管理对话历史、要调用各种工具------代码很快就会乱成一团。LangChain 把这些常用的东西都封装好了：

• LCEL （LangChain Expression Language）：用 | 把各个组件串起来，像搭积木一样
• Memory：对话记忆管理
• Retriever：知识库检索
• Tool：工具调用
• LangGraph：复杂的工作流编排

后面大家写代码的时候会发现，LangChain 让整个开发体验顺畅很多。不用它当然也能做，但会多踩很多坑。

3.9 上下文窗口

一句话解释：AI 一次能"看到"的最大文字量。

之前提到 Token 的时候顺带提了一下。上下文窗口大小决定了你一次性能跟 AI 交流多少内容。

不同模型的上下文窗口不一样：

• GPT-4o：128K Token（大约 10 万字）
• DeepSeek V3：128K Token
• Claude 3.5：200K Token

在咱们项目里：这意味着我们需要策略性地管理对话内容。不可能把所有历史对话都塞给 AI，所以第二章会讲怎么用"滑动窗口"只保留最近几轮对话。

3.10 结构化输出

一句话解释 ：让 AI 不只返回一段话，而是返回一个格式化的数据结构（比如 JSON）。

普通的 AI 调用返回的是一段自然语言："用户看起来很生气，建议转人工"。

结构化输出返回的是：

{
  "emotion": "angry",
  "confidence": 0.92,
  "suggested_action": "escalate_to_human"
}

这在工程里特别重要------程序需要的是结构化的数据来判断流程，而不是一段需要再次解析的文字。后面第四章做情绪识别、第五章做工单生成，都会大量用到结构化输出。

3.11 Function Call --- 函数调用

一句话解释 ：让 AI 不只是"说"，而是能调用你写好的代码来做事。

之前咱们用的 AI 都只能"动嘴"------回答问题、提供建议，但它没办法帮用户查一下订单到哪了、库存还有多少。Function Call 就是来解决这个问题的。

工作流程是这样的：

用户："我的订单到哪了？"
        │
        ▼
  AI 理解意图 → "用户想查物流"
        │
        ▼
  AI 返回："请调用 query_order_status 函数，参数是 order_id"
        │
        ▼
  你的代码执行这个函数 → 从数据库查到 "快递已发出，预计明天到"
        │
        ▼
  把结果喂回给 AI → AI 生成自然语言回复："您的快递已经发出了，预计明天送达"

类比：AI 就像一个客服，他不能直接碰你们的系统，但他可以"喊"旁边的技术同事："帮我查一下这个订单"，查完之后他再用自然语言告诉客户。

在咱们项目里：第七章会详细讲怎么定义 Tool、怎么让 LLM 自动选择和调用工具。

3.12 Tool --- 工具

一句话解释：Function Call 的具体实现------把某个能力"包装"成一个 AI 可以调用的工具。

在 LangChain 里，一个 Tool 大概长这样：

@tool
def query_order_status(order_id: str) -> str:
    """查询订单的物流状态"""
    # 去数据库查，返回结果
    return "快递已发出，预计明天到"

LLM 看到这个函数的名字、参数说明和文档字符串，就能判断什么时候该调用它、传什么参数。

在咱们项目里：我们会给客服 Agent 配备一组工具------查订单、查物流、查库存、退款处理等，让 AI 能真正"动手做事"而不是只会说。

3.13 MCP --- Model Context Protocol

一句话解释 ：一个标准协议，让 AI 能通过统一的接口接入各种外部工具和数据源。

这是 Anthropic（Claude 的母公司）在 2024 年底提出来的开放标准。大家可以把 MCP 类比为"AI 领域的 USB 接口"------不管什么设备，只要符合 USB 标准，插上就能用。MCP 也是一样：不管什么工具（查数据库、调 API、读文件），只要实现了 MCP 协议，AI 就能用。

架构分三层：

┌─────────────────────────────┐
│   AI 应用（LLM Host）        │  ← 比如咱们的客服 Agent
│   ChatGPT / Claude / 自建    │
└──────────┬──────────────────┘
           │ MCP 协议
┌──────────▼──────────────────┐
│   MCP Client                 │  ← 内置在 AI 应用里
│   负责跟 MCP Server 通信      │
└──────────┬──────────────────┘
           │
    ┌──────┼──────┬──────────┐
    ▼      ▼      ▼          ▼
┌──────┐┌──────┐┌──────┐┌──────┐
│Server││Server││Server││Server│
│数据库 ││文件  ││API   ││搜索  │
└──────┘└──────┘└──────┘└──────┘

为什么这很重要：以前每接一个新工具，都要写专门的适配代码。有了 MCP，工具提供方只要实现一次 MCP Server，所有支持 MCP 的 AI 应用就都能用了。相当于工具生态的一次"标准化"。

在咱们项目里：第十章会实现一个简单的 MCP Server，把客服常用工具（查订单、查知识库等）暴露为 MCP 接口。

3.14 Skills --- 技能

一句话解释 ：把一组相关的 Tool + Prompt + 知识打包成一个"技能包"，AI 可以按需加载。

大家玩过 RPG 游戏吧？角色有不同技能------"火球术""治疗术""潜行"，每个技能是独立的一套能力。AI Agent 的 Skills 也是这个意思：

skills = {
    "refund_skill": {
        "description": "处理退款相关请求",
        "tools": ["query_order", "process_refund", "send_notification"],
        "prompt": "你是退款专员...",
        "knowledge": "退款政策文档"
    },
    "tech_support_skill": {
        "description": "处理技术故障",
        "tools": ["query_device", "check_firmware", "create_repair_ticket"],
        "prompt": "你是技术支持...",
        "knowledge": "故障排查手册"
    }
}

跟 MCP 的关系：MCP 是底层通信协议，Skills 是上层的能力组织方式。MCP 解决的是"怎么连"，Skills 解决的是"怎么管"。

在咱们项目里：第十章会把不同业务场景（退款、技术支持、物流查询）打包成不同 Skills，让客服 Agent 根据用户问题自动选择合适的技能包。

3.15 ReAct --- 推理与行动交织

一句话解释 ：让 AI 边想边做------每一步都是"想一想该做什么→做了→看看结果→再想下一步"。

ReAct 是 Reasoning + Acting 的缩写，2022 年的一篇论文提出的，是目前最主流的 Agent 模式。核心循环长这样：

Thought（思考）："用户要查订单，我需要先拿到订单号"
    → Action（行动）：调用 query_order("ORD-001")
    → Observation（观察）：查到了，订单已发货 3 天
    → Thought（再思考）："用户还说要退货，3 天在退货期内"
    → Action（再行动）：调用 check_refund_policy(...)
    → Observation（再观察）：7 天内可全额退
    → Answer（最终回答）："您的订单在退货期内，可以在..."

特点：没有提前规划，走一步看一步。好处是灵活，简单问题处理得快；坏处是复杂问题可能"绕弯路"------因为缺乏全局视角。

跟下一节 Plan-Execute-Replan 的关系：Plan-Execute-Replan 可以理解为 ReAct 的"升级版"------加了全局规划能力。简单问题用 ReAct 就够了，复杂问题用 Plan-Execute-Replan 更靠谱。第七章的 ToolAgent 本质上就是一个 ReAct 循环。

3.16 Plan-Execute-Replan --- 规划执行框架

一句话解释 ：让 AI 自己先想好怎么做（Plan）→ 一步一步执行（Execute）→ 发现不对就调整（Replan）。

这是解决复杂问题的一种经典思路。简单问题（"查一下我的订单"）一步就能搞定，但复杂问题需要多步：

用户："我买了两个耳机，一个有杂音一个连不上，都要退，但其中一个超了 7 天"

Plan 阶段（AI 自己规划）：
  1. 查询两个订单的详细信息
  2. 分别判断是否在退货期内
  3. 对于在退货期内的：走正常退款流程
  4. 对于超出退货期的：查看是否有质保政策
  5. 生成两个工单，分别处理
  6. 汇总结果告知用户

Execute 阶段（逐步执行）：
  执行第 1 步 → 查到订单 A（购于 5 天前）、订单 B（购于 12 天前）
  执行第 2 步 → A 在退货期内，B 超出 7 天

Replan 阶段（根据中间结果调整）：
  发现 B 超出退货期 → 查质保政策 → 发现质保期 1 年，可以换新
  调整计划：A 走退款，B 走换新

最终汇总：告知用户两个订单的不同处理方案

在咱们项目里：第八章会用 LangGraph 实现这个 Plan-Execute-Replan 循环，让 AI 能自主处理这种需要多步推理的复杂客服场景。

3.17 Multi-Agent --- 多智能体协作

一句话解释 ：不是一个 AI 包揽所有事，而是多个 AI 各司其职、互相配合。

单 Agent 系统像一个"全能客服"，什么都能做但什么都不精。Multi-Agent 系统像一个客服团队：

                    ┌─────────────────┐
                    │   用户发来消息    │
                    └────────┬────────┘
                             │
                    ┌────────▼────────┐
                    │  接待 Agent      │  ← "前台"
                    │  初步理解、分流   │
                    └────────┬────────┘
                             │
              ┌──────────────┼──────────────┐
              │              │              │
     ┌────────▼──────┐┌─────▼────────┐┌───▼──────────┐
     │  售后 Agent    ││ 技术支持 Agent ││ 投诉处理 Agent │
     │  退款/退货/换新││ 故障排查/维修  ││ 升级/补偿/安抚│
     └────────┬──────┘└─────┬────────┘└───┬──────────┘
              │              │              │
              └──────────────┼──────────────┘
                             │
                    ┌────────▼────────┐
                    │  主管 Agent      │  ← 质量把控、最终决策
                    │  审核工单、分配   │
                    └─────────────────┘

每个 Agent 有自己的 Prompt、Tools 和 Skills，专注自己的领域。Agent 之间通过消息传递协调工作。

跟 Plan-Execute-Replan 的关系：Plan-Execute-Replan 是一个 Agent 内部的思考方式，Multi-Agent 是多个 Agent 之间的协作方式。复杂系统通常两者结合------每个 Agent 内部可以做规划，Agent 之间也可以互相派活。

在咱们项目里：第九章会实现一个 Multi-Agent 客服系统，接待 Agent 负责分流，专业 Agent 负责处理，主管 Agent 负责审核和兜底。

---

4. 这些概念怎么串起来

看完了名词解释，可能有人会觉得："概念好多，它们之间什么关系？"

画个全景图帮大家串一下：

                        ┌──────────────┐
                        │   用户消息     │
                        └──────┬───────┘
                               │
                        ┌──────▼───────┐
                        │    Agent     │  ← 整个系统的"指挥官"
                        │  (LangGraph) │     用 LangGraph 编排工作流
                        └──────┬───────┘
                               │
       ┌───────────┬───────────┼───────────┬──────────┐
       │           │           │           │          │
┌──────▼──────┐┌───▼───┐┌─────▼────┐┌────▼─────┐┌───▼──────┐
│   LLM 推理   ││  RAG  ││结构化输出 ││  Tools   ││  Agent  │
│  理解意图    ││查知识库││返回 JSON ││调用工具   ││  协作    │
└──────┬──────┘└───┬───┘└─────┬────┘└────┬─────┘└───┬──────┘
       │           │           │           │          │
       │    ┌──────▼─────┐    │    ┌──────▼──────┐   │
       │    │  Embedding │    │    │ MCP Server  │   │
       │    │  文字→向量  │    │    │ 标准化接口   │   │
       │    └──────┬─────┘    │    └─────────────┘   │
       │           │          │                      │
       │    ┌──────▼─────┐    │              ┌───────▼────────┐
       │    │  向量数据库  │    │              │  Multi-Agent   │
       │    │  (Milvus)  │    │              │  多智能体协作    │
       │    └────────────┘    │              └────────────────┘
       │                     │
       └──────────┬──────────┘
                  │
           ┌──────▼───────┐
           │  Prompt +    │
           │  Memory +    │  ← 每轮对话都有上下文
           │  Skills +    │     技能包按需加载
           │  Plan-Execute│     复杂问题先规划再执行
           └──────────────┘

整个项目就是围绕这张图来展开的：

概念	在哪章学
LLM、Prompt、Memory	第一章、第二章
Embedding、向量数据库、RAG	第三章
结构化输出	第四章（情绪识别）、第五章（工单生成）
Function Call、Tool Use、ReAct	第七章
Plan-Execute-Replan	第八章
Multi-Agent 多智能体协作	第九章
MCP 协议、Skills 技能体系	第十章
Agent 编排与系统集成	第十一章（完整集成）

---

5. 需要什么基础

大家最好有：

• Python 基础：能写函数、能用 pip 装包、能理解类和对象就行
• 基本的命令行操作：会 cd、会跑 python 脚本
• 听说过 LLM：用过 ChatGPT 或类似产品，知道它能干什么

不需要：

• 不需要 AI/机器学习背景
• 不需要了解 Transformer、注意力机制这些底层原理
• 不需要提前学过 LangChain

如果你能看懂 print("Hello World") 和 pip install xxx，那就够了。

---

6. 课程怎么用

• 跟着顺序来：从第一章到第十一章，每章都依赖前面的代码
• 代码一定要跑：看懂 ≠ 跑过。建议边看文档边在本地跑，改改参数看效果
• 结合实际场景思考：学到知识库，想想自己公司的文档能不能用；学到工单系统，想想现在的售后流程怎么优化；学到 Multi-Agent，想想团队里怎么分工
• 遇到问题先查文档：每章的 README 下方有"常见问题"，大部分坑都帮你踩过了

---

下一章

第一章：环境搭建与基础对话

下一章正式动手，搭环境、写代码、跑出第一个会说话的 AI 客服。

---

完整版合集、面试题库、项目实战，全网同名【图解 AI 系列】