AI+各行各业的概念铺天盖地。数据库作为IT架构的基石，存放的是企业的核心资产——但这里有个微妙的区分：“数据库”和“数据”，从市场变现的角度看，显然后者才是真正的主角。
我是一名DBA，幸运的是身边有不少思想活跃、关注技术前沿的客户。去年一次交流，在和一个客户交流AI在数据库上如何大有作为，给我浇了盆冷水，也促使我开始重新审视数据库与AI的真实关系。
DB+AI 还是Data +AI?
这位客户早在DeepSeek这类大模型爆火之前，就已经在深耕AI领域。像Chat2SQL、Chat2DB这些概念，在他看来都算不上新鲜。
他给我拆解了数据库与AI结合的两个方向：
一个是“DB+AI” ——比如AI for DB或DB for AI，智能运维是典型代表。几年前我在准备Oracle 21ai活动分享PPT时，就了解到Oracle已经在做这方面的工作。去年得到消息，Oracle公有云的数据库运维已经自治运行了整整半年。
另一个是“数据+AI” ——比如Chat2SQL或AI+BI，核心是让AI去理解业务数据，而非仅仅理解数据库本身。
去年客户跟我聊“数联网”、“本地建模”时，我听得确实有些吃力。他有个观点特别扎心：DBA做AI产品，有点像A股里抱着白酒研究的“老登”——赛道本身没问题，但想玩出新花样，难。
理由很直接：数据库运维工作大部分是标准化的，AI或大语言模型在里面能发挥的空间有限——更多时候只是识别人类语言，触发事先编排好的流程操作，因为运维多数场景不需要发散思维。当然，高级故障诊断除外。
而真正有价值的，恰恰是让AI理解数据库中沉睡的海量业务数据。客户还抛了个更激进的判断：AI对行业软件业的冲击，未来可能让“某某系统”不再需要界面UI——虽然有些极端，但我们不妨拭目以待。
如何做DB+AI?
“DB+AI”这条路，要么做进内核实现数据库自治，要么用Agent加知识库或Skills来辅助完成SOP运维。
坦白说，这个方向的市场盘子不大，但是必须做，也必须要有人做——这是基本功。
现在的趋势已经很清晰：AI推理大模型本地化部署 + 本地化Agent + 内网数据库，不久就会在企业真正落地。它能拉升DBA的运维能力天花板，在响应速度、操作频率、工作时长上都远超人力。更关键的是，它可以实现知识经验的真正沉淀，减少对人的依赖，把DBA从重复机械的操作中解放出来，去做更有创造性的工作。
我们已经在做这样的事，助力客户的智能运维在生产内网安全落地。
另外，数据库作为数据的载体，其使用方式也在被彻底改写。
过去几十年，数据库是为“人”设计的。财务查报表，运营拉订单，DBA跑批量任务——大家规规矩矩地写SQL，数据库老老实实地返回结果。这是一种计划性系统设计：表结构提前定好，查询路径提前优化，一切服务于人类的固定需求。
但现在，使用者变了。
未来两到三年，一半以上的数据库访问将来自大模型和AI Agent，而不是人类。与此同时，软件开发的门槛被AI大幅拉低——连销售部门都能自己“写”程序了。这意味着应用和数据库结构的创建，正变成大量一次性或敏捷交付的产物。每个人可能需要一套独立的Schema，甚至一套独立的DB；数据的形态也从单一的结构化记录，扩展到文档、图像、音视频等非结构化内容。
面对这种变化，传统的单机或分库分表架构已经力不从心——我们需要一个能同时承载结构化与非结构化数据、能快速隔离租户、能支撑海量Schema的多模态数据库。
国产数据库OceanBase给出了答案。从V4.3、V4.4版本开始，OceanBase逐步丰富了多模态支持能力，并在前不久正式发布了面向Agent优化的下一代数据库——OceanBase LakeBase。
简单来说，这款AI数据库既可以独立部署，也可以基于OB V4.3及以上版本升级而来。它具备几个关键能力：
- 湖库一体：打破数据湖与数据仓库的边界，一份数据服务所有引擎；
- 多模态支持：关系数据、文档、向量、图像、音视频统一管理；
- Schema-less + 逻辑表：用逻辑表快速隔离海量Schema，轻松应对Agent爆发式增长；
- Fork Database：像GitHub分支一样秒级克隆数据库，支持Agent安全试错与回滚；
- 内置RAG与Agent Memory：在库内构建Agent上下文，让记忆和检索离数据更近。
更多特性细节，建议直接查看OceanBase官方发布会材料，这里不再赘述。
如何做DATA+AI？
“Data+AI”的关键，是让AI真正理解数据、理解业务。
传统应用是“你写程序、我执行”，数据是静止的。数据库只管“怎么存、怎么取”，业务语义是应用层的事。只给Agent一堆表名和字段名，它根本无法准确给出想要的数据。
Chat2SQL被寄予厚望，但往往Demo里惊艳全场，一到生产环境就频频翻车。原因不是大模型不够强，而是缺少足够的业务上下文。
Wren AI的层次结构我很认同：让Agent理解业务数据需要分五层——连接层、语义层、业务层、操作层、行为层。第一层让Agent能读取数据库，中间两层帮它理解业务，最后两层帮它安全行动并持续改进。
连接层的上下文可以从DDL、Comment、表设计文档中获取，但语义层和业务层的上下文，必须来自产品说明、新员工培训、业务术语等非结构化数据——这其实也是数据治理中“数据标注”的范畴。
我有个客户自己做了个小工具，通过表结构查数据。表名规范的时候还好说，但遇到命名不清晰的表就抓瞎了。于是他用AI做了个补充上下文的方法：遍历采样表数据来了解内容，在后续对话中让AI自行修正，并将修正后的查询经验保存到记忆上下文中——用多了，效果越来越好。
有意思的是，直到前段时间看OceanBase发布Lakebase和DataPilot产品，我突然发现，我们一直摸索的“Data+AI”路径，在OB上找到了可用的产品方案。因为它可以依赖Lakebase数据库，在库内部构建丰富的上下文，再复用数据库的混合检索能力——这事就成了。
我很高兴看到国产数据库厂家也能基于内核能力迭代，衍生出创新型产品。以前这种现象，只发生在Oracle身上。
最后想说
数据库是数据的底座。Oracle时代就在倡导“融合”理念——让算法来找数据，而不是把数据ETL出去再做AI。
AI时代也一样。不会是专用向量库一统天下，不存在谁取代谁，而是走向融合。像OceanBase lakeBase这样的AI数据库，超融合一体化。
当数据库基座支持了多模态，Agent的记忆与上下文就可以和数据库放在一起。利用AI大模型的赋能，我们不仅能做数据库智能运维，还能孵化出更多Agent——服务于开发、服务于IT运维、服务于数据理解与使用，为Agent管理和使用数据库，提供真正可落地的场景。