过去三年，AI 的变化快到让人目不暇接，模型能力的跃迁让 token 消耗指数级增长。大家都在追逐更好的模型，用它做设计、写代码、做 PPT——编码能力确实有目共睹。但回过头来看，似乎一直忽略了一个环节。身边不少老板和互联网公司也在焦虑：投入产出比远不及预期——新模型用了，算力部署了，对应的价值却迟迟没有兑现。直到最近，才终于想清楚缺的是什么——两个字：数据。

大模型就像一台超跑，能力再强，不加油也跑不起来；一旦加了油，就是一台搭载 V8 发动机的性能巨兽。所以常说的 AI 最后一公里，尤其是对企业而言，数据才是核心。而承载业务数据的数据库，才是一切的根本。

可能有人会问：数据库不是已经非常成熟了吗？关系型、非关系型、向量数据库、搜索引擎、数仓、数据湖……能选的东西这么多，PostgreSQL 加个 pgvector 也能做向量搜索，为什么还要专门谈数据库？

这是个好问题。以前我们理解的数据库，就是一个存东西的地方：订单、用户信息、交易记录——人用的时候写 SQL、查数据、看报表。但 Agent 不一样，它不会偶尔查一次数据，它会不停地找资料、写结果、改状态，还会把前面发生过的事记下来。这时候数据库对 Agent 来说，就不再只是一个仓库，而是一个关于数据的实验场。所以越来越清晰的是：企业 AI 真要往深处走，最后一定会回到数据库这件事上。模型很重要，但模型只是大脑——数据才是支撑大脑运转的营养。

什么是 AI 数据库

之前也曾经把 AI 数据库理解为“关系型数据库外加一个向量检索插件”——如果这样想，那可能跑偏了。AI 数据库需要重新回答一个问题：在一个由 AI 驱动的世界里，数据应当如何被组织、被理解、被调用？这一点尤为关键。在传统数据库体系中，答案是人——碳基生命；而在 AI 时代，应该让 Agent 来回答。

如果要让 Agent 来回答，需要从两条线展开。

第一条线：属于 Agent 的三个概念

上下文：上下文是 Agent 的记忆体，是智能体的命门。每一次回答，本质上就是一段上下文加一次模型调用。能不能把对的信息精准地组织成喂给模型的上下文，直接决定它答得准不准。

规模：现在一个 AI 应用的成本在逐渐趋于零，应用数量级指数级爆发。有数据表明，蚂蚁灵光已经有了千万个应用，妙思在企业内部也支撑了上万个应用，但平均每个应用仅有百余行数据。传统观念里，规模意味着架构复杂性和代码量级；但在 AI 领域，规模不是单个数据量大，而是库的数量多——其中 99% 的库处于沉睡，极少数被唤醒时却要秒级响应。

自进化：Agent 就像小孩子，会犯各种错误，但需要试错才能成长。需要为它搭建一个能反复试验的环境。如今 AI 写代码的成本已大幅下降，但造出一个能让智能体安全跑起来的试验环境，代价仍然很高。

第二条线：数据的组织形式

企业过去积累的海量数据——文档、邮件、产品手册、客服录音、视频——虽然很有用，但基本是非结构化的，往往直接归档了。因为这些数据无法被有效组织，价值没有完全释放。但在 AI 时代，非结构化和结构化数据可以在同一个底座上被统一管理、统一治理、统一调用，形成 Agent 可以调用的上下文。例如：一个金融投研 Agent 需要看研报、公告、行情、交易数据、新闻舆情；一个智驾 Agent 需要看视频、图片、传感器、GPS、地图位置；一个健康 Agent 需要看用户对话、体检报告、PDF、历史问诊记录、偏好和风险规则。

所以 AI 数据库的核心，不是数据库会调用模型。更准确地说，它是把交易、分析和 AI 要用的数据放到同一个系统里，让表格、文档、图片、音视频、向量这些东西能一起管理、一起查、一起用。

为什么是 OceanBase

6 月 29 日，OceanBase 发布了面向 AI 时代的湖库一体 AI 数据库。什么是“湖库一体”？可以拆开来看：

• 库：关系型数据库擅长的事——事务的 ACID 特性、实时查询、高可用，适合核心业务系统。
• 湖：数据湖擅长的事——开放存储、海量数据、多种计算引擎，以及文本、图片、视频、日志、向量等多 media 类型。

湖库一体的 AI 数据库，就是把这两类能力放进同一个系统里。它能让一份数据既能用作实时分析，也能服务于多种数据搜索，还能给 Agent 提供材料。

OceanBase 解决哪些问题

面对 Agent 和多模态数据带来的新需求，OceanBase 给出的答案不是传统数据库上增加若干 AI 功能，而是以湖库一体为核心架构，构建面向 AI 时代的数据基础设施。它将数据湖的开放与海量存储能力，数据库的事务、分析与实时处理能力，以及 AI 所需的多模态理解、语义检索和模型调用能力，统一到同一个强一致的数据底座上。这个底座最核心的是 OceanBase Lakebase 底层引擎。

