这篇文章是我结合自己做过的客服问答项目整理的一份实战笔记。内容主要是把一个问题从用户输入到系统判断、检索、回答再到人工兜底的过程讲清楚。一、先说结论为什么一个客服系统不能只靠大模型如果只用大模型来回答客服问题最常见的两个问题就是容易答偏尤其是政策类、售后类问题。成本高很多高频问题其实没必要每次都调用大模型。所以我在项目里更倾向于把系统拆成三层来看FAQ 快答层处理高频、标准、固定的问题。RAG 兜底层处理 FAQ 没命中的问题从知识库里找答案。Agent 执行层处理需要工具调用、状态流转、人工审核的复杂问题。这样做的好处很直接简单问题快速返回复杂问题按流程处理既省成本也更稳定。二、一个问题进来后系统大概怎么走我一般会把整个流程理解成下面这几步1. 用户先输入问题比如用户问“我的订单怎么还没发货”系统第一步不是直接丢给大模型而是先做基础判断比如这是不是高频问题这个问题有没有明显的订单号、物流号需不需要先查缓存需不需要走工具调用。2. 先看 FAQ 能不能直接命中如果问题很标准比如发票怎么开物流一般多久到退款多久到账这种问题通常可以先走 FAQ。这一步的作用是减少不必要的复杂链路。因为很多问题其实是重复出现的没必要每次都重新检索知识库更没必要每次都让大模型“临场发挥”。在我的项目里FAQ 主要承担两件事承接高频咨询作为第一层过滤减少后面 RAG 和 Agent 的压力。3. FAQ 没命中再进入 RAG如果 FAQ 没找到合适答案系统会进入 RAG 流程。RAG 可以理解成“先去知识库里找资料再根据资料回答”。它通常不是一次性完成而是分成几个小步骤先把用户问题做分词和规范化处理。再去知识库里做召回。召回后再做排序挑出最相关的内容。最后把检索到的内容交给大模型组织成自然语言答案。我在这个过程中理解最深的一点是RAG 的核心不是“让大模型更聪明”而是“让大模型少胡说多依据资料说话”。4. 如果问题需要查业务系统就进入 Agent有些问题不是“查知识”就能解决的比如我的订单到底发货没有物流卡在哪一步退货申请有没有成功这个售后单能不能继续往下走。这类问题通常需要查订单系统、物流系统、工单系统甚至需要人工审核。这时候就要用 Agent。它不是单纯回答而是会根据当前状态决定下一步做什么比如先追问订单号再调用订单接口如果需要人工审核就暂停流程审核完后再接着往下走。三、我在项目里是怎么理解这些技术的1. LangGraph负责把流程串起来我对 LangGraph 的理解很简单它不是拿来“聊天”的而是拿来“编排流程”的。在客服项目里LangGraph 更像一个流程控制器。它会根据当前状态把请求分到不同节点比如商品咨询节点订单服务节点售后处理节点人工审核节点。如果把整个系统比作一个流水线LangGraph 就是决定“这一步该往哪走”的那个人。2. Orchestrator负责判断应该走哪条路Orchestrator 可以理解成编排者。它的工作不是回答问题而是判断这个问题该不该走 FAQ该不该走 RAG还是直接进入某个 Agent。在我的项目里Orchestrator 主要维护几个关键信息用户意图订单上下文风险标签当前流程进度。这些信息一旦维护好系统就不会“前后失忆”。3. MCP / Tool Calling负责把业务工具接进来如果说 Agent 是“会做事的部分”那 Tool Calling 和 MCP 更像是它的手和脚。比如订单查询、物流查询、售后工单创建这些都不是大模型自己凭空生成的而是要去调用真实业务接口。我对这块的理解是Tool Calling解决“怎么让模型发起调用”MCP解决“怎么把多个业务工具统一封装起来”FastAPI负责把底层接口包成标准服务Redis / Checkpointer负责保存状态避免中途断掉后流程接不上。4. Checkpointer Redis负责记住流程走到哪一步客服场景里最怕的一件事就是用户刚走到一半人工介入了回来以后系统忘了之前在干什么。所以我在项目里最关注的一个点就是状态保存。Checkpointer 的作用是保存当前流程状态Redis 适合做会话级缓存。两者配合起来就能让系统在中断后继续往下走而不是重新开始。四、我为什么觉得 FAQ RAG Agent 这种组合最实用做过一段时间后我的感受是这个组合比较符合真实业务FAQ处理“最常见的问题”RAG处理“知识库里能找到答案的问题”Agent处理“要查系统、要走流程的问题”。它不是最花哨的方案但很适合业务场景因为客服系统最重要的不是炫技而是稳定、可控、能落地。五、如果用一句话讲这个项目我一般会这样说这个项目我主要做的是客服问答链路的流程化改造。我们先用 FAQ 承接高频问题再用 RAG 处理知识库查询最后用 Agent 去做订单、物流和售后这类需要工具调用的复杂问题。整个系统通过 LangGraph 做编排用 Checkpointer 和 Redis 保存状态再通过 MCP 和 FastAPI 把业务工具标准化接进来这样既能控制成本也能保证回答更稳定。六、最后总结我自己现在越来越觉得大模型应用开发不只是“会调模型”而是要把问题拆开哪些问题该缓存哪些问题该检索哪些问题该走流程哪些问题必须人工介入。只要把这一层想清楚很多客服、知识库、运营支持类项目其实就能做得比较稳。这也是我在项目里学到最多的地方。 从用户提问到答案返回：我在客服问答项目里怎么理解 FAQ、RAG 和 Agent
这篇文章是我结合自己做过的客服问答项目整理的一份实战笔记。内容主要是把一个问题从用户输入到系统判断、检索、回答再到人工兜底的过程讲清楚。一、先说结论为什么一个客服系统不能只靠大模型如果只用大模型来回答客服问题最常见的两个问题就是容易答偏尤其是政策类、售后类问题。成本高很多高频问题其实没必要每次都调用大模型。所以我在项目里更倾向于把系统拆成三层来看FAQ 快答层处理高频、标准、固定的问题。RAG 兜底层处理 FAQ 没命中的问题从知识库里找答案。Agent 执行层处理需要工具调用、状态流转、人工审核的复杂问题。这样做的好处很直接简单问题快速返回复杂问题按流程处理既省成本也更稳定。二、一个问题进来后系统大概怎么走我一般会把整个流程理解成下面这几步1. 用户先输入问题比如用户问“我的订单怎么还没发货”系统第一步不是直接丢给大模型而是先做基础判断比如这是不是高频问题这个问题有没有明显的订单号、物流号需不需要先查缓存需不需要走工具调用。2. 先看 FAQ 能不能直接命中如果问题很标准比如发票怎么开物流一般多久到退款多久到账这种问题通常可以先走 FAQ。这一步的作用是减少不必要的复杂链路。因为很多问题其实是重复出现的没必要每次都重新检索知识库更没必要每次都让大模型“临场发挥”。在我的项目里FAQ 主要承担两件事承接高频咨询作为第一层过滤减少后面 RAG 和 Agent 的压力。3. FAQ 没命中再进入 RAG如果 FAQ 没找到合适答案系统会进入 RAG 流程。RAG 可以理解成“先去知识库里找资料再根据资料回答”。它通常不是一次性完成而是分成几个小步骤先把用户问题做分词和规范化处理。再去知识库里做召回。召回后再做排序挑出最相关的内容。最后把检索到的内容交给大模型组织成自然语言答案。我在这个过程中理解最深的一点是RAG 的核心不是“让大模型更聪明”而是“让大模型少胡说多依据资料说话”。4. 如果问题需要查业务系统就进入 Agent有些问题不是“查知识”就能解决的比如我的订单到底发货没有物流卡在哪一步退货申请有没有成功这个售后单能不能继续往下走。这类问题通常需要查订单系统、物流系统、工单系统甚至需要人工审核。这时候就要用 Agent。它不是单纯回答而是会根据当前状态决定下一步做什么比如先追问订单号再调用订单接口如果需要人工审核就暂停流程审核完后再接着往下走。三、我在项目里是怎么理解这些技术的1. LangGraph负责把流程串起来我对 LangGraph 的理解很简单它不是拿来“聊天”的而是拿来“编排流程”的。在客服项目里LangGraph 更像一个流程控制器。它会根据当前状态把请求分到不同节点比如商品咨询节点订单服务节点售后处理节点人工审核节点。如果把整个系统比作一个流水线LangGraph 就是决定“这一步该往哪走”的那个人。2. Orchestrator负责判断应该走哪条路Orchestrator 可以理解成编排者。它的工作不是回答问题而是判断这个问题该不该走 FAQ该不该走 RAG还是直接进入某个 Agent。在我的项目里Orchestrator 主要维护几个关键信息用户意图订单上下文风险标签当前流程进度。这些信息一旦维护好系统就不会“前后失忆”。3. MCP / Tool Calling负责把业务工具接进来如果说 Agent 是“会做事的部分”那 Tool Calling 和 MCP 更像是它的手和脚。比如订单查询、物流查询、售后工单创建这些都不是大模型自己凭空生成的而是要去调用真实业务接口。我对这块的理解是Tool Calling解决“怎么让模型发起调用”MCP解决“怎么把多个业务工具统一封装起来”FastAPI负责把底层接口包成标准服务Redis / Checkpointer负责保存状态避免中途断掉后流程接不上。4. Checkpointer Redis负责记住流程走到哪一步客服场景里最怕的一件事就是用户刚走到一半人工介入了回来以后系统忘了之前在干什么。所以我在项目里最关注的一个点就是状态保存。Checkpointer 的作用是保存当前流程状态Redis 适合做会话级缓存。两者配合起来就能让系统在中断后继续往下走而不是重新开始。四、我为什么觉得 FAQ RAG Agent 这种组合最实用做过一段时间后我的感受是这个组合比较符合真实业务FAQ处理“最常见的问题”RAG处理“知识库里能找到答案的问题”Agent处理“要查系统、要走流程的问题”。它不是最花哨的方案但很适合业务场景因为客服系统最重要的不是炫技而是稳定、可控、能落地。五、如果用一句话讲这个项目我一般会这样说这个项目我主要做的是客服问答链路的流程化改造。我们先用 FAQ 承接高频问题再用 RAG 处理知识库查询最后用 Agent 去做订单、物流和售后这类需要工具调用的复杂问题。整个系统通过 LangGraph 做编排用 Checkpointer 和 Redis 保存状态再通过 MCP 和 FastAPI 把业务工具标准化接进来这样既能控制成本也能保证回答更稳定。六、最后总结我自己现在越来越觉得大模型应用开发不只是“会调模型”而是要把问题拆开哪些问题该缓存哪些问题该检索哪些问题该走流程哪些问题必须人工介入。只要把这一层想清楚很多客服、知识库、运营支持类项目其实就能做得比较稳。这也是我在项目里学到最多的地方。