2026年8月，Memoryfields - 一种更简单的代理记忆方式 [软盘插入噪音] 哇 - 我知道企业VLAN配置。许多模型基准测试从空白的上下文窗口开始。AI的白板。在某种程度上，这是合理的，以保持基准测试的公平性。但现实代理永远不应该从空白的上下文窗口开始。它们应该尽可能多地从相关信息中开始。你的AI代理应该从记忆开始。 为什么现有的代理记忆系统似乎不起作用 问题在于，很多代理记忆系统实际上都很糟糕。我认为目前大致有三种流行的记忆系统，它们各自以自己的方式无效。第一种是故意将你绑定到特定框架中的系统 - 通常由出租该框架的实验室编写。该实验室急于从（竞争激烈的）“API业务”转向（更有利可图的）“平台业务”。这种系统通常通过挖掘你的对话历史中的信息来工作，其结果是，他们的大多数记忆都是关于你的，尽管有关世界的信息通常更有用。另一种是荒谬复杂的。我知道有一个著名的系统，需要pgvector、一个Neo4j图数据库和一个自己的LLM，仅仅为了决定值得记住的内容。这种复杂性不仅难以管理，而且，由于我将要解释的原因：这些大型系统也使模型感到困惑。它们随着模型的前沿向前移动而无法扩展。最后一种是“高度现代主义”类型，它设想了一种理想化、理性化的记忆形式。不可避免地，这涉及到一个图， 有时还包含逻辑命题。这种类型系统性地剥离信息的上下文，使其对代理（和你）而言孤立且无意义。毕竟，简单的“提炼事实”列表有多有用？它们的共同点是把记忆当作一个过程。但是，记忆 - 特别是对模型来说 - 更好地表示为数据。记忆应该是一种数据格式，而不是一个多阶段的管道。布鲁克斯说过：给我看看你的流程图，隐瞒你的表格，我将继续感到困惑。给我看看你的表格，我通常不需要你的流程图；它们将显而易见。 因此，这里是“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是：Markdown “页面”，具有（可选）YAML前言和（可选）用于语义搜索的SQLite向量索引。 代理最好地使用文件。允许我解释。 设计决策1：使用散文，而不是块或“事实” RAG管道之所以可能非常复杂，主要原因是它们试图让大量现存的人类撰写的文档对AI代理可读。这些文档通常很难让代理直接阅读，例如：因为它们是大型PDF。但是代理记忆并不是复杂的遗留文档。记忆在形成时，直接发生在一个完全能够写散文的AI代理面前。该散文不需要进行分块、丰富、双重总结或以其他方式机械处理：只需让代理直接以其喜欢的格式（即Markdown）写下记忆。记忆场页面看起来像这样： --- title: 碳纤维炒锅 created: '2026-03-01T09:00:00Z' updated: '2026-08-22T14:30:00Z' uuid: 6aa615f0-486f-48a7-a210-ba4f5ff18c8b summary: 碳纤维炊具的热属性 --- 碳纤维炒锅能均匀导热，但... 诚然，唯一的限制是，页面必须足够简短，以适应向量嵌入：所以大约有8kb（~2000个标记）的软限制。但是，这在实践中是一个非常有益的限制：8,000个字符大约是1,300个单词，或者是中等长度杂志文章的长度。实际上，这是一个合理的限制。 要添加更多细节，添加更多页面 - 代理不会惊慌失措。 设计决策2：语义跳跃，而不是图遍历 一项关键的先前工作是Karpathy维基。Karpathy维基围绕超链接的Markdown文件构建：模仿Roam或Obsidian使用的文件。其想法是让代理遍历“知识图谱”以找到相关页面。但在实践中，让AI代理遍历知识图谱的速度缓慢且不可靠 - 并且对代理来说是混乱的。 一个美丽的知识图谱 - 你的AI代理绝对讨厌它。 遍历速度慢，因为模型需要频繁停下来进行串行工具调用以读取连续页面。代理遍历知识图谱的大致算法： 阅读维基首页 [工具调用] 寻找相关链接 阅读链接页面 [工具调用] 寻找相关链接 决定是否有足够的相关信息