企业官网建设流程全解析

开发过 AI Agent 的读者一定遇到过这样的尴尬场景：和智能体连续聊了十几轮，它突然反问“你刚才说的项目背景是什么”“你叫什么名字来着”。这不是某个模型太笨，而是 Agent 缺少记忆机制导致的“失忆”。

网上关于 Agent 记忆的教程不少，但多数只停留在“用 LangChain 的 ConversationBufferMemory 存一下聊天记录”的层面，一旦遇到跨会话、跨 Agent、需要长期沉淀的场景就不知道怎么办了。本文从理论到实战，系统梳理 Agent 记忆的层次、存储方案、检索策略与工程实现，并给出完整可运行的代码示例。

文章偏工程实操，适合正在做 AI 应用开发、RAG 系统、智能客服、个人助手类项目的开发者阅读。读完你会理解 Agent 为什么要分短期记忆和长期记忆，也能照着文章搭出一套带“记忆能力”的 Agent 服务。

1. 背景与核心概念：Agent 为什么会“失忆”

1.1 什么是 Agent 记忆

在传统的软件系统里，数据持久化是常识：用户注册了账号，数据库里就会存一条记录，下次登录依然存在。但大语言模型（LLM）天生是“无状态”的，每一次 API 调用，模型只拿到这次请求里的 Prompt，它对上一轮对话、上一个任务的结果毫不知情。

AI Agent 是建立在 LLM 之上的智能体。它不仅要理解用户当前这句话，还要推理、规划、调用工具、执行动作，最终给出结果。一旦缺少记忆，Agent 就无法在连续任务中保持一致性，表现为：

• 用户自我介绍过职业背景，下一轮 Agent 又忘了。
• 用户让 Agent 分步骤处理数据，Agent 处理第二步时不知道第一步的产出是什么。
• 多个用户同时使用，Agent 把 A 用户的偏好用到了 B 用户身上。
• Agent 完成复杂任务后，下次遇到类似任务仍然从零开始。

所以，所谓“Agent 记忆”，本质上是让无状态的 LLM 具备状态能力的一系列机制。这些机制包括上下文维持、信息存储、检索召回、更新合并、过期遗忘。

1.2 失忆问题的本质

要理解失忆问题，先要理解 LLM 的上下文窗口限制。模型一次能接收的 Token 数量是有限的，比如 128K、200K。哪怕窗口再大，也不可能无限追加对话历史。对话越长，开销越大，响应越慢，而且中间信息容易被注意力机制“冲淡”。

于是出现了一个工程矛盾：我们希望 Agent 记住更多信息，但物理上不能让所有信息都塞进上下文。失忆问题的本质，就是在这个矛盾下，没有设计出合理的“存储—检索—更新”方案。

这里需要澄清一个常见误区：很多人以为“失忆”就是上下文长度不够。实际上，就算上下文足够长，把所有历史都堆进 Prompt 也不是好方案。因为无关信息会干扰模型判断，增加成本，甚至导致模型忽略关键信息。真正的记忆设计，要解决的是“记住什么、存到哪里、何时取回、如何更新”。

1.3 记忆的三种类型

在 Agent 工程领域，通常把记忆分成三个层次：

这三种记忆不是互斥的，而是组合使用的。一次真实对话中，Agent 的工作记忆负责当前任务，短期记忆维护本次会话上下文，长期记忆在需要时被检索出来注入上下文中。

1.4 双网络记忆模型与 LSTM 的启发

长短期记忆网络（LSTM）是深度学习领域解决序列记忆问题的经典结构。它通过“遗忘门、输入门、输出门”来控制信息流入、留存和输出，避免长期依赖中的梯度消失。

现代 Agent 记忆设计，在思路上与 LSTM 有相似之处：短期内保留最近信息，长期内筛选重要信息并防止无关噪声进入。工程上我们不需要真的实现一个 LSTM 神经网络，而是可以参考它的门控思想，设计 Agent 记忆的写入、更新、遗忘逻辑：

