本文永久链接 – 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＋搜索Agent＋执行Agent”三角色围绕一个文件系统运作，声明式记忆和程序性记忆（技能）统一进同一套Store
  • 结构化整理唯一稳定的收益是搜索成本：材料量大时，整理过的记忆库能把检索花费砍掉一半以上
  • 但整理不等于答得更准：没有一种记忆形态在所有场景都赢，正确率的排名甚至会反直觉地翻转
  • 记忆库长什么样，主要是管理Agent这个模型自身的“性格”，而不是数据规模决定的
  • 好消息：记忆库随时间积累不会“用废”，反而越用越有用；坏消息：只有最强的模型才能守住“整理有序”这件事
  • 换工具集（比如从函数调用换成shell）对记忆库形态的影响，不亚于直接换一个模型

一个几乎被所有人忽略的问题

如果你最近关注过Agent产品的技术细节，大概率见过这样的设计：Agent把自己的长期记忆写成一个个Markdown文件，按主题分门别类地放进文件夹，需要的时候自己用类似ls、grep、view这样的工具去翻找。

OpenClaw的memory tool是这样，Claude Code里Agent自己维护的记忆文件夹也是这样，各家的“Skills”体系也是这样——记忆不再是一个专门设计的向量数据库或知识图谱，而是一套朴素到近乎“原始”的文件系统。

这套做法之所以流行，原因也很直白：编码Agent本来就活在文件系统里，用它顺手扩展Agent的记忆，几乎是零成本的选择。文件系统还天生具备层级结构——文件夹本身就是一套分类体系，人类可以直接打开来看、来改，可解释性拉满。

但学术界这些年做的事情几乎是另一条路：论文里更常见的是精心设计的“专用记忆表征”——分页式上下文管理、抽取出来的事实库、时序知识图谱、自我关联的笔记网络、摘要库、按嵌入向量组织的树……每一种都配了一套定制接口。相比之下，工业界已经大规模部署的“文件系统记忆”，反而是研究最少的那个。

这篇论文要问的问题非常朴素，却从来没人认真回答过：

  • 一个Agent，真的能在记忆持续增长、出现重复、矛盾、过时信息的情况下，把这个“文件仓库”管理得井井有条吗？
  • 就算管理得井井有条，这种“整理”真的能换来更好的效果吗？

论文速览

  • 标题：Filesystem-Based Memory for LLM Agents: Organization, Evolution, and Sustainability
  • 机构：UIUC、UC San Diego、UC Merced、Adobe Research、Texas A&M University
  • 时间：2026年7月29日提交，arXiv:2607.26637
  • 一句话结论：整理记忆库能稳定换来更便宜的检索（材料量大时检索成本能腰斩），但今天的模型还远不能把“整理得好”直接兑现成“答得更准”；而且决定记忆库长什么样的，往往不是数据规模，而是模型本身的“性格”，换一套工具集甚至比换一个模型影响还大。

把记忆形式化：三个角色，一个Store

论文做的第一件事，是把“文件系统记忆”这套业界实践抽象成一个可以做实验的最小模型。

一个记忆库（memory store）被定义为一棵有根的文件路径树，每个文件由三部分组成：路径、一句话描述、正文内容。文件夹没有自己的内容，只是路径的公共前缀；文件夹名、文件名，加上文件内部的Markdown标题，一起构成这个Store的“分类体系”（taxonomy）——这套体系的名字和一句话描述，就是Agent在打开文件之前唯一能看到的路标。

围绕这一个Store，论文定义了三种角色：

  • 管理Agent（management agent）：负责把新进来的内容整合进Store，同时承担维护责任——可以新建、改写、合并、拆分、移动、删除任何东西。记忆库能不能保持“健康”，主要看它。
  • 搜索Agent（search agent）：面对一个固定的Store回答问题，答案必须带引用（文件路径、甚至具体的行号），做到“言之有据”。
  • 执行Agent（execution agent）：只在“技能记忆”场景里出现，负责实际完成任务，它的任务轨迹会被管理Agent蒸馏成可复用的技能文件，检索到的技能又反过来喂给它自己用。

三者所有的读写操作都必须经过一个“工具集”（tool harness）——可以是几个简单的文件操作函数（读、建、改、插、删、改名），也可以是更强力的沙箱Shell，甚至加上正则搜索、关键词排序搜索。这个工具集本身也是论文重点研究的一个变量。

这套三角色框架有一个很聪明的地方：它用同一套定义，同时覆盖了两种记忆——声明式记忆（对话中的事实、偏好、事件）和程序性记忆（从经验中蒸馏出来的技能），不用为“记事实”和“记怎么做”分别设计两套系统。

