企业官网建设流程全解析

搞 Agent 开发的人，迟早都会撞上 Memory 管理这堵墙。不管你是在用 LangGraph 搭多智能体协作，还是用 Dify、Coze 这类可视化平台拖流程，只要 Agent 需要跨轮对话、跨会话记住用户偏好，或者要从一大堆历史记录里把关键信息捞回来，就绕不开三个问题：内存里到底怎么存、磁盘上该怎么落、上下文塞爆了又怎么办。这三个问题，正好对应标题里的三个关键词——内存记忆、文件持久化、上下文截断，它们共同构成了一套 Agent 记忆系统最核心的骨架。

这篇文章不只是讲概念，还会带你从零动手实现一套可运行的记忆管理方案。我默认读者已经跑通过一个最简单的 Agent 调用，懂一点 Python 基础，但还没系统梳理过"记忆"这块。文章会先讲清楚记忆系统为什么存在、由哪几层组成，再分别深入内存记忆、文件持久化、上下文截断三个模块，每部分都配有可以直接抄作业的代码和踩坑记录，最后整理一份高频问题排查表。如果你正在做 Agent 开发，或者准备从 Prompt 工程师往 Agent 工程师方向走，这篇内容应该能帮你省下不少试错时间。

1. 整体设计：Agent 记忆系统要解决的本质问题

1.1 先搞懂一个基础问题：LLM 为什么天生没有记忆

要说清楚 Agent Memory 是怎么设计的，得先承认一个事实：现在的 LLM 本质上是一个无状态的函数。你输入一段文本，它输出一段文本，它不会因为你上一轮输入过某个问题，就天然记得这一轮该怎么接。网上有个特别贴切的类比——你每次调用模型，都相当于把一个刚从睡梦中叫醒的行业专家请到面前，你跟他说"上次聊到哪儿了"，他一脸茫然，因为他根本不记得上次的事。

这不是模型的缺陷，而是它的设计使然。Transformer 架构的推理过程是独立的一次性计算，模型参数里确实编码了大量世界知识，但对话上下文不包含在参数里，只包含在你每次请求时发给它的输入文本中。所以要让 Agent"有记忆"，本质上是我们在外部帮它维护一套历史信息，然后在每次请求前把相关的历史内容整理好、塞进 prompt 里，让模型在"看起来有记忆"的前提下继续工作。

理解了这一点，你就明白了 Agent Memory 管理的第一个重要原则：记忆不是模型自带的能力，而是应用层必须承担的工程职责。搞清楚这个原则之后，所有设计上的选择——存哪些、怎么存、何时清——都是围绕"如何让外部存储的信息高效地进入模型上下文"来展开的。

1.2 记忆的三层形态：内存态、磁盘态、上下文状态

在实际工程里，我习惯把 Agent 的记忆系统拆成三层来看。

第一层是上下文状态，就是真正被组装进 prompt、发送给 LLM 的那段文本。它直接决定模型输出质量，但也受限于模型的上下文窗口大小。ChatGPT 的 32k、128k，或者开源模型经常会碰到的 8k、32k 限制，都是这一层的天花板。

第二层是内存态（in-memory memory），也就是程序运行时保存在进程内存里的数据。它读取极快、操作简便，适合用来管理当前会话的实时状态，比如多轮对话的最近几轮消息、某个任务执行到哪一步、临时变量等。缺点是进程一挂、服务一重启，一切归零。

第三层是磁盘态，也就是持久化存储。把记忆落到文件、数据库或向量数据库里，让 Agent 在下次启动时、在不同会话中、甚至在多实例部署时都能读取到长期知识。磁盘态是内存态的备份和扩展，也是真正意义上"长期记忆"的载体。

三者的关系可以这么理解：内存态是上下文状态的数据源，负责快速提供最近和最重要的信息；磁盘态是内存态的下游蓄水池，负责把有价值的信息沉淀下来以备后续取用。每轮对话的处理链路大致是：从磁盘态加载长期记忆，合并到内存态的会话记录中，经过上下文管理模块的截断和压缩，最终拼装成 prompt 发给模型。

1.3 设计记忆系统前先想明白的四个问题

我见过很多新手一上来就写代码，结果做了一轮对话就发现模型"失忆"，然后就开始到处找话题。其实在动手前，先花十分钟回答四个问题，整个记忆系统的方向和复杂度就清晰了。

