Four-Axis Memory System

一个将「记忆」拆解为时间、状态、项目、对话四个维度的个人 AI 知识管理系统。

不是向量数据库的替代品——而是它的上层组织框架。

---

核心思想

四轴 ≠ 四种数据库。 四轴是把同一套记忆数据，按四种不同的查询模式分别组织和索引——事件驱动 vs 状态驱动。

将记忆按用途而非格式分离：

轴	驱动属性	类比人脑	写入触发	可覆盖
总轴 (Timeline)	事件驱动 — 记录"发生了什么"	回忆往事	外部事件发生	❌ 只追加
上帝轴 (God Agent)	状态驱动 — 记录"我是谁"	我现在什么心情	状态变迁	✅ 最新覆盖旧
对象轴 (Object)	状态驱动 — 记录"事情进度"	项目进展到哪了	任务推进	❌ 只追加
会话轴 (Session)	事件驱动 — 记录"原话怎么说"	对话录音回放	每轮对话	❌ 只追加

关键区分：

• 事件驱动（总轴、会话轴）：发生了什么就记什么，不合并、不覆盖、不修改。每一条都是独立事件。
• 状态驱动（上帝轴、对象轴）：关注的是"当前是什么状态"。上帝轴用 last-write-wins（新的覆盖旧的），对象轴用追加 changelog。

为什么这种区分重要？ 单纯的向量检索分不清"三年前我买了件衣服"（事件）和"我刚才吃了饭"（另一个事件）的区别——它们都只是"买衣服"和"吃饭"的向量。四轴通过不同的持久化策略，让"回忆过去"和"查询现状"走不同的路径，互不干扰。

---

三层架构

第一层：四轴（原始数据层 — 所有记忆的源）
  总轴 · 上帝轴 · 对象轴 · 会话轴
  （每种轴用不同的持久化策略）
         ↓
第二层：语义检索（LanceDB + Embedding）
  extract-fact → 向量化 → 语义搜索
  （从四轴中提取重要事实，做跨维度检索）
         ↓
第三层：知识库（Wiki Vault — 可读知识沉淀）
  concepts · syntheses · entities · sources
  （重要度≥4 的事实自动沉淀为 Wiki 条目）

查询路径：大多数查询不需要语义搜索

四轴最直接的效率来源：按轴查询 = 直接读文件，零计算。

"最近发生了什么"     → 总轴.jsonl 最后N条        ← 纯文件读取
"项目进展到哪了"     → 对象轴/xxx.jsonl 最后1条    ← 纯文件读取
"她现在什么心情"     → 上帝轴/xxx.jsonl 最后1条    ← 纯文件读取
"他当时怎么说的"     → 会话轴/日期-渠道/xxx.jsonl  ← 纯文件读取

"我记得好像有个什么事..." → LanceDB 语义搜索兜底  ← 只有这个需要向量

语义搜索（第二层）只在跨轴模糊查询时启用——你不知道该查哪个轴、只记得大概内容。日常"查状态"、"查时间线"、"查项目进度"都在轴层面直接完成，不需要 Embedding，不需要 LLM。

"四轴是向量库的上层组织框架" 的具体含义就是这个：90% 的记忆查询在轴层面解决，只有剩下的 10% 需要向量兜底。

核心数据流：

用户消息
   ↓ 写入会话轴（原文存档）
   ↓ 自动评估
       状态变化 → 写入上帝轴（last-write-wins）
       重要事件 → 写入总轴（append-only）
       任务推进 → 写入对象轴（changelog）
   ↓ extract-fact（LLM 分析 → 向量化 → LanceDB）
   ↓ importance≥4 → 自动沉淀为 Wiki 条目

---

设计原则

1. 只追加，不修改 — 历史可追溯。过去写下的任何内容都不会被修改。
2. 按职责分离，按需检索 — 查时间线走总轴，查状态走上帝轴，查对话走会话轴，查进度走对象轴。不让一个维度扛所有查询。
3. Agent 原生，不依赖外部服务 — 四轴运行在 AI Agent 内部，JSONL 文件是直接持久化层，不需要独立数据库。
4. 自动沉淀，由点及面 — 原始事实存四轴 → 重要事实自动向量化 → 累积到阈值自动成文。知识从对话中自然生长。

