AI Agent 要用数据库了：Lakebase、seekdb 与 PowerMem 怎么理解

AI Agent 开始真正“用”数据库之后，库本身也要变：既要扛事务与一致性，又要管向量、全文和长期记忆，还得让开发者别被一堆组件拼到怀疑人生。

本文想讲两件事：

1. Lakebase / AI 数据库到底在说什么？ 各家定义并不一样；结合 OceanBase 发布会，说说小编对「Agent 友好」能力的理解。
2. 当 Agent 成为数据库的一等用户，库该长成什么样？ 重点看 seekdb、PowerMem，以及从本地到企业级的一条路径。

🧠 想先上手摸一把？本地可试 seekdb，记忆层可看 PowerMem。

Lakebase，为什么在 Agent 时代突然成了热词？

开篇先唱个反调。

发布会后不少标题写 OceanBase「定义」了 Lakebase / AI 数据库。小编觉得这话偏满：更准确的说法，是 OceanBase 讲清了自己对 Lakebase 的理解，而不是给全行业盖章。

很多人还不熟这个词，先从它是怎么火起来的说起。

最早把 Lakebase 作为产品叙事推到台前的，是 Databricks。Databricks 发布 Lakebase 时，号称它是面向 AI apps 和 agents 的新一代 operational database，其实是基于 Serverless Postgres，打通了 Lakehouse 和 OLTP 能力。

后面 Zilliz 对 Lakebase 的理解又是另一种方式 —— 把 Vector Database 和 Data Lake 融合，围绕向量检索、AI search 和 lake-native storage 打造了一套 Vector 版本的 Lakebase 架构。

上周 OceanBase 发布 AI Database，提出 unified LakeBase architecture，并推出了 OceanBase Lakebase。更准确地说，Lakebase 不是单独一个“底层数据引擎”，而是 OceanBase 面向 AI 数据平台给出的湖库一体架构和数据底座。

OceanBase 的理解更像是：继续做进阶版的“一体化”数据库，把数据库的事务一致性、实时服务和可靠性，跟数据湖的对象存储、海量数据管理、开放计算接到一起，再把结构化、半结构化、非结构化、向量、全文、图这些数据形态放进统一治理体系里。它想解决的不是某个单点检索问题，而是想大幅降低 AI 时代企业数据底座的组件拼装复杂度。

同一个 Lakebase，各家理解完全不一样，这就很有意思了。

Databricks 的老本行是 Lakehouse，强项在数据湖、分析和 AI 平台。所以它讲 Lakebase，自然会讲成 Lakehouse + Serverless Postgres：在离线分析和湖仓体系里，缝合上在线事务处理能力。

Milvus 的本质是一个向量数据库。所以 Zilliz 讲 Lakebase，自然会围绕 Vector 和 AI search，把 Lakebase 的概念定义成 Vector Lakebase。

韩锋老师在《“湖库一体”，OB 一体化再升级》里有个说法很贴切：“OceanBase 的产品演进史，本质上就是一部不断打破数据库技术壁垒的‘一体化’进化史。”所以，OceanBase 讲 Lakebase，自然会从“数据库一体化的进化论”来解释：从 OLTP 到 HTAP，再到多模一体化，再到现在的湖库一体。

其实无论是 Zilliz，还是 OceanBase，乃至于其他数据库，对 Lakebase 的看法并不完全一样，但底层趋势接近：都在自己的维度上做“一体化”的融合。

Lakebase 的热度，不是因为它新，而是因为它准，它正好戳中了 AI 时代数据系统最难受的地方：非结构化数据越来越多，数据质量压力越来越大，数据管理和 AI 开发割裂，实时数据又要更快地进入分析、训练、评测和在线服务链路。

AI Native 企业里经常是一套在线库、一套数仓、一套向量库，数据量大了，可能还会再额外增加一套数据湖。每多一套系统，就多了一份同步的开销和不一致风险。

OceanBase 在对外宣传时，很喜欢说“一体化”这三个字，看上去略显高大上，其实用 OceanBase AI 湖库研发负责人竹翁更朴素的说法，就是：精简技术栈，高效好运维。

也正如韩锋老师所说：

