跳到主要内容

总体架构

羽忆采用的是分层架构，而不是把“存储、检索、召回、控制”混在同一层里。这样设计的原因，是记忆系统本质上同时要解决接入、判断、检索、消费和安全几个不同问题域，如果边界不清晰，系统很快就会变成一个难以演进的杂糅体。

六层架构总览​

Layer 1  Client / Agent Layer
Layer 2  Access Adapter Layer
Layer 3  Memory Orchestrator Layer
Layer 4  Memory Storage Plane
Layer 5  Search & Ranking Layer
Layer 6  Storage / Infra Layer

为什么要这样分层​

Layer 1：Client / Agent Layer​

这一层是实际发起调用的宿主，例如 CLI、MCP 客户端、浏览器工作台和各类 Agent 工具。它负责表达用户意图，但不应该负责长期记忆的判断和持久化规则。

Layer 2：Access Adapter Layer​

Adapter 的职责是把不同宿主的调用方式映射成统一 API。这里必须刻意保持“薄”，否则一旦把业务规则放进各个 Adapter，不同接入方式的行为就会越走越偏。

Layer 3：Memory Orchestrator Layer​

这是系统真正的中枢。写入时要判断什么值得存、应该存到哪一层；召回时要决定什么内容该进入上下文；控制时要处理删除、归档、模式切换和状态变更。换句话说，这一层负责“记忆如何被使用”，而不是“数据存在哪里”。

Layer 4：Memory Storage Plane​

这一层把 Stable Memory、History Recall 和控制元数据分别收纳。之所以不只抽象成一个“数据库层”，是为了让不同生命周期、不同查询模式的数据在语义上先分开。

Layer 5：Search & Ranking Layer​

搜索与召回之间隔着一层明确的相关性和排序基础设施。向量检索、词法检索、RRF 混合排序、过滤条件都在这一层完成，向上再由 Recall Orchestrator 继续做面向任务消费的处理。

Layer 6：Storage / Infra Layer​

最底层负责数据库、缓存、代理、TLS、日志和可选对象存储等基础设施。把这一层独立出来，是为了避免把部署与运维细节反向污染业务模型。

运行时主链路​

可以把系统的核心行为概括成三条路径：

  1. 写入：宿主表达“请记住”
  2. 召回：宿主表达“请回忆当前任务相关内容”
  3. 控制：用户表达“请查看、删除、归档或切换模式”

这三条路径都从 Adapter 进入 API Gateway，再流入编排层，最后才下沉到存储和检索底座。这个顺序不能颠倒，否则系统会失去统一入口和统一规则面。

当前架构下最重要的边界约束​

  • 接入层不承载业务判断
  • 服务端不依赖某个特定模型才能完成主流程
  • 检索层提供候选，不直接决定最终上下文注入
  • 控制面不是附属功能，而是系统的基础能力
  • 安全约束从第一阶段就参与主链路

只要这几条边界守住，后续无论是增强 Judge、引入更多 Adapter，还是调整召回策略，都能在现有结构上增量演进。