企业官网建设流程全解析

1. 项目概述：从“健忘”到“自主记忆”的进化之路

如果你最近在折腾大语言模型的应用，尤其是想让它记住你之前聊过什么、做过什么，那你肯定对“上下文窗口”这个词又爱又恨。爱的是，它给了模型一个“工作记忆区”；恨的是，这个记忆区太小、太贵，而且一刷新就全忘了。这就像让一个天才处理复杂项目，却只给他一张巴掌大的便签纸做笔记，项目稍微一长，前面的细节就全被擦掉了。我们常说的“Towards Autonomous Memory Agents”（迈向自主记忆智能体），瞄准的就是这个核心痛点。它不是一个具体的工具，而是一个架构方向和设计范式，目标是为LLM驱动的智能体赋予真正意义上的、可自主管理的长期记忆能力。

简单来说，它要解决的是智能体的“健忘症”问题。当前的智能体，无论是AutoGPT、BabyAGI还是各类AI助手，其记忆大多依赖有限的上下文窗口，或者简单地将历史对话记录成文本文档。前者有长度和成本限制，后者则缺乏结构、难以检索和有效利用。一个“自主记忆智能体”应该能做到：1）自动决定什么信息值得记住；2）将信息以结构化的方式存储到外部数据库（我们称之为“外部记忆体”）；3）在需要时，能快速、精准地从海量记忆中检索出最相关的片段；4）能对记忆进行动态更新、修正甚至遗忘。这听起来是不是有点像为我们自己构建一个“第二大脑”？没错，其核心思想就是借鉴人类的记忆系统，为AI打造一个外挂的、可扩展的“海马体”。

为什么现在这个话题这么热？因为随着多轮对话、复杂任务规划、个性化服务等场景的深入，记忆成了制约智能体能力上限的关键瓶颈。没有记忆，每次交互都是“初次见面”，个性化无从谈起，长期任务无法分解跟踪，效率大打折扣。而像“chimera”这类关于异构LLM服务的热词，也侧面反映了另一个趋势：未来的智能体系统可能是由多个各司其职的“小模型”或“专业模型”协同工作，它们共享一个中央记忆库，这对记忆系统的性能、延迟和一致性提出了更高要求。因此，深入理解并实践“自主记忆”的构建，是开发现实可用AI智能体的必经之路。

2. 自主记忆系统的核心架构与设计思路

构建一个自主记忆系统，远不止是接个数据库那么简单。它是一套精密的工程架构，需要从数据流、存储、检索、更新等多个维度进行综合设计。一个典型的自主记忆智能体架构，通常包含以下几个核心组件，它们协同工作，共同完成记忆的“感知-存储-回忆-更新”闭环。

2.1 记忆的感知与编码：从原始文本到向量嵌入

智能体每时每刻都在接收信息流：用户的指令、工具调用的结果、自身的推理过程、外部API的返回数据等等。第一步，也是至关重要的一步，就是决定“记什么”以及“怎么记”。

记忆的粒度与类型：并非所有信息都值得存入长期记忆。我们需要对信息进行分类和过滤。

• 对话历史：最基础的记忆。但全量存储效率低下，通常需要做摘要提取。例如，一段关于“帮我规划一个Python学习路径”的10轮对话，最终可能被总结为：“用户目标：从零开始学习Python用于数据分析。当前阶段：已了解基础语法，正在寻找NumPy/Pandas的学习资源。偏好：视频教程优先。”
• 实体与事实：在对话中提及的关键信息，如人名、地点、时间、项目名、参数配置等。这些是结构化记忆的基石。
• 用户偏好与画像：用户表现出的习惯、喜好、禁忌。例如，“用户不喜欢冗长的解释”、“用户对响应速度要求很高”、“用户是左撇子”（在物理交互场景下）。这类记忆是实现个性化的关键。
• 任务状态与上下文：对于执行长期任务的智能体，必须记住任务的总体目标、当前进度、已完成的步骤、遇到的错误及解决方案。这是实现任务连续性的保障。
• 自身行为与反馈：智能体采取的行动及其结果（成功/失败）。这可以用于后续的强化学习或经验积累，实现自我改进。

编码策略：决定了记忆的“存储格式”，直接影响后续的检索效果。

