每日 MCP Server

Memory MCP:让 LLM 拥有跨会话记忆的官方服务器

2026-08-10
开发仓库
支持客户端:
Claude CodeCursorVS CodeContinueCline
MCPMemory记忆知识图谱

简介

Memory MCP 是 ModelContextProtocol 官方维护的记忆集成服务器,基于知识图谱让 LLM 客户端能够记住用户的偏好、事实与关系,实现跨会话的个性化记忆。一条 npx 命令即可让 Claude Code、Cursor 等 MCP 客户端记住'你是谁、你喜欢什么、你在做什么'。本文梳理核心能力、知识图谱模型、各客户端接入与实战注意事项。

安装命令

npx -y @modelcontextprotocol/server-memory

简介

Memory MCP 是 ModelContextProtocol 官方仓库维护的记忆集成服务器。它基于知识图谱(Knowledge Graph)存储用户信息,让 LLM 能跨会话记住用户的偏好、事实与关系。

对所有 LLM 用户而言,这意味着:AI 助理不再"金鱼记忆"——它记得你是前端开发者、你用 React、你正在做一个叫"ShopEase"的电商项目、你偏好简洁的代码风格。

为什么需要 Memory MCP

LLM 的根本局限:无状态。每次对话都是全新的,上一次说过的事这次全忘。

会话 1:
用户:我是前端开发者,用 React
AI:好的,记住了

会话 2(新开):
用户:帮我写个组件
AI:好的,请问你用什么框架?  ← 忘了

传统解决方案:

方案问题
每次手动粘贴背景麻烦,重复劳动
System Prompt 写死无法动态更新
存数据库 + RAG过度工程,小事大做

Memory MCP 的方案:知识图谱 + 自然语言读写,轻量且结构化。

核心能力

工具名用途关键参数
create_entities创建实体entities[](名称+类型+观察)
create_relations创建关系relations[](源+目标+类型)
add_observations添加观察entity_name、observations[]
delete_entities删除实体entity_names[]
delete_observations删除观察entity_name、observations[]
delete_relations删除关系relations[]
read_graph读取整个图谱无
search_nodes搜索节点query
open_nodes打开指定节点names[]

知识图谱模型

Memory MCP 用三类元素建模记忆:

1. 实体(Entity)

{
  "name": "用户",
  "entityType": "Person",
  "observations": [
    "前端开发者",
    "用 React 和 TypeScript",
    "正在开发 ShopEase 电商项目"
  ]
}

2. 关系(Relation)

{
  "from": "用户",
  "to": "ShopEase",
  "relationType": "正在开发"
}

3. 观察(Observation)

事实性陈述,可随时添加或删除:

"用户偏好简洁代码风格"
"用户团队有 5 人"
"用户用 Vercel 部署"

图谱示例

[用户:Person] --正在开发--> [ShopEase:Project]
     |                           |
     |偏好                       |技术栈
     ↓                           ↓
[简洁代码:Preference]     [React+TS:TechStack]
     |
     |部署在
     ↓
[Vercel:Service]

各客户端配置示例

Claude Code(CLI)

编辑 ~/.claude/claude_desktop_config.json:

{
  "mcpServers": {
    "memory": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-memory"]
    }
  }
}

默认将记忆存于 ~/.memory.json。

自定义存储路径

{
  "mcpServers": {
    "memory": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-memory"],
      "env": {
        "MEMORY_FILE_PATH": "/Users/yourname/.config/ai-memory.json"
      }
    }
  }
}

Cursor

编辑 ~/.cursor/mcp.json,结构同 Claude Desktop。

VS Code(Continue 插件)

编辑 ~/.continue/config.json:

{
  "experimental": {
    "modelContextProtocolServers": [
      {
        "transport": {
          "type": "stdio",
          "command": "npx",
          "args": ["-y", "@modelcontextprotocol/server-memory"]
        }
      }
    ]
  }
}

实战场景

场景 1:让 Claude Code 记住你的开发偏好

记住以下信息:
- 我是前端开发者,主要用 React + TypeScript
- 我在做一个叫 ShopEase 的电商项目
- 我偏好简洁的代码,不喜欢过多注释
- 我用 Vercel 部署,用 Tailwind CSS 做样式
- 我的团队有 5 个人,用 GitHub 做版本控制

Claude Code 会调用 create_entities + create_relations 构建知识图谱。下次新会话直接可用。

