Coder DB - AI Memory Enhancement System

Coder DB - AI Memory Enhancement System

一个结构化记忆系统，通过数据库集成，利用 Claude Desktop 和 MCP 服务增强 AI 助手的编码能力。

概述

该系统利用多种数据库类型，为编码辅助构建全面的记忆系统：

1. Qdrant Vector Database：用于对代码模式进行语义搜索和检索
2. SQLite Database：用于结构化算法存储和版本管理
3. Knowledge Graph：用于表示编码概念之间的关系

数据库使用指南

Qdrant Memory Storage

用于根据语义存储和检索代码片段、模式及解决方案。

存储内容：

• 带有说明的可复用代码模式
• 复杂问题的解决方案
• 最佳实践和设计模式
• 文档片段和说明

增强元数据：

• 语言和框架详情
• 复杂度级别（简单、中级、高级）
• 依赖项和要求
• 质量指标（圈复杂度、文档覆盖率）
• 用户反馈和评分

使用示例：

# Storing a code pattern
information = {
    "type": "code_pattern",
    "language": "python",
    "name": "Context Manager Pattern",
    "code": "class MyContextManager:\n    def __enter__(self):\n        # Setup code\n        return self\n    def __exit__(self, exc_type, exc_val, exc_tb):\n        # Cleanup code\n        pass",
    "explanation": "Context managers provide a clean way to manage resources like file handles.",
    "tags": ["python", "resource management", "context manager"],
    "complexity": "intermediate",
    "quality_metrics": {
        "cyclomatic_complexity": 2,
        "documentation_coverage": 0.85
    },
    "user_rating": 4.5
}
# Store in Qdrant

SQLite Algorithm Database

用于维护具有完善版本管理的结构化算法目录。

数据库架构：

• algorithms：算法基本信息（名称、描述）
• algorithm_versions：算法实现的不同版本
• algorithm_categories：类别，例如排序、搜索、图等
• performance_metrics：不同实现的性能数据
• improvements：跟踪不同版本之间的改进
• change_logs：包含理由和上下文的详细变更日志

版本差异比较：

• 存储算法版本之间的差异
• 跟踪不同版本间的性能改进
• 记录变更背后的原因

查询示例：

-- Find all sorting algorithms with performance metrics
SELECT a.name, a.description, v.version_number, p.time_complexity, p.space_complexity
FROM algorithms a
JOIN algorithm_versions v ON a.id = v.algorithm_id
JOIN performance_metrics p ON v.id = p.version_id
JOIN algorithm_category_mapping m ON a.id = m.algorithm_id
JOIN algorithm_categories c ON m.category_id = c.id
WHERE c.name = 'Sorting'
ORDER BY a.name, v.version_number DESC;

-- Get change logs for a specific algorithm
SELECT v.version_number, c.change_description, c.rationale, c.created_at
FROM algorithm_versions v
JOIN change_logs c ON v.id = c.version_id
WHERE v.algorithm_id = 5
ORDER BY v.version_number;

Knowledge Graph Integration

用于表示编码概念、模式和解决方案之间的复杂关系。

高级本体：

• 算法
• 设计模式
• 代码概念
• 问题类型
• 解决方案
• 框架
• 库
• 语言

丰富的关系类型：

• IMPLEMENTS（Algorithm → CodeConcept）
• SOLVES（DesignPattern → ProblemType）
• OPTIMIZES（Algorithm → Performance）
• RELATED_TO（Any → Any）
• IMPROVES_UPON（Solution → Solution）
• ALTERNATIVELY_SOLVES（Solution → ProblemType）
• EXTENDS（Pattern → Pattern）
• DEPENDS_ON（Solution → Library）
• COMPATIBLE_WITH（Framework → Language）

图分析：

• 识别频繁共同出现的模式
• 发现编码实践中的新兴趋势
• 将问题领域映射到解决方案方法

使用工作流

1. 增强的问题解决工作流

遇到新的编码问题时：

1. 收集上下文：

   • 清楚地定义问题和约束条件
   • 确定性能要求和环境详情
   • 记录项目特定的注意事项

