简介随着大语言模型LLM技术的普及智能客服系统的构建方式正在从简单的“套壳问答”向具备完整任务处理能力的Agent演进。在真实业务场景中用户往往在一个会话里包含多个意图且需要多轮对话才能补齐槽位信息这对系统的对话状态管理和流程编排提出了极高要求。LangGraph作为一种图状态编排引擎能够将意图识别、槽位提取、知识检索、转人工决策等模块组织成可恢复、可中断的流转流程结合LangChain的模型适配与工具链能力可以有效解决传统客服系统难以处理的复杂对话场景。本文从实际落地经验出发详细拆解了基于LangGraph的智能客服Agent系统架构、核心模块实现、API封装与踩坑记录为构建高鲁棒性企业级客服Agent提供参考。 先说结论这套智能客服Agent系统如果只是把它当成一个普通的问答机器人来搭那根本没必要上LangGraph。但如果你要处理的是“用户一句话里藏着多个意图”、“上下文来回绕了好几轮之后槽位才补齐”、“回答不了的时候要体面地把人转接给真人客服”这类真实场景那LangGraph的图状态流转就是刚需。这篇文章我按照自己的落地经验把这个系统的架构拆解、核心模块实现、API层封装和踩坑记录完整过一遍希望对准备上手LangChain/LangGraph做客服Agent的同学有实际参考价值。1. 为什么选 LangChain LangGraph智能客服不是简单的“LLM套壳”1.1 智能客服Agent的核心诉求智能客服和普通聊天机器人最大的区别在于它不是“用户说一句模型回一句”而是要在有限的对话轮次里解决一个明确的问题。用户带着“我要改手机号”进来整个系统的目标是尽快帮他完成改号或者判断这个问题超出能力范围后迅速转人工。这个过程涉及到几个核心诉求第一理解用户到底想干什么也就是意图识别第二记住用户已经说了什么、还缺什么信息也就是对话状态跟踪第三在必要的时候去企业知识库或文档里检索答案而不是全靠LLM瞎编第四一旦发现无法解决或用户情绪明确不满必须有一条可靠的路径转给真人客服第五所有这些环节要能以API的形式暴露给上层业务系统而不是只在命令行里跑一个demo。这五个诉求拆开来看每一个都有对应的技术方案但难点在于把它们串成一个完整、有状态、可中断、可恢复的流程。LangChain提供了大量现成的工具链和模型抽象而LangGraph则把流程组织成了图节点和节点之间的边就是状态转移。这就是我选这两个框架的核心原因。1.2 LangChain与LangGraph的分工很多人第一次接触时分不清这两个框架的关系甚至有人以为LangGraph是LangChain的下一代替代品。实际用下来我更倾向于把LangChain理解为“模型与工具的中枢适配层”而LangGraph是“流程编排引擎”。完全可以不用LangChain只用LangGraph只要你自己处理模型调用、提示词模板、工具调用这些工作量会大不少反过来只用LangChain也能做客服但流程控制基本靠手写状态机或一堆if/else代码会越来越难维护。LangChain帮我们解决的是不同LLM厂商API的统一适配OpenAI、Claude、国产模型都能接、Prompt模板的工程化管理、向量数据库的弱化抽象、以及各类工具的封装。LangGraph帮我们解决的是把“理解意图→跟踪状态→查知识→决策转人工”这些步骤定义成图节点把节点之间的跳转条件定义成边系统运行时会自动维护一份全局状态任何一个节点都能读写这份状态。1.3 为什么不直接用单一框架如果只用LangChain你需要自己在循环里管理对话历史自己写状态机去判断“当前应该追问还是回答”代码结构很容易变成一坨。如果只用LangGraph而不用LangChain代码里会大量出现直接拼接模型请求、自己解析JSON的重复工作。两个框架配合LangChain负责“单点能力”调用模型、取工具、检索LangGraph负责“流程组织”各干各擅长的部分边界非常清晰。我在实际项目中还额外体会到一点LangGraph的图结构天然适合可视化调试节点之间的关系画出来就是一张图跟产品、算法同学对齐需求的时候把图截出来贴在文档里沟通成本明显下降。2. 系统整体架构设计从模块拆分到一次请求的完整链路2.1 模块划分与职责边界这个客服Agent项目在标题里列了六个关键模块意图分类器、对话状态跟踪器、知识检索系统、人机转人工决策模型、基于LLM的槽位提取器、API服务层。下面用一个表格把它们各自的职责说清楚模块输入输出核心职责意图分类器当前用户消息 对话历史摘要意图标签及置信度判断本轮用户想干什么比如查询账单、办理改号、转人工、闲聊对话状态跟踪器DST对话历史、当前消息、槽位提取结果更新后的状态字典维护用户已提供的信息和缺失的信息LLM槽位提取器当前消息 槽位定义结构化槽位信息JSON从自然语言里提取业务字段比如手机号、姓名、地址知识检索系统用户问题或改写后的查询命中的知识段落从企业内部文档中召回相关答案人机转人工决策模型置信度、状态完整度、情绪信号、轮次转人工/继续Agent决定是否把对话交给真人客服API服务层HTTP请求含消息、会话ID响应消息、状态快照对外提供服务入口管理会话生命周期每个模块都是独立可测试的这是架构设计里我比较坚持的一点。目的是如果后期想换掉某一个模块比如把意图分类器从LLM方案换成微调的小模型不会牵动其他模块的改动。2.2 一次完整请求的流转过程整个系统的核心编排使用了LangGraph。我用一个简化描述来说清楚一次用户请求的流转请求进来之后先经过“意图分类”节点得到当前意图接着进入“槽位提取”节点把这条消息里的关键业务字段抽出来然后交给对话状态跟踪器将新槽位合并进全局状态此时系统检查状态是否满足“完成任务”的条件如果满足走“知识检索→生成回答”的路径如果不满足走“追问缺失槽位”的路径任何环节如果检测到转人工信号都立刻跳转到“转人工”节点。这不是一条直线而更像是一个带环的图用户可以多次补充信息每一次循环都会刷新全局状态。LangGraph处理这种带条件的循环非常自然因为每个节点在结束之后都会显式返回一条边告诉执行器“下一步走哪”。从我个人经验来看这种显式返回边的模式比在循环外面用全局变量控制前进后退要稳健得多因为系统崩溃之后可以从保存的状态快照恢复继续跑。2.3 LangGraph状态设计的三个关键取舍用了LangGraph之后我做的第一件事就是定义全局状态的数据结构。这个结构不是随便定的它决定了后面所有模块能不能顺畅配合。我定义了三个关键的字段组第一组是对话相关信息包括完整消息列表、当前轮次和最近的系统动作第二组是结构化信息包括意图标签、槽位字典、状态完整度评分第三组是流转控制信息包括是否触发转人工、当前节点的执行状态和错误信息。这里有一个非常重要的取舍状态里到底应该放“完整对话历史”还是“压缩后的摘要”从成本角度看完整历史会让LLM调用消耗大量token从状态完整度看摘要又会丢失关键细节。我采用的折中方案是前几轮用完整历史超过一定轮数之后把更早的内容用summary节点压缩成摘要这实际上是LangChain内置的“摘要记忆”机制在LangGraph状态里的落地。3. 核心模块实现细节意图、状态、槽位三件套3.1 意图分类器从纯规则到LLM的过渡方案意图分类是整个客服Agent最先执行的节点它的准确率直接影响后续所有模块的表现。在实际实现中我建议不要一上来就上大模型分类而是采用“先规则、后模型、再兜底”的三层架构。第一层是规则层做法是维护一份关键词和正则表达式表比如用户输入包含“人工”、“转人工”、“客服”等词时直接判为转人工意图。这一层的优点是零延迟、零成本缺点是可维护性差但它能拦截掉大量明显意图的请求为后面的模型分类降低压力。第二层是LLM分类层使用LangChain的prompt模板传入系统定义好的意图列表、用户的当前消息和最近的对话摘要要求模型返回JSON格式的意图标签和置信度。第三层是兜底层当置信度低于某个阈值时把意图标记为“未知”并采取保守策略比如使用默认回复或直接转人工。有一个实际细节值得分享。LLM意图分类的Prompt输出格式一定要用“结构化输出”来约束。LangChain里有PydanticOutputFarser可以直接定义输出结构为intent: str和confidence: float模型输出后自动校验。我一开始用纯文本prompt让模型输出格式结果时不时来一句“根据您的描述您的意图可能是查询账单”解析器直接罢工。换成Pydantic之后这类问题基本绝迹。意图列表本身也需要版本化管理因为业务方每隔一段时间就会调整意图定义。我一般把意图清单放在一个独立的YAML文件里由代码统一加载每次变更都有git记录。3.2 对话状态跟踪器DST维护一张动态变化的“信息清单”对话状态跟踪器负责回答两个问题用户到目前为止提过了哪些信息完成当前任务还缺哪些信息在我的实现里DST的核心是一个槽位定义表它描述了每个任务需要哪些槽位、该槽位是否必须、以及槽位是否已经填充。以“改绑手机号”任务为例需要的槽位包括新手机号、验证方式、用户身份确认。每次用户说话槽位提取器输出的内容会被合并进状态DST会检查这些必须槽位是否都有值以及值是否通过了校验比如手机号是不是11位数字。这里容易犯一个错误槽位提取的结果不分场合地合并导致状态污染。比如用户上一轮在查账单这一轮突然说“顺便也帮我看看流量套餐”如果直接合并槽位会把新意图的槽位混进旧任务里。解决方案是给槽位附加“所属意图ID”只有当前意图匹配的槽位才会合并旧意图的槽位保留但标记为“历史快照”。这个设计让对话状态可回溯转人工时也能把完整的状态上下文同步给真人客服。DST的实现本身不需要太复杂。如果使用LangGraph每条边的条件判断里读一下全局状态即可。但状态数据结构的规范化非常关键我建议所有槽位都用扁平化的字典存储不要嵌套太深因为嵌套越深写边条件和校验逻辑时就越容易出错。3.3 基于LLM的槽位提取器用Few-shot和JSON Schema约束输出槽位提取本质上是一个信息抽取任务。传统做法是训练一个序列标注模型但现在用LLM配合Few-shot就能达到很好的效果特别是预定义槽位数量比较多、关系相对复杂的场景。我设计槽位提取器时输入包括三部分槽位定义清单包含槽位名、含义、示例值、用户的当前消息、以及上一轮已经填好的槽位字典。输出是一个JSON对象键为槽位名值为提取到的值或null。LangChain里可以用ChatPromptTemplate结合PydanticOutputFarser来约束输出结构这种方式比让模型自由发挥稳定得多。下面是我实际使用的一个核心prompt结构示例from langchain.prompts import ChatPromptTemplate from langchain.output_parsers import PydanticOutputFarser from pydantic import BaseModel, Field class SlotExtractionOutput(BaseModel): intent: str Field(description当前识别到的意图ID) slots: dict Field(description提取到的槽位键值对未提取到的槽位不出现) need_retry: bool Field(description如果内容存在歧义或信息不足置为true) prompt ChatPromptTemplate.from_messages([ (system, ( 你是客服系统的槽位提取器。请从用户输入中提取以下槽位\n {slot_definitions}\n 用户上一轮已确认的槽位{existing_slots}\n 注意只提取当前消息中明确出现的信息不要自行推断。 )), (human, {user_message}), ])这里有一个细节我特别强调“不要自行推断”。因为LLM有个坏毛病会结合上下文脑补槽位值比如把上一轮提到的手机号自动填到当前槽位里。这在某些场景下确实很智能但也容易造成脏数据。我的策略是最少置信原则——宁愿这次没提取到然后通过追问确认也不要提取一个可能是错的槽位给用户埋雷。槽位提取的Few-shot示例通常是必要的。如果完全不给示例模型在遇到长尾业务场景时容易“自由发挥”例如把“顺便帮我妈也改一下”里的“我妈”识别成用户姓名。给两到三个典型的提取示例可以显著提升稳定性尤其是中文口语化表达比较多的场景。4. 知识检索与人机转人工回答质量和安全兜底的组合拳4.1 知识检索系统向量召回 重排 答案生成的完整链路客服系统的知识库文档通常由企业FAQ、操作手册、业务规则等组成。这一部分如果单靠LLM生成那结果百分之百会幻觉所以知识检索系统在整个链路里承担的是“先找到证据再让模型读证据作答”的角色。我用了两个阶段的检索策略。第一阶段的候选召回可以用向量数据库完成文档在入库前先切分切分粒度根据内容层次动态调整。标题层级明显的内容比如操作手册按章节和小节切分FAQ类内容每一条问答为一个单元。向量检索的query不是直接用用户原话而是推荐先经过一次查询改写。比如用户问“我要改手机号旧号不用了”直接检索可能命中“如何修改手机号”但更准确的语义是“旧号停用后的改绑流程”。查询改写可以用LLM实现给模型几个改写示例让它生成一个更标准的知识库查询。第二阶段是重排。向量召回Top 20之后用一个重排序模型或者直接用LLM打分把相关性最高的Top 3选出来。我一开始觉得“向量Top k已经够了吧”但实际业务反馈显示有一次用户问“密码忘了怎么办”向量召回的前三条全是“登录密码修改”和“账号安全设置”而真正需要的“密码重置引导”排到了第五。加上重排之后命中率稳了不少。最终生成回答阶段采用LangChain的create_retrieval_chain思路把Top 3知识段落拼进Prompt要求LLM严格基于提供的上下文回答并且在上下文不足时明确说“这个问题我需要转人工”。这个“可认输”的机制非常关键它保证了系统不会硬编一个错误答案糊弄用户。4.2 人机转人工决策模型置信度并非唯一信号转人工决策是整个系统里风险最高的环节——转错了浪费人力不转又怕用户体验崩掉。我构建的转人工决策模型输入信号远远不止“意图置信度”一个维度。我总结出四个核心信号维度第一是任务完成风险也就是当前状态槽位是否齐备、追问次数是否已经超过阈值比如同一槽位追问三次以上仍无法获取第二是模型自评置信度答案生成前可以加一个自评步骤让LLM评估“基于现有知识能否准确回答用户问题”第三是用户情绪信号我使用了一个轻量级情绪分类Prompt识别用户消息中的负面情绪关键词比如“投诉”、“差评”、“太慢了”、“生气”等第四是业务规则比如贵宾用户、投诉渠道用户必须优先人工。综合这些信号我设计了一个打分公式handoff_score w1 * (1 - state_completeness) w2 * (1 - llm_confidence) w3 * sentiment_score w4 * rule_flag当handoff_score超过阈值时系统进入转人工流程。权重w1/w2/w3/w4可以在配置中心动态调整这是为了应对业务冷启动阶段没有足够标注数据时可以人工调整策略。冷启动阶段我更推荐配置较高的转人工倾向宁可多转也不让用户跟机器较劲。转人工并非简单把“人工客服”四个字抛给用户。系统需要生成一段交接摘要包含意图、已填写的槽位、已尝试的解决过程、用户情绪摘要然后在弹窗中提示用户“正在为您转接人工客服请稍候”。在实际实现中这一步会调用客服工单系统的API如果调用失败要降级为“给用户回拨电话”或“记录留言”。4.3 决策之后的平滑交接我曾经在产品评审时被问过一个问题“转人工了然后呢”这个问题其实非常关键。如果转人工之后直接断开用户所有上下文都丢了那不仅这一轮白聊之前所有轮次的交互都白费。我的实现方案是构建一个handoff_context对象它是一个JSON包含{ session_id: abc-123, intent: change_phone, filled_slots: {new_phone: 13800138000, identity: verified}, missing_slots: [], retry_count: 2, attempted_solutions: [用户尝试通过App自助改绑提示验证码发送失败], sentiment: neutral_to_negative, llm_confidence: 0.48, handoff_reason: llm_confidence_low }这个对象传给人工客服工作台以后客服人员在页面里一眼就能看到用户之前说过的信息不需要重复询问“请问您的手机号是多少”这类问题。交互体验提升了不止一个档次也减少了人工客服的MOT平均处理时长。5. API服务层把Agent从“脚本”包装成“产品”5.1 FastAPI封装与流式响应一个Agent系统如果只能通过命令行跑那它没有产品价值。API服务层承担了两个核心职责对外提供标准的HTTP接口以及管理会话状态的生命周期。我用FastAPI做服务层封装主要接口是from fastapi import FastAPI from pydantic import BaseModel app FastAPI() class ChatRequest(BaseModel): session_id: str user_message: str user_id: str None class ChatResponse(BaseModel): session_id: str response: str handoff_required: bool handoff_context: dict None为什么选FastAPI最大的原因是它有完善的异步支持LLM调用是典型的IO密集操作异步能显著提高并发处理能力。默认的OpenAI SDK已经支持异步调用AsyncOpenAILangChain的arun/ainvoke也提供了对应的异步方法。整体服务不需要依赖外部消息队列就能支撑一定的并发量。流式响应对客服体验来说很重要。如果用户问一个问题要等五秒钟而界面上没有任何动静那用户体验是灾难性的。实现上可以利用FastAPI的StreamingResponse配合LangChain的流式调用逐chunk把生成的文字推给前端。但注意Agent内部流程包含检索和状态更新等耗时步骤这些步骤不应该走流式只有最终的答案生成阶段才启用流式。所以我的设计是先执行完所有Agent节点只把最后一个“生成回答”节点改成流式输出。5.2 会话管理与超时处理会话管理上我用了Redis保存每个session的状态快照。LangGraph支持传入一个checkpointer在每次节点执行完之后自动保存状态。用LangGraph内置的MemorySaver可以开发用但生产环境请务必迁移到Redis或数据库级别的checkpointer不然服务重启一次所有对话状态全部清空这是不可接受的。会话超时策略也是必须设计的。我设置了三个超时级别短期超时用户5分钟未发言将状态标记为inactive但保留槽位信息中期超时30分钟未发言把可能敏感的内容比如身份证号从槽位中移除只保留非敏感信息长期超时24小时未发言清空整个session。这个策略既考虑了用户体验也考虑了数据安全合规。5.3 可观测性与日志埋点客服Agent系统的排查难度比普通CRUD系统大得多因为每个错误可能出现在意图分类、槽位提取、知识检索、LLM生成等多个环节。我建议在API服务层搭建四类埋点请求级日志、状态流转日志、LLM调用日志和业务结果埋点。请求级日志记录每个session每次请求的时间戳、消息内容和响应内容状态流转日志记录LangGraph每个节点的进入时间、退出时间、状态快照LLM调用日志记录每次LLM请求的token数、耗时和返回内容摘要这个对后续做成本优化非常有价值业务结果埋点则记录“是否完成任务”“是否转人工”“用户是否在收到回复后离开”等结果级指标。有一个教训不要把所有日志都不分级别地打到同一个文件里。我最初为了图方便全用print()结果排查问题的时候一个请求的日志被其他并发请求的日志打断非常痛苦。正确做法是用logging模块配合结构化JSON输出每条日志带上session_id、request_id、node_name等字段再用ELK或任何日志平台统一检索。6. 踩坑实录与问题排查6.1 LangGraph状态流的典型坑LangGraph的图执行机制有一个容易让新手困惑的地方所有节点共享一个全局状态但节点之间的数据传递需要显式指定。如果不小心在某个节点return里覆盖了全局状态字段很容易导致后续节点读取到空值。我踩过的一个具体坑是槽位提取器节点把slots字段返回成了空字典因为prompt解析出来的Pydantic对象里面slots没有值然后这个空字典直接覆盖了全局状态里已有的槽位数据之前积累的信息全被清了。解决办法是在节点函数里对解析后的结果做一个“合并再写入”的操作读取全局状态中的旧槽位跟新提取槽位合并后再写回全局状态。这个看似简单的merge逻辑如果漏了整个DST模块就是不可用的。我建议把状态更新逻辑单独封装成工具函数并写单测因为类似问题在长期使用时出现的概率极大。另一个坑是LangGraph的conditional_edges返回值必须和边的定义完全匹配。我曾经写了一个判断逻辑返回continue但边定义里写的条件是continue_processing结果运行时就报“找不到边”的错误。这个错误本身很明确但排查的时候容易忽略因为看起来代码没什么问题。6.2 LLM响应延迟和成本控制LLM调用的延迟是客服系统最大的瓶颈。一次完整请求可能包含意图分类、槽位提取、检索改写、答案生成四次及以上LLM调用如果每次都串行一个回复可能要十几秒。我做了三项优化。第一项是并行化意图分类和槽位提取之间没有依赖关系可以并发调用使用asyncio.gather同时发请求总耗时基本等于最慢的那个。第二项是模型分层配置轻量任务意图分类、槽位提取用快且便宜的模型重活答案生成用更强的模型。第三项是超时控制和重试机制LLM偶尔会超时我设置了5秒超时加1次重试重试还失败就走转人工兜底不要无限等待。成本控制方面我引入了token用量统计每次LLM调用后记录prompt和completion的token数定期按session和意图维度分析。实际运行下来发现知识检索的query改写其实可以优化掉因为很多知识库FAQ的意图已经由意图分类器给出直接拿原始tag去检索即可省掉一次改写调用的成本。当然知识库非常庞大的企业场景可以保留改写这个要看具体情况。6.3 上下文窗口管理LLM上下文窗口是客服系统的硬约束。用户在客服会话里说十句每句几百字如果全部塞进上下文的调用很快就顶到窗口上限。我采用分层的记忆管理策略。立即可用的上下文最近两轮完整消息始终保留中期的上下文采用关键信息抽取用户已经提供的槽位、意图、情绪标签保留在状态里更早的上下文走summary压缩。这套策略实施以后上下文窗口压力小了很多效果没有明显下降。另外还要注意压缩摘要建议直接使用LLM来做而不是简单截断因为摘要需要保留业务相关的关键信息用文本截断法会丢细节。6.4 常见问题速查表问题现象常见原因排查方向和解决建议槽位提取结果覆盖旧值合并逻辑缺失检查DST节点是否做新旧slot的合并意图分类总是返回“未知”意图列表定义不清晰或prompt缺少示例补充Few-shot示例精简意图列表知识检索命中内容不相关查询改写或向量切分粒度不合适检查检索query是否被过度改写尝试调整切分逻辑转人工从不触发阈值设置过高或信号缺失查看各维度信号分数临时降低阈值灰度测试请求响应很慢LLM串行调用将无依赖任务改为并发调用引入模型分层服务重启后会话丢失使用了MemorySaver更换为Redis或持久化checkpointerLLM返回JSON解析失败输出格式未约束改用PydanticOutputFarser或JSON mode用户话里有多个意图单意图分类器天然缺陷允许多意图输出或增加意图切换检测节点7. 结语与个人经验这套带意图分类、状态管理、知识检索和转人工决策的客服Agent我自己从零搭过一遍最深的体会是技术难点不在单一模块而在模块之间的衔接。LangChain把单点能力抽象得够好LangGraph把流程组织得够清晰但真正把系统跑稳靠的是对状态流的精细设计和对边角case的持续打磨。最后再分享一个小技巧。在做系统联调的时候建议先不开LLM真实调用用Mock数据和录制回放的方式把整个LangGraph流转跑通等流程没问题了再切真实模型。这样调试时不会因为模型输出不稳定而无法定位问题省下了大量时间。后续如果要把这个系统扩展成多语言客服、语音客服架构层面也基本不用大动只需要在意图分类和槽位提取部分做对应适配。本文还有配套的精品资源点击获取 基于LangGraph的智能客服Agent架构设计与落地实践
简介随着大语言模型LLM技术的普及智能客服系统的构建方式正在从简单的“套壳问答”向具备完整任务处理能力的Agent演进。在真实业务场景中用户往往在一个会话里包含多个意图且需要多轮对话才能补齐槽位信息这对系统的对话状态管理和流程编排提出了极高要求。LangGraph作为一种图状态编排引擎能够将意图识别、槽位提取、知识检索、转人工决策等模块组织成可恢复、可中断的流转流程结合LangChain的模型适配与工具链能力可以有效解决传统客服系统难以处理的复杂对话场景。本文从实际落地经验出发详细拆解了基于LangGraph的智能客服Agent系统架构、核心模块实现、API封装与踩坑记录为构建高鲁棒性企业级客服Agent提供参考。 先说结论这套智能客服Agent系统如果只是把它当成一个普通的问答机器人来搭那根本没必要上LangGraph。但如果你要处理的是“用户一句话里藏着多个意图”、“上下文来回绕了好几轮之后槽位才补齐”、“回答不了的时候要体面地把人转接给真人客服”这类真实场景那LangGraph的图状态流转就是刚需。这篇文章我按照自己的落地经验把这个系统的架构拆解、核心模块实现、API层封装和踩坑记录完整过一遍希望对准备上手LangChain/LangGraph做客服Agent的同学有实际参考价值。1. 为什么选 LangChain LangGraph智能客服不是简单的“LLM套壳”1.1 智能客服Agent的核心诉求智能客服和普通聊天机器人最大的区别在于它不是“用户说一句模型回一句”而是要在有限的对话轮次里解决一个明确的问题。用户带着“我要改手机号”进来整个系统的目标是尽快帮他完成改号或者判断这个问题超出能力范围后迅速转人工。这个过程涉及到几个核心诉求第一理解用户到底想干什么也就是意图识别第二记住用户已经说了什么、还缺什么信息也就是对话状态跟踪第三在必要的时候去企业知识库或文档里检索答案而不是全靠LLM瞎编第四一旦发现无法解决或用户情绪明确不满必须有一条可靠的路径转给真人客服第五所有这些环节要能以API的形式暴露给上层业务系统而不是只在命令行里跑一个demo。这五个诉求拆开来看每一个都有对应的技术方案但难点在于把它们串成一个完整、有状态、可中断、可恢复的流程。LangChain提供了大量现成的工具链和模型抽象而LangGraph则把流程组织成了图节点和节点之间的边就是状态转移。这就是我选这两个框架的核心原因。1.2 LangChain与LangGraph的分工很多人第一次接触时分不清这两个框架的关系甚至有人以为LangGraph是LangChain的下一代替代品。实际用下来我更倾向于把LangChain理解为“模型与工具的中枢适配层”而LangGraph是“流程编排引擎”。完全可以不用LangChain只用LangGraph只要你自己处理模型调用、提示词模板、工具调用这些工作量会大不少反过来只用LangChain也能做客服但流程控制基本靠手写状态机或一堆if/else代码会越来越难维护。LangChain帮我们解决的是不同LLM厂商API的统一适配OpenAI、Claude、国产模型都能接、Prompt模板的工程化管理、向量数据库的弱化抽象、以及各类工具的封装。LangGraph帮我们解决的是把“理解意图→跟踪状态→查知识→决策转人工”这些步骤定义成图节点把节点之间的跳转条件定义成边系统运行时会自动维护一份全局状态任何一个节点都能读写这份状态。1.3 为什么不直接用单一框架如果只用LangChain你需要自己在循环里管理对话历史自己写状态机去判断“当前应该追问还是回答”代码结构很容易变成一坨。如果只用LangGraph而不用LangChain代码里会大量出现直接拼接模型请求、自己解析JSON的重复工作。两个框架配合LangChain负责“单点能力”调用模型、取工具、检索LangGraph负责“流程组织”各干各擅长的部分边界非常清晰。我在实际项目中还额外体会到一点LangGraph的图结构天然适合可视化调试节点之间的关系画出来就是一张图跟产品、算法同学对齐需求的时候把图截出来贴在文档里沟通成本明显下降。2. 系统整体架构设计从模块拆分到一次请求的完整链路2.1 模块划分与职责边界这个客服Agent项目在标题里列了六个关键模块意图分类器、对话状态跟踪器、知识检索系统、人机转人工决策模型、基于LLM的槽位提取器、API服务层。下面用一个表格把它们各自的职责说清楚模块输入输出核心职责意图分类器当前用户消息 对话历史摘要意图标签及置信度判断本轮用户想干什么比如查询账单、办理改号、转人工、闲聊对话状态跟踪器DST对话历史、当前消息、槽位提取结果更新后的状态字典维护用户已提供的信息和缺失的信息LLM槽位提取器当前消息 槽位定义结构化槽位信息JSON从自然语言里提取业务字段比如手机号、姓名、地址知识检索系统用户问题或改写后的查询命中的知识段落从企业内部文档中召回相关答案人机转人工决策模型置信度、状态完整度、情绪信号、轮次转人工/继续Agent决定是否把对话交给真人客服API服务层HTTP请求含消息、会话ID响应消息、状态快照对外提供服务入口管理会话生命周期每个模块都是独立可测试的这是架构设计里我比较坚持的一点。目的是如果后期想换掉某一个模块比如把意图分类器从LLM方案换成微调的小模型不会牵动其他模块的改动。2.2 一次完整请求的流转过程整个系统的核心编排使用了LangGraph。我用一个简化描述来说清楚一次用户请求的流转请求进来之后先经过“意图分类”节点得到当前意图接着进入“槽位提取”节点把这条消息里的关键业务字段抽出来然后交给对话状态跟踪器将新槽位合并进全局状态此时系统检查状态是否满足“完成任务”的条件如果满足走“知识检索→生成回答”的路径如果不满足走“追问缺失槽位”的路径任何环节如果检测到转人工信号都立刻跳转到“转人工”节点。这不是一条直线而更像是一个带环的图用户可以多次补充信息每一次循环都会刷新全局状态。LangGraph处理这种带条件的循环非常自然因为每个节点在结束之后都会显式返回一条边告诉执行器“下一步走哪”。从我个人经验来看这种显式返回边的模式比在循环外面用全局变量控制前进后退要稳健得多因为系统崩溃之后可以从保存的状态快照恢复继续跑。2.3 LangGraph状态设计的三个关键取舍用了LangGraph之后我做的第一件事就是定义全局状态的数据结构。这个结构不是随便定的它决定了后面所有模块能不能顺畅配合。我定义了三个关键的字段组第一组是对话相关信息包括完整消息列表、当前轮次和最近的系统动作第二组是结构化信息包括意图标签、槽位字典、状态完整度评分第三组是流转控制信息包括是否触发转人工、当前节点的执行状态和错误信息。这里有一个非常重要的取舍状态里到底应该放“完整对话历史”还是“压缩后的摘要”从成本角度看完整历史会让LLM调用消耗大量token从状态完整度看摘要又会丢失关键细节。我采用的折中方案是前几轮用完整历史超过一定轮数之后把更早的内容用summary节点压缩成摘要这实际上是LangChain内置的“摘要记忆”机制在LangGraph状态里的落地。3. 核心模块实现细节意图、状态、槽位三件套3.1 意图分类器从纯规则到LLM的过渡方案意图分类是整个客服Agent最先执行的节点它的准确率直接影响后续所有模块的表现。在实际实现中我建议不要一上来就上大模型分类而是采用“先规则、后模型、再兜底”的三层架构。第一层是规则层做法是维护一份关键词和正则表达式表比如用户输入包含“人工”、“转人工”、“客服”等词时直接判为转人工意图。这一层的优点是零延迟、零成本缺点是可维护性差但它能拦截掉大量明显意图的请求为后面的模型分类降低压力。第二层是LLM分类层使用LangChain的prompt模板传入系统定义好的意图列表、用户的当前消息和最近的对话摘要要求模型返回JSON格式的意图标签和置信度。第三层是兜底层当置信度低于某个阈值时把意图标记为“未知”并采取保守策略比如使用默认回复或直接转人工。有一个实际细节值得分享。LLM意图分类的Prompt输出格式一定要用“结构化输出”来约束。LangChain里有PydanticOutputFarser可以直接定义输出结构为intent: str和confidence: float模型输出后自动校验。我一开始用纯文本prompt让模型输出格式结果时不时来一句“根据您的描述您的意图可能是查询账单”解析器直接罢工。换成Pydantic之后这类问题基本绝迹。意图列表本身也需要版本化管理因为业务方每隔一段时间就会调整意图定义。我一般把意图清单放在一个独立的YAML文件里由代码统一加载每次变更都有git记录。3.2 对话状态跟踪器DST维护一张动态变化的“信息清单”对话状态跟踪器负责回答两个问题用户到目前为止提过了哪些信息完成当前任务还缺哪些信息在我的实现里DST的核心是一个槽位定义表它描述了每个任务需要哪些槽位、该槽位是否必须、以及槽位是否已经填充。以“改绑手机号”任务为例需要的槽位包括新手机号、验证方式、用户身份确认。每次用户说话槽位提取器输出的内容会被合并进状态DST会检查这些必须槽位是否都有值以及值是否通过了校验比如手机号是不是11位数字。这里容易犯一个错误槽位提取的结果不分场合地合并导致状态污染。比如用户上一轮在查账单这一轮突然说“顺便也帮我看看流量套餐”如果直接合并槽位会把新意图的槽位混进旧任务里。解决方案是给槽位附加“所属意图ID”只有当前意图匹配的槽位才会合并旧意图的槽位保留但标记为“历史快照”。这个设计让对话状态可回溯转人工时也能把完整的状态上下文同步给真人客服。DST的实现本身不需要太复杂。如果使用LangGraph每条边的条件判断里读一下全局状态即可。但状态数据结构的规范化非常关键我建议所有槽位都用扁平化的字典存储不要嵌套太深因为嵌套越深写边条件和校验逻辑时就越容易出错。3.3 基于LLM的槽位提取器用Few-shot和JSON Schema约束输出槽位提取本质上是一个信息抽取任务。传统做法是训练一个序列标注模型但现在用LLM配合Few-shot就能达到很好的效果特别是预定义槽位数量比较多、关系相对复杂的场景。我设计槽位提取器时输入包括三部分槽位定义清单包含槽位名、含义、示例值、用户的当前消息、以及上一轮已经填好的槽位字典。输出是一个JSON对象键为槽位名值为提取到的值或null。LangChain里可以用ChatPromptTemplate结合PydanticOutputFarser来约束输出结构这种方式比让模型自由发挥稳定得多。下面是我实际使用的一个核心prompt结构示例from langchain.prompts import ChatPromptTemplate from langchain.output_parsers import PydanticOutputFarser from pydantic import BaseModel, Field class SlotExtractionOutput(BaseModel): intent: str Field(description当前识别到的意图ID) slots: dict Field(description提取到的槽位键值对未提取到的槽位不出现) need_retry: bool Field(description如果内容存在歧义或信息不足置为true) prompt ChatPromptTemplate.from_messages([ (system, ( 你是客服系统的槽位提取器。请从用户输入中提取以下槽位\n {slot_definitions}\n 用户上一轮已确认的槽位{existing_slots}\n 注意只提取当前消息中明确出现的信息不要自行推断。 )), (human, {user_message}), ])这里有一个细节我特别强调“不要自行推断”。因为LLM有个坏毛病会结合上下文脑补槽位值比如把上一轮提到的手机号自动填到当前槽位里。这在某些场景下确实很智能但也容易造成脏数据。我的策略是最少置信原则——宁愿这次没提取到然后通过追问确认也不要提取一个可能是错的槽位给用户埋雷。槽位提取的Few-shot示例通常是必要的。如果完全不给示例模型在遇到长尾业务场景时容易“自由发挥”例如把“顺便帮我妈也改一下”里的“我妈”识别成用户姓名。给两到三个典型的提取示例可以显著提升稳定性尤其是中文口语化表达比较多的场景。4. 知识检索与人机转人工回答质量和安全兜底的组合拳4.1 知识检索系统向量召回 重排 答案生成的完整链路客服系统的知识库文档通常由企业FAQ、操作手册、业务规则等组成。这一部分如果单靠LLM生成那结果百分之百会幻觉所以知识检索系统在整个链路里承担的是“先找到证据再让模型读证据作答”的角色。我用了两个阶段的检索策略。第一阶段的候选召回可以用向量数据库完成文档在入库前先切分切分粒度根据内容层次动态调整。标题层级明显的内容比如操作手册按章节和小节切分FAQ类内容每一条问答为一个单元。向量检索的query不是直接用用户原话而是推荐先经过一次查询改写。比如用户问“我要改手机号旧号不用了”直接检索可能命中“如何修改手机号”但更准确的语义是“旧号停用后的改绑流程”。查询改写可以用LLM实现给模型几个改写示例让它生成一个更标准的知识库查询。第二阶段是重排。向量召回Top 20之后用一个重排序模型或者直接用LLM打分把相关性最高的Top 3选出来。我一开始觉得“向量Top k已经够了吧”但实际业务反馈显示有一次用户问“密码忘了怎么办”向量召回的前三条全是“登录密码修改”和“账号安全设置”而真正需要的“密码重置引导”排到了第五。加上重排之后命中率稳了不少。最终生成回答阶段采用LangChain的create_retrieval_chain思路把Top 3知识段落拼进Prompt要求LLM严格基于提供的上下文回答并且在上下文不足时明确说“这个问题我需要转人工”。这个“可认输”的机制非常关键它保证了系统不会硬编一个错误答案糊弄用户。4.2 人机转人工决策模型置信度并非唯一信号转人工决策是整个系统里风险最高的环节——转错了浪费人力不转又怕用户体验崩掉。我构建的转人工决策模型输入信号远远不止“意图置信度”一个维度。我总结出四个核心信号维度第一是任务完成风险也就是当前状态槽位是否齐备、追问次数是否已经超过阈值比如同一槽位追问三次以上仍无法获取第二是模型自评置信度答案生成前可以加一个自评步骤让LLM评估“基于现有知识能否准确回答用户问题”第三是用户情绪信号我使用了一个轻量级情绪分类Prompt识别用户消息中的负面情绪关键词比如“投诉”、“差评”、“太慢了”、“生气”等第四是业务规则比如贵宾用户、投诉渠道用户必须优先人工。综合这些信号我设计了一个打分公式handoff_score w1 * (1 - state_completeness) w2 * (1 - llm_confidence) w3 * sentiment_score w4 * rule_flag当handoff_score超过阈值时系统进入转人工流程。权重w1/w2/w3/w4可以在配置中心动态调整这是为了应对业务冷启动阶段没有足够标注数据时可以人工调整策略。冷启动阶段我更推荐配置较高的转人工倾向宁可多转也不让用户跟机器较劲。转人工并非简单把“人工客服”四个字抛给用户。系统需要生成一段交接摘要包含意图、已填写的槽位、已尝试的解决过程、用户情绪摘要然后在弹窗中提示用户“正在为您转接人工客服请稍候”。在实际实现中这一步会调用客服工单系统的API如果调用失败要降级为“给用户回拨电话”或“记录留言”。4.3 决策之后的平滑交接我曾经在产品评审时被问过一个问题“转人工了然后呢”这个问题其实非常关键。如果转人工之后直接断开用户所有上下文都丢了那不仅这一轮白聊之前所有轮次的交互都白费。我的实现方案是构建一个handoff_context对象它是一个JSON包含{ session_id: abc-123, intent: change_phone, filled_slots: {new_phone: 13800138000, identity: verified}, missing_slots: [], retry_count: 2, attempted_solutions: [用户尝试通过App自助改绑提示验证码发送失败], sentiment: neutral_to_negative, llm_confidence: 0.48, handoff_reason: llm_confidence_low }这个对象传给人工客服工作台以后客服人员在页面里一眼就能看到用户之前说过的信息不需要重复询问“请问您的手机号是多少”这类问题。交互体验提升了不止一个档次也减少了人工客服的MOT平均处理时长。5. API服务层把Agent从“脚本”包装成“产品”5.1 FastAPI封装与流式响应一个Agent系统如果只能通过命令行跑那它没有产品价值。API服务层承担了两个核心职责对外提供标准的HTTP接口以及管理会话状态的生命周期。我用FastAPI做服务层封装主要接口是from fastapi import FastAPI from pydantic import BaseModel app FastAPI() class ChatRequest(BaseModel): session_id: str user_message: str user_id: str None class ChatResponse(BaseModel): session_id: str response: str handoff_required: bool handoff_context: dict None为什么选FastAPI最大的原因是它有完善的异步支持LLM调用是典型的IO密集操作异步能显著提高并发处理能力。默认的OpenAI SDK已经支持异步调用AsyncOpenAILangChain的arun/ainvoke也提供了对应的异步方法。整体服务不需要依赖外部消息队列就能支撑一定的并发量。流式响应对客服体验来说很重要。如果用户问一个问题要等五秒钟而界面上没有任何动静那用户体验是灾难性的。实现上可以利用FastAPI的StreamingResponse配合LangChain的流式调用逐chunk把生成的文字推给前端。但注意Agent内部流程包含检索和状态更新等耗时步骤这些步骤不应该走流式只有最终的答案生成阶段才启用流式。所以我的设计是先执行完所有Agent节点只把最后一个“生成回答”节点改成流式输出。5.2 会话管理与超时处理会话管理上我用了Redis保存每个session的状态快照。LangGraph支持传入一个checkpointer在每次节点执行完之后自动保存状态。用LangGraph内置的MemorySaver可以开发用但生产环境请务必迁移到Redis或数据库级别的checkpointer不然服务重启一次所有对话状态全部清空这是不可接受的。会话超时策略也是必须设计的。我设置了三个超时级别短期超时用户5分钟未发言将状态标记为inactive但保留槽位信息中期超时30分钟未发言把可能敏感的内容比如身份证号从槽位中移除只保留非敏感信息长期超时24小时未发言清空整个session。这个策略既考虑了用户体验也考虑了数据安全合规。5.3 可观测性与日志埋点客服Agent系统的排查难度比普通CRUD系统大得多因为每个错误可能出现在意图分类、槽位提取、知识检索、LLM生成等多个环节。我建议在API服务层搭建四类埋点请求级日志、状态流转日志、LLM调用日志和业务结果埋点。请求级日志记录每个session每次请求的时间戳、消息内容和响应内容状态流转日志记录LangGraph每个节点的进入时间、退出时间、状态快照LLM调用日志记录每次LLM请求的token数、耗时和返回内容摘要这个对后续做成本优化非常有价值业务结果埋点则记录“是否完成任务”“是否转人工”“用户是否在收到回复后离开”等结果级指标。有一个教训不要把所有日志都不分级别地打到同一个文件里。我最初为了图方便全用print()结果排查问题的时候一个请求的日志被其他并发请求的日志打断非常痛苦。正确做法是用logging模块配合结构化JSON输出每条日志带上session_id、request_id、node_name等字段再用ELK或任何日志平台统一检索。6. 踩坑实录与问题排查6.1 LangGraph状态流的典型坑LangGraph的图执行机制有一个容易让新手困惑的地方所有节点共享一个全局状态但节点之间的数据传递需要显式指定。如果不小心在某个节点return里覆盖了全局状态字段很容易导致后续节点读取到空值。我踩过的一个具体坑是槽位提取器节点把slots字段返回成了空字典因为prompt解析出来的Pydantic对象里面slots没有值然后这个空字典直接覆盖了全局状态里已有的槽位数据之前积累的信息全被清了。解决办法是在节点函数里对解析后的结果做一个“合并再写入”的操作读取全局状态中的旧槽位跟新提取槽位合并后再写回全局状态。这个看似简单的merge逻辑如果漏了整个DST模块就是不可用的。我建议把状态更新逻辑单独封装成工具函数并写单测因为类似问题在长期使用时出现的概率极大。另一个坑是LangGraph的conditional_edges返回值必须和边的定义完全匹配。我曾经写了一个判断逻辑返回continue但边定义里写的条件是continue_processing结果运行时就报“找不到边”的错误。这个错误本身很明确但排查的时候容易忽略因为看起来代码没什么问题。6.2 LLM响应延迟和成本控制LLM调用的延迟是客服系统最大的瓶颈。一次完整请求可能包含意图分类、槽位提取、检索改写、答案生成四次及以上LLM调用如果每次都串行一个回复可能要十几秒。我做了三项优化。第一项是并行化意图分类和槽位提取之间没有依赖关系可以并发调用使用asyncio.gather同时发请求总耗时基本等于最慢的那个。第二项是模型分层配置轻量任务意图分类、槽位提取用快且便宜的模型重活答案生成用更强的模型。第三项是超时控制和重试机制LLM偶尔会超时我设置了5秒超时加1次重试重试还失败就走转人工兜底不要无限等待。成本控制方面我引入了token用量统计每次LLM调用后记录prompt和completion的token数定期按session和意图维度分析。实际运行下来发现知识检索的query改写其实可以优化掉因为很多知识库FAQ的意图已经由意图分类器给出直接拿原始tag去检索即可省掉一次改写调用的成本。当然知识库非常庞大的企业场景可以保留改写这个要看具体情况。6.3 上下文窗口管理LLM上下文窗口是客服系统的硬约束。用户在客服会话里说十句每句几百字如果全部塞进上下文的调用很快就顶到窗口上限。我采用分层的记忆管理策略。立即可用的上下文最近两轮完整消息始终保留中期的上下文采用关键信息抽取用户已经提供的槽位、意图、情绪标签保留在状态里更早的上下文走summary压缩。这套策略实施以后上下文窗口压力小了很多效果没有明显下降。另外还要注意压缩摘要建议直接使用LLM来做而不是简单截断因为摘要需要保留业务相关的关键信息用文本截断法会丢细节。6.4 常见问题速查表问题现象常见原因排查方向和解决建议槽位提取结果覆盖旧值合并逻辑缺失检查DST节点是否做新旧slot的合并意图分类总是返回“未知”意图列表定义不清晰或prompt缺少示例补充Few-shot示例精简意图列表知识检索命中内容不相关查询改写或向量切分粒度不合适检查检索query是否被过度改写尝试调整切分逻辑转人工从不触发阈值设置过高或信号缺失查看各维度信号分数临时降低阈值灰度测试请求响应很慢LLM串行调用将无依赖任务改为并发调用引入模型分层服务重启后会话丢失使用了MemorySaver更换为Redis或持久化checkpointerLLM返回JSON解析失败输出格式未约束改用PydanticOutputFarser或JSON mode用户话里有多个意图单意图分类器天然缺陷允许多意图输出或增加意图切换检测节点7. 结语与个人经验这套带意图分类、状态管理、知识检索和转人工决策的客服Agent我自己从零搭过一遍最深的体会是技术难点不在单一模块而在模块之间的衔接。LangChain把单点能力抽象得够好LangGraph把流程组织得够清晰但真正把系统跑稳靠的是对状态流的精细设计和对边角case的持续打磨。最后再分享一个小技巧。在做系统联调的时候建议先不开LLM真实调用用Mock数据和录制回放的方式把整个LangGraph流转跑通等流程没问题了再切真实模型。这样调试时不会因为模型输出不稳定而无法定位问题省下了大量时间。后续如果要把这个系统扩展成多语言客服、语音客服架构层面也基本不用大动只需要在意图分类和槽位提取部分做对应适配。本文还有配套的精品资源点击获取