第一，记什么。不是所有对话都值得记住。用户偏好（比如"邮件要用简洁风格"）、正在执行的任务状态（比如"已经生成了报告初稿，等待用户确认"）、领域知识（产品资料、FAQ、历史决策记录）这三类信息优先级最高，寒暄和临时问答的价值就要低得多。

第二，存多久。按生命周期划分，会话级记忆只服务于当前对话，结束即清；用户级记忆跨会话保存，用来维护个性化体验；全局级记忆则属于整个系统或团队，比如共享的知识库、审批流程等。层级不同，存储方案也不同。

第三，存哪里。小数据、低并发场景用 JSON 文件就够了；需要结构化查询、多用户隔离就用 SQLite；要支持语义检索、模糊匹配，就得上向量数据库。这个选择直接影响后续的查询方式和性能。

第四，怎么捞。是精确匹配用户 ID 去查某一条记录，还是用关键词或者向量相似度去做召回，是只取最近的 N 条，还是结合时间权重做记住与遗忘的平衡，这决定了记忆系统的查询接口长什么样。

这四个问题想清楚，后面每一步都会顺很多。接下来进入具体实现，先从最常被拿来当切入点的内存记忆开始。

2. 内存记忆：会话级短期记忆的工程实现

2.1 短期记忆的本质是一条有边界的消息队列

内存记忆最简单的形态，就是拿一个数组把历史消息按顺序记下来。每次用户发来一句话，Append 进列表；Agent 调用模型前，把整个列表拼接成 prompt 发给模型。但这里有个问题：如果不加约束，列表会无限增长，总有一天超过上下文窗口。

所以相比之下，我更喜欢用队列，或者叫"有边界的数组"。它的核心逻辑是先进先出，超过设定容量后最老的消息自动被挤出。这样就能天然控制内存记忆的规模，也为后面做上下文截断打好了基础。

把这个逻辑做抽象，短期记忆模块的职责就是三件事：新增一条消息、取出当前需要给模型的消息、在必要时清空。它的数据结构非常简单，但就是这份简单，构成了整个 Agent 记忆系统里最频繁使用的底层原语。

2.2 Python 实操：一个极简会话记忆类

直接上代码，这一版是我在日常项目里用得最多的简化实现：

from collections import deque from dataclasses import dataclass, field from typing import List, Dict, Any import time @dataclass class ConversationMemory: max_messages: int = 50 messages: deque = field(default_factory=deque) def add_message(self, role: str, content: str, **kwargs): """新增一条消息，超过容量时自动淘汰最老的""" msg = { "role": role, "content": content, "timestamp": time.time(), "meta": kwargs } self.messages.append(msg) if len(self.messages) > self.max_messages: self.messages.popleft() def get_context_messages(self) -> List[Dict[str, Any]]: """返回供 prompt 使用的消息列表""" return list(self.messages) def clear(self): self.messages.clear()

使用的时候就是这样：

mem = ConversationMemory(max_messages=20) # 模拟一轮对话 mem.add_message("user", "帮我写一封请假邮件") mem.add_message("assistant", "好的，请问请假几天？什么原因？") mem.add_message("user", "三天，家里有事") # 构建 prompt 时直接取全部消息 for msg in mem.get_context_messages(): print(f"{msg['role']}: {msg['content']}")

这个类虽然短，但已经把短期记忆的核心逻辑都涵盖了。max_messages 控制了消息数量上限，deque 保证了追加和淘汰都是 O(1) 操作。如果你用的是 LangChain，其实 ConversationBufferMemory 做的事情和这段代码基本一致，只是封装得更多，还附带了一些序列化逻辑。

这里我想特别说一句：不要迷信框架自带的 Memory 类。框架封装得越黑盒，你越难在出问题时定位根源。我身边很多同事最后都选择自己维护一个简单的记忆类，原因就是它足够透明，出了问题一眼就能看到。框架的记忆组件适合快速原型验证，生产环境还是建议自己掌握核心逻辑。

2.3 经常被忽略的细节：角色区分和消息元数据

实际开发里，消息不会只有 user 和 assistant 两种。在带工具调用的 Agent 里，还会有 system 消息和 tool 消息。如果工具调用记录处理不当，模型会困惑："这个函数返回的结果是哪来的？"所以内存记忆里每条消息最好带上 role 字段，同时为工具结果留出独立的位置。

另外，我强烈建议在每条消息里附带 timestamp 和 meta 字段。timestamp 可以用于时间衰减策略——太久远且不重要的消息可以优先被淘汰；meta 字段则可以记录消息的来源渠道（比如"来自长期记忆恢复"还是"来自本次对话"），这对后面做记忆融合非常有用。看似加了两个小字段，实际排查问题的时候会省很多事。

