我之前给一个基于NodeJS的AI Agent做记忆系统一开始图省事直接接了Agent框架结果一堆隐形的内存缓存和会话状态把Node进程的内存顶到了800MB跑两三天就崩一次报错码是0xc0000005。查了两天没头绪最后狠下心把框架拆了用原生NodeJS自己写了一套Agent Memory的维护模块。这个过程确实痛苦但收获也很大——我搞明白了Agent记忆到底需要哪些能力也把NodeJS内存管理里的不少底细摸了个透。这篇文章就是这段实践的完整复盘主角是原生NodeJS、Agent、Memory不管你是正在做AI Agent还是单纯想绕开框架陷阱、自己掌控NodeJS内存生命周期这里的内容都值得参考。1. 为什么我放弃了框架选择原生NodeJS来维护Agent记忆1.1 框架表面省事暗地里却绑架了内存我用过一套比较流行的Agent框架上层封装确实漂亮对话状态机、工具调用、记忆注入全都有接完就能跑。但它的记忆能力被设计成“向量索引 嵌入模型”的组合为了通用性每个会话都要维护一堆中间对象还要调本地的嵌入服务。而我的Agent是一个私有部署的任务助理用户量不大但硬性要求是低延迟、低内存占用最好是单进程跑起来就完事。框架的内存模型和我的需求完全不匹配。它默认“多租户、多会话、大规模知识库”可我的使用场景根本用不到那一层。为了保持通用性框架必须把数据包装得足够抽象抽象意味着更多的对象、更多的闭包、更多的临时变量这些都会变成GC压力最后反应在居高不下的内存占用和时不时出现的进程崩溃上。1.2 原生NodeJS能让我精确控制每一块内存用原生NodeJS维护Memory本质是自己定义记忆的数据结构、存储方式和淘汰策略。这意味着我可以精确控制哪些对象长期存活、哪些对象尽快让GC回收。举个例子对话历史在工作记忆里只保留最近10轮超过的部分立即压缩成摘要丢进长期记忆。这个逻辑在框架里改起来很困难但自己写就是几十行代码的事。原生方案还能让我避开很多无谓的依赖。我最开始的版本只用了Node内置的fs、crypto、path模块零第三方依赖部署时只需拷一个文件夹过去不用管npm install、不用管原生模块编译连node_modules都可以不提交。对一个追求稳定的小型服务来说这种可控感非常重要。1.3 我最终采用的架构分层整个方案拆成三层调用层、记忆层、持久层。调用层Agent主逻辑负责接收用户输入、调用模型、执行工具。记忆层MemoryStore负责工作记忆、短期记忆、长期记忆的读写、检索和淘汰。持久层FileStore负责把记忆块序列化到磁盘以及启动时恢复。调用流程是这样的Agent收到用户消息后先在MemoryStore里检索相关记忆拼进上下文送给模型模型返回后再把新的对话内容写入记忆层MemoryStore定期触发淘汰和落盘把不再高频使用的记忆沉淀到磁盘。这套结构没有框架层面的魔法每一层都能看懂、能改、能单测。后面所有踩坑和优化都是在这个结构上展开的。2. Agent Memory的落地结构工作记忆、短期记忆与长期记忆2.1 三个记忆池的边界必须清晰很多Agent项目挂掉是因为把短期、长期、工作记忆全塞进一个数组里最后上下文越来越大、越来越慢。我在设计时把记忆拆成了三层分别对应不同的生命周期和存储介质记忆类型生命周期容量上限实现方式工作记忆单次会话内10~20轮对话数组短期记忆几小时到几天数百到数千块Map LRU长期记忆跨会话永久不限JSON文件 / 轻量数据库工作记忆是给当前对话用的相当于人脑子里的“工作台面”会话结束了就清空。短期记忆是最近产生的、可能会被再次提到的内容比如用户正在处理的几个任务、最近聊到的话题。长期记忆是沉淀下来的用户偏好、项目背景、历史结论不是一次会话就能用完的。三个池子之间需要服务。工作记忆超过阈值就把最旧的内容降级到短期记忆短期记忆经过淘汰后重要的内容再降级到长期记忆。这个流向如果设计好内存就不会无限膨胀。2.2 记忆块的数据结构想要可淘汰就必须有元数据为了支撑检索和淘汰我给每一条记忆定义了一个结构化的MemoryBlock而不是简单存一段字符串。这里放一个简化版的核心定义class MemoryBlock { constructor({ id, sessionId, role, content, timestamp, importance 0.5, keywords [] }) { this.id id; this.sessionId sessionId; this.role role; // user | assistant | tool this.content content; this.timestamp timestamp; this.importance importance; // 0~1人工或规则赋值 this.keywords keywords; // 关键词数组用于检索 this.accessCount 0; // 被检索命中的次数 this.lastAccessAt timestamp; // 最近一次被访问的时间 } }每个字段都不是白加的。importance用于长期价值评估一个用户明确说“我很看重这个项目”的记忆重要性就应该更高accessCount和lastAccessAt用于短期价值评估经常被回忆起来的记忆应该被保留更久keywords则是检索的抓手没有关键词后续做相关性匹配就只能靠全文扫描。在这个类的基础上我实现了MemoryStore。它内部维护了三个容器一个普通数组保存工作记忆一个限制容量的Map保存短期记忆一个磁盘文件目录保存长期记忆。短期记忆的Map是重点它的插入、访问、淘汰都和内存直接相关。2.3 写入与检索给Agent“想起来”的核心逻辑写入一条记忆大概分四步先判断内容长度太长的直接截断或拆成多条然后提取关键词这里我用的方法是去掉停用词后做简单分词接着赋予一个初始importance比如工具执行结果给0.5用户明确表达偏好的内容给0.8最后根据当前会话状态决定进入工作记忆还是短期记忆。检索的逻辑比写入复杂一点。当Agent需要回忆时它会传入一个查询字符串比如“用户之前提过数据库连接超时的时间”。我会做两件事先用关键词匹配把短期记忆和长期记忆里包含相关关键词的记忆块捞出来然后根据一个打分函数排序取topN。function score(mem, queryKeywords, now) { let hit mem.keywords.filter(k queryKeywords.includes(k)).length; const recency 1 / (1 (now - mem.lastAccessAt) / 3600000); return hit * 3 mem.importance * 2 recency; }这个打分公式很有用。命中一次关键词给3分重要性最高给2分最近的记忆每小时衰减一次。这样检索结果不会总被某个高重要性但长期不相关的旧记忆占着坑也不会让最新但无关的消息排前面。很多人做Agent记忆时不用打分排序直接把所有历史都塞给模型如果记忆量小还看不出问题一旦超过几十条模型的上下文窗口和响应质量都会明显下降。3. 记忆淘汰与落盘阻止内存无限膨胀的关键策略3.1 为什么我的Agent会内存失控先说结论NodeJS里的内存泄漏大部分时候不是语言的问题而是你的数据结构“只进不出”。我的Agent第一次出问题时短期记忆Map里最终膨胀到了十几万个对象原因就是我写了insert写了get但忘了写remove。每多一次对话Map里就多一个键永远不删。除此之外还有一个常见的坑事件监听器里不小心引用了记忆对象。比如某个监听函数里写了store.getMemoryById(id)然后这个监听器是全局的、没有解绑它就会持续持有记忆对象的引用导致GC永远无法回收这块内存。我的内存泄漏有一部分就是这种隐性引用造成的。3.2 基于时间、重要性与访问频率的淘汰算法要避免内存失控必须在写入路径上加一道闸门。我给短期记忆池设了一个上限默认1000块。当数量超过上限时触发淘汰例程把所有记忆块按一个综合评分排序移除得分最低的20%。综合评分是这样算的function evictionScore(mem, now) { const ageScore (now - mem.timestamp) / 86400000; // 天数越小越年轻 const recencyScore (now - mem.lastAccessAt) / 3600000; // 小时越小越新鲜 return mem.importance * 2 (1 / (1 ageScore)) (1 / (1 recencyScore)) mem.accessCount * 0.01; }这个公式把“重要性”“新鲜度”“访问频率”三个指标揉在一起。importance高的记忆不会轻易被清掉刚刚产生的记忆得分高经常被命中的记忆会越来越难被淘汰相当于实现了软性的LRU升级路径。当一条记忆被命中多次后我还会给它动态提升importance让它逐渐沉淀为长期记忆。淘汰动作不是一次性把所有超限对象全删掉而是每次只淘汰最末尾的20%然后马上检查是否低于阈值的80%。这样不会造成淘汰风暴也不会让短期记忆池在写入高峰时频繁触发淘汰GC压力更平均。3.3 持久化到磁盘原子写与防抖内存里的记忆不落盘进程一重启就全没了。我选择了最简单的JSON文件持久化方案但没有用最简单的writeFileSync直接覆盖因为直接覆盖会发生一个经典问题写入过程中进程挂了文件只剩一半。我的落盘方案分三步。第一先写临时文件第二写完以后调用fs.renameSync把临时文件原子替换目标文件第三保留一份上一次的备份文件启动时优先找主文件如果主文件JSON解析失败就自动从备份恢复。下面是核心代码const tmpPath ${storePath}.tmp; const bakPath ${storePath}.bak; fs.writeFileSync(tmpPath, JSON.stringify(data), utf8); fs.renameSync(tmpPath, storePath); fs.copyFileSync(storePath, bakPath);为了防止每次写入都触发全量序列化我做了一个防抖策略记忆变更后不立即写盘而是开启一个5秒的定时器定时器到点才开始落盘同时记录变更次数超过1000次变更也会触发一次提前写入。这样既不会丢失大量数据又不会在每轮对话后都做一次昂贵的JSON序列化。落盘的数据结构是分片式的把长期记忆按月份拆成多个文件比如2025-06.json、2025-07.json。加载时只加载当月和历史三个月的文件再早的按需懒加载。这个设计避免了启动时把所有历史全读进内存也节约了序列化时间。4. 踩坑实录从0xc0000005崩溃到npm安装脚本问题4.1 崩溃第一次0xc0000005 memory access violation这个错误码可以说是我那几天最不想看到的。运行环境是Windows ServerNode进程跑着跑着就悄无声息地退出事件日志里只有一行“0xc0000005 (memory access violation)”。最开始我怀疑是原生模块的问题因为我们项目里安装过node-pty用来做终端交互这东西是有原生代码的指针出格就会报内存访问违规。我立刻做了一次对照实验把涉及到node-pty的代码全部注释掉只保留纯JS逻辑结果依然崩溃。然后我怀疑是不是Node版本问题换了LTS、Current、甚至刚从官网下载的最新版都没用。最后我用了--trace-gc参数把GC日志打出来才发现真相崩溃前GC执行得极其频繁每次做完GC后堆内存还是以肉眼可见的速度增长直到达到V8的堆上限然后进程直接终止。现在回头看0xc0000005本身并不代表是C级别的指针错误在无法申请到足够内存时V8内部某些内存操作也会越界最终被操作系统记录成内存访问违规。所以它更像是一个“内存彻底耗尽”的并发症而真正的根因就是记忆Map的无限增长。4.2 用heapdump和Eclipse MAT定位到泄漏铁证定位泄漏时我用了两个工具heapdump包抓取堆快照Eclipse MAT分析快照。heapdump只需要一行代码就能在进程里触发快照require(heapdump).writeSnapshot(/tmp/heap- Date.now() .heapsnapshot);把崩溃前的快照抓到以后用Eclipse MAT打开看Dominator Tree。结果非常直观一个名为messages的数组占了整个堆的92%里面装的全是历史对话内容。顺着引用链往上查发现这个数组被一个事件监听函数闭包持有只要进程不退出监听函数就不会释放数组就一直被当“根对象”引用GC永远动不了它。修复方案也很简单一是给监听函数加上条件判断不再往那个数组里塞数据二是把全局的messages数组改成上面说的MemoryStore内部受控的Map加上上限和淘汰逻辑。改完以后同样跑满1000轮对话内存曲线终于不再是只涨不降了。有一个多吃一堑的经验查NodeJS内存泄漏不要靠“感觉”一定要抓快照看引用链。我第一次就是因为盲目改代码花了两天都没定位到后来用MAT十分钟就找到了。新手建议先学会用heapdump和MAT这两个工具比什么内存优化技巧都值钱。4.3 npm执行策略和原生依赖的坑踩完崩溃的坑另一个环境坑也很有代表性。新配的Windows开发机上我运行npm run dev结果直接报npm : 无法加载文件 C:\Program Files\nodejs\npm.ps1因为在此系统上禁止运行脚本。这是PowerShell的默认执行策略限制不是NodeJS本身的问题。解决办法其实就两行命令Set-ExecutionPolicy -Scope CurrentUser RemoteSigned或者在PowerShell里用CMD绕过npm.cmd run dev如果你遇到的是process exited with code 3221225477或memory access violation那就要优先怀疑Node进程的堆内存被榨干而不是先去查什么原生模块。我见过很多同学一看到内存访问违规就认为必须是native code的问题实际上Node纯JS代码在内存严重不足时一样会触发这个报错。另外原生NodeJS方案在安装环节还有一个隐性好处不需要编译node-gyp、不需要Python环境、不需要Visual Studio Build Tools。如果你用框架一装就是几百个依赖包里面但凡有一个带原生模块Windows上安装失败的概率就会直线上升。这也是我后来不后悔拆框架的重要原因。5. 长会话压测跑满1000轮对话后内存还稳如老狗5.1 压测脚本怎么设计写完淘汰和落盘逻辑以后我做了一个长会话压测。脚本模拟用户与Agent的连续对话每轮对话产生一条用户消息和一条模型回复也就是两条记忆块每20轮随机触发一次对旧记忆的查询每50轮强制触发一次短期记忆池的淘汰和落盘。压测脚本的核心很简单setInterval(() { for (let i 0; i 10; i) { const userMsg 用户第${round}轮说的内容${Math.floor(Math.random() * 1000)}; store.remember({ role: user, content: userMsg, sessionId: stress }); const resp 助手回复第${round}轮已处理${Math.floor(Math.random() * 100)}; store.remember({ role: assistant, content: resp, sessionId: stress }); } const memories store.recall(内容 Math.floor(Math.random() * 1000)); round; }, 100);为了对比我同时跑了一份“没有淘汰机制”的对照版本它只往Map里塞数据不做任何清理。两边都跑1000轮记录堆内存占用。5.2 内存占用曲线与GC表现数据很能说明问题运行轮次无淘汰机制内存占用有淘汰机制内存占用有淘汰机制GC次数0轮45MB45MB-200轮120MB68MB32次400轮210MB76MB31次600轮290MB79MB30次800轮370MB82MB29次1000轮460MB85MB28次对照版本在第850轮左右就已经接近V8默认堆上限后面随时可能触发0xc0000005而带淘汰机制的版本在1000轮时内存稳定在85MB左右几乎没有继续爬升的趋势。GC次数甚至比对照版还少因为对象总量被控制住了GC每次扫描的成本也降低了。5.3 测试结论这套压测让我确信原生NodeJS只要数据结构设计得当完全可以应付中轻量级Agent的长期记忆需求。性能瓶颈不在语言本身而在检索和淘汰策略。需要注意的是这里压测的是内存不是响应延迟。我同时记录了一下recall函数的平均响应时间在短期记忆池1000块、长期记忆文件三个月份的情况下一次关键词匹配加打分排序的耗时稳定在1~3毫秒完全不影响Agent主流程。如果未来记忆量增长到数十万条可能要考虑引入倒排索引或者真正的向量检索那是后话。6. 一点经验总结和后面打算做的事6.1 给后来者三条落地方案建议第一记忆混合用。工作记忆用普通数组短期记忆用带容量的Map加上淘汰策略长期记忆用文件或数据库。不要把三层混在一起否则一定会遇到“上下文越滚越脏”的问题。第二淘汰机制必须提前设计。不要等跑到线上再补。哪怕你的Agent现在只有几十条记忆也要在一开始就把LRU和重要性评分写好因为数据量增长的速度比你想象中快得多。我吃过这个亏所以现在任何Agent项目第一步就是给记忆模块加上限。第三落盘用临时文件加rename不要直接覆盖。这个方案在很多场景下都适用不仅仅是NodeJS。直接覆盖主文件一旦进程在写一半时退出整个记忆库就可能损坏恢复起来非常痛苦。6.2 为什么原生NodeJS反而是务实之选这次实践以后我不再迷信Agent框架了。对于中小规模、私有部署、低内存占用的场景原生NodeJS实现Memory维护的成本很低收益却非常高。没有框架依赖部署简单内存可控出问题可以一眼看到根因。就算未来要上向量检索我也可以只引入一个轻量级的向量索引库把嵌入和存储继续放在记忆层外面核心架构不用推翻重写。这就是原生方案最大的好处——每加一块能力都是显式的不会出现框架自带的隐性黑盒。6.3 我接下来准备做的事现在这套记忆模块已经跑了两周稳定得让我有点不习惯。我打算在几个方向继续扩展一是把记忆摘要从“简单截断”升级成“用模型生成总结”这样长期记忆的密度会更高二是按用户维度做记忆隔离避免多用户共用Agent时互相串记忆三是尝试用worker_threads做记忆索引的并发查询把recall阶段的延迟进一步压下来。最后再分享一个小技巧如果你的Agent也在用原生NodeJS维护记忆记得定期检查一下短期记忆池里对象的accessCount分布。如果一个记忆块很久没被访问过那它大概率就该被淘汰了。AI Agent的Memory维护本质上是一个内存工程问题而不是机器学习问题。把数据结构、淘汰策略、落盘机制这三件事做好你的Agent就能像人一样记住该记住的、忘掉该忘掉的。