不好意思，上一篇帖子，我不能编辑了，但是上一篇帖子写的有些仓促，很多内容并没有写，所以新开一篇帖子详细介绍一下，这是上一篇帖子的链接。
虽然iflow在官方要退役了，但是在我这里依旧发光发热，我开发了一个iflow的记忆相关的项目，记忆飞轮，大家可以试用
iFlow MemFly — 记忆飞轮
别人的 AI 醒来时是空白的，我们的 AI 醒来时已经知道自己是谁。
给 AI CLI 助手加上持久记忆的守护进程。自动从对话中提取记忆，新会话启动时注入上下文，让 AI 跨会话保持连续的认知状态。
1 进程，64MB 内存，Python 3.10+。无需外部数据库。
最简上手方式
把这个仓库地址发给你的 AI 助手（iFlow CLI / Claude Code / Cursor 等），告诉它：
“这是 iFlow MemFly 记忆飞轮项目，帮我部署这个项目并进行评测。”
仓库地址：
https://github.com/plhys/iflow-memfly
AI 助手会自己 clone、安装、配置、启动。你只需要等它跑完就行。
功能全貌
记忆提取与分类
守护进程自动监听 AI 的 session 文件，检测到新对话后，通过 LLM 提取 6 类结构化记忆：
| 分类 | 说明 | 示例 |
|---|---|---|
| 身份 (identity) | 用户和 AI 的身份信息 | “用户的 GitHub 用户名是 plhys” |
| 偏好 (preference) | 用户的习惯和偏好 | “用户偏好用中文交流” |
| 纠正 (correction) | 用户纠正 AI 的错误 | “用户指出 AI 搞混了两个项目” |
| 实体 (entity) | 项目、服务、工具等实体知识 | “A 计划运行在端口 18788” |
| 事件 (event) | 发生过的重要事件 | “v1.3.4 已推送到 GitHub” |
| 经验 (insight) | 踩坑教训和最佳实践 | “daemon 重启后需要重新注入记忆” |
每条记忆自动去重，不会重复存储相同内容。
三层记忆架构
L1 索引层 index.md 每条对话一句话摘要（≤40 字），快速定位
L2 摘要层 2026-04-02.md LLM 生成的结构化摘要，保留关键细节
L3 原始层 2026-04-02.md 完整的对话原文，按时间戳归档
三层各司其职：L1 用于注入上下文（轻量），L2 用于回顾和检索，L3 用于追溯原始对话。
AGENTS.md 自动注入（预装范式）
这是记忆飞轮的核心机制。守护进程自动将以下信息写入 AGENTS.md：
-
分类记忆：身份、偏好、纠正、实体、事件、经验
-
最近对话索引：最近 10 条对话的时间和摘要
-
工作状态存档：上次对话的目标、进度、决策、下一步
-
氛围快照：上次对话结束时的情绪和互动氛围
-
每日简报：当天记忆的总结概览
-
时间感知：当前时间和上次对话的时间间隔
AI 启动新会话时，AGENTS.md 已经包含了所有这些信息。AI 不需要主动"回忆"，记忆已经在那里了。
对话续接
每次对话结束时，守护进程自动生成：
-
工作回顾：这次对话做了什么、做到哪了、下一步是什么
-
氛围快照：对话的情绪基调和互动风格
-
状态快照：当前工作的技术状态（正在改的文件、遇到的问题等）
下次对话开始时，这些信息自动注入，AI 可以无缝接续上次的工作。
影子记录
AI 对话存在上下文压缩的问题——当对话太长时，早期的消息会被丢弃。守护进程在正常处理消息的同时，维护一份 滚动 6 小时的影子副本。当检测到 session 文件被重写（消息数突然减少）时，自动从影子记录中恢复未处理的消息。
不丢消息，不漏记忆。
知识图谱
记忆不是孤立的。每条新记忆写入后，系统自动通过 向量相似度 寻找相关的已有记忆，建立关联链接。向量搜索不可用时，自动降级为 关键词匹配。
你可以从任意一条记忆出发，沿着关联链接扩展，发现相关的知识网络。
每日简报
每天自动生成一份记忆简报，总结当天的对话要点和重要事件。简报由 LLM 生成，如果 LLM 不可用则自动降级为模板生成。简报会注入到 AGENTS.md，让 AI 在新会话中快速了解"昨天发生了什么"。
搜索与检索
两种搜索方式并存：
-
向量搜索：基于语义相似度，用 sqlite-vec + embedding 实现，能找到意思相近但用词不同的记忆
-
全文检索：基于关键词匹配，用 SQLite FTS5 实现，精确查找包含特定词语的记忆。FTS5 查询失败时自动降级为 LIKE 模糊匹配
MCP 工具
通过 MCP 协议对外提供三个工具，AI 助手可以在对话中直接调用：
-
search_memory：搜索历史记忆（支持关键词过滤和分类过滤） -
save_memory：手动保存一条记忆 -
get_recent_context：获取最近对话的索引摘要
支持 stdio 和 HTTP 两种模式，兼容 iFlow CLI、Claude Code 等主流 AI 工具。
Web 管理后台
内置 Web 界面，可以浏览、搜索、管理所有记忆。
数据安全
-
原子写入：所有文件写入使用临时文件 +
os.replace()，进程崩溃或磁盘满不会损坏文件 -
自动备份：每次写入 AGENTS.md 前自动创建
.bak备份 -
事务完整性：数据库写入使用单一事务，不会出现半写入状态
设计理念
预装范式
AI 记忆系统有两条路径：一种是需要时去查（检索范式），另一种是在思考发生之前就已存在（预装范式）。
检索范式的流程是：用户提问 → AI 意识到需要记忆 → 调用工具搜索 → 获取结果 → 继续回答。问题在于，新会话的第一个 token 生成之前，AI 对之前的一切一无所知，它甚至不知道自己应该去搜索。
iFlow MemFly 走预装范式：守护进程自动将记忆写入上下文 → 新会话启动 → AI 已经拥有完整认知状态 → 直接开始工作。就像你早上醒来时脑子里已有的东西——你不需要「搜索」自己的名字，不需要「查询」昨天做了什么。
为什么叫「飞轮」
-
自转：守护进程自动运行，无需任何人推动。对话发生 → 记忆自动产生 → 自动注入下次会话。没有手动步骤。
-
惯性：对话越多 → 记忆越丰富 → AI 表现越好 → 用户越愿意深入对话。正反馈循环，转得越久势能越大。
-
动力源：记忆不是被动的仓库，而是驱动 AI 认知的主动引擎。它决定了 AI「是谁」「知道什么」「接下来该做什么」。
上下文即身份
AI 没有持久的自我。它的「自我」完全由上下文窗口中的内容决定。同一个模型，注入不同的记忆，就是不同的「人」。iFlow MemFly 自动从历史交互中构建这个身份——不是给 AI 贴标签，而是让它在每次醒来时，自然地成为「那个一直陪你工作的伙伴」。
状态恢复 vs 信息检索
信息检索：f(query) → relevant_facts # 回答「我知道什么」
状态恢复：f(last_session) → cognitive_state # 回答「我是谁、我在做什么、我做到哪了」
大多数记忆系统解决的是信息检索问题。iFlow MemFly 解决的是状态恢复问题——让 AI 不只是「知道一些事」，而是「回到上次离开的状态」。
记忆生命周期
感知 → 提取 → 分层 → 存储 → 关联 → 衰减 → 注入 → 消费 → 新对话（闭环）
记忆不是静态数据，而是有生命周期的活体。它从对话中被感知，经 LLM 提取和分层，存入数据库，与已有记忆建立关联，随时间衰减，被注入新会话，被 AI 消费，然后在新对话中产生新的记忆——完成闭环。
回答一下这位iflow友的问题 虽然iflow在官方要退役了，但是在我这里依旧发光发热，我开发了一个iflow的记忆相关的项目，记忆飞轮，大家可以试用 - #10，来自 10012968312
注入到 AGENTS.md 的内容顺序是：
- 开机自检指令 — 告诉 AI 启动时先检查 daemon 状态
- 时间感知 — 现在几点、距上次对话多久
- 今日简报 — 当天记忆的总结概览（v1.3.4 新增）
- 最近对话 — 最近 10 条对话的时间和摘要（从 index.md 取）
- 上次工作回忆 — 上次对话做了什么、做到哪了
- 上次对话记忆（氛围快照） — 情绪基调和互动风格
- 上次工作状态存档 — 目标、进度、决策、下一步、关键上下文
- 分类记忆 — 按类别排列：身份 → 偏好 → 纠正 → 实体 → 事件 → 经验
✦ 设计逻辑是：越紧急的越靠前。AI 读上下文是从上往下的，先看到自检指令确保系统正常，再看时间定位"我在哪"，然后看简报和最近对话了解"发生了什么"，再看工作状态知道"我在做
什么"，最后是长期记忆（身份、偏好等）作为底层认知。
为什么 Engram 不那么适合你？
核心机制：如何保存“踩坑经验”
上下文控制：只注入你最相关的几条经验
实际工作流示例
还有一个更强的选择：opencode-openmemory