当你在凌晨三点调试一个 AI 智能体时，是否曾为它"失忆"而头疼——上一轮对话里它记住了什么？下一轮又该从哪里找上下文？传统的解法是 Redis 缓存 + Pinecone 向量库 + Neo4j 图数据库三件套，再配上一堆同步胶水代码。RushDB 说：不用这么复杂，一个 API 就够了。

RushDB：为 AI 智能体打造的图+向量记忆层

图1：RushDB Logo

RushDB 是一个开源的图 + 向量混合数据库，专门设计为 AI 智能体的外部记忆层。它的核心思路非常直接：推送任意 JSON，RushDB 自动完成类型推断、关系建模和向量嵌入，开发者无需设计模式、无需写迁移脚本、无需维护同步管道。截至目前，该项目在 GitHub 拥有 309 颗星，被标注为 AI、ai-agents、ai-memory、ai-tools、database、graph-database 等 10 个 Topic，表明它已被 AI 开发者社区广泛认可。

背景：AI 记忆困境

构建真正有用的 AI 智能体，远不止一个聊天窗口那么简单。智能体需要在多个会话之间保持状态、记住决策、存储工具调用结果、追踪用户偏好。业界标准方案是三库鼎立：Redis 存键值、Pinecone 或 Weaviate 存向量、Neo4j 处理图关系，再写一堆胶水代码让三者保持同步。

这种架构的问题在于：每个新项目都要重新搭一遍；一旦数据模型变了，三处都要改；向量和图查询是分离的，无法在一个请求里同时用两种能力做过滤。RushDB 的创始人 1pxone 正是厌倦了这套复杂性，决定在 Neo4j 基础上构建一个统一的记忆层。

核心技术：一张图搞定所有

RushDB 底层基于 Neo4j 图数据库，在此之上封装了一层 Labeled Meta Property Graph（LMPG）模型。理解它的设计需要一点图数据库基础，但上手却出奇简单——只需调 db.records.create() 推送一条 JSON，RushDB 自动完成以下几件事：

• 类型推断：根据数据内容自动识别属性类型（字符串、数字、布尔、数组……）
• Label 生成：将数据结构映射为对应的 Label，无需手动声明
• 关系边构建：自动从 JSON 结构中推断节点之间的关联关系，生成有向图边
• 向量嵌入：服务端自动完成 embedding，无需外部 embedder

开发者只需要关心数据本身，底层的图结构由 RushDB 在写入时实时生成和扩展。这种"写入即建模"的理念，与传统数据库的模式优先（schema-first）完全不同。

查询层面，RushDB 支持三种模式：

• 图遍历（Cypher 查询）：用 Cypher 语言做节点关系查询，擅长处理多跳关联
• 语义搜索：db.ai.search() 方法结合向量相似度与图过滤条件，一次调用搞定
• 混合查询：在同一个请求里同时使用语义相似度和图过滤，取两者交集

这种混合查询能力是 RushDB 的核心竞争力。比如："找出与我讨论过 Q4 财报的智能体，在它所有记忆中，语义上最接近'我们决定削减成本'的内容"——一条语句，图过滤 + 向量相似度同时生效。

技术架构：模块化插件体系

RushDB 采用 monorepo + pnpm workspaces 组织，核心分为以下几个包：

后端核心采用 NestJS + Fastify，性能优异且支持 OpenAPI 自动生成文档。数据层使用 Drizzle ORM 支持 PostgreSQL 和 SQLite 切换。元数据库（PostgreSQL/SQLite）存储结构化元信息，真正的图数据和向量数据由 Neo4j 负责，两者在应用层通过 neo4j-driver 和 neogma OGM 统一管理。

整个平台的部署通过 Docker Compose 组织，包含三个核心服务：Neo4j（带向量索引支持）、PostgreSQL（应用元数据）、可选的 Synx（分布式任务队列，基于 Rust）。多阶段 Dockerfile 从 node:22-alpine 构建，生产镜像精简。

快速上手：两条路径

路径一：云服务（推荐尝鲜）

npm install @rushdb/javascript-sdk
# 或
pip install rushdb

import RushDB from '@rushdb/javascript-sdk'
const db = new RushDB('YOUR_API_KEY')

// 告诉 RushDB 自动为 'output' 字段生成向量索引
await db.ai.indexes.create({ label: 'MEMORY', propertyName: 'output' })

// 写入一条智能体记忆
await db.records.create({
  label: 'MEMORY',
  data: {
    agent_id: 'agent-42',
    session_id: 'sess-001',
    topic: 'Q4 results',
    output: summaryText
  }
})

// 语义召回：图过滤 + 向量搜索
const memories = await db.ai.search({
  labels: ['MEMORY'],
  propertyName: 'output',
  query: '我们决定怎么削减 Q4 成本？',
  where: { agent_id: 'agent-42' },
  limit: 10
})

路径二：自托管（适合生产环境）

RushDB 提供了完整的 Docker Compose 配置，只需：

cd platform/core
docker compose up -d

即可启动 Neo4j + PostgreSQL + RushDB Core 三个容器。docker-compose.yml 中 Neo4j 启用了 Java Vector API 以获得最佳向量索引性能，所有配置通过环境变量管理。

适用场景

RushDB 最适合以下几类场景：

• AI 智能体记忆：多会话状态持久化、跨 agent 共享记忆
• GraphRAG：文档 + 实体 + 引用关系统一管理，向量 + 图混合检索
• AI 应用后端：CRM、客服、分析类应用的内容管理（结合 MCP 协议）
• 研究原型：快速验证 AI + 图数据库结合的场景，无需复杂建模

不支持的场景：超大规模 OLTP（没有分片）、需要强事务保证的金融系统（Neo4j 事务模型不同）。

局限与挑战

RushDB 也有不可回避的短板：

1. 学习曲线：虽然写入简单，但高级用法需要理解 Cypher 查询语言和 Neo4j 图模型，有一定门槛
2. 性能边界：单节点 Neo4j 的写入吞吐量有限，需要理解 Neo4j 的事务批处理才能优化高负载场景
3. 供应商锁定：深度依赖 Neo4j，迁移成本较高
4. License 双重标准：核心平台（platform/core）使用 Elastic License 2.0（非开源友好），SDK 包（packages/javascript-sdk）才使用 Apache 2.0
5. 无内置认证：自托管版本需要自行在 Nginx/Caddy 层配置 HTTPS 和认证

行业意义

RushDB 的出现折射出一个更大的趋势：AI-native 数据库正在从概念走向实用。传统数据库是"先有数据结构，再有查询"，而 RushDB 这类工具实践的是"先有数据意图，再有动态结构"。GraphRAG 的热度、记忆增强智能体的需求爆发，让图+向量融合存储成为 2025-2026 年 AI Infra 领域最受关注的方向之一。RushDB 309 星的增长轨迹，正是这一趋势的玩家认可证明。