Agent Memory as a File Format：记忆应是数据而非流程
现有的 Agent 记忆系统往往过于复杂，依赖 pgvector、Neo4j 等重型组件，或将记忆视为需要多阶段处理的流程，导致模型困惑且难以扩展。我提出 Memoryfields 方案，主张将记忆视为一种简单的文件格式：由 Markdown 页面、可选的 YAML 前缀和 SQLite 向量索引组成。这种设计摒弃了低效的图遍历，利用语义搜索直接定位内容，让 Agent 能像人类一样直接读写自然语言记忆。通过这种“低机制”的开放格式，记忆系统能随模型能力的提升而自然进化，避免被特定厂商的 API 锁定，让 Agent 真正拥有属于自己的知识库。
向我展示你的流程图并隐藏你的表格，我会继续感到困惑；向我展示你的表格，我通常就不需要流程图了，因为它们会显而易见。
HN 评论区
69- dataviz1000
还有谁不用记忆功能吗？
我发现只要混入一行有毒的文本，就会对下游所有环节产生负面影响。所以我改用 temp/ 文件夹存放文档，为不同的 agent 和模型使用不同的文件。然后我必须不断修剪和删除这些文件。任何可以推断出的信息都只是噪音，会对 agent 产生负面影响。如果你有一个数据库结构的定义并且已经实现了，那么这些信息就不应该出现在任何文本文档中——它们是噪音，会漂移，而且你根本无法调试为什么 agent 会持续产生不期望的行为。
我有一个 ~/Projects 文件夹。例如，我使用 Playwright 配合 Chrome DevTools Protocol 来进行性能测试和泄漏检测。有一个脚本专门处理这个。我的提示词是“在 ~/Projects 中搜索使用 CDP 和 Playwright 进行性能测试的内容并在此实现”。重点是，如果我需要任何东西，我会指向某个资源或要求搜索某个资源，它能很快找到，而且最重要的是，往往能在每次迭代中不断改进它。
如果我在某个机构工作，我会建立一个仓库，更倾向于直接指向资源并说“用那个”，而不是在本地保留它的记忆。
- morelandjs
我本来准备写点讽刺的话，因为这本质上就是 RAG，但我觉得作者触及了一些看似重要的微妙细节。
- 记忆系统是一种特定类型的知识库，其中所有文档都是生成的。你完全可以生成小于 embedding token 限制的文档，从而省去分块（chunking）的需要。
- embedding 模型正在变得更好，不再仅仅是语义平均。
- 小模型变得极其便宜，使得并行读取的成本变得可控。
他们描述的架构可以说是利用这些观察结果的最简单架构。当他们说这很有效时，我相信他们。
不过我确实怀疑，如果每条记忆都只是向量，那么像关键词查找这样的功能会完全失效。这就是为什么像 Typesense 混合搜索这样的东西仍然有用。
- JustFinishedBSG
写了一大堆文字，其实就是为了说“它是 markdown”。
- Avijit_Thawani
“不相关的材料根本不会被语义搜索呈现出来。”
这未免太乐观了。有很多“记忆”或过去与 agent 的对话应该被抑制和遗忘，因为它们当时找错了地方，或者最终被证明是错误的。然而从语义上看，它们对未来搜索来说可能看起来非常相关。这就是为什么在试图解决考试问题时，你不应该同时搜索教科书和科幻小说。
- loehnsberg
这反映了我自己的经验：
- 将会话轮次存储在 sqlite-vec 中
- 为 agent 提供一个 mcp 来搜索 vec-db
- 让 agent 在 md 文件中写笔记，并附带索引/frontmatter
结合提交历史，vec-db 为 agent 提供了长期记忆。笔记允许用户纠正错误知识的累积。
更简单，但更好。