基于文件系统的 LLM 智能体记忆：组织、演进与可持续性

  • 关联论文：2607.26637
  • 作者：Tom
  • 更新：2026-08-01

一句话结论

当前 LLM 智能体普遍用「把 markdown 文件塞进文件夹」作为长期记忆，但实验证明：这种默认方式在记忆不断增长时组织会退化、没有最强管理 Agent 就无法维持收益——而且换一套工具集对记忆结构的影响几乎和换模型一样大。

解决什么真问题

现实部署的 LLM 智能体越来越依赖文件系统记忆（filesystem-based memory）：把记忆存成目录树中的 markdown 文件，通过通用文件工具读写和重组。这已经成为事实上的默认方案。但研究社区几乎完全跳过这个媒介，去研究定制化的记忆表示和检索——留下两条核心假设从未被系统验证：

  1. 可维护性假设：随着记忆累积、冲突、过时，智能体能否依然把文件系统组织好？
  2. 效益假设：这种组织是否真的值得付出（写代码、维护目录结构所消耗的 token/时间）？

本文首次对这两条假设做了系统性实验。

核心方法

设定建模：围绕一个 shared memory filesystem 定义三种角色： - Management Agent：负责整合和组织新来的内容，决定如何分类、合并、更新文件 - Search Agent：接收查询，从记忆中检索相关内容并返回带引用的答案 - Execution Agent：执行具体任务轨迹（trajectories），将结果蒸馏成 skill 文件

这三种角色统一在一个文件系统 store 中，declarative memory 和 skills 不再分离。

实验变量（五个维度）： | 维度 | 取值 | |---|---| | 记忆形态 | Agent 组织层级 / 原文 dump / chunk 检索 | | 流规模 | 短对话 / 长对话（随记忆增长累积） | | 工具集 | 沙盒 shell / memory-tool 风格函数 / 多种搜索工具 | | Management Agent 强度 | 强（如 GPT-4o）/ 弱（如 GPT-4o-mini） | | Search Agent 强度 | 强 / 弱 |

评估指标： - Answer Quality：答案质量 - Cost：token 消耗（检索经济性） - Store Health：记忆组织的健康程度（文件结构是否清晰、有无过时/冲突内容）

关键实验与数据

  • 记忆组织的核心收益是检索经济性：当记忆体量大时，有组织的 store 比 verbatim dump 检索成本下降约一半（~50% cost reduction）⚠️ 存疑：具体对比数字原文未完全公开，"约一半"来自摘要描述，具体场景（chunk size、检索库类型）未注明
  • 但这个收益依赖最强的 Management Agent：当 Management Agent 较弱时，组织效果会随记忆增长而退化——所有被测 Agent 均无法逃脱这一趋势
  • 组织本身不等于更好的答案：最强的组织形态（Agent-organized hierarchy）并不一定带来最高答案质量，说明「结构好看」和「记得准确」是两回事
  • 工具集是强力杠杆：单独更换工具集，对记忆 store 结构的塑造效果几乎和换模型一样大。这意味着工具设计本身就是记忆架构的核心组成部分
  • 当前最强 Agent 也无法维持默认承诺：即使最强配置的 Agent，在长程增长实验中 store organization 也会衰退

亮点与局限

亮点： - 首个对「文件系统作为 LLM 记忆媒介」的端到端系统研究，不是理论推导 - 五大维度的交叉实验设计（记忆形态 × 流规模 × 工具集 × 管理/搜索 Agent 强度），覆盖了几乎所有实际部署时会遇到的变量组合 - 揭示了一个反直觉的结论：组织收益主要在 cost，不在答案质量——这对工程决策有直接指导意义 - 工具集的效果暗示：记忆系统的瓶颈可能不在模型，而在工具抽象

局限： - 实验用特定 benchmark（长对话 benchmark + 具身任务），具体场景的泛化性待验证 - 管理/搜索/执行三种角色的划分是论文自定义的，不一定对应所有实际部署架构 - 记忆形态（hierarchy vs. dump vs. chunk）的对比实验中，chunk 检索方案依赖外部检索系统，其效果可能受检索质量影响 - Store Health 的量化指标文中未完全公开具体定义，可能存在主观性 - ⚠️ 未量化：组织退化速度（多少天后开始显著衰退）未公开；最强/最弱 Agent 的具体 cost reduction 数字差距未公开

对工程落地的启发

  1. 不要假设「智能体会自然维持记忆组织」：当智能体需要长期运行（数周/数月），必须显式设计组织维护机制，或者定期人工介入重建组织
  2. 如果 cost 是瓶颈，组织记忆值得做；如果 answer quality 是瓶颈，单纯组织文件树帮助有限，需要配合更好的检索策略
  3. 工具集即记忆架构：在设计 Agent memory 系统时，工具抽象的选择（沙盒 shell vs. memory function API）会直接影响记忆的结构和质量，应视为架构决策而非工程细节
  4. 混合存储可能更优：将 filesystem-based memory 和 structured retrieval 结合，各自发挥所长（文件系统的灵活性 + structured retrieval 的精确性）

