智能体记忆的可移植文件格式（9分钟阅读）

# 智能体记忆作为文件格式 来源：https://calpaterson.com/memoryfields.html 2026年8月 Memoryfields ——一种实现智能体记忆的极简方式 一张《黑客帝国》中尼奥学习功夫的图片\[软盘插入声\] 哇！我已经知道了企业VLAN配置 许多模型基准测试都从空白上下文窗口开始 (https://simonwillison.net/tags/pelican-riding-a-bicycle/)。这是人工智能的白板状态。从某种程度上说，为了保持基准测试的公平性，这很有道理。 但真正的智能体绝不应该从空白上下文窗口开始。它们应该从尽可能多的相关信息开始。你的AI智能体应该从**记忆**开始。 ## 为什么现有的智能体记忆系统似乎不起作用 问题在于，许多智能体记忆系统实际上相当糟糕。我认为目前大致有三种流行的记忆系统，每一种都以自己的方式失效。 第一种是故意将你绑定到特定运行环境的系统——通常由出租该运行环境的实验室编写。该实验室迫切希望从（竞争激烈的）“API业务”转向（利润更高的）“平台业务”。这种系统通常通过从你的对话历史中挖掘信息来工作，结果导致它们的大多数记忆都是关于你的，即使关于世界的信息通常更有用。 另一种类型则极其复杂。我知道有一个著名的系统需要pgvector、Neo4j图数据库和自己的LLM来决定什么值得记忆。这种复杂性不仅难以管理，而且，原因我稍后解释：这些庞大的系统也会让模型感到困惑。它们还未能随着模型前沿的发展而扩展。 最后一种是“高度现代主义”变体，它们想象一种理想化、理性主义的记忆形式。不可避免地，这涉及一个图，有时还包括逻辑命题。这种方法系统地剥离信息的上下文，使智能体（和你）感到信息孤立且无意义。一个简单的“提炼事实”列表，到底有多大用处呢？ 它们的共同点在于，将记忆视为一个过程。但记忆——尤其是对模型而言——最好作为数据来呈现。 ## 记忆应该是一种数据格式，而不是多阶段的流水线 布鲁克斯 (https://martinfowler.com/bliki/MythicalManMonth.html) 说： > 给我看你的流程图，而隐瞒你的表格，我会继续感到困惑。给我看你的表格，我通常不需要你的流程图；它们会显而易见。 那么，这就是“memoryfield”便携式记忆文件格式： `` my-memories.memoryfield.zip ├── carbon-fibre-woks.md ├── finnish-bureaucracy-tips.md ├── [... 更多 md 文件...] ├── wec-2026-season-notes.md └── nomic-embed-text-v1.5.sqlite3 `` Memoryfield 包括： 1. Markdown “页面”，其中包含 2. （可选的）YAML 前置元数据，以及 3. （可选的）用于语义搜索的 SQLite 向量索引 智能体与文件配合得最好。请允许我解释。 ## 设计决策 1：使用散文，而不是分块或“事实” RAG 流水线之所以可能非常复杂，主要原因在于它们试图让一大群现有的、人类编写的文档对AI智能体可读。这些文档通常对智能体来说很难直接阅读，例如：因为它们是大型 PDF。 但智能体记忆并不是复杂的遗留文档。记忆在形成之时，是直接发生在能够熟练编写散文的AI智能体身上的。这种散文不需要被分块、丰富、双重总结或以其他方式机械处理：只需让智能体以其喜欢的格式（即 Markdown）直接编写记忆即可。 Memoryfield 页面看起来像这样： `` --- title: Carbon Fibre Woks created: '2026-03-01T09:00:00Z' updated: '2026-08-22T14:30:00Z' uuid: 6aa615f0-486f-48a7-a210-ba4f5ff18c8b summary: Thermal properties of carbon fibre cookware --- Carbon fibre woks conduct heat evenly, but... `` 必须承认，一个限制是页面必须足够短以适合向量嵌入：因此有一个约 8kb（~2000 tokens）的软限制。 但在实践中，这是一个非常有益的限制：8000 个字符大约是 1300 个单词，或者一篇中等长度杂志文章的篇幅。事实上，即使没有限制，这也是一种合理的约束。要添加更多细节，就添加更多页面——智能体这样做并不困难。 ## 设计决策 2：语义跳跃，而不是图遍历 一个重要的先例是Karpathy wikis (https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f)。Karpathy wikis 围绕超链接的 Markdown 文件构建：模仿 Roam 或 Obsidian 所使用的文件。其想法是智能体通过遍历“知识图谱”来查找相关页面。 但在实践中，让AI智能体遍历知识图谱既缓慢又不可靠——而且对智能体来说也很令人困惑。 一张 Obsidian 知识图谱的截图 一张美丽的知识图谱——但你的AI智能体绝对讨厌它，真可惜 遍历缓慢是因为模型需要频繁地停下来进行串行工具调用以读取连续的页面。 智能体遍历知识图谱的粗略算法： 1. 读取维基首页 \[工具调用\]- 找到相关链接 2. 读取链接页面 \[工具调用\]- 找到相关链接 3. 决定是否已找到足够相关信息- 如果没有，转到步骤 #2 如果相关信息在知识图谱中深度为 N 步，则需要 N+1 次工具调用来检索它。这很慢，因为你的价值数十亿（万亿？）美元的LLM模型必须为每次工具调用暂停，每次调用可能需要 2-3 秒。这也严重惩罚了深度嵌套的知识图谱，坦率地说，这违背了其初衷。 知识图谱也不可靠。因为 AI 只能通过查看链接文本，或者可能页面标题（如果某种方式外部化的话）来判断材料是否相关。这给智能体带来了巨大压力，迫使其进行 1990 年代 SEO 风格的页面元数据黑客操作，以确保每个页面的链接文本/标题/说明既简洁又准确。这样做惩罚了离题、附带记录侧面细节以及在大型文本语料库中常见且非常有用的隐式背景知识。 在实践中，相关信息在 Karpathy wikis 中经常被错过，因为它的标题或说明方式对搜索智能体来说不够吸引人。 知识图谱也常常让智能体感到困惑，因为它们在遍历图谱时经常不得不仔细查看大量无关信息。无意中读取无关信息（首页通常是主要罪魁祸首）会将大量噪音放入模型的上下文窗口中，降低其输出质量，并使其看起来专注于奇怪的东西。 这些问题都通过使用语义搜索直接跳转到**所有**相关页面（基于它们的实际内容，而不是页面元数据）并让智能体一次性、*并行地*读取所有相关页面来解决了——现在绝大多数模型都能做到这一点。因此，在 memoryfield 中，最多需要 2 次工具调用（#1 搜索，#2 并行读取）。相关内容确实被找到，并且无关的输入令牌被最小化。 ## 设计决策 3：更多模型，更少机制 “高机制”记忆系统——包含大量专门构建的 API 或数据库——带来的问题之一是，智能体为了使用它们，必须在一个复杂的接口迷宫中导航才能达成目标。如果接口很大，那么你需要在上下文中加载大量 `openapi.json`。如果接口很小，那么它就具有局限性。即使平衡得当，API 通常仍然是错误的：回忆一下那些你不得不使用别人编写的、未曾预见到你需求的 API 的经历。你喜欢那种体验吗？ 因此，memoryfields 作为一个“低机制”系统（仅为一个文件格式），赋予智能体更大的自由度去发明自己的访问模式。虽然提供了一些（希望）有用的工具 (https://github.com/calpaterson/memoryfield-tool/)，但智能体完全可以自由使用任何它们喜欢的访问模式。例如，使用 `perl` 在整个语料库中进行查找和替换，或者在记忆中放置内联 CSV 文件，然后使用 SQLite 查询它们（这两种都是我亲身见过的真实案例）。 “低机制”也意味着 memoryfields 能够随着模型前沿的发展而扩展。随着模型变得更好，智能体能想出更多可做的事情。最近的一个突破是，模型意外地非常擅长 bash。它们也很擅长 Markdown 和 SQLite。我认为 memoryfields 在真实智能体中效果良好的原因之一在于，智能体从根本上能够从它们的训练数据（在你能读取你的记忆之前，这就是你拥有的一切）中“理解”正在发生什么，这种方式是它们作为“记忆流水线”中的一个独立的LLM调用时所无法做到的。 随着模型变得更好，它们会自动开始以更巧妙的方式编写记忆。那些“外挂式”记忆系统很少能做到这一点。使用固定 API 端点的方式只有那么几种。Memoryfields 将随着模型前沿的发展而扩展。 ## 设计决策 4：开放格式、可互换、传输无关 随着你的记忆集合不断增长，它们开始变得珍贵。你积累的宝库，包含了学到的教训和辛苦得来的既定事实。你不想被锁定在特定的运行环境、模型或智能体中。 我为该文件格式撰写了一份 RFC 风格的规范 (https://github.com/calpaterson/memoryfield-spec/blob/main/SPEC.md)——主要是为了消除歧义并避免将其绑定到特定的嵌入函数。 如果你愿意，你当然可以仅凭规范就轻松写出你需要的任何工具。但我也提供了一个技能 (https://github.com/calpaterson/memoryfield-skill) 和一个针对智能体优化的命令行工具 (https://github.com/calpaterson/memoryfield-tool)。 Memoryfield 的规范“归档”格式是 zip 文件。这是为了使数据交换尽可能简单。但我刻意让规范保持开放，以便可以通过本地文件、Amazon S3、GitHub 或 HTTP 提供服务。实际上，任何有文件系统的地方都可以。我个人混合使用多种传输方式：使用 Syncthing 用于个人 memoryfields，使用 S3 用于与他人共享的 memoryfields。 ## 快速开始 你可以让你的智能体拉取 SPEC.md (https://github.com/calpaterson/memoryfield-spec/blob/main/SPEC.md) 并轻松实现一个，但最简单的开始方式可能是使用我的工具： `` # 需要：ollama, uv 和 npx (随 npm 提供) # # 1. 拉取嵌入模型： ollama pull nomic-embed-text # 2. 安装命令行工具： uv tool install git+https://github.com/calpaterson/memoryfield-tool # 3. 安装技能： npx skills add calpaterson/memoryfield-skill -g -y ``` 你的智能体应该能帮助你从这里开始运行起来。 如果你想尝试一个示例 memoryfield，试试 `soapstones.memoryfield.zip` (https://blobs.calpaterson.com/soapstones.memoryfield.zip)。Soapstones 是我早期关于智能体记忆的一个项目，这个精选导出包含了许多关于智能体如何获取数据的高价值（相对于其体积）记忆（例如智能体如何搜索 Reddit、如何使用 Jina Reader、如何使用 MediaWiki API 高效阅读维基等）。 ## “这不就是某种 RAG 吗” —— 以及其他常见反对意见 > 这不就是某种 RAG 吗？ “RAG”目前的解释非常宽泛——只要任何智能体检索数据，“RAG 就发生了”。从这个意义上说：是的，这就是某种 RAG。 但是：几乎所有智能体都会检索数据。例如通过搜索网络。而且通常与“RAG 系统”相关的大多数技术在这里并不存在。没有分块，没有重排序，没有混合搜索。 另一方面，当然是智能体在编写记忆。RAG 系统通常涉及读取，但 memoryfields 也用于写入。 > `nomic-embed-text-v1.5` 不是已经两年多了吗？不是有更新更好的模型吗？ 嵌入模型既不像前沿模型那么大，也不像它们那样快速演变。`nomic-embed-text-v1.5` (https://ollama.com/library/nomic-embed-text) 在小巧和强大之间保持着良好的平衡。它足够小（270MB），足够快，可以在非 GPU 硬件上运行，并且是一个广受欢迎且经常推荐的默认嵌入模型。 然而，该规范允许使用其他嵌入模型。 > 我如何判断什么是值得存储的好记忆？如何避免让我的记忆充满垃圾？ 这是记忆系统常见的担忧，但并不真正适用于 memoryfields。无关材料根本不会通过语义搜索被发现。无关记忆确实占用空间，也许你希望定期清理，但它们不会以任何方式阻碍智能体。 为了获得最佳效果：在 memoryfield 中自由插入记忆。但我要给出的一个建议是：当记忆包含引用（最好是 URL 形式）时效果最佳。这有助于未来对记忆的审查以加强它们，并帮助智能体核实过时或可疑的材料。 > 安全性怎么办？关于“忽略那个！” (https://calpaterson.com/disregard.html) 怎么办？ **你绝对不能将你的上下文窗口（包括通过记忆）与你不信任的方共享。** 规范中包含静态 zip 文件格式的原因之一，就是允许你手动审核并固定（通过 `sha256sum`）从他人那里获得的 memoryfields。 仍然**没有办法**让智能体区分“好提示”和“坏提示” (https://calpaterson.com/disregard.html)。 ## 数据优先 既然流程图已经清晰，我不妨明确地陈述它： 1. 将记忆写成 Markdown 2. 将其嵌入并保存向量到 SQLite 3. 通过语义搜索再次找到记忆 Memoryfields 作为一种记忆系统是独特的，因为它指定了数据结构而不是过程。没有提取流水线，没有后台处理服务，没有可插拔的——嗯，任何东西。有一个向量索引，但它是可删除的缓存，而不是系统本身。 记忆就是数据！我们放在智能体和该数据之间的固定机制越少，智能体就可能越好。 --- ## 联系方式/等等 --- ## 备注 如果你有时间，请查看规范 (https://github.com/calpaterson/memoryfield-spec/blob/main/SPEC.md)。任何（人类）对它的审阅都非常宝贵。 根据我的统计，我的安装过程包含了四个不同的包管理器（Ollama、uv、NPM、Vercel Skills）。这确实感觉一定有更好的方法。请将答案寄到老地址。