第二章：用户意图理解与多轮对话设计
"林然对着监控面板发了好一会儿呆。他的智能客服Agent上线第二周，数据显示用户平均对话轮次是7.8轮------看起来对话挺活跃。但当他把每段对话逐条打开看时，发现了一个诡异的现象：'你好，我的订单发货了吗？' '好的，请问您的订单号是？' 'JD20260512001' '您说的是订单号 JD20260512001 对吗？' '对' '已查到您的订单，运输中，预计明天送达。' ------ 一段本应2轮完成的对话，硬生生走了4轮。这种'多轮但不是好对话'的体验，让林然的Agent在第二周流失了34%的回访用户。"
2.1 意图识别的五层模型：从"听到了"到"真懂了"
产品经理做Agent对话设计，最容易犯的错误是把"意图识别"当作一个NLP问题甩给算法团队。实际上，意图识别首先是产品设计问题------你设计了一个什么样的表达接口，决定了用户表达意图的难度，也决定了算法能识别多准。
我们来看一个五层递进模型：
| 层级 | 名称 | 用户表达 | Agent理解 | 产品设计问题 |
|---|---|---|---|---|
| L1 | 关键词匹配 | "查订单" | 触发订单查询 | 预设了哪些关键词？漏掉了什么？ |
| L2 | 模板匹配 | "帮我查下昨天那个蓝色T恤到哪了" | 意图=查物流，物品=蓝色T恤，时间=昨日 | 模板能覆盖多少种说法？ |
| L3 | 上下文推断 | （上一轮在聊退换货）"那个订单呢" | 意图=查退换货订单 | 如何关联上下文？多义代词怎么办？ |
| L4 | 隐含意图 | "天气真好" （在订机票场景中） | 用户可能想看旅游推荐或目的地天气 | 如何判断隐含意图？该追问还是猜测？ |
| L5 | 意图纠偏 | "帮我取消订单"（3秒后）"不对，先看看能不能改地址" | 识别用户自我修正，撤销前一个意图 | 如何区分"新意图"和"修正旧意图"？ |
大多数Agent产品的第一个版本卡在L1和L2之间------做了一堆关键词规则和正则匹配template，看起来能覆盖80%的case，但那20%的遗漏恰恰是最致命的：用户觉得"说不通"，一次就流失了。
真正让林然头疼的是L3------上下文推断。他的日志里有大量这样的片段：
用户: 帮我查一下最近那个订单
Agent: 请问您的订单号是？
用户: 就是上次退的那个
Agent: 抱歉，我无法理解您的意思。请提供您的订单号。
【用户关闭对话窗口】这段2轮对话的失败，不是因为Agent能力不够，而是因为林然没有设计"上下文记忆读取"------Agent知道用户是谁、知道用户最近的订单列表、知道有一条订单处于退货状态，但它没有在设计层面把这些信息关联起来。
产品设计启示：L1-L2靠技术，L3-L5靠设计。 你需要在PRD里定义的不是"准确率要达到95%"，而是"当用户说'那个'时，Agent读了哪些上下文信息来做指代消解"。
2.2 对话状态管理：你要管理的不是对话，是任务进度
很多PM把对话设计理解为"设计问答对"------用户问什么，Agent答什么。周明远在创业初期也踩过这个坑------他让团队梳理了300多个FAQ问答对，以为覆盖率高了体验就好。
上线两周后他才发现：用户真正需要Agent解决的，不是"回答一个问题"，而是"完成一个任务"。 而任务需要多轮对话，多轮对话需要状态管理。
对话状态机的三个核心变量
把Agent的对话流想象成一个状态机，它始终在追踪三个核心变量：
1. 槽位（Slots）------"这个任务的参数集齐了吗？"
每个任务都有一组必填参数。以"查询物流"为例：
| 槽位 | 类型 | 必填 | 获取方式 |
|---|---|---|---|
| 订单ID | string | 是 | 用户提供 / 从上下文最近订单推断 |
| 收件人手机后四位 | string | 是（安全验证） | 用户提供 |
| 查询意图 | enum | 是 | 从用户消息提取 |
产品设计点：哪些槽位必填、哪些可选、默认值是什么，这些不能靠算法拍脑袋，要由PM定义。林然的改进版中，他把"手机验证"从必填改为"最近订单跳过验证"，对话轮次直接从4轮降到2轮------一个简单的产品决策，比任何NLP模型优化都有效。
2. 上下文窗口（Context Window）------"Agent现在'记得'什么？"
上下文窗口不是越大越好。LLM的上下文窗口已经能塞下一本小说，但在Agent对话设计中，你需要精确定义"当前应该引用什么"：
| 上下文类型 | 示例 | 保留策略 |
|---|---|---|
| 当前任务槽位 | 正在填的订单号 | 任务完成前保留 |
| 对话历史 | 上两轮说了什么 | 滑动窗口保留最近N轮 |
| 用户画像 | 用户是VIP客户 | 全程可用 |
| 领域知识 | 本公司的退换货政策 | 全程可用，按需检索 |
设计陷阱 ：很多PM让Agent把整个对话历史都塞进上下文，以为这样Agent就更"聪明"。结果恰恰相反------上下文越膨胀，Agent越容易"分心"，在无关信息中找答案。林然的经验是：明确告诉Agent"当前任务的上下文边界"，反而是提高准确率最快的方法。
3. 对话阶段（Dialog Phase）------"现在在任务流程的哪一步？"
一个典型的任务型对话会经历以下阶段：
意图确认 → 信息收集 → 执行操作 → 结果呈现 → 收尾/转下一步每个阶段的用户期望和Agent行为完全不同：
- 意图确认阶段：用户期望Agent快速理解，不需要追问太多。如果20个字能说清的意图被追问了3轮，用户已经开始烦了。
- 信息收集阶段：用户可以接受一定的追问，但Agent必须解释"为什么要问这个"。单纯抛一个"请输入您的订单号"远不如"我需要您的订单号来查物流状态，它通常在确认邮件里"------前者像机器人，后者像客服。
- 执行和结果阶段：Agent需要展示进展。"正在为您查询"和沉默等待的体验天差地别。
2.3 多轮对话设计模式：四种经典结构
下面四种多轮对话模式，覆盖了Agent产品中90%的对话场景。你不需要每个都从零设计，直接套用框架，再根据业务调整。
模式A：信息收集型（Form Filling）
适用场景：需要收集多个字段才能执行的任务。如酒店预订、售后服务登记、表单填报。
设计要点：
- 一次只问一个槽位（别一口气列出5个问题）
- 告诉用户还差几个信息，给他一个完成感
- 已收集的信息要展示出来，允许用户随手修正
- 允许跳过非必填项，不要卡住
对话示例：
用户: 我要换货
Agent: 好的，我需要先查到您的订单。您的订单号是？（还差3个信息即可提交换货申请）
用户: JD20260512001
Agent: 已查到：蓝色T恤 ×1，6月2日签收。请问换货原因是？（还差2个信息）
[显示] 订单号 JD20260512001 ✓
换货商品 蓝色T恤 ✓
用户: 尺码不合适
Agent: 收到。您需要换成什么尺码？（最后一步）
[显示] 订单号 ✓ | 商品 ✓ | 原因 尺码不合适 ✓
用户: L码
Agent: 已帮您提交换货申请：蓝色T恤 → L码。预计1-3个工作日审核，通过后会发短信通知您。模式B：探索引导型（Discovery）
适用场景：用户不知道自己想要什么，需要Agent引导发现。如内容推荐、问题诊断、需求探索。
设计要点：
- 先缩小范围再深入（不要一开始就问细节）
- 每个选择后给出即时反馈，让用户感受到"在进展中"
- 提供"快捷选项"降低决策成本，同时保留"自由输入"通道
- 允许随时返回上一步
对话示例：
用户: 我电脑开不了机了
Agent: 我帮你排查一下。开机时屏幕有反应吗？
[有显示，但进不去系统] [完全黑屏] [有异响]
用户: 选 [完全黑屏]
Agent: 了解。电源指示灯亮吗？
[亮的，正常] [不亮] [闪烁]
用户: 不亮
Agent: 这很可能是电源问题。建议检查：
1. 电源线是否松动
2. 试试换个插座
如果还不行，我帮你预约最近的维修点，需要吗？模式C：求证纠偏型（Clarification）
适用场景：用户信息模糊或Agent不确定理解是否正确时。
设计要点：
- 不要问"您能再说一遍吗"------这暗示Agent无能
- 用自己的理解复述一遍，让用户确认或修正
- 给出候选项降低用户修正成本
- 如果连续2轮纠偏失败，切换策略（给出菜单选项或转人工）
对话示例：
用户: 我要改地址
Agent: 您想修改收货地址对吗？我看到您最近有一个待发货订单（JD123），是修改这个订单的地址吗？
[是的] [不是这个订单] [我想修改默认地址]
用户: 不是这个，是我账号里的默认地址
Agent: 明白了，您的默认收货地址现在是：
北京市朝阳区望京SOHO T1 1506
您想改成什么地址？模式D：多任务编排型（Multi-task Orchestration）
适用场景：一个用户意图实际包含多个子任务，需要Agent识别并有序执行。
设计要点：
- 先展示任务清单，让用户确认理解一致
- 显示进度条或步骤提示（"第2步/共4步"）
- 一个子任务失败不影响其他子任务
- 全部完成后给出汇总
对话示例：
用户: 下周去杭州出差，帮我安排
Agent: 好的，我理解你需要：
1. 查航班/高铁
2. 订酒店（周一至周三？）
3. 安排杭州本地的客户拜访
我按这个顺序来，如果缺了什么你随时补充。
【开始第1步】你偏好高铁还是飞机？2.4 模糊意图与降级策略：用户不说清楚的时候
如果说前三种模式是正常路径，那这一节讲的就是异常路径------也是产品体验最见功力的地方。
林然的Agent上线后遇到的第一类"真实用户行为"不是清晰的问答，而是：
- "嗯......帮我看一下吧"（用户自己也不知道要什么）
- "之前那个"（完全不提供辨识信息）
- "算了"（放弃型输入，但有可能还想继续）
- "Help me"（跨语言混合输入）
- 直接丢一张截图（多模态，但Agent第一版完全没处理）
处理模糊意图的三级策略：
| 策略级别 | 触发条件 | Agent行为 | 成本 |
|---|---|---|---|
| L1 主动猜测 | 置信度 > 80% | 用确认式回复："我猜您想查物流，对吗？" | 低，1轮确认 |
| L2 缩小范围 | 置信度 50-80% | 给出2-3个候选项："您是想查物流、改地址、还是取消订单？" | 中，可能需要2轮 |
| L3 结构化引导 | 置信度 < 50% | 列出能力清单："我能帮您处理以下事项，您选一个？" | 中，但可能流失 |
| 兜底 | 连续3轮无法识别 | 转人工/留消息/引导到FAQ | 高，体验断崖 |
产品设计要点：L1到L3的策略听起来都合理，但哪个场景用哪一级，PM必须在PRD里写清楚。不能把"主动猜测"用在金融交易等高风险场景------猜错了用户就再也不会信你了。
2.5 案例拆解：一堂花34%流失率买来的对话设计课
让我们回到林然的智能客服。第一版失败后，他做了三件事，把对话体验从"能用"变成了"好用"：
改进一：任务卡片式入口替代开放式对话
改之前：一个空旷的对话框，用户不知道能说什么。
改之后：对话顶部展示3个高频任务卡片：
[查物流] [改地址] [申请退款]用户点了"查物流"，Agent直接跳进模式A（信息收集型），自动读取最近订单，对话平均轮次从7.8降到了3.1。
设计原则 ：自由输入是能力的上限，但引导式入口是体验的下限。 不要把用户丢进空白对话框让他自己想------你定义了Agent的能力边界，就该让用户看到这个边界。
改进二：给每个追问一个"为什么"
改之前：
Agent: 请输入您的订单号改之后：
Agent: 我需要您的订单号来查物流状态（您可以在确认短信或邮件里找到，通常是JD开头）改动只有一句话，但任务完成率提升了18%。用户不是不愿意配合，是不理解为什么要配合。
改进三：主动提供"最近用过的"快捷选项
改之后：
Agent: 我看到您最近有一个待收货的订单（JD123 - 蓝色T恤），
您要查这个吗？[是] [不是，查别的]这个改动让80%的查物流场景从3-4轮缩减到1轮。因为大多数用户查的就是最近一个订单------系统知道，之前只是没在设计里用上。
2.6 决策矩阵与本章小结
对话设计模式选择矩阵
| 对话场景特征 | 推荐模式 | 关键指标 |
|---|---|---|
| 参数明确、需要收集多个字段 | 模式A：信息收集型 | 槽位填充率、平均对话轮次 |
| 用户不知道自己要什么 | 模式B：探索引导型 | 任务完成率、引导点击率 |
| 用户表达模糊 | 模式C：求证纠偏型 | 首次纠偏成功率 |
| 一个意图包含多个子任务 | 模式D：多任务编排型 | 子任务完成率、中断率 |
| 连续识别失败 | 兜底策略 | 人工介入率 |
本章核心要点
- 意图识别首先是产品设计问题。L1-L2靠NLP，L3-L5靠你的设计决策------上下文怎么用、指代怎么消解、隐含意图要不要猜。
- 对话状态管理管的是任务进度，不是对话历史。槽位×上下文窗口×对话阶段，三维度决定了用户感受到的是"智能"还是"智障"。
- 四种对话模式覆盖90%场景。别每个对话流都从零设计，直接套信息收集/探索引导/求证纠偏/多任务编排框架。
- 异常路径比正常路径更见功力。用户不说清楚时怎么处理------三级降级策略必须写入PRD，不能靠算法自由发挥。
- 界面设计 > 对话设计 > 模型能力。任务卡片式入口、追问理由说明、快捷选项------这些前端设计决策对体验的影响往往比模型精度更大。
行动建议
- 今天就做的：拿出你的Agent产品中的一段对话日志，逐条检查：①有哪些追问是没有解释"为什么"的？②有哪些用户信息其实系统已经知道了但没有在设计里用上？
- 本周完成的：选一个核心任务场景，画出完整的对话状态机------包括正常路径和3种以上异常路径（信息缺失、用户改口、工具超时）。
- 持续优化的：建立对话轮次监控，每周拉出"轮次最长Top10"的用户对话，逐条分析------是设计问题（该合并的问题分开了）还是用户问题（不知道该说什么）？
当用户说了"你好，帮我查一下那个订单"，Agent理解了意图、收集了信息、完成了多轮确认------接下来，它需要真正"动手"去做了。执行，不是Agent自己闷头写代码，而是调用一系列可组合的Skill和工具。第三章，《Skill生态与插件化架构设计》，我们进入Agent产品的"肌肉系统"。