1. 向量嵌入（核心）：将文本片段通过嵌入模型（如OpenAI的text-embedding-3-small、BGE、M3E等）转换为高维向量。这个向量捕获了文本的语义信息，是进行语义相似度检索的基础。关键点：嵌入模型的选择至关重要，需要与你的任务领域匹配。通用模型可能无法很好地区分专业术语。
2. 元数据（Metadata）：为每段记忆附加结构化标签。例如：timestamp（时间戳）、source（来源，如“用户输入”、“工具输出”）、type（类型，如“用户偏好”、“任务步骤”）、importance_score（重要性分数，可初始化为一个默认值，后续动态调整）。元数据便于进行高效的属性过滤。
3. 原始文本：存储编码前的原始文本或摘要文本。当检索到相关向量后，需要将对应的原始文本返回给LLM，作为生成回复的上下文。

实操心得：在编码阶段，一个常见的误区是“过度切片”。把一段长文本切得太碎，会导致每段记忆信息量不足，失去上下文；切得太大，又可能包含无关信息，降低检索精度。我的经验是，根据语义的自然段落或句子进行切割，并确保每个切片能表达一个相对完整的意思。同时，为每个切片生成一个简短的“标题”或“摘要”作为元数据的一部分，能极大提升后续人工检视和调试的效率。

2.2 外部记忆体的选型与数据组织

这是记忆的“仓库”。选择什么样的数据库，如何设计数据表（或等价的集合/索引），直接决定了系统的性能上限。

数据库选型：

• 向量数据库（首选）：专为高维向量相似性搜索优化。如Pinecone、Weaviate、Qdrant、Milvus、ChromaDB等。它们内置了高效的近似最近邻（ANN）搜索算法（如HNSW、IVF-PQ），能在大规模数据中快速找到语义相似的记忆。
  • Pinecone/Weaviate：云服务，开箱即用，运维简单，但可能有成本。
  • Qdrant/Milvus：开源，可自托管，功能强大，定制灵活，但需要一定的运维能力。
  • ChromaDB：轻量级，易于集成，适合原型开发和中小规模场景。
• 关系型数据库 + 向量扩展：如PostgreSQL的pgvector插件。优势是可以将向量搜索和丰富的结构化查询（通过元数据）完美结合在一个事务中，保证数据一致性。适合对事务有要求，且记忆的元数据查询非常复杂的场景。
• 图数据库：如果记忆之间的关系（如“事件A导致事件B”、“人物X属于组织Y”）是核心，图数据库（如Neo4j）是强大选择。它能高效处理复杂的关联查询，但纯粹的语义相似度搜索可能不如专用向量库。

数据组织（“记忆库”设计）： 不建议将所有记忆混在一个大的“池子”里。合理的做法是根据记忆的归属进行分库或分区。

1. 会话记忆库（Session Memory）：存储一次对话会话内的短期、高频率记忆。检索速度快，但生命周期短（随会话结束而清空或归档）。
2. 用户记忆库（User Memory）：存储属于特定用户的长期记忆，如用户画像、历史偏好、重要事实等。这是实现个性化的核心数据库。
3. 全局记忆库（Global/Entity Memory）：存储所有用户共享的公共知识或事实，例如产品文档、公司规章制度、领域知识库等。
4. 任务记忆库（Task Memory）：为每个长期运行的任务单独创建一个记忆空间，存储该任务的所有相关上下文和状态。

这种分离带来了多重好处：安全性（用户数据隔离）、检索效率（缩小搜索范围）、管理便捷（可以针对不同库设置不同的保留策略和更新频率）。

2.3 上下文的动态组装：检索、排序与注入

当智能体需要回应或思考时，它如何从庞大的外部记忆中提取出最相关的片段，并组装成LLM可理解的上下文？这个过程称为“上下文组装”，是记忆系统智能化的体现。

检索-重排序（Retrieve-and-Rerank）管道：

1. 初步检索（Recall）：利用向量相似度搜索，从目标记忆库中召回Top-K个候选记忆片段（例如K=20）。这一步追求“全”，尽可能不漏掉相关项。
2. 重排序（Rerank）：对初步检索的结果进行更精细的排序。这里可以综合多种信号：
   • 语义相关性：使用更强大但更慢的交叉编码器模型（如BGE-Reranker）对查询和每个候选片段进行深度匹配打分。
   • 元数据权重：给重要性分数高、时间更近的记忆赋予更高权重。
   • 新鲜度衰减：引入时间衰减因子，让较旧的记忆排名自然下降，除非它们极其相关。
   • 多样性：避免返回过多内容重复或语义高度重叠的记忆，通过聚类或最大边际相关性（MMR）算法来保证结果的多样性。
