MCP × 记忆：模型上下文协议中缺失的层

1. 模型上下文协议的革命

当 Anthropic 在2024年末发布模型上下文协议（MCP）时，它改变了围绕 AI 智能体架构的讨论。这是第一次有了标准化的方式让 AI 模型与外部工具、数据源和服务交互。MCP 提供了一个通用协议——可以将其视为 AI 智能体的 HTTP——允许任何语言模型通过一致的接口调用任何工具。每个 AI 应用都必须为每个服务构建自己桥梁的定制工具集成时代终于要结束了。

采用速度令人瞩目。几个月内，主要平台——GitHub、Slack、Notion、Jira 等几十个——发布了官方 MCP 服务器。生态系统因社区贡献的服务器而爆发，涵盖从数据库访问到网页抓取到代码执行的一切。到2026年初，MCP 已成为 AI 智能体工具访问的事实标准，获得了 OpenAI、Google 和几乎所有主要 AI 平台的支持。

但随着 MCP 采用率的增长，一个关键差距变得越来越明显。MCP 擅长给智能体提供工具访问——做事的能力。它不提供的是记忆事物的能力。每个 MCP 交互在设计上都是无状态的：智能体调用工具，获得结果，协议不提供任何机制让智能体跨会话存储、检索或推理信息。这不是 MCP 的 bug；这是一个经过深思熟虑的设计选择，使协议保持简单和专注。但它为需要在数天、数周和数月内运行的智能体创造了一个根本性问题。

2. MCP 做得好的地方：工具访问的标准化

在讨论缺失了什么之前，让我们先欣赏 MCP 已经取得的成就。该协议在 AI 模型和外部服务之间定义了一个清晰的抽象层。MCP 服务器公开一组工具——每个工具都有名称、描述和参数及返回值的 JSON 模式。MCP 客户端（通常嵌入在 AI 智能体中）可以发现可用工具、理解其接口，并通过标准化的 JSON-RPC 协议调用它们。这在简洁性上很优雅。

这种标准化的力量怎么强调都不为过。在 MCP 之前，构建一个能与 GitHub 交互、运行 SQL 查询和发送 Slack 消息的 AI 智能体需要三个单独的集成，每个都有自己的认证方案、错误处理和数据格式。有了 MCP，智能体只需连接三个 MCP 服务器，并通过相同的协议与所有服务器交互。这种可组合性是 MCP 具有变革性的原因——您可以混合和匹配不同提供商的工具，而无需更改智能体代码。

MCP 还很好地处理了发现问题。当智能体连接到 MCP 服务器时，它会收到可用工具的清单，包含人类可读的描述和机器可读的模式。然后智能体可以根据用户请求决定使用哪些工具，而无需对特定工具名称或参数进行硬编码。这种动态发现对于构建能够适应不同环境和工具配置的灵活智能体至关重要。

3. 状态性问题：没有记忆的工具

这是根本问题：MCP 给了智能体双手，但没有给大脑。拥有 MCP 工具的智能体可以执行操作——创建 GitHub issue、查询数据库、发送消息——但它无法记住昨天做了什么、从过去的错误中学习或随时间积累知识。每个会话都从零开始，智能体对之前的交互、过去的决策或积累的上下文没有任何意识。

考虑一个具体例子。您有一个 AI 智能体，使用 MCP 访问公司的项目管理系统、代码仓库和通信渠道。周一，智能体帮您设计一个新的 API 端点。它根据团队讨论做出了关于认证模式、错误处理和响应格式的决定。周二，您要求同一个智能体实现第二个端点。没有记忆，它对周一的决定毫无记忆。它可能选择不同的认证模式、不一致的错误处理或不兼容的响应格式——不是因为这些选择更好，而是因为它没有记忆昨天决定了什么。

这不是一个假设性的问题。它是部署了基于 MCP 智能体的团队的头号投诉。智能体在当下很强大——它可以访问所需的所有工具——但它没有连续性。每个会话都是一个孤岛。智能体无法建立在昨天工作的基础上，无法从上周的错误中学习，也无法在多个相关任务之间保持一致性。正如 Li 等人（2025）在对生产 AI 智能体部署的分析中指出的，"无状态工具访问对于有效的长期运行智能体系统是必要的，但不充分的"（Li 等，"有状态智能体：生产 AI 系统的要求"，NeurIPS 2025）。

4. 为什么上下文窗口不是记忆

一个常见的反驳是，现代语言模型有越来越大的上下文窗口——128K token、200K token，甚至 1M token——您可以简单地在提示中包含相关历史。虽然这种方法对短期上下文有一定价值，但它从根本上误解了上下文和记忆之间的区别。

上下文是临时的。它存在于单个 API 调用期间，然后消失。记忆是持久的。它跨会话、跨天、跨月存在。无论上下文窗口多大，您都无法将六个月的智能体交互装入其中。即使可以，成本也会让人望而却步——您将在每次 API 调用中为数百万 token 的上下文付费，其中大部分与当前任务无关。

