AVM：重新思考 AI Agent 的记忆
AI agent 会忘掉一切。每次 session 从零开始。唯一的连续性是你在开始时明确交给它的东西——而最直觉的解法是把所有东西堆成一坨 markdown 文件，全量加载。
能用，直到撑不住。
真正的问题不是存储
碰到记忆上限时，本能反应是想存储问题：数据放哪？但这是错误的问题。真正的约束是上下文窗口——agent 不从磁盘读，它从 token 读。所有进入记忆的内容都要挤进有限且昂贵的预算里。
所以真正的问题不是「记忆存在哪」，而是「现在值得加载哪些记忆」。
这个重新定义改变了一切。你不需要更大的磁盘，你需要一个感知 token 成本的检索系统——能在给定查询下，在不超出预算的前提下返回最相关的上下文。
为什么是文件系统？
AVM 把 agent 的记忆组织成虚拟文件系统。这个选择看起来有点奇怪。为什么不是数据库？不是向量存储？不是图？
因为文件系统是我们拥有的最通用的结构化信息心智模型。每个开发者都理解路径、目录、权限和文件操作。更重要的是：agent 也理解它。agent 已经在用的工具——读、写、列目录、搜索——直接映射到文件系统操作上。
还有更深的原因。记忆不是单一的东西。一个 agent 有不该共享的私有笔记，有应该在 agent 之间流动的共享知识，还有紧急信号的广播频道。文件系统让这些区别可见、可导航。扁平数据库做不到这一点。
/memory/private/{agent}/ ← 只属于你
/memory/shared/market/ ← 所有人可读，专家可写
/memory/shared/events/ ← 广播，任何人可写命名空间即策略。
记忆不该被覆盖
当你更新对某件事的看法，你不会抹掉之前的想法。你在旧的旁边加一条新的观察。历史很重要——它是你的思考在演化的证据。
AVM 默认把写入当成追加操作。每条新观察创建一个新节点，旧版本保留。当你 recall 某件事时，系统在所有版本里找到最相关的节点，在 token 预算范围内合成。
这才是记忆应有的语义。覆盖适合配置；不适合知识。如果两个 agent 独立观察到同一个市场信号，都写下了各自的分析——你想要两份分析，而不是看谁后写。
/proc 的启示
Linux 有一个优雅的设计：/proc 看起来像文件系统，但它不是。当你 cat /proc/cpuinfo 时，你不是在读一个文件——你在触发一个内核函数，它把实时系统状态格式化成文本。文件系统接口只是一个通用 API。
AVM 对记忆元数据做了同样的事。每个节点都有虚拟子文件：
note.md:meta— 节点的重要性分数、时间戳、来源note.md:links— 这个节点与哪些其他节点关联note.md:history— 内容如何随时间演变:search?q=RSI— 目录级别的搜索，渲染成文件读取
核心洞察：文件系统接口足够完备，能表达任意操作。不需要特殊的客户端库，不需要学新 API。Shell 命令、脚本、agent——任何能读文件的东西都能立即使用。
多 Agent 作为一等公民
大多数记忆系统为单个 agent 设计。多 agent 支持是事后加上去的——通常是在数据前加个前缀来区分谁的是谁的。
AVM 把多 agent 作为一等设计约束。权限模型是声明式的：每个 agent 对特定命名空间有明确的读写权限。一个 agent 不能意外地把私有上下文泄露给另一个。共享知识必须显式放进共享命名空间。
这很重要，因为 agent 会犯错。一个把敏感推理写进共享命名空间的 agent，会把它暴露给所有人。一个读了另一个 agent 私有笔记的 agent，可能被它本不该看到的上下文污染。权限系统不是官僚主义——它是让每个 agent 能够信任自己上下文的边界。
「Token 预算」真正意味着什么
Token-aware 检索听起来像优化。它实际上是一种设计哲学。
目标从来不是删除旧记忆——删除会销毁信息。目标是控制在某个 session 里加载什么。recall() 不返回文件；它返回一份合成摘要，按相关性、新鲜度和重要性打分，裁剪到指定的 token 预算内。
这比数据库查询更接近人类记忆的工作方式。你不会检索你对某个话题的全部记忆——你检索最显著的部分，由上下文过滤。系统做这个过滤，所以 agent 不用自己做。
文件系统的隐喻、Append-only 的写入、虚拟节点、声明式权限——这些不是实现选择，它们是对同一个底层问题的回答：对一个 agent 来说，「记住」意味着什么？
不是存储，不是检索，而是把重要的东西以现在有用的形式真正带到下一刻。