---
title: "MCP Memory Server：把长期记忆存成知识图谱"
wiki: mcp
category: "服务端开发"
slug: server-memory
url: https://learnagent.wiki/mcp/cards/server-memory
tags: ["MCP", "Memory Server", "知识图谱", "长期记忆", "Reference Server"]
last_updated: 2026-04-11
reading_time: 11
---
> Memory Server 是 MCP 官方 reference servers 里最容易被误解的一类。很多人一看名字就会以为它是“让 Claude 永远记住一切”的万能记忆外挂。实际上官方 README 说得很明确：**这是一个基于本地 knowledge graph 的持久化 memory 基础实现。**
# MCP Memory Server：把长期记忆存成知识图谱
## 基础概念
Memory Server 是 MCP 官方 reference servers 里最容易被误解的一类。很多人一看名字就会以为它是“让 Claude 永远记住一切”的万能记忆外挂。实际上官方 README 说得很明确：**这是一个基于本地 knowledge graph 的持久化 memory 基础实现。**
它的本质不是“自动记忆所有聊天”，而是把记忆拆成三种结构化对象：
- **Entities**：实体
- **Relations**：关系
- **Observations**：观察值 / 事实
这种设计很关键。因为它意味着 Memory Server 存的不是“一整段聊天记录”，而是更像数据库里的知识片段。比如：
- 某人是谁
- 某人和某组织是什么关系
- 某人有哪些稳定偏好或事实
这和把全文对话直接塞进向量库是两种完全不同的记忆哲学。
### 核心要素
| 要素 | 作用 |
|------|------|
| **实体（Entities）** | 知识图谱里的节点，通常是人、组织、事件等对象 |
| **关系（Relations）** | 节点之间的有向连接，比如 `works_at`、`knows`、`likes` |
| **观察值（Observations）** | 贴在实体上的离散事实，强调原子性，一条 observation 最好只表达一个事实 |
| **持久化存储** | 官方 README 说明它默认把数据存在本地 `memory.jsonl`，也支持通过环境变量改路径 |
| **使用定位** | reference implementation，适合学习和搭原型，不应直接等同于企业级记忆系统 |
### 它到底存的是什么
```mermaid
graph TD
A["用户信息 / 对话里提取出的稳定事实"] --> B["Entity"]
A --> C["Relation"]
A --> D["Observation"]
B --> E["name + entityType"]
C --> F["from + to + relationType"]
D --> G["entityName + atomic facts"]
E --> H["本地 knowledge graph"]
F --> H
G --> H
```
官方 README 的建议非常值得记住：**Observation 应该是原子的，一条 observation 最好只表达一个事实。**
也就是：
- 好的：`"Prefers morning meetings"`
- 不好的：`"Works at Anthropic, speaks Spanish, likes tea, and travels often"`
### 为什么它不是“聊天记录仓库”
```mermaid
graph LR
A["原始对话"] --> B["筛出稳定、有价值、可复用的信息"]
B --> C["实体"]
B --> D["关系"]
B --> E["观察值"]
C --> F["知识图谱记忆"]
D --> F
E --> F
```
这个流程说明了一件事：**Memory Server 更像“结构化记忆层”，不是“原样存聊天历史”。**
## 基础用法
### 官方最小配置
在 Claude Desktop 里，官方 README 给出的最简单配置是：
```json
{
"mcpServers": {
"memory": {
"command": "npx",
"args": [
"-y",
"@modelcontextprotocol/server-memory"
]
}
}
}
```
如果你更想自己控制存储文件位置，还可以加环境变量：
```json
{
"mcpServers": {
"memory": {
"command": "npx",
"args": [
"-y",
"@modelcontextprotocol/server-memory"
],
"env": {
"MEMORY_FILE_PATH": "/path/to/custom/memory.jsonl"
}
}
}
}
```
README 里明确写了：
- `MEMORY_FILE_PATH` 用来覆盖默认存储路径
- 默认文件名是 `memory.jsonl`
### 它最适合怎么用
一个典型流程是：
```text
你：以后记住，我更喜欢早上开会，而且我会说西班牙语。
客户端 / 系统提示：
1. 识别“这是稳定偏好和长期事实”
2. 把你映射成一个实体，比如 default_user
3. 调用 add_observations
4. 在之后对话里再先检索相关记忆
```
重点在于：**Memory Server 自己不会凭空知道哪些内容该记、什么时候记。** 这通常依赖客户端流程设计、系统提示或上层应用策略。
### 常用工具怎么理解
#### 创建实体
```json
{
"entities": [
{
"name": "default_user",
"entityType": "person",
"observations": [
"Speaks fluent Spanish"
]
}
]
}
```
这类调用对应 `create_entities`。
#### 创建关系
```json
{
"relations": [
{
"from": "default_user",
"to": "Anthropic",
"relationType": "works_at"
}
]
}
```
这类调用对应 `create_relations`。
#### 新增观察值
```json
{
"observations": [
{
"entityName": "default_user",
"contents": [
"Prefers morning meetings",
"Likes concise answers"
]
}
]
}
```
这对应 `add_observations`，是最常见的记忆补充路径。
#### 搜记忆
```json
{
"query": "Spanish morning meetings"
}
```
这对应 `search_nodes`。README 说明它会同时搜索：
- 实体名
- 实体类型
- observation 内容
### 官方还给了一个很关键的提示
README 里甚至附了一个示例 system prompt，指导模型把用户信息按：
- 身份
- 行为
- 偏好
- 目标
- 关系
这些维度去写入 memory。这里最值得学习的，不是照抄 prompt，而是一个原则：
> **Memory Server 的好坏，很大程度取决于你的“记忆提取策略”是否稳定。**
也就是说，真正难的常常不是 Server 本身，而是“上层什么时候记、记什么、怎么避免记垃圾信息”。
## 同类工具对比
如果目标都是“让 AI 具备长期记忆”，常见路线并不止一种：
| 维度 | Memory Server | 直接保留聊天历史 | 向量数据库记忆方案 |
|------|---------------|------------------|-------------------|
| 核心存储对象 | 实体、关系、观察值 | 整段原始对话 | 文本块 / embedding |
| 适合什么信息 | 稳定事实、关系、偏好 | 上下文回放 | 语义检索、长文档召回 |
| 结构化程度 | **高** | 低 | 中 |
| 可解释性 | 高，容易看出记了什么 | 中，容易冗长 | 中，召回逻辑不直观 |
| 上手成本 | 低到中 | 最低 | 中到高 |
核心区别：
- **Memory Server**：适合存“稳定、可复用、能结构化表达”的长期记忆。
- **聊天历史**：适合保留上下文，但不适合做精炼长期记忆层。
- **向量数据库方案**：更适合语义检索，不一定天然适合人物关系和偏好管理。
## 常见误区
| 误区 | 准确理解 |
|------|----------|
| 以为 Memory Server 会自动记住所有聊天内容 | 不会。它只是提供记忆存取能力，何时写入要靠客户端或上层策略 |
| 以为它存的是完整聊天记录 | 不是。官方设计是知识图谱，核心对象是实体、关系、观察值 |
| 以为 observation 写得越长越完整越好 | 不对。README 明确建议 observation 原子化，一条尽量只表达一个事实 |
| 以为它适合直接做企业级长期记忆平台 | 它是 basic implementation / reference server，适合原型和学习，不是现成企业方案 |
| 以为只要存了 memory，模型就一定会主动用好 | 不一定。检索策略、系统提示和调用时机决定了记忆实际效果 |
| 以为它只能做用户画像 | 不止。也能存组织、事件、项目、关系网络，只要你设计好实体和关系即可 |
## 优劣势分析
| 优势 | 劣势 |
|------|------|
| **结构清楚**：实体、关系、观察值这套模型比“整段聊天堆起来”更可控 | **需要额外提取策略**：记什么、怎么记，不是 Server 自己能自动解决的 |
| **适合长期偏好和关系管理**：很适合做个性化和持续协作记忆层 | **不是语义检索万能方案**：面对长文本知识库，不如向量检索自然 |
| **本地持久化简单**：用 JSONL 就能跑起来 | **reference implementation 定位明显**：复杂安全、协作、权限仍需自行设计 |
| **容易解释和审查**：你能明确看到记忆图谱里到底存了什么 | **记忆污染风险真实存在**：上层提取策略差，会把无价值甚至错误信息存进去 |
| **跨客户端复用潜力好**：只要客户端会调，就能共享同一记忆层 | **图谱设计需要 discipline**：实体命名、关系命名、观察值粒度都要统一 |
## 思考题
初级：为什么官方 Memory Server 要把记忆拆成“实体、关系、观察值”三层，而不是直接存一整段文本？
**参考答案：**
因为长期记忆真正有价值的部分，往往不是原始措辞，而是可以重复利用的结构化事实。
比如“用户喜欢早上开会”这件事，关键不是它当时在聊天里用了什么句子表达，而是这条偏好本身。拆成实体、关系、观察值后，后续检索、修改、删除都更清楚。
这也解释了为什么它更适合做“长期记忆层”，而不是“聊天归档系统”。
中级：什么时候你应该把信息写成 observation，什么时候应该单独建实体和 relation？
**参考答案：**
判断标准是：这条信息未来是否值得被单独引用、关联和扩展。
如果只是某个主体身上的稳定属性，比如“喜欢简洁回答”“偏好晨会”，通常写 observation 就够了。
但如果这条信息涉及另一个重要对象，比如“在 Anthropic 工作”“和某个项目有关系”，那就更适合把对方建成实体，再用 relation 连接起来。这样未来你还能继续往那个实体上追加更多信息。
简单说：
- **单体事实**：优先 observation
- **涉及另一个长期重要对象**：考虑实体 + relation
进阶：为什么很多 Memory Server 项目最后不是死在“不会存”，而是死在“不会取”和“不会筛”？
**参考答案：**
因为长期记忆系统真正难的常常不是写入接口，而是记忆治理。
如果你的策略是“用户说啥都记”，记忆很快就会膨胀、污染、互相矛盾。到最后模型虽然“有记忆”，但检索回来的东西反而让回答变差。
所以成熟一点的思路通常要同时设计三件事：
1. **提取标准**：什么信息值得记
2. **检索标准**：什么时候取哪些记忆
3. **修订标准**：旧事实被新事实推翻时怎么更新
Memory Server 只是给你一套结构化容器，真正决定效果的是上层治理策略。
## 参考资料
1. 官方 Memory reference server README：（查询日期 2026-04-11）
2. 官方 Reference Servers 仓库：（查询日期 2026-04-11）
3. MCP 官方示例服务器目录：（查询日期 2026-04-11）
---
*Source: https://learnagent.wiki/mcp/cards/server-memory*
*Markdown mirror of https://learnagent.wiki, served as text/markdown for LLM ingestion.*