做智能体（Agent）的项目时间越长，我越觉得“记忆系统”是最容易被低估、却又最能拉开体验差距的一块。大家平时聊天都喜欢盯着模型参数、工具调用、提示词模板，真正让一个 Agent 从“答非所问”变得“像个靠谱的同事”的，往往是它能不能记住和你聊过什么、做过什么、承诺过什么。这篇文章就把 Agent 记忆系统这件事从头到尾拆开讲清楚，从为什么需要记忆、记忆分几种，到具体怎么选方案、怎么写代码、踩过哪些坑，最后放一份大模型学习礼包的组织清单，希望对正在做 Agent 或者准备入门的人有点用。
文章不会绕圈子，也不搞教科书式铺陈。你有任何编程基础都能看懂后面的代码示例，纯小白也能从前面几节先建立框架认知。我会用最直白的话解释概念，再给一套可以实际落地的最小实现思路。
1. 为什么 Agent 离不开一套记忆系统
很多刚接触大模型的人会困惑：模型明明很聪明，为什么聊天总是“聊了就忘”？这不是模型的智商问题，而是它的工作方式决定的。先把这个根因看清楚，后面所有设计逻辑都会顺理成章。
1.1 上下文窗口的“短命”本质
大模型对话的本质是你把所有消息拼成一段文本送进去，模型基于这段文本预测下一个字符，再逐步生成回复。这段文本能塞多少内容，就是所谓的上下文窗口。不同模型窗口大小差异很大，从几万 token 到上百万 token 的都有，但无论如何都有一个物理上限。
更要命的是，窗口不是为你一个人服务的。当消息总量超过上限，最早的消息会被挤出去，只剩靠后的内容。你可以把它类比成一个人在工作时能同时记住的信息量：你大概能记住一串 7 位电话号码，但很难一边听电话一边记住三天前那个客户的全部要求。 Agent 也一样，它只能看到当前窗口里还剩多少内容。
这就带来三个直接后果。第一，一个非常长的对话，聊到后面开头的信息已经丢了；第二，用户关掉页面、第二天再打开，对话历史如果没被保存，Agent 完全是失忆状态；第三，即便对话历史被存下来了，每次重新调用模型时也不可能把全部历史都塞进窗口，成本和时间都扛不住。所以记忆系统本质上解决的是“上下文窗口有限但对话和知识是持续增长”的矛盾。
1.2 没有记忆的 Agent 到底有多尴尬
我一开始也不太重视记忆，觉得模型聪明就够了。直到自己做了一个跨平台的数据整理助手，才发现没记忆的东西根本没法用。
当时有个用户在第一轮说“我账号登录不了，报错 302”，第二轮说“我试了三次了，还是不行”。这个“三次”指什么？如果 Agent 不记得前一句，它根本不知道用户在说试了三次什么。它会礼貌地再问一遍：“请问您试了什么三次？”这一瞬间用户就会觉得这东西是个弱智。
还有一类场景是偏好型记忆。用户对你说“回复风格帮我改得正式一点”，如果你没记住这个偏好，第二天再问它“帮我写个会议纪要”，它又恢复成闲聊风格。内容创作类的 Agent 出现这种问题尤其致命，用户会觉得自己在反复调教一个失忆的人。
更麻烦的是跨会话的长期任务。比如用户昨天说“每天早上九点把数据汇总发给我”，如果这套记忆没有落盘，第二天系统重启，Agent 就把这个定时任务忘得一干二净。我那个项目上线第一周就收到过类似反馈，用户的原话是“它昨天答应得好好的，今天就不认账了”。从那之后我才开始认真研究记忆系统。
2. 记忆系统的四层架构拆解
把“记忆”这个词摊开，它在不同场景下指的东西其实不一样。我习惯把 Agent 的记忆分成四层：工作记忆、情景记忆、语义记忆、程序记忆。设计记忆系统时先想清楚自己需要哪几层，而不是一上来就堆一个大而全的存储。
2.1 工作记忆：活在上下文窗口里的临时状态
工作记忆就是当前对话上下文窗口中的全部内容，包括系统提示词、最近几轮消息、工具返回的结果、模型正在生成的输出片段。它的特点是：容量小、易丢失、读取极快。你可以把它类比成你手上正拿着的一张便签纸，写着当前要做的事，但随时可能被扔掉。
对工作记忆的主要操作是“管理窗口”，而不是“存储”。常见的做法是滑动窗口，只保留最近 N 轮对话；或者做摘要压缩，把更早的对话先“浓缩”成几句话再放进窗口。很多框架在底层就是这么干的，只是对使用者透明而已。
工作记忆的设计目标是在“保留关键信息”和“节省 token 成本”之间取平衡。但要注意，它解决不了跨会话问题，因为会话一结束，这层记忆基本就归零了。所以单靠调大上下文窗口永远替代不了真正的记忆系统。
2.2 情景记忆：存“发生过什么”的长期档案
情景记忆记录的是事实：“昨天用户说了什么”“上次对话中我们确认了哪些结论”“这个项目最后选择了哪套方案”。它有点像人类对亲身经历过的场景的回忆，有明确的时间线，通常是按事件存储的。
实现层面，情景记忆就是写入数据库的日志型数据，每一条记录至少包含用户标识、会话标识、消息内容、时间戳、来源类型（用户发言还是模型总结）。它不一定需要向量化，因为很多场景只需要按时间和关键字查就行。真正关键的是要严格记录“谁、在什么时候、发生了什么事”，保持事实的原始性，别让模型在写入时就瞎总结。
情景记忆的价值在于支持多轮、跨会话的连续性。比如用户提到“上次你说那个方案有两个问题”，Agent 如果能从情景记忆里拉回上次的记录，就能接上话。我在实际项目里最爱用这层记忆，因为它简单、可靠、便宜。
2.3 语义记忆：抽象出来的知识库
语义记忆是比情景记忆更高一层的概括。同样是“用户喜欢看深入但通俗的内容”这样的结论，情景记忆可能存了十几次对话中用户分别表达了这个偏好，而语义记忆直接存一句话：“用户偏好深入+通俗。” 它不再绑定某一次事件，而是从多个事件中抽象出的规律和概念。
实现语义记忆通常需要做两件事：一是从历史对话中抽取关键概念（人物、偏好、结论、知识点），二是在写入前把文本向量化，方便按含义检索。检索时你问“这个用户对文章风格有什么要求”，它不会匹配“深入”和“通俗”这两个词，而是能通过语义相似度找到“他喜欢先看结论再看案例”这类表述相近的内容。
这层记忆的信息密度最高，但也最容易出错。因为抽取和概括的过程会产生信息损耗，甚至可能带进模型自己的演绎。所以在我的经验里，抽象出的语义记忆必须保留原始来源的引用，方便追溯和纠正。
2.4 程序记忆：会调用工具的“肌肉记忆”
程序记忆指的是技能的复用，比如“如何格式化一份报告”“如何调用搜索引擎接口”“遇到网络超时该重试还是放弃”。它对应人类“学会了骑车之后不用再想脚怎么踩”的肌肉记忆，Agent 每次执行任务时可以快速套用，不需要每次重新探索。
这层记忆常见的形式是工具描述、技能包、或一组预设的执行流程。可以在系统提示词里写规则，也可以在工具调用前动态挂载对应的技能片段。是否需要做成复杂的技能库，取决于你的 Agent 要执行的任务是否足够复杂。如果只是固定调用几个 API，把工具描述写好就够了；如果是做自动化研发助手，那就值得设计一套可插拔的技能库。
以上四层记忆并不是互相排斥，真实产品往往是多层叠加。我的习惯是先分清当前最痛的是哪一层，再决定投入多少精力。
| 记忆类型 | 典型存储介质 | 生命周期 | 典型用途 |
|---|---|---|---|
| 工作记忆 | 上下文窗口、短期缓存 | 会话内 | 保持话题连续性 |
| 情景记忆 | 关系型数据库、日志 | 长期 | 回顾历史事件和结论 |
| 语义记忆 | 向量索引、摘要库 | 长期 | 理解用户偏好、抽取知识 |
| 程序记忆 | 配置库、技能集 | 长期 | 复用工具调用流程 |
3. 五种实用记忆实现方案横向对比
设计记忆系统最怕一上来就选最复杂的方案。我先罗列五种我从项目里实际用过的路子，按从简单到复杂的顺序讲清楚它们的原理、适合谁、有什么坑。你可以先对照自己的需求，再决定用哪种，或者组合使用。
3.1 方案A：自动摘要压缩，最便宜的那条路
原理特别简单：当对话内容超过一定长度，调用模型把之前的对话“浓缩”成几百字的摘要，然后把它作为后续上下文的一部分。下一次对话开始前，先把这个摘要塞进系统提示词或者对话开头，再接新消息。
优势是几乎零基础设施，有模型调用能力就能做，非常适合刚起步的个人开发者。缺点是摘要一定会丢细节，而且如果多次摘要逐层压缩，信息损耗会累积。我试过连续压缩五轮以上时，原始结论都可能失真，所以它更适合短会话、轻量场景。
3.2 方案B：向量数据库语义检索，目前最普遍的做法
向量检索方案的技术路线是：把历史消息按段落切块，每块通过嵌入模型转成向量，存入向量索引；等到新提问进来，把问题也转成向量，在索引里找语义相近的 top-k 块，拼进上下文。
这套方案解决的是“记了但翻不出来”的问题。用户没有说出准确的关键词，只说了意思相近的话，也能召回对应记忆。它的坑在于工程细节多：块切多大、用哪个嵌入模型、相似度阈值设多少、要不要加时间衰减，全部都能影响效果。如果做不好，存了一堆垃圾，召回的结果还不如用关键字搜索。
3.3 方案C：结构化存储，写最明确的短期和长期记忆
这是最直白的一类：把“用户叫什么”“用户偏好什么风格”“上次确认的方案是什么”直接存成键值对或数据表记录。读取时不需要向量计算，直接按用户 ID 和记忆类型查数据库。
优点是精确、可控、便宜，写入和读取的逻辑都简单，非常容易做审计。缺点是无法覆盖模糊语义。比如用户说“感觉上次那个说法有点问题”，“有点问题”这种描述很难抽象成结构化字段。所以结构化存储通常和其他方案搭配，不单独撑起全部记忆。我的习惯是把“显式的、确定性的”记忆归这里，比如用户明确说“以后用正式风格”，这比让模型猜要好太多。
3.4 方案D：记忆Bank的“写入、检索、更新”循环
这种方式把每条记忆当成独立条目，每条记忆带时间戳、来源、置信度，并且有专门的写入策略、检索策略、更新策略。它借鉴了人类记忆的工作方式：先记下来，使用时按重要性提取，如果发现记忆之间冲突就做优先级改写。社区里很多产品级 Agent 框架都在往这个方向收敛。
优势是表达能力最强，适合长期、复杂的用户画像和项目状态。代价是工程复杂度和调用成本都高，需要设计记忆写入筛选、检索重排、周期整理等多个模块，对新手不友好。如果项目还没到需要精细化用户建模的阶段，不建议一上来就上这套。
3.5 方案E：图记忆与关系图谱，适合多跳关系场景
图记忆把实体（人、项目、文档、任务）作为节点，把实体之间的关系作为边，存入图数据库。当你需要回答“用户在哪个项目里提到了哪份文档，这份文档和谁共享过”这类涉及多跳关系的问题时，图结构比向量检索更有优势。
代价是需要做实体抽取和关系维护，每轮对话都可能需要更新图谱结构，维护成本是几个方案里最高的。就我接触的多数 Agent 项目来说，前期没必要上图谱，先做好前三层记忆就够了。
| 实现方案 | 核心原理 | 适用对象 | 开发成本 | 主要短板 |
|---|---|---|---|---|
| 自动摘要压缩 | 对话太长先浓缩再带入 | 会话级轻量场景 | 低 | 细节易丢失 |
| 向量数据库 | 语义相似度召回 | 历史知识、FAQ | 中 | 工程参数敏感 |
| 结构化存储 | 精确字段存取 | 偏好、用户资料 | 低 | 无法处理模糊语义 |
| 记忆Bank | 独立条目+置信度更新 | 产品级长期记忆 | 高 | 系统复杂度高 |
| 图记忆 | 实体关系多跳推理 | 复杂关系分析 | 很高 | 实体维护困难 |
4. 实操：从零搭一个最小可用的记忆系统
我不太喜欢只会讲理论。下面我把我个人验证过的最小记忆系统设计思路写出来，不依赖任何特定平台，你可以直接翻译成自己的代码。这个系统只做三件事：定义好记忆条目的结构、把关写入质量、提供混合检索。
4.1 数据模型设计：把记忆条目当成一等公民
先定义一个记忆条目的数据结构。不要偷懒只存一个“用户ID+聊天记录”，那样后面检索和更新都会很痛苦。每个记忆条目至少包含这些字段。
from dataclasses import dataclass, field from datetime import datetime from typing import Optional @dataclass class MemoryEntry: entry_id: str user_id: str session_id: str memory_type: str # working / episodic / semantic / procedural content: str source: str # user / assistant / tool created_at: datetime last_accessed_at: datetime access_count: int = 0 confidence: float = 0.8 # 写入时给一个初始置信度 ttl_days: Optional[int] = None metadata: dict = field(default_factory=dict) # 可附带话题标签、引用来源等为什么每个字段都有用？先看memory_type，它决定了这条记忆被检索时的权重和过期策略。语义型记忆可以活很久，工作型记忆可能当晚就过期。再看source，这告诉后续读取者这条内容到底是用户亲口说的，还是模型自己推测的。如果是模型推测的，置信度就要调低，检索时排序也要靠后。
access_count和last_accessed_at是实现“遗忘”机制的重要依据。一个从写入到现在都没被读过的记忆，大概率不是用户的刚需，一段时间后就可以考虑折旧或者压缩。这些字段配合起来，你才有能力做记忆的精细管理，而不是让记忆库变成一个只增不减的垃圾桶。
4.2 写入策略：不是所有内容都值得记住
我把“写入策略”看作记忆系统里最重要的一道闸门。很多人做了记忆库之后效果反而变差，原因就是什么都往里塞。一段日常寒暄、一个随口附和、一次临时玩笑，都被当成长期记忆写入，等真正检索时，无关内容的噪声会淹没关键信息。
我在项目中会先设置一个筛选函数，只允许三类内容通过：用户明确表达的偏好和事实；用户确认过的项目结论；对后续任务有影响的状态变化，比如“已发送”“等待回复”这类。代码逻辑可以写成下面这样。
def should_store(message_text: str, source: str) -> bool: if source != "user": return False # 1. 过短或纯打招呼的内容不值得存 if len(message_text.strip()) < 4: return False # 2. 包含明确偏好关键词才进入语义型记忆 preference_keywords = ["我喜欢", "我要", "以后请", "风格", "偏好", "更倾向于"] for kw in preference_keywords: if kw in message_text: return True # 3. 包含状态类关键词进入情景型记忆 state_keywords = ["已经完成", "决定用", "确认", "发送了", "更新了"] for kw in state_keywords: if kw in message_text: return True return False写完筛选逻辑之后，还要加一个轻量去重。每次写入前把新内容和已有的同类型记忆做一次相似度比较，如果相似度超过阈值，直接合并更新而不是新增一条。我通常会计算新内容和已有条目的语义相似度，阈值设在 0.85 左右。这个值不用特别精确，目的是把“用户今天又说了一遍喜欢简洁风格”这种重复输入合并掉，防止记忆库被同一条信息撑爆。
最后是总量控制。我给每条用户记忆设一个条数上限，超出后优先淘汰最久未被访问的记录。这个上限可以按业务定，一般一个用户长期记忆控制在几十条上下就足够覆盖日常需求了，再多反而是负担。
4.3 检索策略：混合检索再加时间衰减
理想的检索不是只靠向量相似度，而是混合召回。我会同时发起两路检索：一路是向量语义检索，用来模糊匹配“意思相近但用词不同”的记忆；另一路按重写后的关键词或结构化条件匹配，用来确保精确召回。比如用户说“上次那个正式风格的偏好”，可以提取“正式风格”做关键词查询，同时向量检索也能召回相关表述。
两路结果合并后，还要做重排。重排的权重我习惯按这个顺序来：置信度权重、时间衰减权重、访问频率权重。
时间衰减是特别容易被忽略的点。在我的系统里，越近的记忆权重越高，但又是连续衰减而不是断崖式。我用的指数衰减：分数乘以 exp(-λ * 相隔天数)，λ 根据业务调节。想让近期记忆更强势就调大 λ，想让长期记忆也有机会露脸就调小。你可以把这段逻辑封装成一个函数。
def retrieve_memory(user_id: str, query: str, top_k: int = 5) -> list[MemoryEntry]: semantic_results = vector_search(query, user_id, top_k * 2) keyword_results = keyword_search(query, user_id, top_k * 2) candidate_map = {} for entry in semantic_results + keyword_results: candidate_map[entry.entry_id] = entry now = datetime.utcnow() def score(entry: MemoryEntry) -> float: time_factor = 0.7 ** max((now - entry.last_accessed_at).days, 0) access_factor = min(entry.access_count / 20, 1.0) return entry.confidence * (0.6 * time_factor + 0.4 * access_factor) ranked = sorted(candidate_map.values(), key=score, reverse=True) # 更新访问次数，这里只增加 1 次 for entry in ranked[:top_k]: entry.access_count += 1 return ranked[:top_k]这里有一个很值得说的细节：检索之后要更新access_count。这样你才能知道哪些记忆是真正高频有用的，哪些只能躺在角落里积灰。下次做整理或者剪枝时，这个字段会帮你做非常理性的决策。
4.4 遗忘与合并：控制记忆膨胀的止损机制
记忆系统必须要有“忘掉”的能力。很多开发者只考虑“存”，不考虑“删”，结果就是记忆库无限膨胀，检索越来越慢，噪声越来越大。我把记忆整理设计成一个每天执行一次的任务，主要做两件事。
第一，合并同类项。把同一用户下相似度很高的多条语义记忆找出来，合并成一条更概括的记忆。合并时可以直接调用模型生成摘要，但要注意保留原始条目的 ID 作为引用来源，免得以后追溯时找不到依据。
第二，过期清理。对设置了 ttl 的条目，超过有效期直接删除；对没有 ttl 的条目，如果访问次数是零且创建时间超过 N 天，就降级为摘要条目，不再单独参与检索。这个操作像是在给记忆做“磨皮”，让记忆库始终保持精简。
def consolidate(user_id: str, model_client): all_entries = load_active_entries(user_id) cluster_similar_entries(all_entries, threshold=0.88) for cluster in clusters: merged = model_client.summarize([e.content for e in cluster]) write_entry( user_id=user_id, memory_type="semantic", content=merged, source="system_merge", confidence=0.7, metadata={"merged_from": [e.entry_id for e in cluster]} ) delete_entries([e.entry_id for e in cluster])这段代码只是一个示意，但它勾勒出了合并的核心流程。写完之后你会明显发现检索质量变好，因为留下来的都是真正经过筛选和提炼的记忆，而不是原始的垃圾堆积。我的判断标准是：如果记忆系统在一个月不维护的情况下还能保持高质量，那它的设计才算及格。
5. 常见问题与排查技巧实录
这套系统运行了一段时间之后，陆陆续续会遇到一些典型问题。我把自己踩过的一些坑整理一下，希望能帮你少走弯路。
5.1 问题一：召回不准，记了却找不到
现象是明明记忆库里存了用户偏好，但提问时就是召不回相关内容。我先查的不是向量检索本身，而是原始文本切块方式。如果一块文本太长，向量化后相当于“高糊图片”，语义丢失严重。切块大小应该根据记忆粒度来定，偏好类的短句子可以直接一条一块，长对话先按段落切，再按语义边界合并。
第二个要查的是相似度阈值。如果阈值设得太高，只有高度重叠才召回，那语义检索的优势就没了。我会对每次检索结果做日志记录，统计返回结果的命中率，动态调整阈值。这个方法笨，但很有效。
还有一个很容易被忽略的点是时间衰减过猛。把 λ 调太大，老一点但仍有效的重要记忆永远排不上，用户就会以为系统“选择性失忆”。所以每次调参都要回到真实对话里去验证，不要只看测试集指标。
5.2 问题二：记忆污染，旧的错误信息反复出现
记忆系统最吓人的问题不是忘事，而是记住了错的东西。用户随口说“我其实不喜欢蓝色”，第二天又说了“蓝色还行”，系统如果两句话都存下来，检索时会同时读出一条正倾向和一条反倾向，模型思绪就会摇摆。
我的处理是在写入前增加一个置信度评估。用户明确声明且语气稳定，置信度给高；开玩笑的语气，置信度给低。检索时低置信度记忆直接过滤掉，除非其他权重特别高否则不参与候选。另外要给用户一个“反馈纠错”的入口，允许用户说“这点不对”，系统定位到对应记忆条目直接修订或删除。看起来是个小动作，但对 Agent 的信任度提升非常大。
信源优先级同样重要。我总会给用户直接说的内容高于模型推测内容的权重，因为模型推测一定会带有主观演绎。一旦发现模型生成的记忆与实际事实矛盾，直接以用户消息为准做覆盖。
5.3 问题三：Token 成本与存储成本失控
记忆系统本质上是把“模型记忆力差”的成本转嫁到了存储和检索上。如果每轮请求都把所有检索结果拼进上下文，token 成本很快就会失控。我后来加了两个机制来缓解。
第一个是分层摘要。平时请求只带高置信度的短期记忆摘要；只有特定场景，比如用户主动追问历史细节，才触发深度检索，把详细信息拉入上下文。第二个是冷热分离：把访问频率高的记忆放到快速缓存里，低频冷数据放到普通存储。这样既保证响应速度，又让日常请求 keep 在较小的 token 预算内。
5.4 问题四：多会话隔离与访问权限混乱
在多用户场景下，最不可接受的问题是 A 用户的记忆被 B 用户的对话触发。这类问题通常出在查询时漏加了用户过滤条件。每个记忆条目必须有明确的命名空间，比如user_id加上应用标识app_id组成复合主键；所有查询接口强制要求带命名空间参数，在代码层面就杜绝串数据。
除此之外，我给每个会话也加了session_id。这样可以区分“这个用户跨会话长期偏好”和“这次会话临时状态”。工作型记忆按会话隔离，语义型记忆按用户聚合，互不混淆。这个设计早期就要做，否则上线后要返工迁移数据，那个滋味我试过，非常难受。
| 问题现象 | 可能原因 | 排查方向 | 推荐解决 |
|---|---|---|---|
| 相关记忆召回不上 | 切块过大、阈值过高、衰减过猛 | 检查存储粒度、检索日志 | 调整切块、动态阈值 |
| 错误记忆反复生效 | 写入太宽松、信源未分级 | 检查写入筛选、置信度 | 分级置信度、提供纠错 |
| 成本快速上升 | 每轮都深度检索 | 检查提示词构造 | 分层摘要、冷热分离 |
| 用户之间串数据 | 查询缺少过滤条件 | 检查检索接口 | 命名空间强制隔离 |
6. 大模型学习礼包：小白和程序员各自的进阶路线
标题里说了要附一份大模型学习礼包，我这里不准备吊人胃口，直接把礼包的组织方式写出来。它不会是一个单一的文档，而是一套按角色拆好的学习路径，你做 Agent 开发时能对照着查缺补漏。
6.1 小白入门路线图：从提示词走到一个小项目
如果你完全没有技术背景，先不要碰记忆系统底层的索引和算法。第一步是把提示词玩明白，搞懂系统提示、用户消息、历史消息三者怎么组合，输出质量就会有很大差异。第二步是理解“上下文窗口”这个概念，你可以手动把一段历史摘要复制到下一轮 prompt 里，亲自感受它如何影响模型回复。
第三步是找一个封装程度比较高的 Agent 开发环境，先不管底层原理，做一个“能记住名字和偏好”的聊天机器人。这一阶段的目标不是掌握每个技术点，而是跑通“输入、处理、记忆、回复”的完整链路。最后再回头学“记忆要存到哪儿”的问题，你会发现前面的抽象概念全都有了落点。
6.2 程序员进阶路线图：从检索系统走向可靠记忆
有工程经验的开发者可以直接从信息检索基础切入，重点学习文本向量化和相似度计算的基本原理，同时掌握一个关系型数据库和一个日志型存储的用法，这是把记忆做成工程化组件的地基。
接下来要研究的是记忆的评估指标，这是我特别想强调的。很多人把记忆系统做上线就结束了，但记忆质量必须用数据说话。我常用四个指标：命中率，即应该被召回的条目有没有被召回；正确率，即召回的条目是不是用户需要的；新鲜度，即当前回答是否引用了足够新的信息；单位成本，即每次召回和写入花了多少 token。把这四个指标拉起来，你才知道一个记忆系统到底有没有做好。
最后一个建议是拿一个真实的业务场景反复做对照实验。比如“会话摘要应该在哪一轮触发”“语义记忆应该存几条上限”“时间衰减系数该设多少”，这些参数没有标准答案，只能靠记录实验、复盘结果来逐步逼近最优解。这个过程中你会慢慢形成自己的判断体系，比任何现成的框架文档都更有价值。
最后说几句实在话
现在做 Agent 项目，技术门槛不是最高的门槛，反而是很多基础工程问题最能消磨人。记忆系统看上去只是加一个数据库、接一次检索，真正落地时才会发现它的复杂度全部埋在写入筛选和整理策略里。我在实际项目中最大的体会是：先用最简单的方式跑通，再一步步加重。你现在从摘要压缩开始做，遇到真实的召回问题时再引入向量检索，等积累了一定数据量再考虑记忆Bank那套精细化玩法，这条路最稳妥。
如果早点把记忆的写入规则和数据模型设计想清楚，后面的返工会少很多。希望这篇文章能帮你把 Agent 记忆系统从“玄学”变成“工程”，也欢迎你按自己的场景去调整这些策略，做成更适合自己业务的样子。