少接几套系统，就少几条数据同步链路；少几条同步链路，就少几个凌晨三点把人叫醒的故障点。

OceanBase AI 产品体系，有啥值得关注的新东西？

发布会上重点讲的 OceanBase Lakebase，只是 OceanBase AI 产品体系中的底层数据平台，它把基于对象存储、存算分离的 OceanBase 和数据湖接起来，把湖、仓、库做成一套引擎，统一支撑湖仓分析负载，和数据库的事务负载。

官方的原文是：

OceanBase Lakebase 作为底层引擎，承载湖库一体与多模态数据能力，让结构化数据、非结构化数据和向量数据能够在统一架构中被管理、加工、检索和调用。

上面这张图，看起来总觉得比较别扭。从发布会上的内容来看，OceanBase Lakebase 的整体架构大概可以简化成：

OceanBase Lakebase
    ├── OceanBase
    ├── Spark 引擎整合
    ├── Ray 引擎整合
    └── 对象存储

其中：

• OceanBase：专注于实时数据处理和分析，提供高效的向量计算、混合搜索、实时加工与分析、事务处理能力。
• Spark：开源集成，提供高性能离线加工能力。
• Ray：开源集成，提供高效的 embedding、训练、推理和 Python 数据处理能力。

优势也比较明显：一是 OceanBase 在支持湖库能力之前，HTAP + 单机分布式一体化架构的技术能力就已经比较成熟，TP/AP/AI 能力不输专用数据库和专业数仓；二是现在又增加了传统 Lakehouse 的大数据处理和分析能力，可以直接为企业的 AI 数据平台提供一套非常完整的解决方案。

除此以外，在发布会上我注意到还有一个 OceanBase 正在逐步成为 “Agent native 引擎” 的概念。不过发布会上只是简略一提，说 OceanBase 中会增加大量和 AI 相关的新特性，可惜都没有细讲。所以，小编正好可以趁机说说自己的理解（非官方，欢迎纠错）：

• 支持对象存储、存算分离。这个好理解，就是为了应对 AI 时代持续膨胀的数据量，降低存储成本。
• 大对象类型（例如 AI 离不开的向量类型）会自动根据数据的实际大小，选择不同的存储形态。我理解就是数据小，存数据；数据大，存指针，然后指向实际的外部存储空间。
• AI 列。这个东西，从使用的角度来看，我理解会类似于在生成列（GENERATED AS）的定义中加入 AI Function，让数据库根据提示词自动根据表格中的某些行的内容到一个生成列上。好处是所有数据都被包在数据库里，避免数据流入流出带来的风险和延时。
• 逻辑表。我理解就是让多个表结构相同的表，只存一份元数据。通过逻辑映射实现低成本共享与隔离，解决海量 Agent 导致的 Schema 爆炸问题。
• unified catalog。这个和数据安全相关，我理解就是类似于用 Oracle 中的 Schema，对湖库中不同格式的数据，进行访问权限的隔离。

剩下的“多模态”、“一体化”、“开放生态”……都是些老生常谈的东西，这里就不再展开细聊了，可以详见：《OceanBase 湖库一体 AI 数据库正式发布》。

除了上面这些东西，还有一个值得继续和大家详细聊一聊的东西，就是 “Agent 友好” 这个新时代的数据库特性 —— 因为 Agent 不只读写数据，它还会犯错并不断试错、会复用历史经验，还要支持层出不穷的端侧智能设备。所以也需要记忆和上下文、分支快照和出错回滚、极致轻量化等诸多新能力。

所以，在小编看来，发布会上重磅推出的 OceanBase Lakebase，只是 AI 数据库体系里的湖库底座。AI 数据库产品体系，显然不只是面向湖库能力的一次功能增强，而是面向 Agent、多模态数据和上下文工程的一次基础设施重建。所以，它还需要 seekdb、PowerMem 等 AI Native 产品来补齐 “Agent 友好” 这个 AI 时代对数据库的新诉求。

发布会上的叙事方式比较宏大，OceanBase 的各位老大们只重点介绍了 OceanBase Lakebase 这个 AI 时代的数据基座。有一些开发者朋友们最关心的是：我现在马上就能用到的是什么？答案之一就是刚刚提到的 —— seekdb。

