Back to MCP Servers

Context Keeper

LLM-driven context and memory management with wide-recall + precise-reranking RAG architecture. Features multi-dimensional retrieval (vector/timeline/knowledge graph), short/long-term memory, and complete MCP support (HTTP/WebSocket/SSE).

knowledge-memoryllmrag
By redleaves
15010Updated 5 months agoGoMIT

Installation

npx -y context-keeper

Configuration

{
  "mcpServers": {
    "context-keeper": {
      "command": "npx",
      "args": ["-y", "context-keeper"]
    }
  }
}

How to use

  1. Run the installation command above (if needed)
  2. Open your Claude Code settings file (~/.claude/settings.json)
  3. Add the configuration to the mcpServers section
  4. Restart Claude Code to apply changes
<div align="center"> <p align="center"> <img src="docs/img/elephant.png" alt="Context-Keeper Logo" width="120"/> </p>

Context-Keeper

基于LLM驱动的智能记忆与上下文管理系统

重新定义AI助手的记忆边界,让每一次对话都有意义

<p align="center"> <a href="https://github.com/redleaves/context-keeper"><img src="https://img.shields.io/github/stars/redleaves/context-keeper?style=for-the-badge&logo=github&color=ff69b4" alt="GitHub Stars"/></a> <a href="LICENSE"><img src="https://img.shields.io/badge/License-MIT-blue.svg?style=for-the-badge" alt="License"/></a> <a href="https://golang.org/"><img src="https://img.shields.io/badge/Go-1.21+-00ADD8?style=for-the-badge&logo=go" alt="Go Version"/></a> <a href="https://github.com/modelcontextprotocol"><img src="https://img.shields.io/badge/MCP-Compatible-green?style=for-the-badge" alt="MCP Protocol"/></a> </p> <h3 align="center"> <a href="README-en.md">English</a> | 简体中文 </h3> </div>

📋 目录导航


1. AI时代的开发困境:当智能工具遇到记忆断层

"还记得昨天讨论的微服务架构方案吗?" → "抱歉,我不记得..." → 😤

📊 四维痛点:你是哪一种?

<div align="center">
👤 个人开发者👥 团队Leader🏗️ 项目经理🏢 企业高管
💔 核心痛点🔄 每天重复解释项目背景给AI<br/>🧠 上下文丢失:AI无法理解开发意图<br/>🌀 重复劳动:相似问题反复解决📚 知识断层:老员工经验无法传承<br/>💬 沟通成本高:反复解释相同问题<br/>🚫 决策延迟:缺乏历史上下文参考🔧 技术债务:历史决策原因不明<br/>⏱️ 项目延期:新人上手周期长<br/>📋 文档滞后:代码与文档不同步💸 人才流失:核心知识随人员离职<br/>📈 ROI下降:跨项目最佳实践难复用<br/>🎯 竞争劣势:创新速度被拖慢
⚡ 直接影响🔥30%开发时间浪费📉团队效率下降40%💰项目成本超预算2x⏰人才培养成本6-12个月
</div>

🔥 行业现状数据

  • 📊 50%开发者每天重复解释项目背景给AI助手
  • 💰 平均成本:替换一个资深工程师需要6-12个月
  • ⏱️ 时间损失:新人完全熟悉复杂项目需要3-6个月
  • 🔄 重复工作:团队中30-40%的技术问题是重复性的

核心问题:AI工具缺乏持续记忆能力,无法形成智能的知识积累和传承体系。面对这些困境,我们需要的不是另一个记忆工具,而是一个真正理解开发者意图的智能大脑。🚀 Context-Keeper:突破传统边界的智能解决方案


2. 核心特性

%%{init: {'theme':'base', 'themeVariables': {'fontSize':'16px', 'fontFamily':'Arial, sans-serif'}}}%%
graph LR
    subgraph Stage1["🔍 多维宽召回<br/>(高覆盖率)"]
        A1("语义检索<br/>TOP-50") 
        A2("时间线检索<br/>TOP-30")
        A3("知识图谱<br/>TOP-20")
        A1 --> A4("候选集<br/>~100条")
        A2 --> A4
        A3 --> A4
    end
    
    subgraph Stage2["🧠 LLM精排序<br/>(高准确率)"]
        A4 --> B1("LLM智能分析")
        B1 --> B2("质量评估")
        B2 --> B3("相关性排序")
        B3 --> B4("TOP-N<br/>精准结果")
    end
    
    subgraph Stage3["🎯 多维融合<br/>(个性化输出)"]
        B4 --> C1("语义维度")
        B4 --> C2("时间维度") 
        B4 --> C3("知识维度")
        C1 --> C4("智能融合引擎")
        C2 --> C4
        C3 --> C4
        C4 --> C5("个性化方案")
    end
    
    style Stage1 fill:#e3f2fd,stroke:#e2e8f0,stroke-width:1px,rx:8,ry:8
    style Stage2 fill:#fff3e0,stroke:#e2e8f0,stroke-width:1px,rx:8,ry:8
    style Stage3 fill:#e8f5e9,stroke:#e2e8f0,stroke-width:1px,rx:8,ry:8

