Adaptive Recall登场：给AI助手装上一颗基于MCP的长期记忆

又一个记忆方案，但这次走的是MCP协议

昨天Hacker News的Show HN板块冒出一个新项目：Adaptive Recall，官网自称是「AI助手的持久化记忆层」，走的是Model Context Protocol（MCP）协议。开发者把它挂到Claude Desktop、Cursor、Windsurf这类支持MCP的客户端上，助手就能跨会话记住用户说过的话、做过的项目、踩过的坑。

听起来是不是有点耳熟？Mem0、Letta（前MemGPT）、LangMem，包括AWS今年推的Bedrock AgentCore Memory，做的都是类似的事——给LLM一个「外挂海马体」。但Adaptive Recall这次的切入点不太一样：它不做SDK、不做框架，而是把记忆能力直接封装成一个MCP服务器，谁想用谁接。

这个思路值得聊聊。因为它反映的是2026年整个AI基础设施的一个明显趋势：记忆正在从「框架内嵌功能」变成「独立协议层」。

为什么记忆这件事一直没做好

先说个开发者都遇到过的场景。你用Claude或者ChatGPT写代码，反复告诉它「我们项目用的是Vue 3组合式API，别给我写Options API」「数据库是PostgreSQL 15，别用MySQL语法」。这些话说了十遍，第十一次开新会话它还是老老实实忘掉。

根本问题在上下文窗口。哪怕是Claude的200K窗口、Gemini的百万窗口，塞满历史对话都是奢侈的——一方面成本上不划算，另一方面上下文一长模型的推理质量还会下降（业内叫「lost in the middle」现象，中间部分的信息模型会「视而不见」）。

于是就有了各种记忆方案，大致分三类：

• 框架内嵌型：LangMem、Letta这种，深度绑定LangChain/LangGraph生态，你得用它的Agent框架才能吃到记忆能力
• 独立SDK型：Mem0是典型代表，一套API包起来，你自己在Agent里调，灵活但要写胶水代码
• 托管服务型：AWS Bedrock AgentCore Memory、阿里云百炼的长期记忆体，云厂商全托管，一键接入但绑云

这三类各有各的问题：框架型侵入性太强，独立SDK型对接成本高，托管型有厂商锁定。Adaptive Recall走的是第四条路——协议化。你的助手只要说MCP，我就能给你记忆。

MCP这层壳，到底解决了什么

MCP是Anthropic去年底推、今年上半年被主流客户端全面接纳的协议。它的定位类似「AI界的LSP」——LSP让编辑器和语言服务解耦，MCP让LLM客户端和工具/数据源解耦。

把记忆做成MCP服务的直接好处是：

1. 零SDK集成：Claude Desktop、Cursor、Cline、Windsurf、Zed这些主流客户端都已经原生支持MCP，加一行配置就能接入，不用改代码
2. 模型无关：底层跑的是GPT-5、Claude Opus 4.8还是DeepSeek V4都无所谓，客户端负责调模型，MCP负责给数据
3. 可组合：你可以同时挂记忆MCP、文件MCP、数据库MCP，助手按需调用

配置起来大概长这样，跟接其他MCP服务器没差别：

{
  "mcpServers": {
    "adaptive-recall": {
      "command": "npx",
      "args": ["-y", "@adaptive-recall/mcp-server"],
      "env": {
        "RECALL_API_KEY": "your-key-here"
      }
    }
  }
}

对开发者来说，这种「一次配置、多处生效」的体验，比每换一个IDE就要重接一遍Mem0要舒服得多。

技术实现上的取舍

从官网和Show HN评论里能扒出的信息看，Adaptive Recall的架构没什么颠覆性——本质还是那套「向量检索+LLM抽取」的组合拳。但它在几个细节上做了取舍：

存什么：不是把对话原文全塞进去，而是让LLM在后台异步分析每轮对话，提炼出「事实」「偏好」「项目上下文」三类结构化记忆片段。这个思路和阿里云百炼的「记忆变量+记忆片段」双层结构、Bedrock AgentCore的memory strategies几乎如出一辙——业界基本收敛到这个范式了。