发布会上提到的多模表、混合搜索、AI Function、fork table / fork db 等与 AI 和 Agent 相关的能力，都能直接（甚至提前）在 seekdb 上体验到。

seekdb：给 Agent 准备的“轻量级 AI Native 数据库”

seekdb 是 OceanBase 社区面向 Agent 和 AI 应用的轻量级 AI Native Search Database，项目已开源，详见：https://github.com/oceanbase/seekdb

它的定位不是“再造一个大而全的企业数据库”。它更像是 OceanBase 这条 DB for AI 路线在开发者侧的一个轻量入口：你可以先在本地、单机、嵌入式场景里用起来，再根据规模切到 seekdb server 或 OceanBase。

最关键的是，它知道 Agent 需要什么。

第一件事：别让开发者第一步就被部署劝退

很多 AI 基础设施死在第一步，开发者刚想试试，就被满是繁文缛节的部署文档劝退了。

seekdb 这点很务实：

pip install -U pyseekdb

pyseekdb 是 seekdb 的 Python SDK。它支持 embedded、本地 server、远程 OceanBase Server。原型阶段可以本地嵌入式运行，不用先搭复杂服务；后面要上规模，再换连接方式。

这条路，很适合 AI 应用开发。

今天很多 Agent 项目都是先从一个脚本、一个 Copilot、一个内部小助手长出来的。

seekdb 的 GitHub README 里把自己概括成一句话：“Write, Search, Fork. The State Store for AI Agents.” Agent 不只是需要存储，它需要持续写入、马上检索、随时试错。

第二件事：不把 Agent 记忆当成纯向量问题

很多人一提 Agent 记忆，第一反应是向量数据库。

但真实场景里，Agent 的记忆和知识库很少是纯向量问题。

比如你问一个企业助手：“找一下上个月华东区客户投诉里，和退款相关、且语气比较激烈的案例。”

这句话里至少有三种检索：

• 上个月、华东区、客户投诉，是结构化过滤；
• 退款，是全文关键词；
• 语气激烈、相似案例，是语义向量检索。

如果你用 MySQL + Elasticsearch + Milvus 拼，当然也能做。但你要维护数据同步、权限一致、结果融合、排序策略，还要祈祷半夜别掉链子。

seekdb 的思路是：向量、全文、标量过滤放在一个引擎里，用一条 SQL 或一个 SDK 接口完成混合搜索。

这不只是省事。对 Agent 来说，这意味着上下文更实时，权限更一致，工程链路更短。

第三件事：提前给会犯错的 Agent 准备后悔药

现在这个时代，最危险的可能已经不是 AI 大模型敢胡说八道了，而是 Agent 敢拿着很高的权限，到处胡操八作。

Agent 会犯错，行业已经用层出不穷的生产事故一次又一次地交过学费，详见：《700 万人围观 AI 删库跑路，罪魁祸首写下奇葩检讨》。

上面这篇文章，可以用一句话来概括：完善的 System Prompt 绝对不是 Agent 去操作数据的安全边界。

对于 DBA 来说，重要的往往是效率和成本。但对 Agent 来说，有可以吃的后悔药，也许更重要。

seekdb 更实际的做法是 Fork / Diff / Merge。

它支持 Fork Table / Fork Database，给 Agent 创建一个隔离的数据分支。Agent 可以在分支里改表、写数据、测试 Prompt、跑评测。成功了再 merge，失败了直接 drop。详见：《seekdb fork table 能力测试报告》里，测试场景包括 A/B 实验、数据版本管理、回滚、生产数据隔离测试。这个能力很像 Git，只不过管理的不是代码分支，而是数据分支。

如果上面这篇文章里在 AI 创业公司里删库跑路的 Agent 当时操作的是一个 fork 出来的测试分支的 Database，它就可以在里面尽情犯错，数据不会陪它一起消失。

这就是 Agent 时代数据库该有的基本礼貌：假设 Agent 一定会犯错，然后把爆炸半径关进 fork 出来的测试分支里。

第四件事：seekdb M0，把记忆产品往前推一步

除了 seekdb 本身，还有一个值得单独提的产品：seekdb M0。

它在社区文章里被描述为一个专门为 AI Agent 设计的自进化云记忆，支持一键接入、分享经验和持续进化，会在支持 Agent 之间经验共享的同时，缩减 token 成本。