🚀 三大核心突破

突破点传统方案痛点Context-Keeper解决方案核心优势
🧠 智能推理机械匹配,无法理解意图LLM深度推理:理解开发场景和项目上下文准确率75%+
⚡ 宽召回+精排序召回率与准确率矛盾两阶段架构:宽召回(100条) → 精排序(TOP-N)覆盖率80%+
🎯 多维融合单一语义检索,信息孤立三维记忆空间:语义+时间+知识图谱深度融合关联发现率3倍提升

🎯 业务价值

对开发团队的价值

应用场景开发者问题Context-Keeper智能响应价值体现
架构决策回顾"为什么选择微服务而非单体?"基于3月15日技术评审记录的详细分析🧠 历史智慧复用
Bug修复复用"类似性能问题怎么解决?"发现2个相关案例并提供解决方案经验快速复用
技术选型参考"Redis集群配置最佳实践?"项目历史配置+业界最佳实践对比🎯 决策支持优化

对企业的价值

  • 📈 开发效率提升: 减少重复性解释和讨论
  • 💰 人力成本节省: 新员工培训时间大幅度缩短
  • 🎯 决策质量提升: 基于历史经验的智能建议
  • 🔄 知识资产积累: 团队智慧的系统性沉淀

3. 架构设计

Context-Keeper目前经历了两个版本的迭代:

🧠 一期核心设计

📚 长短期记忆分层设计

  • 短期记忆:存储完整的近期对话,使用本地文件系统,保证高速访问
  • 长期记忆:存储关键信息摘要,使用向量数据库永久保存
  • 渐进式压缩:信息从短期记忆的详细记录逐步转化为长期记忆的语义摘要

👤 用户隔离与个性化

  • 会话隔离:每个用户拥有独立的会话空间,确保数据安全和隐私保护
  • 工作空间隔离:不同项目/工作空间的上下文完全隔离,避免信息串扰
  • 个性化记忆策略:根据用户工作风格自动调整记忆阈值和摘要策略
  • 跨会话知识传递:在同一用户的不同会话间建立智能关联

🔄 记忆与批次管理机制

  • 记忆ID (memoryID):用户视角的"完整记忆",对应一个工作任务或主题
  • 批次ID (batchID):系统视角的"存储单元",对应连续对话片段
  • 智能重要性评估:自动识别关键决策点,确保核心内容永久保存

🚀 二期LLM驱动升级

Context-Keeper基于LLM驱动的智能上下文记忆管理系统,在一期基础上实现了两个关键突破:

🧠 LLM驱动的宽召回+精排序架构 - 构建"意图理解 → 宽召回 → 精排序 → 智能合成"的LLM驱动架构

⭐️ 智能上下文管理 - 四维统一上下文模型+LLM驱动的全生命周期智能管理


🧠 3.1 LLM驱动的宽召回+精排序架构

🏗️ 架构图

<div align="center"> <img src="docs/img/context整体架构.png" alt="LLM驱动的宽召回+精排序架构图" style="width: 70%; max-width: 1200px; height: auto;"> </div>

⏱️ 时序图

sequenceDiagram
    participant User as 👤 用户
    participant LLM1 as 🧠 LLM阶段一
    participant MDRE as 🔍 多维检索引擎
    participant LLM2 as 🧠 LLM阶段二
    participant Context as 🌟 上下文管理
    
    User->>LLM1: "回忆项目架构设计"
    LLM1->>LLM1: 🎯 意图分析<br/>核心意图+领域上下文+应用场景
    LLM1->>MDRE: 检索策略+查询改写
    
    par 宽召回阶段
        MDRE->>MDRE: 向量检索:架构语义
        MDRE->>MDRE: 时间线检索:设计讨论
        MDRE->>MDRE: 知识图谱:架构关联
    end
    
    MDRE->>LLM2: 候选集 (~100条)
    LLM2->>LLM2: 🧠 精排序<br/>质量评估+相关性排序
    LLM2->>Context: 结构化合成
    Context->>User: ✅ 个性化架构方案

📋 架构核心特性

层级核心能力技术实现性能优势
🧠 智能层两阶段LLM协同推理意图分析+智能合成分工准确率75%
🔍 检索层多维宽召回+精排序语义+时间+图谱混合检索召回率80%+
⭐️ 管理层智能上下文管理四维协同+实时同步响应<500ms

📋 3.2 智能上下文管理

Context-Keeper构建了四维统一上下文模型作为上下文信息的载体,通过LLM驱动的智能管理机制,实现上下文从初始构建→填充完善→智能分析&更新上下文(循环往复)的全生命周期管理

