我最近在调一个 AI Agent 项目时碰到一个诡异现象用户明确说过“我习惯早上九点开会”结果第二天 Agent 照旧在下班时间帮用户安排会议用户第三次重申“预算不要超过五千”Agent 依然在第四轮把报价推荐到八千。日志里明明记录了用户说过的话系统提示词里也写着“请记住用户偏好”可它就是记不住。这不是模型能力问题是 Agent 的记忆架构问题。很多人做 Agent 时只关注工具调用和规划能力把记忆当成“把历史对话拼进上下文”这种小事结果做到后面发现对话一长就乱、跨会话全忘、用户画像形同虚设。这篇是“走进 AI Agent”系列的第三篇我把自己在真实项目里给 Agent 加记忆的完整思路、踩坑过程和可落地的代码骨架一次性说清楚。无论你是在用 LangGraph、Spring AI 这类框架还是从零搭建自己的 Agent只要你想让 AI 记住用户这篇文章都值得看完。1. 先复盘一个真实场景为什么 Agent 总在“记住”之后继续忘1.1 在调试日志里看到的“三连忘”那个项目的功能其实不算复杂一个帮用户做日程管理、差旅规划、采购审批的办公 Agent。最开始我们把所有历史对话一股脑丢进上下文指望大模型“自己记住”结果一上线就出问题。日志里反复出现三种情况用户第一轮说“我预算五千以内”第六轮 Agent 推荐了八千的商务舱套餐用户说“我不吃辣”三小时后 Agent 又推荐了川菜馆用户说“以后周五下午不要安排会议”第二周周五 Agent 照样给用户拉了个三点半的评审会。最典型的一次用户已经被问了三遍“您常去哪个城市出差”用户在第一遍就答过了。每问一次用户就得重复一次。这种体验用一句话概括Agent 像个金鱼只有七秒记忆。1.2 记忆缺失的连锁反应重复提问、重复确认、体验崩坏表面上这只是“信息没记住”实际上它会引发一连串连锁反应。第一交互轮次暴增。用户被反复追问已经提供过的信息原本 5 轮能完成的日程安排被拖到 12 轮以上。每多一轮都意味着 Token 消耗增加、响应延迟变长、出错概率变大。第二用户信任崩塌。信任这东西很奇怪用户能容忍 Agent 某一步算错了但容忍不了“我已经告诉过你的事情你一点反应都没有”。后者会直接让人觉得“这东西根本没有脑子”。第三业务动作失效。这不是聊天游戏Agent 是要干活的。安排会议、提交审批、预订行程这些动作都依赖对用户历史偏好的准确理解。没有记忆Agent 每次开工都是“失忆状态”所有流程都要从头问一遍。1.3 工程上给“记忆”一个可落地的定义在动手之前我们先说清楚“记忆”在 Agent 工程里到底是什么。我的定义是这样的记忆是 Agent 在当前会话及历史会话中获取的信息经过筛选、加工和持久化之后能在后续决策时被检索并利用的那部分结构化或半结构化数据。拆开看有三个关键点可筛选不是所有东西都值得记记忆的前提是“去噪”可持久化内存里的东西断电就没了真正有用的记忆要落到存储里可检索存进去不代表能用上必须在需要的时候能快速找回来。很多团队做记忆系统失败就是只做了“收集”和“存储”漏了“筛选”和“检索”。信息存了一堆召回时什么都捞不到或者捞回来一堆没用的效果自然差。2. 给 Agent 记忆做分层别让所有信息都挤在一个篮子里市面上各种记忆方案五花八门但其实只要按“存活时间”和“抽象程度”两个维度去拆所有记忆都能分成四类。这个分类方式参考了认知科学里对记忆的研究直接搬过来用就行。2.1 短期记忆跟着上下文窗口走的“工作台”短期记忆就是当前对话过程中的上下文。它对应大模型的 context window存活时间从几秒到几小时不等取决于对话多长、窗口多大。短期记忆的价值在于“即时性”。用户说“刚才那份报表的分析结论是什么”Agent 能回答就是因为对话历史还在上下文里。它的问题是“容量有限”现阶段主流模型窗口再大也经不住长对话无限堆叠。工程上的做法通常是滑动窗口截断只保留最近 N 轮对话再早的直接丢弃或者压缩成摘要再放回窗口。这个 N 怎么定是个非常讲究的经验问题后面踩坑部分我会详细说。2.2 长期记忆跨会话保留的“用户档案”长期记忆是让 Agent“记住你”的核心。它的特点是跨会话、可持久化、结构化程度高。典型的内容包括用户的基本信息称呼、城市、职位、所在行业用户的偏好沟通风格、预算范围、时间习惯、内容喜好用户的决策历史过往审批过的方案、拒绝过的类型用户的身份关系和公司、团队、项目之间的关联。长期记忆不追求“全”追求“准”。存一百条过期噪音不如存十条准确画像。因为长期记忆每一条都会在未来的决策里反复被调用一旦某条是错的错误会被无限放大。2.3 情景记忆和语义记忆记忆系统里容易混淆的两类数据这两类来自认知心理学但在 Agent 工程里也有明确对应。情景记忆Episodic Memory记录的是“具体发生过的事件”上周二用户拒绝了蓝色款式的设计方案、上个月用户把机票改签到了下午三点。这类记忆的特点是带时间、带上下文、不可替代。语义记忆Semantic Memory记录的是“抽象出来的知识”用户偏好极简风格、用户出差一般选靠窗座位。语义记忆通常是从一段或多段情景记忆里归纳提炼出来的。很多人做记忆系统只做语义记忆直接问 LLM“从这个对话里摘要出用户的偏好”结果丢失了大量关键细节。更合理的做法是先保存情景记忆的原始记录再定期用 LLM 做归纳把提炼出的语义记忆单独存一层。两层配合使用一个管“细节回溯”一个管“快速决策”。2.4 各层记忆的核心差异一览记忆类型存活时间存储位置典型内容更新频率检索方式短期记忆当前会话上下文窗口最近对话轮次每轮更新顺序读取情景记忆数周至数月数据库/日志具体事件记录事件发生后写入时间标签语义记忆长期向量库/知识图谱用户偏好画像定期归纳相似度检索工作记忆当前任务内存变量当前任务状态和中间结果任务进行中直接读取工作记忆容易被忽略但做多工具协同的 Agent 时非常关键。它负责保存当前任务的中间结果比如已经搜到的材料、正在填的表单、下一步要执行的动作。没有工作记忆Agent 一旦调用了五六个工具很快就忘了自己一开始想干什么。3. 搭一套最小可用记忆系统写入、存储、召回三段式理论说完直接进入实操。一个能用且不用过度设计的记忆系统核心就三个环节写入、存储、召回。我把每个环节最容易犯的错和最优做法一起讲。3.1 写入阶段规则触发与 LLM 抽取的取舍写入记忆最忌讳“什么都记”。如果每轮对话都调用一次 LLM 做抽取成本爆炸不说还会把大量无关信息写进记忆库污染后续召回。我的实践方案是“规则触发 LLM 抽取”两层配合规则层先用轻量规则判断哪些对话值得进入抽取流程。比如用户在句子中表达了偏好“我喜欢”“我习惯”“以后不要”、提供了个人信息“我在上海工作”“我的预算是”、或者对 Agent 的动作给出了否定反馈“不对”“不要这个”。这些模式可以用正则或关键词快速命中。LLM 抽取层命中的对话才交给 LLM让它按照预定义的字段结构抽取记忆点。比如抽取用户的预算范围、风格偏好、时间习惯每条记忆附带一个置信度和来源时间。这样设计的好处是省钱、省时、噪音少。大量无关对话在规则层就被拦住了LLM 只处理真正值得记的内容。3.2 存储阶段从 JSON 文件到向量数据库的选型思路存储选型没有银弹完全取决于你的数据规模。我从轻到重排个序JSON 文件适合原型验证、个人项目、单用户场景。把用户记忆读进内存用关键词匹配。优点是零依赖缺点是检索能力基本没有。SQLite / 关系型数据库适合结构化记忆较多的场景。用户画像、事件记录、偏好表都可以建表存。配合全文索引能解决一部分检索需求。优点是查询灵活缺点是语义检索做不了。向量数据库Chroma、Milvus、Weaviate、pgvector 等适合需要“按语义召回”的场景。用户说“我出差喜欢安静”你要在记忆库里找到“偏好靠窗、远离走廊”这条记录关键词匹配做不到向量相似度可以。知识图谱适合实体关系复杂的场景比如记忆里有多个人、多个项目、多个组织之间的关联。优点是可以做逻辑推理缺点是构建和维护成本高普通项目慎用。我个人的建议MVP 阶段直接用 SQLite 存结构化记忆 一个轻量向量索引就够。不要一上来就上重型向量数据库后面你维护的时候会后悔的。3.3 召回阶段检索时机、Top-K 与上下文注入位置召回是整个记忆系统里最影响体验的环节。存了好记忆召回不出来等于没有。先解决“什么时候召回”。我的做法是在每次 Agent 执行任务前先做一个意图判断。如果当前任务涉及用户偏好、历史事实、已有决策比如推荐、审批、规划就触发记忆召回如果任务是纯工具型操作比如查天气、算个公式就不召回节省 Token。再解决“召回多少条”。Top-K 到底取多少取决于记忆库的质量。记忆库质量高、去噪做得好K 可以取 3 到 5记忆库噪音多K 越大越危险。我常用的策略是动态 K根据当前用户问题的复杂度决定问题里涉及多个条件预算、时间、地点就把 K 调大。最后解决“注入到哪里”。召回出来的记忆应该拼进 System Prompt 的一个独立区块用明确的分隔符包起来比如memory_section 用户身份上海某创业公司市场负责人 预算习惯单次采购不超过5000元 沟通偏好喜欢直接给结论不用铺垫 近期事件上周否决了8000元商务舱方案 /memory_section这样做有两个好处一是模型能明确区分“记忆信息”和“当前对话”不会被混淆二是方便调试输出日志时能清楚看到每次请求拼了哪些记忆进去。3.4 一个可以直接跑的 MemoryManager 骨架下面给出一段简化但可运行的 Python 骨架代码涵盖写入、存储、召回三段逻辑。它不绑定具体框架你可以直接嵌到自己的 Agent 里。import json import hashlib import time from dataclasses import dataclass, asdict from typing import List, Optional dataclass class MemoryItem: content: str # 记忆内容 memory_type: str # personal / preference / event / fact user_id: str # 用户标识 created_at: float # 写入时间 source_turn: str # 来源对话轮次便于溯源 importance: float 0.5 # 重要度0-1用于后续合并/淘汰 retrievable: bool True # 是否可以被召回 class MemoryManager: 最小可用记忆系统 - 写入save() 写入一条记忆 - 召回retrieve() 按关键词/语义返回相关记忆 - 更新update() 合并或淘汰旧记忆 - 遗忘forget_before() 清理过期记忆 def __init__(self, storage_path: str ./memory_store.json): self.storage_path storage_path self._items: List[MemoryItem] self._load() def _load(self) - List[MemoryItem]: try: with open(self.storage_path, r, encodingutf-8) as f: raw json.load(f) return [MemoryItem(**item) for item in raw] except FileNotFoundError: return [] def _flush(self): with open(self.storage_path, w, encodingutf-8) as f: json.dump([asdict(item) for item in self._items], f, ensure_asciiFalse, indent2) def save(self, content: str, memory_type: str, user_id: str, source_turn: str, importance: float 0.5): item MemoryItem( contentcontent, memory_typememory_type, user_iduser_id, source_turnsource_turn, created_attime.time(), importanceimportance ) self._items.append(item) self._flush() def retrieve(self, query: str, user_id: str, top_k: int 5) - List[MemoryItem]: 简化版检索 1. 过滤出该用户可召回的记录 2. 按关键词简单打分 3. 按重要度加权 生产环境可以把这里替换成向量库的语义检索 query_words set(query.lower().split( )) scored [] for item in self._items: if not item.retrievable or item.user_id ! user_id: continue content_words set(item.content.lower().split( )) hit len(query_words content_words) / max(len(query_words), 1) score hit * 0.7 item.importance * 0.3 scored.append((score, item)) scored.sort(keylambda x: x[0], reverseTrue) return [item for _, item in scored[:top_k]] def update(self, item_id: str, new_content: str None, new_importance: float None): 按 id 更新一条记忆通常是偏好变更时使用 for item in self._items: # 生产环境这里应该用唯一 id 匹配示例中省略 if item.content item_id: if new_content: item.content new_content if new_importance is not None: item.importance new_importance break self._flush() def forget_before(self, timestamp: float): 遗忘早于某个时间点的低频记忆 self._items [ item for item in self._items if item.created_at timestamp or item.importance 0.7 ] self._flush()这段代码故意做得很轻把向量检索替换成了简单的关键词打分目的就是让你先跑通逻辑。生产环境只要把 retrieve 方法内部换成向量数据库的相似度查询就行接口不用动。4. 让记忆“准”而不是“多”检索阈值、冲突合并与更新策略写完第一版记忆系统本地测试看着不错一旦接上真实用户问题就全冒出来了。核心矛盾是记忆不是越多越好而是越准越好。这一节讲我把检索从“能用”调到“好用”的过程。4.1 Top-K 召回为什么经常把关键记忆漏掉用向量库做 Top-K 召回最典型的翻车场景是该记的没出来不该记的出来一堆。原因在于用户当前问题里的关键词和真正有用的历史记忆之间往往不是字面匹配而是语义关联。比如用户问“出差住宿怎么选”真正有用的记忆是“用户上次出差选了行政楼层理由是隔音好”——这中间隔着“出差”和“行政楼层”两层抽象。如果你只对对话末尾的最新一条做检索肯定召回不到几个月前的那条关键记录。我的解决办法是多路召回第一路对用户当前 query 做向量检索取 top 10第二路对用户当前会话的主题标签做检索取主题相关的历史记忆第三路对用户画像中的高频偏好直接轮询按重要度排序取前几条最终合并去重按综合得分重新排序。三种召回渠道画像不同综合得分 检索相似度 × 0.5 重要度 × 0.3 新鲜度 × 0.2。这个权重我调了很久核心逻辑是既要让相关性强的内容排前面又要给重要但相似度稍低的记忆一个出场机会。4.2 相似度阈值怎么调才不容易误伤召回出来的内容不是每条都有用。上一轮还聊着聚餐下一轮问工作安排如果相似度阈值太低Agent 就把“聚餐偏好”当成高优先级记忆塞进上下文反而干扰判断。我踩过的坑是按“推荐值”抄阈值。向量库的相似度分数没有一个通用标准不同 embedding 模型的分数分布完全不同。有的模型打分普遍在 0.7 到 0.9 之间你以为 0.75 是很接近了其实已经差得很远换一个模型0.5 以下才真的没关系。我的做法是给自己做一个校准实验选 50 个真实用户 query每个 query 手动标注“应该召回”和“不该召回”的记忆集合在测试集上跑不同阈值看 precision 和 recall 的交点选一个“宁缺毋滥”的阈值——记忆召回宁可少一点不要召回乱七八糟的东西进上下文。校准之外还有一个实用技巧不要只看相似度分数要设一个绝对的最低分底线。不管什么场景低于 0.4 的召回结果直接丢。这个底线能挡掉大量无意义的语义噪声。4.3 用户偏好变了记忆冲突的更新与淘汰机制记忆系统做得再准也会碰到一个绕不开的问题——用户变了。用户上个月喜欢详细汇报这个月嫌你啰嗦上周说预算五千这周说预算可以放宽。如果不处理冲突Agent 会陷入“人格分裂”一会儿按旧偏好办事一会儿按新偏好办事用户感觉像个杠精。我在系统里加了三道处理机制时间戳权重相同主题的记忆优先采信时间更近的那条。具体实现是给每条记忆加一个衰减系数召回的排序得分乘以 exp(-days / half_life)。半衰期我一般设 30 天也就是一条记忆过了一个月相关度折一半。显式否定优先当用户明确说“不要/不用/取消/以后别”这条指令优先级最高。我不只把它当作一条新记忆还会把它标记为“废止”相关联的旧记忆。比如用户说“我以后不吃辣了”系统要把之前“用户喜欢吃辣”这条记忆的 retrievable 置为 False而不是让它继续和新记忆打架。周期性固化每周五跑一次任务把本周的情景记忆拿去让 LLM 归纳更新到语义记忆层。归纳时如果发现新旧偏好矛盾以最近三条的用户反馈为准生成一条新的偏好记忆并把旧记忆降权。4.4 用 LLM 做记忆合并/去噪时的注意事项很多人喜欢让 LLM 做记忆抽取和合并但要小心几个问题。第一LLM 容易被上下文“带偏”。如果 prompt 里给的示例都是关于出差偏好的它就会把用户今天聊的“喜欢安静”强行理解成出差偏好而实际上用户说的是办公室环境。解决办法是抽取任务的任务描述要独立清晰不要给太多无关示例。第二LLM 会把推测当成事实。用户说“我最近在看房子”LLM 可能在抽取时记成“用户打算买房”。这两句话差别巨大但 LLM 很容易越过事实做推断。我的处理方式是在抽取 prompt 里写死原则只能抽取用户明确表达的事实禁止任何推断识别到不确定内容时标 low confidence 而不是直接记录。第三LLM 抽取结果要过“校验层”。我用一个很小的人工规则库做兜底比如抽取出的内容必须包含至少一个动词短语、必须能还原出“谁、什么、怎么样”三个要素、不能只有形容词。过不了校验的直接丢弃。5. 实测踩坑记录从“什么都记”到“记不住重点”的完整排查链路这部分是重头戏。我把上线后用户反馈最多的几个问题从现象到根因到修复完完整整走一遍排查链路。如果你已经做了记忆系统但效果不好建议对照检查。5.1 坑一记忆全量塞进上下文输入 Token 直接翻倍现象接上记忆系统之后Token 消耗暴涨响应延迟明显变高更离谱的是效果反而变差了。排查过程先看日志发现每次请求的 system prompt 里都拼了近五千字的历史记忆摘要。原来第一版实现图省事把用户所有历史记忆全部序列化进 prompt。上下文从原本的一千字 token 涨到六千多模型要处理的信息量暴增注意力被大量低价值记忆稀释。根因我没有给记忆做“范围限制”理想情况是每次只注入当前任务最相关的 3 到 5 条记忆我直接一股脑全塞。修复把注入逻辑改成“先召回再注入”。每次请求只带召回的 top 5 记忆每条记忆不超 100 字。Token 消耗立刻回落效果也恢复了。5.2 坑二记忆污染——召回出来的内容本身就有毒现象Agent 有时候会突然无中生有。用户没说过的话它当成用户偏好说出来。比如用户只是问了一句“你们有儿童套餐吗”第二天 Agent 就断定“用户带娃”推荐了一堆亲子产品。排查过程把一条被召回的“用户带娃”记忆拿到人工审查发现源头是某次对话里用户提到帮朋友问儿童套餐。LLM 抽取记忆时丢了“帮朋友问”这个上下文直接记成了“用户关注儿童餐”。根因记忆抽取阶段没有约束“主体归属”。用户对话里提到的信息不一定是关于用户本人的。必须区分“用户的事实”和“用户提到的第三方事实”。修复在抽取 prompt 里加入强制要求——只有包含“我 / 我们 / 本人”等第一人称指代且明确表达主体是用户本人的内容才允许写入用户画像。涉及第三人称的内容最多写入 event 类型记忆并且检索权重降到最低。修复后这类幻觉消失了大半。5.3 坑三旧记忆和新偏好打架Agent 像个杠精现象用户明确说“这次不用考虑预算选最好的”Agent 却在好几个方案里反复标注“考虑到您以往预算五千以内”。用户直接炸毛。排查过程查看召回的候选列表发现旧记忆“预算不超过五千”评分非常高因为历史里提过很多次重要度已经被反复写入抬得很高而“本次不考虑预算”这条新记忆只有一条重要度低排序排在后面。根因我完全没有做“即时压制”。用户在当前对话给出的信息优先级应该天然高于历史记忆。旧记忆靠重复把重要度刷上去了但它在当下已经失效。修复加了一条硬规则——当前对话中用户的最新指令永远排在所有历史记忆之前。具体做法是先把当前对话涉及的主题标记出来召回历史记忆时凡是主题相同且时间早于当前对话轮次的一律降权 0.5。新指令说完旧记忆立刻让位。5.4 坑四把记忆直接拼进 System Prompt改起来想哭现象每次要调整记忆注入格式都要重新发版更糟的是有些模型的 System Prompt 一长指令遵循能力就开始下降。排查过程统计线上失败案例发现凡是带有大量历史记忆的请求模型漏掉关键指令的概率明显上升。System prompt 同时承载了“角色设定、工具说明、安全约束、记忆数据”四类内容互相干扰严重。根因职责混杂。System prompt 应该只放“不会变的东西”可变的数据不该生硬拼接进去。修复把所有记忆数据挪到 user 消息的单独区块或者用工具方式独立传参。让 System Prompt 保持精简记忆作为独立的上下文段落传入。改动之后模型指令遵循能力明显回升。如果你框架支持也可以直接用消息数组里单独一个 system 分段放记忆注意观察不同模型对多段 system 的兼容性。5.5 踩完坑之后留下的四条铁律把上面几个坑复盘完我提炼出四条铁律现在每次新项目都直接套用先召回再注入记忆永远只带相关的一小部分不搞全量搬运主体识别兜底只有关于用户本人的明确事实才能进画像第三方信息单独隔离当前指令优先用户当下说的话永远比历史记忆权重高数据与指令分离记忆是数据不是指令不要污染 System Prompt。6. 记忆系统要不要做重取决于你的场景终局最后一篇的篇幅留给架构取舍。很多人问我“记忆系统到底要做到多复杂”我的回答是先看你产品离了记忆能不能转。6.1 按使用场景选记忆方案轻量聊胜于无重量未必划算不同产品对记忆的依赖程度完全不一样。我按轻重梯度列个表场景类型典型产品记忆复杂度推荐方案一次性问答在线客服、文档问答低只要上下文窗口就够高频个人助手个人助理、日程规划中用户画像 情境记忆SQLite 向量召回深度个性化产品教育陪练、健康管理、理财顾问高分层记忆 知识图谱 周期性归纳机制这里我给一个特别重要的建议不要为了技术炫技而做重记忆系统。如果你的用户一周只来一次对话轮次也少一个轻量 JSON 存储可能比向量数据库体验更好。重系统的维护成本远超你想象。6.2 隐私与数据主权记忆本身就是用户的数据这一点一定要单独拿出来说因为它太容易被忽略了。记忆系统本质上在做的事是把用户说过的话长期保存下来。这会让你的产品更懂用户但也意味着你掌控了用户的隐私数据。我的处理原则记忆必须支持查看和删除用户在设置里能看到“AI 记住了我的什么”并能一键清空深度个性化数据默认加密存储不在日志里明文打印业务不需要的敏感信息银行卡号、身份证号、密码需要在写入阶段就拦截绝不进记忆库记忆数据不会用于训练这一点需要在产品协议里写清楚。不要觉得这是小题大做。如果哪天用户发现你的 Agent 还记得他三个月前的体检指标而你没法解释清楚数据的用途信任崩塌的速度比功能上线快得多。6.3 让记忆可被看见可视化调试是长期维护的关键记忆系统是个黑盒看不见就会失控。我踩过一个教训有一次 Agent 推荐质量大跳水排查了半天发现是记忆库里有十几条互相矛盾的旧记录在轮流生效导致每次推荐逻辑都不一样。但因为记忆存在数据库里只能看文件根本没法快速定位。后来我加了个简单的“记忆可视化”面板把每个用户的记忆列表按类型、时间、重要度列出来还能直接手动修改和删减某条记忆。有了这个面板调试效率翻了好几倍。你不用做什么复杂前端一个简单的后台页面或者一条 debug 命令就够。关键是让“Agent 当前记住的东西”可见、可改、可溯源。6.4 如何评估一个记忆系统“做得好不好”记忆系统的效果不像大模型推理能力那样有清晰的 benchmark但我们可以用三个指标来衡量重复提问率用户问过同一个问题的次数占比理想情况应该随着记忆积累明显下降偏好一致率Agent 的输出和用户历史明确表达的偏好之间的匹配程度可以抽样人工打分记忆时效性过时记忆在召回结果中的占比这一条越低越好需要定期清理机制来保证。这三个指标不需要做得很重哪怕是每周人工抽 20 条日志来看一眼也比完全黑盒强得多。我自己常用的组合是“重复提问率 定期人工抽检”在小团队的资源约束下性价比最高。我个人在做记忆系统时最深的体会是记忆不是功能是架构。它横跨数据层、检索层、prompt 层和产品交互层任何一环掉链子最终表现都是“Agent 记不住你”。所以不要指望一个灵光一现的技巧能解决问题老老实实把分层、写入、召回、更新、清理这套链路走通你手里那个 Agent 才会真正从一个“每次都重新认识的陌生人”变成一个越用越懂你的搭档。