深度专题四十七 对话式 AI 与智能体产品设计

47.1 从"聊天机器人"到"智能体产品"的范式转移

理解对话式 AI 与智能体产品设计的第一步，是先把两件常被混为一谈的事情拆开：对话是一种交互通道，**智能体（Agent）**是一种系统能力。前者回答"用户怎么告诉系统要什么"，后者回答"系统能不能自己把事办了"。

过去十年，业内经历了三次明显的范式更迭。第一阶段是规则与检索型聊天机器人（2015 前后），代表是早期的客服 FAQ 机器人、微信公众账号里的关键词自动回复，本质是一张"关键词—话术"映射表，稍复杂的就用决策树。第二阶段是任务型对话系统（2017—2022），以 Rasa、Dialogflow、微软 LUIS 为代表，工程上分成 NLU（意图识别 + 实体抽取）和 DM（对话管理，内部又分对话状态跟踪 DST 和对话策略 Policy），用有限状态机（FSM）或机器学习策略驱动多轮填槽完成任务，例如订机票、查余额。第三阶段是 2023 年后随大模型成熟而兴起的智能体产品：系统不再被钉死在预设流程图里，而是由 LLM 作为"推理引擎"，根据用户目标自主规划、调用工具、读写记忆、在必要时回问澄清，最终把任务推进到一个可验证的完成状态。

一句话区分：聊天机器人陪你聊，任务型对话带你走流程，智能体替你把事办了。

这个转移对产品设计的影响是结构性的。任务型对话时代，设计师的工作是画对话流图、定义意图和槽位、写话术模板；到了智能体时代，设计师要定义的是目标、工具集、边界约束、记忆策略和人在回路（HITL）的触发条件。前者是"控制每一步怎么说"，后者是"约束 agent 在哪些范围里自由行动"。这是从微观编排到宏观治理的转变，也是为什么很多团队把对话流图直接搬到 agent 上会失败——agent 不按你画的线走，它按自己理解的子目标走。

需要强调的是，范式转移并不意味着旧范式被淘汰。今天一个成熟的客服产品内部通常是三层共存：80% 的高频问题走检索 + 模板（快、稳、可控、便宜），15% 的标准业务流程走任务型对话状态机（合规、可审计），剩下 5% 的长尾和复杂组合交给 agent 自主处理（灵活、覆盖广）。FDE 在现场做方案时，第一步往往不是"上 agent"，而是先帮客户画出这张三层分布图，把不该用 agent 的地方坚决拉回规则层。

47.2 对话式 AI 的设计层次

把一个对话式产品纵向切开，可以看到五个必须被分别设计的层次，缺一层都会出问题。

意图理解层。回答"用户到底想干嘛"。传统做法是训练意图分类器（fastText、BERT 微调），今天主流是用 LLM 做零样本或少样本意图识别，配合一个意图体系（intent taxonomy）。设计要点是：意图粒度要和业务动作对齐，而不是和语言表达对齐——"我想退掉上次买的那个东西"和"申请退款"是同一个意图。另一个常被忽视的设计是意图置信度阈值与兜底意图（fallback / out-of-domain）：置信度低于阈值时不强行猜，而是回问澄清，这一步能显著降低后续错误链。

多轮管理层。核心是对话状态跟踪（DST）：每一轮把用户的最新输入和已有上下文合并成一个结构化的"当前状态"（已填槽位、未填槽位、用户偏好、历史决策）。设计上要回答三个问题：上下文窗口保留多少轮、哪些信息要持久化到长期记忆、跨会话如何关联同一个用户。工程上 Rasa 的 Tracker、LangGraph 的 state、自研的 session store 都在做这件事。

任务执行层。把"理解到的意图"翻译成"对后端系统的调用"。这一层的关键是工具（function/tool）的粒度和契约：工具太粗，agent 一次调用要塞十几个参数容易出错；工具太细，agent 要串十几次调用才能完成一件事，延迟和失败率都高。经验值是单个工具的入参不超过 5—7 个，且每个参数都有明确的类型和示例。

