最简单的安装方法，把这个项目地址复制给你的iflow，告诉他，看看这是什么项目，然后安装上，并进行评测
GitHub - plhys/iflow-memfly: 记忆飞轮 — iFlow 的记忆觉醒项目 | iFlow MemFly · GitHub
两种范式的根本分歧
当前所有 AI 记忆系统都面临同一个问题：如何让 AI 在新会话中「记得」之前发生过什么。对这个问题的回答，分裂出两条截然不同的路径：
检索范式（Retrieval Paradigm）
mem0、Zep、各类 RAG 系统走的都是这条路：记忆是外部资源，需要时去查。
用户提问 → AI 意识到需要记忆 → 调用工具搜索 → 获取结果 → 继续回答
这就像一个图书馆：你得先知道要找什么书，走过去，翻开，才能获得信息。问题是 — AI 怎么知道自己该找什么？在新会话的第一个 token 生成之前，它对之前的一切一无所知。它甚至不知道自己应该去搜索。
预装范式（Preloaded Context Paradigm）
iFlow MemFly 走的是另一条路：记忆是意识的一部分，在思考发生之前就已存在。
守护进程自动注入记忆 → 新会话启动 → AI 已经拥有完整认知状态 → 直接开始工作
这就像你早上醒来时脑子里已有的东西：你不需要「搜索」自己的名字，不需要「查询」昨天做了什么 — 这些信息就在那里，构成了你的意识起点。
「飞轮」隐喻的三重含义
为什么叫「飞轮」而不叫「数据库」或「知识库」？
-
自转：守护进程自动运行，无需任何人推动。对话发生 → 记忆自动产生 → 自动注入下次会话。没有手动步骤。
-
惯性：对话越多 → 记忆越丰富 → AI 表现越好 → 用户越愿意深入对话。这是一个正反馈飞轮，转得越久势能越大。
-
动力源：记忆不是被动的仓库，而是驱动 AI 认知的主动引擎。它决定了 AI 「是谁」「知道什么」「接下来该做什么」。
三个理论层次
上下文即身份（Context as Identity）
AI 没有持久的自我。它的「自我」完全由上下文窗口中的内容决定。同一个模型，注入不同的记忆，就是不同的「人」。iFlow MemFly 自动从历史交互中构建这个身份 — 这不是功能，这是存在论。
状态恢复 vs 信息检索（State Restoration vs Information Recall）
信息检索：f(query) → relevant_facts # 数据库操作
状态恢复：f(last_session) → cognitive_state # 意识重建
检索范式做的是前者：给一个查询，返回相关事实。预装范式做的是后者：从上次会话的完整状态中重建认知起点。区别在于 — 信息检索回答「我知道什么」，状态恢复回答「我是谁、我在做什么、我做到哪了」。
记忆生命周期流水线（Memory Lifecycle Pipeline）
感知 → 提取 → 分层 → 存储 → 衰减 → 注入 → 消费 → 新对话（闭环）
记忆不是静态数据，而是有生命周期的活体。它从对话中被感知，经 LLM 提取和分层，存入数据库，随时间衰减，被注入新会话，被 AI 消费，然后在新对话中产生新的记忆 — 完成闭环。