在 LLM 应用逐步从单轮对话走向长链路任务的今天,任何严肃的智能体项目都绕不开一个老问题:如何让 Agent 跨会话、跨进程、跨客户端地保留上下文。聊天窗口内的对话历史只是临时缓存,真正决定一个 Agent 能不能「接着上一次把事情干完」的,是它背后那一层持久化记忆。这一层在 Anthropic 2024 年 11 月开源的 Model Context Protocol(以下简称 MCP)出现之
在 LLM 应用逐步从单轮对话走向长链路任务的今天,任何严肃的智能体项目都绕不开一个老问题:如何让 Agent 跨会话、跨进程、跨客户端地保留上下文。聊天窗口内的对话历史只是临时缓存,真正决定一个 Agent 能不能「接着上一次把事情干完」的,是它背后那一层持久化记忆。这一层在 Anthropic 2024 年 11 月开源的 Model Context Protocol(以下简称 MCP)出现之前,几乎每家厂商都在自己造轮子:有的用 Postgres 加 pgvector,有的用 Redis 加自定义摘要,有的干脆把所有上下文塞进系统提示词。
MCP 协议的官方定义
Anthropic 在 2024-11-25 的官方博客《Introducing the Model Context Protocol》中明确写道:Today we are open-sourcing the Model Context Protocol (MCP), a new standard for connecting AI assistants to the systems where data lives, including content repositories, business tools, and development environments. Its aim is to help frontier models produce better, more relevant responses. 这段话被业内反复引用,是因为它点出了 MCP 的真正定位——它不是另一个模型框架,而是一份「AI 助手如何接入数据源」的开放标准。在 MCP 之前,每一个 AI 工具要对接一个新的数据源,都得写一套定制集成;在 MCP 之后,数据源以 MCP 服务器的形式对外暴露,AI 客户端以 MCP 客户端的身份调用,中间通过一份统一的协议握手。这件事最直接的工程收益是:Memory(记忆存储)从「每个 Agent 自己实现」变成了「按 MCP 协议暴露的一类标准能力」。
Memory 作为 MCP 原语的映射
MCP 协议把服务端可对外提供的能力抽象成三类原语:Tools、Resources、Prompts。Tools 对应模型可以主动调用的函数,Resources 对应可被读取的结构化数据,Prompts 对应可复用的提示词模板。一个 MCP Memory 服务器要做的事情,本质上就是把这三类原语映射到持久存储上:Tools 负责「写入记忆」和「按条件召回」,Resources 负责「按 ID 取出某条记忆的完整快照」,Prompts 负责「把检索到的记忆格式化成模型友好的上下文片段」。Anthropic 同时开源了官方 SDK、Claude Desktop 桌面端的本地 MCP 服务器支持,以及一个收录了 Google Drive、Slack、GitHub、Git、Postgres、Puppeteer 等常见系统的预置服务器仓库。这条「协议加 SDK 加官方参考实现加桌面端内置」四件套,是后续一年内整个 MCP 生态得以快速铺开的基础设施。
为什么 Memory 跑出了工程新样本
在 MCP 生态里,Memory 是最先跑出工程新样本的一类能力。原因不复杂:对话历史、用户偏好、项目状态、长期任务进度这些「需要被记住」的内容,几乎是每一个严肃 Agent 都会遇到的通用需求;而传统方案(往上下文里塞摘要、用向量数据库做相似度检索)又都有明显的工程痛点。塞摘要会撞上下文窗口,纯向量检索对精确关键词召回不友好。Glama 目录在 2026-09 收录的 MCP 服务器总数已经超过 8.6 万个,其中专门面向 Knowledge & Memory 分类的就有 5420 个以上。这一密度本身就说明,「给 Agent 装一层持久记忆」已经不再是少数人的实验,而是普遍需求。
FTS5 路线:精确召回的不可替代性
在这些 MCP Memory 服务器里,有一类项目尤其值得关注——它们选择把 FTS5 作为 Agent 记忆检索的核心数据结构,而不是直接套用业内更常见的向量数据库路线。FTS5 是 SQLite 自带的全文检索引擎,支持词干提取、停用词、BM25 排序、多种辅助函数,对于「在某条历史对话里找一段原话」「在项目的 issue 列表里搜一个报错关键词」「在用户的偏好设置里命中某个配置项」这类强精确性的检索任务,FTS5 比纯向量检索更稳,而且零额外依赖、零运维成本。Agent 需要的不是每一条记忆都「语义相似」,而是能在正确的时间点找到正确的那一条——这正是全文检索擅长、向量的盲区。
模型本身拉低了 MCP 服务器的开发门槛
Anthropic 在 2024-11-25 那篇博客里还提到一个关键事实:Claude 3.5 Sonnet is adept at quickly building MCP server implementations, making it easy for organizations and individuals to rapidly connect their most important datasets with a range of AI-powered tools. 也就是说,模型本身对 MCP 协议的熟练度,意味着 MCP 服务器的开发门槛被显著拉低。一个熟悉 Python 或 TypeScript 的工程师,通常只需要几百行代码就能写出一个最小可用的 MCP Memory 服务器:把记忆条目写入 SQLite,用 FTS5 建一张虚拟表,再通过 MCP SDK 把 store_memory、search_memory、get_memory 三个 Tools 暴露出去,加上 read_memory 一个 Resource,即可接入 Claude Desktop、Cursor、Cline、Continue 等所有兼容 MCP 协议的客户端。这种「开发成本接近于零,集成收益却是协议级」的特性,是 MCP Memory 生态能快速繁殖的真正底层原因。
协议层工程新样本的三个共性
协议层的工程新样本,集中体现在三件事上。第一是「协议加存储引擎」的可插拔。一个 MCP Memory 服务器可以后端挂 SQLite 的 FTS5、Postgres 的 tsvector、甚至 DuckDB 的全文扩展,前端对客户端的 Tools / Resources 接口完全一致,这意味着替换底层引擎不会影响任何上游 Agent 代码。第二是「语义召回加关键词召回」的混合路由。Glama 在 2026-09 收录的 Memwyre 自描述里就明确写:Powered by hybrid vector search, BM25, and cross-encoder reranking with a published 73.1% LoCoMo benchmark accuracy. 这条声明同时引用了三种检索技术:向量搜索负责语义近似、BM25(本质就是 FTS5 的默认排序算法)负责关键词精确、重排模型负责最终排序,三者在协议层之下按策略组合,对外只暴露统一的 search_memory 接口。第三是「本地优先加跨客户端同步」。同样是 Glama 收录的 docmancer,自描述里写:Local-first memory for coding agents. Discovers the memory, instructions, and rules Claude Code, Codex, and Cursor already wrote on your machine, combines them into one canonical Markdown tree, and serves grounded, cited recall through tools like ask_memory and canonical_memory. 它做的是把多个客户端各自写在本地文件系统上的记忆文件(Markdown 树)合并成一个权威版本,通过 MCP 对外提供有引用出处的检索。这一类设计回答的不是「Agent 怎么记东西」这种小问题,而是「不同客户端写的同一份记忆怎么不打架」这种工程级难题。
回到 MCP 协议本身
把视线从工程样本拉回到协议本身。Anthropic 在 2024-11 那篇博客里给出的 MCP 架构其实只有两个端:MCP servers 负责暴露数据,MCP clients 负责调用。客户端既可以是 Claude Desktop 这种桌面应用,也可以是 Cursor、Zed、Replit、Codeium、Sourcegraph 这类开发工具,Anthropic 在博客里点名提到了他们正在使用 MCP。As the ecosystem matures, AI systems will maintain context as they move between different tools and datasets, replacing today's fragmented integrations with a more sustainable architecture. 「可持续的架构」这四个字,正是 MCP 想要替代「每接一个数据源写一个集成」那种不可持续局面的核心承诺。对企业级 Agent 项目来说,MCP 的真正价值不在某一个服务器有多强大,而在于把「记忆、知识、工具、数据」这几类异构资源全部收到同一份协议之下,让上层 Agent 实现可以稳定复用,让底层基础设施可以独立演进。
MCP Memory 场景的几个确定性判断
回过头看 MCP Memory 这个细分场景,有几个工程层面的判断是相对确定的。第一,FTS5(或者 BM25 同源算法)在精确召回上的不可替代性,意味着任何严肃的 MCP Memory 项目都不能只押向量检索,关键词引擎是底座而非可选项。第二,本地优先(local-first)是协议层工程新样本的共同选择——docmancer 扫本地 Markdown、Memwyre 提供 MCP-native 持久层,背后都是同一条判断:Agent 的记忆不应该被迫上传到某个云端才能用,否则就违背了 MCP 设计的初衷(数据留在它原本在的地方)。第三,跨客户端一致(canonical memory)是 2025-2026 年才浮现出来的新需求,它把 MCP Memory 的工程复杂度从「单客户端单后端」推到了「多客户端多后端的统一抽象」,这也是当下最值得持续关注的方向。
新做一个 MCP Memory 服务器的稳妥起点
最后回到开发者视角。如果今天要新做一个 MCP Memory 服务器,基于上面这些协议层新样本的经验,一个相对稳妥的起点是:用 SQLite 加 FTS5 作为底层存储,前端挂 MCP 官方 SDK,把 Tools 拆成 store_memory / search_memory / delete_memory,把 Resources 拆成按 hash 取记忆全文,把 Prompts 拆成「基于检索结果构造上下文片段」。语义召回可以在 search_memory 内部作为一条旁路,与 BM25 结果做混合排序,而不必一开始就去接向量数据库。本地优先默认开启,跨客户端同步留作可选项;当同一个 Agent 同时被 Claude Desktop、Cursor、CLI 三种客户端调用时,再考虑引入 canonical memory 这一层抽象。这条路径对个人开发者足够轻、对企业级集成又留好了扩展口子,正是协议层「标准先行、实现多样」这一精神的最佳实践。