• 写入门：判断哪些信息值得记住。
• 更新门：新信息与旧信息合并后，覆盖旧信息。
• 遗忘门：过期、错误、低置信度的信息要被清理。

这种“双网络记忆模型”，在 Agent 工程中的落地形态就是“短期记忆窗口 + 长期向量存储”的组合。后面实战部分会详细展开。

2. 环境准备与项目结构

2.1 运行环境

本文示例代码使用 Python 编写，建议使用 Python 3.10 及以上版本。我在本地开发环境中的组合如下，供参考：

需要提醒一点：LangChain 的 API 在 0.x 版本到 1.x 版本之间有过调整，不同版本的导入路径和类名可能不同。你在运行代码时如果遇到ImportError，优先检查当前环境中的包版本，再对照官方文档调整。

2.2 安装依赖

创建工作目录并安装依赖：

mkdir agent-memory-demo cd agent-memory-demo python -m venv venv source venv/bin/activate # Windows 下使用 venv\Scripts\activate pip install langchain langchain-openai chromadb redis openai python-dotenv

如果你的网络环境无法直接访问外部模型接口，可以把代码中的base_url指向本地部署的兼容服务，或者使用支持 OpenAI 格式的国内模型服务。核心逻辑不依赖具体厂商。

2.3 项目结构

agent-memory-demo/ ├── .env # 存放 API Key 等环境变量 ├── src/ │ └── agent_memory/ │ ├── __init__.py │ ├── conversation_memory.py # 会话级短期记忆 │ ├── vector_memory.py # 向量长期记忆 │ ├── shared_memory.py # 多 Agent 共享记忆 │ ├── memory_agent.py # 完整 Agent 示例 │ └── combined_context.py # 双网络记忆组合示例 └── data/ └── chroma/ # ChromaDB 持久化目录

.env 文件示例：

OPENAI_API_KEY=sk-xxxx OPENAI_BASE_URL=https://api.example.com/v1 REDIS_URL=redis://localhost:6379/0

3. 记忆体系的设计要点：写入、检索、更新

在写代码之前，先把记忆体系的设计思路理清楚。很多项目失败不是因为代码写不出来，而是不知道哪些信息该存、哪个阶段该检索、旧数据怎么处理。

3.1 写入：不是所有内容都值得记住

很多初学者的做法是：把用户每一句话都存进数据库。这样看起来“全”，实际上是在制造噪声。想象一下，如果用户的每一句“哈哈”“好的”“继续”都沉淀成长期记忆，长期记忆里全是无意义内容，真正重要的画像反而不容易被检索到。

建议的写入策略：

• 抽取式写入：对话完成后，用一次 LLM 调用抽取结构化摘要，再存入库。
• 事件式写入：只有发生了“有意义事件”才写，比如用户修改了偏好、任务产生了最终结论、出现了关键错误。
• 时效性标记：每条记忆都记录时间戳，长期不命中的记忆降低权重。

一个简单但有效的判断规则：如果这句话删掉，未来对话会不会受影响？如果不会，就不要写入长期记忆。

3.2 检索：让相关记忆“恰好在需要时出现”

存储只是第一步。Agent 收到新消息时，要从长期记忆里捞出最相关的信息，这就是检索。向量检索是当前的主流方案，思路是把文本转化成向量，然后在向量空间中找语义相近的内容。

实际工程中，仅有向量检索往往不够。还需要配合：

• 时间衰减：距离当前时间越近的记忆，权重越高。
• 用户隔离：检索时带上user_id过滤条件，防止不同用户记忆互相污染。
• 主题过滤：通过 metadata 中的topic字段限定范围。

3.3 更新与遗忘：记忆不是只增不改

长期记忆最大的坑，是“旧信息覆盖新信息、错误信息长期存在”。举例：用户上周说“我喜欢喝茶”，这周说“我最近改喝咖啡了”。如果记忆系统不去更新，下周 Agent 仍然会给用户推荐茶。

解决思路：

• 合并式更新：检索到同一主题的旧记录后，不是新增一条，而是把旧记录和新信息合并成一条新记录。
• 冲突检测：如果新旧信息矛盾，以最新时间戳为准。
• 定期压缩：对同一主题的多条记忆生成摘要，删除冗余条目。

