AI时代的数据库:不是加插件,而是重写底座

过去三年，AI领域最热闹的故事是模型的跃迁。GPT-4、Claude、通义千问，能力以"周"为单位迭代，算力同步爆发，企业争相投入。但一个尴尬的事实正在浮现：投入产出比远不及预期。

模型买了，算力部署了，价值为什么没有兑现？

问题出在一个被长期忽视的环节——数据。

模型定义了AI的能力边界，而数据决定了AI的业务价值。一个通用大模型也许"无所不知"，却未必懂得"这一家企业"的业务逻辑。让它从"什么都懂一点"走向"真正懂我"，靠的是高质量的数据与上下文。AI落地的"最后一公里"，本质上是一道数据的难题。

两股力量，正在把这个问题推向必须解决的临界点。

第一股力量：数据的使用者变了。

据预测，到2028年，将有三分之一的企业软件交互由智能体完成。它们全天候不间断地调用数据、做出判断。数据库第一次迎来"非人类"的使用者——不再是工程师逐条编写查询，而是智能体在毫秒之间自动完成查询、推理与决策。

第二股力量：数据的形态变了。

据预测，到2025年，全球超过80%的数据是非结构化的——文本、图像、音频、视频。过去，这些数据因机器难以理解而长期沉睡；AI第一次让它们变得"可计算"，从企业的"边角料"，跃升为最具价值的核心资产。

两股力量叠加，传统数据库的架构开始承压。更关键的是，一个根本性的认知正在形成：大模型之间的差距正在快速收敛，应用与应用的差距，越来越体现为"上下文质量"的差距。

这意味着，AI竞争的焦点，正从"谁的模型更强"，转向"谁能让AI真正读懂业务、把价值落到实处"。而这一转移，把数据库推到了舞台中央。

AI时代，数据库不再只是支撑业务的后台系统，而是AI价值兑现的战略制高点。

对中国而言，这件事还多了一层含义。长期以来，操作系统、数据库这类基础软件的标准大多由先行者定义。而AI数据库是一条全新的赛道——全球几乎站在同一条起跑线上，既有技术存量不再构成绝对壁垒。中国第一次有机会从基础软件标准的"跟随者"，成长为"共同定义者"。

面对上述变化，一个误解需要被澄清：AI数据库，不是"传统数据库加一个检索插件"。它需要重新回答一个根本问题——在一个由AI驱动的世界里，数据应当如何被组织、被理解、被调用。

要看清它的全貌，不妨从前面"两股力量"分别带来的需求说起。

来自新使用者——Agent的需求

智能体与人不同，它持续运行、自主调用数据，并通过不断试验完成任务。它有三个天性，对数据底座提出了人类用户提不出来的要求。

上下文——是智能体的命门。

智能体的每一次回答，本质上都是"一段上下文，加一次模型调用"。能不能把对的信息，精准地组织成喂给模型的上下文，直接决定它答得准不准。而一段完整的上下文，从不区分"结构化还是非结构化"——一笔订单的数字、一段客服录音、一张发票照片，本来就是一体的。这就要求数据库能在一次检索里，从多种形态的数据中找出最相关的信息，做到"供给得准"。

规模——从"一个应用一个库"，到"一句话一个应用"。

当生成一个应用的成本被AI压到接近于零，应用的数量将呈指数级爆发。蚂蚁灵光已有3000万个闪应用，妙思在企业内部支撑了上万个应用，平均每个应用仅有百余行数据。这就是AI时代的"海量"——不是单个数据量大，而是库的数量多。其中99%的库处于沉睡，极少数被唤醒时却要秒级响应。这要求数据库"承载得起"：高密度共存、彼此隔离、按需启用、闲时几乎不占成本。

进化——靠不断试错而成长。

复杂智能体的开发，最大的瓶颈往往不是写代码，而是为它搭建一个能反复试验的环境。如今AI写代码的成本已大幅下降，但"造出一个能让智能体安全跑起来的试验环境"，代价依然高昂。这就要求数据底座能像管理代码一样，随时开辟一个彼此隔离的试验空间，让智能体在其中放手尝试，做得好就保留、不行就丢弃，做到"演练得稳"。

Agent是AI时代数据库共同面临的新的业务形态，而「上下文、规模、进化」这三个关键能力，将共同打造AI native的数据底座。它回答的，是"智能体怎么用好数据"。

来自数据新形态的需求

如果说AI native的数据底座解决的是"怎么用"，那么另一条线要回答的，是"用什么"。

非结构化数据，要从"存储成本"变成"可计算资产"。