一份“合格”的记忆文件应该长什么样

既然要评价Agent整理记忆的好坏，总得先有个标准。论文给出的答案是五条“分类体系契约”（taxonomy contract），几乎所有管理Agent的系统提示词里都写了这五条：

  1. 同级可区分：同一个父级下的东西，光看名字（最多加一句话描述）就能分清楚，不用打开文件。
  2. 同级要相关：放在同一个父级下的东西，应该是自然而然属于一类的。
  3. 父级要覆盖子级：一个目录下的所有内容都应该落在这个目录名所声明的范围内，反过来，这个范围内的内容也应该尽量都放在这个目录下——这样往下钻探时，搜索范围会不断收窄而不会漏掉目标。
  4. 距离要反映相关性：两份内容越相关，在这棵树里的位置就应该越近。
  5. 结构服务于检索，而非自我服务：多加一层目录，是因为它真的有助于定位信息；帮不上忙的层级就是纯粹的负担。

这五条原则说白了就是“一个称职的图书管理员会怎么整理书架”，论文后面几乎所有关于“记忆库整理得好不好”的量化指标，都是在给这五条原则打分。

怎么测：四个对话基准 + 一个具身任务，六种记忆形态打擂台

为了让结论站得住脚，作者设计了相当扎实的实验矩阵。

对话记忆（回答关于长对话内容的问题，带引用出处）：

  • LoCoMo：长期多轮对话问答，长记忆研究里的“默认标准考卷”
  • PersonaMem（32k / 128k两档上下文长度）：人物设定丰富的对话流，选择题形式，考的是随流长增加信息量的场景
  • REALTALK：21天真实人类聊天记录，用来验证结论在“接地气”的真实对话里是否依然成立

技能记忆：

  • ALFWorld：140个居家具身任务，执行Agent顺序完成，记忆库只能从“之前做过的任务”里积累经验，绝不能提前看到后面的任务（严格的“防作弊”协议）

六种记忆形态覆盖了从“完全不整理”到“完全交给Agent自主整理”的整个光谱：

记忆形态 说明
闭卷（Closed-book） 完全不给记忆，测模型自身知识的下限
分块检索（Chunk retrieval） 传统RAG做法：切块+BM25排序检索
逐字转储（Verbatim dump） 一次会话一个文件，内容原样保留，零模型成本，“零整理”基线
分文件夹归档（Foldered sessions） LLM只负责设计文件夹分类，把逐字转储的文件搬进去，不改一个字
重组存档（Reorganized store） LLM对逐字转储的内容重新拆分合并，内容分布会变
Agent自主整理（Agent-curated store） 从空白开始，管理Agent自己决定写什么、怎么组织，内容和结构一起变

一个有意思的插曲：作者发现，“重组存档”如果不特别叮嘱，模型默认的重组行为会悄悄丢细节——重写的过程中内容明显缩水。于是他们做了两个版本对比：一个是不加约束的“压缩版”，一个是加了“必须保留每一条事实”这条硬性规则的“保留版”，专门用来量化这种“模型自己的坏习惯”到底会造成多大损失。

技能记忆这边同样设了五档，从“完全没有记忆”到“整理成技能+经验笔记+按任务动态生成指导”逐级递进，细节这里不展开，重点在下面的结论。

五个问题，五个不那么符合直觉的答案

论文围绕五个研究问题（RQ1-RQ5）展开，两套实验场景（对话记忆 / 技能记忆）各回答一遍。

RQ1：Agent自己整理记忆，会长成什么样子？

结论是：记忆库长什么形状，主要是模型自身的“性格”，而不是材料多少决定的。

作者做了两组对照实验来拆解“规模”和“模型”这两个变量：

固定同一个管理模型，把材料量从PersonaMem 32k档拉到128k档（材料量大约变成5倍），记忆库并没有像常识预期的那样“分裂”成更多文件——恰恰相反，文件夹和文件层反而变薄了，层级关系转移进了单个文件内部的标题结构里，也就是所谓的“整理不是分片，而是压缩重排”。

反过来，固定材料量不变，只换管理Agent这一个模型（从小到大的三档），同一份对话在不同模型手里，会变成完全不同的三种树形结构——最小的模型倾向铺成浅而广的文件森林，中等模型几乎把所有层级都塞进两个文件的标题里，最大的模型则长出了整个实验里最深的树，还会用大量的“交叉引用”把散落的文件重新缝合起来。

