过去三年，AI 行业最热闹的故事几乎都围绕模型展开：参数规模、推理能力、上下文长度、智能体能力、多模态能力不断刷新。但当企业真正把 AI 放进业务流程时，另一个问题开始变得突出：模型能力越来越强，算力投入也越来越大，为什么 AI 的业务价值并没有同步兑现？
答案往往不在模型本身，而在数据。
Agent 成为数据库新用户，哪些东西变了？
通用大模型可以理解通用知识，却天然不了解一家企业自己的业务逻辑。它不知道某个客户的历史订单，不知道一次投诉背后的通话录音，也不知道一张发票图片与哪笔交易相关。要让 AI 从“懂很多”变成“懂这家企业”，关键要素是企业能否持续、实时、准确地把业务上下文供给给 AI。
这也是 OceanBase 此次提出 AI 数据库的背景：AI 竞争的下半场，焦点正在从“谁的模型更强”转向“谁能让 AI 真正读懂业务”。数据库也因此被重新推到舞台中央。
它不再只是业务系统背后的存储和查询工具，而开始成为 AI 应用能否进入生产系统、能否参与业务决策的关键底座。
更根本的变化是，数据库迎来了一个新的使用者：Agent。
Gartner 在去年 6 月发布的预测中提到，到 2028 年，至少 15%的日常工作决策将由 Agentic AI 自主完成，33%的企业软件应用将内置 Agentic AI，而 2024 年这一比例还不到 1%。
路透社在报道这一预测时也指出，虽然超过 40%的 Agentic AI 项目可能会因成本、商业价值不清等问题在 2027 年底前被取消，但 Agent 进入企业软件和业务决策链条，已经是明确趋势。
这意味着，Agent 不再只是企业软件上方的聊天入口，而会变成一个持续调用系统、读取数据、生成判断并执行动作的新型使用者。
过去，数据库的主要用户是人和应用系统。工程师写 SQL，业务人员看报表，应用程序按照预设逻辑读写数据。数据库的核心任务，是把订单、账户、交易、库存等事实准确记录下来，再按照人的需求被查询、分析和归档。
Agent 的到来改变了这一点。人类用户不再满足于借助智能体偶尔查询数据等基础工作，还希望它们成为能持续运行、自动调用数据、根据上下文做判断并执行任务的“硅基用户”。
它需要在毫秒到秒级时间内完成查询、检索、推理和行动，并且这种调用不是一次性的，而是高频、自动、连续发生的。
这带来了三类新要求。
第一是上下文。Agent 的一次回答，本质上是“上下文加模型调用”的结果。上下文越完整、越准确，结果越可靠。但真实业务上下文从来不是单一表格里的几行字段。一笔订单可能关联客服录音、物流轨迹、合同文本、发票图片、用户画像和历史投诉。Agent 要理解的是完整业务事实，而不是割裂的数据片段。
在采访中，OceanBase 举了一个医疗问答类场景：用户 10 点上传一张照片，系统给出初步判断；10 点 01 分，用户又补充另一张图片和新的描述。如果图片、时间、用户记忆、判断结果分散在不同系统里，Agent 很难保证所依据的信息是一致且实时的。一旦上下文错位，结果就可能出错。类似问题也存在于营销、客服、风控和内容安全等场景中。比如一通营销电话背后的语音内容，需要和客户订单、信用卡权益、历史投诉以及情绪判断实时关联，才能支撑后续动作。
第二是规模。AI 正在降低应用生成成本，“一个应用一个库”的逻辑正在变成“一句话生成一个应用”。蚁灵光已经承载 3000 万个闪应用，企业内部也出现了上万个轻量应用。这些应用的共同特点是：单个数据量并不大，平均可能只有百余行数据，但数量极多，而且大量处于沉睡状态。只有在被调用时，才需要迅速唤醒并秒级响应。
这意味着，AI 时代的“海量”不只是单库数据量变大，而是数据库实例、轻应用、智能体环境的数量爆发。数据库需要支持高密度共存、资源隔离、按需启用和低成本闲置，而不是只解决传统意义上“把一个库做大”的问题。
第三是进化。Agent 不是一次开发完成后长期不变的软件。复杂智能体需要不断试错、评测、回滚和迭代。尤其是高复杂度 Agent，一次功能改动可能影响最终行为，因此需要端到端评测环境，需要把真实业务数据克隆出来做测试，又不能影响主干数据。换句话说，数据库不仅要支撑 Agent 读写数据，还要支撑 Agent 的实验、分支、隔离、回滚和持续演进。
从记录事实，走向参与决策
这也是为什么数据库的角色正在发生历史性变化：从记录事实，走向参与决策。
过去，数据库只需要“如实记录”。一笔交易发生了，就把它存下来；一张订单生成了，就把它归档好。AI 时代，数据库中的数据不只是被事后查询，而会直接进入 Agent 的决策链条。
尤其是在风控审核、内容安全、营销触达、客服响应等场景中，Agent 的判断可能直接影响用户体验和业务结果。
这也让数据库的底线变得更重要，而不是更不重要。
一致性过去是核心交易系统的高标准，到了 AI 决策链路中，它可能变成生死线。因为 Agent 一旦基于错误、过期或不一致的数据行动，风险就不再只是查询结果有误，而可能演变成错误拦截、错误推荐、错误回复甚至错误业务操作。
实时性也从“体验优化”变成“决策前提”。如果 Agent 面对的是在线业务，它不能依赖隔夜跑批后的数据，也不能等待多个系统之间异步同步完成后再行动。它需要在线数据、实时分析、语义检索和模型调用之间形成更短链路。
这正是传统数据架构开始承压的地方。过去企业常见的数据架构，是交易库、数仓、数据湖、搜索引擎、向量库、对象存储等多套系统拼装而成。结构化数据放在数据库里，文档、图片、音视频放在对象存储或数据湖里，向量检索又放在另一套系统中。这样的架构在传统 BI 和离线分析时代可以运行，但到了 Agent 时代，问题会变得突出：数据被反复复制，权限和元数据分散，链路变长，一致性难以保证，实时性也容易被牺牲。
因此，AI 数据库不是在传统数据库旁边加一个向量检索插件，也不是简单把对象存储和数据库拉一条线连起来。它需要重新回答一个问题：在 AI 驱动的世界里，结构化、半结构化和非结构化数据，如何在同一个底座上被组织、治理、理解和调用？
OceanBase 给出的答案是湖库一体。
真正的 AI 数据库该是什么样子
6 月 29 日，OceanBase 发布面向 AI 时代的湖库一体 AI 数据库，提出以湖库一体为核心架构，将数据湖的开放与海量存储能力、数据库的事务处理与分析能力，以及多模态数据处理能力统一到一套强一致的数据底座上，帮助 Agent（智能体）一次获取完整业务上下文，让 AI 真正“读懂”企业。
围绕这一能力，OceanBase AI 数据库 同步形成覆盖数据引擎、数据治理与业务入口的产品体系，包括 Lakebase、DataStudio、DataPilot 等，并已在蚂蚁阿福、灵光等 AI 场景完成业务验证。
所谓湖库一体，核心不是概念拼接，而是把“库”的事务、一致性、实时处理能力，与“湖”的开放、海量存储、多样化计算能力统一到一个底座上。
数据库负责强一致、在线服务和核心交易能力，数据湖负责开放格式、海量数据和多计算引擎协同。AI 时代的要求，是让两者不再割裂。
这也是 OceanBase 与一些从湖、仓或搜索路线出发的方案之间的主要差异。
OceanBase 的路径是从数据库内核出发，把过去在核心交易场景中积累的事务一致性、高可用、实时处理和弹性扩展能力，延伸到湖、非结构化数据和多模态数据之上。杨传辉在采访中提到，OceanBase 这一路线更偏在线；相比偏离线、大规模训练或分析的路线，它更关注 Agent 实时决策场景中的一致性和实时性。
具体到产品体系，此次 OceanBase AI 数据库包括 Lakebase、DataStudio 和 DataPilot 三个层次。
Lakebase 是底层引擎，面向湖库一体和多模态数据管理，承担结构化数据、非结构化数据和向量数据的统一管理、加工、检索和调用。DataStudio 是运行在 Lakebase 之上的数据生产、治理与服务工作台，覆盖数据接入、数据加工、任务编排、语义建模、数据治理到 Agent 协作等环节。DataPilot 则面向经营分析和业务决策，让业务人员通过自然语言生成分析报告、数据看板和可信答案。
其中，最值得关注的是 Lakebase 中的多模表和 AI 列设计。
多模表试图把结构化字段、文本、图片、音视频、JSON、LOB、向量等不同数据形态，放到同一张表的语义之下。
用户看到的仍然是一张表，但这张表背后承载的不再只是传统关系型字段，而是完整的多模态业务对象。比如一笔交易既可以包含金额、时间、账户等结构化字段，也可以关联发票图片、客服录音、合同文本和向量表示。
AI 列则进一步把模型能力引入数据库内部。它可以基于原始数据生成摘要、标签、特征、向量或其他语义结果，让模型理解能力以“列”的形式进入数据处理链路。这样，企业不必把数据搬出数据库，交给外部模型处理后再写回，而可以通过数据库函数、任务或 AI 列，把语义加工、向量化、重排和生成结果纳入数据处理链路，减少数据搬运和反复回写。
OceanBase CTO 杨传辉在发布会后的采访中提到，“多模态处理并不是简单把文件放进去就结束。比如每一行数据可能都要做 embedding，可能调用不同模型，有人调用千问、有人调用 DeepSeek，也可能在语音抽帧、图像处理或向量生成环节失败。因此，OceanBase 希望让这些多模态加工动作具备类似事务的一致性：要么一起成功，要么一起失败。这一点体现了数据库内核路线与外部系统拼装路线的差别。
另一个变化是语义层的重要性上升。过去，语义层更多服务 BI 和报表，未必是数据库公司的核心能力。但在 Agent 时代，数据库里的表名、字段名和业务关系，必须变成 AI 能理解的业务语义。仅有 schema 不够，还需要描述这个表是什么、字段代表什么、业务实体之间如何关联，以及这些语义如何随业务变化持续更新。OceanBase 方面认为，语义层会成为 AI 数据库的原生能力之一，而不是外部附加模块。
从行业角度看，这一判断有其现实背景。
企业过去沉淀的大量非结构化数据，长期只是归档和备份资产。文档、邮件、产品手册、客服录音、视频、图片，很多时候只有在审计、监管或事后复盘时才被调用。AI 的出现，让这些数据第一次具备了被理解和计算的可能。但要真正进入业务决策，它们必须和结构化数据放在一起被治理、检索和使用。
例如在智驾、具身智能、地图和本地生活等场景中，视频、图片、地理位置、行车轨迹、POI 信息往往天然混合在一起。高德相关场景中，高精度 POI 需要从大量图片、视频和位置数据中持续更新。如果不先把非结构化数据和结构化信息关联起来，而是直接把长视频全部送进大模型处理，成本和效率都难以承受。这类场景需要数据库在更靠近在线业务的位置完成预处理、关联、检索和语义加工。
当然，OceanBase AI 数据库仍处在早期阶段。据介绍，相较传统多系统方案，OceanBase AI 数据库可降低整体 TCO（Total Cost of Ownership，总体拥有成本）约 30%-50%。
针对这一数据，采访中杨传辉和 OceanBase CEO 杨冰给出了相对谨慎的解释：这一估算主要来自传统技术架构与湖库一体架构的对比。
传统方案往往需要四到五套技术栈，迁移到统一底座后，有些系统可以被合并或减少，因此在存储和部分计算成本上形成下降。杨冰也提到，一些大型场景仍在迁移过程中，精确数据还在变化，这一数字更接近基于架构对比和已有经验形成的估算，而不是所有场景下都能直接套用的结论。
这点很重要。AI 数据库不是一个简单的新功能，也不会因为一次发布就完成行业切换。企业是否采用，取决于 AI 应用进入核心流程的速度，也取决于企业自身的数据基础、治理水平、成本结构和业务风险承受能力。
但趋势已经比较清楚：当 Agent 成为数据库的新用户，数据库面对的不再只是人类查询和固定应用逻辑，而是持续运行、实时决策、不断试错的智能系统。它需要看到的不再是一张张表格，而是完整的多模态业务世界。结构化、半结构化、非结构化数据必须被统一管理；在线服务、离线分析和模型调用必须形成闭环；事务、一致性、实时性、高可用这些传统数据库能力，也必须延伸到 AI 工作负载中。
这就是 OceanBase 所说 AI 数据库必须是湖库一体的核心逻辑。
如果把数据库的发展放回更长的技术周期里看，每一代数据库其实都对应着一代计算范式。
关系数据库解决的是企业信息化时代“把业务记录下来”的问题；数仓解决的是管理者“事后看清楚业务”的问题；大数据平台解决的是互联网时代数据规模突然膨胀后的存储与计算问题。
到了 AI 时代，问题又变了。
企业不再只是希望系统把发生过的事情记下来，也不再满足于事后生成一张报表。它们开始希望 AI 能直接进入业务现场，理解一个客户、一笔交易、一次风险、一段对话，然后给出判断，甚至执行动作。数据库因此被推到了一个更靠前的位置：它不再只是安静地站在后台，等待别人来查数据，而是要把分散在表格、文档、图片、语音、日志里的业务事实，组织成 AI 能理解、能调用、能信任的上下文。
这也是 Agent 带来的真正变化。
对 OceanBase 来说，AI 数据库不是一次简单的产品加法，而更像是一次路线延展。
它过去积累最多的地方，是分布式数据库、金融核心系统、高可用、强一致和在线交易能力。这些能力在传统数据库时代主要服务于“不能出错”的交易系统；到了 AI 时代，它们开始变成 Agent 进入生产环境的底线。
因为一旦智能体开始参与风控、客服、营销、审核和经营分析，数据是否实时、是否一致、是否可回滚，就不再是技术细节，而会直接影响一次判断、一次响应，甚至一次业务结果。
最后的最后，湖库一体、多模态、语义层、Agent 友好，这些概念最终不能停留在发布会里，而要经得起企业真实业务的考验。但可以确定的是，AI 正在改变数据库的使用方式，也在改变数据库的行业位置。
过去数据库回答的是“数据如何被存下来”，现在它必须回答一个更难的问题：当 AI 开始替人理解业务、参与决策时，什么样的数据底座才能让它看得全、看得准、信得过。
