Markdown内存上限

三个价值数十亿美元的独立人工智能代理平台汇聚在纯文本文件上进行内存存储。收敛验证了问题。他们共享的故障模式定义了接下来会发生什么。

Markdown内存上限

无人计划的融合

Manus 是一个面向消费者的人工智能代理。 Claude Code 是 Anthropic 的编码助手。 OpenClaw 是一个开源个人人工智能。不同的团队、不同的代码库、不同的业务模型。

所有三个都将代理内存存储在 Markdown 文件中。

Manus 使用“todo.md”清单,该清单在每个步骤后都会重写自身。 OpenClaw 使用“MEMORY.md”以及“memory/”目录中的日期文件。 Claude Code 使用范围为目录的分层“CLAUDE.md”文件,始终加载的内容最多有 200 行。

似乎没有人抄袭其他人。 DEV Community 上的 Yaohua Chen 称之为“趋同进化”。当三个在不同约束下的独立系统达到相同的架构时,该架构会告诉您有关问题的一些信息。

Micheal Lanham 在 2026 年 3 月记录了这种融合。他对所有三个系统的分析是我见过的对生产代理内存架构最彻底的公开比较。这些数据值得直接使用。

为什么文件是默认起点

显而易见的解释很简单。文件是人类可读的、可 git 跟踪的,并且不需要基础设施。真实但不完整。

更深层次的原因是LLM经济学。

Manus 联合创始人 Yichao “Peak” Ji 公布了这些数字。 Manus 为每 1 个输出令牌处理 100 个输入令牌。在 Claude Sonnet 上,缓存令牌的成本约为每百万美元 0.30 美元。未缓存的代币价格为每百万 3 美元。 10 倍的价差意味着投入成本占主导地位。任何提高 KV 缓存命中率的方法都可以节省真正的资金。

基于文件的内存是稳定的、可预测的文本,可以与 KV 缓存前缀很好地配合。仅追加上下文在调用之间很少发生变化,这意味着模型可以重用缓存的计算。每次都会组装不同上下文片段的数据库支持的 RAG 系统无法实现这种优化。

Manus 的“todo.md”模式是最明显的例子。代理在每个步骤后都会重写清单。这会将当前计划放置在最近的上下文窗口位置。长上下文中间的信息会被忽略。上下文末尾新重写的计划文件修复了没有检索基础设施的问题。

经济方面的争论超出了马努斯的范围。 Claude Code 将始终加载的内存上限限制为 200 行,因为内存文件每个会话都会消耗令牌。限制不是存储。这是注意力预算。文件可让您控制模型看到的内容以及它在上下文中的显示位置。

这些都不是偶然的选择。它们是具有成本意识的架构。

文件损坏的地方

Lanham 的文章对故障模式很诚实。诚实是分析中最有价值的部分。

上下文预算压力。 Claude Code 警告说,大型“CLAUDE.md”文件会降低模型的一致性。文件一直有效,直到它们变得臃肿且内部矛盾为止。 200 行上限是一个务实的解决方案,而不是一个解决方案。随着代理使用规模的扩大,文件会增长,并且自相矛盾,并且没有人知道事实的哪个版本是最新的。

并发性。 多个代理写入同一内​​存文件已损坏状态。 Lanham 直接指出:“当多个代理或用户需要访问同一内存时,并发文件写入可能会损坏数据。”单代理上限是真实存在的。大多数代理工作流程不会永远保持单代理。

无版本控制。 文件被覆盖。 OpenClaw 的内存压缩会触发静默代理轮转,在截断之前写入持久内存。压缩之前文件里有什么?未知。如果压缩版本丢失了一个事实,那么它就消失了。无观察记录。没有回滚。

无出处。 当特工写入记忆条目时,没有任何记录表明该条目的来源、时间或是否与上周写入的内容相矛盾。该文件是一个摘要。摘要掩盖了它们的成分。

无实体解析。 一个会话中为“Acme Corp”,下一个会话中为“ACME CORP”。代理每次都会从上下文窗口重新推断身份。没有稳定的ID。没有合并规则。没有规范实体。每个会话都是会话范围内的推理。

**没有模式限制。**任何代理或工具都可以将任何内容写入内存文件。没有验证。没有类型检查。不强制执行内存条目应包含的内容。糟糕的写作作为真理传播。

这些失败并不是假设的。它们由构建这些系统的团队记录。它们是基于文件的内存的操作上限。

均衡中的差距

Lanham 提出了一个四层的“平衡架构”。文件作为主要界面。积极卸载到磁盘。派生检索层(文件上的矢量索引)。当并发性和正确性需要时,明确升级到数据库。