用一句话总结记忆设计的原则：写入要克制，检索要精准，更新要及时，遗忘要主动。

4. 完整实战案例：打造带长期记忆的 Agent

下面进入实战环节。我们会从最简单的会话记忆开始，逐步升级到向量长期记忆，最后实现多 Agent 共享记忆。

4.1 会话级短期记忆：用 LangChain 窗口记忆保持多轮一致

会话级记忆解决的是“同一次会话内别失忆”。最简单的方式是使用 LangChain 的ConversationBufferWindowMemory，它只保留最近 N 轮对话，实现“滑动窗口”效果。

# 文件路径：src/agent_memory/conversation_memory.py from dotenv import load_dotenv from langchain.memory import ConversationBufferWindowMemory from langchain.chains import ConversationChain from langchain_openai import ChatOpenAI load_dotenv() model = ChatOpenAI( model="gpt-4o-mini", temperature=0.3, ) # 只保留最近 5 轮对话，防止上下文膨胀 memory = ConversationBufferWindowMemory(k=5, return_messages=True) chain = ConversationChain( llm=model, memory=memory, verbose=False, ) print(chain.predict(input="我叫小明，是一名后端工程师，最近在研究 Agent 记忆方案。")) print(chain.predict(input="我在对比向量数据库和传统数据库做长期记忆的差异。")) print(chain.predict(input="我刚才介绍了自己，我的职业是什么？"))

运行第三句时，Agent 可以准确回答“你是后端工程师”，这就是会话级短期记忆的效果。

这个方案的优点是实现简单，适合轻量场景；缺点是跨会话就失效了。只要服务重启，或者用户换了浏览器，记忆就没了。要解决跨会话问题，必须把记忆落到持久化存储中。

4.2 向量长期记忆：用 ChromaDB 存储跨会话信息

长期记忆的思路很简单：把用户的关键信息转换成向量，存入向量数据库；新对话开始时，先从向量库里检索相关内容，再注入 Prompt。

这里实现一个VectorMemory类，封装 ChromaDB 的读写操作：

# 文件路径：src/agent_memory/vector_memory.py import uuid from typing import List, Dict, Any, Optional import chromadb from chromadb.config import Settings class VectorMemory: """基于 ChromaDB 的长期记忆存储，支持写入、检索、删除。""" def __init__(self, collection_name: str = "agent_memory"): self.client = chromadb.PersistentClient( path="./data/chroma", settings=Settings(anonymized_telemetry=False), ) self.collection = self.client.get_or_create_collection( name=collection_name, metadata={"hnsw:space": "cosine"}, ) def add_memory( self, text: str, user_id: str, topic: str = "general", metadata: Optional[Dict[str, Any]] = None, ) -> str: """写入一条记忆，返回记忆 ID。""" memory_id = str(uuid.uuid4()) meta = metadata or {} meta.update({ "user_id": user_id, "topic": topic, "created_at": meta.get("created_at", ""), }) self.collection.add( documents=[text], ids=[memory_id], metadatas=[meta], ) return memory_id def search(self, query: str, user_id: str, top_k: int = 5) -> List[Dict]: """按语义相似度检索指定用户的记忆。""" result = self.collection.query( query_texts=[query], n_results=top_k, where={"user_id": user_id}, ) docs = result["documents"][0] metas = result["metadatas"][0] ids = result["ids"][0] return [ {"id": ids[i], "text": docs[i], "metadata": metas[i]} for i in range(len(docs)) ] def delete_memory(self, memory_id: str) -> None: """按 ID 删除记忆，用于遗忘机制。""" self.collection.delete(ids=[memory_id])

这里有几个关键点：

• PersistentClient(path="./data/chroma")会把向量数据持久化到本地目录，服务重启不丢失。
• where={"user_id": user_id}实现用户级隔离，避免串记忆。
• metadata中可以追加topic字段，方便后续主题过滤。

4.3 组合短期与长期记忆：双网络记忆模型落地