举个例子：用户连续问了三轮天气，三轮的 meta 标记都是"临时查询"。后来用户问"我上次问你天气是哪一天"，如果只靠内容匹配很难找到准确时间，但如果有 timestamp，直接按时间范围一捞就出来了。这些元数据的价值往往要在项目后期才显形，但前期加成本极低，我建议所有消息都统一带上。

2.4 内存态的边界：容量失控和多线程并发

这里分享两个我踩过的坑。第一个坑是没有设置边界，把 max_messages 设成了无限或者一个很大的数。对话一旦拉长，内存占用自然涨，更麻烦的是每次调用模型要处理的 prompt 也在疯涨，费用和延迟都不受控。所以我现在的习惯是，内存记忆的容量宁可设小一点，配合后面的文件持久化来做补偿。

第二个坑是并发。如果 Agent 是 Web 服务，多个请求同时读写同一个会话的 memory 对象，不加锁就会出现消息乱序甚至丢失。Python 里可以用 threading.Lock 把 add_message 和 get_context_messages 包起来，或者干脆用 Redis 这类外部存储来做会话状态的共享。业务量再往上走，内存态基本就要让位于外部存储了。

还有一个小问题容易被忽略：内存记忆里的消息顺序。deque 本身是天然保序的，但如果你在中间插入过逻辑（比如做过去重或排序），一定要确认顺序没有被破坏。模型对消息顺序非常敏感，顺序一乱，整个对话的逻辑就崩了。这个问题的隐蔽性在于不会有任何报错，只有输出质量悄悄下降。

3. 文件持久化：把记忆从进程里搬出来

3.1 为什么内存态撑不起真正意义上的长期记忆

先说一个场景：用户跟 Agent 聊了三十分钟，Agent 记住了他的公司规模、产品方向和邮件风格。结果第二天用户再来，Agent 一脸茫然，所有偏好全部丢失。因为进程重启，内存里的对象已经销毁了。

更复杂的情况是，Agent 部署了多个副本，流量通过负载均衡随机分发到不同实例上。用户上一次请求落在实例 A，记忆存在 A 的内存里；下一次请求落在实例 B，B 根本不知道这段历史。所以只要 Agent 需要跨会话、跨实例工作，就必须引入持久化存储，把记忆从进程内部搬到独立于进程的外部存储中。

这是文件持久化的核心价值：让记忆的生命周期超越单个进程和单次会话。选型上有很多路径，但不管用哪种，本质都是解决同一件事——把内存里的结构化数据，序列化到磁盘，再在需要时反序列化回来。

3.2 三种持久化方案选型：JSON 文件、SQLite、向量数据库

我按实际项目里最常见的三类存储做了个对比，方便你按场景选。

我的建议很简单：项目初期用 JSON 文件，先把记忆逻辑跑通；用户量和数据量上来以后再迁移到 SQLite；当你的记忆不仅需要"找得到"，还需要"按意思找"的时候，才值得引入向量数据库。很多人一开始就上向量库，结果发现向量化的成本、检索的调参、冷启动问题一大堆，实际上很多场景用结构化存储就够了。

这里多说一句向量数据库的冷启动问题。向量检索效果好，建立在有足够多高质量记忆文本的基础上。项目刚启动时记忆库是空的，向量检索等于无米下锅，这时候系统体验反而不如简单的"最近消息优先"策略。我见过不少团队一上来就搭 Chroma、Milvus，折腾半天，最后发现核心瓶颈根本不在这里。先跑起来，再逐步演进，才是稳妥的路线。

3.3 实操：基于 JSON 的文件持久化实现

JSON 方案的核心就四个字：序列化、反序列化。下面这段代码来自我某个实际项目的简化版本，特点是每个用户一个文件，方便隔离和备份。

import json import os from typing import List, Dict class JsonMemoryStore: def __init__(self, base_dir: str = "./agent_memory"): self.base_dir = base_dir os.makedirs(base_dir, exist_ok=True) def _file_path(self, user_id: str) -> str: # 用户 ID 做一次安全转义，避免路径穿越 safe_id = user_id.replace("/", "_").replace("\\", "_") return os.path.join(self.base_dir, f"{safe_id}_memory.json") def save_messages(self, user_id: str, messages: List[Dict]) -> None: path = self._file_path(user_id) tmp_path = path + ".tmp" with open(tmp_path, "w", encoding="utf-8") as f: json.dump(messages, f, ensure_ascii=False, indent=2) os.replace(tmp_path, path) # 原子替换，防止写入一半崩溃 def load_messages(self, user_id: str) -> List[Dict]: path = self._file_path(user_id) if not os.path.exists(path): return [] with open(path, "r", encoding="utf-8") as f: return json.load(f)

