Skip to main content

六层架构拆解

总体架构描述的是全景，这一页更关注“每一层到底解决什么问题，以及为什么不能混在一起”。

第 1 层：Client / Agent​

这一层包含 Codex、Claude Desktop、CLI、浏览器工作台等宿主。它们的共同特点是：

  • 发起意图
  • 展示结果
  • 决定何时触发写入、召回或控制动作

但它们不应该承担长期记忆的判断逻辑，否则一旦接入方式增加，系统行为就会分叉。

第 2 层：Access Adapter​

Adapter 负责把宿主差异转成统一能力，例如：

  • prompt 型 Skill 转成 API 请求
  • function calling Tool 转成 JSON Schema 工具调用
  • MCP tools / resources 转成远端记忆服务
  • CLI 参数转成标准 REST 请求

这一层的关键词是“转换”，不是“决策”。

第 3 层：Memory Orchestrator​

这一层承载三条核心管线：

  • Write Pipeline
  • Recall Pipeline
  • Control Pipeline

它回答的是系统层面的业务问题：

  • 这条信息值不值得长期保存
  • 当前任务该召回哪些上下文
  • 这次删除或状态变更是否允许执行

如果少了这一层，系统就会退化成“若干表 + 若干搜索接口”，而不是一个真正的记忆基础设施。

第 4 层：Memory Storage Plane​

这里把存储从语义上拆成三块：

  • Stable Memory Store
  • History Recall Store
  • Control Metadata Store

这么做的价值在于，不同对象的生命周期、查询方式和控制语义都不一样。先在模型上拆开，才能避免后续所有逻辑都挤进一张大表或一个模糊抽象里。

第 5 层：Search & Ranking​

这一层向上提供候选召回能力，向下使用词法和向量能力。它承担的是：

  • 相关性初筛
  • Scope 与标签过滤
  • 时间窗口过滤
  • RRF 混合排序

但它不直接决定最终注入模型上下文的内容，因为最终结果还要考虑 Token 预算、冲突提示和分层分配。

第 6 层：Storage / Infra​

这层包括：

  • PostgreSQL 与 pgvector
  • 缓存与限流计数器
  • 反向代理与 TLS
  • 日志与审计基础设施

它提供的是运行条件，而不是记忆语义本身。把基础设施和业务规则分开，后续替换某个中间件时才不会牵一发而动全身。

分层之后带来的直接收益​

收益说明
适配层稳定新增接入方式不需要复制业务逻辑
业务判断收口写入、召回、控制规则统一落在服务端
模型可演进可以在不破坏整体结构的前提下增强 Judge 和 Recall
运维边界清楚部署、数据库、代理和日志问题不会污染上层语义

六层架构的价值不在于层数本身，而在于它强迫系统先回答“每一层到底该负责什么”，从而为后续演进保留空间。