2026年6月29日，OceanBase在线上发布会上正式推出产品新形态，诸多特性既有当下关注的，又有立足于未来的考量。而我关注的重点在AI湖库一体。这也是我过去两年在实际工作中一直在实际接触的内容。
一、开源湖仓的现实困境
在过去的几年里，我所做的就是把各种开源工具拼凑起来，开源的对象存储、开源的Iceberg、开源的计算引擎、开源的ETL和CDC。再挂一个向量数据库做语义检索。这套方案看起来灵活开放，但Agent走向生产环境时，几个结构性缺陷就会迅速暴露。事务一致性是软肋。开源湖仓方案大多从湖出发，Iceberg就是如此。优先解决海量存储和开放格式，事务能力是后来补上去的，只能保证最终一致性。当Agent从辅助工具走向替人决策，它背后的数据就有了核心交易系统的属性。错一条、慢一拍，不是技术指标偏差，是业务事故。只做检索的系统扛不起这个责任。
拼装的工程复杂性被低估。我拼凑的开源架构涉及Iceberg、Spark、Flink、Kafka、Trino、Milvus多个组件，每个有独立的部署方式、版本兼容和监控体系。表面上是最佳实践，拼在一起运维复杂度却指数级上升。数据每经过一段链路，就是一次延迟累加和一致性风险。
Agent友好能力需要从零搭建。大家如果仔细看这个开源拼图，我这套开源组件是为人类分析师设计的，不是为Agent设计的。Agent需要的数据分支、逻辑库、资源隔离、按需唤醒、混合搜索，这些能力在开源生态中要么不存在，要么需要用户在应用层自己拼装。实现创建分支、隔离实验、有效合并最后无效回滚的完整链路，需要大量代码。而且实际测试中要命的是，质量和可维护性完全依赖用户自身工程能力。
多模态处理链路割裂。非结构化数据在开源架构中是独立离线管道，数据导出到外部AI平台处理，再写回。延迟大，且原始数据和AI加工结果分属不同系统，数据权限、数据血缘、生命周期管理各自为政。我还需要一个单独的工具比如Datahub去管理，整个运维全家桶又多了一件。
开源湖仓解决的核心问题是数据怎么存，成本怎么降，唯独不是Agent怎么用。从开源组件到Agent可用的数据底座，中间横着个巨大的Gap。
二、先有库，后有湖
与Iceberg从湖出发的路线不同，OceanBase走的是从库出发，向湖延伸。这是两种完全不同的技术哲学。
OceanBase的起点是支付宝核心交易场景，这个场景对数据一致性、系统可用性要求达到极致。而这条路径的独特价值在于事务一致性不是后补的能力，而是从第一行代码就内建的基因。当Agent走向替人决策，它对数据底座的要求与金融核心交易系统高度同构，能够实现强一致、高可用、实时响应。先有库后有湖，意味着这些能力是长出来的，不是拼上去的。
在这个地基之上，OceanBase的Lakebase把库的强一致和实时能力延伸到湖的领地。结构化、半结构化、非结构化数据统一在同一套元数据、权限、事务和生命周期管理体系下，数据不必在多套系统之间搬运复制。这也是我认为，AI Agent时代和过往数据湖仓时代最大的不同，过往基于ETL和CDC的湖仓，都是建立在一个假设的基础上，即数据是可以被搬运的。可是到了毫秒级别的Agent场景下，搬运来不及了。具有多模湖仓能力的数据库才是刚需。
多模表+AI列让AI理解能力成为数据库的原生功能。多模表让结构化列、JSON列、向量列、文本列、图片列存在于同一张表的语义之下。AI列把大模型理解能力以列的形式引入数据库，这就意味着我可以把研报PDF存进去，自动提取关键指标；把客户经理和客服的录音存进去，自动转写并标注情绪信号。加工发生在数据原地，存进去的那一刻理解就发生了，AI加工结果和原始数据共享同一套治理体系。
Agent友好设计回应了新使用者的核心需求。混合搜索让向量、全文、结构化数据在同一条查询中完成；数据分支像Git一样管理数据快照，Agent可秒级创建隔离实验环境；逻辑库和按需唤醒让海量Agent应用共享基础设施，闲时几乎不耗资源。这些是数据库内核的原生能力，不是应用层拼凑。
从数据治理和实际运维的角度，开放计算确保数据主权始终在用户自己手里。支持S3兼容对象存储与Iceberg开放表格式，可以让我根据之前的方案，直接对接Spark、Ray、Flink、Python生态。作为用户可以我在保证OceanBase原生的数据库级强一致和高可用的同时，自由切换计算引擎，不被任何专有系统锁定。
三、AI Agent能做什么
继续研究，我意识到一个问题，当湖仓一体、多模AI、Agent友好、开放计算这四个能力集成到同一个数据底座上，AI Agent的能力边界会被重新定义。
在传统架构下，一个研究员想查北向资金持续加仓、且机构评级上调、且无减持公告的锂电产业链公司，需要分别在行情终端拉资金流向、在金融数据库调持仓明细、在研报系统翻PDF、在舆情平台筛新闻，最后手工拼凑结果。这甚至不是分析，是搬运。一个简单查询动辄跨越三到四套系统，延迟以分钟计，而市场不会等人。
当OceanBase Lakebase把实时行情、历史研报、公告信息和产业链关联关系统一到同一个底座上时，Agent的工作方式就彻底变了。它发起一次查询，数据库在内部完成结构化过滤、向量相似度搜索、全文匹配和图遍历，百毫秒内返回完整结果。智能研报生成、合规监控、异常交易检测这些场景，从技术上可行但工程上不划算变成了可以规模化跑在生产环境里。对于一个成本
更根本的变化在于，当数据底座原生支持Agent的记忆系统时，短期记忆、长期记忆、语义记忆、结构记忆不再散落在四套系统里。一个风控 Agent 可以记住上次预警时用到的关联账户图谱，下次类似交易出现时直接复用，不需要重新跑图遍历。一个投研Agent可以记住某家公司的历史评级变化轨迹，新的研报出来时自动对比立场转向。Agent不再是每次查询从零开始的问答机器，而是具备持续学习和上下文累积能力的真正智能体。
尾声
基础设施是为上层应用服务的，上层应用是为现实业务服务的。当AI Agent作为上层应用，数据库的角色也正在从存放数据转向承载智能。Agent成为数据库的主人时，核心问题变成了如何让一个7×24小时自主运行的智能体，安全、准确、实时地获取它所需要的全部上下文。过往我用的开源湖仓提供了开放性，但从湖出发的路径，在数据一致性和Agent友好上承载了巨大的补课压力。OceanBase选择从金融级内核出发，用十五年的强一致、高可用、实时处理积累做地基，再延伸到湖和多模态数据——先有库，后有湖，让事务能力成为基因，让AI理解能力长进内核。
这或许不是唯一的路径，但它为AI时代的数据底座应该是什么样提供了一个系统性的回答。
