Agent成为数据库新用户，AI数据库为什么必须走向湖库一体？

过去三年，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的路径是从数据库内核出发，把过去在核心交易场景中积累的事务一致性、高可用、实时处理和弹性扩展能力，延伸到湖、非结构化数据和多模态数据之上。杨传辉在采访中提到，OceanBas