这里有两个细节值得多说两句。一个是写文件用了 tmp 文件加 os.replace 的原子替换方式，直接覆盖写文件在进程中途崩溃时很容易留下一个截断的半成品 JSON，导致下次读取直接抛异常。另一个是文件名对用户 ID 做了转义，避免用户传入特殊字符造成路径穿越或者把目录结构破坏掉。这些细节看着小，但在生产环境里都是实打实的坑。

使用的时候，可以把上一节的内存记忆类和这个存储类结合：每轮对话开始前，从 store 加载历史到内存；每轮对话结束后，把内存里的最新消息写回 store。这样就完成了一个最简单的会话记忆+长期记忆的闭环。

还有一个实践细节：写入频率要控制。如果每轮对话都立刻写盘，高并发下 I/O 会拖慢响应。我常用的折中方案是"内存里先攒着，每 N 秒或每 M 条消息批量写一次"。但对绝大多数个人项目来说，每轮对话结束同步写一次问题不大，等遇到性能瓶颈再做异步也不迟。

3.4 进阶方案：SQLite 结构化存储与向量检索

当数据量上来、用户量上来以后，JSON 全量加载的方式就比较吃力了。用户查一条历史记录，结果把整个 JSON 都载进内存遍历一遍，效率极低。这时候 SQLite 是更稳妥的选择，它本身就是一个单文件数据库，不需要额外部署服务，Python 标准库也自带 sqlite3 模块。

用 SQLite 存记忆的核心是建一张消息表，字段至少有 id、user_id、role、content、timestamp，有需要的话再加一个 session_id。查询时就通过 SQL 条件精准捞数据，比如"取某用户最近 20 条消息"或者"取某用户三天前的所有工具调用记录"。这些操作用 JSON 方案写起来十分痛苦，用 SQL 就是一行的事儿。

建表语句可以参考这个精简版本：

CREATE TABLE IF NOT EXISTS messages ( id INTEGER PRIMARY KEY AUTOINCREMENT, user_id TEXT NOT NULL, session_id TEXT, role TEXT NOT NULL, content TEXT NOT NULL, timestamp REAL NOT NULL ); CREATE INDEX IF NOT EXISTS idx_user_time ON messages(user_id, timestamp);

索引一定要加在 (user_id, timestamp) 上，这是查询最频繁的条件组合。没有索引的话，数据量过万之后查询速度会肉眼可见地下降。

至于向量数据库，适合的场景是"语义记忆"。比如用户很久以前说"我对咖啡因敏感"，后来你问 Agent"用户的饮食偏好是什么"，精确匹配"咖啡因敏感"可能匹配不上，但向量检索能通过语义相似度把这条历史记录召回。实现思路是：把每条记忆文本做 embedding，存进向量库；查询时对用户当前的问题也做 embedding，再算相似度取 Top-K。这个方向扩展性强，但要处理好 embedding 成本、索引更新频率等问题，没有看起来那么轻量。

4. 上下文截断：窗口不够用时的"记忆取舍"

4.1 上下文超长：每个 Agent 应用都会撞上的天花板

模型上下文窗口是硬约束。就算你用支持百万级上下文的模型，prompt 越长，生成速度越慢，单次调用成本越高，而且模型对中段信息的关注度还会下降。我见过一些团队把几千条历史消息全塞进 prompt，结果模型不仅没变得"更聪明"，反而被无关信息干扰，回答质量明显下降。

所以上下文管理真正要做的不是"尽可能塞更多"，而是"在有限空间里塞最有用的信息"。这涉及三个重要手段：截断（只保留最近或最重要的）、压缩（把长内容概括为短摘要）、检索（从长期记忆中有针对性地召回所需信息）。三者经常组合使用，合起来就是 Agent 上下文管理模块的核心职责。

4.2 五种常用截断策略的对比与取舍

下面是我在项目里实践过的五种策略，各有适用场景。

我不太建议一上来就做混合策略，复杂度是几何级上升的。更多团队是先用滑动窗口撑住基本面，等功能稳定了，再逐步把摘要压缩和关键信息抽取加进去，这样每一步的收益都可观测、可回退。

