Skip to content
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
92 changes: 51 additions & 41 deletions src/data/post/memflywheel-memory-flywheel.md
Original file line number Diff line number Diff line change
@@ -1,58 +1,50 @@
---
publishDate: 2026-07-01T00:00:00Z
title: 'MemFlywheel:给 AI Agent 装上文件原生记忆飞轮'
excerpt: 'MemFlywheel 是面向 Agent Harness 的文件原生记忆飞轮,通过执行前召回、执行后沉淀和 dream 整理, Agent 每一次运行都更懂你。'
title: 'MemFlywheel:Agent 把每一次执行,沉淀成下一次更懂你的开始'
excerpt: 'MemFlywheel 是面向 Agent Harness 的文件原生记忆与自学习闭环,通过执行前召回、执行后沉淀、learned skill 演化和 dream 整理,让现有开源 Agent 框架获得可治理的长期记忆层。'
image: '~/assets/images/memflywheel-overview.png'
category: 'tech'
tags: ['memflywheel', 'ai-agent', 'memory', 'open-source']
author: 'iFLYTEK Open Source Team'
---

# MemFlywheel:给 AI Agent 装上文件原生记忆飞轮
# MemFlywheel:Agent 把每一次执行,沉淀成下一次更懂你的开始!

AI Agent 正在快速走向生产落地,但一个核心问题始终困扰着开发者:**Agent 如何记住过去的经验,并在下一次做得更好?**
AI Agent 正在快速走向生产落地,但一个核心问题始终困扰着开发者:如何让 Agent 把每一次执行,沉淀成下一次更懂你的开始?

目前大多数 Agent 框架将记忆交给模型上下文窗口或外部向量数据库,前者受限于窗口大小,后者则引入了额外的复杂度和延迟。科大讯飞开源的 **MemFlywheel** 提出了一种不同的思路——**文件原生(file-native)记忆飞轮**,让 Agent 的记忆以 Markdown 文件的形式持久化在本地,可检查、可 diff、可版本控制。
主流方案把记忆交给上下文窗口或外部向量数据库,前者受限于窗口大小,后者平添部署复杂度与检索延迟,且都只解决了“记住”,没有解决“学会”。科大讯飞开源的 MemFlywheel 走了另一条路:**文件原生(file-native)的记忆与自学习闭环**。记忆以 Markdown 文件落在本地,可检查、可 diff、可版本控制;重复出现的工作流被自动提炼成可复用的 learned skill,形成“越用越聪明”的飞轮

![](~/assets/images/memflywheel-overview.png)

## 核心设计理念

MemFlywheel 的定位非常明确:**它不替代 Agent Harness,而是作为记忆与学习的增强层**。宿主 Agent Harness 继续负责生命周期管理、模型访问、鉴权和工具调用;MemFlywheel 则专注于记忆闭环
MemFlywheel 不替代 Agent Harness,而是在宿主原有生命周期、模型、鉴权和工具体系之上,补上一层文件原生的记忆与自学习闭环

这一设计遵循三个原则:

- **文件原生(File-native)**:所有记忆、source trace 和 learned skills 都以 Markdown 文件存储,开发者可以直接查看、编辑和版本控制,无需依赖专用数据库。
- **宿主原生(Harness-native)**:通过 npm 包的方式接入 Pi、Hermes、OpenCode 和 OpenClaw 等主流 Agent Harness,不需要改造宿主架构。
- **模型无关(Model-agnostic)**:MemFlywheel 不绑定任何特定模型,可以在不同的 LLM 后端上运行。
- **文件原生(File-native)**:记忆和 learned skills 以可读文件沉淀,`MEMORY.md` 索引由扫描重建,source trace 保留可回溯证据。核心记忆文件和 learned skills 可按需纳入 Git,支持 diff、review 和版本回滚;source trace 与审计日志则按团队隐私策略管理。
- **宿主原生(Harness-native)**:以 npm 包形式接入 Pi、Hermes、OpenCode、OpenClaw 等开源 Agent 框架,不改造宿主架构。
- **模型无关(Model-agnostic)**:核心层不持有模型传输与鉴权,生成式步骤通过宿主模型契约完成。
- **闭环自学习(Closed-loop Learning)**:执行前召回,执行后沉淀,重复工作流演化为 learned skills,dream 再把冗余流程记忆压缩成技能线索。

## 记忆飞轮如何运转

MemFlywheel 的核心是一个完整的记忆生命周期,分为四个阶段:
MemFlywheel 不是“召回 + 存储”两件套,而是一条首尾相接、从记忆到自学习的闭环。

