昨晚 HN 榜首是一个叫 OKF Agent Memory 的项目，主张一句话：Agent 的长期记忆应该住在 Git 里，不该住在别家公司的向量库里。我打开它文档的第一反应，是有点熟——因为我用 OpenClaw 每天在做的事，就是把记忆写进 memory/YYYY-MM-DD.md 和 MEMORY.md。这套 Git-native 思路根本不是新东西，只是 OKF 第一次把它工程化、给了个专门的搜索引擎。
TL;DR
- OKF Agent Memory：Go 写的 CLI，用 In-Memory BM25 索引 Markdown 文件，搜索延迟 <300µs，冷启动 <4ms，零外部依赖，Apache-2.0
- 对手 mem0 / Letta / Zep 走"向量库 + Postgres/Neo4j"路线，检索延迟 150-800ms，还要 API 费用
- OKF 的核心不是"更快"，而是把 Agent 的记忆变成 Git 里的可 diff、可 blame、可 rollback 的一等公民
- OpenClaw 的
memory/YYYY-MM-DD.md+MEMORY.md早就是这个思路，只是没上索引；OKF 补了这一块- 谁该上：写代码的 Agent、企业合规场景、不想被 SaaS 绑架的团队。谁别上：需要多用户人格记忆、跨会话情感对话的产品
为什么 Agent 记忆的黑箱化让越来越多人受不了？
主流"Agent 记忆"方案长这样：
你的对话 → 向量化 embedding → 塞进 Pinecone/Postgres/Qdrant → 检索时相似度匹配
看着高级，实操上有三个我踩过的坑：
第一，你看不到它记了啥。 Pinecone 里存的是一堆浮点数，你翻它的表看不出 Agent 到底记住了"我上周说了 JWT 用 RS256"还是"我上周说了 JWT 用 HS256"。出问题只能靠调 prompt 复现。
第二，改一条记忆要动一次数据库。 想让 Agent 忘掉某个错误决策？你得写 SQL 或调 API。不是"删一行文本"这么简单。
第三，你的记忆被绑死在一个 SaaS 上。 换个记忆服务，等于让 Agent 失忆重建。企业合规更麻烦——审计问"这个决策 Agent 是何时学到的"，你没法回答。
Reddit 上有个开发者写了个帖子叫 《2 years building agent memory systems, ended up just using Git》，一句话概括了这波觉醒：
我能知道它是"什么时候"学到某件事的（git blame），我能"回到过去"看它当时知道什么（git checkout），我能"看看它这半年怎么变了"（git diff）。
OKF Agent Memory 具体做了什么不一样的事？
它把记忆存成一堆 Markdown 文件，每个文件带一段 YAML frontmatter 表明"是谁写的、可信度多少、什么时候写的"：
$ okf bootstrap . # 在项目里初始化
$ okf search "jwt auth flow" knowledge
Score: 4.82
architecture/auth-decision.md
Trust: verified
Author: human:[email protected]
Summary: Use RSA-256 JWTs with 15m expiration
⚡ Retrieved in 268.4µs via In-Memory BM25
三个我觉得值得说的设计点：
In-Memory BM25：全站 Markdown 一次性 slurp 进内存，用 BM25 算相关度。没有向量化步骤，没有 GPU，没有 embedding API 费用。代价是内存占用会随知识库增大——他们号称能扛"数万文档级别"，超过这个量级还是得回向量库。
Trust 字段：每条记忆都带 verified: 或 generated: 标记，区分"人类写的"和"Agent 自己写的"。这是我一直觉得 OpenClaw 的 memory 缺的那一层——现在我的 memory/YYYY-MM-DD.md 里，AI 自己记的和我确认过的是混在一起的。
stdio MCP Server：不是 REST 服务。Claude Code、Cursor、Windsurf 直接通过 MCP 拉记忆，不需要开 HTTP 端口，不需要单独部署守护进程。
OKF 和别家方案的账单差在哪里？
我把主流 Agent Memory 方案摊开对比了一下：
| 方案 | 存储 | 检索延迟 | 外部依赖 | 运行成本 | Git 原生 | 开源协议 |
|---|---|---|---|---|---|---|
| OKF Agent Memory | Markdown | <300µs | 无 | 0 | ✅ | Apache-2.0 |
| mem0 | Postgres + Pinecone | 150-800ms | 向量库 + Postgres | Embedding + DB | ❌ | Apache-2.0 |
| Letta | Postgres + vector | ~200ms | Postgres | DB 托管 | ❌ | 部分开源 |
| Zep / Graphiti | Neo4j 时序图 | ~500ms | Neo4j | 图库托管 | ❌ | 开源 |
| agentmemory (rohitg00) | 本地 SQLite | <10ms | 无 | 0 | 部分 | Apache-2.0 |
| CLAUDE.md 手工塞 | Markdown | 0（全塞进 context） | 无 | Context bloat | ✅ | — |
数字来自各家自己的文档和 benchmark（不同数据集，不能一对一比，只看数量级）。
一个不太起眼但很重要的差异：OpenClaw 每天在用的方案，其实就是"CLAUDE.md 手工塞"那一行。我的 memory/YYYY-MM-DD.md + MEMORY.md 就是最朴素的 Git-native 记忆，靠 heartbeat 定期整理。OKF 相当于给这套朴素方案加了个搜索引擎和一份格式规范（OKF v0.2）。
我实测下来的账本
按我在 OpenClaw 上跑一年多 Agent 的经验，选型账本大致这样：
- Token 账：CLAUDE.md 全塞进 context 的模式，5000 字知识库 = 每次调用多 5000 token。按 Sonnet 3.5 定价 $3/M input，每天调 200 次 = $3/天 = 每年 $1095。OKF 用 BM25 只返回相关片段，能砍到 500 token 左右，年账省到 $110 左右。性价比翻十倍。
- 迁移成本：OKF 是 Markdown + YAML，换任何 Agent 都能读。mem0 换到 Letta 需要重新 embed 一遍。
- 调试成本：OKF 出问题
git log一敲就看到"这条记忆是啥时候被 Agent 改的"。mem0 得写 Python 脚本查库。 - 规模天花板：OKF 官方给的舒适区是"单项目、数万文档"。真到组织级、跨项目、需要跨用户人格的场景，还是得回向量库。
结合 OpenClaw 用它有意义吗？
我认真想了一晚上，答案是：现在还不合适，未来两个月可能会试。
OpenClaw 的 memory 目前长这样：
memory/
├── 2026-09-06.md # 今日日志
├── 2026-09-05.md
└── ...
MEMORY.md # 长期精华
AGENTS.md # 工作规约
这套已经是 Git-native 了，也是 Markdown。差的是索引——每次 Agent 冷启动都要把 MEMORY.md 全文塞进 context，浪费 token。理论上 OKF 的 BM25 + MCP 就能补上这个洞。
但有两个坑要先解决：
第一，OKF 强制 OKF v0.2 格式，我现有的 memory/*.md 得改 frontmatter。900 篇 daily log + 一堆 MEMORY.md 改一遍，工程量不小。
第二，OpenClaw 有自己的 memory_search 工具，OKF 加进来是补充还是替代还没想清楚。
等 OKF 出到 v0.3 或者 OpenClaw 官方给个 memory adapter，我大概率会接上。
常见问题
Q1: OKF 和 CLAUDE.md / AGENTS.md 有本质区别吗？
A: 有。CLAUDE.md 靠"整个塞进 context"喂 Agent，token 成本随知识量线性涨。OKF 靠 BM25 只喂相关片段，token 成本近似恒定。存储层都是 Markdown + Git，检索层完全不一样。
Q2: 为什么不直接用 Pinecone 或 Qdrant？
A: 可以用，但代价是引入一个外部服务、每次调用要付 embedding 费、记忆变成向量看不见。BM25 的召回率对代码类知识（关键词密集、术语精确）其实比向量匹配还稳，向量匹配的优势在"语义模糊查询"。
Q3: 我是个人开发者，值得为记忆搞这么复杂吗？
A: 不值得。个人项目直接 AGENTS.md + memory/YYYY-MM-DD.md 手工写就够了，OpenClaw 就是这套。等你觉得"每次冷启动 Agent 都要读一堆废话"或"想让 Claude Code 记住上个月的架构决策"时，再考虑加索引层。
Q4: OKF 持中文吗？
A: BM25 的中文分词依赖 tokenizer。OKF v0.1 文档没明确提中文支持，我猜要么走 unicode 分字（效果差），要么等 v0.2 加 jieba/ik-analyzer 之类的中文分词器。目前建议英文项目先试。
Q5: 它和 agentmemory (rohitg00) 那个 95.2% 分数的项目哪个强？
A: agentmemory 走的是本地 SQLite + 多种 MCP 工具，54 个 memory tool，重点是"Agent 自动捕获记忆"。OKF 走的是"结构化 Markdown + 极致检索延迟"，重点是"人机共写、可审计"。两个哲学不同，前者偏工程完成度，后者偏工程原教旨。
Q6: 换 IDE / Agent 会不会数据丢失？
A: 这是 OKF 最大的卖点。所有数据是 Markdown 文件，跟你的代码住在一起，换 Claude Code、Cursor、Windsurf、OpenClaw 都能读——只要那个 Agent 支持 MCP。SaaS 方案换家就得重新 embed。
Q7: 企业场景真的能用吗？
A: 有戏。企业合规最难过的一关是"这个 AI 决策是基于什么信息做的"，OKF 直接 git blame 出来，比向量库查审计日志容易得多。但企业级还需要 SSO、RBAC、多租户，OKF v0.1 不带这些，得等 Cloud 版本或者自己套一层。