没有记忆的Agent本质上就是一个每次从零开始答题的“即用即弃”工具。你上一个问题里告诉它的偏好和结论它转头就忘下一个问题又重新推测。把这个场景放到工业级Agent里问题就不是“体验不好”这么简单了——客服Agent会重复追问用户已经给过的订单号数据分析Agent会忘记自己刚算出的中间结果多Agent协作时信息在节点之间断裂。我拆过几个头部大厂和开源生态里的Agent记忆方案也自己在项目里落地过一套轻量记忆系统这篇就把核心机制、架构思路和可复现代码一次性讲清楚。这个内容适合两类人一类是在做Agent应用开发、想解决“上下文断裂”问题的工程师另一类是刚接触Agent、想知道记忆系统到底怎么设计的初学者。读完你会明白大厂的记忆机制并不是什么黑科技本质上是把“短期会话”“长期事实”“业务状态”分层存储再配合检索和写入策略踩出来的工程方案。我会从零开始拆解这套机制然后给出一个可以直接上手的实现路径。1. 先说清楚Agent为什么必须要有自己的记忆1.1 没有记忆的Agent再聪明也像个“一次性外援”很多人一开始觉得大模型本身已经有上下文窗口把历史对话全部塞进去不就有记忆了吗确实GPT级别的模型上下文窗口现在动辄几百K看起来“记住”几十轮对话不是问题。但你真放到生产环境里试一次就会发现这条路根本走不通。首先是成本问题。一次对话里塞进去10万字的历史记录每次请求的Token开销直接翻几倍响应延迟也会显著上升。工业级Agent一天几十万次调用这个成本没有哪家公司扛得住。其次是效果问题模型对超长上下文的注意力会衰减真正重要的信息会被大量冗余内容淹没反而导致回答质量下降。我在实际测试里踩过这个坑把两周的对话记录全部塞进上下文结果Agent连用户最开始说的“不要推送营销信息”这种基础偏好都执行不好。所以大厂的做法非常简单粗暴记忆不能全放在上下文窗口里而是放到外部存储中按需、按相关性、按时效性去检索只把真正有用的那部分记忆注入到当前对话里。这个思路贯穿了所有成熟的Agent记忆方案包括开源项目里常见的Memory模块本质都是“外部化存储智能召回”。1.2 记忆不是“记住聊天记录”而是分层建模我刚接触记忆系统时犯过一个方向性错误把记忆等同于“把历史对话存下来再检索”。这个思路做出来的系统能用但非常粗糙。你试想一下如果用户两周前跟你说“我住浦东预算500万学区房优先”今天问你“推荐几个楼盘”理想情况下Agent应该直接调出这两周沉淀下来的核心需求而不是把两周前的对话原文翻出来再理解一遍。大厂记忆机制的共性设计是把记忆拆成了几个层次工作记忆Working Memory当前任务过程中产生的临时信息比如正在处理的数据、上一步计算出的中间结果任务结束就可以清掉。情景记忆Episodic Memory某次具体对话或任务的历史记录带有时间戳、场景标签用来回溯“当时发生了什么”。语义记忆Semantic Memory从历史对话中抽取出的事实、偏好、规则比如用户的需求约束、业务领域知识这种记忆是去场景化的长期保留。程序记忆Procedural MemoryAgent学会的工作流程、操作步骤比如“处理退款时需要先校验订单状态”通常以工作流或技能配置的形式存在。这个分层映射了人类认知记忆的分类方式也是工业级Agent记忆系统的设计底座。你在搭建自己的记忆系统时不用一上来就实现全部分层但至少要做对一件事把“临时对话”和“长期事实”区分开分别用不同的存储和生命周期策略去管理。我见过很多开发者把用户的长期偏好和昨天的闲聊记录放在同一个向量库里最后召回结果混乱不堪就是这么来的。1.3 大厂记忆机制的共性设计别被表象迷惑拆解大厂实现的时候你会发现各家叫法不同、模块划分不同但底层逻辑高度一致。某头部云厂商的Agent平台其记忆模块核心就是“变量存储数据库向量检索”三件套另一个主流Agent框架其长期记忆用的也是“摘要向量实体抽取”的组合。名词眼花缭乱但拆开看都逃不开这几个环节对话流经过信息抽取识别出值得记住的内容区分短期和长期。长期记忆经过向量化、结构化处理后写入对应存储。新对话产生时先做一次记忆查询把相关记忆拉出来拼进Prompt。存储层定期执行清理、合并、过期策略防止记忆无限膨胀。理解了这套共性逻辑之后不管你用什么框架、什么向量库都能搭建出适合自己的记忆系统。下面我就按这条主线把架构拆解和实操过程完整过一遍。2. 记忆系统架构拆解四层模型与写入/读取链路2.1 四层记忆模型短期会话、长期事实、业务状态、工作上下文我做记忆系统时最喜欢用的分层方式是参考认知科学又贴合工程实现的“四层模型”前面提到的情景记忆、语义记忆、程序记忆对应到工程上可以进一步提炼出四类存储职责。第一层短期会话记忆Short-term Session Memory。这是最接近“上下文窗口”的一层通常只在单次会话内有效。实现上可以做滑动窗口截取最近N轮对话或者用摘要模型把前面的内容压缩成一小段“对话小结”。我在项目里一般把原始消息存到消息表里同时维护一个动态摘要字段每轮对话结束后增量更新这样既保留细节又能在超长会话里控制Token消耗。第二层长期事实记忆Long-term Fact Memory。这个对应语义记忆是记忆系统里最核心、也最值得花精力设计的一层。用户/业务对象的名称、偏好、约束条件、历史结论都放这里。存储上我习惯用“结构化表格向量索引”双写结构化字段用来精确过滤比如用户ID、事实类型、时间范围向量索引用来语义召回比如用户说“预算500万”“学区房”这种自然语言描述。第三层业务状态记忆Business State Memory。这层容易被忽略但工业级Agent里非常重要。比如一个订单处理Agent它执行到“退款审批”这一步时当前状态是“等待财务确认”这笔钱是从哪个订单来的、用户在哪个环节卡住——这些状态如果丢了流程就断了。实现上通常用键值存储或数据库记录状态机快照而不是丢给大模型去“记住”。第四层工作上下文记忆Working Context Memory。这层解决多步推理中的临时数据传递问题。比如Agent在分析数据时先查了A表再查B表中间结果存在哪里如果每次都靠模型重新推理既慢又容易出错。工程上通常用Transaction ID或者执行上下文ID把中间变量存起来任务完成后清理。很多人在设计记忆系统时只重视第二层结果长尾场景里处处碰壁。我自己的项目吃过这个亏给Agent只加了长期向量记忆结果在处理一个需要跨三个流程节点的任务时中间状态全靠Prompt传递超过两轮就开始丢信息最后还是要补上状态层才真正跑通。2.2 写入链路从对话流到事实抽取与落库理解了分层之后下一个核心问题是记忆是怎么被写入的。这块是很多自建方案做得最糙的地方——直接把整段对话文本丢进向量库完事。这样做的结果就是召回时噪声极大信息密度极低。一个正规的写入链路应该长这样对话数据采集从消息总线或回调接口拿到用户与Agent的完整交互记录包括输入、输出、工具调用结果、时间戳。消息预处理过滤掉系统提示词、调试信息、无意义的“我明白了”这类话术把有效内容提取出来。事实抽取这一步可以用大模型做也可以先用规则做粗筛再用大模型精炼。抽取的目标是产出结构化的“记忆单元”比如“用户偏好回复简洁”“用户需求预算500万的浦东学区房”。我在生产项目里的做法是让大模型输出JSON格式的记忆候选只保留置信度高的字段。记忆分类把抽取出来的记忆单元按类型拆分——事实类去长期记忆对话摘要去短期层流程状态去业务层临时变量去工作上下文。向量化与双写长期事实类记忆生成Embedding向量写入向量库同时把原始结构化字段写入关系表摘要和状态走各自的存储。去重与合并如果用户今天说“预算500万”明天又说“预算提到700万”旧的记录要么标记过期要么和新的合并成一条避免记忆自相矛盾。这个链路每一步都有细节坑。我重点提醒两个第一个是事实抽取的置信度门槛如果模型从一句“我觉得可能”里抽出一个肯定事实那这个记忆就是污染源我们后面会专门讲怎么处理第二个是去重合并不能只按内容去重还要按用户和时间维度处理演进型事实否则记忆会越存越乱。2.3 读取链路按需召回而不是全量塞入写入做的再好如果读取时是无脑全量注入也白搭。读取链路的责任是在当前对话发生时快速判断“我需要哪些记忆”然后把最有价值的记忆拼装进Prompt。我实际用的读取流程是这样收到用户消息后先做一个意图预判判断当前对话涉及的记忆类型。比如用户问“我上周问过的那几套房子怎么样”时系统能识别出这是查询历史对话需要走情景记忆召回。然后做记忆召回不是只跑一个向量相似度而是多种检索方式并行。关键词精确匹配用来保证“订单号”“手机号”这类实体能100%命中向量语义检索用来发现“我喜欢安静”和“不要靠马路”这类语义关联结构化查询用来拉取用户画像、状态数据这些确定性信息。召回的候选记忆进入重排与裁剪按相关度、时效性、内容冲突度打分只保留Top N条保证注入Prompt的总篇幅在可控范围内。最后是Prompt组装把短期摘要、长期事实、业务状态按模板填入并明确告诉模型哪些是“当前对话信息”、哪些是“历史记忆”避免混为一谈。这一节的重点是读取永远是有损的、按需的。如果一次对话需要注入全部记忆才能工作说明你的记忆分层和索引设计有问题。一个健康的记忆召回率应该很高但每次真正注入Prompt的记忆量通常是有限的工业级Agent尤其要控制这个预算。3. 从零搭建一个可用的记忆系统实操记录3.1 技术选型与前置准备决定自己搭而不是直接用平台通常是两个原因一是数据要走私有化部署不能把用户对话送到第三方托管平台二是需要对记忆的存储结构和召回逻辑做深度定制。如果这两个需求你都没有说实话直接用成熟的Agent框架自带记忆模块或平台记忆能力更省事。但我下面的方案对理解原理和做深度定制非常有价值。技术栈方面我用了一套“轻量可替换”的组合关系数据库选SQLite做Demo生产环境可以换PostgreSQL。主要存用户表、会话表、事实表、状态表。向量库选Chromadb做本地测试足够生产环境可以换Milvus或qdrant。核心是做Embedding向量的存储和相似度检索。Embedding模型本地用开源的文本向量模型也可以接在线Embedding接口。要求是中文场景下语义区分度够用。大模型接口用于事实抽取、摘要生成、Prompt组装采用统一接口封装方便切换模型。实际操作中你会发现记忆系统本身不复杂复杂的是和LLM的配合。Embedding模型的选型很关键我在项目中对比过几款开源向量模型中文长文本的召回效果差异不小。如果你的业务中文占比高测试数据一定要用真实场景的对话不要用通用Benchmark自欺欺人。3.2 存储设计表结构、向量索引与元数据策略存储设计是整个记忆系统的地基。我先给出一套经过验证的关系表结构再讲向量库和元数据策略。用户表CREATE TABLE users ( user_id TEXT PRIMARY KEY, profile_json TEXT DEFAULT {}, created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP, updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP );会话表CREATE TABLE sessions ( session_id TEXT PRIMARY KEY, user_id TEXT NOT NULL, summary TEXT DEFAULT , start_time TIMESTAMP DEFAULT CURRENT_TIMESTAMP, last_active TIMESTAMP DEFAULT CURRENT_TIMESTAMP );长期事实表CREATE TABLE facts ( fact_id TEXT PRIMARY KEY, user_id TEXT NOT NULL, fact_type TEXT NOT NULL, -- preference, requirement, profile content TEXT NOT NULL, confidence REAL NOT NULL, -- 置信度低于阈值不写入 source_session_id TEXT, created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP, expires_at TIMESTAMP, -- 可配置过期时间 active_flg INTEGER DEFAULT 1 );业务状态表CREATE TABLE task_states ( task_id TEXT PRIMARY KEY, user_id TEXT NOT NULL, state_json TEXT NOT NULL, updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP );这套表结构看着简单但每个字段都不是随便设计的。fact_type是为了区分“这个记忆是用户偏好还是业务约束”召回时按类型过滤confidence是防污染闸门我只让高置信度的记忆进入长期存储source_session_id用来溯源记忆出问题时可以追踪到是哪次对话写入的。向量库这边我维护的文档结构大致是{ id: fact_xxxx, vector: [0.12, 0.35, ...], metadata: { user_id: user_123, fact_type: preference, content: 用户偏好回复简洁不需要展开背景, timestamp: 1710000000 } }元数据设计是很多人忽略却至关重要的地方。你向量库里的metadata决定了你能做多少种过滤召回。我只按content本身做向量检索再加上user_id和fact_type两个过滤条件召回精度就比裸向量检索高出非常多。因为不同用户的记忆场景天然不同硬塞到一个向量空间里互相比相似度是很荒谬的。3.3 核心代码实现写入与召回的完整闭环下面这一段是整套系统的核心代码我用一个MemoryManager类把写入和召回两个核心方法完整展示出来。为保持可读性我做了一些简化但主体逻辑直接可以照着修改使用。import json import sqlite3 import uuid from datetime import datetime, timedelta from typing import List, Dict, Optional class MemoryManager: def __init__(self, db_path: str, embed_fn, llm_extract_fn): # embed_fn: 文本 - embedding向量 # llm_extract_fn: 对话文本 - 结构化记忆候选列表 self.conn sqlite3.connect(db_path, check_same_threadFalse) self.embed_fn embed_fn self.llm_extract_fn llm_extract_fn self._init_tables() def _init_tables(self): cur self.conn.cursor() cur.execute( CREATE TABLE IF NOT EXISTS facts ( fact_id TEXT PRIMARY KEY, user_id TEXT NOT NULL, fact_type TEXT NOT NULL, content TEXT NOT NULL, confidence REAL NOT NULL, source_session_id TEXT, created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP, expires_at TIMESTAMP, active_flg INTEGER DEFAULT 1 ) ) self.conn.commit() def store_session_memory(self, user_id: str, session_id: str, conversation_text: str) - List[Dict]: 对话结束后调用抽取记忆、分类存储、双写 # Step 1: 让大模型抽取结构化记忆候选 memory_candidates self.llm_extract_fn(conversation_text) # Step 2: 过滤低置信度候选 high_confidence [c for c in memory_candidates if c.get(confidence, 0) 0.75] # Step 3: 对长期事实写入关系库 向量库 for cand in high_confidence: fact_id ffact_{uuid.uuid4().hex[:12]} fact_type cand.get(type, fact) content cand.get(content, ).strip() # 结构化字段落库 expires_at datetime.now() timedelta(dayscand.get(ttl_days, 180)) cur self.conn.cursor() cur.execute( INSERT OR IGNORE INTO facts (fact_id, user_id, fact_type, content, confidence, source_session_id, expires_at) VALUES (?, ?, ?, ?, ?, ?, ?), (fact_id, user_id, fact_type, content, cand.get(confidence, 0.0), session_id, expires_at) ) self.conn.commit() # 向量化写入向量库 emb self.embed_fn(content) vector_doc { id: fact_id, vector: emb, metadata: { user_id: user_id, fact_type: fact_type, content: content, timestamp: datetime.now().isoformat() } } self.vector_db.upsert([vector_doc]) return high_confidence def recall_memory(self, user_id: str, query_text: str, top_k: int 5, recall_hours: int 72) - List[Dict]: 查询时召回向量召回 精确召回 活跃过滤 memories [] # Step 1: 向量语义召回 query_emb self.embed_fn(query_text) vector_hits self.vector_db.query( query_emb, where{$and: [{user_id: user_id}, {active_flg: 1}]}, top_ktop_k ) for hit in vector_hits: memories.append({ content: hit[metadata][content], source: vector, score: hit[distance], fact_type: hit[metadata][fact_type] }) # Step 2: 近期对话精确召回关键词匹配 recent_facts self._get_recent_facts(user_id, recall_hours) keywords self._extract_keywords(query_text) for fact in recent_facts: if any(kw in fact[content] for kw in keywords): memories.append({ content: fact[content], source: exact, score: 1.0, fact_type: fact[fact_type] }) # Step 3: 按来源去重并排序 seen set() unique_memories [] for mem in sorted(memories, keylambda x: x[score], reverseTrue): if mem[content] not in seen: seen.add(mem[content]) unique_memories.append(mem) return unique_memories[:top_k * 2] def _get_recent_facts(self, user_id: str, hours: int) - List[Dict]: cur self.conn.cursor() cur.execute( SELECT content, fact_type FROM facts WHERE user_id ? AND active_flg 1 AND created_at datetime(now, ?), (user_id, f-{hours} hours) ) rows cur.fetchall() return [{content: r[0], fact_type: r[1]} for r in rows]几个细节我必须展开讲置信度阈值0.75是经验值。我试过0.9很多有价值的事实被滤掉了试过0.5一堆无意义的推测性内容都进库了。0.75在多数通用对话场景下是比较稳的平衡点但你如果跑特定领域比如医疗、法律需要单独调优。双写的一致性。关系库和向量库如果写入失败一个就会出现不一致。我代码里示例省略了事务处理生产环境我建议先写关系库再写向量库写完之后定时任务做对账修复。有些方案是先写向量库再异步同步关系库各有取舍但绝不能两边独立写不校验。召回时不只查向量。很多人把召回完全交给向量库但这会导致精确实体手机号、订单号、地址丢失。我在代码里补了一层近期事实的关键词精确匹配配合向量召回形成混合检索这个组合在生产里实测比单跑向量检索的命中率高出三成以上。3.4 参数调优与遗忘策略不能让记忆无限膨胀记忆系统最容易被忽视的是“遗忘”。很多自建系统跑了一个月向量库膨胀到海量数据每次召回的延迟和噪声都不可接受然后才手忙脚乱地加清理策略。我在项目里从第一天就固定了三类遗忘机制TTL过期。长期事实表里我设计了expires_at字段不同类型事实有不同的有效期。用户偏好类我一般设180天业务状态类短一些30天甚至更短临时对话摘要类就几个小时。到点就标记active_flg0不再参与召回。这个用SQL定时任务就能实现成本几乎为零。相似度合并。当新写入的事实和已有事实的向量距离非常近比如内容基本重复不新增记录而是更新原记录的时间戳避免同一信息反复存储。重要性分级。我的记忆单元里其实隐含了一个重要性字段代码示例里简化了高重要性的记忆即使过期也会被保留做分析低重要性的记忆到期直接清理。这个对系统长期健康非常关键因为有些核心事实只要用户不推翻就应该一直留着。参数调优方面我实际跑下来最敏感的通常是三个召回条数top_k、召回时间窗口recall_hours、注入Prompt的记忆总量。top_k太小漏信息太大灌噪声时间窗口太短记不住太长拉出过时信息。我的基准值是top_k5、recall_hours72但要按业务场景调。客服场景用户画像重要事实类召回占比加大数据分析场景工作上下文更重要要保证中间结果不丢。4. 常见问题与排查技巧实录4.1 记忆污染模型把猜测当成了事实记忆系统一旦上线最大的敌人就是“错误事实固化”。用户一次随口的假设被写进长期记忆之后每次对话都被当成真事引用。我遇到过最典型的一次用户说“我们明年可能会换系统”Agent就记住了“用户计划更换系统”后续对话里直接基于这个推测做方案弄得用户一头雾水。这个问题的根源在写入链路的事实抽取环节。模型在做抽取时倾向于把自然语言里的“可能性”表述转为确定性事实。我排查后加了三条防线第一提示词里明确要求模型区分“用户陈述事实”和“用户表达意图/假设”假设类内容只能进短期记忆。第二置信度阈值严格执行实测里低于阈值的候选直接丢弃。第三每次写入长期记忆前做一次去重冲突检测如果新记忆和已有的高置信度记忆矛盾比如时间线冲突宁可标记待确认也不盲目覆盖。4.2 召回不准与精确信息丢失第二种高频问题语义相关的记忆都能召回但精确信息在向量检索里丢了。比如用户问“我上次那个订单HS123456退了吗”向量检索很容易返回一堆和“订单”“退款”语义相似的记忆却找不到那个具体订单号。这个就是纯向量检索的通病。我的解决思路前面提到过一部分就是混合检索并重。现在更正式地归类一下排查路径先检查关键词抽取。确保代码里的实体识别能覆盖订单号、日期、数字这类特征一旦命中走精确匹配通道。再看向量检索的过滤条件。明确召回范围限定在同一个user_id下不然跨用户干扰特别严重。最后检查重排逻辑。我建议给精确命中一个较高的基础权重让它优先于语义相似度排序。生产环境里召回不准的问题大多数不是向量库不好而是你只用了向量检索而没有叠加其他通道。脑子里要绷着这根弦向量检索是召回的兜底不是唯一手段。4.3 并发写入与双写一致性在Demo阶段写入速度无所谓快照型写库就行。但在真实生产环境Agent的对话事件是并发到达的多个会话同时结束同时触发记忆写入就会遇到两个经典问题一是SQLite单机写锁导致延迟堆积二是向量库和关系库写入不同步出现“有的记忆有向量没结构、有的有结构没向量”。并发这块我建议生产环境做三件事关系库从SQLite切到PostgreSQL或者增加连接池和写入队列向量库可以使用支持高并发的方案写入操作异步化对话结束先把记忆写入消息队列由消费端把记忆送入抽取和落库环节不要在对话主链路里同步做记忆抽取。双写一致性没有银弹只能做补偿机制。我的做法是关系库写入成功后记一条日志向量库写入完成后回调更新状态跑一个定时对账任务扫描那些只出现在一边的记录做重写或修复。4.4 多用户隔离与权限控制如果你做的Agent要服务多个用户或企业内部多个租户记忆隔离就不是技术选型问题而是红线问题。我之前拆过一个框架发现它的记忆表设计里是全局唯一的不同业务域的记忆全搅在一起这要是线上跑了用户隐私直接泄露。正确做法从存储设计源头隔离所有记忆表强制带上user_id或tenant_id字段所有查询强制加过滤条件绝不能出现“查记忆时不带owner”的代码分支。向量库的metadata过滤条件必须和关系库的字段对齐索引设计要保证“带租户过滤的向量检索”性能不塌。召回结果在做Prompt注入之前还要再做一次权限校验确保即使检索出记忆也不会把不该当前角色看到的内容塞进上下文。5. 场景落地与后续扩展方向5.1 典型落地场景一客户服务Agent客服Agent是记忆系统收益最直观的场景。用户第一次来咨询时提到“我孩子上小学三年级住城东”下一次来问“推荐周末亲子活动”过去的记忆能让Agent直接从老用户角度回答而不是每次从“你是谁、住在哪、孩子多大了”开始问起。落地时要注意客服场景的记忆时效性要求很高。用户今天问“退货流程”下周再问“哪里看退货进度”中间隔着的订单状态、用户ID、货品信息都要能从业务层准确调出。所以客服场景我强烈建议把“短期会话摘要”和“长期画像”分开建不要让画像控制所有对话走向。5.2 典型落地场景二数据分析与多Agent协作数据分析场景对记忆的要求不一样它更看重工作上下文和状态机记忆。一个数据分析Agent在执行多步查询时中间结果如果不做外部缓存模型每步都要重新读一遍原始数据效率低且容易出错。我把中间结果写入task_states之后整条链路顺畅很多令牌消耗也降下来了。多Agent协作里还有一个额外维度就是Agent与Agent之间的记忆共享。我在项目里的做法是每个Agent保留自己的私有记忆协作时通过“共享记忆区”交换必要信息。某个主Agent汇总子Agent只提交结果和关键依据不把全部记忆暴露出去。这样既保证协作效率又控制信息泄露面。5.3 后续演进方向结构化记忆与记忆回滚最后聊聊这个系统还能怎么进化。我下一步计划做两件事第一把记忆抽取从“每轮对话后异步跑”改成“在线增量抽取”。现在的方案是对话结束后统一处理但在超长会话中前期的关键事实不能被后续对话引用体验有割裂感。改成增量抽取后关键事实产生时可以实时进入存储后续轮次立刻就能查拉到。第二实现记忆版本与回滚。目前记忆更新是覆盖式的旧版本直接过期。但如果新写入的记忆是错的或者用户反悔了历史版本就找不回来了。我计划把每次变更存为版本记录查询时默认拿最新版本需要时可以追溯旧版本。这对工业级系统的可审计性很重要也方便排查记忆被哪次对话污染。这套系统的完整代码我还在整理准备把它做成一个开箱即用的脚手架包括完整的提示词模板、表结构和Python实现等测试稳定后会放出来。你在搭自己系统时不用纠结于一上来就做得多全先把“分层存储、按需召回、遗忘机制”这三件事做对就足够支撑大多数生产场景了。