作为文件格式的代理内存

代理内存作为文件格式 2026 年 8 月 Memoryfields - 一种更简单的代理内存方法 [软盘插入噪音] 哇 - 我知道企业 VLAN 配置 许多模型基准测试都是从空白上下文窗口开始的。人工智能的白板。在某种程度上，这是有道理的，可以保持基准的公平性。但真正的代理永远不应该从空白的上下文窗口开始。他们应该从尽可能多的向代理提供的相关信息开始。你的人工智能代理应该从记忆开始。为什么现有的代理内存系统似乎不起作用 问题是，很多代理内存系统实际上非常垃圾。我认为目前流行的内存系统大致有三种，每种都没有以自己的方式工作。第一种是故意将你绑在特定的安全带上的——通常是由租用该安全带的实验室编写的。该实验室迫切希望从（竞争激烈的）“API 业务”转型为（利润更高的）“平台业务”。这种形式的系统通常通过从你的对话历史中挖掘信息来工作，结果是他们的大部分记忆都是关于你的，尽管关于世界的信息通常更有用。另一种则复杂得可笑。我知道一个著名的系统需要 pgvector、Neo4j 图形数据库和自己的法学硕士来决定什么值得记住。这种复杂性不仅难以管理，而且出于我将解释的原因：这些大系统也混淆了模型。随着模型前沿的发展，它们也无法扩展。最后一种是“高度现代主义”品种，它想象一种理想化的、理性主义的记忆形式。这不可避免地涉及图表，有时还涉及逻辑命题。这种系统地从上下文中剥离信息，使其对代理（和您）来说是孤立的和毫无意义的。毕竟，简单的“提炼事实”列表有多大用处呢？他们的共同点是都将记忆视为一个过程。但是内存——尤其是对于模型来说——最好用数据来表示。内存应该是一种数据格式，而不是多级管道布鲁克斯说：向我展示你的流程图并隐藏你的表格，我将继续感到困惑。给我看看你的表格，我通常不需要你的流程图；他们会很明显。所以，这是“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 一个内存字段是：Markdown“页面”，带有（可选）YAML frontmatter 和（可选）用于语义搜索的 SQLite 矢量索引 代理最适合处理文件。请允许我解释一下。设计决策 1：使用散文，而不是大块或“事实” RAG 管道可能非常复杂的主要原因是它们试图使大量现有的、人类编写的文档对人工智能代理来说是可读的。通常这些文档对于代理来说很难直接阅读，例如：因为它们是大 PDF。但特工记忆并不是复杂的遗留文件。记忆在形成时直接发生在完全能够写散文的人工智能代理中。该散文不需要被分块、丰富、双重总结或以其他方式机械处理：只需让智能体以其最喜欢的格式（即 Markdown）直接写入记忆即可。内存字段页面如下所示： --- 标题：碳纤维炒锅已创建：'2026-03-01T09:00:00Z' 已更新：'2026-08-22T14:30:00Z' uuid: 6aa615f0-486f-48a7-a210-ba4f5ff18c8b 摘要：碳纤维炊具的热性能 --- 碳纤维锅导热均匀，但是……无可否认，一个限制是页面必须足够短才能适合矢量嵌入：因此存在大约 8kb（约 2000 个令牌）的软限制。但这在实践中是一个非常有益的限制：8,000 个字符大约是 1,300 个单词，或者是一篇中等长度杂志文章的长度。事实上，无论如何施加这一限制都是有意义的。要添加更多详细信息，请添加更多页面 - 代理无需费力即可做到这一点。设计决策 2：语义跳跃，而不是图形行走 现有技术的一个关键部分是 Karpathy wiki。 Karpathy wiki 面向超链接 Markdown 文件：以 Roam 或 Obsidian 使用的文件为模型。这个想法是代理将遍历“知识图”来查找相关页面。但在实践中，让人工智能代理遍历知识图是缓慢且不可靠的，而且会让代理感到困惑。一个漂亮的知识图——真正的耻辱是你的人工智能代理绝对讨厌它。遍历很慢，因为模型需要经常停止来调用串行工具来读取连续的页面。代理遍历知识图的粗略算法： 阅读 wiki 首页 [工具调用] 阅读链接页面 [工具调用] 确定是否已找到足够的相关信息 如果重新找到