3. 上下文压缩与格式化：检索到的记忆片段总和可能仍然超过LLM的上下文窗口。因此需要进行压缩：
   • 选择性注入：只选择重排序后得分最高的前N个片段（如N=5）。
   • 摘要压缩：如果单个片段太长，可以用一个小型LLM（如Llama 3 8B）对其进行摘要，再将摘要注入上下文。
   • 格式化：将最终选定的记忆片段，按照一定的模板（如“【用户偏好】：...”、“【历史对话摘要】：...”、“【相关事实】：...”）组织成一段连贯的文本，作为系统提示词（System Prompt）的一部分或用户消息的前缀，输入给LLM。

注意事项：上下文组装是性能瓶颈之一。向量检索和重排序都比较耗时。在实践中，需要根据应用对延迟的容忍度来调整K和N的值。对于实时对话，K和N不宜过大（例如K=10， N=3）。对于后台分析任务，则可以放宽限制以追求更高的召回率。另外，缓存机制非常有效：对于频繁出现的相似查询，可以直接缓存其检索结果，避免重复计算。

3. 实现自主记忆的关键环节与实操方案

理解了架构，我们来看看如何动手实现一个具备基础自主记忆能力的智能体。这里我将以一个基于Python，使用LangChain框架和Qdrant向量数据库的简化示例，拆解关键步骤。

3.1 环境搭建与核心工具链选择

首先，明确我们的技术栈。为了兼顾灵活性和功能，我选择以下组合：

• 框架：LangChain。它提供了构建智能体所需的大量组件（记忆、链、工具），并且抽象良好，能快速搭建原型。当然，你也可以选择更底层的LlamaIndex或直接调用SDK。
• 向量数据库：Qdrant。开源、性能优秀、Docker部署简单，同时支持云服务。
• 嵌入模型：text-embedding-3-small。在成本、速度和效果之间取得了很好的平衡。对于中文场景，可以选用BGE-M3或M3E。
• LLM：GPT-4o或Claude 3 Haiku（用于推理和生成）。对于记忆摘要等内部处理任务，可以使用成本更低的模型如GPT-3.5-Turbo。

部署Qdrant：

# 使用Docker快速启动一个Qdrant实例 docker run -p 6333:6333 -p 6334:6334 \ -v $(pwd)/qdrant_storage:/qdrant/storage:z \ qdrant/qdrant

这将在本地6333端口启动Qdrant服务。

3.2 构建记忆存储与检索层

接下来，我们用代码实现记忆的存储和检索核心逻辑。

