简介一套基于扣子COZE平台构建企业官网多轮对话智能客服的资料包面向有编程基础的开发者与企业技术人员解决用户问题自动应答、服务推荐、信息查询等客服自动化需求。资料仅含1个docx文档大小14KB内容紧凑已有1468人学习。文档围绕完整项目案例依次讲解对话流程设计、意图识别与多轮问答配置、插件与API集成、对话个性化与场景扩展、发布与测试包含意图关键词触发、上下文跟踪、变量提取、HTTP接口调用示例如订单核验等可操作细节。针对企业常用场景还涉及产品推荐、FAQ导航、服务状态查询与用户数据收集借助COZE的低门槛能力可直接参考文中方案将客服Bot接入企业现有系统并通过多轮交互、上下文管理与数据分析持续优化对话效率。文档中的变量提取JSON配置和订单核验请求参数示例便于读者直接复用。1. 官网客服“秒回”背后的多轮对话为什么常用扣子COZE来搭官网挂着在线客服用户点开就问“你们那个能定时的小家电还有货吗”客服回“请稍等我查一下”十分钟过去没下文。这种场景我在多家企业官网见过用户流失就发生在那段等待里。这里要讲的“人工智能客服”是指基于扣子COZE平台搭建的多轮对话智能客服助手用来完成企业官网客户服务自动化。它能在多轮对话里记住用户上一句说过什么、把零散信息拼成完整需求遇到答不了的主动转人工。适合正在选型或者已经在用扣子COZE、但觉得机器人答得生硬的人。2. 搭多轮对话客服前先拆能力意图识别、状态记忆和转人工开关在哪2.1 用户在一场多轮对话里到底在测什么单轮FAQ的模式是“问一句答一句”用户发“怎么退货”机器人从知识库翻出退货流程完了。多轮对话不一样用户开头说“我想买个挂烫机”中间插一句“之前你们推荐的那个会不会漏水”结尾又说“算了还是选便宜的”。这里有三件事单轮模型做不到一是记住“之前推荐的那个”到底指代什么二是把三个零散信息拼成一个完整的购买需求三是在用户变卦的时候及时修正意图。这就是多轮对话能力训练的重点也是用户实际在测试机器人的地方。我在扣子COZE平台配置这类助手时习惯先把用户可能走的分支列出来而不是直接开控制台。分支大致是这样几类意图没识别到时要不要追问追问几轮槽位没收集齐型号、地址、数量怎么二次确认知识库没有答案时兜底话术说什么用户连续表达负面情绪是否提前转人工。把这些先写在纸上再去工作流里配置比建好机器人再慢慢补要省事得多。很多翻车案例并不是模型不行而是没定义“当用户没说清楚时系统下一步干什么”。2.2 把会话状态挂进工作流把“聊天”变成“办事”扣子COZE平台里没有一个叫“状态机”的节点但它把状态机的逻辑拆成了“节点 变量”。常见的做法是先声明一批会话变量比如 intent_name 存当前意图、slot_json 存已收集到的参数、turn_count 存对话轮数、handover_flag 存是否转人工。然后每轮对话都从消息事件进入工作流节点依次读变量、判断条件、改写变量、把结果拼回答案。举个例子。第一轮用户说“我要买挂烫机”intent_name 被设为 product_intent同时把“挂烫机”写进 slot_json。第二轮用户说“有没有便宜点的”工作流看到 intent_name 已经是 product_intent就不会重新去猜这是不是售后问题而是直接进入价格话术分支。第三轮用户说“那算了不买了”intent_name 被改成 abandon_intent流程可以往挽回话术或结束语走。这个转发过程本质上是把“聊天”变成了“办事”每轮都不是独立事件而是对上一轮状态的增量更新。有一点要提醒别在 prompts 里靠“请记住用户刚才说的话”来长期依赖大模型的上下文上下文窗口再大也是有边界的。扣子COZE工作流里的变量是显式状态比让模型自己记要可靠。模型负责理解和生成变量负责记账各干各的才能把多轮对话做稳。2.3 会话落库先把转人工开关设计在字段里很多团队把机器人跑起来之后才发现没有会话数据可回溯用户投诉了都没法对线。我一般会在第一版就建一张会话表字段按下面的结构来CREATE TABLE customer_session ( session_id VARCHAR(64) PRIMARY KEY, user_id VARCHAR(64) NOT NULL, intent_name VARCHAR(64) DEFAULT , slot_json TEXT, turn_count INT DEFAULT 0, handover_flag TINYINT DEFAULT 0, created_at DATETIME, updated_at DATETIME, KEY idx_user (user_id), KEY idx_updated (updated_at) );字段的逻辑说明session_id 是扣子COZE会话的唯一标识user_id 从网页端埋点或登录态拿intent_name 存最后一轮识别到的意图slot_json 存整场对话收齐的参数格式可以是 JSONturn_count 记录轮数超过阈值却没完成目标时直接置为待转人工handover_flag 是人工坐席系统要轮询的字段机器人一闭环不了就把这个字段置 1。这张表同时解决了三件事给人工坐席提供上下文、给多轮对话能力训练提供样本、给弃单分析提供事实依据。没有这张表后面所有评测和优化都是空谈。3. 扣子COZE平台实操知识库、会话流和代码节点把官网客服跑起来3.1 把FAQ和产品手册送进知识库两种灌法一道门槛在扣子COZE平台创建机器人之后第一步是把企业官网的FAQ、产品手册、售后政策灌进知识库。常见做法有两种一是直接上传 Markdown/PDF/Word 文档二是填官网 URL 让平台自动抓取页面内容。两种都可行但我更推荐第一种因为文档可以提前清洗URL 抓回来的内容常带导航、页脚和推荐位噪音多灌进去反而影响检索命中。灌知识库有一道门槛必须过分块。默认按字数切块常常把“产品型号”和“保修政策”切到两块里去用户问“这台 X1 保修几年”时检索返回的可能是半句话。我一般把分块大小控制在 200500 字每块只讲一件事产品型号和保修期限放进同一块不跨主题。文档开头写清楚适用对象比如“X1 电熨斗常见问题”后续检索的命中率会明显高。知识库节点还有几个参数值得调相似度阈值我习惯设在 0.7 左右低于这个值的检索结果直接丢弃返回条数设 3 条给大模型足够信息但不让它同时看到五六个互相矛盾的片段。阈值设太低会出现“任意问题都从知识库拉一段出来”的幻觉这是最常见的翻车源。3.2 编排多轮对话主流程让机器人记住上一步说的话知识库灌完接下来是工作流编排。扣子COZE的工作流绘制区会让你先放一个开始节点和一个结束节点中间按业务需要添加大模型节点、知识库检索节点、条件分支节点和代码节点。多轮对话回路是这样串的开始节点接收用户消息后先走大模型节点做意图判断把结果写进 intent_name 变量再走条件分支看 intent_name 是 product_intent 还是 after_sale_intent走不同分支每个分支里再接知识库检索节点或代码节点最后把答案拼成文案回到结束节点。第二轮用户再发消息时工作流重新从开始节点进入但变量里已经有上一轮的 intent_name 和 slot_json条件分支就能走到“追问缺哪个参数”而不是重头再猜。这里要特别处理轮次限制。常见做法是加一个计数节点当 turn_count 大于等于 3 且槽位还没收齐时不再继续追问而是主动转人工。用户可以接受机器人多问一两轮细节但连续三轮都在问同一个问题用户就会开始烦躁。这个阈值我一般写死在配置里改起来也容易。3.3 用代码节点接真实“查订单”接口别让大模型猜业务数据多轮对话里用户常问“我的订单什么时候到”“能不能改地址”这类数据大模型不知道必须实时调业务接口。在扣子COZE工作流里可以插入代码节点来干这件事下面是一个查订单状态的示例# 扣子COZE 工作流里的代码节点查订单状态 import requests def main(params: dict) - dict: order_id params.get(order_id) user_id params.get(user_id) if not order_id: return {hit: False, result: 没拿到订单号向用户追问} # 替换成企业自己的订单系统地址注意超时设置 api https://api.example.com/orders/query try: resp requests.post( api, json{order_id: order_id, user_id: user_id}, timeout5 ) data resp.json() except Exception: return {hit: False, result: 订单系统暂时开小差给用户一个低姿态话术} items data.get(items, []) info , .join([f{i.get(name)} x{i.get(qty)} for i in items]) return { hit: True, result: f订单{order_id}当前状态是{data.get(status)} f含{info}预计{data.get(eta, 待更新)}送达 }参数说明params 里的 order_id 和 user_id 是从会话变量 slot_json 里解析出来的所以用户在上一轮说了“订单号是 12345”这一轮代码节点就能直接用。timeout 设 5 秒业务系统慢也不能拖垮对话响应。异常分支返回的是“低姿态话术”而不是让大模型自己编一个订单状态这个原则要守住AI 客服可以答不到但不能谎报物流。3.4 一组能直接上线的对话参数模型、温度和记忆窗口在扣子COZE平台的模型配置里有几个参数直接决定多轮对话体验我的参考取值如下参数建议取值说明模型版本生产环境优先选稳定版客服场景追新版本容易踩到未知行为temperature0.3低于 0.2 话术僵硬高于 0.5 开始自我发挥记忆窗口最近 1015 轮太长模型容易混淆太短接不上话知识库返回条数3足够覆盖常见问题减少冲突片段知识库相似度阈值0.7偏低会答非所问偏高会漏答记忆窗口需要多说一句。不是窗口越大越好客服场景里用户经常在一个问题上纠缠超过 15 轮还没解决就该转人工了硬要模型记住前面 30 轮的内容反而会把最后几轮的关键信息冲淡。温度设 0.3 是我个人实践下来的平衡点话术稳定又不至于完全像复读机。“多轮对话能力训练”这类需求很多时候不是换模型而是这些参数先用对。4. 多轮对话能力训练与评测用回归用例集而不是感觉调机器人4.1 从日志里捞出那些“被用户放弃”的会话多轮对话做得好不好不能靠点几轮测试就下结论。我每月会从扣子COZE平台导出一次会话日志筛出那些“用户聊到一半就不理人”的记录。这些会话是优化方向的金矿它们代表了模型没接住用户的地方。筛选可以写一段简单的脚本# 从导出日志里筛“被用户放弃”的会话 import pandas as pd df pd.read_csv(coze_session_log.csv) abandoned df[ df[is_last_msg].eq(1) df[user_content].str.contains(在吗|人呢|算了|没听懂|气死|再见, naFalse) ] stats ( abandoned.groupby(intent_name)[session_id] .count() .sort_values(ascendingFalse) ) print(stats.head(20))逻辑说明is_last_msg 标记每个会话的最后一条消息user_content 里出现“算了”“人呢”这类词说明用户在等待或放弃边缘。按 intent_name 分组统计后能看到哪个意图分支放弃率最高是售后流程太长还是机器人追问次数太多。参数说明关键词列表要定期补充早期只有“算了”“没听懂”后来加了“服了”“再见”这类词覆盖更全。4.2 搭一套回归用例集覆盖意图、槽位、兜底和转人工四类分支优化对话时最怕改了一个分支另一个分支悄悄坏了。我维护了一张回归用例表每次调整知识库或工作流后把用例逐条跑一遍再上线。用例集至少覆盖四类分支用例ID用户输入期望意图期望返回检查点R001想问问你们那台落地扇product_query推荐型号或导购链接意图识别正确R002它噪音大不大spec_query具体分贝数值能读懂指代“它”R003地址填错了能改吗after_sale_query改地址流程知识库命中R004转人工handover转人工排队话术转人工优先级最高R005我随便看看unknown_intent引导类兜底话术不死循环每条用例跑完记录“通过/不通过/不确定”三档。不确定的用例最值得处理说明模型输出不稳定大概率是知识库片段冲突或 prompt 里没定义边界。回归集不用多50 条左右就能覆盖一个中等规模官网客服的主要分支每周增补几条新出现的高频问法就够了。4.3 负样本库与话术修正多轮对话能力训练的边界在哪很多人问“能不能微调模型”在扣子COZE这类平台上底层模型权重通常是不开放的真正能做的多轮对话能力训练集中在三层提示词、知识库、工作流。最常见做法是把用户问了但机器人答错的句子收集成负样本库比如用户问“你们有没有那种不用插电的熨斗”知识库没命中机器人回“对不起我不明白”。这时不用急着加知识库先看是“产品确实不存在”还是“需求没归纳对”。前者直接加一条标准问答后者要修正用户话术到知识库表达之间的检索映射比如把“不用插电”纳入“无线熨斗”的同义词。负样本库的积累是个长期活。我每周固定花半小时把上一周日志里的未命中案例过一遍标记成三类知识库缺内容、意图判断错、话术表达差。标记结果分别对应三个动作补内容、调分支、改提示词。这样多轮对话能力才会稳定上升而不是靠玄学调热度。5. 上线前必看的避坑清单客服机器人翻车多发生在这四处5.1 答非所问且第二句话就忘了上一轮说的什么现象是我测试时连续输入“我想买挂烫机”“刚才那个贵不贵”第二句直接被当成新问题回了一段产品百科。原因多半是工作流里没有把第一轮的 intent_name 和商品名写进变量或者大模型节点没有引用会话变量作为上下文。解决方法是检查工作流把上一轮识别到的 intent_name、关键实体和已填槽位在节点输入里显式传给下一轮不要依赖模型的隐式记忆。改完再测同一段对话看第二轮是否走价格分支。5.2 两个长得像的产品在知识库里互相打架用户问“A 款和 B 款有什么区别”结果机器人把 A 的功率和 B 的重量拼在一起回答数据完全串了。原因是知识库里两个产品的文档分块重叠检索返回的 3 条里既有 A 又有 B模型不知道该信哪个。解决方法是给每款产品的文档加清晰的标题前缀比如“【产品A-操作指南】”“【产品B-常见问题】”并且在提示词里写明当知识库片段涉及多款产品时必须在答案开头标注产品名称只陈述对应产品的内容。另一个补救办法是把相似度阈值从 0.7 提到 0.75减少模糊命中的概率。5.3 “转人工”明明触发了人工客服却收不到任何通知用户说“转人工”机器人也回了“正在为您转接”但人工坐席后台空空如也。原因是转人工动作只停留在对话层没有通过代码节点调用工单系统接口把 handover_flag 写进数据库更没有通知坐席。解决方法是检查工作流条件分支命中 handover 后接一个代码节点把 session_id、user_id、slot_json、对话摘要一并 POST 到工单系统再在工单系统里配上企微/短信/webhook 通知。转人工不能只靠机器人嘴上说说消息链路必须打通到人的终端。5.4 并发一上来响应时间翻倍先查这几个地方上线预热后流量一大机器人从 1 秒响应变成 4 秒。常见原因有三个一是知识库索引没预热首次查询走了慢路径二是代码节点里的业务 API 响应慢每次对话都实时调用三是大模型节点 prompt 太长每轮都把全部历史塞进去。解决方法是按顺序排查先看知识库节点是否需要预加载再看业务 API 是否加了缓存层最后压缩 prompt 里的历史轮数超过 10 轮就滚动丢弃旧内容。代码节点里的外部请求如果非实时不可就加一层 Redis 缓存把高频查询结果缓存 30 秒。6. 上线一个月后的进阶玩法会话摘要、情绪标签和坐席协同6.1 用会话摘要把长对话压成一张工单传给人工转人工时直接把完整对话列表丢给坐席坐席要翻半天才知道用户在干嘛。我一般会在转人工节点前置一个大模型节点把当前会话内容压缩成 100 字以内的摘要包含用户姓名或 ID、咨询意图、已收齐的槽位、是否表达过负面情绪、机器人已给出的回复。摘要写进工单的 first_message坐席一眼就知道从哪接起。这个节点的 temperature 我会调到 0.2摘要不需要创造性稳定最重要。6.2 给对话打情绪标签命中“投诉/退款”直接置顶提醒在代码节点里加一组关键词检测命中“投诉”“退款”“12315”“差评”等词时给会话打上 emotional_flag1同时把该会话在工单系统里的优先级字段置为最高。这个动作不用大模型参与关键词匹配就够快且可解释。上线后用了一个月坐席处理投诉的平均耗时降了不少因为高危会话不会沉底了。6.3 每周看一次“未命中对话”把机器人的黑匣子拆开看我给自己定的规矩是每周一上午拉一次未命中对话列表逐条标记是知识库缺内容、意图判断错还是话术表达差。这三类分别对应补文档、调分支、改提示词三个动作。有一次我把知识库相似度阈值从 0.7 调低到 0.65当周退货咨询的答错率直接翻倍后来才明白阈值不是越高越好也不是越低越好而是必须和文档分块质量配合着调。从那以后我再也不乱动阈值每次只改一个参数改完跑一遍回归用例集再上线。这些小事不如新功能显眼但多轮对话的质量就是靠一轮一轮补出来的。希望帮到你。本文还有配套的精品资源点击获取