人格（Persona）层。回答"agent 用什么口吻、什么立场说话"。人格不是写一段 system prompt 让它"热情友好"那么简单——人格要和品牌、风险等级、专业边界一致。医疗 agent 不能用"亲，建议您试试哦"这种口吻，金融 agent 不能用调侃语气谈论亏损。人格设计包括语气、主动程度（是被动应答还是主动建议）、信息密度（一句话回答还是展开解释）、以及自我边界声明（明确告诉用户自己不能做什么）。

兜底层。任何对话系统都会遇到答不出、做不了的情况，兜底设计决定了那一刻用户体验是崩塌还是优雅。兜底不是一句"我还没学会这个问题"，而是一套组合：澄清式回问、提供相关替代方案、记录到待学习队列、必要时转人工。一个没有兜底层的产品，用户用三次就会弃用。

47.3 对话流设计：树状 / 状态机 / Agent 自主

对话流设计有三种主流范式，对应不同的可控性—灵活性权衡。

树状对话是最早的形态：每一个节点是一个系统提问，根据用户回答走向不同分支。优点是可预测、可测试、可审计，缺点是只能覆盖设计者预想到的路径，用户一旦跳出树就死掉。适合流程极其标准、且合规要求高的场景，比如银行开户的身份核验环节。

状态机对话是树状的泛化：把对话抽象成一组状态和状态间的转移条件，允许环路（用户改主意可以回到上一个状态）。Rasa 的 stories、Dialogflow 的场景都是这一类。状态机比树状灵活，能处理"用户中途改主意""主动跳过某步"等情况，但状态数量随业务复杂度爆炸，维护成本高。实践中超过 30 个状态的状态机就很难维护了。

Agent 自主对话是 LLM 时代的新范式：不再预先画流程图，而是给 agent 一组工具、一组约束、一个目标，让它自己决定每一轮说什么、调什么工具、什么时候结束。这种范式灵活性最高、覆盖最广，但可控性最差：同一句话两次问可能走不同路径，难以做回归测试，合规审计困难。

经验法则：合规要求每一步可审计的，用状态机；流程开放、答案空间大的，用 agent；两者之间的，用状态机做骨架 + agent 做节点内的灵活处理（即"结构化的 agent"）。

FDE 在现场最常推荐的混合架构是：外层状态机管主流程和合规节点，节点内部用 agent 处理自然语言理解和长尾回复。例如保险理赔，主流程（报案—取证—定损—核赔—结案）用状态机保证每一步都有审计记录，而每个节点内部用户怎么表达、agent 怎么追问，交给 LLM 自由发挥。这样既守住了合规底线，又拿回了灵活性。

47.4 智能体产品的核心要素

拆解一个真实的智能体产品，绕不开六个要素，少一个都立不住。

目标（Goal）。agent 必须有一个清晰的、可验证的终止条件。"帮用户解决问题"不是目标，"在 3 轮内确认用户的退货商品编号、退货原因，并生成退货单"才是。目标设计的关键是可验证——系统能自己判断有没有完成，而不是靠人感觉。

工具（Tools）。agent 的能力边界等于它能调用的工具集合。工具设计有三个原则：契约清晰（参数、返回值、错误码都有 schema）、粒度适中（见 47.2）、有副作用标注（只读工具可以随便试，有写副作用的工具必须经过确认）。

记忆（Memory）。分短期记忆（当前会话上下文，通常用滑动窗口或摘要压缩）、长期记忆（跨会话的用户画像、偏好、历史决策，通常落到向量库或结构化存储）、工作记忆（agent 在完成单个任务时的中间状态，比如"我已经查过库存了，结果是 X"）。记忆设计最大的坑是记忆污染：把用户的临时玩笑当成偏好永久记住，导致后续行为变怪。治理办法是给记忆加 TTL、加置信度、加来源标记，定期清洗。

人格（Persona）。见 47.2，不赘述。

