OceanBase 发布湖库一体 AI 数据库，面向 Agent 场景重构数据底座

OceanBase 近日正式发布「湖库一体 AI 数据库」（OceanBase Lakebase），将库内实时事务能力与湖上开放存储、开放计算能力整合到同一套数据底座中，主打面向 AI Agent 时代的数据基础设施。该产品由 OceanBase CTO 杨传辉对外介绍，延续了其在分布式 OLTP、实时 OLAP、多模一体化方向上的演进路径。

设计出发点：数据库使用者从应用扩展到 Agent

杨传辉在介绍中指出，AI 正在同时改变三件事：数据库的使用者从应用扩展到 Agent；管理的数据从结构化数据扩展到多模态数据；承载的工作负载从事务和分析扩展到搜索、上下文工程与 AI 应用。

OceanBase 团队认为，AI 数据库并不是「传统数据库加几个 AI 函数」或「向量数据库补上 SQL」，而是要解决 AI 进入生产系统后的数据基础设施问题，包括多模态数据统一管理、离在线融合、Agent 实时获取可信上下文等。

核心架构：存算分离 + 多模表 + 开放计算

湖库一体 AI 数据库的架构可以拆为三层能力：

• 存算分离：数据存放在对象存储之上，计算层独立运行。Agent 负载具有突发性，存算分离支持计算层瞬时扩容、空闲时缩到零。
• 多模表：在关系列之外引入多模列与 AI 列，统一管理结构化、半结构化、非结构化数据以及向量、图、全文索引。LOB 支持行内存储、切片存对象存储或引用外部文件三种模式。
• AI 列：可视为表上的实时计算列，写入后自动触发 Embedding、打标等模型计算，并保持事务一致性——一批数据要么全部完成计算，要么全部失败。

上层计算除 SQL 引擎外，还支持 Spark 处理 PB 级 ETL、Daft on Ray 处理 AI 推理，使多套计算引擎共享同一份数据。

混合搜索与基准表现

OceanBase 团队将 AI 数据库中的基本查询模式定义为「混合搜索」，即在同一张表内同时完成关系过滤、全文搜索、向量搜索、图搜索及 AI 计算。其逻辑是先通过关系过滤缩小候选集，再进行向量与语义搜索，以降低推理成本。

公司公开的基准数据显示：

• 向量搜索：使用 HNSW 算法，在 768 维与 1536 维场景、同等召回率下，性能「远领先于」Milvus、Elasticsearch 与 pgvector（原文未给出具体倍数）。
• 混合搜索：在 MS MARCO 数据集上，性能相比 Elasticsearch 提升 30% 以上。

为 Agent 设计的能力：Fork Database 与逻辑表

为了让 Agent 进入生产系统，OceanBase 引入了两项关键机制：

• Fork Database：秒级创建完整数据库副本，即使 PB 级库也能在秒内完成，基于 Copy-on-Write 只占增量空间。配合 DIFF 与 MERGE，Agent 可在分支上自由试错，失败直接回滚。
• 逻辑表：将「千万 Agent × 几百行」的场景映射到底层同一张物理表，通过逻辑层抽象应对 Schema 爆炸问题。

杨传辉表示，传统数据库为「少库 + 海量数据」优化，Agent 场景则相反，需要在「独立环境」与「实例规模」两端同时解决。

上下文层：PowerMem 与 OSI 语义

在引擎与应用之间，OceanBase 增加了「上下文层」，分为两个部分：

• 数据上下文（OSI 语义层）：基于 Ant-OSI 语义层标准设计，将指标、口径、原始数据、上下文图谱与本体层统一起来，主打「语义即代码」。
• 应用上下文（PowerMem）：构建在 AI 数据库之上，记忆检索本身是一次结构化过滤 + 语义相似度的混合查询，并支持经验与技能的自进化。

OceanBase 给出的对比数据为：在同一轨迹、同一模型下，使用 AppWorld 公平蒸馏实验，seekdb M0 方案通过率 39%，对照方案 Hermes 22%；完成相同任务时 M0 平均 6.2 步，Hermes 10.4 步，整体 Token 消耗降低 32%。

小结

OceanBase 将湖库一体 AI 数据库的架构概括为三层：底层是湖库引擎（多模表 + 对象存储 + 多套计算引擎），中间是上下文层（数据上下文 + 应用上下文），上层是面向数据开发与数据分析的 Agent。官方认为，要让企业真正用好 AI，第一步是通过一体化的 AI 数据库把数据管起来，而湖库一体是面向 AI Agent 时代给出的具体答案。