给 Agent 装长期记忆，零 API key 的方案我实测了一遍

一个所有用过 AI 编程助手的人都撞过的墙

Claude Code 帮你调通了一个绕了半天的构建问题，你关掉终端。第二天重开，问它"上次那个坑你还记得吗"——它一脸茫然。会话一关，学到的东西全没了。这是所有 coding agent 的通病，不是某家的 bug。

主流解法是给 agent 接一个"记忆库"：向量嵌入、知识图谱、云同步，各显神通。上周我们盘点过四个代表性项目（cognee、ai-memory、Memori、hindsight），它们要么要 API key，要么要数据库，要么干脆把记忆交给第三方服务。

这周 fast 榜上又冒出一个 1457★、13 天龄的项目 agent-memory（tigerless-labs/agent-memory，MIT），把前面的路子全反过来：零 API key、零数据库服务、记忆就是一堆 Markdown 文件。我把它装到本机完整跑了一遍。

项目速览

它把记忆做成了"文件系统"，而不是"数据库"

agent-memory 的核心判断是：给 agent 的记忆，要么做成检索引擎（向量库、知识图谱），找到的东西是一个不透明的大块，agent 没法核查，也没法迁移；要么做成文件系统，agent 能 ls、能 grep，但不会排序，目录一大就抓瞎。

它的答案是两个都做，但把主次摆得很清楚——文件是真相，索引只是缓存。

存储结构是这样：MEMORY.md 是常驻索引，每条记忆一行；decision/、fact/ 等目录按 schema 分类放记忆文件；archive/ 存蒸馏证据和会话全量备份；.index/ 是 SQLite 索引，README 原话是"你可以随时删掉它"——删了跑一次 mem rebuild 就重建，一条不丢（这是被测试强制保证的承诺，不是文档里吹的）。

每条记忆就是一个 Markdown 文件，frontmatter 带名字、摘要、类型、状态、时间戳、链接、权重。文件边界就是失效原子：覆盖、加权、召回都按整个文件操作，要么有效要么无效，没有中间态。

召回按"层级"收费，不把上下文塞爆

召回不是把记忆全文贴进你的上下文，而是先给一个 L0 列表——一行摘要、文件路径、锚点、分数：

mem recall "why files instead of a database"
mem read <name> --level outline   # 只看标题；或 abstract、full
mem context "..."                 # 两者合一，前几条展开全文

一行摘要 → 摘要 → 全文 → 原始素材，每往下一级贵一个数量级，每一级都可以停下来。长文件还有两个免费档位：命中的锚点和读取时现算的 outline。

除了这条 BM25 召回（FTS5 索引，可选向量插件按 RRF 融合），它还有两条保底通道：会话开始往上下文里注入 MEMORY.md；以及最朴素的"失败就 ls 目录"。

写入也不靠 agent 自觉：蒸馏在会话边界触发（SessionStart 注入、Stop/SessionEnd 蒸馏、PreCompact 驱逐），先把全量 trace 复制进 archive——"蒸馏器漏了"不等于"系统丢了"。

实测：安装、写入、召回、重建、睡觉

下面是我在 Ubuntu 服务器（3.4G 内存、无 GPU）上按 README 步骤实测的结果，数据采集于 2026-09-16。

成本：0 元。全程无 API key、无 GPU、无外部服务，依赖只有 Python 3.12 + uv。

耗时：安装约 2 分钟；日常读写都是亚秒级（0.2s 上下）。

失败率：按 README 一条命令装完，mem 命令入口没进 .venv/bin（workspace 脚本入口未生成，实测踩到的坑），补 uv pip install -e packages/cli -e packages/core -e packages/executor -e packages/adapters 后全链路一次通过。不确定：此坑可能与 uv 版本有关，官方未提及。

作者还贴了一组对照数据（LongMemEval-S，120 个 episode，Haiku 4.5 作 host）：agent-memory 52.9%，对照组 MemCore 35.8%，无记忆 5.8%。以及 9 组 host 配对（Claude Code / Codex CLI / Hermes 两两组合）全部通过。这些是作者自测，未独立复现。