import os from datetime import datetime from typing import List, Dict, Any from langchain.embeddings import OpenAIEmbeddings from langchain.vectorstores import Qdrant from langchain.schema import Document from qdrant_client import QdrantClient from qdrant_client.http import models class AutonomousMemorySystem: def __init__(self, user_id: str, collection_name: str = None): self.user_id = user_id # 使用用户ID作为集合名的一部分，实现逻辑隔离 self.collection_name = collection_name or f"user_memory_{user_id}" # 初始化嵌入模型 self.embeddings = OpenAIEmbeddings(model="text-embedding-3-small") # 连接Qdrant客户端 self.client = QdrantClient(host="localhost", port=6333) # 确保集合存在，并配置向量索引 self._ensure_collection() # 初始化LangChain的Qdrant包装器 self.vectorstore = Qdrant( client=self.client, collection_name=self.collection_name, embeddings=self.embeddings ) def _ensure_collection(self): """创建或验证向量集合""" collections = self.client.get_collections().collections collection_names = [c.name for c in collections] if self.collection_name not in collection_names: # 创建集合，定义向量维度和距离度量（1536是text-embedding-3-small的维度） self.client.create_collection( collection_name=self.collection_name, vectors_config=models.VectorParams( size=1536, distance=models.Distance.COSINE # 余弦相似度 ) ) print(f"Collection '{self.collection_name}' created.") def store_memory(self, text: str, metadata: Dict[str, Any] = None): """存储一段记忆""" if metadata is None: metadata = {} # 注入默认元数据 default_metadata = { "user_id": self.user_id, "timestamp": datetime.utcnow().isoformat(), "type": "conversation", # 默认类型 "importance": 1.0, # 默认重要性分数 "source": "assistant" } default_metadata.update(metadata) # 创建LangChain Document对象 doc = Document(page_content=text, metadata=default_metadata) # 存储到向量数据库 self.vectorstore.add_documents([doc]) print(f"Memory stored: {text[:50]}...") def retrieve_memories(self, query: str, filter_dict: Dict = None, k: int = 5) -> List[Document]: """检索相关记忆""" # 1. 初步向量检索 docs = self.vectorstore.similarity_search_with_score( query, k=k*2, filter=filter_dict # 召回2倍，为重排序留空间 ) # docs格式: [(Document, score), ...] if not docs: return [] # 2. 简单的重排序策略：结合向量分数和元数据 reranked_docs = [] for doc, vector_score in docs: final_score = vector_score metadata = doc.metadata # 时间衰减因子：越近的记忆分数加成越高（示例：24小时衰减一半） time_str = metadata.get("timestamp") if time_str: try: mem_time = datetime.fromisoformat(time_str.replace('Z', '+00:00')) hours_passed = (datetime.utcnow() - mem_time).total_seconds() / 3600 recency_factor = 0.5 ** (hours_passed / 24.0) # 半衰期24小时 final_score *= (0.7 + 0.3 * recency_factor) # 时间权重占30% except: pass # 重要性加权 importance = metadata.get("importance", 1.0) final_score *= importance reranked_docs.append((doc, final_score)) # 按最终得分排序 reranked_docs.sort(key=lambda x: x[1], reverse=True) # 3. 返回Top-K return [doc for doc, _ in reranked_docs[:k]] def update_memory_importance(self, memory_id: str, new_importance: float): """更新某段记忆的重要性分数（示例，Qdrant需通过点ID操作）""" # 注意：Qdrant的update操作需要知道点的ID。 # 在实际中，存储时需记录ID，或通过元数据中的唯一标识来查找。 # 此处为逻辑示意。 print(f"Would update memory {memory_id} importance to {new_importance}") # self.client.update(...)

这个类封装了记忆系统的核心：存储和检索。store_memory方法负责将一段文本及其元数据向量化后存入Qdrant。retrieve_memories方法实现了带有时序衰减和重要性加权的简单重排序逻辑。

3.3 集成到智能体工作流：让记忆“活”起来

现在，我们需要将这个记忆系统嵌入到智能体的决策循环中。一个典型的循环是：观察 -> 检索记忆 -> 思考/规划 -> 行动 -> 存储新记忆。