现在把两块拼起来：短期记忆负责当前会话的上下文，长期记忆负责跨会话的信息恢复。这其实就是文章开头提到的“双网络记忆模型”——短期窗口网络负责近期上下文，长期向量网络负责历史沉淀。

# 文件路径：src/agent_memory/combined_context.py from datetime import datetime from typing import List, Tuple def build_short_context(history: List[Tuple[str, str]], max_rounds: int = 5) -> str: """从最近对话历史中截取短期记忆片段。""" recent = history[-max_rounds:] lines = [] for user_msg, assistant_msg in recent: lines.append(f"用户：{user_msg}") lines.append(f"助手：{assistant_msg}") return "\n".join(lines) def build_long_context(vector_memory, query: str, user_id: str, top_k: int = 3) -> str: """从向量库检索长期记忆。""" results = vector_memory.search(query=query, user_id=user_id, top_k=top_k) if not results: return "暂无相关长期记忆。" lines = [ f"- {item['text']}" for item in results ] return "\n".join(lines) def build_final_prompt( user_input: str, short_context: str, long_context: str, ) -> str: """组合成最终 Prompt。""" prompt = f"""你是拥有长期记忆能力的 AI Agent。 【长期记忆（来自之前的交互）】 {long_context} 【短期记忆（本次会话上下文）】 {short_context} 【当前用户问题】 {user_input} 请结合记忆回答用户问题。如果长期记忆中没有相关内容，直接根据当前问题回答即可。 """ return prompt

这里的设计亮点是：长期记忆是“按需注入”的。只有当前问题相关的历史信息才会被检索出来进入 Prompt，而不是把全部历史一股脑塞进去。这样既控制成本，又减少噪声。

4.4 多 Agent 共享记忆：用 Redis 实现记忆总线

在稍微复杂的系统里，可能同时存在多个 Agent：一个负责客服，一个负责数据处理，一个负责推荐。如果每个 Agent 各存各的记忆，用户跟客服反映完偏好，再去用推荐 Agent，推荐 Agent 仍然一无所知。

多 Agent 共享记忆的常见做法是引入一个中央存储，比如 Redis。所有 Agent 往同一个命名空间读写记忆。

# 文件路径：src/agent_memory/shared_memory.py import json from typing import Optional, Dict, Any import redis class SharedMemory: """基于 Redis 的多 Agent 共享记忆，按命名空间隔离。""" def __init__(self, redis_url: str = "redis://localhost:6379/0"): self.client = redis.Redis.from_url(redis_url, decode_responses=True) def set_memory(self, agent_name: str, user_id: str, key: str, value: Any) -> None: redis_key = f"agent_memory:{agent_name}:{user_id}:{key}" self.client.set(redis_key, json.dumps(value, ensure_ascii=False)) def get_memory(self, agent_name: str, user_id: str, key: str) -> Optional[Any]: redis_key = f"agent_memory:{agent_name}:{user_id}:{key}" data = self.client.get(redis_key) if data is None: return None return json.loads(data) def publish_event(self, namespace: str, event: Dict[str, Any]) -> None: """发布共享事件，其他 Agent 可订阅后更新自身记忆。""" self.client.publish(f"agent_shared:{namespace}", json.dumps(event, ensure_ascii=False)) if __name__ == "__main__": # 示例：客服 Agent 写入用户偏好 shared = SharedMemory() shared.set_memory( agent_name="customer_service", user_id="U10001", key="preference", value={"drink": "coffee", "channel": "app"}, ) # 推荐 Agent 读取同一用户偏好 pref = shared.get_memory( agent_name="recommendation", user_id="U10001", key="preference", ) print("推荐 Agent 读到的偏好：", pref)

这种方式适合跨 Agent 共享用户画像、任务状态等结构化数据。如果共享的是非结构化文本，可以叠加向量数据库，用共享向量库替代单机 Chroma。

4.5 完整的记忆型 Agent：把所有模块串起来

下面把上面的模块组装成一个带完整记忆能力的 Agent 类：

