本文永久链接 – https://tonybai.com/2026/08/05/filesystem-based-memory-for-llm-agents
大家好，我是Tony Bai。
【导读】
Claude的memory tool、Claude Code的记忆文件夹、各家Agent框架的Skills……几乎所有部署中的Agent都在用同一种方式做长期记忆：一棵由Agent自己读写、整理的Markdown文件目录树。这套做法早已是行业默认，却几乎没有论文认真研究过它是否真的可靠。UIUC联合UCSD、UC Merced、Adobe Research、德州农工大学的最新研究，第一次把“文件系统记忆”系统地拆开来看，用三个角色、五个基准、六种记忆形态，给出了一份相当反直觉的成绩单。
【文章要点】
如果你最近关注过Agent产品的技术细节，大概率见过这样的设计：Agent把自己的长期记忆写成一个个Markdown文件，按主题分门别类地放进文件夹，需要的时候自己用类似ls、grep、view这样的工具去翻找。
OpenClaw的memory tool是这样，Claude Code里Agent自己维护的记忆文件夹也是这样，各家的“Skills”体系也是这样——记忆不再是一个专门设计的向量数据库或知识图谱，而是一套朴素到近乎“原始”的文件系统。
这套做法之所以流行，原因也很直白：编码Agent本来就活在文件系统里，用它顺手扩展Agent的记忆，几乎是零成本的选择。文件系统还天生具备层级结构——文件夹本身就是一套分类体系，人类可以直接打开来看、来改，可解释性拉满。
但学术界这些年做的事情几乎是另一条路：论文里更常见的是精心设计的“专用记忆表征”——分页式上下文管理、抽取出来的事实库、时序知识图谱、自我关联的笔记网络、摘要库、按嵌入向量组织的树……每一种都配了一套定制接口。相比之下，工业界已经大规模部署的“文件系统记忆”，反而是研究最少的那个。
这篇论文要问的问题非常朴素，却从来没人认真回答过：
论文做的第一件事，是把“文件系统记忆”这套业界实践抽象成一个可以做实验的最小模型。
一个记忆库（memory store）被定义为一棵有根的文件路径树，每个文件由三部分组成：路径、一句话描述、正文内容。文件夹没有自己的内容，只是路径的公共前缀；文件夹名、文件名，加上文件内部的Markdown标题，一起构成这个Store的“分类体系”（taxonomy）——这套体系的名字和一句话描述，就是Agent在打开文件之前唯一能看到的路标。
围绕这一个Store，论文定义了三种角色：
三者所有的读写操作都必须经过一个“工具集”（tool harness）——可以是几个简单的文件操作函数（读、建、改、插、删、改名），也可以是更强力的沙箱Shell，甚至加上正则搜索、关键词排序搜索。这个工具集本身也是论文重点研究的一个变量。
这套三角色框架有一个很聪明的地方：它用同一套定义，同时覆盖了两种记忆——声明式记忆（对话中的事实、偏好、事件）和程序性记忆（从经验中蒸馏出来的技能），不用为“记事实”和“记怎么做”分别设计两套系统。
既然要评价Agent整理记忆的好坏，总得先有个标准。论文给出的答案是五条“分类体系契约”（taxonomy contract），几乎所有管理Agent的系统提示词里都写了这五条：
这五条原则说白了就是“一个称职的图书管理员会怎么整理书架”，论文后面几乎所有关于“记忆库整理得好不好”的量化指标，都是在给这五条原则打分。
为了让结论站得住脚，作者设计了相当扎实的实验矩阵。
对话记忆（回答关于长对话内容的问题，带引用出处）：
技能记忆：
六种记忆形态覆盖了从“完全不整理”到“完全交给Agent自主整理”的整个光谱：
| 记忆形态 | 说明 |
|---|---|
| 闭卷（Closed-book） | 完全不给记忆，测模型自身知识的下限 |
| 分块检索（Chunk retrieval） | 传统RAG做法：切块+BM25排序检索 |
| 逐字转储（Verbatim dump） | 一次会话一个文件，内容原样保留，零模型成本，“零整理”基线 |
| 分文件夹归档（Foldered sessions） | LLM只负责设计文件夹分类，把逐字转储的文件搬进去，不改一个字 |
| 重组存档（Reorganized store） | LLM对逐字转储的内容重新拆分合并，内容分布会变 |
| Agent自主整理（Agent-curated store） | 从空白开始，管理Agent自己决定写什么、怎么组织，内容和结构一起变 |
一个有意思的插曲：作者发现，“重组存档”如果不特别叮嘱，模型默认的重组行为会悄悄丢细节——重写的过程中内容明显缩水。于是他们做了两个版本对比：一个是不加约束的“压缩版”，一个是加了“必须保留每一条事实”这条硬性规则的“保留版”，专门用来量化这种“模型自己的坏习惯”到底会造成多大损失。
技能记忆这边同样设了五档，从“完全没有记忆”到“整理成技能+经验笔记+按任务动态生成指导”逐级递进，细节这里不展开，重点在下面的结论。
论文围绕五个研究问题（RQ1-RQ5）展开，两套实验场景（对话记忆 / 技能记忆）各回答一遍。
结论是：记忆库长什么形状，主要是模型自身的“性格”，而不是材料多少决定的。
作者做了两组对照实验来拆解“规模”和“模型”这两个变量：
固定同一个管理模型，把材料量从PersonaMem 32k档拉到128k档（材料量大约变成5倍），记忆库并没有像常识预期的那样“分裂”成更多文件——恰恰相反，文件夹和文件层反而变薄了，层级关系转移进了单个文件内部的标题结构里，也就是所谓的“整理不是分片，而是压缩重排”。
反过来，固定材料量不变，只换管理Agent这一个模型（从小到大的三档），同一份对话在不同模型手里，会变成完全不同的三种树形结构——最小的模型倾向铺成浅而广的文件森林，中等模型几乎把所有层级都塞进两个文件的标题里，最大的模型则长出了整个实验里最深的树，还会用大量的“交叉引用”把散落的文件重新缝合起来。
技能记忆那边结论更极端：管理模型越强，技能库越“精炼”——最强模型把140次任务尝试蒸馏成十几个高密度的文件，最弱的模型反而铺开成上百个近乎扁平的文件。两种记忆场景，模型能力都决定性地改变了记忆库的形状，但方向截然相反：对话记忆是“非单调地忽大忽小”，技能记忆则是“越强越精简”，单调递减。
一句话总结：别指望“数据越多，记忆库自然长得越整齐”，真正决定形状的是那个负责整理的模型本身。
这是全篇最反直觉的部分。
先说好消息：结构化整理唯一稳定兑现的好处，是检索便宜。在材料量最大、最密集的场景下（PersonaMem两档），经过重组或Agent整理的记忆库，能把每次检索的花费砍到逐字转储版本的一半甚至更低；材料量本来就不大的场景下，这个优势会缩水到几乎持平。背后的机制也很清楚：整理过的记忆库虽然搜索轮次和调用次数变多了（因为搜索Agent要沿着结构一步步导航，而不是简单扫一遍），但每次读取拉取的内容量小得多，总体反而更省。
再说坏消息：正确率没有一种记忆形态能通吃所有场景，排名甚至会和“整理得越细致越好”的直觉正好相反。全场最稳定的反而是成本最低的“分文件夹归档”——它只是把原始转储文件搬进LLM设计的文件夹，一个字都没改，却在多个基准上追平甚至超过了完全由Agent自主整理的版本；而“Agent自主整理”版本在PersonaMem 32k档上是全场表现最差的记忆形态之一，甚至不如什么都不整理、只是简单分块检索的传统RAG做法。
“重组存档”的两个版本（压缩版 vs. 保留版）在不同基准上甚至会反着来：在长对话和真实聊天记录里，保留每条细节明显更好（真实聊天场景下，压缩版的正确率几乎腰斩）；但在信息密度更高的PersonaMem 32k档上，反而是压缩版本表现更好，因为更紧凑的库更容易搜。
一句话总结：整理记忆，买到的是“查得快”，不是“答得准”；到底该不该整理、整理到什么程度，取决于材料本身，而不存在一个放之四海而皆准的最优策略。
技能记忆场景的结论同样耐人寻味：谁来“消费”这份记忆，会直接决定哪种形态更优——面对能力强的执行Agent，把原始经验日志（一字不改的episode log）直接甩给它效果最好；面对能力弱的执行Agent，反而是精炼蒸馏、按任务实时生成指导的版本更管用，两者差距能达到十个百分点左右。换句话说，同一份记忆，喂给“学霸”和喂给“学渣”，最优的呈现方式完全不同。
在对话场景里，答案要拆成两半看：管理Agent的能力，买到的是“整理风格”，不是“答案质量”；搜索Agent的能力，才会直接兑现成答案质量。 也就是说，换一个更强的模型去整理记忆，记忆库的样子会明显不同，但最终搜索出来的答案对不对，跟整理模型的强弱关系不大；反倒是负责搜索、回答问题的那个模型，越强答得越准。
但有一个例外：当“写”这件事本身出了问题时，模型能力就会直接体现在答案质量上。论文发现，在某个基准上，管理Agent经常没能把“用户偏好发生变化”这件事，正确地记录成一条“带日期的更新”，导致过时的事实被当成“当前仍然成立”的信息留在库里——换一个更强的模型去执行同样的整理指令，能挽回大约一半的损失；但如果记忆库本身已经服务得不错，换模型就不会带来任何提升了。
技能记忆场景则揭示了一种“阈值效应”：当需要把经验蒸馏成可复用的程序时，模型能力表现为一道门槛——一旦跨过这道门槛，记忆库里到底装了什么内容，就比执行这一步的模型是谁更重要了。
好消息是：在论文测试的时间跨度内，记忆库不但没有变差，反而越用越有用，而且积累下来的经验，可以在一定程度上替代执行Agent自身能力的不足——哪怕执行Agent本身比较弱，只要记忆库里攒够了经验，照样能把任务完成得更好。
Store的“健康度”整体也站得住：对话场景里，记忆库的文件基本是在流程早期就建好的，后续只是不断编辑，几乎不会删除文件；技能记忆场景里，早期形成的记忆同样能长期存活，能力更强的管理Agent会倾向于“原地维护”已有文件，而不是不断新建替换。
但坏消息也很直接：“整理得好不好”这件事，会随着记忆库变大而逐渐失守——绝大多数管理Agent，都会在规模增长的过程中让分类体系逐渐松散、走样，只有实验里能力最强的那个管理Agent，才能一直守住这条“整理契约”。
而且，整理记忆这件事的边际成本从不会随着经验增加而变便宜——每新增一段经验，管理Agent还是要花差不多的精力去消化它；唯一一项会随着规模扩大而持续膨胀的“负债”，是那种“什么都保留、来者不拒”的逐字经验日志——检索时不得不把所有历史都扫一遍。
这一条对做工程实现的读者尤其有参考价值：只是给Agent多加一个工具，会改变它的行为习惯，但不一定改变最终结果；而彻底换一套工具集，对记忆库形态的重塑力度，不亚于直接换一个模型。
比如在长对话场景里，换成更偏“分片、依赖交叉引用”的工具集会让记忆库变得更零散但彼此勾连更紧密；而在技能记忆场景里，同样是换工具集，方向却是相反的——工具集变了会让记忆库变得更“整合、集中”，并且直接带来更好的任务结果。也就是说，工具集不是一层可以忽略的“中性外壳”，而是设计Agent记忆系统时和“选模型”同等重要的一根杠杆。
把上面五个问题拧成几句实操建议，大概是这样：
论文也很坦诚地留下了两个尚未解决的问题：
作者的态度很克制：这篇论文并不是说“文件系统记忆”注定行不通，而是把它从一条被默认相信、却从未被检验过的“假设”，变成了一整个可以被系统研究、系统调优的设计空间。
参考信息
还在为写 Agent 框架频频死循环、上下文爆炸而束手无策？我的新专栏 《从0 开始构建 Agent Harness》 将带你：
扫描下方二维码，开启从 0 开始构建Agent Harness 的实战之旅。
还在为“复制粘贴喂AI”而烦恼？我的新专栏 《AI原生开发工作流实战》 将带你：
扫描下方二维码，开启你的AI原生开发之旅。
商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。