from langchain.agents import AgentExecutor, create_openai_tools_agent from langchain_openai import ChatOpenAI from langchain.prompts import ChatPromptTemplate, MessagesPlaceholder from langchain.tools import Tool from langchain.memory import ConversationBufferMemory import json class MemoryAugmentedAgent: def __init__(self, user_id: str): self.user_id = user_id self.memory_system = AutonomousMemorySystem(user_id) # 1. 定义工具：记忆检索工具 def retrieve_memories_tool(query: str): """根据当前问题检索用户的长期记忆。""" docs = self.memory_system.retrieve_memories(query, k=3) if not docs: return "没有找到相关的长期记忆。" memories_formatted = "\n---\n".join([f"* {doc.page_content} (类型：{doc.metadata.get('type', 'N/A')}, 时间：{doc.metadata.get('timestamp', 'N/A')})" for doc in docs]) return f"检索到的相关记忆：\n{memories_formatted}" # 2. 定义工具：记忆存储工具 def store_memory_tool(text_to_store: str, memory_type: str = "fact", importance: float = 1.0): """将重要信息存储到长期记忆中。""" metadata = { "type": memory_type, "importance": importance, "source": "agent_action" } self.memory_system.store_memory(text_to_store, metadata) return f"已成功将信息存入长期记忆。内容摘要：{text_to_store[:100]}..." # 将工具包装成LangChain Tool对象 tools = [ Tool( name="retrieve_long_term_memory", func=retrieve_memories_tool, description="当需要回忆与用户相关的过往信息、偏好或事实时使用此工具。输入一个查询字符串。" ), Tool( name="store_to_long_term_memory", func=store_memory_tool, description="当用户提供了重要的、值得长期记住的个人信息、偏好或决策时使用此工具。输入要存储的文本、记忆类型（如'preference', 'fact'）和重要性分数（1-5）。" ), # 这里可以添加其他工具，如网络搜索、代码执行等 ] # 3. 构建提示词模板，预留位置给记忆和聊天历史 prompt = ChatPromptTemplate.from_messages([ ("system", """你是一个拥有长期记忆的智能助手。你可以访问一个专门存储用户信息的记忆库。 在回答用户问题前，请先使用`retrieve_long_term_memory`工具查看是否有相关历史信息。 如果用户提供了新的、有价值的信息，请使用`store_to_long_term_memory`工具将其保存。 请基于所有可用信息（当前对话、工具返回结果、长期记忆）进行友好、专业的回复。"""), MessagesPlaceholder(variable_name="chat_history"), # 短期对话历史 ("user", "{input}"), MessagesPlaceholder(variable_name="agent_scratchpad"), # 代理的思考过程 ]) # 4. 初始化LLM和智能体 llm = ChatOpenAI(model="gpt-4o", temperature=0) self.agent = create_openai_tools_agent(llm, tools, prompt) self.agent_executor = AgentExecutor(agent=self.agent, tools=tools, verbose=True, handle_parsing_errors=True) # 5. 短期记忆（会话内存） self.short_term_memory = ConversationBufferMemory(memory_key="chat_history", return_messages=True) def run(self, user_input: str): """执行一轮交互""" # 在调用智能体前，可以主动触发一次记忆检索，并将结果预加载到上下文中（可选，更高效） # 这里我们依赖智能体自己调用工具，更符合自主性原则。 # 准备输入 inputs = { "input": user_input, "chat_history": self.short_term_memory.buffer_as_messages # 注入短期历史 } # 执行智能体 response = self.agent_executor.invoke(inputs) # 更新短期记忆 self.short_term_memory.save_context({"input": user_input}, {"output": response["output"]}) return response["output"] # 使用示例 if __name__ == "__main__": agent = MemoryAugmentedAgent(user_id="alice") # 第一轮：用户告知偏好 print("用户：我特别喜欢喝黑咖啡，不加糖也不加奶。") resp1 = agent.run("我特别喜欢喝黑咖啡，不加糖也不加奶。") print(f"助手：{resp1}\n") # 第二轮：几天后，用户询问推荐 print("用户：今天有点困，有什么饮料推荐吗？") # 智能体会自动调用`retrieve_long_term_memory`工具，查询“饮料推荐”或“咖啡”相关记忆。 # 工具会返回之前存储的“喜欢黑咖啡”的记忆。 # LLM结合此记忆生成回复。 resp2 = agent.run("今天有点困，有什么饮料推荐吗？") print(f"助手：{resp2}")

在这个实现中，智能体被赋予了两种关键能力：主动回忆（通过retrieve_long_term_memory工具）和主动记忆（通过store_to_long_term_memory工具）。LLM根据对话上下文，自主决定何时调用这些工具。例如，当用户说“我特别喜欢喝黑咖啡”时，LLM应能判断这是一条重要的个人偏好，从而调用存储工具。当用户后来问“有什么饮料推荐”时，LLM应能联想到需要查询用户的饮食偏好，从而调用检索工具。

4. 性能调优、问题排查与进阶策略

将基础系统跑起来只是第一步，要让它在生产环境中稳定、高效地运行，还需要面对一系列挑战。

4.1 延迟与性能优化实战

记忆系统的引入，最直接的代价就是延迟增加。主要耗时点在：1）向量嵌入生成；2）向量数据库检索；3）重排序（如果使用复杂模型）。以下是一些行之有效的优化策略：

1. 异步与非阻塞操作：

• 存储异步化：记忆的存储（尤其是生成嵌入和写入数据库）完全不需要阻塞主响应流程。可以将其放入后台任务队列（如Celery、RQ）中异步执行。

  # 伪代码示例：使用异步任务 from celery import Celery app = Celery('tasks', broker='redis://localhost:6379/0') @app.task def async_store_memory(user_id, text, metadata): memory_system = get_memory_system_for_user(user_id) # 需处理对象序列化或重建 memory_system.store_memory(text, metadata) # 在智能体响应后，立即返回，同时触发异步任务 async_store_memory.delay(user_id, important_text, metadata_dict)

