简介这份资源面向有一定编程基础、关注智能客服开发的开发者与企业技术人员围绕扣子COZE平台讲解如何搭建一个具备多轮对话能力的智能客服助手用于企业官网的客户服务自动化。内容涵盖对话流程设计、意图识别与上下文跟踪、变量提取、插件与API集成以及产品推荐、FAQ导航、服务状态查询等场景扩展并涉及发布测试与数据分析优化。资源包共1个文件为docx文档大小约14KB以图文与代码片段结合的方式呈现完整开发思路。目前已有1468人学习下载。读者可从中获得一套可落地的COZE智能客服构建方案理解节点跳转、条件判断、订单核验接口调用等关键环节并参考变量管理与Prompt个性化配置快速将多轮问答能力接入企业现有系统减少重复开发成本。1. 企业官网客服的自动化拐点为什么多轮对话才是分水岭很多企业官网的在线客服本质上还是一个“关键词问答机”。用户问“怎么收费”它弹一段价格表用户追问“那超过 50 人怎么算”它就开始答非所问。问题不在模型不够强而在于它没有“记住上下文”的能力。基于扣子 COZE 平台做多轮对话智能客服助手解决的正是这个断层让官网客服能接住连续追问、能带着历史信息回答、能在合适的时候把对话交给人工。它适合两类人——一类是手里有企业官网、被重复咨询拖住的中小团队另一类是想把大模型能力落到具体业务、但不想从零搭一套对话系统的开发者。这篇文章不讲空泛的“AI 赋能”只讲怎么在 COZE 上把这个助手搭出来、参数怎么设、哪里会翻车。2. 拆解 COZE 多轮对话客服的骨架从意图识别到会话状态在动手之前得先想清楚一件事多轮对话客服和单轮问答机器人的本质区别在哪。单轮问答是“输入→匹配→输出”每次请求都是独立的多轮对话是“输入 会话历史→理解→决策→输出”它必须维护一个会话状态。COZE 平台把这个状态管理封装成了“对话流 变量”的组合你不需要自己写 Redis 存上下文但你必须理解它的变量作用域否则会出现“上一轮填的参数这一轮读不到”的玄学问题。2.1 意图识别、槽位填充与会话状态的三层结构一个能用的多轮客服内部至少分三层。第一层是意图识别判断用户这句话是在问价格、问售后、还是要转人工。第二层是槽位填充比如用户说“我要咨询企业版”系统需要知道“产品版本企业版”但“人数规模”这个槽位还空着于是追问“请问大概多少人使用”。第三层是会话状态把已经填好的槽位、当前所处的对话节点、用户身份是否已登录都存下来供后续轮次读取。在 COZE 里这三层不是靠一个提示词搞定的。常见做法是用“意图识别节点”做第一层用“变量节点 条件判断”做第二层用“会话变量”做第三层。会话变量又分两种一种是“对话内变量”只在当前这次对话里有效另一种是“用户变量”跨对话持久化。做官网客服大部分场景用对话内变量就够了只有“记住用户上次咨询过什么”这种需求才需要用户变量。提示不要把槽位填充逻辑全塞进大模型的提示词里。模型在长对话中会“忘记”早期指令这是血泪经验。能用变量节点显式存的就不要靠模型记忆。2.2 在 COZE 上创建第一个多轮客服 Bot 的完整步骤下面是从零创建一个最小可用多轮客服的流程。假设你已经有一个 COZE 账号并且进入了工作空间。第一步新建 Bot选择“对话流”模式而不是“单 Agent”模式。单 Agent 模式适合开放域闲聊对话流模式才能精确控制多轮分支。第二步定义会话变量。在对话流编辑器的变量面板里新建三个对话内变量{ user_intent: string记录当前识别到的意图如 price_query / after_sale / human_transfer, slot_product: string记录用户咨询的产品版本, slot_scale: string记录用户的使用规模 }第三步搭建主流程。拖入“意图识别节点”配置三个意图类别每个类别给 3 到 5 条示例话术。意图识别节点的输出连接到“条件判断节点”根据user_intent的值走不同分支。第四步在“价格咨询”分支里先判断slot_product是否为空。为空则追问产品版本并把用户回答写入变量不为空则继续判断slot_scale为空则追问规模。两个槽位都填满后走“知识库检索节点”或“大模型回答节点”生成最终回复。第五步配置兜底分支。当意图识别置信度低于阈值COZE 里通常设 0.6 到 0.7走“澄清节点”回复“我不太确定您的意思您是想咨询价格、售后还是转人工”这套流程跑通后你就有了一个能连续追问两轮、并且记住答案的客服助手。它不复杂但已经比 80% 的官网客服强了。2.3 对话流节点的参数配置与变量作用域COZE 对话流里最容易翻车的地方是变量作用域。对话内变量在“对话流”的整个生命周期内有效但如果你在某个节点里用了“子流程”子流程默认读不到父流程的变量除非你显式传参。我一般会在子流程的入参里把需要的变量一个个映射进去虽然麻烦但比调试“为什么变量是空的”要省时间。另一个参数是“意图识别节点”的置信度阈值。设太高用户稍微换个说法就识别不了设太低什么话都往意图上套。实测下来官网客服场景设 0.65 比较稳。如果你们的用户说话特别口语化可以降到 0.55但要在兜底分支里加一轮澄清避免误判。还有“大模型回答节点”的温度参数。客服场景不需要创造力温度设 0.1 到 0.3 就够了。设高了模型会自己编价格、编政策这是绝对不能接受的。我一般直接设 0.1并且在提示词里加一句“如果知识库中没有相关信息回复‘我帮您转接人工’”。3. 把知识库和人工兜底接进对话流让客服不胡说、能转接多轮对话的骨架搭好后下一步是给它接上“大脑”和“安全网”。大脑是知识库安全网是人工转接。没有知识库模型就会靠预训练知识胡编没有人工兜底遇到投诉或复杂问题就会死循环。这一章讲怎么把这两块接进去以及参数怎么调。3.1 企业知识库的切片策略与检索参数COZE 的知识库支持上传文档、网页、问答对。企业官网客服最常用的素材是产品文档、FAQ、价格表。上传之后平台会自动切片。切片大小直接影响检索效果切得太碎检索到的片段缺少上下文切得太大噪声多模型容易抓错重点。我的经验是FAQ 类内容按“一问一答”作为一个切片不要拆开。产品文档按段落切每段 300 到 500 字。价格表这种结构化内容最好转成问答对再上传比如“企业版 50 人以下多少钱—— 具体价格”。这样检索命中率最高。检索参数方面COZE 知识库有“相似度阈值”和“返回条数”两个关键参数。相似度阈值设 0.5 到 0.6返回条数设 3 到 5 条。返回太多模型会被无关信息干扰返回太少可能漏掉关键信息。如果你们的文档质量参差不齐可以把阈值提到 0.65宁可少返回也不要返回错的。# 伪代码知识库检索节点的参数配置逻辑 retrieval_config { similarity_threshold: 0.6, # 低于此分数的片段不返回 top_k: 4, # 返回最相关的 4 条 rerank: True, # 开启重排序提升相关性 fallback_reply: 这个问题我暂时没有找到答案帮您转接人工客服。 }这段配置的核心是rerank。开启重排序后平台会用一个小模型对初步检索结果重新打分把真正相关的排到前面。代价是响应时间增加 200 到 500 毫秒但客服场景对延迟不敏感这个代价值得付。3.2 人工转接的触发条件与工单字段设计人工转接不是“用户说转人工就转”那样人工会被打爆。合理的触发条件有三类第一用户明确要求转人工第二意图识别置信度连续两轮低于阈值第三用户情绪被判定为负面比如出现“投诉”“垃圾”“骗人”等词。在 COZE 里前两类可以通过条件判断节点实现。第三类需要接一个“情感分析节点”或者用大模型节点做一次分类。我一般用大模型节点提示词写“判断以下用户话语是否包含强烈负面情绪只输出 yes 或 no”成本低且够用。转接时要把工单字段填好否则人工客服接起来还要重新问一遍。至少传这几个字段用户 ID、对话摘要、已填槽位、转接原因。对话摘要可以让大模型生成提示词写“用一句话总结用户的问题不超过 30 字”。{ user_id: {{user_id}}, summary: {{llm_summary}}, slots: { product: {{slot_product}}, scale: {{slot_scale}} }, transfer_reason: user_request / low_confidence / negative_sentiment }这套字段设计的好处是人工客服在接起对话前就能看到上下文不用让用户重复描述。实测能减少 40% 左右的重复沟通时间。3.3 用提示词约束模型不编价格、不承诺、不跑题知识库和转接都配好后最后一道防线是提示词。客服场景的提示词要短、要硬、要可执行。我一般会写这么几条约束只根据知识库返回的内容回答知识库没有的回复“我帮您转接人工”。不主动承诺折扣、不承诺具体交付时间、不评价竞品。回复控制在 80 字以内超过 80 字用户会不耐烦。如果用户连续两次问同一个问题直接转人工。这些约束要放在系统提示词的最前面并且用“必须”“禁止”这种强指令词。模型对强指令的遵循度明显高于“建议”“尽量”。注意提示词不是越长越好。我见过一个客服提示词写了 2000 字结果模型在第三轮对话就开始忽略后面的指令。把最重要的约束放在前 200 字内后面用变量和节点控制。4. 多轮客服上线的避坑清单从变量丢失到意图漂移这一章不讲新功能只讲踩过的坑。每一个都是真实调试出来的现象、原因、解决方式都写清楚。你照着排查能省至少两天的调试时间。4.1 坑一第二轮对话变量读不到现象第一轮用户回答了“企业版”第二轮系统又问“请问您咨询哪个版本”。原因变量写在了“意图识别节点”的输出分支里但第二轮对话走了另一个分支变量没被读取。解决把变量读取放在流程的最前面用一个“变量读取节点”统一读取再分发给后续节点。不要在每个分支里单独读变量。4.2 坑二意图识别在第三轮开始漂移现象前两轮识别准确第三轮用户说“那这个价格包含培训吗”系统识别成“售后咨询”。原因意图识别节点默认只看当前这句话不看历史。解决在意图识别节点的输入里把最近两轮对话拼进去。COZE 支持用{{conversation_history}}变量但要注意长度限制一般截取最近 500 字就够了。4.3 坑三知识库检索返回无关内容现象用户问“企业版支持私有化部署吗”检索返回的是“个人版功能介绍”。原因切片太大一个切片里混了多个版本的信息。解决重新切片按版本拆分文档。如果文档本身混在一起先用大模型做一次预处理把不同版本的内容分开。4.4 坑四转人工后对话直接结束现象用户点转人工系统回复“已为您转接”然后对话就断了人工客服那边没收到。原因转接节点只发了消息没有调用工单系统的 API。解决在转接节点后面加一个“HTTP 请求节点”把工单字段 POST 到你们的客服系统。记得加超时和重试网络抖动很常见。4.5 坑五模型在兜底回复里自己编答案现象知识库没检索到内容模型没有回复“转人工”而是自己编了一个价格。原因提示词里的兜底指令不够强或者温度设太高。解决把温度降到 0.1并且在提示词里加“如果知识库为空必须回复‘我帮您转接人工’禁止自行回答”。同时在知识库检索节点后面加一个条件判断如果返回条数为 0直接走转人工分支不经过大模型。5. 让客服助手越用越准对话日志回流与意图库迭代上线不是终点。一个多轮客服助手如果三个月不迭代准确率会从 85% 掉到 60%因为用户问法在变、产品在变。这一章讲怎么用对话日志做迭代以及一个我常用的验证方法。5.1 从对话日志里挖出高频失败问法COZE 后台有对话日志但默认只存最近一段时间。我一般会每天导出一次日志用脚本筛出“转人工”和“兜底回复”的对话。这些就是失败案例。然后人工看前 50 条把用户问法归类。常见的失败类型有三种新问法意图库没覆盖、新知识知识库没更新、多意图混合一句话问了两个问题。针对新问法直接在意图识别节点里加示例话术每次加 5 到 10 条不要一次加太多否则会影响已有意图的识别。针对新知识更新知识库文档重新切片上传。针对多意图混合需要在意图识别前面加一个“拆解节点”用大模型把用户问题拆成多个子问题再分别走流程。# 伪代码从对话日志中筛选失败案例 import json def filter_failed_dialogues(log_file): failed [] with open(log_file, r, encodingutf-8) as f: for line in f: record json.loads(line) # 转人工或兜底回复视为失败 if record.get(transfer_reason) or 转接人工 in record.get(reply, ): failed.append({ user_query: record[query], bot_reply: record[reply], intent: record.get(user_intent, unknown) }) return failed # 按意图分组看哪个意图失败最多 from collections import Counter failed filter_failed_dialogues(dialogue.log) intent_counter Counter([f[intent] for f in failed]) print(intent_counter.most_common(5))这段脚本跑完你会看到失败最集中的意图。优先修那个意图投入产出比最高。5.2 用影子模式验证新意图库再全量改完意图库不要直接全量上线。我一般会开一个“影子模式”新意图库和旧意图库同时跑但只有旧库的回复发给用户新库的回复只记日志。跑三天后对比两个库的识别准确率。如果新库在失败案例上的识别率提升超过 15%再全量切换。这个做法能避免“改完反而更差”的翻车。影子模式在 COZE 里可以用两个并行的意图识别节点实现一个连到回复节点一个连到日志节点。代价是每次对话多消耗一次意图识别调用但比起全量翻车的代价这点成本可以接受。5.3 一个我坚持了三年的习惯每次改完对话流我一定会用同一组 20 条测试话术跑一遍。这 20 条里5 条是标准问法5 条是口语化问法5 条是多意图混合5 条是边界情况比如空输入、超长输入、纯符号。跑完记录通过率低于 90% 就不上线。这个习惯帮我拦住了至少五次“看起来没问题但一上线就崩”的改动。多轮对话客服的调试没有捷径只有反复跑、反复看日志。希望帮到你。本文还有配套的精品资源点击获取