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