Agent Memory as a File Format:为什么 2026 年的 Agent 内存应该回归文件

一、为什么 Agent 内存这个老问题突然又被提起

2026 年 8 月 31 日,Cal Paterson 在 HN 发布 "Agent memory as a file format"(HN 191 pts),提出 memoryfield——一个把 Agent 内存当作"数据"而非"过程"的极简文件格式。

这篇文章击中了一个长期被复杂化的问题:现有 Agent memory 系统几乎都失败了。失败的根源是把 memory 当作多阶段处理流水线(process),而不是模型可以直接读取的数据(data)。

同期,NevaMind-AI 的 memU(14.4k stars,2026-01 发布)用"file-based memory, works like skill"的另一种路径,把 Agent memory 推到了可跨 Agent、跨设备共享的层面。

两件事放在一起,可以看到 2026 年下半年 Agent memory 领域的清晰共识:memory 应该回归文件。

二、Cal Paterson 批判的三种现有 memory 设计

Cal Paterson 在文章里把现有 Agent memory 系统分成三类,每类都有问题:

类别一:vendor lock-in 的 harness 记忆

"Said lab desperately wants to transition out of the (highly competitive) 'API business' and into the (much more lucrative) 'platform business'. This form of system usually works by mining information out of your conversation history."

中文:这类系统通常从对话历史里挖信息,目的是把用户绑死在厂商平台上。

主要问题:记忆的是"你",不是"世界"。对话历史是关于用户的,但 Agent 真正需要的 memory 大多是关于世界的事实——这两类信息价值完全不同。

类别二:过度复杂的 pipeline

"I know of one prominent system that needs pgvector, a Neo4j graph database and an LLM of its own just to decide what's worth remembering."

中文:有家头部系统需要 pgvector + Neo4j graph DB + 自己的 LLM 来决定什么值得记住。

主要问题:1) 运维复杂 2) 模型困惑 3) 不能随模型升级扩展。复杂的 pipeline 让 Agent 在调用时困惑——本来 Agent 看一眼文件就能用的信息,被塞进了三层数据库。

类别三:High Modernist 理性主义

"This kind systematically strips information from its context and leaves it isolated and senseless to the agent (and you)."

中文:这类系统系统性地把信息从上下文剥离,留下孤立、Agent(和你)都看不懂的内容。

主要问题:过度抽象 = 失去上下文。把 memory 简化成"distilled facts"看似干净,但 Agent 真正需要的是带语境的原始材料,不是脱水的标签。

三、Cal Paterson 的核心洞察:memory 是 data 不是 process

Cal Paterson 引 Brooks 的话:

"Show me your flowcharts and conceal your tables, and I shall continue to be mystified. Show me your tables, and I won't usually need your flowcharts; they'll be obvious."

中文:给我看流程图却藏起表,我继续困惑。给我看表,通常我不需要流程图——一切都会明了。

memoryfield 的设计是把 memory 当数据(tables),而不是 pipeline(flowcharts)。具体结构:

my-memories.memoryfield.zip
├── carbon-fibre-woks.md
├── finnish-bureaucracy-tips.md
├── wec-2026-season-notes.md
└── nomic-embed-text-v1.5.sqlite3

一个 memoryfield 是:

  • Markdown "pages"(可选 YAML frontmatter + 可选 SQLite 向量索引)
  • 打包成 zip
  • 任何能存文件的地方都能存(S3 / Syncthing / GitHub)

这个设计的 4 个核心决策:

决策 1:用 prose 不用 chunks/facts

  • Agent 写 memory 时直接写 Markdown,不需要 chunk/enrich/double-summarize
  • 软上限 ~8KB(约 2000 token,正好一段中等长度的杂志文章)
  • 想写更多内容,就加更多 pages——Agent 不缺加 page 的能力

决策 2:semantic jump 不用 graph walking

  • 批判 Karpathy wikis 的"hyperlinked markdown + AI 走 graph"模式
  • graph walking 慢(每步 N+1 个 tool call,2-3 秒/步)且不可靠(依赖链接文字 + 标题元数据)
  • memoryfield 用 semantic search:2 个 tool call就能找到全部相关 page
  • 现代模型都能并行读全部相关 page,一次性塞 context

决策 3:more model, less mechanism

  • 故意避免复杂的 API 和数据库
  • Agent 自己决定怎么访问 memory(用 perl grep、用 SQLite 查内联 CSV)
  • Agent 本身就是 bash + Markdown + SQLite 专家(这些都在训练数据里)
  • "low mechanism" 让 memory 系统随模型升级自动变好——不需要重写 pipeline,模型升级直接带来更好的 memory 使用方式

