AI助手记忆系统开发：三层记忆架构与跨会话实现-北京尧图网络

如果你正在开发 AI 助手大概率遇到过这个尴尬场景用户上一秒告诉你“我姓陈做跨境电商的”下一秒换个话题聊三次助手就不再记得这回事又重新问了一遍“请问怎么称呼您”。问题通常不在大模型的能力而是 AI 助手缺少一套属于自己的记忆系统。更准确地说跨会话记忆真正的难点不是“把更多历史记录检索出来”而是让 Agent 学会“回忆”——知道该记住什么、该在什么时候想起什么、该忘掉什么。本文作为 AI 助手记忆系统开发的实践篇重点解决三类问题为什么不能靠“全量堆历史消息”来实现记忆如何在工程上把记忆拆成工作记忆、情景记忆、语义记忆三个层次以及用一套可直接运行的 Python SQLite 示例带你从零实现一个带跨会话记忆的 AI 助手。读完你不仅能跑通代码还能明白记忆系统在实际项目里应该如何设计、验证和迭代。1. 为什么 AI 助手必须拥有记忆系统先看几个真实场景。场景一用户第一次说“我叫李婷从事教育行业”助手回答“好的李婷老师”。第二次对话用户没有重复身份信息助手却把“李婷”喊成了“李静”或者干脆问“请问你是哪位”。场景二用户在助手里配置了偏好比如“日报按项目维度汇总不要按人汇总”。当天没问题第二天换一个会话助手又忘记了这条约定输出格式回到默认状态。场景三业务方希望 Agent 能主动提醒“你上次说这个需求这周要提测今天是周三了要不要排一下时间”。一个没有记忆的助手不可能做到这一点因为它连“上次”是什么都不知道更不用说跨周跟踪。这三个场景背后的核心诉求是一致的AI 助手要积累关于用户的长期知识并在后续交互中把相关知识自动唤醒。没有记忆系统助手本质上是一台“每次见面都不认识你”的自助查询机可以做单轮问答却做不了持续的陪伴、协作和代理执行。需要强调的是记忆系统解决的不是“存储”问题。聊天记录、向量数据库、对象存储都能存下大量历史文本真正的差距在于“回忆”策略。给大模型塞 50 条历史记录很容易但其中可能有 45 条与当前问题无关甚至会形成干扰。好的记忆系统应该是在正确的时间把正确粒度的信息放到正确的位置。这也是“三层记忆”架构存在的原因。1.1 没有记忆时我们通常怎么做最简单的做法是把整段历史记录拼到 Prompt 里。在演示阶段很快但用户多聊几轮之后Token 成本快速上升模型关注度被无关信息稀释跨天之后会话长度失控超长上下文还会带来首 token 延迟变大、费用不可控等问题。另一种常见做法是“做一个数据库存消息”然后每次都模糊地把最近 N 条拉出来。这仍然是“检索多少就给多少”的思路没有区分信息的稳定程度。用户昨天说过的偏好和昨天随口说的一句“今天下雨了”被同等对待长期知识被淹没在噪音里。1.2 三层记忆的总体判断三层记忆方案把记忆按“稳定性”和“生命周期”拆成三个层次工作记忆负责当前会话的短期上下文情景记忆负责已经结束的历史事件语义记忆负责从对话中提炼出来的长期事实与偏好。这个设计的核心判断是记忆不是单一维度的数据而是有生命周期和抽象层次的信息体系。稳定的知识放长期层临时上下文放短期层历史事件放在两者之间的归档层。后文会围绕这个判断展开架构说明和代码实现。2. 三层记忆架构解析三层记忆并不是新概念它借鉴了认知科学中对人类记忆的常见划分落地到工程上却很实用。下面分别说明每一层做什么、不做什么。2.1 工作记忆工作记忆对应当前正在进行的会话。它的特点是生命周期短变化快直接参与生成。例如用户当前正在聊一个排期计划Plan A 和 Plan B 的细节都放在这一层。在实现上工作记忆一般就是会话内的消息列表但可以额外存一份“会话摘要”用于在关键节点压缩上下文。比如聊到 20 轮后可以把前面的信息压缩成“用户正在评估 5 月版本的两个方案备选方案 A 是重构消息模块方案 B 是优先做跨端搜索”然后只保留最近几轮原文。2.2 情景记忆情景记忆负责“发生过什么”。它保存的是历史会话的归档记录某个用户在什么时间向助手发起过什么请求最后结果是什么重点是记录完整的事件脉络但不需要保留每一句话的原文。可以把它类比成项目日志或日记。比如上周用户让助手生成过一份数据分析脚本情景记忆里保存的是“2025-04-12 用户要求生成订单趋势分析脚本使用 Python pyecharts输出 HTML 报告”而不是那一整段多轮对话原文。情景记忆的价值在于让 AI 助手具备“追溯过去”的能力。用户说“上次那个脚本帮我改一下”助手能在情景记忆中找到对应事件而不是要求用户重新描述一遍。2.3 语义记忆语义记忆是最抽象、最稳定的长期知识。它存放的是跨会话仍然有效的用户事实和偏好典型包括姓名、行业、职位、常用工具、偏好语言、产品偏好、沟通风格。语义记忆可以理解为“用户画像规则知识”的集合每条记录通常是结构化键值对或三元组。例如key: user.name, value: 李婷key: user.industry, value: 教育key: output.preference, value: 日报按项目维度汇总之所以把它单独拆出来是因为这类信息非常适合结构化存储和精确检索。用户在第五次对话时提到“我一直用 Python”这个事实应该在所有后续对话中都有效而不是被当成某条历史片段处理。2.4 三层对比维度工作记忆情景记忆语义记忆核心问题当前在聊什么发生过什么用户是谁长期偏好是什么生命周期会话结束即清理或压缩中长期保留长期保留可跨月跨年存储内容消息原文、会话摘要事件标题、摘要、时间键值对、结构化事实数据来源实时写入会话结束后归档从对话中提炼参与生成方式直接注入上下文按需检索后注入按需检索后注入典型容量KB 到几十 KB可增长需要遗忘机制通常较小质量优先三层之间还有流转关系新信息先进入工作记忆一段会话结束时重要事件被归档为情景记忆同时抽取出的稳定事实和偏好被写入语义记忆。后文实现会展示这个流程。3. 整体设计记忆系统如何工作在写代码之前先把记忆系统的整体链路说清楚。它本质上是一个围绕“写入—读取—遗忘”三个动作设计的中间件。3.1 写入链路写入发生在用户每一轮对话之后。大致流程是把用户消息和助手回复写入工作记忆附带当前会话 ID。使用规则或大模型从本轮对话中抽取结构化事实。比如捕获“我叫陈晨”“我喜欢用 Python”这类信息。将抽取到的事实写入语义记忆采用 upsert 语义已存在的事实直接更新不重复插入。当会话到达结束点或超过一定轮数触发归档为当前会话生成标题和摘要写入情景记忆并清理或压缩工作记忆。3.2 读取链路读取发生在生成回复之前。每次收到用户问题时从工作记忆取出当前会话最近的若干条消息。对用户输入做关键词提取或向量化然后从语义记忆中检索相关长期事实。再从情景记忆中检索与当前问题相似的历史事件。将三层结果按优先级组装成“记忆上下文”注入系统 Prompt。这里的关键是优先级工作记忆是基础上下文语义记忆里命中用户画像的事实通常比情景记忆里的历史事件更优先因为画像类信息更稳定、更相关。排序依据可以是命中次数、更新时间和相似度分数。3.3 遗忘与衰减机制记忆系统必须能遗忘。如果不加控制语义记忆会越攒越多但很多事实会随时间失效。例如用户说“这个季度我们在用钉钉”下个季度可能已经切换到了飞书。工程上常用的思路是给每条记忆维护一个“重要性分数”和“最后命中时间”。每次被成功检索并用于生成分数上升长时间没有被命中分数逐渐衰减分数低于阈值时进入候选清理列表。最终由人工确认或定时任务物理删除。这样既能避免无效记忆占用也能在一定程度上保障用户隐私。3.4 技术选型环节可选方案适用场景存储SQLite / MySQL / Redis轻量演示优先 SQLite高并发用 MySQL Redis 缓存向量检索本地 Embedding FAISS / pgvector需要语义相似度召回时引入关键词检索SQL LIKE / 倒排索引事实型记忆姓名、偏好完全够用事实抽取正则规则 / LLM 抽取快速演示用规则生产用 LLM 人工审核大模型接入OpenAI 兼容接口 / 本地推理服务本文示例兼容两种从工程经验来看事实型记忆适合用结构化键值对事件型记忆适合全文检索叙述型长文才真正需要向量检索。如果一上来就为所有记忆引入向量库很容易过度设计。4. 环境准备与项目初始化下面进入实际代码。本文的示例使用 Python 3.9、SQLite 内置库和一个 OpenAI 兼容的 Chat Completions 接口。4.1 项目目录结构assistant-memory/ ├── assistant.py # AI 助手主程序对接大模型 ├── memory_store.py # 存储层SQLite 封装 ├── memory_manager.py # 记忆管理抽取、检索、归档、遗忘 ├── demo.py # 演示脚本 ├── config.yaml # 配置文件 └── requirements.txt # 依赖清单4.2 Python 环境与依赖建议创建一个独立的虚拟环境避免污染其他项目。python3 -m venv .venv source .venv/bin/activate pip install -r requirements.txtrequirements.txt 内容如下openai1.0.0 python-dotenv1.0.0 PyYAML6.0如果你准备完全使用本地模型和本地 Embedding甚至可以只保留 PyYAML只跑三层记忆逻辑不依赖任何外部大模型。本文为了演示 AI 助手完整对话默认使用大模型接口具体配置见下一节。4.3 配置文件创建一个 config.yaml内容如下llm: base_url: http://localhost:11434/v1 api_key: local-key model: qwen2.5:7b temperature: 0.7 memory: db_path: assistant_memory.db work_limit: 20 semantic_top_k: 5 episodic_top_k: 3 semantic_decay_threshold: 0.3需要说明的是base_url 和 model 请以你实际使用的推理服务为准。配置成 OpenAPI 兼容接口可以直接连本地推理服务也可以换成企业内网部署的模型网关不需要修改业务代码。只要大模型服务提供 /v1/chat/completions 格式的接口就能接入。4.4 大模型接入说明为了避免示例依赖某个特定厂商的账号主程序会按环境变量优先的方式读取配置如果设置了 LLM_BASE_URL、LLM_API_KEY、LLM_MODEL就覆盖 config.yaml 中的值。本地推理服务和云端模型都能使用同样一套代码。5. 核心代码实现从零开始写三层记忆管理器这一章分三层来说存储层、记忆管理层、对话主流程。5.1 存储层SQLite 表设计与访问文件路径memory_store.py# 文件路径memory_store.py import sqlite3 import time from typing import List, Dict, Optional, Tuple class MemoryStore: 三层记忆的 SQLite 存储层。表说明 - work_memory: 当前正在进行的会话记忆随会话生命周期变化 - episodic_memory: 已结束会话的摘要性事件记录 - semantic_memory: 从对话中提炼出来的长期事实和偏好 def __init__(self, db_path: str assistant_memory.db): self.db_path db_path self._init_db() def _init_db(self): with sqlite3.connect(self.db_path) as conn: conn.executescript( CREATE TABLE IF NOT EXISTS work_memory ( id INTEGER PRIMARY KEY AUTOINCREMENT, conversation_id TEXT NOT NULL, role TEXT NOT NULL, content TEXT NOT NULL, summary TEXT DEFAULT , created_at REAL NOT NULL ); CREATE TABLE IF NOT EXISTS episodic_memory ( id INTEGER PRIMARY KEY AUTOINCREMENT, conversation_id TEXT NOT NULL, title TEXT NOT NULL, summary TEXT NOT NULL, happened_at REAL NOT NULL, remind_count INTEGER DEFAULT 0 ); CREATE TABLE IF NOT EXISTS semantic_memory ( id INTEGER PRIMARY KEY AUTOINCREMENT, key TEXT NOT NULL UNIQUE, value TEXT NOT NULL, source TEXT DEFAULT , confidence REAL DEFAULT 1.0, updated_at REAL NOT NULL, hit_count INTEGER DEFAULT 0 ); CREATE INDEX IF NOT EXISTS idx_work_conv ON work_memory(conversation_id); CREATE INDEX IF NOT EXISTS idx_episodic_time ON episodic_memory(happened_at); ) def add_work_message(self, conversation_id: str, role: str, content: str, summary: str ): with sqlite3.connect(self.db_path) as conn: conn.execute( INSERT INTO work_memory (conversation_id, role, content, summary, created_at) VALUES (?, ?, ?, ?, ?), (conversation_id, role, content, summary, time.time()), ) def get_work_messages(self, conversation_id: str, limit: int 20) - List[Dict]: with sqlite3.connect(self.db_path) as conn: cursor conn.execute( SELECT role, content, summary FROM work_memory WHERE conversation_id? ORDER BY id DESC LIMIT ?, (conversation_id, limit), ) rows list(reversed(cursor.fetchall())) return [ {role: role, content: content, summary: summary} for role, content, summary in rows ] def upsert_semantic_memory(self, key: str, value: str, source: str , confidence: float 1.0): with sqlite3.connect(self.db_path) as conn: conn.execute( INSERT INTO semantic_memory (key, value, source, confidence, updated_at, hit_count) VALUES (?, ?, ?, ?, ?, 0) ON CONFLICT(key) DO UPDATE SET valueexcluded.value, sourceexcluded.source, confidenceexcluded.confidence, updated_atexcluded.updated_at , (key, value, source, confidence, time.time()), ) def search_semantic_memory(self, keywords: List[str], limit: int 5): if not keywords: return [] placeholders OR .join([key LIKE ? OR value LIKE ?] * len(keywords)) params [] for kw in keywords: params.extend([f%{kw}%, f%{kw}%]) with sqlite3.connect(self.db_path) as conn: cursor conn.execute( fSELECT key, value, source, confidence, hit_count fFROM semantic_memory WHERE {placeholders} fORDER BY confidence DESC, hit_count DESC LIMIT ?, (*params, limit), ) return cursor.fetchall() def add_episodic_memory(self, conversation_id: str, title: str, summary: str, happened_at: Optional[float] None): happened_at happened_at or time.time() with sqlite3.connect(self.db_path) as conn: conn.execute( INSERT INTO episodic_memory (conversation_id, title, summary, happened_at, remind_count) VALUES (?, ?, ?, ?, 0), (conversation_id, title, summary, happened_at), ) def search_episodic_memory(self, keywords: List[str], limit: int 3): if not keywords: return [] placeholders OR .join([title LIKE ? OR summary LIKE ?] * len(keywords)) params [] for kw in keywords: params.extend([f%{kw}%, f%{kw}%]) with sqlite3.connect(self.db_path) as conn: cursor conn.execute( fSELECT conversation_id, title, summary, happened_at fFROM episodic_memory WHERE {placeholders} fORDER BY happened_at DESC LIMIT ?, (*params, limit), ) return cursor.fetchall() def decay_semantic_memory(self, threshold: float 0.3, max_items: int 1000): with sqlite3.connect(self.db_path) as conn: conn.execute( UPDATE semantic_memory SET confidence confidence * 0.95 WHERE id IN (SELECT id FROM semantic_memory ORDER BY updated_at DESC LIMIT ?), (max_items,), ) conn.execute( DELETE FROM semantic_memory WHERE confidence ?, (threshold,), )这段代码里有几个设计点值得注意。第一semantic_memory 用 key 做唯一约束目的是避免同一事实被重复插入。事实型记忆的天然形态就是键值对重复插入会制造脏数据后续检索时难以去重。第二search_semantic_memory 的检索用 SQL LIKE 做关键词命中。这个方案的优点是零依赖、可解释缺点是找不出“同义表达”。对于姓名、行业、工具名这类精确事实关键词检索已经足够。如果后续要支持“用户说我想看看上次那个图表”这种模糊指代再在前置召回阶段引入向量检索也不迟。第三decay_semantic_memory 是遗忘机制的雏形。它每隔一段时间把所有记忆的置信度乘以 0.95低于阈值则删除。真实项目里更合理的是只衰减长期未被命中的记录并且删除前走人工确认流程。5.2 记忆管理器抽取、检索、归档文件路径memory_manager.py# 文件路径memory_manager.py import re import time from typing import Dict, List, Tuple from memory_store import MemoryStore # 简单规则抽取优先覆盖姓名、偏好、行业这三类最常见事实 RULE_PATTERNS [ (user.name, re.compile(r我(?:叫|是|的名字叫)\s*([\u4e00-\u9fa5A-Za-z0-9]{1,10}))), (user.industry, re.compile(r(?:我|我们).{0,6}(?:做|从事|在)\s*([\u4e00-\u9fa5A-Za-z0-9]{1,12})行业)), (user.preference, re.compile(r我(?:喜欢|比较喜欢|更愿意|偏好)\s*([\u4e00-\u9fa5A-Za-z0-9]{1,20}))), (user.stack, re.compile(r我(?:一直用|主要用|用)\s*([A-Za-z0-9#]{1,30}))), ] def extract_keywords(text: str) - List[str]: 简单中文关键词提取按标点和空格切分过滤纯语气词。 tokens re.findall(r[\u4e00-\u9fa5A-Za-z0-9], text) stopwords {我, 你, 他, 她, 我们, 你们, 的, 了, 吗, 呢, 怎么, 什么, 一个} return [tok for tok in tokens if tok not in stopwords][:8] class MemoryManager: def __init__(self, store: MemoryStore, llm_extract: bool False, extractorNone): self.store store self.llm_extract llm_extract self.extractor extractor # 可选LLM 抽取回调函数 def extract_and_store_facts(self, conversation_id: str, user_text: str, assistant_text: str): 写入链路从对话中抽取稳定事实写入语义记忆。 source fconv:{conversation_id} if self.llm_extract and self.extractor is not None: facts self.extractor(user_text, assistant_text) else: facts self._rule_extract(user_text) for key, value in facts: self.store.upsert_semantic_memory(key, value, sourcesource) def _rule_extract(self, text: str) - List[Tuple[str, str]]: results [] for key, pattern in RULE_PATTERNS: match pattern.search(text) if match: results.append((key, match.group(1).strip())) return results def get_relevant_memories(self, conversation_id: str, user_query: str) - Dict: 读取链路合并三层记忆返回结构化结果。 work self.store.get_work_messages(conversation_id) keywords extract_keywords(user_query) semantic self.store.search_semantic_memory(keywords) episodic self.store.search_episodic_memory(keywords) return { work: work, semantic: semantic, episodic: episodic, } def archive_conversation(self, conversation_id: str, title: str, summary: str): 会话结束或达到归档条件时把工作记忆归档到情景记忆。 self.store.add_episodic_memory(conversation_id, title, summary) # 实际项目中可选择删除或保留工作记忆原文 # 简化实现只归档不删除这段代码的关键是 extract_and_store_facts 被设计成“规则优先、LLM 可选”。规则抽取的好处是零成本、结果稳定缺点是覆盖范围有限。生产环境常见的做法是规则抽取负责事实型记忆LLM 抽取负责复杂综合摘要两路结果经过一层校验后写入。get_relevant_memories 返回的是三层记忆的合并结构主程序拿到它之后按优先级拼装到系统 Prompt 中。这里的检索策略是“关键词SQL”因为没有引入向量依赖如果换成向量检索函数签名不需要变化只需要把 search_semantic_memory 和 search_episodic_memory 的实现替换成向量召回即可。5.3 对话主流程让大模型真的“记得”文件路径assistant.py# 文件路径assistant.py import os import uuid import yaml from openai import OpenAI from memory_store import MemoryStore from memory_manager import MemoryManager with open(config.yaml, r, encodingutf-8) as f: config yaml.safe_load(f) llm_cfg config[llm] mem_cfg config[memory] BASE_URL os.getenv(LLM_BASE_URL, llm_cfg[base_url]) API_KEY os.getenv(LLM_API_KEY, llm_cfg[api_key]) MODEL os.getenv(LLM_MODEL, llm_cfg[model]) client OpenAI(base_urlBASE_URL, api_keyAPI_KEY) store MemoryStore(mem_cfg[db_path]) manager MemoryManager( storestore, llm_extractFalse, ) def build_system_prompt(conversation_id: str, user_query: str) - str: memories manager.get_relevant_memories(conversation_id, user_query) lines [] if memories[semantic]: lines.append(以下是关于用户的长期记忆按置信度和命中次数排序) for key, value, source, confidence, hit_count in memories[semantic]: lines.append(f- {key}: {value} (confidence{confidence:.2f})) if memories[episodic]: lines.append(以下是相关历史事件) for conv_id, title, summary, happened_at in memories[episodic]: lines.append(f- {title}: {summary}) if lines: head f当前时间{time.strftime(%Y-%m-%d %H:%M:%S)}\n\n head 请充分利用以下记忆信息回答用户不要复述记忆来源。\n\n return head \n.join(lines) return def ask(conversation_id: str, user_text: str) - str: system_prompt build_system_prompt(conversation_id, user_text) work_messages store.get_work_messages(conversation_id, limit10) messages [] if system_prompt: messages.append({role: system, content: system_prompt}) for msg in work_messages: messages.append({role: msg[role], content: msg[content]}) messages.append({role: user, content: user_text}) response client.chat.completions.create( modelMODEL, messagesmessages, temperaturellm_cfg[temperature], ) reply response.choices[0].message.content store.add_work_message(conversation_id, user, user_text) store.add_work_message(conversation_id, assistant, reply) manager.extract_and_store_facts(conversation_id, user_text, reply) return reply if __name__ __main__: conv_id str(uuid.uuid4()) print(AI 助手已启动当前会话 ID:, conv_id, ) while True: user_input input(你: ) if user_input.lower() in {exit, quit}: break reply ask(conv_id, user_input) print(助手:, reply)这段代码的核心是 build_system_prompt。它把记忆信息放在 system prompt 中而不是混在用户消息里这是为了让大模型把这些信息当成背景知识来用减少“指令冲突”。在真实项目里如果检索到的记忆过多可以在组装前做一次重排只留下与当前问题相关性最高的前 N 条。另外代码在每一轮回答后都会调用 extract_and_store_facts把新事实写入语义记忆。这个时机非常关键必须是“回复之后”再做抽取因为用户这一轮说的话往往要在助手回答之后才能被更好地理解。还要说明一点这个示例没有做对话结束后的自动归档。实际项目中可以在检测到长时间空闲、用户切换话题、或业务明确标记“会话结束”时调用 manager.archive_conversation。主要原因是自动判别“事件边界”本身就是一个完整课题示例先用简化逻辑跑通主链路。5.4 记忆可视化与调试调试记忆系统时直接看数据库是最直观的。下面给出一个查看三层记忆的小脚本建议加到项目里方便排查。文件路径demo.py# 文件路径demo.py import sqlite3 import time import uuid from memory_store import MemoryStore from memory_manager import MemoryManager from assistant import ask, build_system_prompt def show_all_memories(db_path: str assistant_memory.db): with sqlite3.connect(db_path) as conn: print( 语义记忆 ) for row in conn.execute(SELECT key, value, confidence, hit_count FROM semantic_memory): print(row) print( 情景记忆 ) for row in conn.execute(SELECT title, summary FROM episodic_memory): print(row) def main(): conv_id str(uuid.uuid4()) # 第一段会话让助手记住身份信息 ask(conv_id, 你好我叫陈晨做跨境电商的平时主要用 Python 处理订单数据。) print(第一段会话结束) # 模拟跨会话新会话使用新的 conversation_id new_conv_id str(uuid.uuid4()) print(新会话 ID:, new_conv_id) # 不重复自我介绍直接问业务问题 reply ask(new_conv_id, 帮我分析一下这个月的库存周转重点关注 SKU 维度。) print(助手回复:, reply) print() show_all_memories() if __name__ __main__: main()演示脚本通过不同的 conversation_id 模拟跨会话场景。第一次会话写入了用户身份信息第二次会话是全新的会话 ID工作记忆里没有任何历史消息。如果助手能说出“陈晨的业务背景”或至少不再问“你叫什么”说明语义记忆的提取和检索链路生效了。6. 运行验证对比有无记忆的效果现在把整个项目跑起来。先确认 config.yaml 中的地址指向一个可用的 OpenAI 兼容推理服务然后执行python demo.py6.1 预期输出如果一切正常你会看到类似这样的输出第一段会话结束新会话 ID: d6f3a63e-9d93-4c5a-8a25-3b7f0d123456 助手回复: 陈晨你好我理解你关注的是 SKU 维度的库存周转。结合你的跨境电商业务背景建议先按 SKU 聚合库存数量和销售速度优先分析滞销比例和资金占用情况。语义记忆 (user.name, 陈晨, 1.0, 1) (user.industry, 跨境电商, 1.0, 1) (user.stack, Python, 1.0, 1) 情景记忆注意实际输出会随模型不同而变化重点判断以下三个标准。6.2 如何判断记忆真正生效第一新会话没有重复询问用户身份。如果回复里出现“你叫什么名字”“可以介绍一下你自己吗”说明语义记忆没有在检索阶段被命中优先检查 extract_keywords 是否提取出了特征词。第二回复内容体现了用户背景。比如这里的回复没有停留在通用层面而是结合了“跨境电商业务背景”说明语义记忆已经注入 System Prompt。第三记忆表中存在可解释的数据。show_all_memories 完成后你应当能在语义记忆表中看到 user.name、user.industry、user.stack 三条记录。如果表是空的说明抽取规则没有匹配到你的说法需要调整规则或改为 LLM 抽取。6.3 失败时的第一步排查如果跨会话记忆没有生效先不要急着怀疑模型。按下面的顺序排查检查控制台是否有报错尤其注意 API 地址和模型名称是否可访问。单独查询语义记忆表确认事实有没有写入。没有写入问题在抽取链路。如果写入了但回复没有体现打印 build_system_prompt 的返回值确认注入的 Prompt 是否包含记忆内容。如果 Prompt 有记忆内容但模型没有使用尝试更新提示词明确要求“结合用户背景信息回答”。最后才检查模型本身的能力边界。多数情况下前三步就能定位问题。记忆系统是数据链路问题不是模型能力问题。7. 记忆系统开发常见问题与排查问题现象可能原因排查方式解决方案事实没有写入语义记忆抽取规则未匹配打印 _rule_extract 的输入输出增加规则或开启 LLM 抽取新会话不记得用户身份检索关键词太泛检查 extract_keywords 结果加入更具体的特征词或引入向量检索检索出的记忆太多太杂阈值设置过低查看语义记忆表的 confidence 分布调高阈值只保留高置信度记录同一事实重复写入key 设计不唯一检查 upsert 冲突逻辑结构化 key使用 ON CONFLICT 更新模型总是不使用记忆Prompt 里记忆被历史淹没检查 messages 长度控制历史消息条数记忆表只看 TopK记忆表无限增长缺少遗忘机制查看数据量增幅启用 decay_semantic_memory 定时任务跨会话 ID 不同导致信息断掉会话 ID 分配策略问题检查前端是否每次新建会话使用同一用户 ID 关联多个会话除了表格里的问题还有一类容易被忽略的情况用户的表述本身会变。用户第一次说“我用 Python”第二次说“我用 py”如果只用关键词匹配就检索不到。这不是技术问题而是记忆系统设计时必须接受的边界。解决这类问题有两种思路。一种是记录同义词别名在写入时增加 alias 字段另一种是做归一化比如识别到“py”“Python”都属于编程语言统一存成语言类偏好。从工程成本看第二种可选第一种更可控。真实项目中不建议一上来就引入大而全的知识图谱先用简单方式跑通再根据实际痛点逐步增强。8. 工程化最佳实践从演示到生产这套代码能跑通演示但从“能跑”到“能在生产环境稳定使用”还有几件必须做的事情。8.1 记忆写入前的清洗与校验生产环境不能让任何文本直接进入记忆表。LLM 抽取出的“用户是超级喜欢在春天喝咖啡”这类带情绪、带修饰的信息并不适合作为长期事实。建议接入一层校验规则长度超过 50 个字符的事实人工复核。涉及手机号、邮箱、家庭住址等敏感信息的字段加密存储并限制读取权限。同一 key 的 value 变化过于频繁时需要二次确认后再更新旧值。8.2 检索策略关键词优于向量混合才是常态很多团队一上来就追求向量检索其实对记忆系统来说关键词检索和向量检索各有优势。事实型记忆用关键词事件型记忆可以用摘要匹配只有句子级的长文本召回才真正需要向量。推荐的分层策略是先用关键词快速召回候选再通过 LLM 或规则判断当前问题是否真的需要这些记忆。这样可以降低无效检索带来的 Token 消耗和幻觉风险。8.3 隐私与权限边界记忆系统存储的是用户私密信息必须默认按最小权限设计。同一个用户的不同项目要隔离不同用户的记忆绝不能互相检索。在生产环境里每条记忆都要绑定 user_id 和 scope检索 SQL 必须强制带上这两个条件。此外用户应当拥有查看和删除自己记忆的权利。很多产品最后被投诉“AI 助手记住了不该记的东西”就是因为少了这一层透明性。至少要提供一条命令按用户 ID 清理全部记忆以及导出某用户全部记忆的能力。8.4 性能与容量SQLite 适合演示和单机小规模场景一旦用户量上来读写竞争和锁问题会变得明显。生产环境更推荐 PostgreSQL 或 MySQL 存储结构化事实Redis 缓存高频命中的画像型记忆向量库只保存长文本场景下的 embedding。遗忘任务建议做成定时任务而不是放在请求链路里。如果每次请求都做全表衰减会因为写锁造成接口抖动。可以把衰减频率设成每天一次或每周一次放在业务低峰期执行。8.5 可观测性与灰度回滚记忆系统上线时最怕的是模型悄悄记住了错误信息用户没发现但行为一直在变坏。因此必须监控三类指标记忆写入量、记忆检索命中率、以及记忆参与前后回复质量的对比。更稳妥的做法是先做“影子模式”系统正常生成回复同时默默把检索到的记忆记录下来只做日志不注入 Prompt。跑一段时间后人工评估这些记忆是否准确、是否有用再决定要不要全量开启。万一开启后用户反馈变差可以一键关闭记忆注入开关让系统退回无记忆状态。记忆系统最怕“不可回退”因此开关设计比算法设计更重要。9. 总结与后续学习方向跨会话记忆不是把聊天记录原封不动地塞给大模型而是通过三层记忆架构帮助 Agent 学会回忆。本文用一套可运行的 Python 示例实现了工作记忆、情景记忆、语义记忆的写入、检索、归档和遗忘并演示了跨会话场景下身份信息的自动继承。如果你想继续深入这里有四个值得探索的方向一是记忆的向量化召回让系统能通过语义而不是关键词找到相关历史二是记忆的自动编辑当新事实和旧记忆冲突时如何判断该保留哪条三是事件级记忆摘要如何准确判断一段对话是否值得归档四是多用户记忆隔离和权限体系这在大规模产品场景下几乎是必答题。最后提醒一句不要急于给记忆系统增加复杂能力。先从“用户身份和偏好”这种最稳定的语义记忆开始把写入、检索、清洗、回滚链路全部跑稳再逐步加入情景记忆和事件追溯。记忆系统是数据质量系统不是模型能力系统数据越干净Agent 的“回忆”才越可靠。

AI助手记忆系统开发：三层记忆架构与跨会话实现

相关推荐

openEuler+鲲鹏平台：Agent Memory记忆管理系统实战指南

从散落混乱到统一入口：一套JSON工具类封装方案的设计与难点复盘

动物“接电话”行为洞察：声学感知与智能交互技术的应用

更多资讯

Agent Skills架构解析与开发实战指南

大语言模型智能体的15类安全威胁与防御实践

AgentScope Java：Java工程师的多智能体AI应用开发新入口

排序算法课程设计：实现、测试与性能分析

MongoDB索引优化与createIndex使用详解

AI与物联网如何革新智慧农业：技术解析与实践

今日更新

Agent-Reach：打通大模型触达外部系统的最后一公里

深度学习图像隐写分析实战：从CNN原理到毕设源码全解析

AI赋能知识产权供需匹配：专利评估、需求挖掘与多路召回工程实践

本周精选

防幻觉智能体架构：电源硬件设计中的大模型编排与工具化实践

OpenGL面试核心考点：渲染管线、矩阵变换与性能排查全解析

全国计算机二级C语言真题PDF高效刷题指南

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？