LangChain智能客服实战：从零构建高可用AI对话系统

最近在做一个智能客服项目，从零开始踩了不少坑，也积累了一些经验。传统客服系统要么靠人工，要么是规则引擎，维护起来太痛苦了。规则写少了不够用，写多了又容易冲突，特别是遇到一些长尾问题，用户问得稍微绕一点，系统就懵了。正好LangChain这个框架挺火的，就尝试用它来构建一个更智能的客服系统，效果还不错，今天就来分享一下我的实战过程。

1. 为什么选择LangChain？传统客服的痛点与AI的机遇

在深入代码之前，我们先聊聊为什么需要LangChain。传统的客服系统，尤其是基于规则引擎的，有几个绕不开的痛点：

  • 冷启动成本高：上线前需要产品、运营、开发一起梳理海量的业务规则和问答对（FAQ），耗时耗力。
  • 长尾问题处理差：规则引擎只能覆盖预设的场景。用户一旦问出“规则外”的问题，比如组合提问或者表述非常口语化，系统就无法理解，只能转人工。
  • 维护困难：业务一变动，规则就要跟着改，牵一发而动全身，测试回归成本巨大。
  • 缺乏上下文：多轮对话中，用户经常会用“它”、“这个”、“上面说的”来指代，传统系统很难记住之前的对话历史，导致答非所问。

而LangChain的出现，正好能解决这些问题。它的核心优势在于“链”（Chain）和“智能体”（Agent）的思想。

  • 上下文维持：LangChain提供了多种记忆（Memory）组件，可以轻松地让大语言模型（LLM）记住整个对话历史，实现真正的多轮交互。
  • 工具调用：客服不只是回答问题，有时需要查订单、算运费、转人工。LangChain可以让LLM根据对话内容，自主判断并调用我们预先定义好的业务工具（函数），完成复杂任务。
  • 检索增强：单纯依赖LLM的“脑内知识”回答业务问题，容易产生“幻觉”（胡说八道）。LangChain可以很方便地集成RAG（Retrieval-Augmented Generation，检索增强生成），先从我们自己的知识库（产品文档、客服手册）里找到相关依据，再让LLM基于这些依据生成回答，准确率大幅提升。

简单说，LangChain像是一个“胶水”和“调度中心”，把强大的LLM、我们的业务数据、以及各种功能工具有机地组合在一起，形成一个真正可用的智能系统。

2. 技术方案选型：纯LLM vs. LangChain + RAG

在动手前，我做了一个简单的对比测试，结论很清晰。下面这个表格量化了两种方案的关键差异：

对比维度 纯LLM API调用方案 LangChain + RAG 方案 说明
响应延迟 较低 (200-500ms) 较高 (500-1500ms) RAG需要先进行向量检索，增加了耗时。但可通过缓存优化。
回答准确率 不稳定，易“幻觉” 高且稳定 RAG方案的回答基于提供的业务知识，有据可查，极大减少错误。
业务适应性 差 优秀 通过更新知识库即可让模型学习新业务，无需重新训练模型。
可解释性 差（黑盒） 好 可以追溯回答引用了知识库中哪份文档，方便排查和优化。
开发复杂度 低（简单封装） 中（需理解框架概念） LangChain引入了链、记忆等概念，学习曲线稍陡，但封装后更易维护。
多轮对话支持 需自行拼接历史 内置支持 ConversationChain等组件开箱即用，简化了上下文管理。
工具扩展能力 需自行设计调度逻辑 内置支持 Agent框架可让LLM自主选择调用工具，实现查订单、创建工单等复杂流程。

可以看到，虽然LangChain+RAG方案在响应速度上略有牺牲，但在准确性、可控性和可扩展性上具有压倒性优势，这对于要求严谨的客服场景来说是至关重要的。牺牲几百毫秒的延迟，换来回答可靠性的质变，这笔买卖非常划算。

3. 核心实现：一步步搭建智能客服骨架

理论说再多不如看代码。我们来搭建一个最核心的、具备记忆和知识检索能力的智能客服。

3.1 环境准备与LLM连接

