我用LangChain搭客服Agent，处理3万条FAQ的实战踩坑
前不久接了个电商后台项目，客户是个做家居用品的中型商家，客服团队每天要回两三千条咨询，大多是「发货没」「尺码怎么选」「能不能开发票」这种重复性问题。他们想上个智能客服先拦住 80% 的标准咨询，人工只接复杂工单。知识库大概有 3 万条 FAQ 文档，格式杂得很，有 Word、PDF、网页导出的 HTML，还有一堆客服群里沉淀的聊天记录 TXT。
选型时在 LangChain 和 LlamaIndex 里纠结半天
说实话，最开始我倾向于 LlamaIndex，索引构建那套 API 确实顺手。但转念一想，项目后期肯定要挂工具——查订单物流、改收货地址、申请退款，这些都要 Agent 去调 API。LangChain 的 Tool/Toolkit 体系和 ReAct Agent 现成，社区生态也更活，改动成本低。试了一圈发现，用create_react_agent配合AgentExecutor落地最快，哪怕中间层封装得有点重，赶工期它最稳。
向量库选了 Milvus 立alone 版，部署在客户内网服务器上，数据不出域。Embedding 模型用的bge-large-zh-v1.5，本地跑，延迟能接受。LLM 走的私有化部署的 Qwen2-72B，显存压力大，但安全合规过得去。
```python
核心检索链定义，后面 Agent 会把这个当 Tool 用
from langchain.chains import create_retrieval_chain
from langchain.chains.combine_documents import create_stuff_documents_chain
from langchain_core.prompts import ChatPromptTemplate
retrieval_prompt = ChatPromptTemplate.from_template("""
你是家居电商智能客服，仅根据下面检索到的知识库片段回答用户问题。
如果片段里没有答案，直接说“知识库暂无相关信息”，禁止编造。
片段：{context}
问题：{input}
""")
document_chain = create_stuff_documents_chain(llm, retrieval_prompt)
retrieval_chain = create_retrieval_chain(vectorstore.as_retriever(search_kwargs={"k": 5}), document_chain)
```
切分策略差点把我整吐了
这是个大坑。文档里全是「规格参数表」那种半结构化文本，加上客服聊天记录的长上下文。最先用RecursiveCharacterTextSplitter(chunk_size=500, chunk_overlap=50)，上线测试一看，检索全是断句，问「床垫承重多少」能匹配到「床垫」和「承重」在两个 chunk 里，回答直接幻觉。
当时我觉得加大 chunk_size 到 1000 就行，结果发现噪音更多，Top-K 里全是无关段落。后来咬牙上了语义切分SemanticChunker，配合breakpoint_threshold_type="gradient"，虽然嵌入调用量翻倍、建库慢了 40 分钟，但检索准确率肉眼可见地涨上来了。
还有个插曲：PDF 里的表格被PyMuPDF解析成乱七八糟的文本。没办法，只能针对规格书那类文件，单独写脚本用pdfplumber抠表格转 Markdown 再入库。有意思的是，这一步把「长宽高」「材质」「承重」这些字段结构化后，Agent 回答参数类问题基本零幻觉了。
```python
语义切分配置，建库慢但检索准
from langchain_experimental.text_splitter import SemanticChunker
from langchain_community.embeddings import HuggingFaceEmbeddings
embed_model = HuggingFaceEmbeddings(model_name="/models/bge-large-zh-v1.5")
text_splitter = SemanticChunker(
embed_model,
breakpoint_threshold_type="gradient",
breakpoint_threshold_amount=85
)
```
Agent 给工具描述写模糊了，上线第一天被用户薅秃
ReAct Agent 绑了三个 Tool：faq_retriever、order_query_api、transfer_human。提示词里对词里对order_query_api的描述写的是「查询订单信息，输入订单号」。结果用户发「我的货到哪了」，Agent 直接报错：Missing required parameter: order_id。
当时我觉得这锅不在我，用户不给单号我咋查。结果复盘发现，用户根本不知道要给单号，他们习惯说「帮我查一下」。坑死了，得在 Agent 系统提示词里加强约束：缺参数时必须先追问，不能直接报错抛异常。改完后效果好多了，但偶尔还是会把「查物流」和「改地址」搞混，后来在 Tool 的args_schema里加了Literal类型约束，配合 Few-shot 示例才稳住。
```python
Tool 定义加上严格参数校验和示例
from langchain_core.tools import StructuredTool
from pydantic import BaseModel, Field
from typing import Literal
class OrderQueryInput(BaseModel):
order_id: str = Field(description="18位数字订单号，例如：202407290001234567")
query_type: Literal["logistics", "detail", "refund_status"] = Field(description="查询类型：物流轨迹/订单详情/退款进度")
order_tool = StructuredTool.from_function(
func=query_order_api,
name="order_query_api",
description="查询订单物流、详情或退款进度。必须提供订单号。如果用户未提供，先追问。",
args_schema=OrderQueryInput,
return_direct=False
)
```
还有一个细节：AgentExecutor默认max_iterations=15，有次 Agent 陷入「调用检索 -> 觉得不够 -> 再调用检索」的死循环，把 Token 烧光了。加上early_stopping_method="force"和自定义的max_execution_time=30秒熔断，才彻底杜绝跑飞。
落地后的数据反馈
跑了两周，日均拦住 1600 条标准咨询，人工客服工单量下降 62%。剩下的 38% 里，有 15% 是 Agent 识别意图不对转人工（多为组合意图，如「换货且改地址」），23% 是知识库真没覆盖到的新 SKU 问题。
下一步打算把客服转人工的对话日志跑一遍 Embedding 聚类，自动生成候补 FAQ 补库。这套 LangChain + Milvus + 本地大模型的架构，在内网环境下跑通闭环，维护成本比预期低不少。
本文基于实际项目经验整理，欢迎在评论区交流技术问题。