关于滑动窗口还有一个隐藏问题：窗口设多大合适？太小容易丢重要信息，太大又容易逼近上下文上限。我的经验是窗口大小取模型上下文窗口的三分之一到二分之一比较稳，留出空间给 system 提示和工具返回结果。选型的时候也别光盯着模型官方标称的上下文长度，实际使用要预留安全余量，否则一个大工具返回就可能直接撑爆。

4.3 实操代码：实现一个可配置的滑动窗口截断

滑动窗口实现特别直白，主体就是一个切片操作：

def build_prompt_with_window(memory, max_messages: int = 20): messages = memory.get_context_messages() # 始终保留首条 system 消息，其余只保留最近 N-1 条 system_msgs = [m for m in messages if m["role"] == "system"] non_system_msgs = [m for m in messages if m["role"] != "system"] windowed = non_system_msgs[-(max_messages - len(system_msgs)):] return system_msgs + windowed

这里的细节是把 system 消息和普通对话消息分离开来。system 消息里往往放着角色设定和核心指令，属于"无论对话多长都不能丢"的部分，而普通对话是可以用窗口截断的。所以这个函数先过滤出 system 消息，再从非 system 消息里取最近 N 条，合并返回。

你可能注意到了，这个方案其实非常简单。我见过不少团队在滑动窗口里过度设计，给每条消息加权重、做时间衰减、搞优先级队列，最后发现效果和朴素方案差不多，复杂度倒是翻了几倍。滑动窗口的精髓就是"快、省、可预测"，先保证不出错，再谈优化。

4.4 更聪明的做法：摘要压缩与关键信息抽取

当对话长度超过了滑动窗口能承受的范围，或者你有"早期信息也很重要"的需求时，摘要压缩就派上用场了。做法是：当内存里的消息数超过阈值，把最旧的一段消息抽出来，调用一次 LLM 让它总结成几句话，然后把这个摘要当作一条特殊消息存回记忆里，替代被压缩的原始消息。

def compress_old_messages(memory, llm_func, compress_threshold: int = 30): messages = memory.get_context_messages() if len(messages) <= compress_threshold: return messages # 保留最近的 10 条，压缩之前的全部 recent_msgs = messages[-10:] old_msgs = messages[:-10] text = "\n".join(f"{m['role']}: {m['content']}" for m in old_msgs) prompt = ( "请把下面的对话压缩成一段不超过100字的中文摘要，" "重点保留用户的指令、关键事实和未完成的待办事项，不要遗漏结论。\n\n" f"{text}" ) summary = llm_func(prompt) compressed_msg = {"role": "system", "content": f"[历史摘要] {summary}"} return [compressed_msg] + recent_msgs

这段代码的思路是：把老的对话批量交给 LLM 做总结，生成一条以 system 角色存在的历史摘要，再接上最近的完整对话。这样模型既能看到"早期发生了什么"的压缩信息，又能看到最近的具体表达。摘要产生的 token 远远小于原始对话，代价是一次额外的 LLM 调用。对于"宁可多花一点算力也要保住长期上下文"的场景，这个方案很实用。需要注意压缩的时机和频率，避免每轮对话都在做压缩，导致费用失控。

关键信息抽取则是在每轮对话结束后，单独用规则或 LLM 从对话里抽取实体与偏好，存储到独立的"记忆知识库"里。比如用户说"以后邮件都用简洁风格"，这条信息通过抽取逻辑落到持久化层，下次对话直接从知识库加载，而不必等用户重新提起。这是记忆系统中"主动记忆"的一环，越早做越受益。

这里也有个容易踩的坑：摘要压缩是会失真的。模型总结时可能丢掉用户的原话细节，导致后续判断偏差。为了缓解，我习惯在摘要里保留原始对话里最关键的引用片段，比如数字、日期、姓名这类不可发明的信息。摘要的 prompt 里尽量明确要求"保留所有数字和专有名词"，实测下来信息完整度会高不少。

5. 常见问题与排查实录

5.1 上下文窗口还有余量，模型却"忘"了早前的指令

有段时间我做的 Agent 经常出现一个诡异现象：第 10 轮对话时，模型开始忘记第 2 轮的用户指令。明明上下文没超长，为什么记不住？后来排查发现，第 3 轮工具调用返回的 JSON 特别长，虽然总量没超，但模型注意力被中间大段数据稀释了，早期指令在整个序列中的权重自然下降。

