3.4 多轮对话与转人工：答不上来时的体面收场

智能体上线第一周我就在盯一件事：答不上来的用户最后去了哪。答得漂亮是加分项，答不上来怎么收尾才是生死线。一个用户问了三遍没得到答案，又看不到人工入口，直接关窗口走人；客服组还不知道有人来过，这是最亏的——流量花了、信任没了、问题还晾在那。转人工不是说技术不行了，恰恰相反，知道自己不行、并且知道把用户交给谁，才是整个系统设计成熟度的体现。

这一节讲两件事：多轮对话的状态怎么管，以及什么时候、以什么方式把用户交给真人。前面 3.1 讲的异常分支是机器内部的兜底，这一节是面向用户的兜底，标准只有一个：用户离开时没带着怨气。

下单买过东西的人都有体会：一个会打断你、让你重述问题的客服，比一个干脆说办不到的客服更招人烦。智能体同理，多轮对话管得好，用户觉得它懂事；管不好，用户觉得自己在和一个复读机较劲。这一节的内容不涉及多高深的模型能力，几乎全是状态设计和话术打磨，但偏偏是这些最不起眼的地方，决定了客服组用不用得上这个智能体。

多轮对话的状态管理

用户很少一句到位。先问价格，再问能不能开发票，最后问发货时间——这是三个独立意图，不是一次问答。链路里要有一个上下文槽位，记住当前话题，并在话题切换时正确跳转。没有槽位的多轮对话，等于让模型每次都面对一个失忆的对话伙伴，每一轮都在重新猜用户的意图。

实际设计时我定了三条规矩。其一，槽位只存当前话题，上一轮的检索结果不带入下一轮，避免模型把发货的答案编进发票回答。其二，切换话题要明确，用户消息里出现新意图就重新走检索，别自作聪明沿用上文——这也是幻觉的一个来源，3.2 清单里提过。其三，上下文设有效期，间隔超过一段时间就视为新会话，不然用户隔天回来还接着昨天的茬，前面的话题早就过时了。

第四轮的例子值得单独说。用户说查得不对，这时候模型最容易犯的错是换一套说辞重新答一遍，或者干脆道歉但不说错在哪。正确做法是把这句当作对回答结果的不满信号：跳转人工，并且把失败原因标注为查询结果不符。它既是话术问题，也是状态机里一个明确的跳转条件。

三轮规矩定下来后，多轮对话的混乱收敛了大半。效果比对方法很简单：把同一段三意图的测试对话，在改前后各跑十遍，看回答串题的次数。从十次串七次降到十次串一次，这个对照比任何理论都有说服力，也成了后来给客服组汇报时的固定材料。问题模糊时先确认一句：您是问发货时间还是物流公司？一次反问比一次错答划算得多，尤其是订单查询这种带参数的场景（3.3 展开过参数缺失怎么反问）。

槽位设计我走过一段弯路：起初想把所有历史轮次都塞进上下文，结果后面的回答被前面的旧话题带偏。后来只保留两样：当前话题标记和上一次工具调用结果，其他一律丢弃。上下文越短，回答越聚焦，成本也越低——这是一个技术判断之外的收益。

转人工之后用户去了哪

转人工按钮不是终点。我追踪过一批转人工会话的后续：用户点了转人工之后，有多少真的和客服说上了话、问题解决了没有。结果发现一个隐形缺口：从智能体跳到客服工作台之间，有大约百分之十五的会话断了线——用户转完就直接关了页面，客服收到工单时人已经不在了。这部分用户在转人工统计里是个工单，在业务上是彻底流失。

对策是把交接做成长连接：用户留在原窗口等待，客服接入时直接在同一对话里出现，而不是让用户去别的入口找客服。同时转人工后的等待时间给出预期：客服同事正在赶来，前面还有两位，预计三分钟之类——有预期和没预期，用户流失差一倍。

这条链路的打通必须靠数据驱动，盯转人工完成率、平均等待、问题解决率三个数，每周看一次趋势。怎么搭这套监控见 5.3。转人工不是把锅甩给客服，而是让客服在他们最擅长的环节发挥作用，所以数据必须能看到用户转过去之后的结果，而不只是转过去这个动作。

什么时候转人工

转人工触发条件是和客服组一起定的，写死在条件判断节点里：

其中连续两次无答案这条争议最大。客服组怕用户没耐心，希望一次兜底就转；我说只兜底一次直接转，会把大量其实能答的问题推给真人，反而更忙。两次是折中的结果，上线后配合 5.1 的转人工率指标，用数据再调阈值。这些条件不是定死就不能变的，每月复盘一次：哪条触发过于频繁、哪条从来没触发过，都说明判定规则需要调整。