怎么召回：走的是语义检索，用户新一轮提问先做向量匹配，把Top-K相关记忆注入到当前上下文。这里有个隐藏成本要注意——记忆越多，每轮对话的Token开销越大。Adaptive Recall官方没给具体数字，但按行业经验，一个「活跃了半年」的记忆库，每轮召回大概会增加2000-5000 Token的开销。这不是免费午餐。

放哪里：这是Adaptive Recall和Mem0、Letta最本质的区别——它默认走云端SaaS，不像mcp-ai-memory那类开源项目支持本地Qdrant+Ollama纯本地部署。对隐私敏感的团队来说这是个减分项，虽然官方说了「企业版支持自托管」，但没开源的话可信度打折扣。

跟现有方案比，值得用吗

实话实说，Adaptive Recall在技术上没有秒杀谁。Mem0在GitHub上快30k星了、Letta的双层虚拟内存架构学术味更浓、AWS AgentCore有企业级SLA背书。这些都是Adaptive Recall短期内比不了的。

但它抓住了一个正确的产品切面：开发者不想再写胶水代码了。

我最近跟几个做AI应用的朋友聊，普遍反馈是——2025年下半年到2026年初，AI基础设施的心智负担在爆炸增长。你要选模型API聚合服务、选Agent框架、选向量库、选记忆方案、选评测工具……每个环节都有5-10个候选。开发者要的是「插上就能用」，而不是「读三篇论文再选型」。

MCP协议化恰恰对准了这个痛点。就像2005年前后的Web开发者不需要关心HTTP协议细节、只需要用Rails的路由DSL一样，未来的AI应用开发者也不应该被记忆抽取的prompt模板、向量库选型这些事拖住。

从这个角度看，Adaptive Recall即便技术上是「Mem0的MCP皮肤版」，也依然有它的位置。协议化本身就是一种价值创造。

一个必须提的隐忧：记忆污染

聊记忆方案，绕不开一个业内还没解决好的问题：记忆污染（memory poisoning）。

如果用户在一次会话里说了句气话「我最讨厌TypeScript」，助手当真了、写进长期记忆里，那接下来几个月它给你推的方案可能都在绕开TS，你还不知道为啥。阿里云百炼的做法是引入「记忆变量」作为高权重校准项，让用户手动定义关键字段，避免临时性信息干扰。Bedrock AgentCore则通过记忆策略配置，把「事实」「偏好」「摘要」分开处理。

Adaptive Recall目前的公开文档里，对这块的处理逻辑没细说。这是评估任何记忆方案时要重点看的一点：它有没有给用户提供记忆的可视化、编辑、删除入口？有没有区分「稳定事实」和「临时状态」？如果只是无脑存无脑召回，用久了迟早出问题。

顺带一提

Adaptive Recall本身没有绑定任何特定模型，客户端调GPT-5、Claude Opus 4.8、Gemini 3、DeepSeek V4都可以。如果你在国内环境测试，OpenAI Hub这类聚合平台一个Key就能覆盖上述全部主流模型，直连不折腾，用来跑MCP+多模型对比记忆效果挺方便的。

写在最后

2026年了，长期记忆已经不是「值不值得做」的问题，而是「怎么做才不添麻烦」的问题。Adaptive Recall的出现说明一件事——MCP正在成为AI能力交付的默认接口。以前是SDK时代，一个能力对应一个SDK；现在是协议时代，一个能力对应一个MCP服务器。

对开发者来说，短期内不用急着切换方案，Mem0跑得好就继续用。但如果你正在启动新项目、或者痛恨集成成本，Adaptive Recall值得放进你的候选清单里试一下。协议化的红利，总是要有人先吃到的。

参考来源

• MorseWayne/mcp-ai-memory (GitHub) — 一个基于Mem0的开源MCP记忆服务器实现，支持本地部署和自定义LLM，可作为Adaptive Recall的开源对照参考
• AI Agent入门指南（四）：Memory记忆机制综述（知乎） — 系统梳理了Agent记忆机制的分类、实现思路和主流框架对比，理解记忆层设计的入门读物