这里不展开讲产品细节，只说它代表的方向：

Agent 记忆不应该只停留在“把聊天记录存下来”。它应该能跨会话、跨任务、甚至跨 Agent 沉淀经验。

比如一个 coding agent 试过某个错误方案，下次另一个 agent 不应该重新踩一遍坑。一个机器人在某个环境里学到的操作偏好，也不应该每次断电之后从零做人。

这件事继续往下走，就会从“记忆存储”走向“经验系统”。

第五件事：seekdb 不只适合云上，也适合端侧和边缘

最近 Google DeepMind CEO 哈萨比斯在演讲中有一个判断：模型蒸馏会让更强的模型能力逐步下沉到端侧，详见：《人类离 AGI 只剩 4 年，只差最后 3 块拼图》

这个趋势眼看着就要逐步成真了，所以很多 AI 能力，不会永远待在云上。

智能设备、边缘设备、具身智能、智能驾驶，都有一个共同问题：不能每次想起一件事都先回云端翻档案。原因也很现实：移动网络很可能不稳定，但设备的延迟不能太高；外加用户隐私问题、成本问题等等。

这时，seekdb 的嵌入式形态、低资源门槛、本地混合检索就很有价值。它可以在设备侧保存局部状态、任务轨迹、用户偏好和检索索引。车端、机器人、智能终端都需要一块本地“小脑”：能低延迟检索，也能在必要时和云端大脑同步。

数据中心侧则可以用 OceanBase Lakebase 做多模态数据回流、治理、训练和评测。设备侧用 seekdb + PowerMem 负责即时反应，中心侧负责长期演进。

这条路，比“所有记忆都塞进云端大模型上下文窗口”靠谱得多。在发布会上，日照也提到了很多支持智驾的车企，现在就是这样做的 —— OceanBase + seekdb + PowerMem。这类“端侧即时反应 + 中心侧长期演进”的架构方向，正在变得越来越现实。

PowerMem：让 Agent 不只是“记住”，而是“会整理记忆”

讲完 seekdb，再看 OceanBase CTO 日照在发布会上提到的另一个 AI 产品 —— PowerMem（项目也已开源，详见：https://github.com/oceanbase/powermem）。

如果说 seekdb 更偏“存和搜”，PowerMem 更偏“记和忘”。它不是向量数据库，也不是简单聊天历史。它更像 Agent 的记忆管理层：负责抽取、合并、遗忘、检索和经验沉淀。

德哥在《PowerMem 未来可能成为 OB 的杀手锏》里用了一个很形象的比喻来阐述 PowerMem 和其他记忆产品的不同：

普通的向量数据库(Chroma、Milvus、Pinecone)是“会搜索的文件夹”: 你塞什么它存什么，召回什么它不负责。

mem0 是“听话的笔记本”:你告诉它“记住 X”，它存；你忘了告诉它，它不会主动记。

PowerMem 是“会思考的笔记本 + 秘书”: 它会自动从对话里“划重点”，对记忆进行去重和合并冲突、遗忘长期得不到访问的记忆，同时还支持记忆的精准召回。

Agent 的长期记忆最怕两种极端：一种是金鱼脑袋。每次新会话都像初次见面，昨天刚说完的偏好，今天又问一遍。另一种是仓库脑袋。什么都记，什么都塞，最后上下文越来越贵、越来越慢、越来越乱。不会遗忘的 Agent，最后不是更聪明，而是更像一个塞满旧便签的抽屉。

PowerMem 解决的就是 Agent 的长期记忆问题。

它要知道什么值得记

不是所有聊天记录都值得长期保存。

“用户喜欢咖啡”可能值得记。

“用户今天下午 3 点说了一个‘嗯’”大概率不用记。

“这个项目的数据库从 MySQL 迁到了 OceanBase”值得记。

“刚才命令行输出了一个临时路径”可能只适合短期上下文。

PowerMem 做的是从对话、任务轨迹、反馈中抽取关键事实，再变成可检索、可更新、可治理的记忆。

它会处理记忆冲突

记忆不是静态文本。例如：用户昨天说喜欢咖啡，今天又说要戒咖啡了。

