openDB
wuwangzhang1216/openDB加载项目详情…
本应用为开源项目,仅供学习研究,请遵守其开源协议。
加载项目详情…
本应用为开源项目,仅供学习研究,请遵守其开源协议。
想象这样一个场景:一位 AI 开发者与 AI 助手合作开发项目,已经进行了 17 轮对话。助手突然"失忆"——它不记得第 3 轮时你们决定用 CreateInvoice 类替代 InvoiceFactory,不记得 API 端口改成了 :9090,不记得那个中间件位置在 pkg/gateway/middleware/auth.go。开发者不得不重新解释一遍又一遍。
这正是当前 AI Agent 普遍面临的长期记忆困境。Mem0、Zep、Letta 等记忆方案依赖向量数据库和 Embedding API,不仅引入额外依赖,还存在"幻觉"风险——Agent 可能检索到看似相关但实际不存在的事实。
openDB 的解题思路截然不同:用 SQLite FTS5 全文本检索替代向量搜索,记忆数据完全存储在本地,无任何外部 API 调用。这让它成为了一个"零成本、零依赖"的 Agent 记忆基础设施。
openDB 由独立开发者 wuwangzhang1216 于 2026 年 3 月创建,定位为"AI Native 本地数据库"。项目名称中的"DB"既指 Database,也隐含 DataBank(知识银行)的双关含义。
作者在 CodeMemEval 基准测试中专门设计了针对编码 Agent 记忆的评测维度,填补了现有 LongMemEval 等通用记忆评测框架忽视"代码知识"(架构决策、API 签名、Bug 修复路径)的空白。项目自发布以来保持活跃更新,截至分析时已发布 12 个版本。
openDB 的能力可以概括为三个层次:
第一层:任意文件读取。 支持 PDF、Word、Excel、PPT、图片 OCR(支持中英文),通过统一抽象层让 Agent 能访问工作区的所有内容。解析后的文本自动建立 FTS5 全文索引。
第二层:持久化记忆存储。 Agent 可以将对话中形成的知识(如"这个项目用 FastAPI 而非 Flask")写入 openDB,后续对话自动检索。不依赖任何外部 Embedding 服务,检索延迟仅 0.8ms。
第三层:MCP 协议集成。 项目提供完整的 MCP Server 实现,注册为 Agent 的标准工具。目前已支持 Claude、OpenAI、LangChain、CrewAI、AutoGen、Google ADK、Mastra 等主流 Agent 框架。
pip install open-db[cli]
opendb index ./my_workspace
opendb serve-mcp
安装完成后,Agent 立即获得 12 个 MCP 工具,包括文件读取、跨文件搜索、记忆存取、工作区切换等。Docker Compose 部署则只需 docker compose up,包含 PostgreSQL 后端和 FastAPI 服务。
Dockerfile 基于 python:3.12-slim,预装了 tesseract-ocr 及中日韩语言包。OCR 识别的中文准确率在标准 PDF 测试集上表现良好,但对于扫描版繁体文档仍有一定误差。
openDB 在 LongMemEval(ICLR 2025)基准上取得了 93.6% E2E 准确率,与依赖向量数据库的 OMEGA(95.4%)和 Mastra(94.9%)相比差距不大,但完全不需要 Embedding API——这对于数据隐私敏感或网络受限的场景意义重大。
更值得注意的是 CodeMemEval 的结果:架构决策类事实准确率 100%,API 签名检索 100%,零幻觉(从不虚构记忆)。这说明 FTS5 的精确匹配特性在代码领域恰好优于向量相似度——代码中的标识符(CreateInvoice、:9090)是精确的,不需要模糊匹配。
局限也很明显:FTS5 擅长精确匹配,但无法处理语义相似性查询(如"查找与登录相关的代码")。对于非代码类知识(如项目背景、产品决策),向量检索仍有优势。此外,当前版本不支持多租户/权限隔离,所有记忆对所有 Agent 可见。
openDB 的出现反映了一个重要趋势:AI Agent 的记忆基础设施正从云端向量库向本地 SQLite 迁移。随着 Claude Code、Cursor Agent 等产品级 Agent 工具的普及,如何让 Agent 跨会话保留知识成为刚需,而本地 SQLite 方案在隐私、成本和部署复杂度上都优于云端服务。
对于开源社区而言,openDB 提供了一个可复现的基准测试框架(CodeMemEval),这对整个 Agent Memory 研究方向都有参考价值。