约束（Constraints）。约束是 agent 的护栏，包括硬约束（不能越权、不能编造、必须经过确认才能执行高风险动作）和软约束（回答长度、响应风格、单次任务最大轮数）。约束要写到 system prompt 里，但光靠 prompt 不够，关键约束必须有代码层的强制检查作为兜底——prompt 是建议，代码是法律。

人在回路（HITL, Human-in-the-Loop）。哪些动作必须人工确认才能执行？哪些情况自动转人工？用户能不能中途打断、回退、改主意？HITL 不是"出错了才找人"，而是从一开始就设计好 agent 的自主权边界。常见分级是：低风险只读动作全自动、中风险写动作自动执行但留痕可申诉、高风险动作（转账、删除、合同签署）必须人工二次确认。

47.5 用户体验：何时对话、何时界面、何时静默执行

对话式 AI 最大的反模式之一，是为对话而对话——把原本一个表单、一个按钮就能搞定的事，硬塞进对话里让用户来回说五轮。好的产品设计师会先回答一个问题：这件事到底该用对话、用界面，还是 agent 静默完成？

判断框架可以参考三个维度。模糊度：用户需求模糊、需要澄清和探索的，适合对话（"我想找个适合送长辈的礼物"）；需求明确、参数确定的，适合界面（"买两张明天北京到上海的高铁票，G1 次二等座"）。频次：高频重复操作适合界面固化成快捷入口，低频复杂任务适合对话引导。代价：操作可逆、代价低的可以让 agent 静默执行后告知（"我帮你把会议改到下午三点了，已通知所有人"）；操作不可逆、代价高的必须显式确认。

黄金法则：对话适合"探索和澄清"，界面适合"高效执行"，静默适合"低风险日常代办"。三者混用才是好产品。

一个具体的混合设计案例：电商导购助手。用户说"想给女朋友挑个生日礼物"，agent 用对话澄清预算、风格、收件时间（对话层）；澄清完进入商品列表，用界面让用户滑动筛选比较（界面层）；用户选定下单后，agent 静默跟踪物流并在到货时主动提醒（静默层）。三层各司其职，没有任何一层越俎代庖。

47.6 信任设计：可解释、可中断、可回退、透明

智能体产品比传统软件更需要信任设计，因为它的行为不可完全预测。信任不是靠"我们的模型很准"宣传出来的，而是靠四个具体能力挣来的。

可解释（Explainable）。agent 做了一个决定，要能说出依据。不是泛泛的"基于大数据分析"，而是"我查到您账户近三月平均消费 8000 元，且本月已支出 6500 元，所以建议您这个月不要再办分期"。可解释设计要求 agent 在关键决策点显式输出 reasoning，并保留可追溯的决策日志。

可中断（Interruptible）。用户随时能打断 agent 正在做的事。这在多轮执行中尤其重要——agent 正在调用一连串工具，用户发现方向错了必须能立刻叫停。工程上需要支持工具调用的取消、正在进行的 LLM 流式输出能中断、已发出的副作用动作能尽量回滚。

可回退（Reversible）。已经执行的动作要尽量能撤销。转账类不可逆动作必须设计"软提交"窗口（几秒内可撤回），数据修改类动作要保留版本历史。Agent 产品的设计原则之一是默认 reversible，不可逆动作必须显式提升到 HITL。

透明（Transparent）。让用户知道自己在跟什么对话、agent 当前在做什么、哪些信息被记住了。透明设计包括：明确标识"这是 AI"（不要假装真人）、展示 agent 当前的中间步骤（"正在查询库存…""正在生成订单…"）、允许用户查看和删除自己的记忆数据。透明度低的产品短期转化可能更高，长期必然因信任崩塌流失用户。

47.7 失败体验：优雅降级与转人工

任何对话式产品都一定会失败，区别只在于失败时表现得有多难看。失败体验设计是把"必败"变成"不伤人"。

**优雅降级（Graceful Degradation）**的层级通常是：首选方案失败 → 自动尝试次选方案 → 给出有限选项让用户选 → 坦诚告知能力边界并提供替代路径 → 转人工。例如用户问一个 agent 答不了的专业问题，降级链是：尝试检索知识库 → 检索不到则给出 3 个相关问题让用户选 → 都不合适则坦诚说"这个问题我需要转给人工客服"。