2. 查询记忆：

   • 使用顺序思维拆解问题
   • 在 Qdrant 中查询相似解决方案：qdrant-find-memories("efficient way to traverse binary tree")
   • 按语言、复杂度和质量指标筛选结果
   • 在算法数据库中检查相关算法：SELECT * FROM algorithms WHERE name LIKE '%tree%'
   • 在知识图谱中探索相关概念和替代方法

3. 应用解决方案：

   • 在 REPL 中测试并验证解决方案
   • 记录性能特征
   • 与其他方案进行比较

4. 反馈循环：

   • 将成功的解决方案连同详细元数据存回 Qdrant
   • 记录性能指标和使用上下文
   • 更新知识图谱中的关联

2. 模式学习与存储

发现有用的模式时：

1. 自动生成文档：

   • 使用 AI 工具生成初始文档
   • 包含详细的使用示例
   • 记录边缘情况和限制

2. 质量评估：

   • 运行代码检查工具和静态分析器，确保代码质量
   • 计算并存储质量指标
   • 根据最佳实践进行验证

3. 丰富元数据：

   • 通过清晰的示例记录模式
   • 添加全面的元数据（语言、复杂度、依赖项）
   • 使用受控词表统一标记

4. 知识集成：

   • 在 Qdrant 中使用适当的标签和说明进行存储
   • 创建与相关概念的知识图谱连接
   • 如果是算法实现，则添加到 SQL 数据库
   • 根据内容相似度建议自动建立关联

3. 项目设置与样板代码

开始新项目时：

1. 选择模板：

   • 从项目模板库中选择
   • 根据项目需求进行自定义
   • 选择语言、框架和测试工具

2. 自动设置：

   • 生成具有适当目录布局的项目结构
   • 使用适当的 .gitignore 设置版本控制
   • 配置代码检查和代码质量工具
   • 初始化测试框架

3. 集成最佳实践：

   • 查询记忆系统，获取相关样板代码
   • 获取适用于特定项目类型的最佳实践
   • 使用已存储的文档模板进行初始设置
   • 根据项目需求配置 CI/CD

安全与数据完整性

1. 访问控制：

   • 对敏感代码仓库实施基于角色的访问控制
   • 设置查看与修改记忆的权限

2. 备份与恢复：

   • 定期备份 Qdrant 和 SQLite 数据库
   • 对知识图谱进行版本控制
   • 制定数据损坏后的恢复流程

3. 敏感信息：

   • 清理代码示例，移除敏感数据
   • 存储前验证代码片段
   • 标记敏感模式并限制其访问权限

监控与分析

1. 使用情况跟踪：

   • 监控最常检索的模式
   • 跟踪搜索查询模式，找出知识缺口
   • 记录用户评分和反馈

2. 性能指标：

   • 监控数据库响应时间
   • 跟踪内存使用情况和扩展需求
   • 根据使用模式优化查询

维护指南

1. 质量优先于数量：仅存储高质量且文档完善的代码
2. 定期审核：定期审核并更新已存储的模式
3. 上下文存储：为每个已存储的模式添加使用上下文
4. 版本管理：在 SQLite 中跟踪改进和版本
5. 标签一致性：使用受控词表，以便更好地检索
6. 性能优化：定期优化数据库查询
7. 整合反馈：根据使用反馈更新模式

开始使用

1. 存储你的第一条代码记忆：

   qdrant-store-memory(json.dumps({
       "type": "code_pattern",
       "name": "Python decorator pattern",
       "code": "def my_decorator(func):\n    def wrapper(*args, **kwargs):\n        # Do something before\n        result = func(*args, **kwargs)\n        # Do something after\n        return result\n    return wrapper",
       "explanation": "Decorators provide a way to modify functions without changing their code.",
       "tags": ["python", "decorator", "metaprogramming"],
       "complexity": "intermediate"
   }))
   

2. 稍后检索：

   qdrant-find-memories("python decorator pattern")
   

后续增强

• 存储前进行高级代码质量评估
• 与版本控制系统集成
• 从使用模式中学习，以改进检索
• 自动生成文档
• 提供自定义 IDE 插件，实现无缝访问
• 多模态存储（代码、图表、说明）
• 使用自然语言界面进行查询
• 性能基准数据库
• MCP 服务和数据库的安装脚本

MCP 服务

MCP（Model Context Protocol）服务为 AI 模型提供标准化接口，以便与 Coder DB 记忆系统交互。它基于 FastAPI 和 Uvicorn 构建。

