Bloome 重构 Agent 记忆架构：专为多人协作而生
传统的 AI 记忆系统大多是为“一人一助手”的封闭场景设计的。然而，当这种设计被强行套用在 Bloome 这样“多人多 Agent 共享同一空间”的开放协作环境中时，系统往往会出现莫名其妙的故障。Bloome 团队发现，问题的核心不在于搜索算法有多先进，而在于我们问错了问题。
在单人模式下，记忆系统只需回答“我都知道什么？”。但在多人协作中，当 Agent 需要同时服务多个用户时，核心问题必须转变为：“关于这个人，我现在知道什么？”
为什么通用检索在多人场景下会失效
目前主流的扩展记忆方案多采用检索增强生成（RAG）或向量检索：将所有历史对话存入数据库，当需要时，通过文本相似度搜索相关片段。OpenClaw 和 Hermes Agent 等系统均遵循此逻辑。
然而，这种“文本对文本”的匹配方式在共享空间中存在致命缺陷：
- 身份混淆：在多人环境中，同名用户（例如两个不同的 Mike）极易造成检索错误。向量检索返回的是“提到 Mike 的所有文本片段”，而非“关于特定 Mike 的事实”。
- 静态信息的失效：检索系统倾向于返回高相似度的文本，但无法感知事实的时效性。一条关于“Mike 计划去东京”的旧笔记，可能因为关键词匹配而被频繁召回，即便 Trip 早已结束。
核心突破：身份感知的文件化存储
Bloome 的解决方案并非修补搜索算法，而是重新定义了记忆的本质：记忆是可以浏览的文件，而不仅仅是被查询的数据。
1. 物理隔离：谁的文件，谁看
Bloome 为每个用户建立了独立的记忆文件夹。Agent 不再通过模糊的相似度猜测“这是谁的笔记”，而是直接读取属于该用户的文件。这种架构将“身份”从检索的猜测变成了确定的属性，彻底解决了同名用户混淆问题。
2. 前台与后台的分离
借鉴了实体卡片管理的理念，Bloome 将记忆分为两个层级：
- 前台（Front of the card）：包含高频、关键信息（如沟通偏好、紧急过敏原）。这些信息在每次对话中都会自动加载，确保 Agent 始终掌握核心上下文。
- 后台（The drawer）：包含大量低频、细节信息。这些信息被归档存储，只有在 Agent 主动需要时才被打开查阅。
3. 向工程思维致敬：直接读取而非索引猜测
Bloome 从编写代码的 AI Agent 中汲取了灵感。工程师在大型代码库中查找函数时，不会依赖复杂的索引猜测，而是直接打开文件进行文本搜索。Bloome 采用了同样的策略：当前台信息不足以回答问题时，Agent 会直接打开对应的用户文件进行精确查找，而非依赖可能过时的向量索引。
实际价值与应用场景
这一架构升级对开发者与最终用户具有显著价值：
- 精准的多用户协作：在群组聊天或多人会议中，Agent 能准确区分不同用户的意图和偏好，避免将 A 用户的指令误判为 B 用户。
- 动态记忆更新：记忆不再是静态的历史堆砌，而是随用户交互动态更新的活跃状态，自动过滤过时信息。
- 可解释性与可控性：由于记忆以文件形式存在，开发者可以更容易地审计、修改或导出特定用户的记忆数据，增强了系统的透明度。
正如 Bloome 团队所言，"记忆不应只是被查询的数据，而应是用户可以浏览的文件。"这一转变标志着 AI 记忆系统从封闭的单点服务，向开放的多点协作迈出了关键一步。