企业过去积累的海量数据，绝大多数是非结构化的——文档、邮件、产品手册、客服录音、视频。过去，这些数据主要被存储和归档，很难直接参与实施业务决策。AI第一次让它们可以被理解。但要真正释放价值，仅仅"存下来"不够，仅仅"建个索引"也不够。这些数据，需要和结构化数据一起，在同一个底座上被统一管理、统一治理、统一调用。搜索是Agent获取信息的行为方式，统一底座上多模态的混合搜索，才能满足Agent天然的搜索需求。

数据的流动，要形成闭环。

过去的链路是单向的：数据训练模型，模型支撑应用。Agent的运行效果极大依赖模型能力的持续提升，而模型能力的提升又依赖于实时在线的数据上下文供给，这就要求AI时代的数据库必须具备离在线一体的计算能力，在线数据实时喂给模型，模型驱动智能体——数据越用越多、越用越准。这就是AI时代的"数据飞轮"。要让这一数据飞轮真正运转，在线数据与离线数据、实时计算与批量计算不能长期处于彼此割裂的系统中。

数据库，要从"记录业务"走到"理解业务"。

过去，数据库的角色是把一笔交易、一张订单老老实实存下来。自然语言是Agent与数据库交互的全新入口，因此AI时代的数据库，必须具备语义层，才能更好地理解业务，让AI真正"读懂"这家企业在做什么，从而为Agent应用形态服务。

把需求倒推一遍，就得到了AI数据库的定义

把两条线汇到一起，AI数据库该有的样子就清晰了。它由两类东西定义：一类是AI负载实实在在提出的需求，数据库不满足就跑不动；另一类是数据库面向AI时代应当坚守的设计原则。

两个需求——由AI时代的业务负载决定，必须满足：

一体化：多模态数据、离线与在线的计算，统一在同一个强一致的底座上。数据不再被切割、不必在多套系统之间反复搬运，那个"越用越准"的飞轮才转得起来。

多模态：结构化、半结构化和非结构化数据，需要在同一套体系中被统一管理和治理，通过标量、全文、向量等方式进行混合搜索，智能体的记忆天生跨越模态，沉睡的非结构化数据也由此被真正盘活。

两条设计原则——数据库面向AI时代应有的立场：

Agent友好：Agent所需的记忆、上下文、隔离、分支、回滚与规模化运行能力，不应该依赖外部系统拼装，而应成为数据底座的原生能力。

开放：存储与计算开放、不被锁进任何一家的专有系统。企业的数据主权与选择权，应该始终握在自己手里。

这两个需求、两条原则，四者缺一不可——而且都不是凭空罗列：把前面的变化倒推一遍，自然就会得到它们。这不是一句营销断言，而是一组定义。

谈"新品类"，容易让人误以为是把过去的一切推倒重来。事实恰恰相反。

AI改写了数据库的"用法"，却让它的"底线"变得前所未有地重要。

一致性，从"高标准"变成了"生死线"。

当智能体从辅助工具走向"替人决策"——在风控审核、内容安全等环节，已经是智能体直接面向用户在拍板——它背后的数据，就有了核心交易系统一样的属性：错一条、慢一拍，不再是技术指标的小问题，而是真实的业务事故。这也是为什么只做检索的系统不够用——它们没有强一致的保障，扛不起智能体的在线决策。

扩展性，从"把一个库做大"变成了"让一百万个库低成本共存"。

过去十五年，扩展性的题目是怎么把一个库做大、扛住更大的负载——那是上一个时代的题。AI时代，题目变了：是怎么让一百万个库经济地共存——需要时能无限扩展、海量也扛得住，闲下来时又近乎不占成本，像水电一样按需供给。

可靠性，从"有人兜底"变成了"智能体的生命线"。

智能体全天候运转，身边没有运维人员盯着。十五年金融级高可用积累下来的能力，过去为核心交易兜底，到了AI时代，就成了每一个智能体的生命线——它保障的，是业务的连续（它不中断、业务不掉线）与体验的连续（用户感知不到故障）。

实时性，在线、实时地服务智能体的决策，而不是隔夜跑批。

智能体的判断发生在毫秒之间，数据底座必须跟得上这个节奏。

真正需要被重写的，是架构与品类；必须被坚守的，是工程的底线——而且这条底线，被推到了前所未有的高度。

满足这些变与不变，形态上只有一个答案：「湖库一体」——数据湖开放、海量的存储能力，与数据库事务的处理能力，生长在同一个强一致的底座之上。

这不是概念的拼凑，而是业务负载的客观要求："库"擅长一致与实时，"湖"擅长规模与开放，AI时代要求两者合而为一。

AI时代的数据库，就是湖库一体的。

为什么是OceanBase

湖库一体既然是方向，现实的下一个问题就是——从哪里出发去构建它？