项目结构（mcp_server/）

mcp_server 目录包含 FastAPI 应用：

mcp_server/
├── core/                 # Core logic, Pydantic models, configuration
│   ├── __init__.py
│   ├── config.py         # Application settings
│   └── models.py         # Pydantic data models
├── database/             # Database connectors and SQLAlchemy models
│   ├── __init__.py
│   ├── qdrant_connector.py # Logic for Qdrant vector database
│   ├── sqlite_connector.py # Logic for SQLite relational database
│   └── sql_models.py     # SQLAlchemy ORM models for SQLite
├── routers/              # FastAPI routers for different API endpoints
│   ├── __init__.py
│   ├── algorithm.py      # Endpoints for /algorithm
│   ├── health.py         # Endpoint for /health
│   └── memory.py         # Endpoints for /memory
├── tests/                # Unit and integration tests
│   ├── __init__.py
│   ├── test_algorithm_api.py
│   ├── test_health.py
│   └── test_memory_api.py
├── main.py               # Main FastAPI application setup and startup
└── pyproject.toml        # Project dependencies and metadata (using Poetry)

（注意：requirements.txt 属于旧版设置；如果仅使用 pyproject.toml 和 Poetry，则可以移除。）

设置与运行

本项目使用 Poetry 管理依赖项和打包。

1. 安装 Poetry（如果尚未安装）： 按照 Poetry 网站上的说明进行操作。

2. 安装依赖项： 前往包含 pyproject.toml 的目录（如果你将 mcp_server 创建为独立的 Poetry 项目，则应为 mcp_server 目录；如果 mcp_server 是更大 Poetry 项目的子包，则应为此仓库的根目录），然后运行：

   poetry install --with dev # --with dev includes testing dependencies
   

   这将创建虚拟环境（如果此项目尚无虚拟环境），并安装所有依赖项。

3. 环境配置（可选，但建议配置）： 应用使用 mcp_server/core/config.py 中定义的设置。你可以在运行 uvicorn 的同一目录中创建 .env 文件来覆盖这些设置（通常是仓库根目录，或者从 mcp_server/ 目录运行时的该目录）。 .env 文件内容示例：

   # mcp_server/.env or project_root/.env
   # QDRANT_HOST="your_qdrant_host_if_not_localhost" # Overrides default 'localhost'
   # QDRANT_PORT=6334                               # Overrides default 6333
   # QDRANT_API_KEY="your_qdrant_api_key_if_any"
   # SQLITE_DATABASE_URL="sqlite+aiosqlite:///./custom_mcp_data.db" # Overrides default ./mcp_server.db
   # SQLITE_ECHO_LOG=True                           # To see SQLAlchemy logs
   

   请参阅 mcp_server/core/config.py，了解所有可用设置。

4. 运行开发服务器： 确保 Poetry 环境处于激活状态（例如，在包含 pyproject.toml 的目录中运行 poetry shell），或在命令前加上 poetry run。 在仓库根目录（即包含 mcp_server 文件夹的目录）中运行：

   poetry run uvicorn mcp_server.main:app --reload --host 0.0.0.0 --port 8000
   

   服务器将在 http://127.0.0.1:8000 上提供服务。

   • 交互式 API 文档（Swagger UI）：http://127.0.0.1:8000/docs
   • 备用 API 文档（ReDoc）：http://127.0.0.1:8000/redoc

运行测试

安装开发依赖项后（poetry install --with dev）： 在仓库根目录中运行：

poetry run pytest

这将发现并运行位于 mcp_server/tests/ 目录中的测试。

API 端点

服务器目前公开以下主要 API 端点。如需查看详细的请求／响应模型并试用这些端点，请在服务器运行时访问 /docs URL。

• 系统端点（标签：System）

  • GET /：提供服务器的基本信息。
  • GET /health：简单的健康检查端点。返回 {"status": "OK"}。