**转人工（Handoff）**是失败体验的最后兜底，但转人工本身也需要设计。关键信息必须一起转过去：用户身份、当前会话上下文摘要、agent 已经做过的尝试和结论、用户情绪状态评估。一个糟糕的转人工是让用户把事情再说一遍——这几乎必然引发愤怒。好的转人工是无缝的，用户感觉只是"换了个更专业的人"，而不是"从头开始"。

转人工的触发条件要预先定义清楚，通常包括：连续 2 轮 agent 没有进展、用户主动要求人工、检测到负面情绪关键词、agent 置信度低于阈值、任务超时、涉及高危操作。这些触发条件要写进系统的监控规则里，而不是靠人工盯着。

47.8 评估对话 / Agent 产品

对话式产品的评估比传统软件难得多，因为它没有"完全对或完全错"的二值结果。业内常用的评估指标体系分四层。

任务成功率（Task Success Rate / Task Completion Rate）。用户带着一个目标来，最终是否达成了目标？这是最核心的指标，通常通过事后人工标注或用户显式反馈（"问题解决了吗？"）来收集。一个合格的客服 agent 任务成功率应在 60% 以上，优秀的能到 80%+。

效率指标。完成同一任务用了几轮对话、平均响应时长、平均工具调用次数。轮数不是越少越好——为了压低轮数而省略澄清反而会降低成功率，关键是每轮都有信息增量。

满意度指标。CSAT（满意度评分）、NPS、用户主动表扬/投诉比例、复访率。满意度是主观指标，但它的趋势比绝对值更有意义——持续上升说明产品在变好。

过程指标。意图识别准确率、槽位填充准确率、工具调用成功率、转人工率、每轮的困惑度（用户说"什么？""没懂"的频率）。这些是诊断性指标，用来定位瓶颈。

评估方法上，离线评估用标注测试集（准备几百到几千条标准对话，跑完后人工打分），在线评估用 A/B 测试 + 影子评估（shadow evaluation，新版本不真正服务用户，只在后台并行跑，对比两个版本的输出）。Agent 评估还要加一层对抗性测试：故意构造边界 case、注入误导信息、模拟用户改主意，看 agent 会不会崩。一个没经过对抗测试就上线的 agent，几乎一定会在生产环境出洋相。

47.9 行业产品设计差异

同样是对话式 AI，不同行业的约束完全不同，照搬方案必败。下表对比四个典型行业的设计差异。

医疗和金融两个行业的设计共同点是：agent 永远在做"提供信息和提示就医/咨询专业人士"的事，绝不替用户做专业判断。这不是技术做不到，而是责任归属问题——agent 给了错误诊断，谁来负责？所以这两个行业的 agent 设计必须把"我不能替代专业医生/顾问"这一条焊死在人格和兜底层里，且每个回答末尾都带免责声明。FDE 在这两个行业驻场时，第一步往往是和法务、合规一起把责任边界谈清楚，再开始画方案。

47.10 反模式：为对话而对话、黑盒不可控

最后总结几个高频反模式，方便 FDE 在客户现场快速识别并劝退。

反模式一：为对话而对话。把已有的表单、按钮、列表硬改成对话交互，理由是"对话是未来"。代价是用户每做一个操作都要说三五句话，效率反而下降。判断标准很简单：如果这个操作在界面上 3 秒能完成，在对话里要 30 秒，就不要用对话。对话应该用在它真正擅长的地方——模糊需求的探索和澄清。

反模式二：黑盒不可控。Agent 设计完全没有约束、没有 HITL、没有可解释性，全靠 prompt 信任模型自觉。结果是一旦模型在某次回答里跑偏（编造数据、越权操作、口无遮拦），整个产品没有任何护栏能拉住它。这种产品上线一次事故就够毁掉信任。治理办法见 47.6：硬约束必须有代码层兜底，关键动作必须 HITL。

