搞 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_factorydeque) 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_messages20) # 模拟一轮对话 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 的内存里下一次请求落在实例 BB 根本不知道这段历史。所以只要 Agent 需要跨会话、跨实例工作就必须引入持久化存储把记忆从进程内部搬到独立于进程的外部存储中。这是文件持久化的核心价值让记忆的生命周期超越单个进程和单次会话。选型上有很多路径但不管用哪种本质都是解决同一件事——把内存里的结构化数据序列化到磁盘再在需要时反序列化回来。3.2 三种持久化方案选型JSON 文件、SQLite、向量数据库我按实际项目里最常见的三类存储做了个对比方便你按场景选。维度JSON 文件SQLite向量数据库上手成本极低读写文件即可低一个文件一个库中高需要部署或使用托管服务查询能力弱只能全量加载后过滤强支持 SQL 条件查询偏语义检索精确查询较弱数据规模千条以内万到百万级百万级甚至更多并发支持差容易写冲突中等支持事务和锁好天然面向高并发典型场景个人项目、原型验证需要用用户 ID、时间等字段过滤需要按语义相关性召回记忆我的建议很简单项目初期用 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_okTrue) 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, encodingutf-8) as f: json.dump(messages, f, ensure_asciiFalse, indent2) 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, encodingutf-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 五种常用截断策略的对比与取舍下面是我在项目里实践过的五种策略各有适用场景。策略原理优点缺点适用场景滑动窗口只保留最近 N 条消息实现简单、成本低常用信息不易丢失早早前的重要信息直接丢失客服机器人等以最近对话为主的场景摘要压缩用 LLM 把早期对话总结成摘要信息保留度比滑动窗口好不少摘要本身有失真风险需要额外 LLM 调用长篇工作流、研究型任务关键信息抽取只提取任务相关的实体和结论精准、省 token适合用户偏好与重要结论需要规则或模型支持可能遗漏上下文用户画像维护、事实提取分数淘汰给每条消息算个分保留高分灵活可融合时间和重要性两个维度打分规则设计成本高半年以上长期对话混合策略滑动窗口 摘要 关键信息并行效果最好上下文利用率最高实现复杂度最高需要精细调度大型产品级 Agent我不太建议一上来就做混合策略复杂度是几何级上升的。更多团队是先用滑动窗口撑住基本面等功能稳定了再逐步把摘要压缩和关键信息抽取加进去这样每一步的收益都可观测、可回退。关于滑动窗口还有一个隐藏问题窗口设多大合适太小容易丢重要信息太大又容易逼近上下文上限。我的经验是窗口大小取模型上下文窗口的三分之一到二分之一比较稳留出空间给 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 问题排查速查表现象可能原因排查思路模型忘记早期指令指令埋没在长上下文中或指令不在 system 消息里检查 prompt 布局把核心指令前置、重复prompt 长度持续增长消息队列没有上限或截断策略失效检查 max_messages 和 build_prompt 的逻辑记忆在重启后丢失只用内存态没有持久化加 JSON 或 SQLite 存储层并验证 load 路径记忆文件解析失败写入过程被中断改用临时文件原子替换写入模型回复内容与事实矛盾摘要压缩产生了失真压缩时保留原文引用的关键片段多实例下记忆互相覆盖本地文件无法共享迁移到集中式存储如 SQLite 或数据库服务说实话排查记忆问题的难点不在技术深度而在链路太长。从用户输入到模型输出中间隔了存储层、上下文管理层、prompt 组装层任何一个环节的小问题都会被下游放成模型变笨了这种模糊现象。所以排查第一原则永远是先看日志第二原则是逐层隔离不要一上来就怀疑模型本身。你可能会想这些方案看起来都不复杂为什么还有那么多团队在 Memory 上翻车核心原因在于记忆管理本质上不是某个单一技术点而是一个贯穿整个 Agent 生命周期的系统工程。它需要你在每一个决策点都做取舍存什么、存多久、花多少钱、牺牲多少信息粒度。技术方案每个单点都很简单难的是组合起来后的平衡。从零去搭建一套适合自己的记忆系统我建议的路径是第一步先用内存 deque 跑通单轮会话的记忆第二步加 JSON 文件持久化解决重启丢失问题第三步加滑动窗口截断控制 token 消耗第四步再根据业务需要决定是否引入摘要压缩、向量检索和 SQLite。每一步的改动都不大但每完成一步你都会对系统多一层直观理解。最后再分享一个小技巧每次给记忆系统加新功能时先在代码里预留好 trace 日志。把加载了哪些记忆截断了哪些消息压缩时丢掉了什么这些关键动作都打出来调试时你会非常感激这些日志。记忆系统是所有 Agent 逻辑里最黑盒的部分没有日志几乎是没法维护的。我个人的习惯是保留一个专门的 debug 开关平时关闭排查问题时才打开既不会刷屏又能随时定位。提示如果你的项目里已经接手了别人的记忆系统排查问题前先花点时间把记忆从哪来、存到哪去、何时被清理这条链路画出来能少走很多弯路。