更重要的是，上下文是无差别的。上下文窗口中的所有内容具有同等地位——没有办法标记某些信息比其他信息更重要、更可靠或更新。相比之下，记忆可以被结构化、类型化、版本化和优先排序。好的记忆系统知道昨天学到的事实比六个月前学到的事实更可能是最新的。它知道经验证的事实比推断更可靠。它知道用户偏好与系统需求不同。上下文窗口不提供这些能力。

人类认知的类比很有启发性。您的工作记忆（上下文窗口）一次可以保持大约7个项目。但您的长期记忆存储了一生中积累的数十亿事实、经验和技能。您不会试图将所有内容保持在工作记忆中——您根据当前情况有选择地从长期记忆中检索所需内容。AI 智能体需要相同的架构：一个小型、聚焦的上下文窗口用于当前任务，辅以一个大型、结构化的记忆存储用于积累的知识。

5. MCP 智能体需要的三种状态

通过我们与生产 MCP 部署的合作，我们确定了智能体需要但 MCP 不提供的三种不同类型的状态。理解这些类别对于设计正确的记忆架构至关重要。

第一种类型是会话状态——需要在单个扩展交互中持久化但不一定跨会话的信息。这包括当前任务上下文、中间结果和对话历史。虽然上下文窗口处理了其中一些，但对于跨多个工具调用或需要回溯的长时间运行任务，它会失效。会话状态需要比上下文窗口本身更强大的存储机制。

第二种类型是知识状态——应该在所有会话中持久化的积累事实、偏好和学习模式。这是"智能体知道什么？"的问题。知识状态包括项目架构、团队规范、用户偏好和领域专业知识。它随时间增长，随着智能体获得经验，应该变得更可靠、更细致。

第三种类型是关系状态——不同信息片段之间的连接和依赖。这可能是最被忽视的类别。智能体不仅需要知道单个事实；它需要理解这些事实之间的关系。数据库架构连接到 API 端点，API 端点连接到前端组件，前端组件连接到用户故事。没有关系状态，智能体无法推理一个领域的变化如何影响其他领域——这是任何非平凡软件开发任务的基本能力。

6. 记忆作为 MCP 服务器：架构

解决 MCP 记忆差距的优雅方案是将记忆本身视为 MCP 服务器。与其修改 MCP 协议以添加有状态能力——这会损害其清晰的无状态设计——不如在工具服务器旁边添加记忆服务器。智能体通过与其他一切相同的协议与记忆交互：标准 MCP 工具调用。

这种架构有几个优势。首先，它与现有的 MCP 客户端和智能体完全兼容。您不需要修改智能体框架、切换到不同的协议或重写任何代码。您只需将新的 MCP 服务器——记忆服务器——添加到智能体的配置中。其次，它利用 MCP 现有的发现机制。智能体自动了解可用的记忆操作（存储、检索、搜索、更新、删除）及其参数模式。第三，它保持了 MCP 的可组合性：您可以将记忆服务器与任何其他 MCP 工具混合使用而不会冲突。

MemoryLake MCP 服务器通过标准 MCP 工具定义公开了一组丰富的记忆操作。store_memory 工具接受带有元数据、重要性评分和关系标签的类型化记忆条目。retrieve_memory 工具支持跨记忆类型的语义搜索和结构化查询。update_memory 工具自动处理冲突检测和解决。search_memory 工具提供跨相关记忆的多跳推理——这是简单向量搜索无法实现的。

7. MCP + MemoryLake = 完整的智能体栈

MCP 用于工具访问和 MemoryLake 用于持久记忆的组合创造了我们所称的"完整的智能体栈"。MCP 提供手——与外部世界交互的能力。MemoryLake 提供大脑——跨时间记忆、学习和推理的能力。它们共同实现了既有能力又有连续性的智能体。

在这种架构中，智能体在每个会话开始时查询 MemoryLake 获取相关上下文——项目知识、用户偏好、最近决策以及之前会话中未完成的任务。这些信息与用户当前请求一起加载到上下文窗口中。然后智能体使用 MCP 工具执行操作，工作过程中定期将新知识、决策和观察存储回 MemoryLake。会话结束时，智能体总结完成的工作并同样存储，创建跨会话的连续知识链。

这类似于人类的工作方式。当您早上坐在办公桌前时，您不会从零开始。您回忆昨天在做什么，查看笔记，审查待办事项清单，然后从离开的地方继续。您的工具（电脑、IDE、浏览器）给您行动的能力。您的记忆给您跨天和跨周连贯行动的连续性。MCP + MemoryLake 给 AI 智能体相同的双重能力。

8. 实现模式

我们已经确定了几种适用于 MCP + MemoryLake 部署的实现模式。最常见的是"记忆增强提示"模式，智能体在每次对话开始时查询 MemoryLake 加载相关上下文。这是最简单的模式，适用于大多数用例。智能体添加包含检索记忆的系统提示，语言模型自然地将此上下文纳入其响应。