首先，安装必要的包，这里以使用 OpenAI 的模型为例（你也可以替换为国内的其他模型API）。

pip install langchain langchain-openai faiss-cpu sentence-transformers

然后，在代码中初始化LLM。这里有一个非常重要的参数 temperature，它控制着模型输出的“创造性”或“随机性”。

  • temperature 接近 0：模型输出非常确定、保守，对于相同的问题，倾向于给出几乎一样的答案。适合客服、事实问答等需要准确、一致的场景。
  • temperature 接近 1（或更高）：模型输出更具创造性、多样性，但可能不够准确和稳定。适合创意写作、头脑风暴等场景。

对于客服系统，我们通常设置一个较低的 temperature，比如 0.1。

from langchain_openai import ChatOpenAI
import os

# 设置你的API Key，建议从环境变量读取
os.environ["OPENAI_API_KEY"] = "your-api-key-here"

# 初始化LLM，选择gpt-3.5-turbo，控制temperature为0.1以保证回答稳定
llm = ChatOpenAI(model="gpt-3.5-turbo", temperature=0.1)

3.2 构建对话记忆（Memory）

没有记忆的对话是痛苦的。LangChain 的 ConversationBufferMemory 可以帮我们自动保存和管理对话历史。

from langchain.memory import ConversationBufferMemory

# 初始化对话记忆，它会自动保存上下文
memory = ConversationBufferMemory(
    return_messages=True,  # 以消息列表格式返回历史
    memory_key="chat_history"  # 存储在链中的键名
)

# 我们可以手动测试一下记忆功能
memory.save_context({"input": "你们公司的退货政策是什么？"}, 
                    {"output": "我们支持7天无理由退货。"})
memory.save_context({"input": "运费谁承担？"}, 
                    {"output": "非质量问题的退货，运费由您承担。"})

# 查看记忆内容
print(memory.load_memory_variables({}))
# 输出会包含之前的对话历史，这样LLM在回答后续问题时就能知道上下文了。

3.3 集成业务知识库（RAG实现）

这是保证回答准确性的核心。我们使用 FAISS 这个高效的向量数据库来存储和检索知识。

第一步：准备知识文档并生成向量嵌入（Embedding）

假设我们有一个 knowledge_base.txt 文件，里面是客服问答对和产品文档。

from langchain_community.document_loaders import TextLoader
from langchain.text_splitter import RecursiveCharacterTextSplitter
from langchain_openai import OpenAIEmbeddings
from langchain_community.vectorstores import FAISS

# 1. 加载文档
loader = TextLoader("./knowledge_base.txt")
documents = loader.load()

# 2. 分割文本。LLM有上下文长度限制，必须把长文档切分成小块。
text_splitter = RecursiveCharacterTextSplitter(
    chunk_size=500,  # 每个块的最大字符数
    chunk_overlap=50  # 块之间的重叠字符，避免语义被切断
)
docs = text_splitter.split_documents(documents)

# 3. 使用Embedding模型将文本块转化为向量
embeddings = OpenAIEmbeddings()

# 4. 创建向量存储（Vector Store），这里使用FAISS
# 这一步会计算所有文本块的向量，并构建索引，可能耗时较长
vectorstore = FAISS.from_documents(docs, embeddings)

# 5. 将向量库保存到本地，下次直接加载即可，无需重复计算
vectorstore.save_local("faiss_index")

第二步：构建检索链，将知识库与LLM结合

from langchain.chains import RetrievalQA

# 直接从磁盘加载已创建好的向量库
loaded_vectorstore = FAISS.load_local("faiss_index", embeddings, allow_dangerous_deserialization=True)

# 创建检索器（Retriever），设定每次检索返回最相关的3个文档块
retriever = loaded_vectorstore.as_retriever(search_kwargs={"k": 3})

# 创建检索问答链（RetrievalQA Chain）
# 这个链会自动完成“检索相关文档 -> 将文档和问题组合成提示词 -> 发送给LLM -> 返回答案”的流程
qa_chain = RetrievalQA.from_chain_type(
    llm=llm,
    chain_type="stuff",  # 将检索到的所有文档“堆叠”在一起传给LLM，简单有效
    retriever=retriever,
    return_source_documents=True,  # 返回源文档，用于可解释性
    verbose=True  # 打印详细日志，调试时有用
)

