客服Agent这两年热度一直在线市面上Demo也不少但很多都停留在“能问答”的水平离生产可用的客服机器人还有不小的距离。我做的一个项目是把客服Agent真正落到业务线里包含客服工作台H5、后端服务、以及接入外部工作流平台整个过程走下来最大的感受是客服Agent能不能用七成取决于工作流设计剩下三成才是模型和代码。这篇文章就来拆解客服Agent工作流的完整实战过程从业务需求、技术选型、工作流节点配置、前后端联调到线上遇到的坑一次性讲清楚。正在做Agent相关项目、或准备给团队搭智能客服的开发者应该能从里面找到一条可复用的参考路径。1. 实战前想清楚客服Agent到底解决什么问题1.1 客服场景的真正痛点不只是“问答”很多人一上来就把客服Agent等同于“有一个对话框AI能回答”其实这个理解会埋下大坑。客服场景的复杂点在于用户不会按照FAQ标准话术来提问同样一句“你们怎么处理退换货”放在不同场景、不同语气、不同上下文里正确的回复可能完全不同。如果没有明确的意图判断和分流大模型会试图回答所有问题答错的比例就会很高。真实运营中还有几类高频需求订单查询、物流催办、退款申请、人工投诉、产品参数询问、售前砍价。这些需求不仅要求Agent回答准确还要求它能触发后续动作比如创建工单、同步订单状态、记录用户情绪。也就是说客服Agent本质上是一个“对话驱动的业务流程系统”对话只是入口背后的流程编排才决定体验。1.2 为什么用工作流而不是直接写死代码第一版做技术方案时我考虑过直接用LangChain写一套Chain把意图识别、检索、生成串起来也考虑过用工作流平台。最终选了工作流原因有三个。第一开发效率。客服功能迭代很快话术要调整、知识库要更换、转人工规则要变动如果这些逻辑都写在代码里任何改动都要走开发合并发布流程。用工作流可视化编排运营同学也能在限定范围内调整节点参数不用每次把研发拉下水。第二可调试性。工作流平台通常自带单节点调试和运行日志某次回复不对能直接看到是哪一步出的问题是知识库没召回还是大模型生成了错误内容还是转人工条件判断失误。这在自研代码里需要自己打日志排查起来慢得多。第三灰度发布。一个工作流可以复制出多份环境让一部分流量走新话术另一部分走旧话术对比用户满意度数据后再全量放开。自研系统要做到这种灰度需要额外配置路由规则和数据分析成本更高。打个比方客服工作流就像餐饮店的后厨动线点单、备菜、炒菜、装盘、出餐每一步有明确分工。哪一步出问题就改哪一步而不需要把整个餐厅推倒重建。1.3 技术路线判断自建大模型链路还是用低代码工作流平台这个决策会直接影响项目节奏我做了个简单对比对比维度低代码工作流平台Coze/Dify自研编排LangChain等上手成本低可视化配置即可高需要编写代码和部署迭代速度快慢与业务系统深接一般需要通过API强可直接调用内部服务知识库管理平台自带上传即用需要自己实现向量库和检索排查问题有可视化日志需要自己打日志成本按调用量计费按服务器和模型费用计费对于客服场景我的建议分两种情况。如果团队有成熟的研发而且客服系统需要深度对接ERP、CRM那可以走自研链路用工作流平台只做模型编排部分甚至全部自研。如果团队以运营和产品为核心想做快速验证那就踏踏实实用低代码工作流平台把精力放在知识库整理和业务规则梳理上反而更容易出效果。我这套项目实际采用的是结合方式核心工作流用低代码平台搭提供API供后端调用前端和业务数据落库由自研后端完成。这样的混合架构兼顾了开发效率和系统深度。2. 客服Agent工作流核心模块拆解2.1 一次完整客服会话需要哪些环节一个能落地的客服Agent工作流至少得包含下面五个环节接收用户消息、意图分析、知识检索、生成回答、结果后处理。如果只做前四个少了结果后处理那人工转接和工单创建就做不了。用一个具体例子串起来。用户在对话框输入“我上周买的水杯盖子裂了能换吗”这条消息进入工作流后入口节点拿到用户消息文本附带session_id。意图分析节点把消息分类为“售后申请”或“商品质量问题”并输出置信度。知识检索节点根据消息在知识库中查到退换货政策、发图流程、售后时效。生成回答节点把检索结果拼进prompt生成一句安抚性回复并引导用户上传产品照片。结果后处理节点把这条会话标记为“待处理售后”同时生成一条待人工审核的工单记录再回复用户。客服Agent工作流里这个“结果后处理”最容易被忽略也是我觉得最值得做扎实的地方。AI可以承担99%的对话但最后1%的“允许退货”动作还是应该由人工或系统规则触发而不是让大模型直接承诺。2.2 意图识别先分类再回复别让大模型“一手包办”意图识别是客服Agent的门卫。我看到很多项目图省事把用户消息直接丢给大模型让它“边理解边回答”。看起来灵活实际生产中问题很大。一是响应时间不可控。大模型生成一个包含意图判断和话术回复的完整回答往往需要三五秒用户等得很焦躁。如果先把意图分类单独做一次用一个小一点、快一点的模型或规则几十毫秒就能返回分类结果再走知识库和生成节点整个链路虽然多了步骤但每步都可以控制耗时。二是准确率难保证。意图判断和问题回答是两种任务混在一起时模型容易“答非所问”。比如用户说“我不满意要投诉”模型可能回复官方道歉话术但没识别出这是“投诉”意图系统没有发起投诉工单用户反而更生气。实际项目中我会把意图识别做成三层漏斗。第一层是关键词/规则匹配比如“人工”“转人工”“投诉”“差评”一句话命中就直接转对应分支成本最低。第二层是意图分类模型或工作流平台自带的分类器给出预定义意图上的概率分布。第三层才轮到用大模型兜底识别复杂、模糊的语句比如“你们要是这样我就去别家买了”这句话真实意图是“离网风险/挽留”普通分类器可能分不准。2.3 知识库检索和上下文管理细节决定命中率客服Agent的知识库检索跟普通文档问答的检索有一个很大差异用户的表述太口语化并经常带错别字、emoji、商家名词的简称。如果知识库里存的都是标准话术直接拿原文去检索召回率往往惨不忍睹。我在项目里做了几个调整。第一在检索前加“问题改写”节点。用大模型把用户消息整理成标准问题比如“水杯盖子裂了能换吗”改写成“商品出现质量问题如何申请退换货”。改写后的query再做语义检索命中率高很多。这个节点会多花一次模型调用但客服场景下非常值得。第二知识库数据要维护“相似问法”和“关联实体”。一条FAQ不能只有标准答案还必须有十种左右的历史真实用户问法。说得直白一点知识库的质量不是看标准答案写得有多好而是看相似问题收集得够不够全。上线后要持续把用户真实提问沉淀回来补充进知识库。第三上下文不能只检索最新一句。用户经常分几轮把信息说全“我在你们家买了一个东西现在要退货”是第一轮“订单号是20240815001”是第二轮。如果检索只拿“订单号是20240815001”什么都搜不到。正确做法是把最近三轮用户消息拼成一个query或者用会话摘要字段参与检索。3. 客服Agent工作流一步一步搭出来3.1 环境准备与知识库初始化先交代一下我用的是Coze工作流其他低代码平台Dify、n8n思路基本一致节点名称可能不同但核心链路可以对应。创建项目之后第一件事不是画工作流而是把知识库准备好。我把客服FAQ整理成一张Excel表字段包括FAQ类别、标准问题、相似问法、标准答案、关联关键词、是否需要转人工。比如“退换货政策”这条相似问法我会尽量多填像“怎么退货”“东西不喜欢可以退吗”“七天无理由是什么意思”“退货运费谁出”都算进去。导入知识库后有几个配置项值得留意。第一个是分块方式。FAQ场景强烈建议“按条切分”每条FAQ一个独立片段千万不要把整套操作手册混在一起。如果一段文档里既有退换货政策又有维修政策检索时会把两个主题混成一个向量召回结果和问答主题对不上。第二个是检索模式。开启“混合检索”即关键词检索向量检索同时跑再做score融合。纯向量检索在专业术语、型号代码上经常失灵关键词检索能确保精确命中一些SKU号、订单状态词。第三个是知识库更新频率。客服知识库不是静态的促销活动、售后政策、物流时效都会变。我建议每次业务方给出新文案后至少按周更新一次并在工作流里加上“知识库版本号”字段方便追溯某段时间内回答用的是哪个版本的知识。3.2 工作流主链路节点配置我的主链路比较清晰大致的节点顺序是用户输入 → 预处理器问题改写/实体抽取 → 意图识别分支 → 知识检索 → 大模型生成 → 结果校验 → 输出先说预处理器节点。这个节点不是必需的但如果预算允许建议加上。它承担两件事一是把用户消息改写成适合检索的标准问题二是抽取关键实体比如订单号、手机号、商品名称。订单号这种实体非常关键客服机器人如果能自动识别并带入查询回复会显得非常“懂行”。意图识别分支用条件节点来实现。我设置了三类分支售前咨询走知识检索大模型生成给出产品推荐和优惠信息。售后问题多走一步订单信息收集并执行售后服务流程必要时转人工。情绪投诉直接转人工并在输出话术中优先表达歉意。每个分支还可以设置置信度阈值比如意图分类器给出的“售后问题”置信度低于0.6时不执行售后流程先反问用户确认这样能避免误判带来的严重业务后果。大模型生成节点里模型选择我建议把温度参数调低。客服话术要求稳定、可预期温度通常在0.3左右不要超过0.5。温度太高同一个问题两次回答口气和内容差别大用户会觉得不靠谱。知识库检索结果topK设为3到5之间不要塞太多相关知识超过5条时模型回复容易发散。3.3 转人工、兜底和多轮上下文的实现转人工是整个客服Agent链路里必须有的逃生舱。再好的知识库也有覆盖不到的长尾问题再强的大模型也有判断失误的时候。工作流里我在所有分支的末端都判断了一次“是否需要转人工”。触发条件有三个用户明确要求转人工意图识别到投诉或强烈不满知识库检索结果得分过低Agent没有找到合适答案。转人工不只是回复一句“正在为您转接人工”还应该把会话上下文一起带过去。我让工作流生成一个简短的会话摘要包含用户核心诉求、已提供的订单号、已尝试的建议然后通过API发送给客服坐席工作台。这样人工客服接手时不用让用户从头再说一遍体验差异非常明显。兜底逻辑则指工作流对异常情况的容错。比如调用大模型接口超时、知识库检索内部服务不可用、输入消息为空等每种都要有默认输出。我的原则是在客服场景里宁可回复“当前正在排队您可以稍后再试”也不要让用户看到空白或系统报错。这类default response写在工作流的最后节点看起来毫不起眼但线上运行稳定与否往往就是这些边界处理决定的。多轮上下文在低代码工作流里比较容易被忽略。我的做法是在后端存储每一轮对话调用工作流时把最近五轮的用户消息和Agent回复拼接成文本作为“历史会话”字段传给工作流工作流内部用这个字段更新会话摘要变量并在后续轮次参与检索和生成。3.4 提示词模板的工程写法工作流里容易踩的另一个坑是提示词写得太随意。很多人在大模型生成节点里就写一句“你是客服请回答用户问题”然后期望模型表现良好这是不现实的。我给客服Agent的prompt模板分了四个区块角色设定、任务说明、参照上下文、输出约束。示意如下你是XX商城金牌客服工号9527性格耐心友好。你的任务是根据【知识库内容】回答用户问题如果知识库没有相关内容必须引导用户转人工不要自行编造答案。 【知识库内容】 {search_result} 【历史会话】 {chat_history} 【用户问题】 {user_input} 输出要求 1. 回复不超过120字 2. 语气亲切不使用“亲亲”等过度亲昵的称呼 3. 如无法回答问题在结尾附上“我会为您转接人工客服” 4. 不要出现“根据知识库内容”这类机器感强的措辞。模板里的四个占位符需要在工作流节点里通过引用上游节点的输出变量来填充。这里有一个细节客服场景的prompt长度要适度。历史会话占位符如果无限堆积既浪费token又让模型抓不住当前重点。所以我在后端只传最近五轮超过就做截断。4. 前端与后端对接从工作流到客服系统工作流搭好后还得把它接入到真实的客服系统里。这套项目的前端是一个H5聊天窗口后端用Java Spring Boot提供接口整个过程中有几个关键环节。4.1 后端调用工作流API的封装低代码工作流平台一般会提供一个chat/completions风格的API后端封装时要处理好“同步调用”和“异步轮询”两种模式。简单场景用同步调用把用户消息发给工作流等到返回结果再回复给前端。但客服场景可能涉及大模型思考同步调用经常要10秒以上HTTP连接很容易超时。所以我在线上采用了异步模式后端先创建会话记录调用工作流API后立即返回一个processing状态给前端前端通过WebSocket或轮询接口查询最终结果。请求体的核心字段大概长这样{ user_id: u_123456, session_id: s_20240815001, query: 我上周买的水杯盖子裂了能换吗, history: [ {role: user, content: 你好}, {role: assistant, content: 您好很高兴为您服务。} ], extra_params: { intent: 售后, channel: h5 } }值得提醒的是session_id一定要用后端生成的稳定ID不能交给前端随机生成。前端的session如果因为页面刷新而丢失会话连续性就会断掉。请求里的extra_params是从业务侧传入的比如用户等级、页面来源、是否会员这些字段可以被工作流引用让回复更加个性化。4.2 会话存储与上下文关联会话存储我建了张表核心字段如下字段类型说明session_idvarchar会话ID每次会话唯一user_idvarchar用户IDuser_messagetext用户输入agent_replytextAgent回复intentvarchar识别出的意图knowledge_hitvarchar命中的知识库条目IDturn_timedatetime该轮时间extra_jsontext其他业务字段intent和knowledge_hit这两个字段特别重要不是为了追责而是为了评估效果。比如上线后想看“退换货”意图的首次解决率或者想看哪些知识库条目的命中率最高、哪些条目从来没被命中都需要这些字段支撑。另外我之前踩过一个大坑一开始只在数据库存了user_message和agent_reply没有存intent。后来要做会话分析只能翻历史日志重新清洗非常痛苦。所以我的经验是工作流返回的结构化字段哪怕暂时用不上也先落库后面总有需要的一天。4.3 前端聊天窗口需要注意的3个细节前端聊天窗口这部分视觉美化不是重点反而是三个“看不见”的体验细节值得注意。第一个是“等待态”的设计。工作流链路一旦走完通常要好几秒。如果前端没有任何反馈用户会认为机器人坏了然后反复发消息造成对话碎片化。我的做法是用户发消息后立刻显示“对方正在输入”状态并且前端对相同的session_id做队列保护用户下一条消息发送前如果上一条还在processing就提示“请稍等我正在努力处理您的问题”。第二个是“转人工”按钮。前端固定放一个转人工入口比让用户打字输“人工”更符合习惯。用户点击转人工后后端要立刻在工作流会话里打一个转人工标记这样即使后续还有消息进来也不会再触发AI回复了。第三个是图片上传能力。客服场景里用户发截图、发凭证的概率很高前端要支持图片消息。但工作流处理图片的能力有限我的方案是前端上传图片到对象存储返回URL后随文本一起发给后端后端工作流API里带上image_url参数。工作流可以在生成节点前判断如果用户上传了图片先发一条“感谢您的图片我看一下”的过渡消息再结合图片内容回复。如果平台不支持图片理解也可以退而求其次把图片URL转成文本链接给人工客服参考。5. 常见问题与排查技巧实录任何项目上线后都会遇到问题客服Agent尤其多。这里把我实际遇到过的几个高频问题整理成一张速查表每个问题都附上排查方法和最终解决方案。问题现象常见原因排查步骤解决方案知识库检索不到内容分块不合理、query口语化单节点测试检索结果加问题改写节点调整分块策略回复答非所问知识库召回多条无关内容或prompt约束不足看检索结果和生成输入降低topK限制“只能根据知识库回答”上下文串号会话变量用了全局变量检查变量作用域所有变量绑定session_id高峰期响应慢多节点串行调用大模型查看各节点耗时拆分异步流程降级为规则回复人工转接后体验差转人工时未带上下文检查转人工接口工作流生成会话摘要传给坐席5.1 知识库检索不到预期内容这个问题遇到最多。有一次用户问“你家发货用哪家快递”工作流回复说“暂时无法回答”。我在测试环境单跑知识检索节点发现query直接是原文“你家发货用哪家快递”而这个问法在知识库里并没有原句语义向量又没匹配上。后来在预处理器里把用户消息改写成“发货物流合作快递公司”检索结果第一条就是标准答案。这条经验强烈建议做客服Agent的朋友早点采纳。另外如果知识库量大还要检查chunk之间是否互相干扰。很多人喜欢把FAQ分类合并成大块比如“售后政策”一个大文本块结果用户问具体退换货时限系统检索到了政策大块但句子太长大模型很难从中抽到准确数字。最好是一个知识点一个chunk。5.2 大模型“答非所问”或“编造答案”编造答案在客服场景是红线问题。用户问“这个星期发货吗”如果知识库里没有物流时效信息模型可能顺口回答“预计3天内发货”一旦承诺没兑现就是客诉事件。我的应对策略分三层。第一层是prompt约束在模板里写明“如果知识库没有相关内容必须转人工”。但坦白讲大模型未必100%遵守。第二层是结果校验。工作流在生成节点后面加一个校验节点把生成结果和知识库片段做相似度比对如果生成的文本与任何已知知识片段都低相似就判定为“编造”走转人工分支。第三层是降级回复。训练和评估时给模型固定一个特殊答案比如“这个问题我需要转接给人工客服请稍候”同时把知识库得分低于阈值的会话全部标记为低置信度会话方便运营后续补答。这三层叠加编造率能压到很低。5.3 多轮会话上下文串号上下文串号是我见过最隐蔽的bug。工作流平台里的变量分全局变量和会话变量如果创建会话变量时没有正确关联session_id就会出现A用户说“我刚下了一单”B用户问“我什么时候能收到货”结果B用户的Agent回复里带着A用户的订单号。这个问题的可怕之处在于它不会在测试环境出现只有在并发稍微上来后才会随机暴露。排查方法是在后端日志里对比user_id和session_id的对应关系看看返回的agent_reply里的订单实体是否属于当前用户。解决办法也非常明确工作流所有会话级变量都必须以session_id为维度后端每次调用时显式传入。作为加强方案我还在回复前加了一步“实体归属校验”如果生成的回复中出现了订单号、手机号等隐私实体但该实体与当前session关联的用户不匹配就直接拦下走转人工。这个校验在后端做不依赖工作流平台。5.4 高并发下的超时与限流客服系统高峰期集中在白天用户集中咨询时工作流调用量会瞬间上涨。低代码平台的配额和限流策略需要后端做好三层保障。第一层后端接口做线程池隔离。工作流调用和普通业务接口放在不同线程池避免工作流慢导致整个客服系统接口被拖垮。第二层增加本地缓存。热门FAQ比如退换货政策、优惠券使用规则可以缓存固定答案工作流对热门问题直接返回缓存不需要每次都走完整链路。第三层服务降级。当工作流API连续报错或响应超时超过阈值时后端直接切换到“留言模式”提示用户稍后会有客服回电同时记录会话内容。这三层下来即使是大促场景客服入口也不会彻底瘫痪。6. 实战复盘与扩展方向项目上线后我复盘了很久最大的体会有两点。第一点客服Agent工作流的核心不是模型而是业务流程。你给大模型再牛的prompt如果前置的意图识别、知识库整理、转人工规则没有设计好最后还是一堆让人无语的对话记录。我在联调阶段反复被业务同事打回本质问题都不在模型回复而在“AI什么时候该回答什么时候该转人工”这个边界没定义清楚。第二点低代码工作流和自研代码的配合关键在变量交接要做得非常清晰。工作流把哪些字段返回、后端把哪些字段传进去必须提前定好而且要有版本号。有一次我改了工作流里的输出节点结构把最终回答字段名改了前端没跟上线上客服瞬间“失联”全部回复空白。后来所有字段名变更都走了接口文档变更流程这才把风险压住。后续还可以在这个框架上做很多扩展。比如把工作流里的会话摘要节点改造成更完整的“客服质检”节点自动分析人工客服和AI客服的对话质量再比如把意图识别结果接入运营看板实时统计用户关心什么、哪些意图解决率低需要优化话术还可以在转人工时把AI生成的“会话摘要建议动作”一起推给坐席甚至直接生成一张待办工单。这些能力都建立在这套客服Agent工作流的基础上越往后越像一个“对话驱动的业务中台”而不只是单纯的一个聊天机器人。做完整套项目之后我的建议是如果你也想做客服Agent先把客服团队的FAQ和转人工规则整理出来再动工作流这个前摇越长后面越稳妥。