过去三年，AI 的变化太快了，确实太快了，让大家对于 AI 的需求量和 token 消耗成指数级增长。

我们一直陷入到 AI 带来的模型能力的跃迁中，用 AI 做设计、做 PPT、写前端、写后端、写桌面端都没啥问题。编码能力大家都是有目共睹的。但我感觉整个过程中好像一直忽略了一个环节。

我身边也有一些老板和互联网公司，我看他们的日常包括我平常也会交流，他们给我透露的一个事实是，投入产出比远不及预期。

新模型用了，算力部署了，但是相对应的价值没有实现，很头疼，也很焦虑。

我也深有同感，虽然模型定义了能力的边界，但总感觉差点什么。

直到最近，我才确定了我们缺的是什么，我们缺的是其实就俩字：数据。

大模型就像是一台超跑，能力非常强，但是如果你不给他加油，它也跑不起来，但如果你给他加了油，它就像一台搭载 V8 发动机的性能巨兽。

所以大家常说的 AI 最后一公里，尤其是对企业而言，数据，才是核心。

而承载业务数据的数据库，才是一切的根本。

大家可能会想，数据库不是已经非常成熟了吗？关系型数据库、非关系型数据库、向量数据库、搜索引擎、数仓、数据湖，能选的东西这么多，而且PostgreSQL 加个 pgvector 不也能做向量搜索吗？

还说数据库干啥？

这是一个很好的问题。

以前我们理解数据库，更多是把它当成一个存东西的地方。

比如订单存在数据库里，用户信息存在数据库里，交易记录存在数据库里。

人要用的时候，就写 SQL、查数据、看报表。

但 Agent 不一样，Agent 不是偶尔查一次数据，它会不停地找资料、写结果、改状态，还会把前面发生过的事记下来。

这时候数据库对它来说，就不只是一个仓库了，而是一块关于数据的实验场。

所以我现在越来越觉得，企业 AI 真要往深处做，最后一定会回到数据库这件事上。

模型很重要，但模型只是大脑。

数据才是支撑大脑运转的营养。

据 Gartner 的数据表明，到 2028 年，大约三分之一的企业软件应用程序将包含 Agent，而 2024 年这一比例还不到 1%，更有夸大其词的分析师认为到了 2026 年底将有 40% 的应用程序集成 AI Agent。

而且数据的形态变了，过去企业的数据库很少存文本、图像、音视频之类的数据，因为存了人类看不懂，意义不大。但是现在不一样了，Agent 会这些数据“可视化” ，直接成为公司最核心的资产。

所以在 AI 时代，数据库已经不单单是存储数据的基座了，而是会变成 Agent 的上下文，会变成硅基生命的内存与磁盘，这个意义就不一样了。

而且我们正处于历史的关键时期，近年来的信创、国产化替代让大家明白了卡脖子的事实。

所以我基于这两个痛点，研究了一圈，最后把目光放在了OceanBase上。

大家可能会问，OceanBase ？OceanBase 不是传统的关系型数据库吗，怎么和 AI 数据库挂上钩了。

这里先得跟大家说下，AI 数据库是啥。

什么是 AI 数据库

我之前没有好好理解 AI 数据库的概念，我以为就是 AI 数据库外加一个检索插件，如果你像我这么理解，那恭喜你，跟我一样跑偏了。

AI 数据库需要重新回答一个问题：在一个由 AI 驱动的世界里，数据应当如何被组织、被理解、被调用，这一点尤为关键。

在传统的数据库组织形式中，这个问题好回答，当然是碳基生命 — 人。

而在 AI 时代，我觉得应该让 Agent 来回答这个问题。

如果要由 Agent 来回答这个问题，我觉得得从两条线上来讲。

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

• 上下文

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

• 规模

现在一个 AI 应用的成本在逐渐趋于 0 ，所以应用的数量级在指数级爆发。我看到一个消息，蚂蚁灵光已经有了千万个应用，而妙思在企业内部也支撑了上万个应用，但平均每个应用仅有百余行数据。

在大家的传统理念中，规模意味着架构的复杂性和代码的量级，但是在 AI 领域，规模意味着不是单个数据量大，而是库的数量多。其中 99% 的库处于沉睡，极少数被唤醒时却要秒级响应。

• 进化

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

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

企业过去积累的海量数据，比如文档、邮件、产品手册、客服录音、视频。这些数据虽然很有用，但是基本上都是非结构化的，往往直接归档了，因为这些数据无法组织起来，所以价值没有完全释放出来。

不过在 AI 时代，这些非结构化的数据可以和结构化的数据一起，在同一个底座上被统一管理、统一治理、统一调用，来形成 Agent 可以调用的上下文。

比如

一个金融投研 Agent 看研报、公告、行情、交易数据、新闻舆情。

一个智驾 Agent 看视频、图片、传感器、GPS、地图位置。

一个健康 Agent 看用户对话、体检报告、PDF、历史问诊记录、偏好和风险规则。

所以我理解的 AI 数据库，核心不是数据库会调用模型。

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

为什么是 OceanBase

6 月 29 日，OceanBase 发布了面向 AI 时代的湖库一体 AI 数据库。

大家可能不太知道啥叫湖库一体的 AI 数据库。

湖库这两个字可以拆开来看。

库，指的是关系型数据库所擅长的事，比如事务的 ACID 特性、实时查询、高可用，适合跑核心业务系统。

湖，指的是数据湖擅长的事：开放存储、海量数据、多种计算引擎，多种 media 类型（文本、图片、视频）、日志、向量这类数据。

湖库一体的 AI 数据库，就是把这两类能力放进同一个系统里。

它能够让一份数据既能用作实时分析，也能服务于多种数据搜索，还可以给 Agent 提供材料。

理解了“湖”和“库”的概念后，后面就好理解了。

OceanBase 解决哪些问题

面对 Agent、多模态数据带来的新需求，OceanBase 给出的答案，不是在传统数据库上增加若干 AI 功能，而是以湖库一体为核心架构，构建面向 AI 时代的数据基础设施。

OceanBase 把数据湖的开放与海量存储能力，数据库的事务、分析与实时处理能力，以及 AI 所需的多模态理解、语义检索和模型调用能力，统一到同一个强一致的数据底座之上了。

这个数据底座最核心的就是OceanBase Lakebase底层引擎。

我花了两天时间研究了一下 OceanBase 的 PPT。我发现 OceanBase 在一些领域上确实非常突出。

首先方向一，是多模态数据处理。

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 时代的数据底座问题

  OceanBase Lakebase 作为底层引擎，承载湖库一体与多模态数据能力，让结构化数据、非结构化数据和向量数据能够在统一架构中被管理、加工、检索和调用。

• DataStudio 解决了数据如何被生产、治理和服务化的问题；

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

• DataPilot 解决了业务人员如何直接使用数据智能的问题。

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

所以最后，我们可以针对 OceanBase 这次发布做个总结。

OceanBase AI 数据库，是以湖库一体为核心架构、面向 Agent 和多模态数据设计的现代数据基础设施。

它将数据库的事务、一致性与实时处理能力，与数据湖的开放、海量存储和多样化计算能力统一起来，把结构化、半结构化、非结构化数据纳入统一管理体系，打通在线服务与离线分析，消除多系统拼装带来的数据割裂、链路冗余与工程复杂性。

为现代 AI 应用提供可靠、实时、可扩展的数据底座。