# 测试知识库问答
result = qa_chain.invoke({"query": "商品签收后可以退货吗？"})
print(f"答案：{result['result']}")
print(f"参考来源：{result['source_documents'][0].page_content[:200]}...")  # 打印部分源文档

3.4 组装完整对话链

现在，我们把记忆（Memory）和知识检索（RAG）结合起来，形成一个既能记住对话历史，又能从知识库找答案的超级客服链。

from langchain.chains import ConversationalRetrievalChain

# 创建对话式检索链
chat_qa_chain = ConversationalRetrievalChain.from_llm(
    llm=llm,
    retriever=retriever,
    memory=memory,  # 传入我们之前创建的记忆对象
    return_source_documents=True,
    verbose=False
)

# 进行多轮对话测试
question1 = "我想退货，怎么操作？"
result1 = chat_qa_chain.invoke({"question": question1})
print(f"用户：{question1}")
print(f"AI：{result1['answer']}\n")

# 第二问，使用了指代词“它”
question2 = "需要保持它的包装完好吗？"
result2 = chat_qa_chain.invoke({"question": question2})
print(f"用户：{question2}")
print(f"AI：{result2['answer']}")
# 此时，AI因为有了记忆，知道“它”指的是“退货的商品”，从而能正确回答。

智能客服系统架构示意图

4. 生产环境考量：高可用与安全性

系统能跑起来只是第一步，要上线服务，还得过“生产环境”这一关。主要是应对高并发和保障安全。

4.1 压力测试与降级策略

线上流量可能瞬间暴涨，我们必须知道系统的瓶颈在哪里，并准备好应对方案。

  • 压测工具：使用 Locust 模拟用户并发请求非常方便。
  • 编写压测脚本：模拟用户提出各种典型问题。
  • 关键指标：关注 QPS（每秒查询率）、P95/P99响应时间、错误率。

当流量超过系统承受能力时，需要有降级策略：

  1. 限流：使用令牌桶等算法，拒绝部分请求，保证系统不崩溃。
  2. 缓存：对高频通用问题（如“营业时间”）的答案进行缓存，直接返回，绕过LLM和检索。
  3. 兜底回答：当LLM服务或检索服务超时/出错时，返回预设的兜底话术，如“当前咨询人数较多，请稍后再试”或引导用户使用菜单。
# 一个简单的缓存示例（伪代码）
from functools import lru_cache
import hashlib

@lru_cache(maxsize=100)
def get_cached_answer(user_question: str, chat_history_hash: str) -> Optional[str]:
    """对问题和对话历史进行哈希，作为缓存键"""
    pass

# 在调用链之前，先查缓存
cache_key = hash_question_and_history(current_question, chat_history)
cached_answer = get_cached_answer(cache_key)
if cached_answer:
    return cached_answer
else:
    # 调用LangChain链
    answer = qa_chain.invoke(...)
    # 将答案存入缓存
    set_cache(cache_key, answer)
    return answer

4.2 安全防护：日志脱敏与PII检测

客服对话中可能包含用户的手机号、地址、订单号等敏感信息（PII， Personally Identifiable Information）。这些信息绝不能明文存储在日志或数据库中。

  • 对话日志脱敏：在存储日志前，使用正则表达式或专门的NLP模型识别并替换敏感信息。
  • 实现PII检测：可以使用预训练模型或第三方服务来检测文本中的PII实体。
import re

def desensitize_text(text: str) -> str:
    """简单的正则脱敏示例"""
    # 脱敏手机号 (11位数字)
    text = re.sub(r'(1[3-9]\d{9})', r'\1****', text)
    # 脱敏身份证号 (18位，最后4位可能是数字或X)
    text = re.sub(r'([1-9]\d{5}(19|20)\d{2}(0[1-9]|1[0-2])(0[1-9]|[12]\d|3[01])\d{3}[\dXx])', r'\1****', text)
    # 脱敏邮箱
    text = re.sub(r'([a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,})', r'***@***.***', text)
    return text