![](~/assets/images/memflywheel-lifecycle.png)

### 1. 执行前召回(Pre-recall)

在 Agent 执行任务之前,MemFlywheel 首先从 `MEMORY.md` 索引文件中读取线索,然后逐层加载记忆正文、source trace 和 learned skills。这种渐进式的召回机制确保了 Agent 在开始工作前就能获取到相关的历史经验。

### 2. 执行后提取(Turn-end Extraction)

当一轮对话或任务结束后,MemFlywheel 自动从交互记录中提取关键信息,将其转化为结构化的长期记忆。这些记忆以 Markdown 格式持久化到本地文件系统中。

### 3. Dream 整理(Dream Consolidation)

在 Agent 空闲时,MemFlywheel 会触发 dream 整理过程——对已有记忆进行去重、合并和修复,确保记忆仓库保持整洁和高效。

### 4. 技能飞轮(Skill Flywheel)
1. **召回(Recall)**。任务开始前,MemFlywheel 通过预召回(可选)或直接注入 `MEMORY.md` 索引线索,让宿主按需逐层深入到记忆正文、原始 source trace 和 learned skills。读多深由任务决定,绝不把整个记忆库塞进窗口。
2. **执行后抽取(Turn-end Extraction)**。对话一结束,抽取子代理就在后台自动开工,从增量对话里沉淀值得长期保存的信息,写成带溯源引用的类型化记忆,每条记忆都能回链到产生它的原始对话。
3. **技能演化(Skill Evolution)**。当你反复做同一类事,MemFlywheel 会察觉足够的完成轮次与工具调用密度,技能演化子代理把过程性知识提炼成 learned skill 包:沙箱暂存、校验通过才发布、失败自动回滚。
4. **Dream 整理(Dream Consolidation)**。趁 Agent 空闲,dream 过程整理记忆库:去重、合并、修复之外,还有**闭环的最后一步**,把散落在记忆里的冗余流程细节压缩成一条指向技能的路由线索。流程性知识从“记忆”毕业为“技能”,记忆库保持精简,下一轮预召回直接命中技能。

当 Agent 反复执行类似的工作流时,MemFlywheel 会将这些模式提炼为 **learned skills**——可复用的技能文件。Agent 可以直接检查、修改和调用这些技能,实现真正的"越用越聪明"
从预召回到抽取、演化、整理,全程不需要用户下任何指令。你唯一能感知到的,是 Agent 一次比一次更懂你

![](~/assets/images/memflywheel-skill-flywheel.png)

## 多宿主支持
这就是“飞轮”的含义:记忆喂养技能,技能反过来压缩记忆,每转一圈,Agent 的起点都比上一圈更高。整个过程中模型不输出任何“操作计划”,子代理的每一次文件工具调用本身就是变更,写入原子化、全程审计、失败不推进状态,可靠性由工程机制而非模型自觉来保证。

MemFlywheel 通过 npm 包的形式接入了四种主流 Agent Harness:
## 无缝接入

MemFlywheel 已经以原生插件形式接入四个开源 Agent Harness,后续会持续集成更多宿主。

| 宿主 | 安装方式 |
| ------------ | ------------------------------------------------------------------------- |
Expand All @@ -61,32 +53,50 @@ MemFlywheel 通过 npm 包的形式接入了四种主流 Agent Harness:
| **OpenCode** | `opencode plugin @iflytekopensource/adapters --global` |
| **OpenClaw** | `openclaw plugins install npm:@iflytekopensource/adapters` |

每个宿主都只需要安装对应的 npm 包,MemFlywheel 会作为原生记忆插件接入,无需修改宿主的模型、工具或权限配置
MemFlywheel 作为原生记忆插件接入各宿主,不接管宿主模型、工具和权限体系;用户只需按宿主插件机制完成少量配置,就能把记忆召回、执行后沉淀、dream 整理和 learned skills 接到现有工作流里

## 工程实践
## 评测:LoCoMo 基准

### 存储结构
MemFlywheel 当前在 LoCoMo Cat1/2/4 上的成绩:

MemFlywheel 的记忆仓库是一个标准的文件目录,核心文件包括:
| 指标 | 结果 | 配置 |
| --------- | ---------: | ----------------------------------------------- |
| LLM-judge | **81.23%** | `bge-m3` 向量召回 + DeepSeek V4 Flash 作答/评判 |
| Token-F1 | **65.93%** | 同一次运行 |

