做多轮对话系统的人都有个很深的体会单轮问答做得好只算及格真正拉开差距的是用户在第五轮、第十轮甚至第二十轮时的体验。很多模型在评测集上分数漂亮一上线就原形毕露——用户说了一半就放弃、同一件事反复确认、明明推荐了相关的内容用户却反馈“越来越烦”。这些问题单看每一轮的对错根本找不到答案因为它们不是某一轮的生成质量问题而是系统对“用户此刻处于什么状态”缺乏感知。最近我在拆解开源AI助手框架OpenClaw时注意到它在多轮对话的用户状态建模上做了一个非常务实的取舍不靠一个黑盒模型去猜用户情绪而是显式地维护一组状态特征——疲劳度、兴趣度、急迫度、目标清晰度等等。这篇文章就围绕这套特征体系展开聊聊这些特征是什么、怎么算、怎么用以及实际接入对话策略时容易踩的坑。1. 为什么多轮对话必须先建模“用户状态”1.1 单轮问答与多轮对话的本质差异单轮问答本质上是一个“请求-响应”的回合制交互用户给一句输入系统给一个输出两者之间不需要考虑历史。哪怕上下文里塞了再长的对话记录很多系统也只是把历史文本拼进提示词里真正决定回复的依然是当前这一句话。这种模式做出来的产品单看每一轮的准确率都说得过去但一旦进入连续对话就会暴露出一个致命问题系统根本不知道用户现在处于什么状态只是机械地接话。打个比方单轮问答就像有人过来问路你告诉他怎么走任务就结束了。但多轮对话相当于陪人逛街他可能一会儿对某件商品感兴趣一会儿又累了想找个地方坐一会儿又在犹豫要不要买。如果你只关注他每一句在说什么而不去判断他现在的体力、兴趣、耐心还有多少那这趟“逛街”的体验一定很糟糕。你会在他已经很累的时候还兴致勃勃地推荐下一家店也会在他明显对某类商品失去兴趣之后继续围绕这个品类滔滔不绝。OpenClaw把这层差异直接体现在系统设计上对话管理模块并不是“拿到当前输入 → 生成回复”的直线结构而是“更新用户状态 → 结合状态生成回复”的闭环。这个状态不是简单的一句话总结而是一组可量化的特征值。动态状态的存在才是多轮对话和单轮问答真正的分水岭。1.2 没有状态建模的对话系统会表现出哪些毛病我见过太多没有状态建模的对话机器人它们的问题高度相似。首先是重复推荐用户已经摇头拒绝了三次系统还在试图把同一个东西换着花样推给用户因为它只知道“用户提到了这个词”不知道“用户已经对这件东西不感兴趣了”。其次是语气和内容密度不变化。不管用户回复是长是短、是热情还是敷衍系统都按同一个模板输出同样长度的内容。用户在赶时间的时候它还在长篇大论地解释用户兴致正浓、愿意深聊的时候它却一句话就把话题堵死了。这种“一刀切”的回复策略本质上是把用户当作一个恒定不变的输入源而不是一个会疲倦、会兴奋、会走神的活人。第三是不会“见好就收”。优秀的销售会在客户已经满意的时候停止推销但很多对话系统却没有这个能力。它们被设计成“必须对用户的问题给出回答”哪怕用户已经表现出明显的疲惫和离开意愿系统还是坚持把话说完整。这种没有收束机制的多轮系统往往是用户流失速度最快的。OpenClaw之所以把疲劳度和兴趣度作为一等特征很大程度上就是为了解决这些“体验层面的硬伤”。1.3 为什么选“显式特征”而不是“端到端学习”有人会问现在大模型能力这么强直接把历史对话丢给大模型让它自己判断用户状态不行吗理论上可以但落地时会遇到几个现实问题。第一是不可解释模型说“用户现在很不耐烦”你没办法知道它是根据什么信号判断的出了问题也不知道怎么修第二是不可干预运营团队想针对某类用户调整策略黑盒模型根本改不动第三是延迟和成本每次生成都让大模型额外判断一次状态多轮对话的每一轮都要承担额外的推理开销这在真实产品里是很沉重的负担。OpenClaw的做法是把用户状态建模看作一个独立的、可观测的中间层。它先把对话行为拆成一组特征信号用规则和轻量模型计算出疲劳度、兴趣度等指标再把结果作为结构化输入提供给生成模块。这样既能保留大模型在语言生成上的优势又能在状态判断上做到快速、解释性强、可干预。这套设计思路本质上就是“把复杂问题拆成可控制的模块”在我看来是工程上最稳的路线。2. OpenClaw用哪些特征来描述用户状态2.1 疲劳度量化对话过程中的精力消耗疲劳度是OpenClaw特征体系里最容易被感知的一个维度它描述的是用户在对话中投入的认知精力还能维持多久。很多初学者会误以为疲劳度就是“对话时长”其实这是一个很常见的误解。一个人可以连续聊三个小时依然精神奕奕也可以刚聊两句就觉得心累真正决定疲劳度的不是时间而是用户在每轮交互中要付出多少认知成本。OpenClaw在为疲劳度设计信号源的时候重点采集了几类行为。第一类是回复长度的变化趋势如果用户一开始回复平均在三五十字到了后面每轮只剩下几个字那通常说明用户不太愿意继续展开话题了。第二类是回复间隔的变化间隔突然拉长往往意味着用户在犹豫、分心或者已经同时在做别的事。第三类是文本里的疲劳标记词比如“算了”“跳过吧”“你再说一遍”“随便”这类带有明显放弃意味的表达。第四类是重复性行为用户反复问同一个问题或者反复纠正同一类细节说明他可能已经没有精力消化新信息了。在工程实现上疲劳度会被归一化到一个0到1的区间。0代表完全轻松1代表极度疲劳。这个值不是每句话都从零开始算而是带记忆地逐步更新后面我会在计算机制那一节具体展开。2.2 兴趣度追踪内容对用户的持续吸引力兴趣度和疲劳度很容易被搞混但实际上它们的更新逻辑和作用方向完全不同。疲劳度描述的是“用户在精力上还能不能继续”兴趣度描述的是“用户在主观上还想不想继续”。一个人很累但依然很有兴趣这个时候他需要的是更轻量的内容呈现方式一个人精力充沛但对当前话题无感这个时候需要的是快速切换话题而不是调整内容的颗粒度。OpenClaw对兴趣度的建模依赖的信号包括用户是否主动追问、是否扩展了话题、是否提到了“这个有意思”“还有吗”“然后呢”这类推进性表达、是否使用了更多带有情绪倾向的词汇、以及用户自己发起的新话题和当前主题的相关性。还有一个很微妙的信号是“沉默之后的活跃度”比如用户长时间没说话然后突然打出很长一段回复这种“想清楚了再说”的行为往往比秒回的“嗯嗯”更说明兴趣度。兴趣度同样会被映射到0到1的区间。特别要注意的是这个特征必须考虑话题的维度。用户整体兴趣度可能很高但对当前具体子话题的兴趣可能已经跌落谷底。所以OpenClaw在实现时会同时维护一个全局兴趣度和一个话题级兴趣度后者用于指导当前轮次的内容组织前者用于判断整体对话的健康程度。2.3 辅助特征急迫度、熟悉度、目标清晰度除了疲劳度与兴趣度OpenClaw还维护了几组辅助特征它们不像前两者那么显眼但同样在实际对话中发挥作用。急迫度描述用户对得到答案的急切程度。高急迫度的信号包括“快点告诉我”“有急事”“简单说”这类表达以及回复间隔极短、连续多轮打断系统输出等行为。急迫度高的用户需要系统压缩回复长度、优先给结论、减少铺垫哪怕牺牲一点详尽性。熟悉度描述用户对对话主题的了解程度。系统通过用户使用的术语密度、是否需要解释基础概念、提出的问题是否停留在入门层来判断。熟悉度高的用户喜欢直接讲深层内容熟悉度低的用户更需要背景知识和渐进式引导。目标清晰度描述用户当前对话目标是否明确。有些用户一上来就说“我要找一款适合跑步的耳机预算一千以内”这是高清晰度有些用户只说“帮我推荐点东西”这是低清晰度。目标清晰度低的对话系统需要主动在探索阶段多花几轮来收敛需求而不能过早进入推荐和总结阶段。2.4 特征耦合疲劳度和兴趣度不是独立变量在OpenClaw的状态模型里这四个特征共同映射到对话的“宏观状态”不同组合会触发不同的策略基调。把疲劳度和兴趣度做成一个二维平面来看高兴趣低疲劳的用户处于“探索模式”这时候系统应该主动扩展话题、提供更丰富的内容、允许对话分支发散。高兴趣高疲劳的用户处于“强撑模式”他想继续但精力不足系统要做的是降低每轮的认知负担比如把内容拆得更碎、多用示例和类比、主动做阶段性小结。低兴趣低疲劳的用户处于“平淡模式”话题对他没有吸引力但他也没有明显的不耐烦此时系统应该尝试切换话题角度或引入新的信息维度来刺激兴趣。低兴趣高疲劳的用户处于“流失边缘”这种状态最危险系统需要尽快收束当前话题、主动提供退出路径或者大胆切换到一个完全不同的话题来挽回体验。这些宏观状态说明单独看任何一个特征都有局限但把特征组合起来看就能给对话策略提供非常清晰的决策依据。3. 特征的计算与更新机制从原始信号到可用状态3.1 信号采集显式信号与隐式信号的配合特征的精度很大程度上取决于信号采集的质量。OpenClaw在这方面同时用了两类信号。显式信号是用户主动表达的反馈比如对话里嵌入的“喜欢”“不喜欢”“太复杂了”“继续”这样的字眼或者产品界面上用户主动点击的“有帮助”“无帮助”按钮。显式信号的好处是准确坏处是出现的频率太低绝大多数用户在绝大多数时候不会主动给反馈。隐式信号从交互行为里挖掘覆盖更广但也更需要小心处理。OpenClaw会记录每轮回复的字数、响应时间、重复率、话题跳跃度、用户是否在回复中引用系统上轮内容等细节。隐式信号的最大麻烦在于噪声很大比如用户回复变短可能是因为累了也可能只是因为他在走路不方便打字。所以在工程上隐式信号都是作为“弱证据”来用的单个信号不触发状态变化要多个信号同时出现才更新状态。我以前做过一个类似系统当时的经验是如果你把单个强信号当作状态变更的充分条件误判率会高得吓人。后来改成“弱信号累计投票”的机制误判率才降下来。OpenClaw的设计本质上也是这个思路。3.2 状态更新时间策略事件触发与时间衰减相结合用户状态不应该每说一个字就疯狂重算也不应该一整天纹丝不动。OpenClaw的更新策略是事件触发加时间衰减的结合。所谓事件触发就是只有检测到特定事件时才显著更新状态。事件类型包括用户出现明显的疲劳信号词、用户主动表达喜欢或厌恶、用户在长时间沉默后突然恢复、用户发起新话题、用户重复了之前的问题。这些事件一出现系统立刻把对应的特征值往上或往下调调整幅度取决于信号强度。时间衰减则处理那些不产生事件的平静时段。用户的兴趣度和疲劳度都不是永恒的哪怕用户中间一直在安静地阅读作为人的状态也在缓慢变化。OpenClaw用一个时间衰减系数来模拟这种漂移比如每经过一段时间疲劳度会自然回落一点兴趣度会朝默认值缓慢回归。这个设计让我印象很深因为它解决了一个我之前没意识到的实际问题用户在对话中途可能去处理别的事情回来之后状态已经完全不同了如果没有时间衰减系统还会按离开前的状态继续对话表现就会很别扭。3.3 归一化与状态融合把不同量纲的信号拧成一股绳信号源五花八门字数、时间、文本情感、点击行为量纲完全不同不能直接相加。OpenClaw对特征的计算分三步先把每个原始信号映射到0到1的分数再按不同权重进行线性加权最后用平滑函数处理避免状态值在边界附近剧烈跳动。举例来说疲劳度的计算可以简化成这样一个过程。假设系统检测到三个信号本轮回复字数比用户历史均值低了40%记为0.7分回复间隔是平均水平的2倍记为0.5分文本中出现了“算了”这样的标记词记为1.0分。三个权重分别为0.4、0.3、0.3那么加权求和就是0.4×0.7 0.3×0.5 0.3×1.0等于0.73再和一个历史衰减值做融合就得到了这一轮更新后的疲劳度。平滑处理也很关键。如果上一轮疲劳度是0.2这一轮直接跳到0.9系统回复风格会在极短时间内剧变用户会觉得这个机器人人格分裂。OpenClaw的做法是限制单次更新的最大变化幅度比如每次最多调整0.2宁可让状态变化慢半拍也不能让它忽高忽低地乱跳。3.4 状态持久化多轮对话的记忆底座还有一个容易被忽略但实际很重要的环节状态持久化。用户状态的载体不能只在内存里活着因为用户随时可能中断会话过几天又回来。OpenClaw会把会话级的状态序列持久化存储同时把长期用户特征作为先验信息在新会话启动时加载进来。例如在同一个用户的新会话里系统会保留他对某个话题的历史兴趣度基线也会保留他上次对话结束时的疲劳度趋势但不会直接使用旧值作为当前值而是用一个较大的衰减系数把它拉向默认状态。这个“旧状态仅供参考”的思路非常关键。我见过不少系统直接把上次会话的最终状态当作这次会话的初始状态结果用户在新的、精神饱满的状态下还要被系统当成一个疲劳的、低兴趣的老客户来对待体验非常差。4. 状态建模如何反哺对话策略OpenClaw的实际用法4.1 基于疲劳度的收束策略疲劳度最直接的应用是触发对话的收束。当OpenClaw检测到疲劳度进入高位区间时它不会继续沿着原有方向推进而是会主动做三件事总结当前进展给出清晰的可退出路径或者大幅压缩后续内容。举个例子用户咨询一个比较复杂的业务办理流程已经聊了十几分钟期间反复表示“怎么这么麻烦”。系统检测到疲劳度显著升高就会在下一轮主动输出“这部分我帮你梳理成一个三步清单你看一下如果有不清楚的我们再细化。如果你现在有别的事也可以先把清单收藏之后任何时候回来都能继续。”这种“给台阶下”的回复就是典型的基于疲劳度触发的收束策略。实际测试中这种收束策略对用户流失率的影响非常明显。没有收束机制之前用户往往是在对话中段突然不再回复加上收束机制之后很多用户会留下一个明确的离开信号之后回来继续对话的比例明显提高。别小看这个细节对话系统的“完成率”指标很大程度上就取决于这种收束能力。4.2 基于兴趣度的聚焦策略兴趣度主要指导系统该“深挖”还是该“平移”。当话题级兴趣度较高时用户可以接受更深入的内容、更长的篇幅甚至愿意接受系统发起的新一轮追问。低兴趣时再好的内容也是噪音系统需要切换话题切入角度或者干脆引导到另一个完全不同的方向。OpenClaw在处理“用户主动追问”这个小信号上做得特别细。如果用户在回复里引用了系统上一轮的某个概念并追问相关细节这是一个强度很高的兴趣信号系统会顺着这个概念继续延展。相反如果用户回复里没有任何引用只是机械地回到自己的目标上系统就会意识到当前概念对用户没有吸引力自动减少这个方向的内容换一个路径来帮他推进目标。这里有一个值得所有对话工程师记住的体会话题级兴趣度的价值高于全局兴趣度。全局兴趣度高但当前子话题兴趣度低的情况太常见了只有落到具体话题的粒度和内容组织上特征建模才能真正发挥作用。4.3 状态驱动的对话节奏控制把疲劳度和兴趣度同时加进来就构成了对对话节奏的控制能力。高疲劳高兴趣状态下系统会把内容切得更碎每轮只讲清楚一个点多用类比和示例降低理解成本高疲劳低兴趣状态下系统会明显缩减回复长度加快轮换频率尽快把对话引导到决定性节点低疲劳高兴趣状态下系统可以输出更长的、结构性更强的内容并通过开放式问题鼓励用户继续扩展表达。这部分在工程上通常做成一个策略矩阵输入是疲劳度和兴趣度的高中低档位输出是一组生成参数包括目标回复长度、段落数量、是否使用列表、是否追加追问、追问的开放程度等等。OpenClaw把这些参数作为结构化上下文直接传给生成模型效果比在提示词里加一句“用户现在很累请简短回复”要稳定得多因为状态是数值化的不同策略的切换门槛非常明确不会出现模型随机解读的情况。4.4 冷启动与状态回归新会话和新用户怎么处理状态建模最大的挑战之一是冷启动。新用户第一次进入对话没有任何历史信号疲劳度和兴趣度全都未知。OpenClaw的做法是为所有特征设置一个中性默认值比如兴趣度0.5、疲劳度0.3、急迫度0.4同时在对话早期用更大的权重去捕捉显式信号前几轮会刻意做一点试探性输出——先抛出一个问题或一个内容方向观察用户的反应再调整状态的估计值。这个试探过程不要做得太明显最好包裹在正常对话中自然地采集。另外对话被打断后的状态回归也很重要。比如用户在午休时聊了一会儿隔了两个小时又回来了。OpenClaw会通过识别时间间隔和话题承接点判断这是“继续上次对话”还是“全新的会话”。时间间隔短、用户主动提到了之前的主题就按继续处理并缩减状态衰减幅度时间间隔长、用户没提之前的主题就按新会话处理状态值大幅回归默认值。这个决策看似简单但很多系统都栽在这里要么把太久之前的旧状态带进新对话要么把刚刚发生过的正常续聊当作陌生人处理。5. 实操心得常见问题与排查技巧实录5.1 疲劳度被误判为“不感兴趣”这是我在实践中遇到的最频繁的误判类型。表面上看疲劳和没兴趣都表现为“回复变短”“追问减少”“态度变敷衍”但它们在策略响应上需要完全不同的处理。疲劳的人需要的是降低内容负担、给他喘息空间没兴趣的人需要的是换一个话题方向他甚至还有精力只是不想聊这个而已。排查这种误判最快的方法是看用户的恢复速度。如果用户在一次简短回复之后又主动追问了一个细节说明他并不是没兴趣只是上一轮输入负担太重。这时应重点检查疲劳信号的权重是否偏高尤其是“回复时间间隔拉长”这一项因为用户可能只是去忙了不代表他累了。我在调参时习惯把疲劳度的“时间间隔”信号权重压低把“回复长度下降幅度”的权重抬高误判率能明显降下来。5.2 兴趣度震荡导致策略频繁切换当兴趣度在0.4和0.6之间来回跳动时系统的对话策略就会在“深入”和“平移”之间反复横跳上一轮还在详细展开下一轮突然缩成一句话再下一轮又变回详细展开。这种体验极其糟糕很多工程同学看到策略矩阵没问题却忽略了输入信号本身在震荡。解决这个问题有两条路。一是给特征计算加平滑窗口不使用单轮信号直接更新而是取最近三到五轮的平均值二是设置策略切换的最小间隔比如一个策略基调一旦生效至少保持两轮不变。OpenClaw实际采用的是双保险计算层平滑加策略层最小间隔。按我的实测这两个机制缺一个都不行。5.3 状态特征被“指标化”之后带来的失真运营团队一旦开始用疲劳度、兴趣度这些指标来做数据分析就要小心一个问题状态值会被人为“哄高”。比如为了提升兴趣度指标系统会倾向于在低兴趣状态下快速切换话题切换本身没错但如果只是为了刷新指标而频繁切换反而会让用户觉得系统飘忽不定。状态特征必须是服务对话体验的中间量而不是最终的绩效考核目标。我在做这类系统时会刻意做一步“状态可信度”的记录。如果某轮更新主要依据的是弱信号就在状态旁打一个低置信度标记只有强信号触发的状态更新才给予高置信度。这样在数据复盘时就能区分出“真实的状态变化”和“信号噪声引发的误更新”不至于被指标牵着鼻子走。5.4 快速自查清单状态建模上线前必查项目整理一份我在上线用户状态建模模块前会逐项检查的清单供大家直接参考。每个特征是否都定义了明确的分值范围并归一化到一致区间避免某个特征天然比另一个大导致加权失去意义。维度上是否区分了全局状态和话题级状态尤其是兴趣度必须落到话题粒度才有用。同一轮对话中多个特征同时剧烈变化时系统是否有策略层的最小间隔保护防止策略反复横跳。时间衰减的速率是否经过真实场景调优默认值不可取要结合业务的实际对话时长分布来定。新旧会话的状态继承逻辑是否明确旧状态是否做了较大幅度的衰减后才作为新会话先验。是否保留了一键关闭状态机制的总开关一旦新版本状态模型导致线上体验异常可以快速回退到纯规则模式。按这个清单走一遍能避免绝大多数上线后才发现的问题。当然状态建模也不是一劳永逸的事用户行为会变业务目标会变特征体系和阈值都要跟着持续迭代。我个人在实际操作中的体会是用户状态建模最忌讳的就是“想当然”。今天看到一个特征觉得有用就加上明天觉得另一个特征重要又加一个最后整个特征体系膨胀到无法解释、无法调优。OpenClaw这套设计的核心参考价值在于克制特征不用多覆盖了精力、兴趣、意图、认知层次这几个关键维度就够了关键是每个特征都能干净地计算、明确地指导策略然后不停地在真实对话中观察信号与状态变化的对应关系用数据说话。最后再分享一个小技巧如果你的对话系统还没有任何状态建模基础不要一上来就做复杂的多特征融合。先把用户的“回复长度变化”和“回复间隔变化”这两个信号记录下来建一个最简单的疲劳度模型同时配一个“当疲劳度高时主动缩短回复”的策略然后去观察线上效果。我做过的事情告诉我这一步做完你就能看到明显的体验提升。有了正反馈再去加兴趣度、急迫度这些维度逐步把系统打磨成完整的用户状态建模框架。
)