面对这道命题，行业正在探索不同路径。有的从"湖"出发，先解决开放存储和海量数据管理，再向上增强事务能力；有的从"搜索"出发，先解决语义搜索和向量检索，再扩展对结构化数据的处理能力。这些路线各有其价值，也分别回应了AI时代数据处理的不同需求。

但当AI真正进入企业核心系统，数据底座要面对的不只是"能不能找到数据"，还包括数据是否一致、权限是否可控、版本是否可信、系统是否持续可用，以及故障发生时能否快速恢复，都将直接影响Agent的判断与行动。换言之，AI数据库最终要解决的，不只是检索问题或存储问题，而是一个面向生产系统的完整工程问题。

OceanBase的选择，是从内核出发，把已经在核心交易场景中验证过的事务一致性、高可用、实时处理和弹性扩展能力，进一步延伸到湖、非结构化数据和多模态数据之上。

这正是OceanBase构建AI数据库的独特路径：不是把"湖"与"库"简单拼接，而是以成熟的数据库内核为基础，让数据库的事务与实时能力，和数据湖的开放、海量与多模态能力在统一架构中协同运行。过去保障核心交易稳定运行的能力，正在成为Agent安全、可靠进入生产系统的数据基础。

凭什么有这个判断，也有这个能力

OceanBase是中国自主研发的分布式数据库，内核完全自研，是关键基础软件自主可控的代表性产品。十五年来，它在金融这一对可靠性要求最为严苛的领域，经过了长期、大规模的真实锤炼——目前已服务超过400家金融机构，近七成万亿级资产规模的银行，将核心系统建在它之上，并连续三年在中国金融行业分布式数据库本地部署市场中份额排名第一；同时，它是迄今唯一同时在TPC-C、TPC-H两项国际权威基准测试中登顶的数据库，与全球顶尖产品同台竞技并取得领先，业务已覆盖全球多个国家和地区。

数据不出错、系统不中断、故障毫秒恢复——AI时代所说的这些"刚需"，在金融级场景中早已锤炼成熟。把这套能力延伸到"湖"，对OceanBase而言，是站在十五年地基之上的下一步。

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

OceanBase AI数据库把数据湖的开放与海量存储能力，数据库的事务、分析与实时处理能力，以及AI所需的多模态理解、语义检索和模型调用能力，统一到同一个强一致的数据底座之上。从架构层面消除AI应用落地中的系统复杂性，让现代数据与现代工作负载可以在统一架构中协同处理。

在此次发布中，OceanBase AI数据库并不只是推出单一引擎能力，而是形成了完整的产品体系。

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

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

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

合在一起看，OceanBase AI数据库产品体系覆盖从底层数据引擎、数据生产治理到业务智能入口的关键环节：Lakebase解决AI时代的数据底座问题，DataStudio解决数据如何被生产、治理和服务化的问题，DataPilot解决业务人员如何直接使用数据智能的问题。

一句话定义

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

在这套体系中，OceanBase Lakebase是OceanBase数据库面向湖库一体、Agent与多模态数据的核心引擎。它要解决的不是单点能力问题，而是AI时代数据底座的系统性问题：如何让不同形态的数据、不同类型的工作负载，以及不同计算引擎，在同一架构中协同运行。

第一，湖库一体：让多模态数据在同一底座上被实时处理

过去，结构化数据通常放在数据库里，文档、图片、音视频等非结构化数据放在对象存储或数据湖中，两者依赖外部链路关联。到了AI时代，智能体需要的上下文天然跨越多种数据形态：一笔交易、一段客服录音、一张发票图片、一份合同文本，只有被放在一起理解，才构成完整的业务事实。

OceanBase Lakebase通过湖库一体架构，将数据湖的开放格式与海量存储能力、数据库的结构化管理与在线服务能力统一起来，把结构化、半结构化和非结构化数据纳入同一套元数据、权限、事务和生命周期管理体系。数据不必在多个系统之间反复搬迁和复制，就可以直接支撑在线服务、实时分析和AI应用运行。

第二，多模表与AI列：让非结构化数据成为数据库中的一等数据资产

OceanBase Lakebase的多模表让结构化字段、文本、图片、音视频、JSON、LOB、向量等数据形态进入同一张表的语义之下。用户看到的仍然是一张表，但表背后可以承载更丰富的数据资产，并在同一套治理体系中被检索、计算和调用。

在多模表之上，AI列进一步把模型能力引入数据处理链路。它可以基于原始数据生成摘要、标签、特征、向量或其他语义结果，让模型理解能力以"列"的形式进入数据库。这样，企业不必把数据反复搬出数据库、交给外部模型处理后再写回，而可以在数据原地完成语义加工、向量化、重排与智能生成。这意味着，非结构化数据不再只是"被存下来的文件"，而成为可搜索、可计算、可治理、可被Agent安全调用的数据资产。

