很多 AI 学习工具最后仍然停在一个聊天框里：你问，它答；这次对话结束后，它依旧很难知道你真正学到了哪里、哪些知识反复出错、什么内容已经忘记，以及下一步应该继续学还是先复习。
我做 Mnemox，想解决的并不是“怎样让 AI 回答得更聪明”，而是另一个问题：怎样让 AI 基于真实学习行为、可追溯知识和长期状态，给出下一步真正能执行的建议。
目前正式发布版本仍是 v1.3.0，GitHub main 已进入 post-v1.3 开发基线，并完成 Mnemox V2 Stage 7 的工程收口。正式发布版与开发主线会刻意分开，避免把“代码已经实现”误写成“已经正式发布”。
先看整个学习闭环
Mnemox 把资料、笔记、学习行为、记忆、复习和 Agent 放进同一条链路，而不是做成彼此孤立的功能。
这里最重要的一条原则是：Agent 可以提出行动，但不能绕过用户直接替用户做决定。 计划、任务等写入动作需要经过草案与确认；行为结果再重新进入学习状态，形成下一轮上下文。
1. RAG 不只是“向量搜一下”
资料支持 PDF、Word、Markdown 和 TXT。检索由 RetrievalRouter 统一收敛资料、笔记、概念、长期记忆和学习状态。
资料检索目前采用：
- Chroma dense retrieval；
- SQL 关键词检索；
- RRF 融合；
- embedding 不可用时的关键词降级；
- 来源版本、删除、重建与用户隔离。
我刻意没有把向量库当作事实来源。SQLite / PostgreSQL 与原始文件保存规范数据，Chroma 只是可以重新生成的检索投影。
这意味着向量索引损坏、embedding 服务不可用、资料发生更新或删除时，系统仍然有一份可以核对、重建和迁移的数据边界。
2. V2：从“搜到一段文本”走向 Claim + Evidence
传统 RAG 很容易回答“这段资料里写了什么”，但如果希望做知识关联、概念关系和可解释推荐，就需要知道系统当前相信的“事实”到底来自哪里。
Mnemox V2 因此增加了一层 Claim 中心知识模型：
自动抽取出来的 Claim 不会因为“模型说了”就直接成为可信事实。它需要保留来源版本和 Evidence 定位，并经过状态与审核边界后才能进入可见知识层。
这一层解决的是知识系统里很容易被忽略的问题：不仅要知道答案是什么，还要知道答案为什么存在、来自哪一版资料、什么时候失效，以及删除原资料后该怎样同步清理。
3. 为什么先用 SQL 图，再引入 Neo4j
早期的关系查询主要是 shared concept、直接关系和 1～3 hop 固定模式。为这些查询立刻引入独立图数据库，会增加部署、同步和故障处理成本。
所以我先抽象了 GraphStore，默认实现使用 SqlGraphStore：业务层表达的是“我要什么图语义”，而不是直接依赖 SQLAlchemy 或 Cypher。
后来 Claim / Concept 图逐渐成形，再通过 Transactional Outbox 构建 Neo4j Projection，并做 Shadow 对照。Stage 6 的真实对比里，在 5,000 Claim 规模下：
| 场景 | SQL p95 | Neo4j p95 | 结论 |
|---|---|---|---|
| combined multi-hop | 约 33.97 ms | 约 19.20 ms | Neo4j 更适合多跳图执行 |
| direct query | 约 23.71 ms | 约 25.77 ms | 没有稳定切换收益 |
所以最终不是“SQL 或 Neo4j 二选一”，而是：
- PostgreSQL / SQLite 继续做 Canonical Source of Truth；
GRAPH_BACKEND=sql仍是默认路径和桌面端 fallback；- Neo4j 成为可选 Graph Backend；
- 图投影过期或 Neo4j 故障时，基础能力不能被拖垮；
- 真正需要路径搜索时，再使用图数据库擅长的执行能力。
在这个基础上，Mnemox 已经做出第一个 Graph-native 产品切片：Knowledge / Learning Path。它可以在概念图里寻找受限深度路径，再叠加用户 mastery 与 Evidence，解释从“当前掌握的概念”到“目标概念”之间还缺哪些节点。
Association 也增加了可选的多跳解释层。图负责发现 topology，最终展示给用户的 Concept、关系和来源仍回到 Canonical SQL 重新核对，避免把投影数据库误当成事实系统。
4. Memory 不是“把聊天扔进向量库”
Mnemox 的长期记忆更接近一个有生命周期的事实系统。
同一个事实可能会变化，比如：
“我准备 10 月参加考试”
几周后变成：
“考试延期到 12 月。”
如果只是把两句话都存在向量库里，检索时很可能同时召回两个互相冲突的答案。
因此当前 Temporal SQL 会记录稳定事实键、来源、确认状态、有效时间、替代关系和纠错历史。旧事实在新事实确认前仍然有效；确认后保留替代链，过期或删除的数据会退出聊天、Coach、Agent 和派生画像。
Graphiti 目前被保留为独立的 Temporal / Episodic 实验切片，而不是替换现有 SQL Memory。真实验证中它的时态正确性通过，但当前运行成本和延迟仍明显高于 SQL，因此继续保持 Experimental、default-off。
5. Agent 要会行动，也要能停下来
Mnemox 的 AgentRuntime 没有采用“模型拿到工具以后随便跑”的方式。
目前已经实现的关键边界包括：
- 任务持久化，而不是只存在一次 HTTP 请求里；
- 每一步保存受限 checkpoint；
- SSE 实时返回执行过程，断线后可从数据库回放；
- 支持取消、失败后继续以及租约过期恢复；
- 调用前预算估算，调用后记录真实 usage；
- Provider 不可用时可以退回规则型建议；
- 写入任务、计划等动作必须先生成服务端确认凭据，再由用户确认执行；
- 定时评估默认关闭，只有用户显式开启后才运行。
我更希望它像一个“有边界的学习教练”，而不是一个为了显得自动化而获得无限权限的 Agent。
6. 学习本身仍然是产品核心
这些技术最终都要回到学习行为，而不是停留在架构图里。
| 模块 | 在 Mnemox 里解决什么 |
|---|---|
| FSRS | 根据真实复习结果安排下一次复习，并保留旧调度降级路径 |
| Learning Events | 记录番茄钟、错题、复习、目标等真实学习行为 |
| Learner Model | 从学习证据计算专注、坚持、薄弱点和概念状态 |
| Coach | 根据当前状态生成受冷却、反馈和行动边界约束的建议 |
| RetrievalRouter | 把资料、笔记、概念、记忆与学习状态带回当前上下文 |
| Claim / Concept Graph | 把知识关联建立在来源和 Evidence 上，而不是模型猜测上 |
| AgentRuntime | 把建议变成可恢复、可确认、可审计的下一步行动 |
这也是我对项目定位越来越明确的地方：Mnemox 不需要替代 Obsidian、Anki 或通用聊天工具，它更应该负责这些工具很难单独完成的“学习状态理解 + 知识关系 + 行动闭环”。
7. 当前工程状态
截至 2026-09-04 的 GitHub 开发基线：
- 正式发布版本仍为
v1.3.0； - Mnemox V2 Stage 7 工程收口完成；
- Stage 0～7 Knowledge / Temporal 宽回归为
149 passed, 1 warning； - 真实 Neo4j / Graphiti 专项为
6 passed； - 前端为
27 files / 93 tests，production build 与 lint 通过； - 默认 Compose 不启动 Neo4j，只有显式开启 graph profile 才加载可选图服务；
- 下一步重点从“继续堆基础设施”转向 WebUI dogfooding，用真实中文/双语技术笔记验证检索、知识关联与学习路径体验。
这些数字只是工程门禁，不代表产品已经成熟。当前仍有正式数据库升级、真实 Windows Electron E2E、新版发布和长期真实用户样本等工作没有完成。
这个项目对我最大的价值
Mnemox 最初只是一个“AI 学习教练”的想法，后来逐渐变成我学习 AI Application Engineering 的长期实验场。
我更在意的已经不是“用了多少技术”，而是每次新增一层之前先回答几个问题：
- 这个问题现有方案真的解决不了吗？
- 新组件是事实源，还是可以随时重建的投影？
- 它失败以后，基础产品还能不能工作？
- 用户的数据怎样隔离、删除和追溯？
- 如果模型判断错误，用户还有没有最后确认权？
对我来说，这些取舍比把 RAG、Agent、Neo4j、Graphiti 写进技术栈更重要。