---

应用场景

适配场景

场景	适合程度	说明
个人 AI 助手/陪伴	⭐⭐⭐⭐⭐	需要记住你的习惯、偏好、说过的话；聊天中穿插"上次你说..."自然又贴心
AI 伴侣/朋友/聊天机器人	⭐⭐⭐⭐⭐	长程对话的记忆根基：记住共同经历、别问同样的问题、状态驱动能让陪伴感更强
长期对话的上下文管理	⭐⭐⭐⭐⭐	不限 token 窗口、不依赖一次性 prompt、真正的"它会记得"
个人知识笔记系统	⭐⭐⭐⭐	四轴提供结构化组织，Wiki 层沉淀可读知识，适合做第二大脑
AI 角色扮演/人设保持	⭐⭐⭐⭐	上帝轴保持角色状态一致性，对象轴跟踪故事线
个人项目/任务管理	⭐⭐⭐⭐	对象轴天然适配轻量项目管理
共享记忆（跨渠道）	⭐⭐⭐	支持多渠道合并，但单用户设计
企业级/团队使用	⭐⭐	单用户架构，无分布式支持

不适合场景

• 高并发读写
• 多租户 SaaS
• 严格 ACID 事务需求
• 已有成熟向量库 + 图数据库 + 传统数据库的基础设施团队（他们不需要另一层框架）

---

与现有方案对比

	四轴（本文）	MemGPT	纯向量库	图数据库	单层日志
时间感知	✅ 总轴专门处理	✅ 递归摘要	❌ 丢失时序	❌	❌ 需要全文扫描
状态感知	✅ 上帝轴 last-write-wins	❌	❌ 需要额外设计	❌	❌
项目隔离	✅ 对象轴	❌	❌ 无法分组	❌ 太重型	❌
原文保留	✅ 会话轴，可精确回溯	❌ 压缩丢失信息	✅ 但不结构化	❌	✅ 但不结构化
语义搜索	⚠️ 可选增强层	❌ 无	✅ 核心能力	❌ 无	❌ 无
可读知识库	✅ Wiki 自动沉淀	❌	❌	❌	❌
部署复杂度	🟢 低 — Agent 内置	🟡 中	🟡 中	🔴 高	🟢 低
记忆持久策略	🎯 事件/状态双策略分离	❌ 单一	❌ 单一	❌ 单一	❌ 单一
单用户场景	✅ 天然适配，不浪费	✅ 可用	⚠️ 偏重型	❌ 太重	✅ 可用但检索率低
多轴关联查询	✅ 自动跨轴	❌	❌	✅ 但需手动建关系	❌

四轴的核心差异化优势：

1. 事件驱动 vs 状态驱动的双策略分离 — 其他方案要么全追加（膨胀快）、要么全覆盖（丢历史），四轴按"这个数据是历史事件还是当前状态"分别采用不同策略。
2. 三层沉淀链路 — 从原文到向量到 Wiki，自动提炼，无需手动管理。
3. Agent 原生 — 四轴直接运行在 AI Agent 内部，Agent 在回复循环中直接读写 JSONL。不需要独立数据库、容器编排或微服务。
4. 专为"回忆"和"陪伴"设计 — 不是通用知识管理，而是"A 和 B 之间共同经历的事情"。时间线感、状态一致性、对话回溯是核心诉求。
5. 查询不走向量 — 90% 的记忆查询在轴层面直接读文件完成，语义搜索只在跨轴模糊查询时兜底。
6. 一条命令写出所有轴 — auto-update 命令自动评估每个轴是否需要更新，无需手动判断。

---

快速了解

• 架构图 — 三层总览 + 事件 vs 状态驱动数据流
• 设计文档 — 完整设计思路、各轴规格、对比分析、场景判断
• 更新逻辑 — 一条命令的执行流程
• 示例数据 — 各轴的 JSONL 格式示例

---

局限

• 单用户场景设计，无多租户支持
• 语义检索依赖外部 LLM / Embedding 模型
• 字段未形式化定义（工程语言而非学术语言）
• 未做大规模负载验证

---

许可

MIT