基于LangGraph的多智能体客服系统：架构设计与工程实践

1. 为什么大模型客服需要多智能体协作1.1 单模型客服的三个死穴做过客服系统的人都有一个共识传统智能客服的体验天花板极低。早期基于规则引擎的方案维护成本高得离谱业务改一个话术就要动代码后来上了意图识别加FAQ匹配能应付简单问答但用户一旦多问两句就露馅。大模型出来之后很多人以为直接把问题丢给模型就完事了实际落地才发现三个绕不过去的坎。第一个坎是幻觉问题。大模型在客服场景里最怕的就是“一本正经地胡说八道”。用户问退货政策模型编出一个根本不存在的条款这种事故一次就够客服团队喝一壶的。第二个坎是上下文管理。客服对话往往涉及订单号、物流状态、历史工单等多维信息单模型很难同时兼顾意图理解、信息检索和话术生成。第三个坎是流程控制。真实客服场景不是一问一答就结束而是包含意图识别、信息收集、知识检索、工单流转、人工转接等多个环节单模型无法可靠地串联这些步骤。这三个问题的本质是客服不是一个单一任务而是一组任务的编排。把所有这些任务塞给一个模型就像让一个员工同时干销售、技术支持和财务结果必然是样样稀松。1.2 多智能体协作到底解决了什么多智能体Multi-Agent的思路很朴素既然一个模型干不好所有事那就拆成多个专职的智能体各管一摊通过编排框架协调工作。具体到客服场景通常拆成这么几个角色意图识别智能体负责判断用户这句话到底想干什么是查订单、问政策、投诉还是闲聊。知识检索智能体根据意图去知识库、FAQ库、产品文档里捞相关内容。对话管理智能体维护多轮对话的状态记住用户之前说了什么当前处于哪个流程节点。回复生成智能体综合前面所有信息生成最终回复话术。转人工判断智能体判断当前情况是否需要升级到人工客服。这种拆分带来的好处是显而易见的。每个智能体只需要专注自己的职责提示词可以写得更精准输出更可控。意图识别智能体不需要知道退货政策的具体内容它只需要准确分类知识检索智能体不需要理解用户情绪它只需要高效召回。职责单一意味着提示词更短、更聚焦、更不容易出错。更重要的是多智能体架构天然支持流程编排。LangGraph这类框架把智能体之间的流转关系用图Graph的方式定义出来你可以精确控制什么条件下走哪条路径。比如用户情绪激动时直接跳过知识检索走安抚话术加转人工用户问的是简单FAQ时意图识别后直接命中答案不需要走完整流程。这种灵活性是单模型方案给不了的。1.3 LangGraph为什么成了首选编排框架在多智能体编排这个领域LangGraph目前是社区热度最高的选择之一。它的核心设计理念是把智能体工作流建模成有向图节点是智能体或工具调用边是流转条件。相比LangChain早期的Chain模式LangGraph最大的优势是支持循环和条件分支。客服对话天然是一个循环结构用户说话、系统理解、系统回复、用户再说。Chain模式只能线性执行遇到需要反复确认、多轮追问的场景就很别扭。LangGraph的图结构可以轻松表达“如果信息不全就回到上一步继续问”这种逻辑。另一个关键特性是状态管理。LangGraph内置了状态State机制整个对话过程中的所有信息——用户输入、意图分类结果、检索到的知识、已收集的槽位——都放在一个共享状态里每个节点都可以读写。这比手动维护对话上下文要可靠得多。还有一点值得提的是工具调用Tool Calling。LangGraph对工具调用的支持很成熟你可以把查订单API、知识库检索、工单系统接口都封装成工具让智能体在需要的时候自主调用。这比在提示词里硬编码“请调用XX接口”要优雅得多也更稳定。2. 系统整体架构与核心模块拆解2.1 从用户输入到回复输出的完整链路一个典型的多智能体客服系统从用户发消息到收到回复大致经过这么几个阶段用户输入首先进入预处理模块做敏感词过滤、输入清洗、会话ID绑定。然后进入路由智能体判断这是新会话还是已有会话的延续如果是新会话就初始化状态如果是延续就加载历史状态。接下来是意图识别智能体对用户当前这句话做分类。分类结果通常是一个结构化输出包含意图类型查订单/问政策/投诉/闲聊/其他和置信度。如果置信度低于阈值系统会走澄清流程让用户确认意图。意图明确后进入知识检索智能体。根据意图类型选择对应的知识源进行检索。查订单就走订单API问政策就走FAQ向量库投诉就走工单系统。检索结果会写入共享状态。然后是回复生成智能体它拿到用户原始输入、意图分类、检索结果、历史对话综合生成回复。这里通常会做一层安全校验检查生成的回复是否包含敏感信息、是否与检索结果矛盾、是否符合话术规范。最后是转人工判断。如果用户明确要求转人工或者情绪分析显示用户极度不满或者连续多轮未能解决问题系统会触发转人工流程把当前会话状态打包推送给人工客服。整个链路在LangGraph里就是一张图每个环节是一个节点节点之间的边定义了流转条件。这种可视化、可调试的结构比一坨if-else代码要好维护得多。2.2 状态设计整个系统的记忆中枢多智能体系统的核心是共享状态。在LangGraph里状态通常定义为一个TypedDict或Pydantic模型包含所有需要在节点之间传递的字段。一个客服系统的状态设计大概长这样class CustomerServiceState(TypedDict): messages: list # 对话历史 user_input: str # 当前用户输入 intent: str # 意图分类结果 intent_confidence: float # 意图置信度 retrieved_knowledge: str # 检索到的知识 order_info: dict # 订单信息 sentiment: str # 情绪分析结果 need_human: bool # 是否需要转人工 turn_count: int # 对话轮次 session_id: str # 会话ID这个状态设计有几个讲究。messages字段用列表存储完整对话历史方便生成智能体参考上下文。intent和intent_confidence分开存置信度用于后续的条件判断。retrieved_knowledge存检索结果生成智能体直接读这个字段不需要自己再去查。turn_count用于判断是否超过最大轮次超过就强制转人工。状态设计的一个常见坑是字段太多导致状态臃肿。我见过有人把用户画像、历史订单、浏览记录全塞进状态里结果每次节点流转都要序列化一大坨数据性能很差。建议只放当前对话必需的信息其他数据按需查询。另一个坑是状态更新冲突。多个节点同时写同一个字段时要明确谁有权限写。LangGraph的状态更新是覆盖式的后写的会覆盖先写的。所以最好约定好每个字段的写入节点避免混乱。2.3 意图识别智能体的提示词工程意图识别是整个流程的入口它的准确性直接决定后续环节的效率。这个智能体的提示词设计有几个关键点第一意图类别要穷举且互斥。不能出现“其他”这种模糊类别占比过高的情况。如果业务场景复杂可以先做粗分类咨询/办理/投诉再做细分类咨询下面分订单咨询/产品咨询/政策咨询。第二输出格式要结构化。让模型输出JSON格式包含intent和confidence两个字段。这样程序可以直接解析不需要再做文本处理。第三要给出明确的判断依据。在提示词里写清楚每个意图的定义和典型例句。比如“查订单”的定义是“用户询问订单状态、物流进度、预计送达时间等”典型例句包括“我的快递到哪了”“订单什么时候发货”。第四要处理边界情况。用户可能一句话包含多个意图比如“我的订单还没到你们怎么回事”。这时候要定义优先级规则通常投诉类意图优先于查询类意图。一个实际可用的意图识别提示词大概是这样你是一个客服意图分类助手。请根据用户输入判断其意图类别。 可选类别 - query_order: 查询订单状态、物流信息、配送进度 - query_policy: 咨询退换货政策、保修政策、发票政策 - complaint: 投诉、表达不满、要求赔偿 - chitchat: 闲聊、问候、与业务无关的对话 - human_service: 明确要求转人工客服 输出格式严格JSON {intent: 类别名, confidence: 0.0-1.0} 用户输入{user_input}这个提示词看起来简单但实际调优时需要在类别定义和例句上花大量功夫。我的经验是每个类别至少准备20个真实用户问法作为参考让模型有足够的判断依据。2.4 知识检索智能体的RAG实现知识检索智能体负责从知识库中召回与用户问题相关的内容。目前主流方案是RAG检索增强生成核心流程是把知识库文档切块、向量化、存入向量数据库用户提问时把问题也向量化做相似度检索返回Top-K相关片段。在客服场景里RAG有几个特殊考量。第一知识库要分层。FAQ类知识适合用向量检索订单类信息适合用API查询产品文档适合用关键词加向量混合检索。不同类型的知识走不同的检索通道由检索智能体根据意图来路由。第二切块策略要针对客服场景优化。客服知识往往是短文本一条FAQ就是一个完整的问答对。切块时应该以问答对为单位而不是按固定字数切。否则会出现“答案被切到两个块里”的情况检索出来不完整。第三要处理检索不到的情况。如果相似度低于阈值检索智能体应该返回“未找到相关知识”而不是硬凑一个不相关的片段。生成智能体拿到这个信号后应该走兜底话术比如“这个问题我暂时无法回答为您转接人工客服”。第四要支持多路召回。单一向量检索在客服场景下召回率往往不够。我的做法是向量检索加BM25关键词检索双路并行然后做融合排序。实测下来双路召回的准确率比单路向量检索能提升15%到20%。2.5 回复生成智能体的安全护栏回复生成是最后一道关卡也是最容易出问题的地方。大模型在这里可能犯的错包括编造不存在的政策、泄露系统提示词、生成不当言论、回复与检索结果矛盾。安全护栏的设计分三层。第一层是提示词约束在系统提示词里明确写清楚“只根据提供的知识回答”“不知道就说不知道”“不要编造信息”。第二层是输出校验生成后用规则或小模型检查回复是否包含敏感词、是否与检索结果有事实冲突。第三层是兜底策略如果校验不通过直接走预设的兜底话术不把有问题的回复发给用户。提示词约束的写法很关键。不要写“请不要编造信息”这种否定式指令模型对否定式指令的遵循度往往不高。更好的写法是正面引导“你的回答必须基于以下知识片段。如果知识片段中没有相关信息请回复‘这个问题我暂时无法回答’。”输出校验可以用一个轻量级的NLI自然语言推理模型判断生成的回复是否被检索到的知识所蕴含。如果蕴含度低于阈值就判定为可能幻觉触发兜底。这个方案会增加一点延迟但在客服场景里准确性比速度更重要。3. 从零搭建的实操步骤与关键配置3.1 环境准备与依赖安装动手之前先把环境搭好。Python版本建议3.10以上LangGraph对Python版本有一定要求。核心依赖包括langgraph、langchain、langchain-openai或对应模型提供商的包、chromadb向量库、fastapi对外接口。pip install langgraph langchain langchain-openai chromadb fastapi uvicorn如果你用的是国产大模型比如通义千问、智谱GLM、DeepSeek把langchain-openai换成对应的集成包即可。LangGraph本身不绑定模型任何支持工具调用的模型都能接入。向量库的选择上开发阶段用Chroma就够了轻量、零配置。生产环境如果数据量大可以考虑Milvus或Qdrant。嵌入模型可以用OpenAI的text-embedding-3-small也可以用开源的BGE系列中文场景下BGE-large-zh效果不错。注意LangGraph的版本迭代比较快API偶有变动。建议锁定版本号比如langgraph0.2.x避免因为版本升级导致代码跑不起来。3.2 定义状态与构建图先定义状态结构然后创建StateGraph实例把各个节点注册进去。from langgraph.graph import StateGraph, END from typing import TypedDict, Annotated import operator class CSState(TypedDict): messages: Annotated[list, operator.add] user_input: str intent: str confidence: float knowledge: str need_human: bool turn_count: int graph StateGraph(CSState) # 注册节点 graph.add_node(classify_intent, classify_intent_node) graph.add_node(retrieve_knowledge, retrieve_knowledge_node) graph.add_node(generate_reply, generate_reply_node) graph.add_node(check_human, check_human_node) graph.add_node(human_handoff, human_handoff_node) # 设置入口 graph.set_entry_point(classify_intent) # 定义边和条件 graph.add_edge(classify_intent, retrieve_knowledge) graph.add_edge(retrieve_knowledge, generate_reply) graph.add_edge(generate_reply, check_human) graph.add_conditional_edges( check_human, should_handoff, {handoff: human_handoff, continue: END} ) graph.add_edge(human_handoff, END) app graph.compile()这里有个细节messages字段用了Annotated[list, operator.add]这是LangGraph的状态更新机制。默认情况下节点返回的新状态会覆盖旧状态但用operator.add标注后列表会做追加而不是覆盖。这对于对话历史这种需要累积的字段很重要。3.3 意图识别节点的实现意图识别节点接收用户输入调用大模型做分类把结果写入状态。from langchain_openai import ChatOpenAI import json llm ChatOpenAI(modelgpt-4o-mini, temperature0) INTENT_PROMPT 你是一个客服意图分类助手。根据用户输入判断意图。 类别定义 - query_order: 查询订单、物流、配送 - query_policy: 咨询退换货、保修、发票政策 - complaint: 投诉、不满、要求赔偿 - human_service: 要求转人工 - chitchat: 闲聊或其他 只输出JSON{{intent: 类别, confidence: 0.0-1.0}} 用户输入{input} def classify_intent_node(state: CSState): prompt INTENT_PROMPT.format(inputstate[user_input]) response llm.invoke(prompt) try: result json.loads(response.content) return { intent: result[intent], confidence: result[confidence], turn_count: state.get(turn_count, 0) 1 } except (json.JSONDecodeError, KeyError): return {intent: chitchat, confidence: 0.0}这里用temperature0是为了让输出更稳定。意图分类不需要创造性需要的是确定性。解析失败时兜底到chitchat避免整个流程崩溃。3.4 知识检索节点的RAG集成检索节点根据意图选择检索策略把召回内容写入状态。from langchain_community.vectorstores import Chroma from langchain_openai import OpenAIEmbeddings embeddings OpenAIEmbeddings(modeltext-embedding-3-small) vectorstore Chroma(persist_directory./kb, embedding_functionembeddings) def retrieve_knowledge_node(state: CSState): intent state[intent] if intent query_order: # 走订单API查询 order_info query_order_api(state[user_input]) return {knowledge: str(order_info)} elif intent query_policy: # 走向量检索 docs vectorstore.similarity_search(state[user_input], k3) knowledge \n.join([d.page_content for d in docs]) return {knowledge: knowledge} elif intent complaint: # 投诉类走安抚话术库 return {knowledge: 用户正在投诉请先安抚情绪再询问具体问题。} else: return {knowledge: }检索策略的分流是提升准确率的关键。订单类问题走API能拿到实时数据比向量检索靠谱得多。政策类问题走向量检索因为政策文档相对静态。投诉类问题不需要检索知识需要的是情绪安抚话术。3.5 回复生成与转人工判断生成节点综合所有信息产出回复转人工节点做最终判断。REPLY_PROMPT 你是客服助手。根据以下信息回复用户。 用户问题{input} 意图{intent} 参考知识{knowledge} 要求 1. 只根据参考知识回答不要编造 2. 如果参考知识为空回复这个问题我暂时无法回答为您转接人工客服 3. 语气友好专业不要使用亲等过度亲昵的称呼 4. 回复控制在100字以内 def generate_reply_node(state: CSState): prompt REPLY_PROMPT.format( inputstate[user_input], intentstate[intent], knowledgestate[knowledge] ) response llm.invoke(prompt) return {messages: [{role: assistant, content: response.content}]} def check_human_node(state: CSState): need False if state[intent] human_service: need True if state.get(turn_count, 0) 5: need True if state[confidence] 0.3: need True return {need_human: need} def should_handoff(state: CSState): return handoff if state[need_human] else continue转人工的判断条件可以灵活调整。除了上面列的三种情况还可以加入情绪分析结果、用户重复提问次数等维度。核心原则是宁可多转不要漏转。用户被转人工只是多等一会儿但用户被机器反复绕圈子是会直接流失的。4. 踩坑实录与性能优化经验4.1 多智能体系统最常见的五个坑坑一状态字段膨胀导致性能下降。我一开始把用户画像、历史订单、浏览记录全塞进状态结果每次节点流转都要序列化几百KB的数据响应时间从1秒涨到3秒。后来改成按需查询状态里只保留当前对话必需的信息性能立刻恢复。坑二意图分类的置信度阈值设得太低。阈值设0.3时很多模棱两可的问题被强行分类导致后续检索和生成都跑偏。后来调到0.6低于阈值的走澄清流程整体准确率明显提升。坑三检索结果直接塞给生成模型。检索出来的片段可能有冗余、有矛盾直接丢给模型会让它困惑。后来加了一层检索结果重排和去重只保留最相关的2到3条生成质量稳定了很多。坑四忽略对话历史的截断。多轮对话后messages列表越来越长超出模型上下文窗口。后来加了滑动窗口只保留最近10轮对话更早的做摘要压缩。坑五转人工流程没有状态同步。用户转人工后人工客服看不到之前的对话记录和检索结果用户要重新说一遍问题。后来在转人工节点把完整状态打包推送到工单系统人工客服一接入就能看到全部上下文。4.2 响应延迟的优化手段多智能体系统的延迟主要来自多次模型调用。意图识别一次、检索一次、生成一次串行下来至少2到3秒。优化手段有几个并行化意图识别和情绪分析可以并行执行两者互不依赖。用LangGraph的并行节点或者asyncio.gather都能实现。缓存高频问题的意图分类结果和检索结果可以缓存。比如“退货政策”这种问题意图和知识基本不变缓存命中后直接跳过模型调用。小模型替代意图识别和情绪分析用7B级别的小模型就够了不需要上GPT-4。生成环节再用大模型。这样整体成本降下来速度也快不少。流式输出生成节点用流式输出用户看到第一个字的时间能缩短到500毫秒以内体验上感觉快很多。实测下来优化前平均响应时间3.2秒优化后能压到1.5秒左右。对于客服场景2秒以内是用户可以接受的阈值。4.3 效果评估与持续迭代系统上线不是终点持续迭代才是。评估指标分三层指标层级具体指标目标值意图层意图分类准确率90%检索层知识召回率85%生成层回复准确率80%业务层人工转接率30%业务层用户满意度4.0/5.0迭代的抓手主要是badcase分析。每周抽100条对话记录人工标注哪些环节出了问题。如果意图分类错得多就补充训练样本或优化提示词如果检索召回不够就调整切块策略或换嵌入模型如果生成有幻觉就加强安全护栏。我的经验是前两周的badcase密度最高迭代两到三轮后效果会明显稳定。不要指望一次调优就完美多智能体系统的调优是个持续过程。4.4 从开源项目到生产落地的距离开源的多智能体客服项目不少但直接拿来上生产往往会遇到问题。主要差距在几个方面知识库的冷启动。开源项目通常只提供框架知识库要自己建。客服知识库的构建是个脏活累活要把FAQ、产品文档、政策文件整理成结构化格式还要持续更新。模型选型的适配。开源项目默认可能用GPT-4但生产环境要考虑成本和数据合规。换成国产模型后提示词往往需要重新调优因为不同模型的指令遵循能力有差异。并发和稳定性。开源demo通常不考虑高并发生产环境要加限流、熔断、重试机制。模型API偶尔超时是常态要有降级策略。监控和告警。生产系统需要监控每个节点的耗时、成功率、异常率。LangGraph可以接入LangSmith做链路追踪但需要额外配置。我的建议是先用开源项目跑通流程验证业务价值然后再逐步替换和加固各个模块。不要一上来就追求完美架构先跑起来比什么都重要。4.5 多智能体客服的边界与人工协作最后说一个容易被忽视的问题多智能体客服不是要取代人工而是要让人工客服做更有价值的事。机器处理标准化、高频、简单的问题人工处理复杂、情绪化、需要判断的问题。转人工的触发条件设计要合理。太敏感会导致人工压力大太迟钝会导致用户体验差。我的经验值是人工转接率控制在20%到30%之间比较健康。低于20%说明机器可能漏转了复杂问题高于30%说明机器的能力还不够。转人工时要把完整上下文传递给人工客服包括用户意图、检索到的知识、已生成的回复草稿。人工客服可以基于这些信息快速接手而不是从零开始问。这个体验细节做得好不好直接决定用户对整体服务的评价。另外人工客服的处理记录应该回流到知识库作为后续机器学习的素材。哪些问题机器答不好、人工是怎么答的这些都是宝贵的训练数据。形成“机器服务-人工兜底-数据回流-机器优化”的闭环系统才能越用越聪明。这个方向后续还可以往多模态客服扩展比如支持用户上传图片、截图让智能体具备视觉理解能力。也可以往主动服务延伸不等用户提问系统主动推送物流异常提醒、订单状态变更通知。多智能体架构的扩展性很好加一个新智能体、加一条新边就能支持新场景这是它相比单模型方案最大的优势。