如果系统只会“追加”，记忆很快就会打架。PowerMem 要处理的是记忆演化，不是文本堆积。

它懂得忘

这点听起来反直觉，但很重要。

人类记忆有遗忘机制，不是缺陷，而是压缩策略。Agent 也一样。

全量上下文方案看似简单，实际代价很高：token 贵、延迟高、注意力衰减，模型还可能在一堆旧信息里翻车。

PowerMem 的遗忘和衰减机制，就是为了控制噪音和成本，让真正有用的记忆留在前面。

它不限制后端，但 seekdb 很适合它

PowerMem 不应该被理解成“只能绑死某个数据库”。它可以适配不同后端。

但 seekdb 的轻量形态和混合检索能力，显然能提升 PowerMem 的表现。

PowerMem 管“什么值得记、什么时候该忘、怎么召回更准”；seekdb 管“这些记忆放在哪里、怎么稳定地查出来”。

一个像记忆管家，一个像记忆仓库和检索引擎。这两个组合起来，才更接近 Agent 真正需要的长期记忆系统。

Experience + Skill：从记事实，到长经验

PowerMem README 里明确提到 Experience + Skill distillation。相关社区文章也多次提到 seekdb M0 支持 Agent 之间经验共享。

为了避免把产品边界说得过满，这里可以保守理解为：OceanBase 社区这条记忆产品线，正在从“记事实”走向“沉淀经验和技能”。

这一步很重要。未来 Agent 的竞争，可能不只是“谁能调用更强的模型”，而是谁能把每次任务里的经验留下来，让下一次少走弯路。

seekdb + PowerMem + OceanBase：一条从本地到企业级的路

德哥在 《OceanBase 在下一盘大棋》里，把 seekdb、PowerMem 和 OceanBase 放在一起做了个总结：

PowerMem 解决“Agent 怎么记住、怎么忘、怎么调出来”；

seekdb 解决“一条 SQL 把向量、全文、结构化数据查完”；

OceanBase 解决“上规模后怎么稳、怎么扩、怎么进入企业生产系统”。

这条路径很顺：

本地开发阶段，可以用 pyseekdb，也就是 embedded seekdb，加上 PowerMem，快速给 Agent 加长期记忆。

中小生产阶段，可以用 seekdb server 加 PowerMem，承接 RAG、智能助手、代码 Agent、企业知识库。

企业规模阶段，可以用 OceanBase / Lakebase 加 PowerMem，承接多模态、治理、权限、一致性和海量 Agent。

这条路也被德哥在另一篇文章《Claude、Codex 疯狂抢入口，OceanBase 闷声焊地基》里说得很准：

Claude、Codex、各种 Agent 平台都在抢入口。

但当 AI 真要进入企业生产系统，最后绕不开的还是数据底座。

DataStudio 和 DataPilot

当然，OceanBase 这次发布的不只是 Lakebase 和 PowerMem。

OceanBase 产品老大颜然还介绍了另外两个产品：统一开发治理平台 DataStudio，以及面向业务的 BI 分析 Agent DataPilot。

不过这两个产品小编暂时都还没有上手体验过，暂时不便进行过多的分析和评价，后面有缘再和大家介绍和分享。

AI for DB 很热，但 DB for AI 才刚开始

最近和很多 DBA、数据库开发者聊天，大家都在关注 AI 怎么改变数据库运维和开发，也就是 AI for DB，这很重要。让 AI 写 SQL、查慢查询、做巡检、生成报表，都是很现实的方向。

但 OceanBase 这场发布会更像是在讲另一条路：DB for AI。也就是说，数据库怎么反过来支撑 AI。AI 要真正进入企业，不能只靠一个聪明模型，它需要高质量数据，需要实时上下文，长期记忆，安全隔离，试错回滚，多模态治理。这时候，数据库不再只是后台那个“存数据的东西”，它需要进化成 Agent 的地基。

最后总结一下：小编觉得 OceanBase 这次发布会真正值得关注的，不只是“又发布了一个 AI 数据库”。更重要的是，它把一个问题摆到了桌面上：

当 AI Agent 开始使用数据库，数据库应该变成什么样子？

这个问题，才刚刚开始变得有点儿意思。