智能客服不是把模型接到聊天框里而是把“识别、检索、工具、质检、转人工、留痕”串成一张可控的图。前面我们已经讲了 LangGraph 的基础。现在进入实战用 LangGraph 搭一个智能客服 Agent。1. 智能客服不是聊天机器人很多人做客服 Agent一上来就写一个大 Prompt。结果 Demo 能跑上线就崩。原因很简单客服不是单轮问答。客服是流程系统。用户问密码重置可以 FAQ 快速回答。用户问订单物流必须查业务系统。用户投诉扣费必须升级人工。用户要求退款必须走权限和审批。这些事情不能全部交给模型自由发挥。它需要一张图。普通聊天机器人和 LangGraph 客服 Agent 的区别2. 为什么客服场景适合 LangGraph客服系统最怕三件事流程乱、状态丢、责任说不清。LangGraph 正好解决这三件事。流程乱用 Node 和 Edge 把流程显式化。状态丢用 State 和 checkpointer 保存会话状态。责任不清每个节点输入输出清楚出错容易定位。官方文档也建议构建 LangGraph Agent 时要先把流程拆成离散节点再通过共享 State 和边连接起来官方的 “Thinking in LangGraph” 就用客户支持邮件 Agent 作为示例包含分类、检索文档、草拟回复、转人工等步骤。企业级智能客服 Agent 总体架构3. 先设计 State客服流程的工作台State 是整张图的共享状态。它不是数据库。也不是聊天记录垃圾桶。它只放流程需要判断、恢复、追踪的数据。一个比较合理的客服 State可以分成四类。会话上下文messages、user_id、thread_id、trace_id。业务识别intent、urgency、topic、order_id、need_human。知识与工具query_rewrite、retrieved_docs、tool_results、ticket_id。生成与质检draft_answer、quality_score、risk_flags、final_answer。设计原则State 要能支撑恢复、审计、路由。不要把所有中间废话都塞进去。4. 再设计 Node一个节点只做一件事Node 是执行单元。在客服 Agent 里不要写一个万能 node。万能节点最难调试也最容易失控。拆成节点后每一步都能单独观察。分类错了看 classify。检索错了看 rag_search。工具错了看 tool_action。回答不稳看 draft_reply 和 quality_check。5. 再设计 Edge流程的方向盘Node 做事。Edge 决定下一步去哪。客服 Agent 的关键不在“能不能回答”而在“该走哪条路”。常见路由规则非常直接。核心原则业务规则要写进边。模型可以参与判断但不能独占判断。6. 接入 FAQ、RAG 和业务工具客服 Agent 通常不是只靠 RAG。更合理的顺序是FAQ 优先RAG 补充工具查事实人工兜底。FAQ高频问题命中就直接答。速度快成本低。RAG制度、产品文档、操作手册。答案要带来源。业务工具订单、账单、物流、工单、CRM。必须走权限。人工低置信度、高风险、投诉、退款、隐私修改。这里最重要的是模型不能猜业务数据。订单状态、支付结果、物流信息必须由工具返回。7. 质检节点防止错误答案直接出门客服回答必须先过质检。质检不是装饰。它是最后一道闸门。事实检查回答是否基于文档和工具结果。风险检查是否承诺赔付、退款、法律责任。敏感检查是否泄露隐私、账号、手机号。格式检查是否有步骤、是否有引用、是否可执行。质检通过进入 send_reply。质检失败回到 draft_reply 或进入 human_review。8. 源码级拆解StateGraph 到底怎么跑起来现在把源码链路压缩成一条线。8.1 StateGraph 只是 Builder源码里StateGraph 是图构建器。它负责收集节点、边、条件分支和状态 schema。nodes保存每个节点。edges保存固定边。branches保存条件边。schemas / channels保存状态字段和 reducer。它不能直接运行。必须 compile。StateGraph(State) - add_node / add_edge - compile() - CompiledStateGraph8.2 add_node 做了什么add_node 的核心不是“放一个函数进去”。它会把你的函数包装成 Runnable推断输入 schema注册节点名保存 retry、cache、timeout、error_handler 等配置。这就是为什么一个普通 Python 函数进了 LangGraph 之后就能被图运行时统一调度。8.3 add_edge 和 add_conditional_edges 做了什么add_edge 存固定路线。add_conditional_edges 存条件路线。客服场景里classify 后到底走 FAQ、RAG、Tool 还是 Human就是条件边决定的。classify - route_by_intent - faq_search / rag_search / tool_action / human_review8.4 compile 做了什么compile 是上线前的装配动作。检查图结构有没有孤立节点有没有非法边。装配 checkpointer、store、interrupt 配置。把 Builder 变成真正可执行的 CompiledStateGraph。compile 后才能 invoke 或 stream。8.5 运行时怎么流转运行时不是简单 for 循环。Graph API 文档说明LangGraph 用消息传递和 super-step 执行图节点收到状态后激活运行完成后写回状态再触发下一批节点。你可以把它理解成加载 state - 激活节点 - 执行节点 - 返回 partial state - reducer 合并 - 进入下一条边所以客服 Agent 每走一步State 都会更新。配合 checkpointer流程可以恢复。9. ToolNode把模型的工具调用变成真实业务动作模型不会真的查订单。模型只会生成 tool_call。真正执行工具的是 ToolNode。ToolNode 的源码职责很清楚。读取最后一条 AIMessage 里的 tool_calls。根据 name 找到对应 BaseTool。注入 state、store、runtime 等上下文。执行工具支持并行、错误处理和状态更新。把结果包装成 ToolMessage写回 messages。客服系统里ToolNode 是模型和业务系统之间的隔离层。权限、审计、错误兜底都要卡在这里。10. Human Review人工介入不是兜底是安全机制不是所有问题都能自动回答。特别是客服场景钱、隐私、投诉、法务都不能让模型直接决定。图 9interrupt checkpointer 的人工介入流程interrupt 的价值是暂停而不是失败。节点内调用 interrupt。运行时暂停图执行。checkpointer 保存当前状态。人工审批后用同一个 thread_id 恢复。Command(resume...) 把人工结果传回节点。这就是客服 Agent 能上线的关键。复杂问题不硬答高风险操作不自动做。11. 持久化让客服对话能恢复客服系统一定会有多轮。用户今天没说完明天继续问。人工审批暂停后也要能恢复。LangGraph 的 persistence 分两类。checkpointer保存单个 thread 的图状态。适合短期记忆、对话连续、人工介入、故障恢复。store保存跨 thread 的长期信息。适合用户偏好、事实、共享知识。客服系统至少要有 thread_id。它是恢复会话的游标。thread_id user_id channel session_id没有 thread_id就没有真正的多轮客服。12. 企业级部署不要让 LangGraph 直接碰核心业务推荐架构很简单。Java 主服务管业务。Python AI 服务管 LangGraph。模型负责推理不负责权限。落地时核心动作一定要回到业务系统。查询订单工具可以查但要带用户身份和权限。创建工单可以自动创建但要记录原因和上下文。退款赔付不能自动执行必须审批。修改隐私信息必须二次验证。敏感回复必须经过质检或人工。13. 上线前检查清单客服 Agent 上线前先过这张表。14. 总结这一章讲的是怎么用 LangGraph 搭智能客服 Agent。核心不是代码。核心是拆流程。State保存流程快照。Node一个节点只做一件事。Edge把业务规则变成路线。RAG回答产品和制度问题。ToolNode查真实业务系统。Quality Check挡住错误答案。Interrupt高风险场景暂停等人工。Checkpointer让流程可恢复。最后记住一句话客服 Agent 的价值不是会说话而是能按业务流程可靠地把问题处理完。内容来源https://news.eeebb.com/article/3657