在B轮融资之前，不要使用.md文件

几周前，我和一位旧金山初创公司的创始人聊过，他们正在构建垂直型智能体。当时他们只有一位生产环境客户，而那个单一客户的智能体记忆已经积累了1000多个Markdown文件。工程师们技术过硬、迭代飞快，但他们确实还没认真思考过随着公司成长如何扩展这一架构。这无可厚非——我们都曾如此：先写粗糙的代码去验证产品市场匹配，然后再重构成正经代码。

长话短说：又多了几个客户之后，各种权宜之计开始堆积。一个YAML模式的权限配置文件，一个在检索时强制执行的脚本，一个当两个智能体写入同一文件时的合并解析器，一张用于追踪的PostgreSQL表，一个手工维护的文件间交叉引用图。每一个单独看都合情合理，但合在一起，它们悄无声息地成了拖慢产品每一次变更的瓶颈。

于是他们重新设计了整个记忆层，这一次，要为他们的工作流构建一道护城河。

我见过太多创始人最终走上了同样的路。

如果你在构建你期望能在生产环境中运行、跨团队、跨时间的智能体，你也会遇到这个问题。如果你已经走在这条路上，你很可能已经开始打补丁了，却还没意识到自己是在重建什么。

我和别人就这个话题聊过太多次，已经摸清套路了。以下是我最常被问到的五个问题，以及通常听到的回答。

Q1: 用memory.md怎么做权限管理？

A1: 每个主题一个.md文件，每个文件配上文件系统ACL。

真实系统中的权限不是按主题划分的，而是按实体和属性划分的。用户A可以看到客户X的联系信息，但不能看到他们的合同条款。你得为每个 (实体, 敏感度级别) 组合准备一个文件。这会产生组合爆炸。

A2: 将权限编码为前置元数据，在检索时过滤。

现在你的检索层需要在LLM看到内容之前先解析、遵守并强制执行ACL。这相当于在一个文件存储里嵌入了一套访问控制系统。一旦出错，数据就会泄漏到LLM的上下文窗口中。更糟的是，“睡眠”优化（Dream）会合并跨文件的内容，此时你的优化器也需要理解权限，否则它会把敏感内容混入共享摘要中。

A3: 按权限边界划分独立的记忆存储。

这样一来，你就失去了让记忆变得有价值的跨域推理能力。智能体无法回答“在我能看到的所有信息中，有哪些规律浮现？”——因为你已经把知识物理分割了。

Q2: 多个智能体如何与memory.md交互？

A1: 文件锁：一次只允许一个智能体写入。

你已序列化了整个记忆层。延迟会随智能体数量线性增长。而且锁解决不了语义冲突：当两个智能体写同一个客户时，你得到的不是合并，而是最后一次写入覆盖之前的内容，或者两段矛盾的段落并排躺着。

A2: 每个智能体一个只追加日志，加上定期合并任务（本质上就是Claude的“梦境”的规模化版）。

合并变成了完全非确定性的。即使你信任LLM能正确合并，你怎么给它做版本控制？是哪一次合并产生了哪一段记忆？它覆盖了什么？

A3: 共享一个.md，让LLM在读取时解决冲突。

如果在读取时由LLM解决冲突，那你拥有的就不是记忆，而是一个日志加上一个靠猜测来相信什么的LLM。每次查询都要从头重新推导事实，而且每次推导出的结果都可能不同。

Q3: 如何处理时间相关查询？

A1: 给每个条目加上时间戳。

时间戳告诉你的是笔记的写入时间，而不是该事实在现实世界中成立的时间。客户在3月告诉你10月续约，又在6月推到了12月，你会有两条笔记，两个不同的写入时间戳，却无法知道某一天哪个续约日期是当前有效的。

A2: 使用Auto Dream维护一个“当前状态”章节和一个“归档”章节。

你构建了一个会悄悄损坏自身的快照系统。每次合并时，LLM要猜测每条新笔记替代了哪条旧笔记，但却没有任何信息告诉它“客户的续约”和“他们的续约日期”是同一回事。它会猜错。你也不知道它什么时候猜错。而且归档结构过于松散，无法回头检查你之前相信的是什么。

A3: 把所有日期都放在.md文件中，让LLM进行时间推理。

你把一个存储问题变成了推理问题。每个基于时间的问题现在都要花一次模型调用，每次运行返回不同答案，而且没有可以用来验证的事实标准。

Q4: 如何在记忆中加入追踪信息，以便日后用于智能体的自我改进？

A1: 每次会话后追加一个“经验教训”章节。

教训不断累积，而Markdown没有办法区分哪些教训仍然有效。一百次会话后你就有一百条教训。有些可能相互矛盾，有些可能对应已经被删除的代码路径。它们都处于相同的检索优先级，智能体并不知道该看重哪一条。你建了一个只写日志，却称之为学习。

A2: 使用Auto Dream将追踪信息提炼为规则。

提炼是单向的。一旦规则被写下来，你就无法查询“哪些追踪信息产生了这条规则，执行它时得到了什么结果？”。那些能回答这个问题的追踪信息已经被压缩掉了。你让推理变得更便宜，却让评估变得不可能。

A3: 将原始追踪信息存放在独立存储中，将提炼后的规则放在.md中。

你现在有两个毫无关联的记忆系统。.md文件中的规则无法指向产生它的追踪信息，追踪信息也无法查询“哪些产生了仍然活跃的规则”。你又回到了需要关系型或图模型的状态。

Q5: 要在数千个.md文件中找到正确的信息，你打算怎么做？

A1: 分块并嵌入，检索top-k结果。

你在文件存储上建了一个向量存储，检索时完全忽略文件结构。分块会丢失实体上下文：一段关于“他们的定价”的段落被返回了，却没有告诉你这是谁的定价。Top-k优化的是语义相似度，而不是查询真正关心的实体。

A2: 添加元数据过滤（按实体、主题、日期等打标签）。

现在你在维护一个Markdown无法保证的模式。标签会漂移，分类与现实脱节，一个标签错误的文件会默默降低检索效果，且永远无法恢复。你建了一个数据库，却没有那些让数据库值得信赖的约束。

A3: 构建一个基于图的导航系统，跨越数千个.md文件。

到这一步，你实际上是在建一个图数据库，只不过存储层碰巧是Markdown文件。你需要一个索引（Markdown本身不可查询），一种在文件变化时保持索引同步的方法（Markdown不发出事件），有类型的边（Markdown中的链接只是字符串），以及一个顶层的查询引擎。这些恰恰是图数据库和记忆层提供商已经解决的问题。你重新发明了轮子，还特意把存储层搞得更糟。

使用.md文件做记忆并不是错或不好，请别误解。它不过是一个带LLM驱动的压缩的键值存储，对于单个用户、单个智能体、单条时间线来说，可能没问题。但只要你的系统在任何一个维度上成长，你都需要别的东西。

而且，相信我，上面我们只触及了皮毛。比如溯源呢？如何在不丢失连接的前提下区分短期记忆和长期记忆？当记忆的形状在六个月后发生变化时该怎么办？当Auto Dream已经将某个信息吸收并改写进了十几份摘要中时，你怎么真正删掉它？对于不知道彼此关联的笔记，你如何进行多跳推理？每一个话题都可以单独写一篇文章 :)

我们在设计cognee时，心里想的正是这些问题。

在这里可以找到我们：

https://github.com/topoteretes/cognee** ⭐**

https://www.cognee.ai/

加入我们的Discord，获取支持和参与讨论：