场景 2:让 Cursor 记住项目上下文

项目信息:
- ShopEase 是一个电商前端项目
- 技术栈:Next.js 14 + TypeScript + Tailwind + Prisma
- 部署在 Vercel
- 数据库用 Supabase
- 正在重构购物车模块
- 上周完成了用户认证

下次开新会话问"帮我写个购物车组件",Cursor 会记得你的技术栈,直接用 Next.js + Tailwind 写。

场景 3:让 Claude Code 记住代码规范

记住我的代码规范:
- 函数用 camelCase
- 组件用 PascalCase
- 常量用 UPPER_SNAKE_CASE
- 文件名用 kebab-case
- 用函数组件,不用 class 组件
- 用 hooks,不用 HOC
- 每个函数不超过 30 行

以后生成代码自动遵守这些规范,无需每次重复说明。

场景 4:跨项目记忆

我之前做过一个叫 TaskFlow 的项目管理工具,
用的技术栈是 Vue 3 + Pinia + Vite,
现在我想参考它的架构设计 ShopEase。

Claude Code 会建立两个项目的关联,在讨论 ShopEase 时能参考 TaskFlow 的经验。

与其他 MCP 的对比

MCP记忆类型存储适合
Memory MCP结构化知识图谱JSON 文件用户偏好、项目上下文
Postgres MCP结构化数据数据库业务数据查询
Filesystem MCP文件本地文件代码与文档
GitHub MCP仓库Git代码版本管理

组合建议:Memory MCP 记"你是谁",Filesystem MCP 管"你的代码",GitHub MCP 管"你的协作"。

记忆管理策略

1. 主动记忆

用户明确说"记住这个":

用户:记住我用 React 18
→ AI 调用 create_entities

2. 被动记忆

AI 从对话中推断值得记住的信息:

用户:帮我用 Vue 写个组件(第 5 次了)
→ AI 推断"用户用 Vue",存入记忆

3. 记忆更新

旧记忆:用户用 React 17
新信息:我升级到 React 18 了
→ AI 调用 add_observations + delete_observations

4. 记忆遗忘

用户:我不用 Vue 了,现在用 React
→ AI 删除"用 Vue"的观察,添加"用 React"

注意事项

  1. 存储是本地文件:记忆存在本地 JSON,不同设备不同步,需手动复制 memory.json。
  2. 无加密:记忆文件是明文 JSON,敏感信息(密码、密钥)不要存。
  3. 记忆膨胀:长期使用后记忆文件会变大,定期清理过时信息。
  4. 冲突处理:多个 AI 客户端同时写入可能冲突,建议一个主客户端管理记忆。
  5. 隐私边界:AI 可能记住不该记的信息(如临时讨论),需定期审查 read_graph。
  6. 记忆不是数据库:Memory MCP 适合存"偏好与事实",不适合存大量结构化数据(用 Postgres)。
  7. 跨用户隔离:多人共用设备时,每人应有独立的 memory.json 文件。
  8. 备份:memory.json 是 AI 的"长期记忆",定期备份。

安全建议

  • 不存敏感信息:密码、API Key、个人身份信息不要存入记忆
  • 定期审查:用 read_graph 检查 AI 记住了什么,删除不当内容
  • 分人隔离:不同用户用不同 MEMORY_FILE_PATH
  • 文件权限:memory.json 设置 chmod 600
  • 版本控制:把 memory.json 纳入 Git(注意脱敏)

与 RAG 的区别

维度Memory MCPRAG
数据类型用户偏好、事实、关系文档知识
存储JSON 知识图谱向量数据库
查询精确匹配语义相似度
更新实时增删批量重建索引
适合"你是谁""你知道什么"
规模小(百条)大(万条)

互补关系:Memory MCP 记用户画像,RAG 检索知识库。Agent 两者都需要——既要知道"用户是谁",又要知道"答案在哪"。

小结

Memory MCP 是 AI 应用的个性化基石:让 LLM 从"千人一面"进化到"千人千面"。一个 JSON 文件、一条 npx 命令,就能让任意 MCP 客户端记住用户的偏好、项目与关系。

MCP 进阶系列下一篇将讲 Brave Search MCP 进阶:让 LLM 实时联网搜索的深度用法。

相关推荐

查看更多 →
MCP开发

Memory MCP:给编码 Agent 装上跨 session 长期记忆