反模式三：把意图体系做成语言层而不是业务层。意图按"用户怎么说"分类（"查询余额""余额查询""我想看看我有多少钱"分成三个意图），而不是按"用户要做什么业务"分类。结果意图数量爆炸、互相重叠、维护噩梦。正确做法是同一个业务动作归一个意图，语言层的多样性交给 NLU 或 LLM 自己处理。

反模式四：记忆无治理。把每一句话都塞进长期记忆，不做 TTL、不做置信度、不做清洗。三个月后 agent 记了一堆过时信息和用户的临时玩笑，行为越来越怪。记忆必须有生命周期管理。

反模式五：用成功率掩盖体验问题。报告说"任务成功率 85%"，但用户满意度很低——因为成功的 85% 里很多是"虽然最后办成了，但中间被来回折腾了八轮"。必须同时看成功率和效率指标，单看任何一个都会被误导。

反模式六：转人工即放弃。转人工被当成"agent 搞不定了就甩锅"，没有上下文传递、没有用户情绪评估、没有失败原因记录。结果是人工客服接过来后要从头问一遍，用户体验比纯人工还差。

识别这些反模式的能力，是 FDE 在对话式 AI 项目里最重要的现场判断力之一。它们都不复杂，但在客户急于上线、产品经理急于 demo 的氛围里很容易被忽视，最终酿成上线即翻车。

本专题小结

对话式 AI 与智能体产品设计，本质是在可控性、灵活性、信任度三者之间做权衡。范式从聊天机器人 → 任务型对话 → 智能体的演进，不是后者淘汰前者，而是三种范式在不同场景下共存——成熟产品往往是 80% 规则 + 15% 状态机 + 5% agent 的三层结构。

设计的核心抓手是五层架构（意图 / 多轮 / 执行 / 人格 / 兜底）和六要素（目标 / 工具 / 记忆 / 人格 / 约束 / HITL）。对话流的三种范式（树状 / 状态机 / agent 自主）对应不同的可控性需求，FDE 现场最常推荐的是"外层状态机 + 节点内 agent"的混合架构。

用户体验上必须破除"对话万能"的迷思：对话适合探索和澄清，界面适合高效执行，静默适合低风险代办，三者混用才是好产品。信任设计（可解释 / 可中断 / 可回退 / 透明）和失败体验（优雅降级 / 转人工）是 agent 产品能不能长期活下去的关键，评估则要用任务成功率、效率、满意度、过程四层指标体系交叉验证。

行业落地必须先谈责任边界再谈技术方案——医疗和金融的 agent 永远在做"信息提供 + 专业人士提示"，绝不替用户做专业判断。最后，六个高频反模式（为对话而对话、黑盒不可控、意图按语言分、记忆无治理、单看成功率、转人工即放弃）是 FDE 在客户现场最需要警惕的陷阱，识别并劝退它们，往往比堆砌新功能更有价值。

本专题来源

• Thoughtworks《如何借助 LLM 设计和实现任务型对话 Agent》，关于对话状态管理 Tracker 与槽位跟踪的工程实践
• 阿里云 PAI《基于 LLM 的意图识别解决方案》，意图识别从规则到 LLM 的演进路径
• Rasa 官方文档与 Wechaty 社区资料，Rasa NLU（意图+实体）+ Rasa Core（对话管理状态机）架构
• 火山引擎《两万字聊对话系统》，DM 模块细分为 DST（对话状态跟踪）与 Policy（对话策略）的系统性阐述
• ScienceDirect 2025 综述《AI Agents vs. Agentic AI: A Conceptual Taxonomy》（Sapkota 等，被引 648 次），agent 与 agentic AI 的概念区分
• Springer 2025《Agentic AI: A Comprehensive Survey of Architectures》，将 agentic AI 定位为智能系统设计的范式转移
• Stanford HAI 关于从 conversational AI 到 agentic AI 范式转移的研究
• 行业实践：客服 / 导购 / 医疗 / 金融四类助手的产品设计与合规边界差异
• FDE 驻场经验：对话式 AI 项目的三层架构（规则 + 状态机 + agent）选择、HITL 分级、反模式识别