AIPass 记忆系统：为何拥有小型 JSON 文件的智能体胜过巨型向量存储

我深入研究了 AIPass 代码库，查看其记忆系统实际工作原理。这是我在多智能体设置中见过的较为周到的设计之一，因此我想清晰地解析它。核心思想：智能体拥有自己的记忆每个智能体（他们称之为“公民”）都获得自己的 `.trinity/` 目录，其中包含三个纯 JSON 文件： - passport.json，身份（我是谁、角色、原则、边界）。很少更改。 - local.json，个人会话历史 + 关键学习。按最新顺序排列，有意保持较小（20 个会话）。 - observations.json，我如何与人类和其他智能体协作（偏好、摩擦、模式）。这些文件在每次会话开始时加载。智能体不是从冷启动开始的。它已经知道自己的身份和之前在做什么。上下文在项目中是有意分割的。每个智能体只携带和管理属于其领域的记忆。没有巨大的共享上下文窗口需要所有人争夺。为何几乎不需要索引热路径只是智能体直接读取的小型结构化 JSON 文件。没有大型语料库需要每次轮次搜索，因此没有倒排索引、没有持续嵌入管道，也没有日常工作的索引税。只有当文件达到限制时，系统才会将最旧的条目滚动到 ChromaDB（通过 `@memory` 智能体）。Flow 系统中关闭的计划也是如此。一切都被保留并变得可搜索，但智能体的工作记忆保持精简且完全可加载。上下文实际如何进入会话这是钩子引擎（一个完整的一等公民称为 `@hooks`）大展身手的地方。它不是几个临时脚本。它是一个真正的调度引擎，负责：- 在相关事件上注入全局提示 + 分支本地提示 + 护照身份- 强制执行规则（跨分支写保护、git 门等）- 处理压缩/滚动触发器- 干净地记录一切结合无人机路由器（drone @branch 命令），智能体不需要知道大量的命令或路径。一个一致的接口即可访问所有内容。每个智能体都有完全相同的目录结构，其自身的 README.md 充当启动时读取的活分支地图/领域知识。较长的工作存在于 Flow 计划中对于比会话笔记更大的任何内容，他们使用 Flow 规划系统（编号的、有类型的计划：FPLAN、DPLAN 等）。计划是带有注册表的普通 markdown 文件，因此任何智能体都可以随时按编号查找一个计划。当计划关闭时，它会被归档并矢量化到相同的 ChromaDB 存储中。相关记忆随之附上。因此，你得到：- 微小、智能体拥有的工作记忆- 稳定的计划编号 + 用于精确回忆的注册表- 当需要时，对整个历史的语义搜索协调器上还有 Compass（DevPulse），一个策划的 SQLite 存储，记录评级的决策（好/坏/令人印象深刻）。这最终是早期从未完全使用的“符号片段”想法的实际演变。为何这感觉不同大多数系统将记忆视为你从中检索的外部知识库。AIPass 将身份 + 近期经验视为智能体本身的一部分，保持其小而结构化，使用钩子按需注入正确的上下文，并且仅在必要时归档到向量。计划为你提供了一个干净的地方来存放较长的结构化文本，这些文本仍然可以通过编号或搜索来回忆。一切都是本地文件。核心记忆循环无需必需的云服务。它仍然是测试版，并且正在积极开发中（17 个智能体的参考舰队维护着框架本身），但架构是连贯的，并在他们自己的多月多智能体设置中经过实战检验。仓库：https://github.com/AIOSAI/AIPass 站点：https://aipass.ai r/AIPass