Muse Code、Claude Code 这类长任务 Agent 最怕的是:新开一个 session,之前讨论的架构决策、踩过的坑、命名约定全忘了,又得从头讲一遍。Memory MCP(@modelcontextprotocol/server-memory)给 Agent 装上跨 session 持久记忆:基于知识图谱存储实体与关系,自动从对话里提取记忆,下次启动直接 recall。本篇覆盖核心能力、Claude Code / Cursor / VS Code 三客户端配置、与 Muse Code append-only 日志的协同、以及长任务记忆分层策略。

2026-08-26
#MCP#Memory
MCP开发

MCP Elicitation 实战:让服务端在缺参数时反向向用户提问——受限 Schema 设计 + 四套客户端配置 + 13 行排查表

写 MCP Server 的人迟早会遇到一个尴尬场景:工具必填参数用户没给,服务端要么猜一个(猜错就出事),要么返回一个干巴巴的「缺少参数 xx」让 Agent 自己去追问(Agent 经常追问得驴唇不对马嘴)。MCP 协议里的 Elicitation 就是为这个场景设计的第三个「反向能力」——服务端可以在执行过程中主动向客户端发起一次提问,由客户端把问题渲染成表单弹给用户,用户填完再回传,全程服务端不需要自己实现任何 UI、不需要存任何凭据。本文讲透它的机制与边界:elicitation/create 请求的完整结构、为什么 requestedSchema 被刻意限制成只支持原始类型(这是安全设计不是能力不足)、用户的三种响应(accept / decline / cancel)各自的语义差异、以及最关键的——为什么不能在 Elicitation 里索取密码和 API Key。含 TypeScript SDK 完整实现(含类型定义与降级路径)、Claude Code / Cursor / VS Code + Copilot / Trae 四套带中文注释的配置、三个实战场景(部署确认 / 缺失参数补全 / 敏感操作二次确认)、与 Sampling / 传统参数校验的选型对比、六条安全注意事项,以及 13 行故障排查表。

2026-10-12
#MCP#Model Context Protocol
MCP开发

MCP Roots 与 Sampling 实战:让服务端主动划边界、反向要推理——四套客户端配置 + 14 行排查表

多数人写 MCP Server 只用到 Resources / Tools / Prompts 三项,Roots 和 Sampling 这两个反向能力基本闲置,结果就是 Server 既不知道自己该在哪干活,也没有推理能力。本文把这两个方向的能力讲透:Roots 是客户端告诉服务端「工作区边界在哪」的机制(URI 列表、roots/list 双向协商、listChanged 动态通知、路径穿越的必修防御),Sampling 是服务端反过来向客户端的 LLM 请求一次推理的机制(服务端不知道任何 API Key,模型由客户端挑、账由客户端付、人可以卡在中间审批)。含 TypeScript SDK 完整实现代码(含 sampling/createMessage 的类型定义与 human-in-the-loop 回调)、Claude Code / Cursor / VS Code + Copilot / Trae 四套带中文注释的配置、三个实战场景(单仓守卫 / 日志归因摘要 / 隐私脱敏代理)、与其他方案的选型对比表、六条安全注意事项,以及 14 行故障排查表。

2026-10-10
#MCP#Model Context Protocol
MCP开发

MCP 无状态化改造:协议层不再存状态之后——并发、水平扩容、断线重连三大硬伤的根治方案与四套客户端配置

2026 年 MCP 协议经历了一次方向性的改动:核心交互不再依赖服务端保存的会话状态,状态不再存储在协议层,而是被甩给应用层处理。对写过有状态 MCP Server 的人来说,这次改动的直接感受是「少了一大堆坑」——会话粘连导致的多实例不可用、水平扩容一扩就断连、断线重连要么报错要么整段重放。本文讲清楚三件事:为什么协议层存状态在生产环境必然出问题(并发、扩容、重连三个硬伤,各配一组实测对照数据);无状态化之后你手里的工具清单发生了什么变化(transport 类、协议方法、Serverless 适配);以及状态外置的三种标准实现(外部存储、客户端持有、资源句柄),每种都给出可直接跑的 TypeScript SDK 代码。含 Claude Code / Cursor / VS Code / Trae 四套带中文注释的完整配置、三个实战场景、选型对比表、安全注意事项(含 DNS 重绑定的必修项),以及 14 行故障排查表。

2026-10-08
#MCP#Model Context Protocol