花了两天时间研究了一下发布的资料，有几个方向非常突出。

方向一：多模态数据处理

OceanBase Lakebase 的核心设计，是把结构化字段、文本、图片、音视频、JSON、LOB、向量放进同一张多模表里。注意，这不是把所有文件粗暴塞进数据库行——小对象可以 InRow，大对象可以 OutRow，超大文件可以托管在对象存储里，由引擎按对象大小和访问特征做自适应存储。用户和上层应用看到的，仍然是一张统一的表。

这里最关键的是 AI 列。很多企业做 RAG 或智能搜索，都会把原始数据搬出去做摘要、打标签、生成 embedding，再写回另一个系统。流程一长，原始数据和 AI 处理的结果就很难保证一致性。AI Row 的思路，是把摘要、标签、特征、向量这些 AI 处理结果变成表里的列——模型能力以列的形式进入数据库，原始数据和处理结果可以放在一起管理。

方向二：Agent 友好的数据库

传统软件开发里有 Git 分支、测试环境、回滚机制；Agent 进入生产系统后，也需要类似的东西，只不过对象从代码变成了数据、记忆、RAG、业务状态和执行轨迹。OceanBase 这次发布反复提到了 Fork Database、Diff/Merge、Copy-on-Write，本质上就是给 Agent 一个数据沙箱。每个 Agent 可以从基线库 Fork 出独立环境，在里面评测、实验、写数据、改策略——失败了直接丢弃，成功了再合并。

这个能力对 AI 应用迭代很友好。资料中提到的蚂蚁阿福这样的生产级健康应用，核心竞争力就来自持续发现 bad case、修复问题、重新评估。评测阶段里，Agent 会改流程、改策略、改数据，但这些操作不能污染线上数据。对企业而言，这一点的价值不只在开发效率，更在于生产级 Agent 能否形成稳定的迭代机制。

方向三：湖库一体化

过去，结构化数据放在数据库里，文档、图片、音视频等非结构化数据放在对象存储或数据湖中，两者依赖外部链路关联。AI 时代，Agent 需要的上下文天然跨越多种数据形态：一笔交易、一段客服录音、一张发片图片、一份合同文本——只有被放在一起理解，才构成完整的业务事实。OceanBase Lakebase 通过湖库一体架构，将数据湖的开放格式与海量存储能力、数据库的结构化管理与在线服务能力统一起来，把结构化、半结构化和非结构化数据纳入同一套元数据、权限、事务和生命周期管理体系。数据不必在多个系统之间反复搬迁和复制，就可以直接支撑在线服务、实时分析和 AI 应用运行。

这里有几个现实收益：一个是省 Token，另一个是实时性。传统做法里，数据加工是离线的，加工完的结果还要搬回在线系统才能服务应用，中间有 T+1 甚至更长的延迟。湖库一体把离线加工和在线服务统一在同一份数据上：Spark ETL 的产出，SQL 引擎立即可查；模型推理生成的向量，混合搜索立即可用——不再有“加工完了还要等同步”的窗口期。实时性不是靠加速搬运实现的，而是靠消除搬运实现的，因为数据不用搬来搬去，向量检索可以直接在数据所在处进行，减少了额外的存储和网络传输开销。

OceanBase 的特点

此次发布中，OceanBase 形成了完整的产品体系，覆盖从底层数据引擎、数据生产治理到业务智能入口的关键环节。完整的产品体系由三个部分组成：

Lakebase

解决了 AI 时代的数据底座问题。作为底层引擎，承载湖库一体与多模态数据能力，让结构化数据、非结构化数据和向量数据能够在统一架构中被管理、加工、检索和调用。

DataStudio

解决了数据如何被生产、治理和服务化的问题。运行在 Lakebase 之上的数据生产、治理与服务工作台，覆盖数据接入、数据加工、任务编排、语义建模、数据治理到 Agent 协作等关键环节，帮助企业把分散的数据资产转化为可管理、可理解、可调用的数据服务。

DataPilot

解决了业务人员如何直接使用数据智能的问题。面向经营分析和业务决策的数据智能 Agent，作为统一的企业业务智能入口，让业务人员可以通过自然语言完成分析报告、数据看板和可信答案生成，把过去依赖专业数据团队完成的分析流程，转化为可交互、可追问、可复用的智能决策能力。

总结一下：OceanBase AI 数据库，是以湖库一体为核心架构、面向 Agent 和多模态数据设计的现代数据基础设施。它将数据库的事务、一致性与实时处理能力，与数据湖的开放、海量存储和多样化计算能力统一起来，把结构化、半结构化、非结构化数据纳入统一管理体系，打通在线服务与离线分析，消除多系统拼装带来的数据割裂、链路冗余与工程复杂性。为现代 AI 应用提供可靠、实时、可扩展的数据底座。