实际上我们最后加了一条隐含规则：同一用户一天内多次触发转人工，直接走优先通道。老用户的问题反复解决不了，是最该优先处理的信号。这条规则是客服组提的，他们对谁频繁来往比系统还敏感。

转人工交接清单

转人工最忌讳的是把用户丢过去就完事：客服接起来不知道前因后果，让用户把问题从头重说一遍，前面的等待全白费。我的交接包里有三样：

对话记录摘要——不是全文，是机器整理的要点：用户问了什么、智能体答了什么、卡在哪一步。全文太长客服没空看，摘要控制在三五行。

摘要的生成放在转人工节点里完成：把本会话最近若干轮对话喂给大模型，套一段固定提示词，输出用户问题、已答内容、卡点三段式。客服组验收过几十条摘要质量，偶尔补一两个字，稳定后才放开自动跑。

用户信息——订单号或手机号尾号（如果对话中出现过）、来源页面、访问时间，方便客服快速定位。这些字段在工单系统里有固定映射：对话摘要写进工单的问题描述栏，用户信息写进客户档案，未解决问题单独占一字段并标红，保证客服打开工单第一眼就看见。

未解决问题——当前悬而未决的那一条，写清楚智能体没能回答的原因（检索为空、工具失败还是超范围），客服一眼就知道该从哪接手。

这三样随工单一并推到客服工作台，转人工的体感基本就被撑住了。客服组反馈最有用的是第三样——未解决问题的原因标注，他们接起来不用先猜发生了什么，两秒钟就能进入正题。

转人工通道本身也可能失败，比如工单系统恰好在维护，这时候的兜底是留言存档并告知用户客服会主动联系，绝不能让请求石沉大海。我把通道失败的告警接到了自己的手机上，虽然是极小概率事件，但兜底的兜底没人盯，就等于不存在。

交接清单怎么落地

三样东西听着清楚，做的时候要解决一个具体问题：摘要谁写。最早我让客服组手工从对话记录里摘，第一天他们就罢工了：一上午二十个工单，每个翻五分钟，比直接聊还累。

后来改成智能体在转人工节点自动生成摘要——模型读一遍本会话的历史，输出固定格式：用户问题、已给过的回答、卡住的原因。成本极低，客服组验收过摘要质量后直接上线。省下来的精力让客服更愿意处理复杂情绪问题，这才是他们不可替代的部分。这也呼应了 3.2 提示词模板的思路：同一个模型，套上不同提示词就是不同工种。

兜底话术的写法

话术是最见功德的细节。同样是答不上来：

低情商版：我不知道，请转人工。用户读出一股敷衍感，潜台词是你问错地方了。

我最后用的版本是三层结构：先给结论（这个问题我手头的资料没覆盖到），再给动作（已经帮您记录，客服会在工作时间回复），最后给选择（您也可以现在直接转人工）。三层分别照顾情绪、不确定性掌控感和自主权。

再举一例。用户问能不能提前发货，知识库没写：

低情商版：不清楚，请联系人工。

改写版：发货时效目前按订单顺序安排，暂时没有加急通道。如果您确实有紧急需求，我可以帮您备注，客服同事会看有没有其他办法。

两者的信息量几乎一样（都没给加急），但后者给了用户一个被接住的感觉：问题被记录、有人会想办法。话术的差距不在知识，在姿态。

另外几个口径：兜底不说绝对否定词，用资料没覆盖到代替我不知道，前者是客观描述，后者像态度问题；转人工给用户选择权而不是强制跳转；敏感问题转人工时话术更沉稳，不渲染情绪也不急着解释。话术定稿后会进 3.2 提示词模板的兜底指令位，和模板是同一套体系，改话术等于改提示词，同样要走变更流程。

话术不是拍脑袋写的。我收集了上线头两周所有兜底会话，按用户回复分三类：满意的、无回复的、发火的。无回复和发火的那两类逐条看话术，发现三个共性：解释太多（用户不想听为什么不行，只想知道接下来怎么办）、选择太少（转不转人工都没得选）、语气太冷（模板痕迹重）。改完之后又收两周数据，无回复比例明显下降。这是拿真实会话喂出来的迭代，比坐在工位上揣摩用户强百倍。

知识库建在本地还是云端，会影响转人工时客服能否快速调取上下文，想对比方案的可以看NAS 家庭服务器。整本书涉及的云端基础底座，腾讯云五件套实战有系统的讲解。转人工链路的长期运行靠监控兜底，故障第一时间发现，见 5.3 那一节的告警设计。

延伸阅读

• 轻量建站实战：官网侧如何承接从智能体转人工的用户。
• 笔记知识库：兜底问题汇总成知识补丁的方法论。