前三层都有详细记录。第四个留给读者作为练习。

“升级到数据库”假设数据库解决了完整性问题。默认情况下,Postgres 不会为您提供版本化的观察结果。它不会为您提供来源链。它不会为您提供跨文档的确定性实体解析。它不会为您提供对代理编写的状态的架构约束。从 Markdown 文件转移到数据库表并不能解决“无版本控制”问题。它解决了“无并发访问”的问题。这些是不同的问题。

平衡在第三层和第四层之间存在间隙。在“适用于一个代理的降价文件”和“完整的数据库基础设施”之间缺少一层。具有完整性保证的结构化状态。无需自定义数据库架构。

OpenClaw 的架构暗示了这一点。它的混合检索、sqlite-vec 具有可配置的矢量/文本权重、时间衰减、MMR 多样化,比简单的文件搜索更加复杂。但它仍然将 Markdown 文件视为事实来源。索引是读取优化,而不是状态完整性层。

缺少的原语与我识别的相同运行我自己的代理堆栈:

  • 版本化观察。 每次写入都会附加,没有任何内容被覆盖。在任何时间点重建状态。
  • 出处。 每个事实都可追溯到来源、时间戳以及编写它的代理或人员。
  • 确定性实体解析。 基于稳定规则的规范 ID,而不是每次会话推断。
  • 架构约束。 写入验证。不良数据在进入商店之前被拒绝。

这些不是数据库功能。它们是状态完整性特征。您可以将它们构建在数据库之上。 Postgres 不会将它们开箱即用地提供给您。而且你根本无法从 Markdown 文件中获取它们。

文件才是真正的现任

Lanham 分析中最重要的战略见解不是关于文件与数据库。这是关于实际的竞争格局是什么样的。

内存基础设施公司针对检索问题筹集了数千万美元资金。 Mem0 筹集了 2400 万美元。 Letta 以 7000 万美元的估值完成了 1000 万美元的种子投资。 Zep 的 Graphiti 项目在 GitHub 上的星数突破了 20K。 MemPalace 采用本地优先、逐字存储的方法,在前两周就获得了 46K 颗星。它们解决了实际问题:跨部署的持久性、个性化、大规模检索和结构化召回。

但处理大多数代理交互的系统并未使用矢量数据库作为内存。他们正在使用文本文件。来自 30 亿美元规模平台的生产证据证实,真正的默认产品并不是现有的数据库产品。它是一个文件。

这改变了位移的故事。升级路径不是从矢量数据库到更好的数据库。它是从 Markdown 文件到结构化状态。需要状态完整性保证的人当前没有使用 Mem0 或 Zep。他们当前正在写入“MEMORY.md”。

迁移,而不是替换

Lanham 的结束建议本质上是正确的:“从 Markdown 文件开始。以后您可以随时添加数据库。”文件是一个合理的起始架构。经济支持他们。可检验性是真实的。简单性很重要。

问题是“以后”是什么样子。

我正在构建 Neotoma 作为升级路径。具有完整性的结构化状态保证了文件的完整性:版本控制、出处、实体解析、模式约束。

成本效率问题很重要。如果升级路径牺牲了使文件变得合理的 KV 缓存经济性,那么它就不是真正的升级。 Neotoma 的读取路径就是围绕这个约束设计的。代理通过 MCP 访问它。响应是注入到上下文窗口中的结构化文本,与模型从读取文件中看到的格式相同。实体快照在调用之间保持稳定。查询两次的同一实体将返回相同的文本,除非观察改变了它。稳定的文本意味着稳定的标记序列。稳定的令牌序列意味着 KV 缓存命中。

写入路径是经济上不同的地方,也是它们应该的地方。通过架构验证将观察结果写入结构化存储的成本比在 Markdown 文件中附加一行的成本更高。这种开销就是版本控制、来源和冲突检测的代价。问题是这些开销是否值得支付。如果您从未需要回答“我的特工上周二知道什么”或“哪个写入损坏了该实体”,那么不需要。降价是正确的。如果您需要这些答案但无法获得它们,那么写入路径成本是问题中最便宜的部分。

移民的故事很简单。您从“MEMORY.md”开始,因为它是正确的默认值。当您需要跨会话进行版本控制、并发访问、来源或实体解析时,您就会遇到上限。下一步不是“设置 Postgres 并构建自定义架构”。它是一个结构化层,可以为您提供这些保证,同时保留文件的有效功能:可检查性、简单性、本地优先操作。

拉纳姆记录的趋同进化验证了这个问题。三支总价值数十亿美元的团队到达了相同的架构并碰壁。墙壁定义了下一层。

7 最小阅读量Agent Architecture
分享