★ FEATURED ARTICLE 多轮对话做得久了有一个特别扎心的体验你的机器人明明能听懂每一句话却经常在聊到第十轮的时候把已经明显不耐烦的用户当成刚进门的客人来热情接待。单轮意图识别做得再漂亮也解决不了“用户状态在变”这件事。OpenClaw 的对话框架里专门有一层用户状态建模User State Modeling它不回答“用户想要什么”而是回答“用户现在处于什么状态”——疲劳度、兴趣度、情绪、认知负荷这些维度都会被量化成特征喂给下游策略层。这篇文章基于我在实际项目里使用 OpenClaw 的经验把这套特征体系怎么设计、怎么计算、怎么落库、怎么用起来掰开揉碎讲清楚。1. 为什么多轮对话必须建模“用户状态”而不只是“用户意图”1.1 单轮意图识别解决不了的三个问题很多团队做对话机器人的第一步都是怼意图识别用户说“我要退货”识别出 return_intent然后走退货流程。这套逻辑在单轮场景下完全够用但一旦对话超过三轮问题就来了。第一个问题是用户目标会漂移。用户可能一开始在问价格聊着聊着其实是想比价然后又变成问售后政策。单轮意图识别每次都在猜“当前这句话是什么意思”但不知道用户从头到尾在追什么回复就容易断档。第二个问题是用户的交互状态在变。同样一句“你再说一遍”可能是刚才没听清也可能是已经烦了。意图一样状态完全不一样处理方式也必须不一样。第三个问题更隐蔽用户的耐心是有限度的。如果系统感知不到用户已经疲劳还在按标准流程一步一步确认信息用户大概率会直接流失。所以多轮对话系统必须有一个跨越单轮之上的“状态视角”。OpenClaw 的做法是在对话管理模块里单独维护一份用户状态每一轮对话结束后都会更新一次而不是每次从零推理。1.2 用户状态层在 OpenClaw 架构里的位置OpenClaw 的整体结构大致分成四层输入理解层ASR/NLU、对话管理DM、用户状态层User State Tracker、策略与生成层Policy/Response Generation。很多框架会把状态跟踪放在 DM 内部OpenClaw 把它拆出来单独做原因很实际状态特征不仅要给 DM 用还要给推荐、风控、话术策略等多个模块共用。举个例子电商售后的多轮对话里如果用户状态层判断“当前兴趣度下降”推荐模块就不会再推送商品而是转人工如果判断“情绪强烈负面”风控模块会提前介入避免投诉升级。这些决策不是 DM 一家的需求所以状态建模独立成层方便复用。同时用户状态层还负责维护一个叫“会话记忆”的东西——注意它不是简单的历史消息堆叠而是经过结构化抽样的状态序列。每轮对话结束时状态层会把“用户说了什么”抽象成“用户处于什么状态”然后传给策略层去做加权决策。1.3 规则打分与模型预测的混合路线对用户状态建模业界主流有两条路线一条是纯规则加权一条是端到端模型预测。OpenClaw 实际采用的是混合方案。核心状态疲劳度、兴趣度、情绪先用可解释的规则指标算出原始分再用一个轻量模型做校准和融合。纯规则的好处是可控、可解释、好排查。某个用户的疲劳度突然飙升你打开日志就能看到是哪几个指标把它顶上去的这对线上问题定位极其重要。纯模型的好处是能捕捉到规则想不到的高阶特征比如用户语气里那种微妙的敷衍感。OpenClaw 的做法是让规则负责“稳定”让模型负责“纠偏”二者取长补短。我自己的实践经验是混合方案虽然在开发阶段多花一点时间但上线后调优成本低很多。状态特征是强时序相关的东西用户聊十轮和聊三轮各项特征天然不同规则部分天然适应这种差异模型部分再用历史序列做修正整体效果比单用任何一种都好。2. OpenClaw 的状态特征体系疲劳度、兴趣度是怎么定义的2.1 疲劳度最容易理解、也最容易做坏的特征疲劳度是 OpenClaw 用户状态里最有代表性的一个特征。它想回答的问题是用户当前还有多少耐心继续这场对话。这个特征设计得是否合理直接决定对话会不会把用户聊跑。OpenClaw 里的疲劳度采集信号包括响应时延用户回复越来越慢或者突然变快典型的不耐烦打字都是信号。消息长度变化从长句变成短句、从完整句子变成单字回复都是疲劳上升的迹象。重复措辞用户开始重复说过的需求说明他没得到想要的答案耐心在被消耗。纠错次数用户频繁纠正系统比如“不是这个”“我说的是另一个”疲劳累积速度会非常快。标点与符号密度感叹号变多、表情符号消失在中文对话里也是常见信号。这些信号在 OpenClaw 里并不是简单相加而是带权重的。每个信号先归一到 0-1 区间再做加权平均。我从项目里的默认配置抄过一组参考权重响应时延 0.25、消息长度变化 0.2、重复措辞 0.25、纠错次数 0.2、符号表达 0.1。这个权重不是玄学它的逻辑是“重复”和“纠错”直接表示用户已在对抗权重给得最高时延和长度的置信度相对低容易受客观因素干扰权重就给得保守一点。疲劳度计算之后会映射到三个档位正常0-0.4、偏高0.4-0.7、严重疲劳0.7-1.0。档位的意义在于给策略层一个明确的动作边界而不是让策略层去跟连续值硬碰硬。2.2 兴趣度追踪用户“还想不想聊”兴趣度是 OpenClaw 里另一个核心特征它衡量的是用户对当前话题的投入程度。疲劳度偏“负向警戒”兴趣度则偏“正向引导”两个特征一起构成了对话节奏调节的核心依据。OpenClaw 的兴趣度主要看以下几个信号话题停留时长用户在某个主题上连续追问的轮次越多兴趣度越高。主动提问率用户主动抛出“那这个呢”“还有别的吗”说明兴趣高涨。追问深度用户的问题越来越具体比如从“多少钱”到“保修期内换新怎么收费”这是强烈兴趣的信号。回复开放性用户给出的是开放性回答还是封闭式回答前者兴趣更高。情感极性对话中正面情绪占比越高兴趣度整体越高。实际操作中兴趣度是用“正向信号累加”和“负向信号折减”的方式计算的。比如用户连续追问三次每追一次正向信号加 0.2如果用户连续三次只回“嗯”“哦”“好”负向信号把分数往下拉。OpenClaw 默认还会加入一个小小的随机扰动项防止多个用户的状态值一模一样这在做策略 A/B 测试时特别有用不然分桶会非常尴尬。2.3 情绪、满意度、认知负荷这些辅助维度除了疲劳度和兴趣度OpenClaw 的状态特征体系里还有几个辅助维度虽然单个看起来不那么显眼但组合起来价值很高。情绪维度Emotion是直接基于情感分析结果做的七分类映射高兴、平静、困惑、不满、焦虑、愤怒、中性。它和疲劳度的区别在于情绪是短时波动疲劳是长时间累积。用户可能上一轮生气下一轮被安抚后平静下来情绪特征每轮都会刷新。满意度Satisfaction更像一个滑动窗口内的累积评分它综合了问题是否解决、解决速度、交互轮次等外部结果信号。认知负荷Cognitive Load用信息密度来衡量比如用户回复里的数字、专业术语、技术参数多了说明用户正在处理高负荷信息系统这时要主动简化表达。还有一个容易被忽略的特征是“时间压力”OpenClaw 会记录用户是否在短时间内反复查看时间相关的内容或者是消息里出现“快”“赶时间”等词。时间压力高时即使疲劳度不高系统也应该缩短回复。辅助维度在 OpenClaw 里统一走一个特征融合层。融合层做的事情是每个辅助维度先独立打分再按场景权重汇入一个总状态向量。场景权重是配置化的比如客服场景里情绪权重高教育场景里认知负荷权重高闲聊场景里兴趣度权重最高。这套设计的弹性很好不用改动特征本身只调权重就能适配不同业务。3. 特征的在线更新机制快照、衰减与状态切换3.1 状态快照的数据结构有了特征定义下一步就是怎么存。OpenClaw 每一轮对话结束都会生成一份用户状态快照State Snapshot结构大概是这样的 JSON{ session_id: sess_20240516_001, turn_id: 12, fatigue: { score: 0.63, level: high, signals: { latency: 0.42, length_shrink: 0.78, repeat: 0.8, correction: 0.55, punctuation: 0.12 } }, interest: { score: 0.35, level: low, signals: { topic_dwell: 0.3, question_rate: 0.2, depth: 0.4, openness: 0.5, sentiment: 0.0 } }, emotion: frustrated, satisfaction: 0.4, cognitive_load: 0.2, time_pressure: false, updated_at: 2024-05-16T12:33:21Z }每个快照里都带信号明细而不是只存最终分数这个设计我很认同。排查线上问题的时候只看总分根本不知道问题出在哪必须能下钻到信号级别。比如疲劳度 0.63你必须看到底是重复措辞爆了还是响应时延爆了才能决定调策略还是调采集。3.2 衰减因子让旧状态逐步失效多轮对话状态建模很容易犯一个错把第一轮的老黄历一直背到最后。OpenClaw 在更新状态时给每个特征都配了时间衰减因子旧状态对当前状态的影响随时间指数衰减。衰减的公式很朴素当前有效值 历史值 × e^(-λ × Δt)。其中 λ 是衰减速率不同特征取值不同。疲劳度的衰减速率慢因为疲劳是慢变量情绪衰减快因为情绪是快变量。在长会话里这个差异尤其重要用户前一小时很兴奋不代表现在还兴奋但用户连续聊了一小时疲劳度一定是累积的。实际代码里我经常把衰减做成一个独立函数方便在实验里对比不同 λ 的效果import math def decayed_value(old_value, elapsed_turns, lambda_): return old_value * math.exp(-lambda_ * elapsed_turns)在 OpenClaw 的默认配置里疲劳度 λ 取 0.05情绪 λ 取 0.3兴趣度 λ 取 0.15。这几个数值调起来非常敏感后面我会专门讲怎么调。3.3 阈值切换与状态机如果每个特征都只是连续分数策略层用起来会很麻烦。OpenClaw 在特征分数之上建了一层简单的状态机把连续分数离散化成档位同时允许状态之间有转移条件。疲劳度的状态机是正常 → 偏高 → 严重疲劳只有“严重疲劳”能触发降级策略比如主动建议转人工、压缩回复长度。转移条件不光是看当前分数还要看这个分数持续了几轮。比如疲劳度连续三轮超过 0.7才会进入严重疲劳状态。这么做的目的很明确防止单轮抖动造成误判。3.4 状态如何影响下游策略状态层的最终价值体现在它对策略层的影响上。OpenClaw 的策略模块在生成回复前会先读当前状态向量然后做三件调整调整回复长度、调整主动引导程度、调整交互模式。疲劳度偏高时策略层会强制压缩回复长度把原本两段式回复合并成一句话同时减少反问直接给结论。兴趣度高时策略层会增加追问和推荐把对话往深处带。情绪低落时策略层会切换话术模板加入更多共情表达。这些调整通过一组权重配置来控制状态分数只是输入真正的业务规则都落在配置里这使得非技术人员也能参与调优。4. 实操搭一个最小可用的用户状态模块4.1 从对话日志里提取信号原理讲得再多不如亲手搭一遍。我建议你用 OpenClaw 的离线日志模式先跑通整个流程日志里每一轮对话都会记录消息内容、时间戳、用户ID、解析结果。信号提取就是把这些原始字段换算成前面表格里的特征信号。实际工作中响应时延用当前轮和上一轮的时间差减去系统回复耗时消息长度变化用的是当前轮消息长度除以会话平均长度的比值重复措辞通过计算当前消息和近三轮消息的文本相似度来判断相似度超过 0.7 就记为一次重复。这些信号提取代码最好做成与具体业务解耦的纯函数输入原始对话数据输出结构化信号方便单测。4.2 疲劳度的规则实现我在项目里写过一个最小版本的疲劳度计算函数核心逻辑就是用加权平均把信号合成总分WEIGHTS { latency: 0.25, length_shrink: 0.2, repeat: 0.25, correction: 0.2, punctuation: 0.1, } def compute_fatigue(signals: dict) - float: score 0.0 for k, w in WEIGHTS.items(): score w * clamp_01(signals.get(k, 0.0)) return round(score, 2)注意几个细节信号进来之前必须先做归一化和异常值截断。比如用户响应时延可能因为网络问题飙到 10 分钟这种异常值必须截断在合理上限内否则一个离群点直接让疲劳度打满。我踩过这个坑后来在信号层统一加了一层 winsorize 处理超过 95 分位数的值全部压到 95 分位数。挡位映射我习惯用分位数而不是固定阈值来做。因为不同业务的用户打字习惯差异很大游戏用户回复普遍短客服用户回复普遍长固定阈值在 A 业务合理在 B 业务就失灵。OpenClaw 本身也支持用历史数据动态计算分位数阈值我强烈建议你在上线前用一周历史日志跑一遍看看自己的用户分布落在哪。4.3 兴趣度的情感加权实现兴趣度的核心是扣住“主动”和“投入”。最小实现里我用消息长度、问号数量、追问标记、情感极性四个信号做加权其中情感极性来自一个小的情感分析模型输出 -1 到 1 之间的值。def compute_interest(msgs, sentiment_score): length_factor min(1.0, sum(len(m) for m in msgs) / 80.0) question_factor sum(1 for m in msgs if m.endswith(?)) / max(1, len(msgs)) initiative_factor has_question_mark(msgs[-1]) and 还有 in msgs[-1] sentiment_factor max(0.0, sentiment_score) interest (0.3 * length_factor 0.3 * question_factor 0.2 * float(initiative_factor) 0.2 * sentiment_factor) return round(interest, 2)这个版本的参数比较糙但作为基线足够用。你上线后会很快发现光靠这几项是不够的这时再往里面加“话题停留时长”“追问深度”这些信号就行。OpenClaw 的好处是特征接口是开放的你可以在不碰其他模块的情况下往里挂自己的特征计算器。4.4 冷启动新用户的状态从哪来新用户没有历史对话状态怎么初始化是很多人忽略的问题。OpenClaw 的默认做法是用类型化先验按入口渠道、场景类型、时段来赋初值。比如通过客服入口进来的用户初始疲劳度给 0.3初始情绪给中性通过活动页进来的用户初始兴趣度给 0.5疲劳度给 0.2。冷启动初始化不可太激进。我的经验是前两轮一律让状态层处于“观察模式”只更新不决策等到第三轮有了足够的信号再让状态真正参与策略调整。这样避免了第一句话稍微长一点就把用户标记成疲劳这种乌龙。5. 常见问题与排查实录5.1 疲劳度被误判用户只是打字慢这是最常见的问题。有人天生打字慢或者正在走路只用单手回复响应时延和消息长度两个信号会同时走高把疲劳度顶到高位。更麻烦的是这类误判一旦发生策略层会强制缩短回复用户反而觉得系统变敷衍了。排查方法是别只看时延要结合上下文。OpenClaw 里有个好用的技巧是看“相对时延”而不是“绝对时延”拿用户当前轮的响应时间跟他自己前五轮的平均响应时间做对比比值超过 1.5 才算时延信号。这样打字慢的用户只是基线高不会被误伤。另外回复长度缩短不等于疲劳。如果你发现用户消息长度在降同时保留着表情符号和问句那大概率是进入“高效沟通模式”不是疲劳。这种时候要把符号信号和重复信号结合起来看避免单指标决策。5.2 兴趣度分数震荡兴趣度是几个特征里最容易震荡的。用户可能这一轮连续追问兴趣度冲到 0.8下一轮因为收到一条不满意的回答立刻回个“哦”兴趣度掉到 0.2。策略层如果在每个轮次都跟着这个分数剧烈调整行为用户体验会非常分裂。我的解法是给兴趣度做指数滑动平均平滑系数取 0.6 到 0.7让历史信息占一定权重。OpenClaw 里对应的配置项是 interest_smoothing_factor。还有一招是只在高兴趣或低兴趣状态持续两轮以上时才触发策略变化单轮极值只更新分数不改变策略实测下来能让状态系统稳定很多。5.3 跨会话污染用户昨天聊了一轮很糟糕的售后今天再次进来如果系统把昨天的低满意度直接带过来用户会感觉到莫名其妙的“被安抚”——我们明明才刚说第一句话。OpenClaw 的做法是把跨会话状态分为“强保留”和“弱保留”两类。强保留特征包括用户的长期偏好、知识背景、历史满意度基线这些可以跨会话保留但也要加衰减。弱保留特征包括疲劳度、情绪、时间压力这些必须随会话结束立即清零或者大幅衰减。我在配置里把情绪跨会话保留系数设为 0.1疲劳度设为 0效果比较好。5.4 阈值怎么调先看分布而不是拍脑袋最后说说阈值调整。很多人上来就问“疲劳度阈值应该设多少”这个问题没法直接回答因为答案藏在数据里。正确的姿势是先跑一周历史日志统计所有特征的分布然后按分位数确定初始阈值。比如把 70 分位作为“偏高”的起点85 分位作为“严重”的起点再结合线上业务指标去微调。我调阈值时看的核心指标是“误触发率”和“漏触发率”。误触发是用户明明状态正常系统却降级了漏触发是用户已经很不耐烦系统还在装模作样地走流程。理想情况下误触发率控制在 10% 以下漏触发率控制在 5% 以下。如果两个指标都下不来别急着调阈值先回去看信号采集是不是漏了关键项。6. 关于这套状态体系我最后想说的几句OpenClaw 这套用户状态建模思路其实本质上是把人的直觉变成了可计算的特征。你别把它想得太玄疲劳度就是在回答“用户还有多少耐心”兴趣度就是在回答“用户还想不想聊”情绪就是在回答“用户现在爽不爽”。特征体系本身并不复杂复杂的是怎么让这些特征在真实业务里稳定可靠地工作。我在实际项目里最大的体会是状态建模的第一原则不是精确而是稳定。一个偶尔不准但从不震荡的状态系统远比一个时准时不准的系统更容易调优和上线。所以如果你要动手做类似的东西我建议先跑通规则版本把日志和排查工具做扎实再考虑上模型。最后再分享一个小技巧把状态快照全部落到独立的日志表里每天都跑一张“状态分布日报”看看疲劳度偏高占比、情绪负面占比这些指标有没有异常波动。状态层出问题往往不是线上报错而是业务指标悄悄变差有了这份日报你就能在用户流失之前提前发现问题。这套用户状态建模的方法后续还可以扩展去做用户分层、个性化话术生成、甚至预测用户流失概率路径都是通的关键是先把当前这套跑稳。
阅读完成 · 觉得有帮助？