• 记忆管理端点（标签：Memory Management，前缀：/memory）

  • POST /memory/store：将新的记忆项（例如代码模式、解决方案、文档片段）存储到 Qdrant 向量数据库中。
    • 请求正文：StoreMemoryRequest（包含 MemoryItem 的 JSON 对象）。
    • 响应：StoreMemoryResponse（包含已存储项的 ID 和状态的 JSON 对象）。
  • POST /memory/find：根据自然语言查询和／或筛选条件，在 Qdrant 中搜索记忆项。
    • 请求正文：FindMemoryRequest（包含查询字符串、数量上限，以及语言、标签、复杂度等可选筛选条件的 JSON 对象）。
    • 响应：FindMemoryResponse（包含匹配的 MemoryItem 列表及数量的 JSON 对象）。

• 算法管理端点（标签：Algorithm Management，前缀：/algorithm）

  • POST /algorithm/store：将新算法或现有算法的新版本存储到 SQLite 数据库中。
    • 请求正文：StoreAlgorithmRequest（包含 Algorithm 数据及其版本的 JSON 对象）。
    • 响应：StoreAlgorithmResponse（包含已存储／更新算法的 ID 和状态的 JSON 对象）。
  • POST /algorithm/find：按名称或类别搜索 SQLite 数据库中的算法。
    • 请求正文：FindAlgorithmRequest（包含可选的 name 和 category 字段的 JSON 对象）。
    • 响应：FindAlgorithmResponse（包含匹配的 Algorithm 列表及数量的 JSON 对象）。

• 集合管理端点（标签：Collection Management，前缀：/coder/collections）

  • POST /coder/collections/create：创建新的 Qdrant 集合。
    • 请求正文：CreateCollectionRequest（包含 collection_name 和可选 model_name 的 JSON 对象）。如果省略 model_name，则使用服务器配置中指定的默认嵌入模型。模型名称和向量大小会存储在集合元数据中。
    • 响应：确认消息，其中包含集合名称以及已应用的嵌入模型信息。
  • GET /coder/collections/{collection_name}/info：获取特定 Qdrant 集合的信息，包括其配置和关联的嵌入模型元数据。
    • 路径参数：collection_name。
    • 响应：包含集合详情（状态、点／向量数量、配置）和嵌入模型元数据的 JSON 对象。

嵌入管理

服务器现在使用实际的文本嵌入（通过 FastEmbed 库）在 Qdrant 中存储和搜索记忆。

• 默认模型：服务器配置了一个默认嵌入模型（例如，sentence-transformers/all-MiniLM-L6-v2）。如果未指定特定模型，则使用该模型的维度作为新集合的默认向量大小。
• 集合专用模型：通过 /coder/collections/create 端点创建集合时，可以指定其他受支持的 FastEmbed 模型。所选模型的名称及其特定向量维度将与该集合关联，并存储在其元数据中。配置该集合在 Qdrant 中的向量参数时将使用此维度。
• 动态嵌入：存储或搜索记忆时：
  • 系统通过检查目标 Qdrant 集合的元数据，确定正确的嵌入模型（及其向量维度）。
  • 如果在缺少此特定模型元数据的集合中存储或搜索记忆（例如，在外部创建或在实现此功能之前创建的集合），则使用服务器配置的默认嵌入模型及其维度。
  • 如果 store_memory 操作的目标集合不存在，则会尝试使用 create_coder_collection 创建该集合。如果未为此隐式创建指定模型，则新集合将应用默认模型及其设置。
  • 随后，实际文本（例如，来自 memory_item.explanation 和/或 memory_item.code 的文本）将使用确定的提供程序进行嵌入，然后发送到 Qdrant。
• 支持的模型：EnhancedEmbeddingModelManager 预定义了一个受支持的 FastEmbed 模型及其属性列表。此列表可以扩展。

知识图谱（Neo4j）集成（初始版本）

服务器现在初步集成了 Neo4j 作为知识图谱数据库。这是第三种核心数据库类型，可用于表示和查询编码概念、已存储记忆项与算法之间的复杂关系。

• 用途：

  • 对“记忆项 X 使用语言 Y”“算法 Z 是概念 A 的一种类型”“概念 B 与概念 C 相关”等关系进行建模。
  • 实现对已存储知识更高级的上下文理解、发现和导航。
  • 为未来的分析功能奠定基础（例如，识别连接紧密的概念，基于图路径推荐相关记忆）。

