上一篇 Harness 架构对比给过一个判断：Agent = Model + Harness，而 harness 决定模型能记住什么、能改什么、敢托付什么。那次对比停在架构哲学层面，这次往里走一层，聚焦其中最容易被低估的一块——记忆。同样跑任务的 Agent，有的每次都从零开始，有的把你上次的纠错记一辈子；差距不在模型，在记忆方案。
2026 年这个选择的紧迫感来自两头同时发生的事。一边，AGENTS.md 已成为开放标准，被 30,000 多个项目采用，OpenAI Codex、Cursor、Gemini CLI 与 Claude Code 全部支持，”文件即记忆”成了默认起点；另一边，ChatGPT 在 2025 年 4 月把记忆升级为”引用全部历史会话”（Plus/Pro 先行，TechCrunch，2025-04-10）；到 2025 年 10 月 DevDay，ChatGPT 周活已达约 8 亿（TechCrunch，2025-10-06），记忆成了规模化产品的默认能力。同时 Mem0、Zep、Letta 等记忆框架在开发者侧疯狂内卷，MCP 记忆服务器也一发不可收。三条路线都在成熟，但没有一条全赢——记什么、谁来记、放哪里，这三个问题没有单一答案，只有和你场景匹配的答案。
本文把三条路线放进同一个坐标系横评：规则文件（CLAUDE.md / AGENTS.md 类）、MCP 记忆服务器、外部向量库/RAG，最后用我自己在维护的一个博客发布流水线做真实选型复盘。所有关键数字都标注来源与日期，评测争议的部分单独拆开讲清楚。
Key Takeaways
- Agent 记忆有三条正交轴：写入路径（人工 vs 自动）、读取路径（全量注入 vs 检索 vs 查询）、规模上限。三条路线的差异都能还原到这三根轴上，先分清轴再选型。
- 规则文件（CLAUDE.md/AGENTS.md）赢在审计与确定性：git 可查、版本可回滚、成本近乎为零，但靠人肉维护、有 32KB 量级的实用上限（AGENTS.md 已获 30,000+ 项目采用）。
- MCP 记忆服务器赢在自动沉淀与跨工具共享：官方知识图谱服务器 9 个工具开箱即用，Zep/Mem0 支持时序推理，但写入质量依赖 LLM 提炼，存在记忆污染风险。
- 外部向量库赢在规模，输在新鲜度债：陈旧嵌入已被列为检索系统的一等失败模式（Agent-as-Judge，2025），保持索引新鲜的刷新成本是每次查询的 1.54–3.47 倍（arXiv:2505.01931，2025）。
- LoCoMo 榜单不可尽信：每家厂商都自称第一且数字互相矛盾，朴素向量 RAG 常常打平花哨框架——用你自己的工作负载自建评测，而不是看榜单选型。
本文目录：一、记忆的三条正交轴 · 二、快速对比 · 三、规则文件 · 四、MCP 记忆服务器 · 五、外部向量库 · 六、评测乱象 · 七、三问决策法 · 八、真实项目复盘 · 九、结论 · FAQ
一、先把问题定义清楚：记忆的三条正交轴
在比较方案之前，先把”记忆”拆开。讨论 Agent 记忆时，多数混乱来自把三件不同的事混在一句话里说，它们各自独立、互不决定：
轴一：写入路径——记忆是谁写的？ 人工写的（你在 markdown 里记下团队约定）、Agent 运行时自动写的（对话结束自动沉淀事实）、还是管线批量写的（把历史语料跑一遍嵌入）。写入路径决定了记忆的可信度从哪里来：人工写入的每一条都有人背书，自动写入的每一条都依赖那次 LLM 提炼的质量。
轴二：读取路径——记忆怎么被用？ 全量注入（整个记忆文件每次都塞进上下文）、按需检索（先查再取，只取相关片段）、工具查询（把记忆当外部数据源，通过 API 拿）。读取路径决定成本结构：全量注入按 token 付费且随规模线性涨，检索方案多一层”查不查得准”的风险。
轴三：规模上限——记忆能长到多大？ 全量注入受上下文窗口硬约束，社区实践普遍建议单文件控制在 32KB、300 行以内，40KB 以上的臃肿文件会稀释指令遵循（HumanLayer 的七组实验与社区共识）；检索方案的规模上限取决于存储与索引，可以到百万级片段。
这三根轴画出来，三条路线的位置就清楚了：**规则文件是”人工写 + 全量读 + 小规模”；MCP 记忆服务器是”自动写 + 查询读 + 中等规模”；外部向量库是”管线写 + 检索读 + 大规模”**。没有哪个方案同时占优三根轴，所以选型本质上是判断：你的场景在哪根轴上的要求最苛刻。
二、快速对比
先给一张能停在决策阶段的表，后文逐项展开。
| 维度 | 规则文件（CLAUDE.md/AGENTS.md） | MCP 记忆服务器 | 外部向量库 / RAG |
|---|---|---|---|
| 写入路径 | 人工维护，git 版本化 | Agent 运行时自动沉淀 | 管线批量嵌入 + 增量更新 |
| 读取路径 | 全量注入上下文 | 工具调用按需查询 | 语义检索 top-k |
| 规模上限 | ~32KB / 300 行（社区共识） | 中等，取决于图规模 | 百万级 chunk |
| 审计与回滚 | 最强：diff、PR、回滚一把梭 | 弱：写入分散在运行日志里 | 中：数据可查但嵌入难审 |
| 新鲜度 | 人工更新，容易过期但看得见 | 写入时更新，需防污染 | 最大坑：陈旧嵌入是静默失败 |
| 起步成本 | 几乎为零，写个文件就行 | 一条 npx 命令 + MCP 配置 | 需要嵌入服务 + 向量库 + 运维 |
| 典型场景 | 团队约定、项目惯例、编码规范 | 个人助理、跨会话个性化 | 海量文档问答、多源知识库 |
一句话版本：变化慢、要审计的知识交给规则文件；Agent 自己产出的经验交给 MCP 记忆服务器；规模大到注入不动的大语料才上向量库。
三、方案一：规则文件——最土，也最难被替代
规则文件路线的代表是 CLAUDE.md 和 AGENTS.md：把项目约定写成 markdown，Agent 每次启动时读入。它的全部优势与全部局限，都来自”人工写、全量读”这个组合。
它赢在审计与确定性，这一点目前没有替代品。 规则文件活在 git 里，每一处修改都有 diff、有 commit message、有 reviewer——记忆出错时你能精确回答”哪次提交引入的”。Anthropic 官方文档定义了清晰的记忆层级（企业策略 → 用户级 ~/.claude/CLAUDE.md → 项目级 CLAUDE.md/AGENTS.md → 个人级 CLAUDE.local.md），每层职责分明。而且 AGENTS.md 的标准化让一份文件服务所有工具：OpenAI Codex、Cursor、Gemini CLI 都认它，Claude Code 在没有 CLAUDE.md 时也会自动回退读 AGENTS.md——投资一份文件，回报覆盖整个工具链。
它的上限是规模与人肉维护。 全量注入意味着文件越长，每次会话的基础 token 成本越高，而且社区实践反复验证：超过 32KB 的臃肿文件会稀释关键指令的遵循率。更现实的问题是写入全靠人：项目变了要记得改文件，改完只对新会话生效。规则文件记不住”这周我们临时决定先跳过类型检查”这种短生命周期信息——它天生适合慢变化的知识，不适合快变化的状态。
适用判据：知识以月为单位变化、需要团队审计、单人或小团队维护。这三条里占两条以上，规则文件就是你的主战场。
四、方案二：MCP 记忆服务器——把记忆协议化
MCP 记忆服务器路线的核心主张是：记忆不该是某个特定 Agent 的私有实现，而应该是任何 Agent 都能接的标准服务。Agent 干完活，把值得记的事实自动沉淀到记忆服务；下次开工，通过工具调用按需取回。
最轻的起点是官方知识图谱服务器。 @modelcontextprotocol/server-memory 用”实体—关系—观察”三元组建模记忆（比如”项目A —使用— KSP2”是一个关系，”KSP2 在 2026 年已 GA”是一条观察），提供 9 个工具（建实体、加观察、搜节点、读全图等），数据经 MEMORY_FILE_PATH 落到本地 JSON 文件。它刻意做得很薄：没有嵌入、没有排序算法，就是一个可持久化的结构化小本本——但这恰恰意味着零外部依赖、行为完全可预期，一条 npx 命令就能跑起来。
社区生态按需求分层往上加。 memory-bank-mcp 把记忆组织成结构化 markdown（项目简报、活动上下文、决策日志），本质是”会自我更新的规则文件”；Zep 的 Graphiti 用双时态（bi-temporal）知识图谱记录”事实什么时候成立、什么时候失效”，后端接 Neo4j/FalkorDB，擅长回答”这个结论现在还成立吗”；Mem0 提供托管 MCP 服务与本地化的 OpenMemory，强调跨会话的个性化。选型的分界线很清楚：要确定性选图谱服务器，要时序推理选 Graphiti，要开箱即用的托管服务选 Mem0。
这条路还有一个常被忽略的变体：工具即记忆。不复制数据，直接让 Agent 通过 MCP 查内部工单系统、文档平台——记忆的”真相源”留在业务系统里，Agent 每次现查，新鲜度问题从根上消解（详见前作 MCP 实战：为团队基础设施写一个生产级 MCP Server）。
它的主要风险同样明确：写入是自动的，错误也是自动的。 Agent 提炼出一条错误事实写进图谱，后续所有会话都会引用它，而且没有 diff 审查这一关。把”记住”当成写操作来设计——定期审查记忆内容、提供删除工具、对重要事实要求人工确认（做法同把 code review 流程固化为技能的实践：审查要有清单与触发时机）——是这个方案能不能长期用的分水岭。
五、方案三：外部向量库——规模的天花板，新鲜度的地板
第三条路线把记忆当成检索问题：语料切块、嵌入、入向量库，Agent 每次按语义查 top-k。它的规模上限最高——百万级 chunk 也能亚秒级返回，这是前两条路线做不到的。
但 2025 年以来最集中的批评，恰恰指向它的软肋：新鲜度。 检索系统不会告诉你”这条记忆过期了”，它只会安静地把一条两年前的事实返回给你。Agent-as-Judge 基准（arXiv，2025-09）把”过时上下文、陈旧向量库嵌入”明确列为一等失败模式；RAG 能耗研究（arXiv:2505.01931，2025）量化了维持新鲜的代价：长期运行的会话式 RAG，索引刷新成本是单次查询的 1.54–3.47 倍，嵌入与语料的漂移是主要经常性开销。MemoryOS（arXiv:2505.24433，2025）干脆用操作系统式的 FIFO 衰减来对抗过期；Mem0 的论文（arXiv:2504.19413，2025-04）用两阶段管线在写入时执行 ADD/UPDATE/DELETE，显式作废陈旧记忆。各家都在补这一课，也说明：选向量库 = 签一份新鲜度维护合同，合同没人免费履行。
第二个反直觉的发现：检索未必比”笨办法”便宜或更准。 滑铁卢大学团队 2025 年 6 月的系统综述（659 篇论文）结论是 RAG 与长上下文不是替代关系，混合方案最优，而且随着模型抗噪能力提升，RAG 的成本优势正在缩小。Prompt caching 把”全量注入很贵”的前提又削了一刀：Anthropic 的缓存读取按输入价的 10% 计费（写入 1.25 倍，官方定价文档，检索于 2026-11-02），Gemini 2.5 Flash 缓存读取约 0.25 倍外加存储费（Gemini API 定价，检索于 2026-11-02）。量级不大的知识库，”全量塞进去 + 缓存吃折扣”可能比维护一套检索基础设施更划算。
第三，检索质量本身有方差。 Mem0 论文给出的数据是：prompt 长度每上升 1%，Llama-3.1-8B 的错误率上升 3.85%——检索回来的相关片段太少（模型缺上下文）与太多（噪声稀释注意力）都是坑。规模才是向量库的入场券：语料小，别上；语料大到全量注入物理不可行，或多个数据源必须统一检索，才轮到它出场。
六、LoCoMo 榜单别太当真：一场各说各话的评测混战
如果你去搜”哪个记忆框架最好”，会得到一组互相矛盾的数字，这是本文写作过程中最值得单独讲的一个发现。
拆解这场混战：Mem0 论文（2025-04）宣称在 LoCoMo 上准确率相对提升 26%、p95 延迟 1.44 秒（全上下文方案为 17.12 秒）；Zep 随即发文《Lies, Damn Lies, & Statistics》反驳，指其图记忆实现与自家方案差距达 34%、时序推理被误判；Letta 团队 2025 年 8 月的基准测试文给出了最扎心的对照——**一个把对话历史存成文件、让 Agent 自己翻的”文件系统基线”，在 LoCoMo 上拿到 74.0%，高于 Mem0 顶级图记忆变体自报的 68.5%**，结论直接写进标题：”Is a Filesystem All You Need?”。而后来者 Hindsight 自报 95.2%，又把所有人踩在脚下。LoCoMo 本身的质量问题也早被多方记录：标注依赖 LLM 打分、部分问题根本没有答案、大量问题并不真正需要长期记忆——榜单测的与其说是”记忆”，不如说是”检索”。
这给选型者的启示不是”都别用”，而是评测要自己做。榜单分数换到你自己的工作负载上几乎没有迁移性；正确姿势是拿你真实的记忆操作（去重、时序、多会话一致性）构造小评测集，把候选方案与”便宜 RAG 基线”和”全上下文基线”一起跑，同时记录延迟与成本。这与用变异测试给 AI 生成的测试打分是同一个道理：AI 系统的”看起来很好”必须换成可复现的数字才算数。
七、三问决策法
把前文压缩成三个问题，按顺序回答：
Q1：知识多久变一次？ 以月为单位变（项目规范、架构约定）→ 规则文件。每次会话都在变（用户偏好、任务状态）→ 运行时方案（MCP 记忆服务器或向量库）。注意 AGENTS.md 标准化后，规则文件还是跨工具的公共记忆，优先级应高于直觉。
Q2：谁来记？ 人来记（团队要审计、要背书）→ 规则文件，git 就是你的记忆审计日志。Agent 来记（个人助理、经验沉淀）→ MCP 记忆服务器，但要配审查机制。管线批量导入历史语料 → 向量库。
Q3：语料多大？ 单文件塞得下（几十 KB 以内）→ 别犹豫，全量注入最简单可靠。塞不下但单库可控 → MCP 记忆服务器或 RAG 二选一，后者要预算新鲜度维护。多源异构、百万级 → 向量库，并考虑与长上下文混合（滑铁卢综述的结论：混合最优）。
对应的决策规则收尾：选规则文件，如果你的知识以月为单位变化且需要团队审计；选 MCP 记忆服务器，如果记忆由 Agent 自动产生且要跨工具共享；选向量库，如果语料大到注入不可行且你有能力维护新鲜度；而多数成熟项目，最终是”规则文件 + 一种运行时记忆”的混合体。
八、真实项目复盘：一个发布流水线的记忆选型
拿我自己在维护的一个博客自动发布流水线（auto-blog）做复盘。它的任务是：从选题池取条目 → 写作 → 部署到 Hexo 博客 → 同步到多平台。跑了几个月、十几篇文章之后回看，它的记忆选型恰好把三条路线都用在了各自的正确位置上。
选题状态用规则文件。 选题池是仓库根目录的一个 markdown 文件，每条选题带状态机（候选 → 已确认 → 写作中 → 已部署 → 已同步）。为什么不用数据库？因为这里的需求是审计与人工把关：哪次运行改了状态、为什么改，git log 一目了然；人工 check 点就是让我本人对记忆的每次写入负责。这正是规则文件的甜蜜区——变化以天为单位、写入要背书、语料就是这一个文件。
我的长期偏好用”索引 + 单事实文件”。 用户的 Claude Code 记忆目录里，一条记忆一个文件（带 frontmatter 的 markdown），外加一个 MEMORY.md 当索引。这是规则文件路线在个人维度的规模化变体：单文件保住”全量注入”的可控性，文件粒度保住”按需读取”的可能性——某条记忆过时了，删一个文件就行，不用在几千行的大文件里做手术。
外部业务数据用”工具即记忆”。 工单、文档平台的数据从不复制进任何记忆文件，而是通过 MCP 工具现查。这是第四节那个变体的实践版：真相源留在业务系统，Agent 永远拿最新数据，新鲜度债为零。代价是每次查询有一次工具调用的延迟与鉴权成本——但相比”复制一份然后眼睁睁看它过期”，这笔账划算得多。
这个流水线至今没有用上向量库，原因就是 Q3：语料规模撑不起基础设施，选题池加记忆文件全部注入也就几十 KB，prompt caching 之下成本可忽略。三种方案各有正确位置，混用不是妥协，而是把三根轴分别交给最合适的方案。如果哪天要把几百篇历史文章喂给 Agent 做内容分析，那才是向量库登场的时刻——而且要同时预算它的索引刷新成本。
九、结论
横评到此收束成一句话：记忆选型不是选”最好的方案”，是给三根轴（写入、读取、规模）各找一个匹配的答案。 规则文件用审计与确定性换来人肉维护的代价；MCP 记忆服务器用自动沉淀换来对写入质量的依赖；向量库用规模换新鲜度债——三条路线的短板恰好是互补的，这也是为什么成熟项目几乎都走向混合。
给正在起步的读者的行动清单：先把项目约定写成 CLAUDE.md/AGENTS.md（成本为零、立刻受益）；需要跨会话个性化时从官方知识图谱服务器起步（一条 npx 命令）；语料过 32KB 或需要检索多源时再评估向量库，并同步预算新鲜度维护；任何方案上马前，用你自己的工作负载跑一组小评测，别信榜单。
FAQ
CLAUDE.md 和 AGENTS.md 到底用哪个？
用 AGENTS.md，或两者并存。AGENTS.md 已是开放标准（30,000+ 项目采用），Codex、Cursor、Gemini CLI 原生支持，Claude Code 在无 CLAUDE.md 时自动回退读它。只在需要 Claude Code 特有语法（如 @import 引用）时保留一份薄的 CLAUDE.md。
MCP 记忆服务器会把错误事实一直传播下去吗？
会，这是该路线的核心风险：写入是自动的，错误也是自动的。缓解手段是把记忆当写操作管理——定期审查记忆内容、保留删除工具、重要事实要求人工确认。官方知识图谱服务器因为是本地 JSON 文件，可以用 git 管起来，等于把两条路线的优点拼在一起。
向量库方案的新鲜度问题有标准解法吗？
没有免维护的解法，只有三种成本结构：写入时作废（Mem0 的 ADD/UPDATE/DELETE 管线，依赖 LLM 提炼质量）、周期性重建索引（刷新成本约 1.54–3.47 倍于单次查询，见 arXiv:2505.01931）、或者像”工具即记忆”那样不存副本、每次现查。数据越重要，越应该考虑最后一种。
我该用 LoCoMo 分数来选记忆框架吗？
不该。LoCoMo 上各家口径互相矛盾（Hindsight 自报 95.2%，Mem0 图变体自报 68.5%，而一个文件系统基线就拿了 74.0%），标注质量与 prompt 敏感性问题有据可查。用你自己的记忆操作构造小评测集，把候选方案与”朴素 RAG”和”全上下文”两个便宜基线一起测，同时记录延迟与成本——结论通常比榜单可靠得多。