- `MEMORY.md`:记忆索引文件,包含所有记忆的摘要和线索
- 记忆正文:每个记忆条目一个 Markdown 文件,包含完整的上下文和 source trace
- Learned Skills:提炼后的可复用技能文件
MemFlywheel 是 agent-driven 的记忆系统,同一份测评集换不同模型成绩也会有所差异:qwen3.7-plus 87.12%、DeepSeek V4 Flash 81.23%、GPT-4o-mini 76.89%。

这种结构使得记忆可以无缝集成到现有的 Git 工作流中,支持 diff、review 和回滚。
放到公开系统的语境中(各系统评测配置不同,仅列有论文或官方基准的):

### 评测体系
| 系统 | 公开结果 | 技术路线 |
| ---------------- | ----------------------------- | ------------------------------------ |
| Mem0 | 67.13%(论文)/ 92.5%(最新) | 多级记忆 + 向量/图检索 |
| MemMachine | 91.69% | 完整会话情景 + 上下文化检索 |
| Honcho | 89.9% | 用户/Agent/群组建模的记忆服务 |
| **MemFlywheel** | **76.89%–87.12%(随模型)** | **文件原生,索引→正文→溯源逐层召回** |
| Memori | 81.95% | 语义三元组 + 会话摘要 |
| Zep / Graphiti | 75.14%–80.00% | 时序知识图谱 |
| Letta Filesystem | 74.00% | 文件系统检索(search/grep/open) |
| LangMem | 58.10%–78.05% | LangGraph BaseStore |

MemFlywheel 使用面向 LoCoMo 的回归检查来衡量长期记忆能力。在召回、提取和 learned skill 闭环的持续演进过程中,评测体系确保每一步改进都是可量化的。
值得注意的是:MemFlywheel 在**不引入向量数据库、不引入图数据库、记忆全程人类可读**的约束下,做到了与主流记忆系统同一梯队的成绩。这正是文件原生路线的价值主张。

## 工程实践

MemFlywheel 把记忆做成一套可治理的工程资产,而不是藏在服务端黑盒里。`MEMORY.md` 负责索引,类型化 Markdown 记忆负责承载事实、偏好、风格和流程经验,source trace 负责保留可回溯证据,learned skills 负责沉淀可复用工作流。索引可重建、文件可 diff、变更可审计,团队可以像管理代码一样管理 Agent 的长期记忆。

在写入链路上,MemFlywheel 采用原子写入、追加式审计和单库串行写锁,避免并发执行把记忆库写乱;在隐私链路上,`<private>` 标记内容会被确定性脱敏,明显的密钥、证件等高风险内容会被拦截在抽取阶段。它追求的不是“模型自己记得更好”,而是把记忆写入、召回、回溯和治理都放进可检查的工程流程里。

## 开源边界

MemFlywheel 有清晰的开源边界:它专注于记忆与学习闭环,不会将主 Agent、模型服务、工具权限或技能执行纳入自身。这一设计保证了 MemFlywheel 可以作为一个纯粹的基础组件,在各种 Agent Harness 中复用。
MemFlywheel 的边界也刻意保持克制:它不重写主 Agent,不接管模型服务,不改变宿主的工具和权限体系。它通过宿主生命周期接入,在任务开始前补记忆线索,在任务结束后沉淀记忆与技能,让现有 Agent Harness 获得长期记忆和自学习闭环。

这也是它能接入 Pi、Hermes、OpenCode、OpenClaw 等开源 Agent 框架的原因:宿主仍然是宿主,MemFlywheel 只是补上记忆飞轮这一层。技能由 MemFlywheel 存储、召回和镜像到宿主侧,是否加载、何时执行、执行权限如何控制,仍由宿主框架决定。

## 快速体验

- GitHub 仓库:[iflytek/memflywheel](https://github.com/iflytek/memflywheel)
- npm 包:[@iflytekopensource/adapters](https://www.npmjs.com/package/@iflytekopensource/adapters)
- npm 包:[@iflytekopensource/adapters](https://www.npmjs.com/package/@iflytekopensource/adapters)(另在 GitHub Packages 以 `@iflytek/*` 同步发布)
- 许可证:Apache-2.0

MemFlywheel 让 Agent 的记忆不再是黑盒,而是看得见、改得了、版本可控的工程资产。如果你的 Agent Harness 缺少一个可靠的记忆层,MemFlywheel 值得尝试
MemFlywheel 让 Agent 的记忆不再是黑盒,而是看得见、改得了、版本可控的工程资产,并且每一次运行,都在为下一次运行积累复利
Loading