• 设置要求：

  • 运行中的 Neo4j 实例（建议使用 4.4 或 5.x 版本，以支持约束中的 IF NOT EXISTS 子句）。
  • 必须在 mcp_server/core/config.py 中或通过环境变量（例如，NEO4J_URL、NEO4J_USER、NEO4J_PASSWORD、NEO4J_DATABASE_NAME）配置连接参数（URL、用户名、密码、数据库名称）。默认值为 bolt://localhost:7687，用户名为 neo4j，密码为 password，数据库为 neo4j。
  • neo4j Python 驱动程序（例如，neo4j>=5.17.0）现在是项目依赖项（参见 pyproject.toml）。

• 初始化：

  • 应用程序启动时，服务器会初始化一个异步 Neo4j 驱动程序。
  • 服务器还会尝试创建基本架构约束，以确保关键节点属性的唯一性（例如，KGConcept.name、KGMemory.memory_id、KGAlgorithm.algorithm_id）。这些操作具有幂等性。

• 当前知识图谱架构节点（初始定义）：

  • :KGConcept：表示抽象概念。
    • 属性：name（字符串，唯一）、type（字符串，例如 'language'、'framework'、'tag'、'methodology'、'algorithm_category'、'memory_type'）、description（可选字符串）、created_at（日期时间）。
  • :KGMemory：表示已存储在 Qdrant 中并关联到图谱的 MemoryItem。
    • 属性：memory_id（字符串，唯一，通常是 Qdrant 点 ID 或内部 UUID）、name（字符串，记忆项名称）、type（字符串，记忆项类型，例如 'code_pattern'）、created_at（日期时间）。
  • :KGAlgorithm：表示存储在 SQLite 中并关联到图谱的 Algorithm。
    • 属性：algorithm_id（整数，唯一，来自 SQLite 主键）、name（字符串）、category（字符串）、created_at（日期时间）。

• 关系（初始定义）：

  • 记忆项使用通用关系 [:KG_RELATED_TO {type: "SPECIFIC_REL_TYPE"}] 与概念关联。关系上的 type 属性用于存储语义含义。示例：
    • (:KGMemory)-[:KG_RELATED_TO {type: "USES_LANGUAGE"}]->(:KGConcept {name: "Python"})
    • (:KGMemory)-[:KG_RELATED_TO {type: "TAGGED_WITH"}]->(:KGConcept {name: "asyncio"})
    • (:KGMemory)-[:KG_RELATED_TO {type: "IS_OF_TYPE"}]->(:KGConcept {name: "code_pattern"})

• 知识图谱 API 端点（前缀：/kg）：

  • POST /kg/concept：创建或合并一个 :KGConcept 节点。
    • 请求正文：KGConcept 模型（name、type、description）。
    • 响应：已创建或合并概念的详细信息。
  • POST /kg/link_memory_to_concept：将记忆项关联到概念。如果 :KGMemory 和 :KGConcept 节点不存在，则创建这些节点，然后创建或合并关系。
    • 请求正文：LinkMemoryToConceptRequest（memory_id、memory_name、memory_type、concept_name、concept_type、relationship_type）。
    • 响应：关联确认信息。
  • GET /kg/memory_item/{memory_id}/related_concepts：获取与给定 :KGMemory 节点（由 memory_id 标识）直接关联的所有 :KGConcept 节点，以及关系类型。
    • 响应：概念列表，包含其名称、类型、描述和关系类型。

• 自动更新知识图谱：

  • 通过 POST /memory/store 端点存储新的 MemoryItem 时：
    1. 使用来自 Qdrant 的 memory_id，在 Neo4j 中创建或合并相应的 :KGMemory 节点。
    2. 为记忆项的 language（如果存在）、每个 tags 以及其自身的 type（例如 'code_pattern'）创建或合并 :KGConcept 节点。
    3. 然后使用适当的 KG_RELATED_TO 关系将 :KGMemory 节点关联到这些 :KGConcept 节点（例如，使用 type: "USES_LANGUAGE"、type: "TAGGED_WITH"、type: "IS_OF_TYPE"）。
  • 这样，新增记忆在加入知识图谱时便会自动获得上下文关联。

此初始 Neo4j 集成为构建更复杂的知识表示和基于图的查询能力奠定了基础，正如 Coder DB 愿景中所述。未来的工作将包括扩展架构、添加更多关系类型、将算法集成到图谱中，以及开发更复杂的分析查询。