# 在记录日志前调用
log_entry = f"用户提问：{user_input}， AI回答：{ai_response}"
safe_log_entry = desensitize_text(log_entry)
write_to_log(safe_log_entry)

5. 避坑指南：那些我踩过的“坑”

在开发过程中，我遇到了几个典型问题，这里分享出来，希望大家能避开。

  1. 避免链式调用过深导致的超时 LangChain的链可以嵌套，但过深的嵌套会导致单个请求处理路径非常长，极易超时。在设计工具调用（Agent）或复杂流程时，要评估每一步的耗时，并设置合理的总超时时间和每一步的超时时间。对于非核心步骤，考虑是否可以异步执行或提供超时后的默认值。

  2. 对话状态存储的序列化陷阱 当我们把 ConversationBufferMemory 存入Redis或数据库以便分布式服务共享时，需要序列化。LangChain的Memory对象可能包含复杂的对象引用。不要直接用Python的 pickle，因为它有安全风险且兼容性差。推荐使用 json 序列化，但需要确保Memory中的消息（Message）对象实现了 dict() 方法或使用LangChain提供的 to_json() / from_json() 方法。

  3. 知识库更新的版本灰度方案 业务知识是动态变化的。直接全量更新线上向量库风险很高。建议采用双向量库+流量切分的灰度方案：

    • 维护两个向量库：v1（当前线上）和 v2（待上线新版）。
    • 更新时，先全量构建 v2。
    • 上线时，将少量流量（如1%）导向 v2，对比 v1 和 v2 的回答质量。
    • 确认 v2 回答无误后，逐步放大流量至100%，完成平滑升级。

知识库灰度更新流程

6. 延伸思考：从问答到行动——自动化工单创建

一个更高级的智能客服，不仅能回答，还能行动。比如，用户反馈了一个无法在线解决的复杂问题，客服AI应该能自动创建工单，并分配给对应部门。这就可以用上LangChain的 Agent（智能体） 框架。

挑战在于：

  • 工具定义：需要创建一个 create_ticket(problem_description, user_info, priority) 的工具函数。
  • 权限与控制：Agent不能随意创建工单，必须在明确获得用户授权（如用户说“请帮我提单”）、且问题确实需要人工介入时才能触发。
  • 信息抽取：Agent需要从多轮对话中准确提取工单所需的字段（问题类型、联系人、紧急程度等）。

这里抛出一个实践挑战，也是我们团队正在探索的方向：

如何设计一个LangChain Agent，使其能在多轮客服对话中，智能判断何时需要创建工单，并自动填充工单信息？

你可以思考如何设计提示词（Prompt）来让LLM学会判断“创建工单”的时机，以及如何安全地调用工具。欢迎在评论区分享你的思路，或者提交一个简单的PR方案，我们一起讨论完善。

写在最后

从规则引擎到LangChain智能客服，最大的感受是“灵活性”和“可维护性”的提升。不再需要没完没了地写if-else规则，而是通过更新知识库和调整提示词来优化系统。虽然引入了LLM的调用成本和一些延迟，但带来的用户体验和客服效率的提升是显著的。

当然，这套系统还有很多优化空间，比如引入更快的向量数据库（如 Chroma），对检索结果做重排序（Re-ranking）以提高精度，或者用LangGraph来编排更复杂的客服工作流。希望这篇笔记能给你提供一个坚实的起点，祝你也能搭建出自己强大的AI对话系统。

Logo
AI Agent技术社区

Agent 垂直技术社区，欢迎活跃、内容共建。

更多推荐

cover

AI Agent 记忆系统设计：从短期上下文到长期知识持久化的工程实践

avatar AI Agent技术社区
cover

数以轻舟Agent：做表AI智能体与普通大模型直接处理数据的区别

avatar AI Agent技术社区
cover

DeerFlow Subagent 实现解析：基于 Tool 抽象的多智能体编排架构

avatar AI Agent技术社区