用 BlitzGraph 做 AI Agent 的图数据库后端：从连接到 MCP 实战
场景：Agent 需要一个真正的后端
你的 AI 编码 Agent 正在构建一个稍微复杂的应用——用户管理系统，支持多角色、多租户、带权限和关联数据。你用 Claude Code 写了几百行 SQL，建了六七张表，外键、联合查询、N+1 问题一个个冒出来。Agent 生成 SQL 字符串时偶尔拼错表名，查出来的数据要么少字段要么多字段。你开始想：有没有一种后端，是为 Agent 设计的，而不是强迫 Agent 去理解关系型数据库的范式？
这正是 BlitzGraph 要解决的问题。
传统方案 vs BlitzGraph
| 传统 SQL + ORM | Supabase / PostgREST | BlitzGraph | |
|---|---|---|---|
| 查询方式 | Agent 生成 SQL 字符串（易出错） | REST 层 + 表映射 | Agent 构建类型化 JSON 查询对象 |
| 关系处理 | JOIN 语句（N+1 陷阱） | 需手动嵌套 | 双向 O(1) 关系，原生 $expand |
| 多态存储 | 多表 + 外键 | 视图 + 映射 | 多 Kind 实体（单实体多类型） |
| 实体演化 | 改表结构、迁移脚本 | 改表结构 | 实体动态改变 Kind |
| MCP 支持 | 需自建 MCP 包装 | 需自建 | 内置 MCP Server |
什么是 BlitzGraph
BlitzGraph 是一个为 AI Agent 设计的原生图数据库。它不是一个「套了 GraphQL 的 SQL 数据库」，而是一个从底层就围绕「Agent 如何读数据、写数据、理解数据模型」设计的存储引擎。核心概念是 BlitzStore——一个多态图数据库，用类型化 JSON 查询语言（BQL）取代 SQL，让 Agent 构造查询对象而非拼写 SQL 字符串。
多 Kind 实体（Multi-Kind Entities）
这是 BlitzGraph 最有特色的设计。一个实体可以同时属于多个类型，并在生命周期中改变类型——不需要改表结构：
// 第 1 天：新客户
{ "$id": "acme-corp", "$kinds": ["Company", "Prospect"],
"deal": 50000 }
// 第 7 天：签约客户
{ "$id": "acme-corp", "$kinds": ["Company", "Customer"],
"contract": "ENTERPRISE", "signedAt": "..." }
// 第 86 天：流失客户
{ "$id": "acme-corp", "$kinds": ["Company", "Churned"],
"churnCause": "pricing" }
同一个 acme-corp，在不同阶段拥有不同属性——不需要 ALTER TABLE，不需要迁移脚本，不需要把一张表拆成三张。Agent 在构建这种查询时，只需指定 $kinds 数组，BlitzGraph 引擎自动处理底层存储。
双向 O(1) 关系
在传统数据库中，who wrote this post? 和 what did this user write? 是两个不同的查询：一个通过外键正向查找，一个通过反向索引或 JOIN。BlitzGraph 的所有关系都是双向且同代价的——正向和反向都是 O(1) 操作：
{
"$kind": "Post",
"title": "BlitzGraph 入门",
"author": { "$link": "user-123" }
}
查询时，$expand 自动追踪关系链，不管正向反向：
// 查用户写了什么
{ "$kind": "User", "$id": "user-123", "$expand": { "posts": {} } }
// 查文章的作者
{ "$kind": "Post", "$id": "post-456", "$expand": { "author": {} } }
BQL：类型化 JSON 查询
让 Agent 写 SQL 是一种折磨——拼接字符串、猜结果形状、处理转义。BQL（Blitz Query Language）让 Agent 构造 JSON 对象作为查询：
{
"filter": { "status": "active" },
"sort": { "createdAt": -1 },
"expand": {
"author": { "project": ["name", "email"] }
},
"project": ["title", "body", "createdAt"]
}
每个字段都是确定的 JSON 结构，没有注入风险，没有 parse 歧义。Agent 的代码生成器直接拼装对象，而不是字符串。
从 MCP 连接 BlitzGraph
BlitzGraph 内置 MCP Server 支持，一行命令就能让 Claude Code 或 Codex CLI 连接到你的图数据库：
claude mcp add --transport http blitzgraph https://blitzgraph.com/mcp codex mcp add blitzgraph --url https://blitzgraph.com/mcp
连接后，Agent 可以：
- 自动发现数据库 Schema
- 执行 BQL 查询读数据
- 执行批量 Mutation 写数据
- 创建和管理 Subspace（数据隔离空间）
认证体系
BlitzGraph 使用两层 Token 体系：
- Grant Token（
bzt_前缀）：通过 BlitzGraph 控制面板签发，用于数据面查询 - System Key：内部控制面密钥，仅用于管理路由
当 Agent 通过 MCP 连接时，自动使用当前用户的 Grant Token。Token 可在控制面板中随时轮换或吊销。
深度特性
内建全文搜索
不需要部署 Elasticsearch。BlitzGraph 内置 BM25 全文检索引擎，支持前缀匹配、精确匹配、词干匹配，且能在图遍历中直接使用：
{
"$kind": "Document",
"filter": { "$text": "graph database agent" }
}
业务逻辑在数据库层
验证规则、计算字段、转换函数和副作用都可以定义在 Schema 中，而不是分散在中间件和应用代码中：
{
"validations": {
"email": { "$type": "EMAIL" },
"age": { "$type": "INT", "$min": 0, "$max": 150 }
},
"computed": {
"fullName": { "$expr": { "$concat": ["$firstName", " ", "$lastName"] } }
}
}
引用完整性
BlitzGraph 在引擎层强制执行基数约束和 onDelete 策略（cascade / restrict / unlink），图的一致性由引擎保证。
与同类方案对比
| Neo4j | SurrealDB | Dgraph | BlitzGraph | |
|---|---|---|---|---|
| Agent 专属设计 | ❌ | ❌ | ❌ | ✅ |
| MCP 原生支持 | ❌ | ❌ | ❌ | ✅ |
| 多 Kind 实体 | ❌ | ❌ | ❌ | ✅ |
| 内置全文搜索 | 需插件 | 部分 | ❌ | ✅ (BM25) |
| JSON 查询语言 | Cypher 字符串 | SurrealQL | GraphQL ± | BQL (结构化 JSON) |
注意事项
- 不是 SQL 替换：对于纯表格数据的扁平查询，PostgreSQL 更快。BlitzGraph 的优势在深度关联、多态实体、实体生命周期管理
- Beta 阶段：语义搜索引擎仍在开发中，查询优化器未完全优化，云端前端尚无原生认证引擎
- 数据可能清空：Playground 环境标有「data may be wiped without notice」——生产数据请使用正式 Grant Token 和命名空间
总结
BlitzGraph 是一个从零为 AI Agent 设计的图数据库后端。它的核心创新——多 Kind 实体、双向 O(1) 关系、BQL 类型化查询、原生 MCP 支持——解决了 Agent 在构建应用时最常见的几个痛点：SQL 生成不可靠、表结构变更麻烦、关系查询性能不可预测。如果你正在让 Agent 构建需要持久化数据的应用，BlitzGraph 是一个值得一试的选项。