主流数据库的发展经历了几次重要演进：从最早的OLTP数据库，到OLAP从其中分离出来成为数据仓库，再到大数据系统。长期以来，数据库架构主要围绕人类应用、确定性交易和结构化数据分析设计的。
今天，新的变化正在发生。AI Agent 不再只是读取数据、回答问题，而是开始调用工具、生成代码、执行任务、修改状态，甚至参与业务流程。数据库的使用者，正在从人类应用扩展到大量自主运行的 Agent。这带来一个根本问题：当成千上万个 Agent 同时读写、搜索、试错、回滚和生成上下文，数据库还应该是过去的样子吗？
我认为，答案是否定的。AI 正在同时改变三件事：
- 数据库的使用者，从应用扩展到 Agent；
- 数据库管理的数据，从结构化数据扩展到涵盖结构化、半结构化与非结构化的多模态数据；
- 数据库承载的工作负载，从事务和分析扩展到搜索、上下文工程与 AI 应用。
因此，AI 数据库不是传统数据库增加几个 AI 函数，也不是向量数据库补上 SQL 能力。它要解决的是 AI 进入生产系统后的数据基础设施问题。多模态数据需要在统一底座上被管理，在线服务和离线计算需要融合，Agent 需要获得实时、可信、连续的上下文，读写、试错、回滚和治理中保持数据库级一致性与可靠性。
这不是一次功能增强，而是在 AI 时代重新定义数据库的技术架构。
AI时代，数据库走向一体化
我们先看行业发生了什么。
Databricks 和 Snowflake 从湖仓和数仓出发，不断补充 OLTP 的事务能力；
OceanBase 和 Oracle 从交易库出发，不断补充 OLAP 和大数据能力；
MongoDB、Milvus、Elasticsearch 从专用库出发，不断增强通用数据库的能力。不管出发点如何，不同路线正在向一个能够同时处理交易、分析、搜索、向量以及 AI 计算的统一数据底座演进。
OceanBase 一直坚持走一体化设计思路。
最早我们做的分布式 OLTP，解决了在线交易的扩展性和可靠性。后来我们在 OLTP 基础上加入了实时 OLAP 支持，消除了 TP 到 AP 的数据搬运。去年，我们发布了多模一体化，把向量、全文、JSON、GIS 等能力带进同一个数据库引擎。
今天，我们发布湖库一体，是继续往前走一步：把库里的实时事务能力、湖上的开放存储和开放计算能力，放到同一个数据底座里。
什么是湖库一体
我理解的湖库一体，不能停留在数据库外接一个数据湖，也不能只是给湖仓补几个在线查询接口。要让它进入生产系统，至少要合并三条边界。
第一，数据形态要统一。结构化数据、半结构化数据、非结构化数据、向量、图、全文索引，不能分散在不同系统里各管一份。它们应该在同一套表语义下被管理。
第二，计算路径要统一。SQL 查询、实时分析、混合搜索、Spark ETL、Ray 上的 AI 计算，应该围绕同一份数据工作，而不是靠不断导出、转换、中间落盘来协作。
第三，治理边界要统一。元数据、权限、行级控制、审计、版本、生命周期，必须对所有数据类型一致生效。否则结构化字段有权限控制，向量检索却绕过了权限，这样的系统进不了企业生产。
这也是 OceanBase Lakebase 的设计出发点：
底层使用存算分离的设计架构。数据存在对象存储上，计算层独立运行。AI Agent 的工作负载本质上是突发式的——每一个 Agent 都可能在任何一天流量激增，每一天都可能有一个小型的双十一。存算分离让计算层能够独立伸缩，负载上来瞬间扩容，空闲时缩到零。
中间用多模表统一结构化、半结构化、非结构化数据以及多模态数据。
上层支持开放计算。除了原有的 SQL 计算（OLTP、OLAP、AI 搜索），也支持 Spark 处理 ETL、Daft on Ray 处理 AI 加工。把这些计算引擎统一在同一份数据之上，是湖库一体区别于传统数据库的核心设计目标。
湖的价值在开放、弹性和成本。库的价值在事务、一致性、低延迟和治理。AI 时代需要把这两组能力合在一起。
但还有一个关键价值容易被忽视——实时性。
传统做法里，数据加工是离线的，加工完的结果还要搬回在线系统才能服务应用，中间有 T+1 甚至更长的延迟。
湖库一体把离线加工和在线服务统一在同一份数据上：Spark ETL 的产出，SQL 引擎立即可查；模型推理生成的向量，混合搜索立即可用。不再有“加工完了还要等同步”的窗口期。
实时性不是靠加速搬运实现的，而是靠消除搬运实现的。
多模表，AI数据库的核心数据结构
原来的关系数据库，底层是一张关系表——里面有 Int、Float、Varchar，所有列都是结构化数据。
今天的 AI 数据库，底层应该是一张多模表。
多模表既包括原有结构化数据的关系列，也包括非结构化数据的多模列与 AI 列。
非结构化数据，可以在外部 Embedding 或者打标之后以向量或者文本的方式写入到多模表，也可以直接以 LOB 的形式写入到多模表。
OceanBase 支持非常灵活的 LOB 存储。
- 如果 LOB 对象比较小，直接在行内存储，节省 IO；
- 如果 LOB 对象比较大，切片后存入对象存储，行内只保留每个切片的位置信息；
- 如果 LOB 对象特别大，支持引用外部对象存储中的已有文件，数据库只存储元数据。上层应用看到的仍然是一张表。
在多模表之上，我们还设计了 AI 列。它可以理解成表上的实时计算列：数据写入后，自动触发 Embedding、打标等模型计算，并把结果写回表里。这里最重要的是事务一致性语义。比如一批音频写入后，要么全部完成 Embedding 和打标，要么全部失败，不能出现部分成功、部分失败的情况。
混合搜索：搜索作为AI数据库的一类负载
有了多模表，接下来是在其上执行 AI 工作负载。
AI 数据库里面，查询的基本模式从关系查找进化为混合搜索——在同一张表里完成关系过滤、全文搜索、向量搜索、图搜索以及 AI 计算。
为什么单纯的向量搜索是不够的？
向量搜索在 AI 数据库里一定是最常见的一种计算方式，但在实际场景里，我们往往首先通过关系过滤将全局数据缩小为一个更小的候选集（例如“只看最近 30 天的订单”），接下来在候选集上做向量、全文、图的混合搜索。数据库先缩小范围，模型只处理高价值候选——推理成本更低、结果更准、链路更可控。
在 AI 时代，搜索会与 OLTP、OLAP 一样回归数据库本体，成为数据库的一类负载。
性能上，我们做了系统的评测验证。
使用 HNSW 算法，在 768 维和 1536 维的测试场景下，同等召回率条件下 OceanBase 的向量搜索性能远领先于 Milvus、Elasticsearch 和 pgvector。
在混合搜索维度，使用 MS MARCO 数据集评测，OceanBase 混合搜索的性能相比 Elasticsearch 提升 30% 以上。这不是理论值——是标准数据集上的可复现结果。
开放计算与统一Catalog
Agent 的数据链路不止是 SQL 查询——还有 ETL 加工、AI 推理、多模态理解。
原先的做法，往往是采用多个不同的系统——Kafka 做接入，Flink 做流处理，Spark 做批处理，HDFS 做持久化，ClickHouse 做分析，HBase 做宽表，Elasticsearch 做搜索，Presto 做联邦查询。
OceanBase 湖库一体设计解决的就是这个问题。
底层通过基于对象存储的多模表，实现多套计算引擎之间的数据共享——一份数据同时服务所有计算引擎。OceanBase 的 SQL 引擎处理在线查询和事务；Spark 处理 PB 级批量 ETL；Daft on Ray 处理 AI 推理，从而解决多套系统之间的数据一致性以及计算延迟的问题。
因为需要支持这么多开放计算引擎，我们需要一个统一开放的 Catalog 来管理数据。表、视图、Schema、Lineage、行级权限、列级授权，都应该在这里统一管理。
OceanBase AI 数据库的所有操作在进入系统之前，都需要经过统一元数据与权限控制面做一层过滤，避免数据越权访问。我们也已经支持了最细粒度的行级权限控制（RLS）。
为Agent设计版本控制与弹性规模
为了让 Agent 真正进入生产系统，数据库必须给它一个可隔离、可回滚、成本足够低的操作环境。
通过 Fork Database，可以秒级创建一个完整的数据库副本——像在 GitHub 里拉一个分支。即使 PB 级数据库也能在秒内完成 fork，且只占增量空间（Copy-on-Write，未修改的数据块指向湖上同一份存储，不产生物理拷贝）。
拉完分支之后，可以在分支上做各种 AI 的开发、测试和实验。实验成功就提交，实验失败直接回滚，基本上没有代价。
配合 DIFF 和 MERGE，Agent 就获得完整的数据版本控制能力——Fork 建分支，DIFF 看差异（精确到行和值），MERGE 按策略合回。这不是类比 Git，而是 SQL 级的原生实现。
另一个维度是规模。AI 的 Agent 数据量会是海量的，未来可能有千亿级甚至万亿级 Agent 在并行运行，每一个 Agent 都有自己的 Schema、自己的表——这会造成 Schema 爆炸的问题。
传统数据库为“少库 + 海量数据”优化，一个集群承载几十个库、每个库数十亿行。Agent 场景完全相反：千万个 Agent，每个只有几百行，但实例数量是天文级的。
OceanBase 的逻辑表设计，是让每一个 Agent 看到的是一张张独立的逻辑表，但存储在底层是同一张物理表格，通过逻辑层抽象解决 Schema 爆炸。
Fork Database 解决独立环境，逻辑表解决实例规模——两者协同才能让单个 Agent 安全试错、海量 Agent 低成本并行运行。
上下文层让AI理解企业与用户
AI 数据库，光有引擎还不够。引擎和应用之间还缺一层——上下文。
上下文层分为两个部分。数据上下文，围绕数据的语义和数据的治理展开，让AI理解企业。应用上下文，围绕 Memory 和 RAG 展开，让 AI 理解用户。
在记忆维度，Agent 的记忆不能简单地堆上下文，而是一个可进化的结构化资产。为此我们研发了 OceanBase PowerMem，以及基于 PowerMem 的云上产品 OceanBase seekdb M0。
OceanBase PowerMem 构建在 AI 数据库之上，记忆的检索本身就是一次结构化过滤 + 语义相似度的混合查询。更关键的是它支持记忆的自进化——包括经验的自进化以及技能的自进化。
我们使用 AppWorld 公平蒸馏实验做了验证——同一份轨迹、同一模型、唯一变量是蒸馏和检索方案。结果：seekdb M0 方案的通过率达到 39%，Hermes 只有 22%；完成相同任务，M0 的步骤是 6.2 步，Hermes 是 10.4 步；整体 Token 消耗降低 32%。
在语义维度，高质量的数据语义让 AI 应用真正能够理解企业。OceanBase OSI 要解决的不是再造一套 BI 语义，而是把指标、口径、原始数据、上下文图谱、本体层统一起来。
最底层是语义层——指标、口径、原始数据等，基于 Ant-OSI 语义层标准设计，兼容 OSI 开放标准，并在蚂蚁集团得到了大量实践验证。
中间层是上下文图谱——大模型基于上下文图谱推理，提升准确率。
最上层是本体层——统一业务语义与底层数据库语义，做到全局语义与局部语义的平衡。核心理念是“语义即代码”——数据语义一次定义，BI 渲染报表、Agent 生成 SQL、治理工具做血缘分析，读的是同一份定义。
我们基于 OceanBase OSI 也开发了 DataPilot 产品。在不同行业的客户 POC 测试中，客户反馈准确率远好于业界其他产品。
这背后不是模型的差异，而是语义上下文的质量差异——当 AI 拥有准确的业务口径定义，从自然语言到 SQL 的翻译准确率会本质性地提升。
一套技术栈降低工程复杂度
所有这些能力加在一起意味着什么？最直接的答案是：组件数量的大幅减少。
如果采用传统方案，企业需要 5 到 10 个系统来融合处理多模态数据，且多个系统缝合带来一系列问题，包括：CDC 延迟、ETL 失败重试、多套独立运维、多套权限体系、多套监控告警，等等。
通过OceanBase湖库一体引擎，能够实现多合一，通过一份数据保证一致性，通过离在线融合保证实时性。
小结：湖库一体的AI数据库
如果把这些能力放在一起看，OceanBase AI 数据库的架构可以概括为三层。
最底层是湖库引擎——多模表运行在对象存储之上。通过多模表和对象存储，支持各种开放计算：OceanBase 的 SQL 计算（OLTP、OLAP、搜索）以及 Spark ETL 和大模型 AI 计算。
中间是上下文层——数据上下文让 AI 理解企业，应用上下文让 AI 理解用户。
最上层是我们开发的应用 Agent：面向数据开发工程师的数据开发 Agent，和面向业务分析师的数据分析 Agent。
为了让企业真的把 AI 用起来，最重要、最基本的一步，是通过一个一体化的 AI 数据库把企业自己的数据管理起来。管理好自己的数据之后，才能让企业的 AI 更准、更省、更快、更安全。
湖库一体的 AI 数据库，这就是我们面向 AI Agent 时代给出的答案。