在实际的大语言模型对话应用中用户很少会像考试题一样把完整需求一次性说清楚。更常见的情况是先说要做什么再补一个条件中途又换了一个方向最后还可能说“还是按最开始那个方案来”。这种需求不断变化的过程就是用户意图的演变。很多开发者在调试对话应用时遇到过类似现象模型在单轮问答里表现得很好但用户连续聊几轮之后系统就开始答非所问——要么死守最初的理解要么被最后一句带跑。这个问题有一个贴近研究语境的描述LLMs Get Lost in Evolving User Intent也就是语言模型在处理持续演变的用户意图时会“迷失”。这篇文章会按这样的顺序展开先界定什么是演变的用户意图再从 Transformer 的注意力机制和工程实现方式分析模型为什么会迷失接着用最小实验让现象可复现然后给出四种工程化缓解策略并落地一个意图状态管理模块。最后补充生产环境中的参数选择、常见坑、评估方法和上线检查清单。内容适合正在做对话系统、Agent、客服机器人、智能推荐等方向的开发者和算法工程师也适合刚接触 LLM 应用开发、想理解“为什么模型聊多了就跑偏”的读者。1. 先理解“演变中的用户意图”到底难在哪里1.1 静态意图与动态意图的区别在传统 NLP 里意图识别通常被建模成一个分类问题给一句话判断它是查询天气、订机票还是闲聊。这种做法把每个用户输入当成独立样本处理意图是静态的。但在真实多轮对话中用户意图很少是静态的。用户可能在第一轮表达核心目标第二轮补充限制条件第三轮因为新信息而调整目标第四轮又推翻之前的决定。这种动态变化要求系统不仅理解“当前这句话在说什么”还要理解“这句话相对之前的意图做了什么修改”。两者最大的区别在于静态意图看重“当前输入的独立语义”。动态意图看重“当前输入与历史决策之间的增量关系”。比如同一句话“还是便宜的更好”如果前文在对比两台笔记本它表示选择低价机型如果前文在讨论显卡品牌它表示降低显卡预算。脱离历史这句话的意图就是模糊的。LLM 虽然在单句理解上很强但把它放进不断变化的上下文里它并没有天然的机制去维护一个可查询、可更新、可回滚的“意图状态”。1.2 意图演变的四种典型模式观察真实用户行为后可以把意图演变归纳成四类模式。每种模式对系统的要求都不一样。演变模式用户表现LLM 容易出现的错误系统需要做什么细化逐步补充限制条件把补充条件当成新话题追加约束保留已有信息切换明确表示换了目标仍然沿用旧需求生成结果识别切换重建状态回退说“还是按原来的来”当成全新需求丢失原约束保存历史快照支持恢复模糊化需求越说越含糊直接丢弃早期信息标记待澄清主动反问以“细化”为例用户说“我想买台笔记本”然后说“屏幕要好一点”再补一句“主要用来剪视频”。这三句话合在一起才构成完整意图。如果把每句话独立处理第二次是在追加屏幕要求第三次是在追加用途要求而不是在换话题。很多系统出错是因为模型把后补充的信息误判成了替代关系。“切换”模式则是另一类难题。用户说“算了笔记本先不看帮我看看台式机”这是一次明确的话题切换。系统一边要保留用户对“视频剪辑”和“预算”这类跨话题仍然有效的偏好一边要把设备类型从笔记本换成台式机。如果直接清空所有状态用户就得重新说一遍需求如果完全不清空模型又会把台式机推荐当成笔记本推荐。1.3 为什么多轮场景比单轮问答难单轮问答可以看作一个“给定问题生成答案”的映射。模型的输入是完整可见的答案只需要对齐这一句话。多轮场景引入了几个额外的变量时间顺序哪句话先出现哪句话后出现直接影响意图的覆盖关系。指代关系用户说“那个”“这个”“还是刚才说的”都需要回到历史中解析。更新语义用户是在追加信息、替换信息还是撤销信息单靠文本相似度无法判断。信息权重不是所有历史信息都同等重要。预算和核心目标通常比语气词重要得多。LLM 本身没有“状态”概念。它只是一个基于上下文的概率生成器。把多轮消息直接拼进 prompt本质上是在赌模型能从纯文本中隐式推断出状态。对话变短时问题不大对话变长、意图变化次数变多后模型就会在文本海洋里丢失关键信号。2. 从模型机制看 LLM 为什么会在意图演变中迷失2.1 近因偏差后说的话往往赢得更多注意力Transformer 的注意力机制会计算每个 token 与上下文中其他 token 的相关度但实际应用中靠近 prompt 末尾的 token 往往对输出影响更大。这是因为生成时模型需要把“最近读到的信息”作为续写依据位置编码也会显著影响相关性计算。放在对话场景里这个机制会造成一种典型错误用户前几轮明确说了预算不能超过 8000最后一轮随口问“那 4080 显卡的机器怎么样”模型可能直接忽略预算约束推荐一台 1 万多的设备。原因不是模型“不听话”而是它在计算概率时最后那句关于显卡的提问把注意力拉走了。离模型最近的文本天然拥有更高权重。缓解办法不是给模型加提示说“请记住预算”而是要在输入层面把关键约束放到足够显眼的位置最好独立于对话流水单独固定在 prompt 的安全区域。这一点后面会展开。2.2 早期关键信息被上下文稀释当对话轮次不断增多时早期信息会被不断压缩、折叠、混合。即使模型有 128K 的上下文窗口它也不会像数据库一样精确记住“第三轮用户说过预算 8000”。上下文窗口只是“能容纳”不等于“能精确保留语义”。从信息论角度看每轮新增的消息都会改变整个序列的概率分布。后加入的内容会与已有内容产生注意力交互早期 token 的特征向量经过多层编码后会被大量后续信息覆盖。用户最初的诉求是“剪辑 4K 视频”聊了二十轮后这个信息在向量空间里可能已经变得非常微弱。这也是为什么建议不要把全部历史消息直接塞给模型。原始材料的价值密度会随着轮次增长而下降真正需要保留的是从历史中抽取出来的结构化意图状态而不是逐字逐句的聊天记录。2.3 对话状态缺乏显式维护机制LLM 应用最常见的做法是把messages数组不断追加用户说一句往列表里加一条然后整体发给模型。这种方式本身没有错误错误在于把“消息历史”当成了“对话状态”。对话状态应该是可查询的当前用户的最终目标是什么、已经确认的条件有哪些、哪些条件还冲突、上一轮意图与当前意图是什么关系。但消息历史只是原始事件流它不区分事实和情绪不区分已确认和待确认也不区分旧信息和新信息。意图一旦演变原始文本是“演变前的内容”和“演变后的内容”的混合物模型必须自己推断哪一个覆盖哪一个。比如用户说“预算 8000”三分钟后说“预算可以放宽到 10000”。从消息历史看这两句话是两条独立消息模型需要自己判断后一句覆盖前一句。文本里没有显式标记“这是一次 REPLACE 操作”模型只能靠语义做概率推断出错是正常的。2.4 指令冲突与自我漂移另一种迷失来自系统指令的冲突。很多应用会在系统提示里写“请优先按照用户最新要求执行”同时又要求“记住用户的初始目标”。当用户最新一句话是在初始目标基础上做细化时这两条指令没有冲突但用户最新一句话是在否定初始目标时模型就会出现两难。例如系统要求原则一记住用户最开始的目标。原则二用户最新意图优先。当用户说“还是算了不买笔记本了帮我看看显示器”模型可能既能生成笔记本相关的推荐也能生成显示器推荐具体结果取决于哪条原则在注意力分布中更占优势。这种摇摆就是“自我漂移”。要解决这个问题必须把“更新还是覆盖”的判断从模型隐式推断中剥离出来交给显式的状态操作。用户明确说“算了换成别的”这是一次 SWITCH用户说“再加一个条件”这是一次 ADD用户说“还是按最早那个方案”这是一次 ROLLBACK。只有把这些操作建模清楚模型才不需要猜测。3. 用最小实验让“迷失”现象可复现3.1 实验场景设计为了不依赖具体模型也能观察问题可以先做一个纯文本实验模拟一段意图持续演变的对话然后用两种方式构造输入对比哪种方式更能保留关键信息。第一种方式是“直接截取最近几轮”模拟很多人使用messages[-5:]的做法。第二种方式是“先抽取结构化意图状态再根据状态生成压缩摘要”。这个实验不调用任何大模型 API只对比信息保留结果用来说明消息历史与意图状态之间的鸿沟。对话剧本设计如下用户我想买一台剪辑 4K 视频的笔记本。用户预算控制在 8000 以内。用户平时主要用达芬奇调色。用户算了还是看看台式机。用户你觉得哪种处理器更适合我这个剧本里存在两次重要演变从笔记本切到台式机从具体机型咨询变成处理器对比。真正跨轮次始终有效的约束是“剪辑 4K 视频”和“预算 8000 以内”真正被替换掉的是设备类型。3.2 示例代码# 模拟一段会演变的对话 turns [ 我想买一台剪辑4K视频的笔记本, 预算控制在8000以内, 平时主要用达芬奇调色, 算了还是看看台式机, 你觉得哪种处理器更适合我, ] # 方案一只保留最近 N 轮原文 def recent_context(messages, keep2): return messages[-keep:] # 方案二抽取结构化意图状态 def extract_state(messages): state { device: , purpose: , budget: , software: , confirmed: [], } for text in messages: if 笔记本 in text: state[device] 笔记本 if 台式机 in text: state[device] 台式机 if 4K in text or 调色 in text: state[purpose] 视频剪辑/调色 if 8000 in text: state[budget] 8000以内 if 达芬奇 in text: state[software] 达芬奇 return state print(方案一最后两条原文) for item in recent_context(turns, 2): print( -, item) print(\n方案二结构化状态) state extract_state(turns) for key, value in state.items(): print(f - {key}: {value if value else 未确认})输出结果是方案一最后两条原文 - 算了还是看看台式机 - 你觉得哪种处理器更适合我 方案二结构化状态 - device: 台式机 - purpose: 视频剪辑/调色 - budget: 8000以内 - software: 达芬奇 - confirmed: []从这个例子可以清晰看到问题如果只保留最近两条原始消息系统完全丢失了“剪辑 4K 视频”和“预算 8000 以内”这两个关键约束。模型看到最后两条消息只会知道用户在问台式机处理器无法知道用户需要高性价比、适合 4K 剪辑的台式机。结构化方案也存在问题它把所有信息都当成“追加”不知道“笔记本”被“台式机”覆盖了。说明只抽取不更新同样不够还需要一套明确的状态变更规则。3.3 实验结果观察这个最小实验揭示了两个工程结论截断历史可以控制 prompt 长度但绝不能代替状态管理。截断只会让模型看到更少的证据它原本就隐式推断不足的问题会被进一步放大。单纯抽取字段也不等于理解意图演变。必须区分 ADD、REPLACE、SWITCH、ROLLBACK 四种操作否则抽取出来的状态可能是自相矛盾的。用真实 LLM 做同样测试时现象会更明显。保持同样对话第一问让模型用“最近两条消息”作答第二问让模型用“结构化状态”作答。前者很可能推荐一个高价台式机配置后者则更有可能给出符合 4K 剪辑和 8000 预算的方案。这就是“迷失”在业务结果上的体现。4. 缓解迷失的四种工程化策略4.1 显式对话状态跟踪第一步是改变思路不再把“消息历史”当作系统记忆而是单独维护一份经过结构化处理的对话状态。对话状态至少需要包含topic当前主话题。task用户当前的核心任务。constraints已经确认的约束条件。status当前状态是进行中、待澄清还是已切换。version意图版本的编号用于支持回退。每次用户输入进来先通过一个分类模块判断这次输入属于 ADD、REPLACE、SWITCH 还是 ROLLBACK再决定如何修改状态。只有状态确认后才根据状态构造发给模型的 prompt。模型生成时不再直接面对一大段历史流水账而是面对一份已经整理好的需求清单。4.2 关键信息锚定与上下文压缩即使不用完整状态管理也可以采用一种轻量级优化把关键约束从历史中提取出来放到 prompt 的固定区域。假设系统提示原本是你是一个购机助手请根据用户消息给出建议。改进后可以变成system_prompt f 你是购机助手。用户当前需求如下 - 主话题{state[device]} - 核心任务{state[purpose]} - 预算约束{state[budget] or 未指定} - 软件要求{state[software] or 未指定} 如果用户提供的条件与上述状态冲突以用户最新明确要求为准。 如果用户只是补充信息不要替换原有约束。 这样做有三个好处关键约束在 prompt 开头重复出现注意力更容易覆盖。压缩掉无关历史降低早期信息被稀释的风险。通过显式文本告诉模型当前状态与用户最新输入的关系减少自我漂移。上下文压缩可以结合摘要实现。每几轮对话就用一个独立模型把旧消息压缩成结构化状态或简短纪要而不是直接截断。重点是从“保留最后几句”变成“保留最重要的语义”。4.3 意图变化检测与澄清确认意图变化检测是这类系统的核心模块。它不需要非常复杂关键是定义清楚“什么算变化”。推荐的做法是维护一个轻量分类器输入是上一轮状态加上当前用户消息输出是四类操作之一ADD新增约束或补充细节已有状态不变。REPLACE某个字段被新值覆盖。SWITCH主话题或目标任务发生切换。ROLLBACK用户要求回到之前某个版本。对于 SWITCH 和 ROLLBACK系统不应该直接执行。更好的方式是先向用户确认“你是想彻底切换话题还是在当前话题下补充条件”这一步能明显减少误杀。例如用户说“还是看看台式机”这可能是 SWITCH也可能是补充信息。如果系统自动判断为 SWITCH原有预算约束仍然应该保留但设备类型字段要覆盖。如果用户说“算了刚才说的都不算”这才是完整的 ROLLBACK。4.4 用结构化协议约束意图更新为了让意图状态可维护、可回滚可以把状态变更建模成事件流而不是直接修改一个可变对象。每个变更事件记录变更类型。变更字段。变更前值。变更后值。触发该变更的用户消息。时间戳。这样即使状态被改错了也能从事件流中恢复。这在用户反复调整需求时尤其有用。用户先说要 A然后说改成 B最后说“刚才 B 不合适还是用 A 吧”。如果没有事件流系统只能重新问一遍原始需求有了事件流就可以直接回滚到 A 版本。5. 实现一个意图演变感知的会话模块5.1 需求与数据设计为了演示真实的工程化方案下面实现一个最小可运行的意图状态管理器。它不依赖具体 LLM只负责维护意图状态供上层调用。核心数据结构from dataclasses import dataclass, field from typing import Optional dataclass class IntentState: topic: str task: str constraints: dict field(default_factorydict) version: int 0 last_action: str dataclass class IntentDelta: action: str # ADD / REPLACE / SWITCH / ROLLBACK field_name: Optional[str] None value: Optional[object] None snapshot_id: Optional[int] None dataclass class StateSnapshot: version: int state_copy: IntentState source_text: str每个IntentState代表一个版本的意图状态。版本号递增每次变更都会生成快照以便回退。5.2 核心实现class IntentStateManager: def __init__(self): self.state IntentState() self.snapshots [] self.operations [] def _save_snapshot(self, source_text: str): snapshot StateSnapshot( versionself.state.version, state_copyIntentState( topicself.state.topic, taskself.state.task, constraintsself.state.constraints.copy(), versionself.state.version, last_actionself.state.last_action, ), source_textsource_text, ) self.snapshots.append(snapshot) self.operations.append(source_text) def _next_version(self, action: str): self.state.version 1 self.state.last_action action def apply_delta(self, delta: IntentDelta, source_text: str): self._save_snapshot(source_text) if delta.action ADD: self._apply_add(delta) elif delta.action REPLACE: self._apply_replace(delta) elif delta.action SWITCH: self._apply_switch(delta) elif delta.action ROLLBACK: self._apply_rollback(delta) else: raise ValueError(funknown action: {delta.action}) self._next_version(delta.action) return self.state def _apply_add(self, delta: IntentDelta): if delta.field_name constraints: for key, value in delta.value.items(): self.state.constraints[key] value else: setattr(self.state, delta.field_name, delta.value) def _apply_replace(self, delta: IntentDelta): if delta.field_name constraints: self.state.constraints[delta.value[0]] delta.value[1] else: setattr(self.state, delta.field_name, delta.value) def _apply_switch(self, delta: IntentDelta): # 切换话题时保留跨话题有效的全局约束重置 topic/task self.state.topic delta.value.get(topic, self.state.topic) self.state.task delta.value.get(task, ) # 预算等全局约束不清理 def _apply_rollback(self, delta: IntentDelta): target_version delta.snapshot_id or 0 if target_version len(self.snapshots): return target self.snapshots[target_version].state_copy self.state IntentState( topictarget.topic, tasktarget.task, constraintstarget.constraints.copy(), versionself.state.version, last_actionROLLBACK, )这段代码的核心思想是所有状态变更都通过IntentDelta描述所有变更前状态都保存为快照。SWITCH只重置话题和任务不清理预算这类跨话题约束。ROLLBACK可以直接恢复到任意历史版本。5.3 运行验证用之前那段对话剧本验证manager IntentStateManager() manager.apply_delta(IntentDelta(ADD, value{device: 笔记本}), 我想买一台笔记本) manager.apply_delta(IntentDelta(ADD, value{purpose: 剪辑4K视频}), 剪辑4K视频用) manager.apply_delta(IntentDelta(ADD, constraints, {budget: 8000以内}), 预算8000以内) # 用户切换话题 manager.apply_delta( IntentDelta(SWITCH, value{topic: 台式机, task: 选购设备}), 算了还是看看台式机, ) # 用户回退到最初版本 manager.apply_delta( IntentDelta(ROLLBACK, snapshot_id0), 还是按最开始那个方案来, ) print(当前状态, manager.state)运行后可以观察到第一次 SWITCH 后topic变成“台式机”但constraints[budget]仍然是“8000以内”。ROLLBACK 到版本 0 后topic恢复为“笔记本”约束也恢复为当时的状态。这个模块解决了最核心的“意图演变可管理”问题。真实项目中IntentDelta的生成可以交给 LLM让模型输出 JSON 形式的状态变更指令再由IntentStateManager执行而不是让模型直接修改消息历史。这样既利用了 LLM 的语义理解能力又保证了状态变更的确定性。6. 配置、调参与生产落地6.1 关键参数与调参建议下表列出意图状态管理模块落地时最常调整的参数及其影响参数含义常见值调小影响调大影响意图变化阈值判断 SWITCH 的置信度阈值0.6 ~ 0.8容易误判切换频繁重置状态容易漏掉真实切换沿用旧状态快照保存条数保留多少个历史版本5 ~ 20回退范围变小内存和存储成本上升澄清触发次数同一处歧义最多追问几次1 ~ 2用户可能不耐烦可能忽略真实意图变化状态摘要触发轮数多少轮后压缩旧消息5 ~ 10过早压缩丢失细节太晚压缩导致上下文超限关键约束最大数最多维护多少条约束8 ~ 12重要约束可能被丢弃模型注意力被稀释“变化检测阈值”最值得关注。如果阈值太低用户说“我想再看看另一款”就会被识别成 SWITCH系统立刻重置状态如果阈值太高就算用户明确说“换个方向”系统仍然沿用旧状态。生产环境中建议先取 0.7再根据误判率调。6.2 学习环境与生产环境的差异学习环境里一个messages数组加一个 prompt 就能跑通对话。但进入生产环境至少要补齐以下几块状态存储把IntentState持久化到 Redis 或数据库中而不是只存在内存里。否则服务重启或负载均衡切换后用户状态直接丢失。操作审计每条IntentDelta都要记录用户 ID、会话 ID、来源消息、操作时间。方便排查“用户为什么被推荐了一个错误结果”。权限与隔离不同用户、不同业务域的意图状态要隔离避免互相污染。监控告警监控状态变更频率。如果单个会话在短时间内出现大量 SWITCH 或 ROLLBACK说明用户可能困惑或者检测模块在抖动。回滚方案新版本状态管理逻辑上线后要能快速切回旧版本。状态结构变更时需要兼容旧数据。生产环境的另一个关键点是 API 延迟。如果每轮用户输入都要先做意图分类、再压缩上下文、再构造 prompt最后调用 LLM整体延迟会明显上升。建议把不必要的串行步骤改成异步或并行比如上下文压缩可以放到后台不阻塞主链路。6.3 三个最容易踩的坑坑一把补充信息当成切换用户说“屏幕也要好一点”这通常是对笔记本需求的补充。但变化检测模块如果只看到“屏幕”和前面的“笔记本”不一致就可能判断为 SWITCH导致系统重新问“您是想买笔记本还是显示器”。原因是没有把更新语义区分开。补充信息属于 ADD通常不会改变主话题。解决方式是在分类 prompt 里明确说明只有出现“算了”“换个”“不看了”等切换信号或新输入的核心名词与当前 topic 完全不同且意图明确时才允许判定为 SWITCH。坑二状态只维护不清理越积越多有些实现会把所有约束不断追加导致状态里的约束相互矛盾。用户说“预算 8000”后又“预算 10000”。如果用 ADD 方式追加状态里同时存在两条预算模型不知道该用哪条。这就是典型的“维护了状态但没维护更新语义”。正确做法是对单值约束使用 REPLACE对多值约束才使用 ADD。预算、人数、时间这类字段是单值的新值应该覆盖旧值标签、偏好、待办清单这类字段是多值的可以追加。坑三快照只存了对象引用没有深拷贝内存态演示代码里如果没有深拷贝快照后续修改状态会同时修改所有历史快照导致 ROLLBACK 全部失效。上面示例中通过IntentState(...)显式创建新对象就是为了避免这个问题。生产环境使用对象序列化时要尤其注意不要把同一个引用塞进快照。注意回滚功能是否可靠直接决定用户说“还是按原来的来”时系统表现如何。上线前必须用专门测试用例验证回滚后状态完全恢复而不只是主话题恢复。7. 效果怎么评估怎么判断系统不再迷失7.1 意图演变评测集怎么建判断“迷失”是否被缓解不能只看最终回答是否让用户满意因为满意度受太多因素影响。更可靠的方式是建立一套面向意图演变的评测集。每个测试用例包含四部分多轮对话剧本。剧本中每一步的真实意图状态。期望的状态操作类型。关键约束最终是否保留。例如{ conversation: [ 我想买一台剪辑4K视频的笔记本, 预算8000以内, 算了还是看看台式机, 你推荐一个更适合我的处理器 ], expected_state: { topic: 台式机, purpose: 视频剪辑/调色, budget: 8000以内 }, expected_operations: [ADD, ADD, SWITCH, ADD], key_constraints_kept: [purpose, budget] }评测时把对话逐条送入系统每一步后对比当前实际状态与期望状态。统计三个指标状态一致率每一步状态完全正确的比例。操作准确率ADD、SWITCH、ROLLBACK 四种操作分类正确的比例。关键约束保留率最终状态中仍保留核心约束的比例。这三个指标比“回答正确率”更可控、更稳定。即使模型生成结果换了种说法只要状态正确系统整体就是健康的。7.2 发布前检查清单把意图演变感知模块上线前建议过一遍以下清单状态管理模块是否有完整的单元测试覆盖 ADD、REPLACE、SWITCH、ROLLBACK 四种操作。是否有专门测试“用户说了算了后预算仍然保留”的用例。快照是否深拷贝回滚后原状态是否完全恢复。变化检测阈值是否经过一批真实历史对话调优。长对话超过上下文窗口时压缩策略是否优先保留核心约束。状态持久化是否具备服务重启后能否恢复。是否记录操作审计日志能否回答“用户为什么被推荐这个结果”。回滚上线方案是否存在状态结构变更是否兼容旧数据。是否监控单会话内高频 SWITCH 和 ROLLBACK 异常。7.3 扩展方向意图演变管理不是一个一次性功能而是 LLM 应用对话层的基础设施。下一步可以沿着这些方向扩展把IntentStateManager与多 Agent 编排结合每个 Agent 都读取同一份意图状态避免不同 Agent 对用户需求理解不一致。加入基于用户反馈的自动修正。当用户对推荐结果表示不满时自动分析当前状态中哪个约束可能错了触发澄清或回退。把支持 ROLLBACK 的意图事件流与用户画像打通。长期维护用户在不同业务场景中的偏好演变曲线让推荐更个性化。针对不同语言和业务领域做状态字段的抽象。比如电商、医疗、教育、法律咨询的约束字段完全不同但 ADD/REPLACE/SWITCH/ROLLBACK 这套操作语义是通用的。回到最开始的问题LLM 为什么会在演变中的用户意图里迷失根本原因是模型只能从文本中隐式猜测状态而工程上也没给它维护状态的机会。只要把“当前用户要什么”从消息历史中显式抽离出来用结构化状态加操作事件流管理每一步变化再通过评测集验证关键约束是否保留这个问题就能被系统性地缓解。对开发者来说最重要的转变不是换更强的模型而是先承认意图管理是一种工程能力不能完全交给模型免费获得。