决策 4:开放格式

  • RFC-style spec 文档化格式
  • 任何 harness / / sandbox / 传输都能用
  • 核心哲学:memory 应该属于用户,不属于 vendor

四、memU 的对应路径:跨 Agent 跨设备共享

NevaMind-AI 的 memU(14.4k stars)走的是稍微不同的路径:跨 Agent、跨设备共享的 LLM wiki。

核心特征:

  • Agent-driven memory system——Agent 自己管理 memory
  • 自动从 agent history 提炼 reusable skills
  • 核心逻辑只有 500 行——inspect + understand + adapt
  • 支持 9 个 Agent 适配:Codex / Claude Code / Cursor / OpenClaw / Hermes / WorkBuddy / pi 等
  • 跨 macOS / Windows 平台
  • 提供 `memu.so` 在线服务(free + unlimited)

memU 跟 memoryfield 的关键差异:memU 提供云服务, memoryfield 是纯本地。memU 把"跨 Agent 跨设备共享"做成了产品,memoryfield 把"格式开放"做成了 spec。

五、为什么"memory as a file"是 2026 年的正确方向

把 memoryfield 和 memU 放在一起看,可以看到三个深层判断:

判断一:memory 应该是数据,不是 process

  • 这是 Brooks 早就提过的工程原则
  • Agent 的"memory process"太多层、多阶段、多模型——既增加成本又降低效果
  • 直接把 memory 写成 markdown + SQLite 索引,模型直接读,是最简、最有效的方案

判断二:memory 应该是文件,不是 API

  • 文件的好处:可读、可改、可移植、可 git 版本控制
  • API 的坏处:vendor lock-in + 调用成本 + 不可调试
  • Cal Paterson 原文:"Memoryfields then, being a 'low mechanism' system (just a file format), gives agents much greater latitude to invent their own access patterns."

判断三:memory 应该 portable, 不是 vendor-specific

  • 你在不同 Agent 之间切换时,memory 应该跟着你走
  • 不是"ChatGPT 的 memory 只能在 ChatGPT 用,Claude 的 memory 只能在 Claude 用"
  • 用户拥有自己的 memory 资产,不是租给 vendor

六、对企业的现实启示

短期(立刻):

  • 重新评估现有 Agent memory 系统——如果你的 memory 系统需要 pgvector + Neo4j + 单独 embedding 模型,考虑大幅简化
  • 试试 memoryfield 思路——让 Agent 把 memory 直接写成 markdown,配 SQLite 向量索引,500 行核心代码搞定
  • 关注 memory 可移植性——用户切换 Agent 时,memory 能不能跟着走?如果不能,这是 vendor lock-in 风险

中期(3-6 个月):

  • 建立"个人 / 团队 memory 资产"——把 memory 当作数字资产,定期 backup、版本控制、跨设备同步
  • 关注 memU / memoryfield 这类开放标准的演进——未来 1-2 年可能有"Agent Memory Standard"出现,现在加入是占位
  • 企业 IT 关注"Agent memory 合规"——memory 里有用户信息、商业机密,怎么审计、加密、保留、删除?

长期(1 年+):

  • "Memory as a file"会成为 Agent memory 的事实标准——太简单、太有效,不可能不被广泛采纳
  • vendor lock-in 在 memory 层会瓦解——用户不再被绑死在特定 Agent
  • Memory 基础设施成为新的投资方向——Syncthing-like sync、跨 Agent 翻译、隐私保护会成为新创业赛道

七、回到题目:Agent memory 应该回归文件

2026 年下半年的 Agent memory 讨论,有一个清晰的反共识:把 memory 弄复杂是错的,弄简单才对。

memoryfield 的核心论点是:Agent 自己就懂 Markdown + bash + SQLite,何必搞三层数据库 + 独立 embedding 模型 + 复杂 API?

memU 的核心论点是:memory 应该是用户拥有的资产,跨 Agent 跨设备,不绑定 vendor。

两个论点不冲突——一个是"格式应该简单",一个是"所有权应该属于用户"。组合起来就是:

Memory 是用户的、用文件存的、Agent 直接读的、跨平台可移植的。

任何还在搞"三层数据库 + vendor lock-in + 高 mechanism pipeline"的 Agent memory 系统,都是在逆 2026 年的方向走。

对个人用户:用 memoryfield 自己存 memory,跨 Agent 携带。

对企业:关注 memU 这类"跨 Agent memory"框架,为未来 Agent 切换时 memory 能跟着走做准备。

2026 年下半年,"Memory as a file" 是 Agent memory 领域的明确方向。跟当年的"SQL 回归文件"(SQLite)、"配置回归文件"(YAML/TOML)、"文档回归文件"(Markdown)一样,最有效的方案往往是最简单的。Agent memory 也是如此。