第三，Agent友好：支撑AI应用从试验走向规模化运行

Agent对数据库提出了新的要求。它不仅需要查询数据，还需要长期记忆、会话上下文、业务状态和执行记录；不仅需要结构化查询，还需要向量、全文与结构化数据的混合搜索；不仅需要读数据，还需要在隔离环境中不断试错、生成中间状态并安全回滚。

围绕这些需求，OceanBase Lakebase原生支持面向Agent的实时上下文工程：统一存储和检索Agent的记忆、上下文、状态与行动记录，并通过向量、全文、结构化数据的混合搜索，为Agent提供更准确的上下文供给。同时，OceanBase Lakebase通过数据分支、逻辑库、资源隔离和快速回滚，为海量Agent应用快速创建独立、安全的数据环境。每个智能体或轻应用都可以拥有相互隔离的数据空间，在不影响主干数据的前提下试错、运行和演进。这让AI应用能够从验证阶段走向规模化生产运行。

第四，开放生态：连接现代数据与AI技术栈

AI时代的数据处理不会只发生在一种引擎里。在线交易、实时检索、批量分析、多模态加工、模型训练和推理，往往会同时发生在同一批数据之上。

OceanBase Lakebase基于开放式存储格式与可扩展计算架构，支持S3兼容对象存储与Iceberg开放表格式，并可对接Spark、Ray等计算引擎。不同计算引擎围绕同一份数据和同一份元数据协同工作，各自负责擅长的计算任务，而无需迁移数据或重建数据底座。这带来的价值，是让企业的数据架构保持开放和可演进，未来新的计算引擎也可以在同一数据基础上扩展。

第五，一体化设计：降低AI落地的工程复杂性

相比多系统拼装，OceanBase AI数据库的核心价值不只是"少部署几个系统"，而是从架构层面减少数据冗余、缩短处理链路、统一治理口径，并降低开发与运维复杂度。

在一个系统中同时承载事务处理、实时分析和AI工作负载，意味着企业不必为交易库、数仓、搜索引擎、向量库、数据湖分别维护一套链路。数据只需治理一次、权限只需定义一次、元数据只需维护一套，应用就可以在统一底座上获得可靠、实时、可扩展的数据能力。

据介绍，在相关场景中，OceanBase AI数据库可使整体TCO降低30%-50%。这背后不是简单的成本压缩，而是AI基础设施门槛的降低：当企业不必依赖多套系统拼装复杂链路，AI应用才更容易从试点走向规模化落地。

目前，OceanBase的AI数据库已在蚂蚁阿福、灵光等核心场景完成业务验证。

其中，灵光已承载3000万个由AI生成的闪应用。面对海量应用独立数据空间、动态Schema与SQL计算能力的需求，OceanBase通过面向海量Agent与轻应用的逻辑表，将每个闪应用的Schema与数据映射为可查询、可计算的逻辑表，避免"一应用一物理表"带来的元数据和资源开销，让AI生成应用可以使用标准SQL完成过滤、聚合、Join等计算，支撑千万级闪应用低成本、安全地运行在同一套数据库基础设施上。

这不只是成本数字的优化，更是一道普惠的门槛——让更多企业，而不只是头部巨头，可以负担得起AI落地的基础设施。让企业用得起AI，才有谈AI普惠的可能。

谈到这里，有必要把时间维度拉得更长一些。

从十五年前"双十一"被一行行代码逼出来，到今天在AI最前沿的场景中持续打磨——OceanBase一直是被真实的场景推着往前走。移动互联网催生了分布式数据库，我们在那个时代证明了中国基础软件能做到全球领先；AI时代正在催生新的数据底座，我们要在这个时代，再造一个OceanBase。

数据库正在经历一次角色的根本性转变：从"存放数据"，到"承载智能"。

下一个十年，OceanBase的目标只有一个——再造一个"AI时代的OceanBase"。

整场直播听下来，我有一个总体感受：OB在AI时代的战略，不是"追逐热点"，而是"回归本质"。它没有去卷模型参数、没有去炒Agent概念，而是老老实实回答一个问题：当AI成为基础设施，数据底座该怎么造？

这个问题的答案，不在PPT里，而在生产环境的日志里。3000万闪应用、400+金融机构、TPC-C/TPC-H双登顶——这些数字背后，是真实的场景、真实的锤炼、真实的信任。

作为一个老OBer，我期待的不是下一个"爆款功能"，而是下一个经得起生产环境检验的架构迭代。AI时代的数据库，最终要回答的，和十五年前一样：数据不出错、系统不中断、故障能恢复。

变的是用法，不变的是底线。这句话，既是OB的宣言，也是它的约束。

本文基于OceanBase Hours直播内容的技术观察，仅代表个人视角，不代表OceanBase官方立场。