技能记忆那边结论更极端：管理模型越强，技能库越“精炼”——最强模型把140次任务尝试蒸馏成十几个高密度的文件，最弱的模型反而铺开成上百个近乎扁平的文件。两种记忆场景，模型能力都决定性地改变了记忆库的形状，但方向截然相反：对话记忆是“非单调地忽大忽小”，技能记忆则是“越强越精简”，单调递减。

一句话总结：别指望“数据越多，记忆库自然长得越整齐”，真正决定形状的是那个负责整理的模型本身。

RQ2：整理，到底值不值？

这是全篇最反直觉的部分。

先说好消息：结构化整理唯一稳定兑现的好处，是检索便宜。在材料量最大、最密集的场景下（PersonaMem两档），经过重组或Agent整理的记忆库，能把每次检索的花费砍到逐字转储版本的一半甚至更低；材料量本来就不大的场景下，这个优势会缩水到几乎持平。背后的机制也很清楚：整理过的记忆库虽然搜索轮次和调用次数变多了（因为搜索Agent要沿着结构一步步导航，而不是简单扫一遍），但每次读取拉取的内容量小得多，总体反而更省。

再说坏消息：正确率没有一种记忆形态能通吃所有场景，排名甚至会和“整理得越细致越好”的直觉正好相反。全场最稳定的反而是成本最低的“分文件夹归档”——它只是把原始转储文件搬进LLM设计的文件夹，一个字都没改，却在多个基准上追平甚至超过了完全由Agent自主整理的版本；而“Agent自主整理”版本在PersonaMem 32k档上是全场表现最差的记忆形态之一，甚至不如什么都不整理、只是简单分块检索的传统RAG做法。

“重组存档”的两个版本（压缩版 vs. 保留版）在不同基准上甚至会反着来：在长对话和真实聊天记录里，保留每条细节明显更好（真实聊天场景下，压缩版的正确率几乎腰斩）；但在信息密度更高的PersonaMem 32k档上，反而是压缩版本表现更好，因为更紧凑的库更容易搜。

一句话总结：整理记忆，买到的是“查得快”，不是“答得准”；到底该不该整理、整理到什么程度，取决于材料本身，而不存在一个放之四海而皆准的最优策略。

技能记忆场景的结论同样耐人寻味：谁来“消费”这份记忆，会直接决定哪种形态更优——面对能力强的执行Agent，把原始经验日志（一字不改的episode log）直接甩给它效果最好；面对能力弱的执行Agent，反而是精炼蒸馏、按任务实时生成指导的版本更管用，两者差距能达到十个百分点左右。换句话说，同一份记忆，喂给“学霸”和喂给“学渣”，最优的呈现方式完全不同。

RQ3：模型越强，记忆用得越好吗？

在对话场景里，答案要拆成两半看：管理Agent的能力，买到的是“整理风格”，不是“答案质量”；搜索Agent的能力，才会直接兑现成答案质量。 也就是说，换一个更强的模型去整理记忆，记忆库的样子会明显不同，但最终搜索出来的答案对不对，跟整理模型的强弱关系不大；反倒是负责搜索、回答问题的那个模型，越强答得越准。

但有一个例外：当“写”这件事本身出了问题时，模型能力就会直接体现在答案质量上。论文发现，在某个基准上，管理Agent经常没能把“用户偏好发生变化”这件事，正确地记录成一条“带日期的更新”，导致过时的事实被当成“当前仍然成立”的信息留在库里——换一个更强的模型去执行同样的整理指令，能挽回大约一半的损失；但如果记忆库本身已经服务得不错，换模型就不会带来任何提升了。

技能记忆场景则揭示了一种“阈值效应”：当需要把经验蒸馏成可复用的程序时，模型能力表现为一道门槛——一旦跨过这道门槛，记忆库里到底装了什么内容，就比执行这一步的模型是谁更重要了。

RQ4：记忆越攒越多，会不会“用废”？

好消息是：在论文测试的时间跨度内，记忆库不但没有变差，反而越用越有用，而且积累下来的经验，可以在一定程度上替代执行Agent自身能力的不足——哪怕执行Agent本身比较弱，只要记忆库里攒够了经验，照样能把任务完成得更好。

Store的“健康度”整体也站得住：对话场景里，记忆库的文件基本是在流程早期就建好的，后续只是不断编辑，几乎不会删除文件；技能记忆场景里，早期形成的记忆同样能长期存活，能力更强的管理Agent会倾向于“原地维护”已有文件，而不是不断新建替换。

但坏消息也很直接：“整理得好不好”这件事，会随着记忆库变大而逐渐失守——绝大多数管理Agent，都会在规模增长的过程中让分类体系逐渐松散、走样，只有实验里能力最强的那个管理Agent，才能一直守住这条“整理契约”。

