MemoryGraph:上下文高效的 MCP 内存且不放弃 MCP

发布: (2025年12月7日 GMT+8 21:29)
7 min read
原文: Dev.to

Source: Dev.to

上下文窗口问题是真实存在的

如果你使用过 AI 编码代理,你一定经历过:代理变慢、令牌费用飙升,或者任务因为上下文窗口达到上限而失败。最近的一篇文章突显了这一痛点,显示仅三个流行的 MCP 服务器就消耗了 26 % 的编码代理上下文窗口。

罪魁祸首是什么?MCP 服务器会预先加载数十个工具定义到上下文窗口中,无论代理是否需要它们。一些记忆解决方案公开 40 + 个工具,每个工具都有冗长的描述,导致在代理真正开始工作之前就已经占用了成千上万的令牌。

这确实是一个值得关注的问题。但解决方案并不是完全放弃 MCP——而是把 上下文效率 作为 MCP 服务器的首要设计要求。

MemoryGraph 的做法:审慎的工具设计

MemoryGraph 走了一条不同的道路。我们没有把每一种可能的记忆操作都做成单独的工具,而是围绕一个核心原则进行设计:最少工具,最大能力

数据对比

方案默认工具数量典型上下文使用率
重量级 MCP 服务器40 + 个工具20‑30 % 的上下文
MemoryGraph 核心9 个工具~2‑3 % 的上下文
MemoryGraph 扩展11 个工具~3‑4 % 的上下文

九个工具。足以覆盖 95 % 的使用场景。每个工具的描述都力求简洁,同时保持可发现性。

工具配置文件:按需提供上下文

我们实现了 工具配置文件,让用户可以显式控制自己的上下文占用:

# 核心模式(默认)- 9 个工具,最小上下文
memorygraph

# 扩展模式 - 11 个工具,增加统计和高级查询
memorygraph --profile extended

大多数用户根本不需要扩展模式。核心配置提供:

  • 记忆 CRUD:存储、获取、更新、删除、搜索(5 个工具)
  • 关系管理:创建链接、遍历图谱(2 个工具)
  • 发现功能:模糊回忆、会话简报(2 个工具)

扩展模式增加了数据库统计和复杂关系查询——对高级用户有用,但必须主动选择。

为什么我们没有放弃 MCP

1. 问题不在 MCP——而在工具膨胀

MCP 本身是一个轻量级协议。上下文成本来源于工具 定义,而不是协议本身。一个设计良好的、仅包含 9 个简洁工具的 MCP 服务器,其上下文占用远低于一个即使是 CLI 包装器也会加载的冗长 --help 输出。

2. CLI 丢失了 MCP 的生态优势

MCP 提供:

  • 跨客户端的标准化工具发现(Claude Code、Cursor、VS Code Copilot 等)
  • 一致的安装与配置方式
  • 客户端管理的工具执行与错误处理
  • 跨平台支持,无需额外包装脚本

转向 CLI 意味着需要为每个编码代理维护独立的集成、在不同环境下分别处理身份验证,并失去日益壮大的 MCP 生态系统。

3. 图关系是我们的价值主张

CLI 接口只能实现扁平的文档式存储。MemoryGraph 的强大之处在于 类型化关系

[timeout_fix] --CAUSES--> [memory_leak] --SOLVED_BY--> [connection_pooling]

查询:“关于重试逻辑发生了什么?”会返回完整的因果链——这是扁平存储难以高效实现的。

简洁的工具描述:我们如何保持轻量

冗长(典型)

recall_memories: This is the recommended starting point for recalling past 
memories and learnings from your knowledge graph. This tool wraps search_memories with optimal defaults for natural language queries. When you want to search for past work, solutions, problems, patterns, or project context, use this tool first. 
It automatically uses fuzzy matching which handles plurals, tenses, and case 
variations. Results always include relationship context showing what connects to what. This is simpler than search_memories for common use cases because it has optimized default settings applied. Pass a natural language query and optionally filter by memory types or project path. Results are ranked by relevance with match quality hints included.

简洁(MemoryGraph)

recall_memories: Search memories with fuzzy matching and relationship context. 
Best starting point for "What did we learn about X?" queries. Handles plurals and tenses automatically.

功能相同,却只用了极少的令牌。

实际意义

当你把 MemoryGraph 添加到 Claude Code 时:

claude mcp add --scope user memorygraph -- memorygraph

你的代理即可拥有持久记忆和图关系,同时只消耗约 2‑3 % 的上下文——其余的上下文留给实际工作。相比之下,其他方案在你甚至还没提问之前就已经占用了 20 % 以上

我们的承诺

我们将在文档和网站中加入上下文占用跟踪。用户在安装任何 MCP 服务器之前,都能明确知道其上下文成本。

即将改进

  • 按工具配置文件公布上下文令牌计数
  • 工具描述审计,进一步压缩冗余
  • 持续坚持“最少工具,最大能力”

结论

上下文窗口问题是真实存在的,但 MCP 并非敌人。真正的敌人是工具膨胀。MemoryGraph 证明,你完全可以拥有强大的基于图的记忆与关系追踪,同时保持上下文高效。

  • 九个工具
  • 图关系
  • 2‑3 % 的上下文使用率

这就是我们找到的平衡点。

快速开始

pipx install memorygraphMCP
claude mcp add --scope user memorygraph -- memorygraph

GitHub | Documentation

MemoryGraph 是面向 AI 编码代理的开源 MCP 记忆服务器。我们相信上下文效率与强大功能并不冲突。

Back to Blog

相关文章

阅读更多 »