睡眠期整合：删除只能"提案"，不能动手

它有个叫 mem sleep 的机制：在 agent 不工作时跑一遍整合，有权威分级——可新增、可更新，删除永远只生成提案，等你 mem proposals 查看、mem decide 批准。每次睡觉写一份 dream report，记录动了什么、提了什么案、证据在哪。

这个设计值得单独拎出来说：大多数记忆系统把"忘记"和"记住"绑在同一条写入路径上，agent 觉得不重要就悄悄删了。agent-memory 把"删除"变成人的保留动作——记忆可以过期，但不能被静默消灭。对把 agent 当长期员工用的人来说，这是信任的地基。

和上一轮的四家放在一起，怎么选

上周盘点的四家里：cognee 解决"把任意格式数据变成可查图谱"，ai-memory 解决"换个 CLI 就丢上下文"，Memori 解决"别把上下文塞爆"，hindsight 解决"记忆要有多准"（LongMemEval SOTA + 银行隔离）。它们共同的隐含前提是：记忆需要一个专门的检索层，而且要花钱（API key）或花部署力气。

agent-memory 回答的是"记忆能不能不依赖任何付费层"。选型建议：语料很大、召回精度优先，cognee、hindsight 的检索层仍然值得；只想要 agent 记得住干过的事、踩过的坑，并且希望这些记录自己能随时打开检查，它的方案更省心。

另一个容易被忽略的点：因为记忆是纯文件，导出、迁移、跨 host 共享都变成 cp 和 git push 的事。Claude Code 写的记忆，Codex 能读——这是它官方测过并贴了数据的卖点。

两个实测时值得知道的小事

第一，mem recall 的 JSON 输出里，每条命中带 relevance、recency、score 三分数和完整路径——"凭什么召回这条"是透明的，这少见。

第二，mem sleep 跑完在 dream-reports/ 留报告，我实测生成的报告明确记录了 inspected: 1、actions: []（动了什么）、proposals: []（提了什么案）——整合过程全程留痕。

信号强度

开发者：零成本接入的长期记忆是一个真实的空缺。如果你受够了"换会话就失忆"，又不想为记忆服务付费或担心数据出境，这个项目给了可审计、可迁移的第三条路；它和 Claude Code、Codex 都能接（MCP 也有）。

个人开发者：可以把记忆目录放进 git 仓库，等于给 agent 建了带版本历史的工作笔记。注意边界：这是新项目（0.1.0），schema 可能变，召回质量在真实长上下文下的表现还有待更多人验证。

研究者：它把"记忆该不该由 LLM 来写"摆上台面——蒸馏完全在会话边界发生、不依赖模型判断，这个取舍和"让模型自己决定记什么"形成了可对照的实验组。

技术管理者：评估"给 agent 配记忆"时，它值得进对比清单——不是因为它召回最准，而是因为它把"记忆存了啥、谁删的、怎么恢复"变成看得见摸得着的文件，这个工程价值比召回率更值钱。

Agent 的记忆问题，本质是信任问题：你愿不愿意把"它知道什么"交给一个黑箱。agent-memory 的答案很朴素——把记忆变成你能打开的文件。代价也诚实：纯文件方案在超大语料下的召回会输给重型检索层，分级读取能不能被真正用起来，取决于宿主 agent 的配合。但"打开文件就能核查"的踏实感，是再多召回率也换不来的。

SIGNAL FILE · 情报档案

agent-memory 的独特性不在"召回准"，而在架构取舍：把记忆做成可 ls、可 grep、可 git 的纯文件，把索引定位成"随时可删的缓存"，把写入责任从 agent 的自觉转移给会话边界的系统钩子。它用零成本换来了可审计性——这正是把记忆交给闭源工具时最放不下的东西。

本文基于 AI 情报库收录的条目展开深析；事实性信息以原始报道为准，分析与展望为编辑观点。

原始报道：https://github.com/tigerless-labs/agent-memory（GitHub）

查看原始报道 ↗返回首页