# 文件路径：src/agent_memory/memory_agent.py from datetime import datetime from typing import List, Tuple from langchain_openai import ChatOpenAI from langchain_core.prompts import ChatPromptTemplate from agent_memory.vector_memory import VectorMemory from agent_memory.combined_context import build_short_context, build_long_context, build_final_prompt class MemoryAgent: """具备长期记忆能力的 Agent 示例。""" def __init__(self, user_id: str): self.user_id = user_id self.vector_memory = VectorMemory() self.llm = ChatOpenAI( model="gpt-4o-mini", temperature=0.5, ) self.history: List[Tuple[str, str]] = [] self.remember_keywords = ["我是", "我的", "职业", "偏好", "喜欢", "项目", "计划"] def chat(self, user_input: str) -> str: # 1. 构建短期上下文 short_context = build_short_context(self.history, max_rounds=5) # 2. 检索长期记忆 long_context = build_long_context( self.vector_memory, query=user_input, user_id=self.user_id, top_k=3, ) # 3. 生成回复 final_prompt = build_final_prompt(user_input, short_context, long_context) response = self.llm.invoke(final_prompt).content # 4. 保存到历史列表 self.history.append((user_input, response)) # 5. 判断是否值得写入长期记忆 if self._should_remember(user_input): self.vector_memory.add_memory( text=f"用户说：{user_input}", user_id=self.user_id, topic="user_preference", metadata={"created_at": datetime.now().isoformat()}, ) return response def _should_remember(self, user_input: str) -> bool: return any(kw in user_input for kw in self.remember_keywords) if __name__ == "__main__": agent = MemoryAgent(user_id="U10001") print(agent.chat("你好，我叫小明，是一名后端工程师。")) print(agent.chat("我最近在研究 AI Agent 的长期记忆方案。")) print(agent.chat("我们刚才聊了什么？"))

运行效果：

• 第一轮，Agent 收到自我介绍，触发remember_keywords，把“我叫小明，是后端工程师”写入向量库。
• 第二轮，Agent 收到关于“长期记忆方案”的提问，触发检索，把第一轮沉淀的信息和当前问题组合成上下文。
• 第三轮，Agent 能准确回答“刚聊了 AI Agent 长期记忆方案”，同时记得用户是小明。

这是一个“迷你版”Agent 记忆闭环。真实项目里可以把_should_remember替换成 LLM 抽取式摘要，让模型判断哪些信息值得沉淀。

5. 常见问题与排查思路

在实际开发和调试过程中，Agent 记忆相关的坑不少。下面整理了几类高频问题。

如果你遇到“记忆存了但检索不到”的问题，优先排查三个点：

1. 是否真的写入了？检查向量库集合中的文档数量。
2. 检索条件是否过滤掉了目标数据？比如 user_id 拼写不一致。
3. 向量相似度阈值是否设置过高？可以打印相似度分数观察。

6. 最佳实践与工程建议

6.1 记忆内容要分层管理

不要把所有记忆塞进一个集合。建议至少分成：

• user_profile：用户画像，比如职业、偏好、联系方式。
• task_state：任务状态，比如进行到第几步、输出物在哪。
• interaction_log：交互日志，用于复盘分析。
• domain_knowledge：领域知识，比如产品介绍、公司政策。

分层的好处是：检索时可以根据场景限定集合，减少噪声；清理时也可以按类型分别处理。比如任务结束后，task_state可以直接清空，而user_profile要长期保留。

6.2 写入长期记忆前，先做抽取和压缩

把用户原始对话直接存进长期记忆，是工程上最常见的错误。正确做法是：用 LLM 做一轮抽取，把“用户明确表达的偏好”和“可以忽略的寒暄”区分开。

这里给出一个抽取示例提示词：

EXTRACT_PROMPT = """ 你是一个记忆提取助手。根据用户和 Agent 的对话内容，提取值得长期记住的信息。 要求： 1. 只提取事实性信息，比如姓名、职业、偏好、明确选择。 2. 忽略寒暄、情绪化表达和临时任务指令。 3. 输出为简短的陈述句。 4. 如果没有值得记忆的信息，输出“无”。 对话内容： {conversation} """

