六层架构拆解
总体架构描述的是全景，这一页更关注“每一层到底解决什么问题，以及为什么不能混在一起”。
第 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 |
| 运维边界清楚 | 部署、数据库、代理和日志问题不会污染上层语义 |
六层架构的价值不在于层数本身，而在于它强迫系统先回答“每一层到底该负责什么”，从而为后续演进保留空间。