• 检索流水线化：对于检索，可以将“向量召回”和“LLM生成回复”并行。即，在LLM开始推理的同时，并行执行向量检索。这要求LLM的推理时间不能太短，否则收益不明显。

2. 缓存无处不在：

• 查询缓存：对频繁出现的、相似的用户查询（经过向量化后计算相似度）的检索结果进行缓存。可以使用Redis存储序列化的记忆片段列表。设置合理的TTL（例如5分钟）。
• 嵌入缓存：对相同的文本内容，其嵌入向量是固定的。可以建立一个全局的嵌入缓存（键为文本内容的哈希值，值为向量），避免对重复内容（如常见的问候语、系统提示词片段）反复调用嵌入模型。

3. 索引与检索参数调优：

• HNSW参数：如果使用Qdrant/Milvus，调整HNSW索引的ef_construct和M参数。M影响索引的连通性和内存占用（值越大，精度越高，内存消耗越大）。ef_construct影响索引构建时的精度。对于亿级数据，需要仔细权衡。
• 搜索参数：调整搜索时的ef（动态候选集大小）参数。增大ef可以提高召回率，但会增加搜索时间。
• 量化：使用乘积量化（PQ）等压缩技术，可以在轻微损失精度的情况下，大幅减少内存占用和提升搜索速度。Qdrant和Milvus都支持标量量化。

4. 分级记忆与混合检索：

• 热点记忆常驻内存：将每个用户最近访问的、或重要性极高的少量记忆（如用户姓名、核心偏好）直接缓存在应用服务器的内存中，实现微秒级读取。
• 混合检索：结合向量搜索和基于元数据的过滤。先通过user_id等强过滤条件缩小搜索范围，再进行向量搜索，能极大提升效率。

4.2 常见问题排查与解决方案

在实际运行中，你可能会遇到以下典型问题：

4.3 从“有记忆”到“真自主”：记忆的主动管理与演化

基础的记忆系统是被动的，依赖LLM的指令来存储和检索。要实现“自主”，系统需要具备更高级的能力：

1. 记忆的重要性动态评估与衰减：

• 不要将记忆的重要性分数设为固定值。它可以基于访问频率（被检索到的次数）、新鲜度（最近是否被提及）、来源权威性（来自用户明确声明 vs. 模型推测）以及情感强度（结合情感分析）来动态调整。
• 实现一个后台进程，定期扫描记忆库，对重要性分数低于某个阈值的记忆进行自动归档或删除，模拟“遗忘”机制。

2. 记忆的自动摘要与合并：

• 当关于同一主题的记忆片段过多时（例如，多次对话都涉及“用户喜欢Python”），可以触发一个摘要任务。使用LLM将这些片段合并、去重，生成一个更精炼、信息密度更高的摘要记忆，并删除或降权原始碎片。这能有效控制记忆库的膨胀。

3. 记忆驱动的主动交互：

• 真正的自主智能体不应只被动响应。它可以基于记忆主动发起对话。例如，系统检测到用户上次提到“下周要出差”，在出差日期临近时，可以主动询问：“您之前提到的出差准备得怎么样了？需要我帮您查天气或规划路线吗？”这需要系统具备事件监听和定时触发的能力。

4. 处理“chimera”式异构多智能体场景：

• 在由多个异构LLM（有的擅长推理，有的擅长编码，有的擅长创意）协同服务的系统中，记忆系统可以作为中央共享状态层。
• 每个智能体读写记忆时，都需要通过一个记忆协调器。协调器负责解决潜在的写入冲突（如乐观锁），并为不同智能体提供定制化的记忆视图（例如，给创意模型看情感和风格记忆，给推理模型看逻辑和事实记忆）。
• 这要求记忆的元数据 schema 设计得非常丰富，以支持灵活的过滤和视图构建。

构建一个成熟的自主记忆系统，是一个从简单到复杂、持续迭代的过程。它始于一个向量数据库和几个API调用，但最终会演变成一个包含动态评估、摘要合并、冲突解决和主动触发的复杂子系统。这个过程的核心，始终是围绕一个目标：让AI智能体更像一个持续学习、不断成长的伙伴，而不是一个每次对话都要重启的“金鱼”。