核心设计

  • 🏗️ 统一上下文模型:四维协同的数据存储基石
  • 🔄 智能管理过程:LLM驱动的全生命周期管理机制
  • ⚡️ 实时变更感知:语义级别的上下文变化检测与更新

🏗️ 智能上下文管理分层架构

<div align="center"> <img src="docs/img/上下文 1.png" alt="LLM驱动的宽召回+精排序架构图" style="width: 70%; max-width: 1200px; height: auto;"> </div>

⏱️ 智能上下文管理时序

sequenceDiagram
    participant User as 👤 用户
    participant SessionMgmt as 🚀 会话管理工具
    participant RetrieveCtx as 🔍 上下文检索工具
    participant StoreConv as 💾 对话存储工具
    participant AssocFile as 📝 文件关联工具
    participant Context as ⭐️ 上下文管理
    participant LLM1 as 🧠 LLM阶段一
    participant MDRE as 🔍 多维检索
    participant LLM2 as 🧠 LLM阶段二
    participant Storage as 💾 存储层
    
    Note over User,Storage: 🆕 初始构建(首次会话)
    
    User->>SessionMgmt: session_management(get_or_create)
    SessionMgmt->>SessionMgmt: 工程感知分析<br/>技术栈·架构·依赖识别
    SessionMgmt->>Context: 触发初始构建管理
    Context->>Context: 创建ProjectContext<br/>构建统一上下文模型基础
    Context->>Storage: 持久化ProjectContext
    
    Note over User,Storage: 🔍 填充完善(首次检索)
    
    User->>RetrieveCtx: retrieve_context(query, sessionId)
    RetrieveCtx->>Context: 获取当前上下文
    Context-->>RetrieveCtx: 返回ProjectContext
    RetrieveCtx->>LLM1: 用户查询+上下文
    LLM1->>LLM1: 意图理解+查询改写
    LLM1->>MDRE: 宽召回指令
    
    par 宽召回并行检索
        MDRE->>MDRE: 向量检索
        MDRE->>MDRE: 时间线检索  
        MDRE->>MDRE: 知识图谱检索
    end
    
    MDRE->>LLM2: 候选集数据
    LLM2->>Context: 获取当前上下文进行比对
    Context-->>LLM2: ProjectContext(其他维度待填充)
    LLM2->>LLM2: 🧠 语义比对+精排序合成
    LLM2->>Context: 触发填充完善管理
    Context->>Context: 完整构建TopicCtx+ConvCtx<br/>(CodeCtx由代码变更触发)
    Context->>Storage: 持久化完整上下文模型
    RetrieveCtx->>User: 返回智能合成结果
    
    Note over User,Storage: 🔄 变更管理(后续所有交互)
    
    loop 标准SOP循环:每次MCP工具调用
        alt 检索触发
            User->>RetrieveCtx: retrieve_context(query, sessionId)
            RetrieveCtx->>Context: 获取当前上下文
            Context-->>RetrieveCtx: 完整四维上下文
            RetrieveCtx->>LLM1: 查询+上下文
            LLM1->>MDRE: 宽召回
            MDRE->>LLM2: 候选集
            LLM2->>Context: 语义比对+变更检测
        else 存储触发
            User->>StoreConv: store_conversation(messages, sessionId)
            StoreConv->>Context: 获取当前上下文
            Context->>Context: 基于当前上下文进行变更检测
        else 代码变更触发
            User->>AssocFile: associate_file(filePath, sessionId)
            AssocFile->>Context: 获取当前上下文
            Context->>Context: 结合主题上下文更新CodeContext
        end
        
        Context->>Context: 🎯 变更检测管理<br/>当前上下文 vs 新数据
        
        alt 检测到语义变更
            Context->>Context: ⚡️ 智能更新管理<br/>增量变更+冲突解决
            Context->>Storage: 持久化变更
        else 无变更
            Context->>Context: 保持当前状态
        end
        
        alt 检索触发
            RetrieveCtx->>User: 返回检索结果
        else 存储触发
            StoreConv->>User: 返回存储确认
        else 代码变更触发
            AssocFile->>User: 返回关联确认
        end
    end

🔥 管理机制核心优势

  • 统一存储基石:四维统一上下文模型作为所有管理操作的数据基础
  • 全生命周期覆盖:从初始构建→填充完善→循环变更的完整管理链路
  • LLM智能驱动:每个管理环节都有LLM参与决策,非传统规则引擎
  • 实时变更感知:基于语义分析的上下文变化检测
  • 无冲突合并:LLM驱动的智能冲突解决和优先级仲裁

4. 部署与集成

🛠️ 前置准备

在部署Context-Keeper之前,需要准备以下基础设施:

📊 多维存储基础设施

