redleaves/context-keeper

**基于LLM驱动的智能记忆与上下文管理系统**
*重新定义AI助手的记忆边界，让每一次对话都有意义*
English | 简体中文
---
📋 **目录导航**
- 🎯 为什么选择Context-Keeper？
- 🎯 核心特性
- 🏗️ 架构设计
- 📖 部署与集成
- 🗺️ 产品发展路线图
- 🤝 贡献指南
---
1. AI时代的开发困境：当智能工具遇到记忆断层
> **"还记得昨天讨论的微服务架构方案吗？"** → "抱歉，我不记得..." → 😤
📊 **四维痛点：你是哪一种？**
| | 👤 **个人开发者** | 👥 **团队Leader** | 🏗️ **项目经理** | 🏢 **企业高管** |
|------|-----------------|----------------|----------------|----------------|
| **💔 核心痛点** | 🔄 **每天重复解释**项目背景给AI 🧠 **上下文丢失**：AI无法理解开发意图 🌀 **重复劳动**：相似问题反复解决 | 📚 **知识断层**：老员工经验无法传承 💬 **沟通成本高**：反复解释相同问题 🚫 **决策延迟**：缺乏历史上下文参考 | 🔧 **技术债务**：历史决策原因不明 ⏱️ **项目延期**：新人上手周期长 📋 **文档滞后**：代码与文档不同步 | 💸 **人才流失**：核心知识随人员离职 📈 **ROI下降**：跨项目最佳实践难复用 🎯 **竞争劣势**：创新速度被拖慢 |
| **⚡ 直接影响** | **🔥30%开发时间浪费** | **📉团队效率下降40%** | **💰项目成本超预算2x** | **⏰人才培养成本6-12个月** |
🔥 **行业现状数据**
- 📊 **50%开发者**每天重复解释项目背景给AI助手
- 💰 **平均成本**：替换一个资深工程师需要6-12个月
- ⏱️ **时间损失**：新人完全熟悉复杂项目需要3-6个月
- 🔄 **重复工作**：团队中30-40%的技术问题是重复性的
**核心问题**：AI工具缺乏持续记忆能力，无法形成智能的知识积累和传承体系。面对这些困境，我们需要的不是另一个记忆工具，而是一个真正理解开发者意图的智能大脑。🚀 **Context-Keeper：突破传统边界的智能解决方案**
---
2. 核心特性
🚀 **三大核心突破**
| 突破点 | 传统方案痛点 | **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驱动的宽召回+精排序架构**
**🏗️ 架构图**
**⏱️ 时序图**
**📋 架构核心特性**
| 层级 | 核心能力 | 技术实现 | 性能优势 |
|------|---------|---------|---------|
| **🧠 智能层** | 两阶段LLM协同推理 | 意图分析+智能合成分工 | **准确率75%** |
| **🔍 检索层** | 多维宽召回+精排序 | 语义+时间+**图谱混合检索** | **召回率80%+** |
| **⭐️ 管理层** | 智能上下文管理 | 四维协同+实时同步 | **响应
**⏱️ 智能上下文管理时序**
**🔥 管理机制核心优势**：
- ✅ **统一存储基石**：四维统一上下文模型作为所有管理操作的数据基础
- ✅ **全生命周期覆盖**：从初始构建→填充完善→循环变更的完整管理链路
- ✅ **LLM智能驱动**：每个管理环节都有LLM参与决策，非传统规则引擎
- ✅ **实时变更感知**：基于语义分析的上下文变化检测
- ✅ **无冲突合并**：LLM驱动的智能冲突解决和优先级仲裁
---
4. 部署与集成
🛠️ **前置准备**
在部署Context-Keeper之前，需要准备以下基础设施：
**📊 多维存储基础设施**
**1. 向量数据库（必需）**
我们设计了统一的向量存储接口，**可按照开发者/企业需要自行扩展**，支持多种向量数据库：
- **阿里云DashVector**：可在阿里云控制台快速申请
- **京东云Vearch**：可在京东云快速申请
- **自定义实现扩展**：基于统一接口可扩展实现其他向量存储（如Milvus、Weaviate等）
**2. 时序数据库（必须）**
自行安装：**TimescaleDB/PostgreSQL**（用于时间线存储）
**3. 图数据库（必须）**
自行安装：**Neo4j**（用于知识图谱和关联分析）
**4. LLM模型配置（必须）**
我们支持本地和云端大模型配置，**灵活满足不同场景需求**：
**🏠 本地模型（推荐）**
- 基于**Ollama**框架，响应快、成本低、数据安全
- 安装Ollama：curl -fsSL https://ollama.ai/install.sh | sh