与同方向工作的关系

  • 与 Agent Memory / RAG 文献正交：之前工作关注「如何从记忆中检索」，本文关注「默认存储介质本身的假设是否成立」
  • 与 Skill Library / Tool Learning 文献相关：本文把 skill distillation 纳入同一个 filesystem store，模糊了「记忆」和「能力」的传统边界
  • 与 Personal LLM 研究呼应：Sizhe Zhou 等作者同时活跃在 Personal LLM 领域，本文是同一研究小组对「个人 AI 助手长期记忆」问题的系统性实证

适合谁读

  • LLM Agent 系统工程师：评估或搭建生产级 Agent memory 系统的从业者
  • RAG 方向研究者：理解文件系统作为记忆媒介的 baseline 性能上限
  • Personal AI / 数字分身研究者：关心长期运行记忆健康性的研究者
  • AI Infrastructure 工程师：在做 memory tool、skill library 等基础设施设计时，需要了解工具集对 store shape 的隐性影响

工程落地与核查（Jay）

实际怎么落地

1. 判断你的场景是否值得文件系统记忆

优先考虑 filesystem-based memory 的场景： - 需要长期上下文积累（月度/年度维度的个人助手） - 需要 human-in-the-loop 可审计性（文件可被用户直接查看/修改） - 需要跨 agent 共享记忆（多 agent 协作写同一个 store）

不建议 filesystem memory 的场景： - 短程任务（单次对话内完成，KV cache 更高效） - 高频短查询（检索延迟 > 综合收益） - 需要强一致性保证的场景（文件系统无事务语义）

2. 最小可跑实现方案

# 基础 filesystem memory store 结构示例
memory-store/
├── declarative/       # 事实性记忆（按 topic 组织）
│   ├── research/
│   └── preferences/
├── skills/            # 可执行 skill 文件
│   └── README.md
├── health.json        # Store Health 元数据（手动维护）
└── index.md          # 顶层索引（Management Agent 维护）

# 关键原则：
# 1. 单一职责：每个文件只包含一个 topic 的记忆
# 2. 定期压缩：每月执行一次 merge + prune
# 3. 管理 Agent 不做执行：分离 Management 和 Execution 角色

3. 防止组织退化的工程策略

  • 定期强制重组（Scheduled Re-org）：每 2-4 周运行一次专门的"记忆整理"任务，由 Management Agent 重写 index.md 并合并过时文件。不要依赖运行时累积的组织，因为实验证明它会自然退化
  • ⚠️ 坑：Re-org 任务本身消耗 token，需要算进 cost budget；重组期间记忆不可用（需锁或版本切换）
  • 文件级版本控制：用 git 管理记忆 store，每次重组后 commit，方便回滚 bash cd memory-store && git add -A && git commit -m "reorg-$(date +%Y-%m-%d)"
  • Store Health 自动化监控：在 Management Agent 每次写操作后检查：文件总数增长率、冲突文件数量、过时文件比例；超过阈值则触发告警 python # 伪代码：Store Health 监控 def check_store_health(store_path): stats = analyze_store(store_path) issues = [] if stats.file_count_growth_rate > 0.3: # 月增长率 issues.append("growth_rate_anomaly") if stats.outdated_ratio > 0.2: issues.append("high_outdated_ratio") if stats.conflict_count > 5: issues.append("too_many_conflicts") return issues
  • 双层检索：Search Agent 先用轻量 embedding 检索，再用文件系统 glob 做精确过滤，兼顾 cost 和精度

4. 工具集选择的工程考量

论文发现工具集对 store shape 的影响与换模型相当，具体选型建议：

工具集 适用场景 风险
沙盒 shell（ls/mkdir/cat） 通用性强，灵活性高 缺乏语义，Search Agent 检索质量低
memory-tool API（专用函数） 检索质量高，语义明确 迁移成本高，工具定制开发
混合（shell + tool） 平衡灵活性和质量 架构复杂度高

5. 关键工程坑点汇总

坑点 描述 解决方案
记忆丢失 Management Agent 重写时误删文件 git 版本控制 + 写前备份
长程退化 记忆持续增长后组织崩溃 强制定期重组（Schedule Re-org）
检索幻觉 Search Agent 返回的文件内容已过时 每次检索验证 mtime，过时则警告
token 爆炸 verbatim dump 的 context 随记忆线性增长 组织后检索 + 动态 chunk 策略
跨 agent 竞争写 多 agent 同时写同一 store 导致冲突 写锁（文件锁或 DB 事务）或按角色分目录

6. 未解决的工程问题

  • 论文未给出「组织退化开始显著」的临界时间点，无法做预防性调度
  • Store Health 的自动化量化指标未公开，工程实现时需自行定义（如：文件增长率、重复度、过时率三指标加权）
  • 工具集切换的迁移成本（从 shell 到 memory-tool API 的实际工程量）无数据，迁移决策无量化依据
  • 多 agent 共享同一 filesystem store 的并发安全性问题（race condition、文件锁开销）未讨论