抽取后的结果用于向量存储，既能减少存储量，也能提高检索准确率。

6.3 设计“遗忘”机制

记忆系统一定要有遗忘机制。长期不访问的记忆、被新信息覆盖的记忆，都应该定期清理或降权。常见做法：

• 时间衰减：检索评分时乘以math.exp(-age_days / half_life_days)。
• 定期压缩：每天跑一次离线任务，把同一主题的 20 条记忆合并成 3 条。
• 用户反馈：用户明确说“我不是这个意思”时，删除相关记忆条目。

6.4 安全与隐私边界

记忆系统存储的是用户个人信息，安全要求很高。需要注意：

• 敏感信息脱敏后再入库，比如手机号、身份证号。
• 检索接口不做跨用户越权访问，必须校验身份。
• 生产环境删除记忆要有审计日志。
• 给用户提供“清空记忆”的入口，这是隐私合规的基本要求。

6.5 用评测驱动迭代

记忆质量不好量化，但不代表不能测。建议建立一组评测用例，覆盖：

• 用户信息持久化：第一天告诉 Agent 自己的偏好，第二天再问，是否记得。
• 多轮一致性：同一会话内，Agent 是否引用前面聊到的内容。
• 冲突更新：用户改了偏好，Agent 是否按新偏好回答。
• 检索相关性：给定问题，检索结果里相关内容的占比。

定期跑一遍评测集，分析失败案例，比凭感觉调参有效得多。

7. 2026 年 Agent 记忆的发展方向

写到这里，很多读者可能已经在考虑下一步选型了。结合技术趋势，2026 年的 Agent 记忆会呈现几个明显方向。

一个方向是“记忆即基础设施”。记忆能力正在从各家框架的附属功能，变成独立的基础服务。开发者不再需要自己写 ChromaDB 封装、写 Redis 同步，而是直接接入统一的记忆服务层，通过 SDK 完成读写和检索。这样团队可以更关注业务逻辑。

另一个方向是“多 Agent 共享记忆的标准化”。之前我们通过 Redis Pub/Sub 做了一个简单的共享记忆总线，但在真实系统中，多 Agent 之间需要的是更规范的事件协议，比如“用户偏好变更”事件、“任务完成”事件。这类事件定义、订阅机制和冲突处理规则，会成为多 Agent 应用设计的核心内容。

还有一个值得关注的趋势是“记忆与模型能力解耦”。随着大模型本身的推理能力增强，Agent 不再需要把大量上下文塞进模型窗口，而是把记忆交给向量库、图谱数据库和压缩服务，只把“必要的最小上下文”交给模型。这样一来，模型窗口压力大大减轻，记忆容量可以做到近乎无限。

对开发者来说，未来两年掌握记忆设计能力，会成为 AI 应用开发的一项关键技能。它不要求你懂深度学习算法，但要求你理解信息生命周期，掌握向量检索、缓存、消息队列、数据分层的工程手段。

8. 总结与动手实践建议

这篇文章从 Agent 失忆的根源出发，完整梳理了记忆的三种类型，解释了双网络记忆模型在工程上的落地方式，并给出了从会话记忆、向量长期记忆到多 Agent 共享记忆的完整代码。核心要点可以归结为五句话：

• Agent 失忆的本质是 LLM 无状态，需要通过外部机制补充状态。
• 短期记忆解决会话语境，长期记忆解决跨会话沉淀。
• 写入要克制，抽取摘要后再存，不要存原始垃圾文本。
• 检索要精准，带用户隔离和时间衰减，必要时混合关键词检索。
• 遗忘和更新同样重要，冲突时以最新信息为准。

现在最好的学习方式，是把你手头的 Agent 项目打开，加一个简单的向量记忆模块。不需要一上来就实现全部功能，可以先让 Agent 记住用户姓名和偏好，下次会话时能正确回答“我是谁”，这就是一个好的开始。

如果本文对你有帮助，建议先收藏备用。后面遇到 Agent 记忆相关的选型问题，可以翻回来对照参考。欢迎在评论区聊聊你在项目中踩过的记忆坑。