第二种模式是"持续记忆"，智能体将记忆作为每个重要操作的副作用进行存储。这更积极，但随时间产生更丰富的记忆。智能体不等待特殊的"保存记忆"命令——它自动识别重要信息、决策和观察并实时存储。这种模式最适合每个会话执行大量操作的长期运行智能体。

第三种模式是"反思记忆"，智能体定期暂停反思所学内容，存储更高层次的洞察而非原始观察。这种模式受到 Park 等人生成式智能体工作中反思机制的启发（Park 等，2023），其中智能体定期将经验综合为更抽象的知识。反思记忆对于需要随时间发展专业知识的智能体特别有价值——反思作为一种压缩的高价值知识形式，比原始事件日志对未来会话更有用。

9. 真实世界用例

MCP + MemoryLake 架构已成功部署在广泛的用例中。在软件开发中，编码智能体使用 MCP 访问仓库、问题追踪器和 CI/CD 流水线，而 MemoryLake 存储项目架构知识、编码规范和调试策略。结果是一个随着每个会话变得更有效的智能体——它学习代码库，理解团队偏好，并避免重复过去的错误。

在客户支持中，智能体使用 MCP 访问工单系统、知识库和通信渠道，而 MemoryLake 存储客户历史、解决模式和升级协议。智能体记住客户X上个月有账单问题，并主动检查是否已解决，而不是要求客户从头解释他们的历史。

在研究和分析中，智能体使用 MCP 访问数据源、API 和计算工具，而 MemoryLake 存储研究发现、方法论决策和分析框架。智能体建立在之前分析的基础上，而不是从头开始每个查询，随时间实现更深入和更细致的研究。这些用例展示了一致的模式：MCP 提供操作能力，MemoryLake 提供使这些操作随时间保持连贯和有效的组织知识。

MCP + 记忆：不仅是回忆，还有计算和外部数据

关于 MCP + 记忆的讨论通常聚焦于回忆——赋予智能体记住之前会话中发生了什么的能力。但这种组合解锁了两个经常被忽视的更深层能力：记忆驱动的计算和外部数据作为记忆来源。

记忆驱动的计算意味着记忆服务器不仅存储和检索——它推理。当编码智能体检索项目架构记忆时，记忆服务器可以计算哪些记忆相互冲突（团队在3月决定使用REST但在6月开始构建gRPC端点），哪些模式跨会话反复出现（用户总是在添加新端点后重构错误处理），以及出现什么时间趋势（项目在三个月内逐渐从单体转向微服务）。这些计算——冲突检测、模式综合、时间推理——在记忆层内部发生，并通过 MCP 工具响应浮现。智能体接收到的不仅是原始记忆，还有计算出的洞察。

外部数据作为记忆来源意味着 MCP 工具本身成为记忆图谱的数据提供者。当智能体使用 GitHub MCP 服务器审查拉取请求时，结果——更改的文件、审查评论、CI状态——可以作为事件和事实记忆自动摄入记忆层。当它通过 MCP 服务器查询数据库时，模式信息和查询模式成为智能体积累知识的一部分。记忆层不仅从对话中增长，还从每次 MCP 工具交互中增长。这将 MCP 从无状态的工具调用协议转变为持续学习系统的输入管道。

完整的图景是这样的：MCP 提供工具访问（行动的能力），记忆提供回忆（记忆的能力），记忆计算提供推理（对记忆内容进行思考的能力），而通过 MCP 工具的外部数据补充提供增长（从每个行动中学习的能力）。这个四层栈——行动、记忆、推理、学习——是 MCP + MemoryLake 真正大于各部分之和的原因。

10. 未来：记忆原生的 MCP

展望未来，我们相信记忆将成为 MCP 生态系统中的一等概念，即使它在架构上仍与核心协议分离。MCP 规范可能会发展到包含标准化的记忆工具模式——所有记忆提供商都可以实现的记忆操作通用词汇。这将允许智能体通过一致的接口与任何记忆后端（MemoryLake、本地文件、自定义数据库）合作，就像 MCP 已经标准化了工具访问一样。

我们正在积极为这一愿景做贡献。MemoryLake MCP 服务器是开源的，作为记忆增强 MCP 智能体的参考实现。我们还在与 MCP 社区合作提议标准化的记忆工具模式，这些模式可以被其他记忆提供商采用。目标不是创建 MemoryLake 对智能体记忆的垄断，而是将记忆确立为 MCP 生态系统中公认的、标准化的能力——任何提供商都可以实现，任何智能体都可以使用。

等式很简单：MCP 提供工具访问，MemoryLake 提供持久记忆，它们共同创建完整的智能体栈。没有记忆的工具是无状态函数。没有工具的记忆是被动知识。两者的结合是将 AI 聊天机器人转变为真正 AI 智能体的关键——一个能够行动、学习和随时间改进的智能体。MCP 中缺失的层不是缺陷；它是机遇。而机遇就在现在。

相关文章

• OpenClaw 刚刚发布——它的记忆能做什么
• 60秒为 OpenClaw 添加持久记忆
• 为什么多智能体团队需要共享记忆