你有没有遇到过这种情况：今天让 Claude Code 重构了一个模块，明天再开新会话让它继续干活，它却完全不记得昨天定下的命名规范、技术选型和那些"踩过坑的约定"——你只能重新花十分钟把背景喂给它。这不是某个工具的问题，而是几乎所有 AI Agent 的原生缺陷：它们天生失忆，上下文窗口一到就清零。
8 月 13 日，一位开发者开源了一个叫 MCP-Memory 的项目（GitHub 仓库 fellowgeek/mcp-memory），当天就登上了 Hacker News 首页（40 分、19 条评论），上线第一天拿到 50 颗星。它的价值不在算法多惊艳，而在于把两样现成的东西组合到了一起：Google 的 OKF（Open Knowledge Format）知识格式标准 + SQLite FTS5 全文检索，然后用 MCP 协议把这份记忆喂给所有主流 Agent。这篇文章带你把它跑起来，并讲清楚背后那个更值得关注的信号——Google 正在给"Agent 记忆"定标准。
▲ 图1
先搞懂：Agent 为什么需要"记忆"，又为什么一直做不好
先给不熟悉的朋友补个背景。所谓 Agent harness，就是 Claude Code、Codex、Cursor 这类"给大模型接上终端、文件系统和工具，让它自己循环干活"的宿主程序。它们内部都有个上下文窗口，装着你这次的对话、读过的文件、工具调用结果。窗口一满，早期的信息就会被挤出去——这就是"失忆"的物理根源。
目前社区里解决"跨会话记忆"的路子大致有四条，各有各的硬伤：
- 上下文填充：每次开局把历史笔记全塞进 prompt。问题是 token 贵，而且塞得越多，模型越容易分心。
- 云端记忆服务（比如 Mem0）：功能强，但要联网、要付费、数据进了别人的服务器。
- 向量数据库：能搜语义，但引入了一整套 embedding 依赖和运维成本，对个人开发者偏重。
- 自己写 JSON/文本文件：零成本，但没有检索、没有结构化，跨项目复用基本靠手抄。
MCP-Memory 的答案是第 5 条：本地 SQLite 做索引，OKF 标准做格式。它不用你连网，不用你付钱，记忆文件是纯 Markdown，你能用 cat 直接看、用 Git 直接管，同时又有一个 FTS5 索引让 Agent 在毫秒级搜到它。这套组合的巧妙之处，下面拆开讲。
OKF 是什么：Google 给 Agent 记忆立的"通用格式"
OKF 全称 Open Knowledge Format，是 Google Cloud Platform 在 knowledge-catalog 仓库里维护的一套开源标准，目前版本是 v0.2。社区对它的一个流行概括是——"Google 版的 Karpathy LLM Wiki"。
它最核心的一句话定义是：一个由 Markdown 文件 + YAML frontmatter 组成的目录。没有 schema 注册表，没有中心权威，没有强制工具链。原话很直白：如果你会 cat 一个文件，你就能读 OKF；如果会 git clone 一个仓库，你就能发布 OKF。
但 OKF 真正的门槛不在于"能存"，而在于它把传统 Markdown 笔记不关心、而 Agent 记忆却绕不开的五个问题，做成了一等公民：
- provenance（来源）：这条知识是从哪来的、谁生成的？
- trust（可信度）：我该多相信它？
- freshness（新鲜度）：它现在还有效吗？
- lifecycle（生命周期）：它是草稿、稳定版还是已废弃？
- attestation（证明）：这个数字是按我们规定的方式算出来的吗？
在 OKF v0.2 里，这些问题通过 frontmatter 里的字段落地：sources 记录来源，verified 记录谁在何时验证过，status 标记 draft / stable / deprecated，stale_after 给记忆设过期日。
一张 frontmatter，把五个问题全答了
光讲概念有点干，我们看一条真实记忆的 frontmatter，五个问题就都有答案了。假设你的 Agent 从官方文档里读到了一个 API 的限流阈值，然后存下这条记忆：
- 来源：
sources写明了它来自哪份文档的哪个小节。 - 可信度：
verified里有一条human:roger在 8 月 13 日的验证记录——也就是说这是经过人确认的，不是机器瞎猜的。 - 新鲜度：
stale_after设了 2026-12-31，过了这天这条记忆就该重新核实。 - 生命周期：
status: stable说明它是稳定版，不是draft草稿。 - 证明：
type: Metric表示这是条"指标"类知识，未来如果接入Attested Computation类型，还能进一步约束"这个数字必须由某段指定代码算出"。
一句话总结：OKF 不规定你怎么写知识，只规定怎么让一条知识"可信、可追溯、可失效"。这正是 Agent 记忆区别于普通笔记的地方——当大部分知识是机器自动生成的，你需要的不是一个更大的笔记文件，而是一套能回答"我凭什么信它"的约定。
OKF 和 Karpathy LLM Wiki 差在哪
很多人第一次听到 OKF 会联想到 Karpathy 之前提的 LLM Wiki（用大模型自举生成、互链的 Markdown 知识库）。两者都选了"Markdown 文件"这个载体，这是共识；但 OKF 往前走了一步：LLM Wiki 关心的是"怎么让模型把知识写下来、链起来"，而 OKF 关心的是"写下来之后，怎么让人和机器都能信任、审计、判定过期"。
举个最直观的区别：LLM Wiki 里的一条笔记，你无从知道它是人写的还是模型编的、是三个月前还是昨天写的；而 OKF 里同样的内容，generated.by、verified、stale_after 三个字段就把它钉死了。对于"把知识资产化、要长期复用"的创业团队来说，这一步是决定性的——可审计的记忆才敢放心交给 Agent 自动维护。
▲ 图2
架构：双层存储，人和机器各取所需
MCP-Memory 的存储设计是双层的，这个设计很聪明：
- 给人类看的一层：每个项目根目录下有个
memory/文件夹，每条记忆自动落盘成一个.md文件，还带分层index.md索引和log.md更新历史。你随时可以打开看、手动改、用 Git 做版本管理。 - 给机器搜的一层：项目根目录下有个隐藏的
.mcp_memory/memories.db，用 SQLite FTS5 建全文索引，配合触发器做键值查找——官方宣称单次键查找低于 20 毫秒。
它对外暴露五个 MCP 工具，覆盖了记忆的完整生命周期：
| 工具名 | 作用 | 使用时机 |
|---|---|---|
memory_store | 写入/更新一条记忆 | 学到新东西、定下新约定时 |
memory_retrieve | 按 key 精确取回 | 需要某条已知记忆时 |
memory_search | 关键词/标签全文搜索 | 记不清 key，只记得大概内容时 |
memory_get_last | 读上次的会话检查点 | 每次会话开场必做 |
memory_update_last | 更新会话检查点 | 完成里程碑、暂停工作时 |
其中最后两个工具设计得尤其贴心。它强制约定 Agent 在会话开始时先 memory_get_last 看上次干到哪了，在里程碑或收工时用 memory_update_last 写下进度快照。这就是把"断点续传"这件每个 Agent 都该做、却总被忘掉的事，做成了框架级的默认动作。
接入：三步装好，零手动运维
环境要求只有一个：Python 3。下面开始实操。
第一步，克隆仓库：
第二步，跑安装向导。 项目自带一个 setup.py，能自动探测你机器上装了的 AI 工具（Claude Desktop、Cursor、Windsurf、Codex、Antigravity），并把 MCP-Memory 注册进去：
跑完向导，你的 AI 客户端会在需要时自动在后台拉起 MCP-Memory，你不需要手动开一个常驻服务进程。
第三步（可选），手动配置。 如果向导没识别到你的工具，或者你想手动控制，就自己往客户端配置里加一条 server 项。Claude Desktop / Cursor / Windsurf 走 JSON：
Codex 桌面版走 TOML，加进 ~/.codex/config.toml：
命令行版本的 Agent 也有对应写法。Claude Code CLI 和 Codex CLI 分别用：
装好之后，你可以先跑一遍自带的测试套件，确认 OKF 序列化、SQLite 操作和 MCP 工具都正常：
如果一切通过，你会看到测试用例逐条绿色的输出，说明环境已经就绪。
实操：五个工具怎么用
下面按真实场景走一遍。假设你在做一个叫 my-app 的项目，想要让 Agent 记住你的编码偏好。
场景一：存一条记忆。 你告诉 Agent"我喜欢函数式风格、显式类型标注"，它会调 memory_store：
这条记忆落盘后，在 memory/ 目录里生成的 OKF 文件长这样：
注意看这个 frontmatter：key 用了路径式命名（user/preferences/coding_style），这就是 OKF 里的命名空间隔离——user/ 前缀归用户偏好，project/ 前缀归项目架构，互不污染。
场景二：精确取回。 下次会话开场，Agent 想确认你的编码风格，调 memory_retrieve：
返回就是上面那份 OKF 文档的内容，Agent 直接把你的偏好接进上下文。
场景三：模糊搜索。 你只记得"好像存过一条关于数据库连接的东西"，Agent 就调 memory_search：
这里 FTS5 全文索引就派上用场了——它不是精确匹配 key，而是在所有记忆的 key、frontmatter 和正文里做关键词搜索，毫秒级返回命中的记忆列表。
场景四：断点续传。 这是最推荐养成习惯的一对操作。会话一开始：
对应工具 memory_get_last，返回上次会话留下的 system/last_memory 检查点。收工时再调 memory_update_last，写下一句话进度：
这样下次无论换哪个客户端、隔了多久，Agent 都能从上次停下的地方接着干，而不是从零开始猜。
把四个场景串成一次真实协作
单独看每个工具有点零散，把它们串起来，你就能看到这套记忆系统在真实工作里是怎么转起来的。想象一个周五的完整流程：
- 早上的会话：Agent 开场先
memory_get_last，读到周四晚上留下的检查点"数据库迁移写了一半，还剩两张表"。它没有重新探索整个项目，而是直接从两张表继续。 - 干活中途：你纠正了一句"这里别用全局变量，用依赖注入"，Agent 调
memory_store把这条存成project/architecture/di_preference。 - 收工前：Agent 调
memory_update_last，写下"迁移已完成，单元测试跑了 38/38 通过，下周一从集成测试开始"。
下周一你换了一台机器、换了一个客户端打开同一个项目，Agent 开场一问，三步的进度全回来了。这就是"跨会话长期记忆"落到实处的样子——它不是把整个历史塞回上下文，而是只取回"该记得的几条"。
▲ 图3
成本：这是一套零成本的本地方案
MCP-Memory 最打动个人开发者和创业者的地方，是它的成本结构：
| 维度 | MCP-Memory | 云端记忆服务（如 Mem0） | 手写 JSON/笔记 |
|---|---|---|---|
| 运行成本 | 零，本地 SQLite | 订阅费/按量计费 | 零 |
| 是否联网 | 不需要 | 需要 | 不需要 |
| 数据归属 | 全部在本地 | 数据在第三方服务器 | 本地 |
| 检索能力 | FTS5 全文+标签 | 向量语义搜索 | 基本没有 |
| 跨工具通用 | 任意支持 MCP 的 Agent | 需装对应 SDK | 靠手抄 |
| 格式标准 | OKF（可移植） | 私有格式 | 无格式 |
对"一人公司"或内容创业者来说，这个表格基本可以翻译成一句话：在不想为记忆额外付费、又不想把数据交给别人的前提下，MCP-Memory 是目前把检索、结构化和可移植性配平得最好的一条路。它没有向量检索的语义理解能力，但换来了零依赖、零成本、纯本地。
踩坑提醒：装之前先看这五条
坑一：
project_root是必填参数，漏了会直接报错。 五个工具里除了搜索，几乎都要求传project_root（项目的绝对路径）。很多第一次用的人会漏掉它，结果工具调用失败还不知道为什么。记忆默认是"按项目隔离"的——这是特性，不是 bug。
坑二：
generated.by字段要遵循 actor 约定。 OKF 对"谁生成了这条知识"有格式要求，形如、/ human:或process:。如果你让 Agent 自己生成记忆，最好显式指定生成者，否则溯源（provenance）这一维就形同虚设了。
坑三：中文内容 + FTS5 的默认分词器会失效。 SQLite FTS5 默认的
unicode61分词器对中文按整句切分，中文关键词搜索会搜不到。如果记忆里大量是中文，需要把分词器换成支持中文的（如 trigram tokenizer 或 jieba 方案）。这是本地 SQLite 记忆方案在中文场景下最常见的暗坑，官方 README 没有直接给方案，需要自己改db.py里的建表语句。
坑四：向导没识别到工具时，别卡在原地。
setup.py的自动探测依赖各客户端已正确安装且在默认位置。如果你用的是绿色版、便携版或非默认路径的 Claude Code / Codex，向导会静默跳过。这时候直接用手动配置那三行 JSON/TOML 就行，效果完全一样。
坑五：默认是"每项目一库"，想要全局记忆要显式配置。 默认配置下，每个项目根目录里各有一份
memory/和.mcp_memory/memories.db。如果你想在所有项目间共享一份全局记忆，需要显式设置环境变量MCP_MEMORY_DB_PATH和MCP_MEMORY_DIR指向同一个全局路径。不设置的话，你会发现"上个项目存的约定，这个项目读不到"——这同样是设计使然。
中文场景适配：让 FTS5 会"分词"
上面坑三提到的问题值得单独展开，因为国内开发者大概率会遇到。SQLite FTS5 的默认 unicode61 分词器是给拉丁语系设计的，它把"数据库连接池"当成一个整体词元，你搜"连接池"就搜不到，因为它没法把连续的汉字切开。两个可行的修法：
- 用 trigram tokenizer 建索引：把文本按连续三个字符切分，"数据库连接池"会被切成"数据""据库""库连""连接""接池"等，搜索时同样切分再匹配。好处是不依赖外部库，坏处是索引体积会变大。
- 接入 jieba 分词：在写入时用 jieba 把中文先切好再交给 FTS5 索引，搜索时同样先切。这是最贴合中文习惯的方案，代价是要引入 jieba 依赖。
无论哪种，关键点都落在建表语句上——db.py 里 CREATE VIRTUAL TABLE ... USING fts5 那行的 tokenize 参数。如果你的记忆库里主要是英文技术术语，默认配置也够用；一旦中文内容开始变多，越早改分词器越省事，否则你会积累一堆"存得进去、搜不出来"的死记忆。
适用边界：这套东西不是万能的
任何工具都得先搞清楚"什么时候不该用"，否则很容易高估它。MCP-Memory 适合的场景很明确：
- 个人/小团队的编码与项目协作：记住编码偏好、技术选型、踩坑约定，跨会话断点续传，这是它的主场。
- 知识资产要长期沉淀、要可审计的团队：OKF 的溯源和过期机制，让你敢把知识库交给 Agent 自动维护。
- 对数据主权敏感、不想上云的用户：数据全在本地硬盘，零联网。
反过来，下面几种情况它就不那么合适了：
- 需要语义级模糊匹配的场景。FTS5 是关键词/标签检索，不是向量语义搜索。你说"帮我把那个处理大文件的地方找出来"，它搜不到，因为你没给对关键词。要语义理解，还是得上向量数据库或 Mem0 那一路。
- 多设备、多机器要实时同步的记忆。它的记忆是本地文件 + 本地 SQLite，没有内置同步。跨机器只能靠你自己 Git 提交记忆目录，或者干脆配一个全局路径再手动同步。
- 要严格保证"数字由指定代码算出"的重型合规场景。OKF 的
Attested Computation类型给了这个方向，但 MCP-Memory 目前只是个存储层，并没有把可验证计算真正跑起来。
把这些边界想清楚，你才知道它是你的"默认记忆层"，还是只是工具箱里的一个选项。对大多数个人开发者和内容创业者而言，它在"零成本、纯本地、可移植"这三点的交集上，暂时没有直接对手。
总结：比工具更值得关注的，是标准
MCP-Memory 本身只有几千行代码，一个周末就能读完。它真正的价值，在于把 Google 的 OKF 标准从一纸 SPEC 变成了可跑的东西，并且证明了一件事：Agent 记忆这个赛道，正在从"各家私有格式乱战"走向"一个可移植的通用格式"。
对 AI 创业者来说，这里有两层可以立刻行动的判断：
- 如果你在给 Agent 写记忆/知识管理功能，别再造轮子了，直接让产出对齐 OKF 规范——
sources、verified、stale_after这几个字段，未来大概率会成为 Agent 之间交换知识的事实标准。 - 如果你只是想让自己手里的 Claude Code / Cursor 更"记得住事"，今晚花十分钟跑一遍
setup.py，明天你就能享受跨会话断点续传，而且一分钱不花、数据全在自己硬盘上。
工具会迭代，仓库会改名，但"让机器生成的知识可信、可追溯、可失效"这个需求，只会越来越硬。OKF 和 MCP-Memory，是目前回答这个问题的最轻量答案之一。把记忆这件事想清楚，你的 Agent 才算真正从"工具"变成了"搭档"。
本文由AI辅助创作，经人工审核编辑发布
更多一人公司案例与工具，微信搜索「AI创业内参」关注我们