我们先把话说在前面大模型本身没有“记忆”它看到的只是你每次请求时塞进上下文窗口的那段文本。所谓“长期记忆”本质上是一个工程架构问题不是模型能力问题。很多人接完 OpenAI、Claude 或开源模型的 API 后第一反应是“模型怎么又忘了”第二反应是“那我是不是该微调一下”。其实大部分场景根本不需要微调你需要的是一个能帮大模型做记忆管理的架构。这个主题最近在 Hacker News 上有一个很典型的项目讨论标题叫“Tried some experiments with architecture for Long term memory for LLM”作者用一系列小实验去验证不同记忆架构的效果。这件事之所以值得关注是因为它把长期记忆从“概念”拉回到了“工程实现”。这篇文章不会只停留在概念上。我会先解释长期记忆在 LLM 应用里到底难在哪再对比几种主流的记忆架构最后给你一套可以跑起来的最小实现包括代码、配置、验证方法和常见问题排查。读完你会发现长期记忆最难的不是存储而是“什么时候该记忆、什么时候该遗忘、什么时候该把哪段记忆塞回上下文”。1. 这篇文章真正要解决的问题如果你做过真实的 LLM 应用开发大概率遇到过下面这些情况用户早上和 AI 助理聊过自己的项目背景下午再打开AI 完全不知道你是谁。用户在对话里说了自己的偏好比如“以后回复用中文不要用英文”模型当时记住了但下一个 session 又忘了。你尝试把历史对话全部拼进 Prompt结果很快就把上下文窗口塞满费钱且越到后面效果越差。你想让 AI 在长篇写作、代码重构、知识管理这类任务里扮演“长期协作者”但每次都要重新交代背景。这些问题的根源只有一句话对话是无状态的但真实业务是有状态的。微调能解决一部分风格和知识问题但微调解决不了“用户上午说了什么”这种个性化记忆因为这是动态数据不是静态知识。真正合理的做法是在业务层搭建一套记忆架构把重要的信息存储下来在需要的时候检索出来再注入到模型的上下文里。这篇文章就是围绕这个目标展开的。我会从架构分层讲起然后给出一套可以运行的实验代码最后总结落地时容易踩的坑。适合正在做 LLM 应用、AI Agent、知识库工具、Copilot 类产品的开发者阅读。2. LLM 长期记忆的核心概念与架构分层2.1 记忆不是一块硬盘而是一条链路很多人理解“长期记忆”时会把它想象成一个数据库存进去、取出来。这个理解没错但不完整。真正可用的记忆架构是一条完整的链路记忆采集从对话中识别哪些信息值得存。记忆存储以合适的结构保存这些信息。记忆检索在新一轮对话中找出相关的记忆。记忆注入把检索到的记忆拼进 Prompt 的合适位置。记忆更新根据新信息修正或覆盖旧记忆。缺任何一环记忆系统都会形同虚设。比如很多 RAG 应用只做了存储和检索但完全没有“什么信息值得存”的判断结果库里塞满了废话检索出来的相关度也很差。2.2 长期记忆的类型划分在研究架构之前先要明确“记忆”这个词在不同场景下对应不同的数据类型。记忆类型特点典型例子存储建议会话工作记忆短期、顺序性强当前对话的上下文信息上下文窗口 摘要缓存情景记忆用户明确表述的事实“我在做电商数据分析”键值或数据库记录语义记忆可泛化的知识“用户偏好简洁回答”偏好配置文件程序性记忆操作流程、工具使用习惯“每次回复前先查数据库”规则或提示词模板注意这不只是理论分类它直接影响你的技术选型。比如情景记忆适合用向量数据库检索但语义记忆和偏好类信息更适合用结构化的配置文件存储。把所有记忆都塞进向量数据库是很多项目后期难维护的原因。2.3 记忆架构与 Prompt 的关系要让模型“记起来”最终还是要通过 Prompt 注入。所以记忆架构本质上是决定“哪些文本可以出现在 Prompt 里”的过滤器。这里有一个关键原则不要追求把全部记忆塞进上下文而要追求把最相关的记忆塞进上下文。上下文窗口未来可能会越来越大但上下文越长模型的注意力越分散响应延迟和成本也在增加。一个健康的记忆架构应该像一个优秀助手它知道抓住你这句话的核心而不是把去年所有的工作日志都背出来。3. 主流 LLM 长期记忆架构方案对比下面把目前业界常见的几种架构方案摆在一起。没有绝对最优的方案只有特定场景下更合适的取舍。3.1 方案一上下文窗口全量拼接最原始的做法。把所有历史消息按时间顺序拼成一个长 Prompt每次请求都带上。优点实现最简单没有任何额外组件。对模型能力要求最低适合快速原型验证。缺点上下文长度有限制长期对话必然溢出。Token 成本随对话轮数线性增长。模型在超长上下文中容易丢失早期信息也就是“迷失在中间”问题。适合场景短会话工具、一次性分析任务、对历史没有依赖的问答。不适合做真正的长期记忆。3.2 方案二外部向量库 语义检索RAG 思路把对话内容切块、向量化后存入向量数据库。每次请求前用当前消息的向量去检索最相似的记忆片段拼进 Prompt。优点可以存储海量记忆片段。检索速度快可以处理百万级向量。是当前 LLM 应用里最成熟的记忆方案。缺点对“相关性”的判断依赖向量质量不同 embedding 模型差别明显。记忆之间的关系没有被建模比如“A 提到的项目 B”这种关联。新信息容易覆盖旧信息缺乏冲突处理机制。适合场景知识库问答、客服系统、企业内部资料搜索。这是目前最值得优先掌握的基础方案。3.3 方案三知识图谱记忆将记忆抽取为实体和关系存储在图数据库中检索时沿着关系路径获取上下文。优点能建模复杂关系支持多跳推理。对实体记忆的准确率高不容易被语义相似度误导。缺点构建图谱需要额外的信息抽取流程。动态更新图结构成本较高。适合实体强相关的场景不适合自由形式的文本记忆。适合场景人物关系图谱、资产管理、多维度的业务知识库。这是长期记忆中的进阶玩法。3.4 方案四分层记忆架构借鉴人类记忆模型将记忆分成工作记忆、短期记忆、长期记忆三个层级配合不同的存储和检索策略。这是目前社区讨论最多、也是 Hacker News 那个项目在尝试的核心方向。典型的分层策略工作记忆当前会话的最近几轮对话原文直接放上下文。短期记忆当前会话的历史摘要每 N 轮生成一次摘要。长期记忆跨会话的关键事实和偏好从对话中抽取后存入数据库。检索时先看工作记忆再看短期摘要最后从长期记忆中检索相关事实组合成最终 Prompt。优点兼顾对话连续性和长期知识。Token 成本可控。更接近真实产品需要的记忆体验。缺点架构复杂度高。需要设计摘要触发策略、记忆抽取规则和冲突解决机制。每个环节都可能出错需要系统性的测试。适合场景AI 助手、个人知识库、Agent 类产品。这也是我推荐你去实验的方向。3.5 方案五LLM Wiki 与外部知识管理最近 Andrej Karpathy 提到的 LLM Wiki 范式也值得关注。它本质上不是给模型做记忆而是把 LLM 当作知识库的过滤和整理工具让用户在自己维护的、结构良好的文本文件比如 Obsidian 笔记中管理记忆然后通过 RAG 或特定检索机制供模型使用。这个方案的好处是记忆是显式的、可审查的、可修正的。模型不需要自己判断什么值得记用户自己决定什么重要。它适合个人知识管理和可解释性要求高的场景但不太适合完全自动化的 Agent 对话记忆。不过它给长期记忆架构提供了一个很好的交互范式记忆应该是可读的而不是黑盒向量。3.6 各方案对比总结维度全量拼接向量库 RAG知识图谱分层记忆LLM Wiki实现成本最低中等高较高中等记忆容量很低很高高较高高关系建模无弱强中中检索精度无检索逻辑依赖向量质量高中高中典型场景原型验证知识库问答实体关系复杂场景Agent / 助手个人知识管理从趋势来看纯靠上下文窗口的时代已经过去了向量库是目前的基本盘分层架构是进阶方向。如果你的项目需要长期服务同一个用户并且用户有持续的个性化需求建议直接把分层记忆作为目标架构方向。4. 长期记忆架构实验设计与环境准备接下来我们把上面讨论的东西落到代码上。这里要做一个最小可行的分层记忆实验目标很简单搭建一个带长期记忆的对话系统用户重启会话后模型仍然记得之前交代的事实和偏好。4.1 实验目标支持跨会话记忆重启程序后依然能识别用户。支持基础偏好记忆比如“回复用中文”、“称呼我为老张”。使用向量检索做语义级别的记忆召回。通过摘要机制控制短期记忆的 Token 占用。4.2 环境准备为了不让实验过度复杂我们选一套尽量轻量的技术栈Python 3.10。FastAPI 提供对话接口。SQLite JSON 存储结构化记忆。sentence-transformers 作为本地 embedding 模型。向量检索用内存检索或 sqlite-vec不依赖重型向量数据库。LLM 接口统一封装实验阶段可以接 OpenAI 兼容接口也可以接本地模型。在开始之前先安装依赖。pip install fastapi uvicorn pydantic openai sentence-transformers numpy注意sentence-transformers首次运行会下载模型网络环境不稳定时建议手动下载并放到本地目录。本文代码里可以传入本地模型路径。如果你要在生产环境使用向量数据库可以换成 Chroma、Milvus 或 Qdrant。本实验先把架构跑通不要过早引入重组件。4.3 项目目录结构llm-long-term-memory/ ├── main.py # FastAPI 入口 ├── memory/ │ ├── __init__.py │ ├── store.py # 记忆存储层 │ ├── extractor.py # 记忆抽取和摘要生成 │ ├── retriever.py # 记忆检索 │ └── prompt_builder.py # Prompt 组装 ├── config.py # 配置项 └── data/ └── user_memory.db # SQLite 数据库运行时自动生成这个结构本身就是对架构的一种体现存储、抽取、检索、注入是四个独立的模块便于后续单独替换。5. 长期记忆架构核心模块实现5.1 记忆存储层 store.py先定义长期记忆的数据结构。这里把记忆分为两类user_profile用户显式或隐含提供的事实和偏好使用 JSON 存储。episodic_memory情景记忆即从历史对话中抽取的事件或知识点使用向量 SQLite 存储。代码如下# 文件路径memory/store.py import json import sqlite3 from typing import Optional class MemoryStore: def __init__(self, db_path: str data/user_memory.db): self.db_path db_path self.conn sqlite3.connect(db_path, check_same_threadFalse) self._init_tables() def _init_tables(self): cursor self.conn.cursor() cursor.execute( CREATE TABLE IF NOT EXISTS user_profile ( user_id TEXT PRIMARY KEY, profile_json TEXT NOT NULL, updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP ) ) cursor.execute( CREATE TABLE IF NOT EXISTS episodic_memory ( id INTEGER PRIMARY KEY AUTOINCREMENT, user_id TEXT NOT NULL, content TEXT NOT NULL, embedding BLOB, created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP ) ) self.conn.commit() def upsert_profile(self, user_id: str, profile: dict): cursor self.conn.cursor() cursor.execute( INSERT INTO user_profile (user_id, profile_json) VALUES (?, ?) ON CONFLICT(user_id) DO UPDATE SET profile_json excluded.profile_json, updated_at CURRENT_TIMESTAMP, (user_id, json.dumps(profile, ensure_asciiFalse)) ) self.conn.commit() def get_profile(self, user_id: str) - Optional[dict]: cursor self.conn.cursor() cursor.execute(SELECT profile_json FROM user_profile WHERE user_id ?, (user_id,)) row cursor.fetchone() if row: return json.loads(row[0]) return None def add_episodic_memory(self, user_id: str, content: str, embedding): cursor self.conn.cursor() cursor.execute( INSERT INTO episodic_memory (user_id, content, embedding) VALUES (?, ?, ?), (user_id, content, embedding) ) self.conn.commit() def get_episodic_memories(self, user_id: str, limit: int 50): cursor self.conn.cursor() cursor.execute( SELECT id, content FROM episodic_memory WHERE user_id ? ORDER BY id DESC LIMIT ?, (user_id, limit) ) return cursor.fetchall()这里说明两个设计选择第一user_profile使用合并更新的方式而不是每次覆盖。这样设计的好处是不同轮次抽取到的不同信息片段可以合并不会因为一次新写入就把旧的偏好丢了。第二episodic_memory用 BLOB 存储 embedding 向量虽然简单但对实验是够用的。实际生产应该把向量和业务数据分开避免 SQLite 的写入锁成为瓶颈。5.2 记忆抽取与摘要生成 extractor.py在每轮对话结束后我们需要判断这段对话里有没有值得长期保存的信息。这里引入一个轻量策略用第二个 LLM 调用来做信息抽取和摘要。需要说明这会产生额外 Token 消耗。工程实践中可以只对用户消息做抽取或者按一定概率抽样处理。但对于实验阶段全量抽取可以帮助我们理解记忆系统的行为。# 文件路径memory/extractor.py import json from typing import Dict, List class MemoryExtractor: def __init__(self, llm_client): self.llm_client llm_client def extract(self, user_message: str, assistant_message: str) - Dict: 从一轮对话中抽取可长期保存的记忆。 返回结构 { profile_updates: {name: 老张, language: 中文}, events: [用户正在开发电商数据分析平台] } prompt f 你是一个记忆抽取助手。根据下面的人类用户与 AI 助手的对话抽取值得跨会话长期保存的信息。 要求 1. 抽取用户明确陈述的个人事实姓名、职业、偏好等。 2. 抽取用户当前正在进行的项目或任务。 3. 忽略寒暄和与任务无关的闲聊。 4. 只输出 JSON不要输出解释。 用户消息{user_message} 助手消息{assistant_message} JSON 格式 {{ profile_updates: {{}}, events: [] }} response self.llm_client.chat.completions.create( modelself.llm_client.model, messages[{role: user, content: prompt}] ) content response.choices[0].message.content # 鲁棒性处理去掉可能的 json 包裹 content content.strip().removeprefix(json).removesuffix().strip() return json.loads(content) def generate_session_summary(self, messages: List[Dict]) - str: 把最近的对话压缩成一段摘要用于短期记忆。 conversation_text \n.join([ f{msg[role]}: {msg[content]} for msg in messages ]) prompt f 请把下面的对话压缩成 100 字以内的摘要保留关键主题、决策和事实。 对话内容 {conversation_text} response self.llm_client.chat.completions.create( modelself.llm_client.model, messages[{role: user, content: prompt}] ) return response.choices[0].message.content这个模块设计成“可插拔”的形式很关键。不同的业务场景对记忆抽取的要求完全不同比如客服系统可能需要抽取订单号写作助手可能需要抽取风格偏好。把这个逻辑独立成一个类后续就可以根据业务定制 Prompt 或替换成微调的小模型。5.3 记忆检索 retriever.py检索模块的核心任务是给定当前用户输入找出长期记忆库中最相关的记录。这里采用向量相似度检索。# 文件路径memory/retriever.py import numpy as np class MemoryRetriever: def __init__(self, store, embedder): self.store store self.embedder embedder def retrieve(self, user_id: str, query: str, top_k: int 3) - list: 从 episodic_memory 中检索语义最相关的记忆片段。 同时返回用户 profile作为最基础的长期事实。 query_vec self.embedder.encode(query) memories self.store.get_episodic_memories(user_id) scored [] for mem_id, content in memories: mem_vec np.frombuffer(self.store.get_embedding(mem_id), dtypenp.float32) similarity np.dot(query_vec, mem_vec) / ( np.linalg.norm(query_vec) * np.linalg.norm(mem_vec) 1e-8 ) scored.append((similarity, mem_id, content)) scored.sort(reverseTrue, keylambda x: x[0]) return scored[:top_k]这里有两个细节需要注意。第一get_embedding方法在上面的store.py里没有写进去但实现很简单就是按 id 查表。自己补上即可。第二用np.frombuffer恢复向量时必须保证写入和读取时的 dtype 一致。建议在写入时统一转成 float32 字节串。这个细节如果写错检索结果会完全不对而且很难排查。我后面会专门在常见问题里再强调一次。5.4 Prompt 组装与 FastAPI 接口最后把记忆注入到对话上下文中。这里有一个原则记忆信息要放在指令和用户当前消息之间作为“背景材料”提供给模型。# 文件路径memory/prompt_builder.py from typing import Dict class PromptBuilder: staticmethod def build(system_prompt: str, profile: Dict, memories: list, current_query: str) - list: context_parts [] if profile: profile_text 用户已知信息\n \n.join( [f- {key}: {value} for key, value in profile.items()] ) context_parts.append(profile_text) if memories: memory_text 用户历史相关记忆\n \n.join( [f- {content} for _, _, content in memories] ) context_parts.append(memory_text) context \n\n.join(context_parts) if context: context 以下是关于用户的背景信息请在回答时参考\n context messages [{role: system, content: system_prompt}] if context: messages.append({role: system, content: context}) messages.append({role: user, content: current_query}) return messages在主程序中把上面几个模块串起来。# 文件路径main.py import os import uuid from fastapi import FastAPI from pydantic import BaseModel from sentence_transformers import SentenceTransformer from memory.store import MemoryStore from memory.extractor import MemoryExtractor from memory.retriever import MemoryRetriever from memory.prompt_builder import PromptBuilder # 这里需要替换为你自己的 LLM Client 配置 from openai import OpenAI app FastAPI() # 初始化组件 store MemoryStore(data/user_memory.db) embedder SentenceTransformer(paraphrase-multilingual-MiniLM-L12-v2) llm_client OpenAI( api_keyos.getenv(LLM_API_KEY, your-api-key), base_urlos.getenv(LLM_BASE_URL, https://api.openai.com/v1) ) llm_client.model os.getenv(LLM_MODEL, gpt-4o-mini) extractor MemoryExtractor(llm_client) retriever MemoryRetriever(store, embedder) prompt_builder PromptBuilder() SYSTEM_PROMPT 你是一个有长期记忆的 AI 助手善于利用用户背景信息回答问题。 class ChatRequest(BaseModel): user_id: str message: str def update_memory(user_id: str, user_message: str, assistant_message: str): 每轮对话后抽取并保存长期记忆。 extracted extractor.extract(user_message, assistant_message) if extracted.get(profile_updates): current_profile store.get_profile(user_id) or {} current_profile.update(extracted[profile_updates]) store.upsert_profile(user_id, current_profile) for event in extracted.get(events, []): embedding embedder.encode(event).tobytes() store.add_episodic_memory(user_id, event, embedding) app.post(/chat) def chat(req: ChatRequest): # 1. 检索长期记忆 profile store.get_profile(req.user_id) or {} memories retriever.retrieve(req.user_id, req.message, top_k3) # 2. 组装 Prompt messages prompt_builder.build(SYSTEM_PROMPT, profile, memories, req.message) # 3. 调用 LLM response llm_client.chat.completions.create( modelllm_client.model, messagesmessages, temperature0.7 ) assistant_message response.choices[0].message.content # 4. 异步或同步更新记忆实验阶段先同步 update_memory(req.user_id, req.message, assistant_message) return {reply: assistant_message}到这里一个最小可运行的长期记忆架构就成型了。你可以从对话接口开始测试观察模型是否能记住跨会话信息。6. 运行结果与效果验证启动服务uvicorn main:app --host 0.0.0.0 --port 8000然后打开另一个终端模拟用户第一轮对话。curl -X POST http://localhost:8000/chat \ -H Content-Type: application/json \ -d {user_id: user_001, message: 你好我是老张我在做一个电商数据分析平台以后请用中文和我交流。}模型会返回一个普通问候。但这轮对话结束后记忆系统已经做了两件事把“用户叫老张”“使用中文交流”“正在做电商数据分析平台”抽取并写入 user_profile。把“用户正在开发电商数据分析平台”作为事件写入 episodic_memory。现在重启服务模拟隔天用户重新发起对话curl -X POST http://localhost:8000/chat \ -H Content-Type: application/json \ -d {user_id: user_001, message: 我上次说的那个项目你觉得第一步应该做什么}如果架构生效模型回复中应该能体现“了解你正在做电商数据分析平台”这个背景而不是一脸茫然地说“我不记得你之前的项目”。这里有一个验证技巧在开发阶段可以在返回结果里临时加一个调试字段把“实际注入 Prompt 的记忆内容”打出来人工确认检索结果是否合理。而不是直接看模型输出因为模型输出经过了生成模型有时候它记得但不是因为检索正确有时候检索正确但模型没用上。调试字段能帮你区分问题出在检索端还是生成端。7. 常见问题与排查思路问题现象可能原因排查方式解决方案向量检索出来结果完全不相关写入和读取的向量 dtype 不一致检查tobytes()和np.frombuffer是否都使用 float32统一用np.float32建议封装一个 serialize/deserialize 方法抽取模块报 JSON 解析错误LLM 返回了json包裹或额外的解释文字打印原始返回内容在解析前做字符串清理或改用 JSON 修复库模型始终不记得用户偏好抽取模块没有正确写入 profile查看data/user_memory.db中的user_profile表手工插入一条记录验证检索和注入链路记忆污染旧信息覆盖新信息profile_updates合并逻辑写错检查upsert_profile的 update 逻辑改为合并 dict 而不是整体覆盖Token 消耗暴涨每轮对话后都调用抽取和摘要模型查看日志调用次数增加抽取频率策略如每 N 轮抽取一次长期运行后 SQLite 越来越大情景记忆表无清理机制查看表行数增加定期归档或遗忘策略排错优先级建议先看数据库里有没有正确的记忆数据再看检索返回是否相关最后才看模型回答质量。很多人在记忆系统上花了很多时间结果问题出在模型生成 Prompt 时把记忆放错了位置或者系统提示词本身强调不够。8. 最佳实践与工程建议8.1 记忆写入采用“异步化 时间窗口”同步地每轮对话都做抽取很影响用户体验尤其在最前面加了个摘要调用接口延迟可能多出 1 到 3 秒。实际工程里更推荐的做法是先把对话消息写入消息队列或直接落库记忆抽取放到后台任务异步执行。用户的对话速度不应该被记忆写入阻塞。同时可以引入时间窗口策略比如同一用户 5 分钟内的对话只聚合抽一次避免几轮连续消息产生大量重复记忆。8.2 记忆检索用“多路召回 重排序”向量检索虽然好用但只有一个召回通道容易被无关信息带偏。生产级别建议至少同时使用向量检索拿下语义相似的历史事件。关键词/全文检索拿到包含用户 id、产品名等硬性信息的记忆。profile 热点字段始终注入与用户身份强相关的信息。召回后可以设计一个简单的重排规则或者直接把多条候选摘要拼成一小段文本交给一个轻量的 LLM 调用判断相关性。虽然多花一点 Token但效果明显更稳。8.3 明确“遗忘策略”是长期记忆的一部分长期记忆系统不可能只增不减。如果用户更正了之前的信息之前的记忆必须能覆盖。如果某个话题超过 90 天没有再次被检索就应该进入冷存储或删除。这里要特别关注一种情况用户明确表达了新偏好和历史偏好冲突。在写入新信息时要把冲突的旧信息标记为失效而不是同时提供给模型。否则模型会看到两个矛盾的事实输出反而更不稳定。8.4 安全与隐私边界长期记忆系统的危险性在于它会把用户的敏感信息长期保存。以下几点是底线对记忆数据做分类分级至少明确区分 PII个人身份信息和非 PII。支持用户主动查看、导出、删除自己的记忆数据。涉及删除时必须提供真实的物理删除能力而不是只标记不可见。只有在用户明确授权的情况下才能将记忆用于个性化服务。从技术实现上建议给记忆表增加retention_days字段由业务决定每条记忆的保留时长。定期任务清理过期数据避免数据库无限膨胀。8.5 可观测性是最容易被忽略的工程模块记忆系统是一个黑盒链路抽取、存储、检索、注入、生成每一环都可能出问题。生产环境必须做详细的日志记录至少包括每一轮抽取出了哪些信息。最终实际注入 Prompt 的记忆内容。检索命中了哪些记忆及相似度得分。模型实际使用的记忆占比可以用后续的人工评测打分。没有可观测性你就只能靠用户反馈来发现记忆系统坏了那时候损失已经发生了。8.6 与 Agent 架构结合时的额外建议在 Agent 系统中长期记忆不仅要保存用户事实还要保存任务状态。比如“这个项目已经进行到数据清洗阶段”这种程序性信息需要和纯粹的用户偏好分开存储。另外在 Agent 循环里记忆检索通常要触发两次第一次在 Agent 规划任务前获取背景第二次在 Agent 执行具体工具调用时获取该工具的历史使用方式。不要试图用一次检索覆盖所有场景。9. 总结与后续学习方向长期记忆不是一个独立组件而是一条涉及采集、存储、检索、注入、更新的完整工程链路。大部分人第一次尝试时会天然觉得“加个向量数据库就完事了”但真正上手以后才会发现记忆抽取的规则设计、记忆冲突的处理、记忆检索的精准度才是决定体验好坏的核心。本文从一个架构实验的视角把分层记忆架构拆解成可运行的代码并说明了每个模块要解决的具体问题。你可以直接把这套代码跑起来作为自己的实验底座然后逐步替换其中的模块把 sqlite-vec 替换成 Milvus 或 Qdrant。把固定抽取逻辑改成由任务目标驱动的动态抽取。增加长期记忆的遗忘和归档策略。接入真正的 Agent 框架把记忆从“对话背景”升级为“任务状态”。下一步建议去研究几个方向一是基于知识图谱的记忆增强它和向量检索是互补关系二是 LLM Wiki 这类显式知识管理范式它在个人知识库场景下价值很高三是记忆评测方法目前这个方向还没有统一的 benchmark但已经有不少团队在探索标准化方案。如果你想深入可以先在社区里关注相关实验项目用本文这套代码作为对比基线不断验证新方案的收益。长期记忆这件事值得每个做 LLM 应用的开发者认真做一次架构实验。它决定了你的产品是“一个聪明的接口”还是“一个懂你的助手”。