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 自主为主，灵活	混合，关键节点强约束	状态机为主，全链路审计
人格	专业、简洁	主动、有温度	谨慎、克制、免责声明	专业、克制、零承诺
风险等级	中	低	极高	极高
HITL	简单转人工	几乎不需要	任何诊断建议必须提示就医	任何投资建议必须免责+人工可选
兜底	转人工客服	转人工导购/留资	明确声明非诊断+建议就医	明确声明非投资建议+转人工
合规要求	中（消费者保护）	中（广告法）	极高（执业医师法、个人信息）	极高（金融监管、反洗钱）
关键禁忌	暴露其他用户信息	虚假宣传、价格欺诈	给出具体诊断或用药剂量	承诺收益、推荐具体个股

医疗和金融两个行业的设计共同点是：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 分级、反模式识别