1. 向量数据库(必需)

我们设计了统一的向量存储接口,可按照开发者/企业需要自行扩展,支持多种向量数据库:

  • 阿里云DashVector:可在阿里云控制台快速申请
  • 京东云Vearch:可在京东云快速申请
  • 自定义实现扩展:基于统一接口可扩展实现其他向量存储(如Milvus、Weaviate等)
# 配置示例(二选一)
# 选项1:使用阿里云DashVector
VECTOR_STORE_TYPE=aliyun
VECTOR_DB_URL=https://your-instance.dashvector.cn-hangzhou.aliyuncs.com
VECTOR_DB_API_KEY=your-dashvector-api-key

# 选项2:使用京东云Vearch  
VECTOR_STORE_TYPE=vearch
VEARCH_URL=http://your-vearch-instance.jd.local
VEARCH_USERNAME=your-username
VEARCH_PASSWORD=your-password

2. 时序数据库(必须)

自行安装:TimescaleDB/PostgreSQL(用于时间线存储)

3. 图数据库(必须)

自行安装:Neo4j(用于知识图谱和关联分析)

4. LLM模型配置(必须)

我们支持本地和云端大模型配置,灵活满足不同场景需求

🏠 本地模型(推荐)

  • 基于Ollama框架,响应快、成本低、数据安全
  • 安装Ollama:curl -fsSL https://ollama.ai/install.sh | sh
  • 按需安装模型:ollama pull deepseek-coder-v2:16b
  • 支持模型:CodeQwen、DeepSeek Coder、Llama等

☁️ 云端模型(备用)

  • 申请对应LLM厂商的API密钥即可
  • 支持:OpenAI、DeepSeek、Claude、通义千问等
  • 配置简单,按需调用

5分钟快速开始

环境要求

  • Go 1.21+
  • 4GB+ 内存
  • 支持Docker环境(可选)

一键本地部署

# 1. 获取Context-Keeper
git clone https://github.com/redleaves/context-keeper.git
cd context-keeper

# 2. 环境配置(重要!)
cp config/env.template config/.env

# 编辑配置文件,填入必要参数
vim config/.env

⚙️ 详细参数配置

真实配置文件说明

基于项目实际的 config/.env 配置文件:

# =================================
# 基础服务配置
# =================================
SERVICE_NAME=context-keeper         # 服务名称
PORT=8088                          # HTTP服务端口
DEBUG=false                        # 调试模式
STORAGE_PATH=./data                # 数据存储路径

# =================================
# 向量存储配置(必需)
# =================================
# 向量存储类型: aliyun | vearch
VECTOR_STORE_TYPE=aliyun           # 支持阿里云DashVector和京东云Vearch

# 阿里云DashVector配置
VECTOR_DB_URL=https://your-instance.dashvector.cn-hangzhou.aliyuncs.com
VECTOR_DB_API_KEY=your-dashvector-api-key
VECTOR_DB_COLLECTION=context_keeper
VECTOR_DB_DIMENSION=1536
SIMILARITY_THRESHOLD=0.4

# 京东云Vearch配置(可选替代)
VEARCH_URL=http://your-vearch-instance.jd.local
VEARCH_USERNAME=root
VEARCH_PASSWORD=your-password
VEARCH_DATABASE=db
VEARCH_REQUIRED_SPACES=context_keeper_vector,context_keeper_users

# =================================
# Embedding服务配置(必需)
# =================================
EMBEDDING_API_URL=https://dashscope.aliyuncs.com/compatible-mode/v1/embeddings
EMBEDDING_API_KEY=your-dashscope-api-key

# 批量Embedding配置
BATCH_EMBEDDING_API_URL=https://dashscope.aliyuncs.com/api/v1/services/embeddings/text-embedding/text-embedding
BATCH_QUEUE_SIZE=100
BATCH_WORKER_POLL_INTERVAL=5s

# =================================
# LLM配置(重点:支持本地和云端模型)
# =================================
# 🌟 支持本地和云端模型,本地模型响应快、灵活,适合语义分析和识别
LLM_PROVIDER=ollama_local          # 默认使用本地模型
LLM_MODEL=deepseek-coder-v2:16b    # 本地代码理解模型
LLM_MAX_TOKENS=80000               # 最大Token数
LLM_TEMPERATURE=0.1                # 温度参数(精确分析)
LLM_TIMEOUT_SECONDS=600            # 超时时间

# 云端模型API Keys(备用)
DEEPSEEK_API_KEY=your-deepseek-key  # DeepSeek云端API
OPENAI_API_KEY=your-openai-key      # OpenAI API
CLAUDE_API_KEY=your-claude-key      # Claude API


# 时间线存储(TimescaleDB/PostgreSQL)
TIMELINE_STORAGE_ENABLED=true
TIMESCALEDB_HOST=lo

…
View source on GitHub