而且，整理记忆这件事的边际成本从不会随着经验增加而变便宜——每新增一段经验，管理Agent还是要花差不多的精力去消化它；唯一一项会随着规模扩大而持续膨胀的“负债”，是那种“什么都保留、来者不拒”的逐字经验日志——检索时不得不把所有历史都扫一遍。

RQ5：换个工具集，影响有多大？

这一条对做工程实现的读者尤其有参考价值：只是给Agent多加一个工具，会改变它的行为习惯，但不一定改变最终结果；而彻底换一套工具集，对记忆库形态的重塑力度，不亚于直接换一个模型。

比如在长对话场景里，换成更偏“分片、依赖交叉引用”的工具集会让记忆库变得更零散但彼此勾连更紧密；而在技能记忆场景里，同样是换工具集，方向却是相反的——工具集变了会让记忆库变得更“整合、集中”，并且直接带来更好的任务结果。也就是说，工具集不是一层可以忽略的“中性外壳”，而是设计Agent记忆系统时和“选模型”同等重要的一根杠杆。

给做Agent Memory的工程师们的几点大白话总结

把上面五个问题拧成几句实操建议，大概是这样：

  1. 不要迷信“越整理越好”。如果你的场景里原始材料本来就不大，简单地把会话按主题分好文件夹（甚至不改动内容本身），可能比让Agent“自由发挥”式地重新组织记忆更划算、更稳。
  2. 整理的核心收益是省钱，不是提分。如果你的目标是压低检索成本（尤其是材料量本来就很大的场景），投入整理是值得的；如果你的目标是提升答案准确率，先别指望“整理”能单独扛起这个任务。
  3. 谁在消费记忆，决定了记忆该长什么样。给一个能力强的执行者，原始、完整的经验记录可能比精炼摘要更好用；给一个能力弱的执行者，反而应该多做蒸馏和实时定制化的指导。
  4. 管理Agent的模型强弱，先决定风格，不直接决定质量——除非“写”这一步本身出了错（比如没能正确记录状态变更），这时候换个更强的模型才会立竿见影。
  5. 工具集是一根被低估的杠杆。同一个模型，换一套读写工具，记忆库的组织方式和最终效果都可能发生不小的变化，值得单独作为一个调优维度来看待，而不只是“随便挑一个能用的工具就行”。
  6. 重组/压缩记忆这件事要格外小心。模型在“自由重组”记忆时有天生的压缩倾向，容易悄悄丢细节，如果你的场景要求不能丢信息，最好在提示词里明确写下“必须保留每一条事实”这类硬性规则。

小结：局限与开放问题

论文也很坦诚地留下了两个尚未解决的问题：

  • 现有的问答质量评测，基本上“看不见”记忆库的组织形态——评测只看最终答案对不对，而不太关心这个答案是从多整洁的记忆库里挖出来的，这使得“组织本身值不值”这件事很难被直接量化。
  • 目前的实验时间跨度依然局限在“一段对话”或“一条任务链”的量级，距离真正跨越数月、模拟人类记忆一生演化的长周期场景，还有相当大的差距——而这恰恰是“持续学习型Agent”最终要面对的场景。

作者的态度很克制：这篇论文并不是说“文件系统记忆”注定行不通，而是把它从一条被默认相信、却从未被检验过的“假设”，变成了一整个可以被系统研究、系统调优的设计空间。

参考信息

还在为写 Agent 框架频频死循环、上下文爆炸而束手无策？我的新专栏 《从0 开始构建 Agent Harness》 将带你：

  • 抛弃臃肿框架，回归“驾驭工程 (Harness Engineering)”的第一性原理
  • 用 Go 语言手写 ReAct 循环、并发拦截与上下文压缩引擎等，复刻极简OpenClaw
  • 构建坚不可摧的 Safety Middleware 与飞书人工审批防线
  • 在底层实现 Token 成本审计、链路追踪与自动化跑分评估
  • 从“调包侠”进化为掌控大模型边界的“AI 操作系统架构师”

扫描下方二维码，开启从 0 开始构建Agent Harness 的实战之旅。

还在为“复制粘贴喂AI”而烦恼？我的新专栏 《AI原生开发工作流实战》 将带你：

  • 告别低效，重塑开发范式
  • 驾驭AI Agent(Claude Code)，实现工作流自动化
  • 从“AI使用者”进化为规范驱动开发的“工作流指挥家”

扫描下方二维码，开启你的AI原生开发之旅。

商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。