我用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_chainfrom langchain.chains.combine_documents import create_stuff_documents_chainfrom langchain_core.prompts import ChatPromptTemplateretrieval_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_size500, chunk_overlap50)上线测试一看检索全是断句问「床垫承重多少」能匹配到「床垫」和「承重」在两个 chunk 里回答直接幻觉。当时我觉得加大 chunk_size 到 1000 就行结果发现噪音更多Top-K 里全是无关段落。后来咬牙上了语义切分SemanticChunker配合breakpoint_threshold_typegradient虽然嵌入调用量翻倍、建库慢了 40 分钟但检索准确率肉眼可见地涨上来了。还有个插曲PDF 里的表格被PyMuPDF解析成乱七八糟的文本。没办法只能针对规格书那类文件单独写脚本用pdfplumber抠表格转 Markdown 再入库。有意思的是这一步把「长宽高」「材质」「承重」这些字段结构化后Agent 回答参数类问题基本零幻觉了。python语义切分配置建库慢但检索准from langchain_experimental.text_splitter import SemanticChunkerfrom langchain_community.embeddings import HuggingFaceEmbeddingsembed_model HuggingFaceEmbeddings(model_name/models/bge-large-zh-v1.5)text_splitter SemanticChunker(embed_model,breakpoint_threshold_typegradient,breakpoint_threshold_amount85)Agent 给工具描述写模糊了上线第一天被用户薅秃ReAct Agent 绑了三个 Toolfaq_retriever、order_query_api、transfer_human。提示词里对词里对order_query_api的描述写的是「查询订单信息输入订单号」。结果用户发「我的货到哪了」Agent 直接报错Missing required parameter: order_id。当时我觉得这锅不在我用户不给单号我咋查。结果复盘发现用户根本不知道要给单号他们习惯说「帮我查一下」。坑死了得在 Agent 系统提示词里加强约束缺参数时必须先追问不能直接报错抛异常。改完后效果好多了但偶尔还是会把「查物流」和「改地址」搞混后来在 Tool 的args_schema里加了Literal类型约束配合 Few-shot 示例才稳住。pythonTool 定义加上严格参数校验和示例from langchain_core.tools import StructuredToolfrom pydantic import BaseModel, Fieldfrom typing import Literalclass OrderQueryInput(BaseModel):order_id: str Field(description18位数字订单号例如202407290001234567)query_type: Literal[logistics, detail, refund_status] Field(description查询类型物流轨迹/订单详情/退款进度)order_tool StructuredTool.from_function(funcquery_order_api,nameorder_query_api,description查询订单物流、详情或退款进度。必须提供订单号。如果用户未提供先追问。,args_schemaOrderQueryInput,return_directFalse)还有一个细节AgentExecutor默认max_iterations15有次 Agent 陷入「调用检索 - 觉得不够 - 再调用检索」的死循环把 Token 烧光了。加上early_stopping_methodforce和自定义的max_execution_time30秒熔断才彻底杜绝跑飞。落地后的数据反馈跑了两周日均拦住 1600 条标准咨询人工客服工单量下降 62%。剩下的 38% 里有 15% 是 Agent 识别意图不对转人工多为组合意图如「换货且改地址」23% 是知识库真没覆盖到的新 SKU 问题。下一步打算把客服转人工的对话日志跑一遍 Embedding 聚类自动生成候补 FAQ 补库。这套 LangChain Milvus 本地大模型的架构在内网环境下跑通闭环维护成本比预期低不少。本文基于实际项目经验整理欢迎在评论区交流技术问题。