这个问题的解决办法是：把核心指令放到 system 消息里，并且必要时在 system 里重复一遍关键约束；同时把长工具结果做截断或另存，只把提炼后的摘要放回对话上下文。因为对于自注意力机制来说，不是"上下文里有"就代表"模型能重点看到"，prompt 的信息布局有时候比长度更关键。

5.2 持久化文件被写坏：一次断电引发的教训

有一次我本地的 Agent 在写入 JSON 记忆时突然断电，重启后 load 直接抛 JSONDecodeError，整个用户的记忆文件报废了。这就是直接覆盖写文件的下场。后来我把写入逻辑全部改成"先写临时文件，写完用 os.replace 原子替换"，问题就没再出现过。这个细节在前面代码里已经体现，但这里必须再强调一次：文件持久化的第一原则就是禁止直接打开原文件写入。

另外补充一个习惯：JSON 方案下的记忆文件最好定期导出备份。个人项目可能不在意，但一旦用户量上来，一次误操作覆盖掉几百个用户的历史记录，恢复成本非常痛苦。我现在的项目里每天凌晨会跑一个脚本，把整个 agent_memory 目录做一次快照压缩，保留最近 7 天。成本很低，但关键时刻能救命。

5.3 Token 费用肉眼可见地涨：问题出在"全都要"心态

有段时间我把 max_messages 调到 100，还同时做了摘要压缩和关键信息抽取，结果一个月的模型调用费用明显上升。排查后发现：摘要压缩每轮都触发，等于每轮对话都多了一次 LLM 调用；关键信息抽取也走的是模型，又在额外烧钱。后来我把压缩阈值从 30 条调到 80 条，抽取改成定时批量执行而不是每次对话后立刻执行，费用一下就下来了。

这里总结一个经验：只要是走 LLM 的功能，都会有隐形成本，尤其是摘要和抽取这类"元任务"。一定要控制触发频率，能用规则、缓存、定时任务解决的，就不要每次实时调用模型。

5.4 截断把未完成的任务状态砍掉了

还有一次，Agent 正在执行一个多步骤任务，状态记录在第 5 轮对话里，但滑动窗口只保留了最近 10 条消息，结果模型"不记得"任务执行到哪一步了，后面的流程全乱了。这个问题的根因是：滑动窗口不考虑消息的重要性，只按时间新旧淘汰。"任务状态"这种结构化信息不能只埋在对话文本里，得抽出到独立字段，在每轮组装 prompt 时主动放进去。我现在做 Agent 时，都会预留一个叫 task_state 的字段，专门存当前任务进度，绝不依赖对话记录来还原。

5.5 问题排查速查表

说实话，排查记忆问题的难点不在技术深度，而在"链路太长"。从用户输入到模型输出，中间隔了存储层、上下文管理层、prompt 组装层，任何一个环节的小问题都会被下游放成"模型变笨了"这种模糊现象。所以排查第一原则永远是先看日志，第二原则是逐层隔离，不要一上来就怀疑模型本身。

你可能会想，这些方案看起来都不复杂，为什么还有那么多团队在 Memory 上翻车？核心原因在于，记忆管理本质上不是某个单一技术点，而是一个贯穿整个 Agent 生命周期的系统工程。它需要你在每一个决策点都做取舍：存什么、存多久、花多少钱、牺牲多少信息粒度。技术方案每个单点都很简单，难的是组合起来后的平衡。

从零去搭建一套适合自己的记忆系统，我建议的路径是：第一步，先用内存 deque 跑通单轮会话的记忆；第二步，加 JSON 文件持久化，解决重启丢失问题；第三步，加滑动窗口截断，控制 token 消耗；第四步，再根据业务需要决定是否引入摘要压缩、向量检索和 SQLite。每一步的改动都不大，但每完成一步你都会对系统多一层直观理解。

最后再分享一个小技巧：每次给记忆系统加新功能时，先在代码里预留好 trace 日志。把"加载了哪些记忆""截断了哪些消息""压缩时丢掉了什么"这些关键动作都打出来，调试时你会非常感激这些日志。记忆系统是所有 Agent 逻辑里最"黑盒"的部分，没有日志几乎是没法维护的。我个人的习惯是保留一个专门的 debug 开关，平时关闭，排查问题时才打开，既不会刷屏又能随时定位。

提示：如果你的项目里已经接手了别人的记忆系统，排查问题前先花点时间把"记忆从哪来、存到哪去、何时被清理"这条链路画出来，能少走很多弯路。