而一同被推向舞台中央的，还有数据库。
过去，它扮演的角色很简单，本质就是一个长期、安全、可查询的数据存储系统。比如用户在淘宝购物，完成了下单、支付、退款、查物流等一系列操作，最基本的需求就是这些记录不能丢失、不能出错、可查询，以及能支撑高峰期几亿人同时下单的高并发压力。
这就是移动互联网时代数据库的核心能力，围绕着存储和查询，衍生出一致性、并发处理和容灾备份的需求。
但是当 Agent 越发深入地走进生产场景，它们也自然而然地成为了数据库的新用户。Agent 需要实时访问各种结构化和非结构化数据，数据库也从服务于人写 SQL 查数据的存储模块，变成了 Agent 的记忆系统。这个新的角色，意味着数据库在存储之外，还要支撑 RAG（检索增强生成）和实时数据流驱动的 AI。
RAG 场景下，AI 回答问题需要从数据库召回资料再生成回答，没有数据库就等于 AI “失忆”。而实时数据流驱动的 AI，更有赖于毫秒到秒级的用户行为数据实时读取。这两者是今天 Agent 落地最常见的两种场景。
可以说，当我们讨论 Agent 是否已经迈过那条名为“可用”的界限时，数据库的重要程度，并不亚于模型智能水平。
那么 AI 时代，到底需要什么样的数据库？
01
据 Gartner 预测，到 2028 年，AI Agent 生态系统将能够使多个专业化的智能体在不同企业应用间动态协作。届时，约有三分之一的用户体验将从使用原生应用，转向由 Agent 前端来主导。
数据库是这种转变的一个鲜明代表。当 Agent 成为数据的使用者，对数据库的访问频率将远远高于工程师逐条编写查询。如果人们对 Agent 的需求是是毫秒之间自动完成查询、推理与决策，那么这种压力会直接传导到数据库上。换言之，对 Agent 的想象决定了数据库在 AI 时代面对的是何种需求。
前者在今天已经并不陌生，透过从 OpenClaw 到 Harness 的爆火，能够看到一些一脉相承的东西，比如持续运行、自主调用数据，并通过不断试验完成任务。在这套全新的工作模式中，如何才能让 Agent 把数据物尽其用？
首先是准确的上下文供给。智能体的所有动作，从简单的问答、一次工具调用到长程任务的执行，都可以被拆解为一段上下文加一次模型调用的不断重复。能不能把对的信息，精准地组织成喂给模型的上下文，直接决定了 Agent 的交付质量。来自真实场景的上下文类型杂糅，会议录音、往来文件或者一张匆忙拍下的照片，或许全部结合起来，才构成一条对业务的有效指引。这就要求数据库能在一次检索中，从多种形态的数据中找出最相关的信息。
在诸多上下文中，自然语言作为 Agent 与数据库交互的全新入口，具有着独特的地位，或者说语义层对数据库从未如此重要。从存储模块走向记忆系统的过程中，数据库也在参与 Agent 的推理与决策。因此只有理解了业务，数据库才能真正服务于 Agent 这种高度灵活、主动的应用形态。
Agent 规模的爆发是另一重考验。一种观点认为，Vibe Coding 的尽头是用完即弃的一次性软件。很多证据都指向了这种应用数量的指数级爆发，蚂蚁灵光已有 3000 万个闪应用，妙思在企业内部支撑了上万个应用，每个应用背后，都需要一个独立的数据空间和可操作的数据能力。
值得注意的是，上述每个应用平均仅有百余行数据。这是另一种意义上的数据规模，单个应用数据量并不大，但数据库在爆发式增长。AI 时代数据库面对的局面，就是大部分库在大部分时间都处于沉睡，但极少数需要被访问时，又要做到秒级响应。
一个数据库抗住大规模负载的时代正在远去，眼下的问题，是如何让海量Agent拥有独立数据空间同时以极低成本共存。
最后是自我进化，这种复杂 Agent 的前沿方向，同样体现在了对数据库的需求上。从 skill 开始，Agent 实现自我进化的思路大同小异，都是对既往经验进行总结，识别最佳实践，并在重复执行中完成优化。因此，一个能够让 Agent 反复试验的环境至关重要。数据底座将在很大程度上承担这一任务，随时开辟一个彼此隔离的试验空间，让 Agent 在其中放手尝试，好的实践保留、不行的方案丢弃。
在上述过程中，数据飞轮是一个绕不开的话题。更多的数据，意味着更强的模型、更好的用户体验已经是共识。但追问一步，就会发现这并不是理所当然的结果，至少在数据库层面不是。
事实上，在这个飞轮中同时存在着两种数据。在线数据实时提供给模型以驱动智能体，离线数据被积累下来训练下一代模型。要让这个飞轮真正转起来，在线数据与离线数据、实时计算与批量计算就必然不能长期处于彼此割裂的系统中。
同步发生的另一重变化，是数据形态。一个已经成为现实的共识是，Agent 会最先在数字化水平更高、结构化数据积累更丰富的行业落地。结构化数据因其便于计算的特性，为 Agent 提供了一条在业务场景落地的快车道。但是当落地应用的竞争进一步激化，对非结构化数据的挖掘和利用就成为了必然选择。
这也是 Agent 价值释放的切口。不是简单的存储或索引非结构化数据，而是让它和结构化数据在统一底座上被管理和调用。统一底座上的多模态混合搜索，就是 Agent 对数据库提出的新需求。
02
至此，下一代数据库的画像已经逐渐清晰。
面向 Agent 的业务负载，决定了下一代数据库首先需要一套统一的数据底座。只有当数据不再被切割、不必在多套系统之间反复搬运，“越用越准”的飞轮才真正成立。
建立统一底座之后，真正需要统一的还有数据本身。结构化、半结构化和非结构化数据，需要在同一体系中完成存储、管理和计算，并支持标量、全文、向量等多种检索方式的混合搜索。只有让跨模态数据在统一语义下组织和调用，数据库才能为 Agent 提供完整、准确的业务上下文，将历史积累的非结构化数据真正转化为可用的业务资产。
更进一步，AI 数据库还需要成为 Agent 原生的数据底座。记忆、上下文、隔离、分支、回滚以及规模化运行等能力，不应依赖多个外部系统拼装，而应成为数据库自身的原生能力。同时，面对企业高度敏感的数据资产，数据库还需要保持开放的存储与计算架构，避免数据被锁定在单一厂商体系中，让企业始终拥有数据主权与架构演进的主动权。
回到 GPT-3.5 的发布，亲历者会记得它彼时带来的轰动，人们相信“一切行业都值得用 AI 重做一遍”。这很容易走向一种开创全新品类的幻觉，但对 AI 数据库来说，事实恰恰相反。 Agent 只是改变了它的面向，但过去的设计原则在今天仍然重要。
智能体高度自主的特性决定了它必然会向决策层迈进，这反过来让数据库本身也在从记录事实走向参与决策，因而对数据底座的一致性提出了更高的要求。未来一处错误，一次延迟，都有可能演变成真实的业务事故。为此更需要有超越单纯检索的强一致保障，才能使其胜任 Agent 的在线决策。
可靠的另一重意涵是实时性。数十个小时的长程任务对今天的 Agent 已经不是触不可及，当模型智能水平足以面对这种复杂度的任务目标时，还需要有足够可靠的数据底座支撑。Agent 能全天候运转，数据库能否在脱离运维人员的情况下跑下去？Agent 以毫秒级的速度进行推理和决策，数据库能否跟上这种节奏？
既要保持强一致性与实时性的可靠，为 Agent 挣得一张进入真实业务场景的门票，又要有支持规模扩展的开放架构，以适应 Agent 这种全新的服务形态本身。这是两种南辕北辙的需求吗？
如果把这些需求放在一起看，会发现它们都指向同一种架构，湖库一体。
湖库一体的核心，不是简单把数据湖和数据库放在一起，而是在统一的数据底座上兼顾两者的优势：既拥有数据湖的开放性和海量存储能力，又保留数据库的事务、一致性和实时处理能力。一份数据即可同时支撑在线业务、实时分析和 Agent 应用，无需在多个系统之间重复同步和搬运。
站在 Agent 的需求上回看，这几乎是为 AI 数据库量身定做的架构。Agent 同时依赖结构化数据、非结构化数据和向量数据，也需要在线事务、实时分析和 RAG 检索协同工作。统一的数据底座既减少了重复存储和数据同步，也降低了构建 RAG、企业知识库和 Agent 应用的整体成本。
不过，走向湖库一体并不只有一种路径。有人从数据湖出发，补齐数据库能力，有人从搜索出发，扩展向量和结构化数据处理能力。这些路径各有侧重，也分别解决了开放存储或智能检索的问题。
但是当 Agent 走进真实业务场景，找得到或存得住都远远不足以概括数据底座面对的全部挑战。它还需要强一致的数据事务、严格的权限体系、可信的数据版本、稳定的实时能力，以及能够长期演进的工程架构。真正的数据底座，需要同时满足这些要求，而不是分别优化某一项能力。
也正因为如此，OceanBase 提出了另一种可能。从数据库内核出发，把已经在核心交易场景中验证过的事务一致性、高可用、实时处理和弹性扩展能力，进一步延伸到湖、非结构化数据和多模态数据之上。
这也是它区别于前面两种选择的地方。相比把"湖"和"库"简单组合，OceanBase 希望以数据库内核作为统一基础，让事务能力与开放存储、多模态数据和 AI 计算在同一架构中协同运行，真正实现“湖库一体”，而不是系统拼装。
你能从这种统一架构设计的背后看到不俗的野心，它指向的并不仅仅是 AI 时代一席数据库市场，而是某种堪称 Agent 数据底座的战略卡位。当 Agent 成为企业应用的新入口后，OceanBase 的目标并非提供更多 AI 功能，而是降低 Agent 落地过程中数据同步、系统拼装和治理带来的巨大工程成本。
回到今天 Agent 落地的真实困境，就会看到 OceanBase 这一战略判断尖锐的一面。眼下限制 AI 价值兑现的越来越不是模型能力，而是数据基础设施。API 价格持续下降，但企业部署 Agent 依然昂贵，成本就产生在多套数据系统、复杂的数据链路和治理体系的摩擦中。谁能够把这些复杂性收敛到统一的数据底座，谁就更有机会成为企业 Agent 时代的基础设施提供者。
从这个意义上看，OceanBase 试图重新定义数据库的竞争维度。未来竞争的不再是谁拥有更强的数据库能力，而是谁能够成为 Agent 时代真正的 Memory Runtime。如果这一判断成立，数据库将在 AI 产业链中重新回到核心位置，而 OceanBase 的角色，也将从数据库厂商进一步演变为 Agent 时代的数据操作系统。
03
算力、模型和数据，在 AI 的三要素中，数据库占据了尤为核心的地位。可以说，谁能更好地连接和治理企业核心数据，谁就更有机会在 AI 应用落地中占据关键位置。今天能兑现的商业价值，明天通向 AGI 的想象空间，都在这里了。
诸多因素的叠加之下，数据库在 Agent 落地的角逐中成为了一片兵家必争之地。业内的竞争逐步激化，上下游厂商同样虎视眈眈。狭路相逢，此时站出来试图定义 AI 数据库这种全新形态的 OceanBase，却也不是无名之辈。
对数据库行业了解不多的读者或许没有听过这家公司的名字，但对“双十一”一定并不陌生。OceanBase 的诞生就和这场全球规模最大的线上购物狂欢节紧密相连。
2010 年前后，阿里业务的高速增长，特别是“双十一”带来了爆炸性的数据增长和高并发请求。以 IBM 小型机、Oracle 数据库、EMC 存储为核心的传统 IOE 架构成本高昂且扩展性有限，已经难以满足“双十一”的潜在需求。
OceanBase 最初就是为此而生。从 2014 年承接 10％ 交易流量，到两年后的全面接管，承载了支付宝 100％的核心业务流量，包括交易、支付、会员和最关键的账务库。今天在 OceanBase 身上能看到的分布式关系数据库、高并发交易、分析支持、强一致性、可水平扩展等基因，都是在这一时期奠定。
值得注意的是，OceanBase 的起点正是对数据库可靠性要求最为严苛的金融领域。在诞生之后的十五年中，又进一步经历了大规模的锤炼。
截至目前，OceanBase 已服务超过 400 家金融机构，近七成万亿级资产规模的银行，将核心系统建在它之上，并连续二年在中国金融行业分布式数据库本地部署市场中份额排名第一。同时，它也是迄今唯一同时在 TPC-C、TPC-H 两项国际权威基准测试中登顶的数据库，与全球顶尖产品同台竞技并取得领先，业务已覆盖全球多个国家和地区。
数据不出错、系统不中断、故障毫秒恢复，AI 时代所说的这些“刚需”，在金融级场景中早已锤炼成熟。把这套能力延伸到“湖”，对 OceanBase 而言，是有着十五年积累的谋定而后动。
而得益于阿里、蚂蚁丰富的前沿 AI 业务场景，如支付宝的 AI 支付、蚂蚁阿福、灵光、淘宝 AI 购物助理，以及通义千问、高德、飞猪等，OceanBase 在定义 AI 数据库这条路上有着得天独厚的优势。其中，蚂蚁阿福面向行业复杂智能体开发，灵光则面向大众提供“一句话生成应用”能力，目前已承载 3000 万个闪应用。在积累数据的意义之外，这些场景更是 AI 数据库最真实的练兵场。
时至今日，OceanBase 已经超越了单一引擎能力的范畴，形成了完整的 AI 数据库产品体系：
OceanBase Lakebase：作为底层引擎，承载湖库一体与多模态数据能力，让结构化数据、非结构化数据和向量数据能够在统一架构中被管理、加工、检索和调用。
OceanBase DataStudio：运行在 Lakebase 之上的数据生产、治理与服务工作台，覆盖数据接入、数据加工、任务编排、语义建模、数据治理到 Agent 协作等关键环节，帮助企业把分散的数据资产转化为可管理、可理解、可调用的数据服务。
OceanBase DataPilot：面向经营分析和业务决策的数据智能 Agent，作为统一的企业业务智能入口，让业务人员可以通过自然语言完成分析报告、数据看板和可信答案生成，把过去依赖专业数据团队完成的分析流程，转化为可交互、可追问、可复用的智能决策能力。
这套产品矩阵覆盖了从底层数据引擎、数据生产治理到业务智能入口的全部关键环节。Lakebase 解决 AI 时代的数据底座问题，DataStudio 解决数据如何被生产、治理和服务化，DataPilot 则站在距离一线业务人员最近的位置，直接处理人和数据智能的衔接。
这里面尤其值得一提的是作为 AI 数据库核心引擎的 OceanBase Lakebase。
传统数据库引擎的目标是高效管理结构化数据，并提供可靠的事务处理和 SQL 查询。OceanBase Lakebase 则在此基础上，统一管理结构化、半结构化、非结构化和向量数据，让事务处理、实时分析、AI 推理和 Agent 应用围绕同一份数据协同运行。这不是在传统数据库上增加几个 AI 功能的变化，而是面向 AI 应用对数据形态、检索方式和计算模式全新需求的范式转变。
前面的分析曾经提到，支持多模态数据在统一底座上的实时处理，是 AI 数据库需要实现的核心功能之一。但海量非结构化数据到底如何真正成为数据资产，也是长期困扰企业的问题之一。
对此，OceanBase Lakebase 提出了多模表和 AI 列的全新设计。前者让结构化字段、文本、图片、音视频、JSON、LOB、向量等数据形态进入同一张表的语义之下。用户视角，看到的仍然是一张表，但多模表背后却可以承载更丰富的数据资产，并在同一套治理体系中被检索、计算和调用。
多模表之上，AI 列进一步把模型能力引入数据处理链路。它可以基于原始数据生成摘要、标签、特征、向量或其他语义结果，让模型理解能力以“列”的形式进入数据库。这样，企业不必把数据反复搬出数据库、交给外部模型处理后再写回，而可以在数据原地完成语义加工、向量化、重排与智能生成。这意味着，非结构化数据不再只是“被存下来的文件”，而成为可搜索、可计算、可治理、可被 Agent 安全调用的数据资产。
作为 Agent 的记忆系统，OceanBase Lakebase 同样原生支持面向 Agent 的实时上下文工程，通过统一存储和检索 Agent 的记忆、上下文、状态与行动记录，并通过向量、全文、结构化数据的混合搜索，为 Agent 提供更准确的上下文供给。
同时，OceanBase Lakebase 通过数据分支、逻辑库、资源隔离和快速回滚，得以为海量 Agent 应用快速创建独立、安全的数据环境。每个智能体或轻应用都可以拥有相互隔离的数据空间，在不影响主干数据的前提下试错、运行和演进。这让 AI 应用能够从验证阶段走向规模化生产运行。
开放生态是 OceanBase Lakebase 的另一个关键词。Agent 时代，企业的数据处理不再依赖单一计算引擎，而是同时涉及在线交易、实时分析、全文检索、向量搜索、模型训练和 AI 推理等多种工作负载。传统架构中，不同系统往往各自维护一份数据，需要频繁进行数据同步、复制和转换，不仅增加了成本，也带来数据延迟、一致性和运维复杂性等问题。
OceanBase Lakebase 要解决的正是这一痛点。它基于开放式存储格式与可扩展计算架构，支持 S3 兼容对象存储与 Iceberg 开放表格式，并可对接 Spark、Ray 等计算引擎。不同计算引擎围绕同一份数据和同一份元数据协同工作，各自负责擅长的计算任务，而无需迁移数据或重建数据底座。此外，当数据得以避免被绑定在专有平台，企业整体的数据架构便也保持了开放和演进的可能，未来新的计算引擎也可以在同一数据基础上扩展，这正是 OceanBase Lakebase 作为统一数据底座最具潜力的地方。
相比多系统拼装，OceanBase AI 数据库核心价值远不止于少部署几个系统，而是从架构层面减少数据冗余、缩短处理链路、统一治理口径，并降低开发与运维复杂度。
在 API 价格早已经过了几轮的降价之后，为什么 Agent 在很多企业中仍然难以真正被用起来，瓶颈就在于 Agent 落地的工程复杂性，以及与之伴随的时间、人力和金钱成本。
而当 OceanBase 提供了一个能够同时承载事务处理、实时分析和 AI 工作负载的一体化系统，也就意味着企业不必为交易库、数仓、搜索引擎、向量库、数据湖分别维护一套链路。数据只需治理一次、权限只需定义一次、元数据只需维护一套，AI 应用就可以在统一底座上获得可靠、实时、可扩展的数据能力。
据介绍，在相关场景中，OceanBase AI 数据库可使整体 TCO 降低 30%-50%。这背后不是简单的成本压缩，而是 AI 基础设施门槛的降低。当企业不必依赖多套系统拼装复杂链路，AI 应用才更容易从试点走向规模化落地。也只有让企业用得起 AI，才有谈 AI 普惠的可能。
回过头来看，每一轮技术革命真正沉淀下来的，不仅仅有最先引发关注的新能力，还有支撑这种能力规模化普及的基础设施。云计算如此，移动互联网如此，AI 也不会例外。当模型能力之间的差距越发缩小，能够让企业为之付费的，将不再仅仅是一款模型，而是一套能够承载数据、支撑 Agent、保障业务运行的完整基础设施。
数据库也在迎来这种历史转折。移动互联网时代的分布式数据库，正在演变为 Agent 时代的数据底座。未来 AI 数据库之间竞争的，也未必是谁拥有更多 AI 功能，而是谁能够以更低的成本、更高的可靠性和更开放的架构，让 Agent 真正走进企业核心业务。在这幅全新的竞争图景中，OceanBase 已经走得很远。
正在生成分享图...
木子