前言

这两年我接触 AI 应用，最大的感受是，一开始很容易觉得事情已经被大家跑通了。

智能问答、知识助手、数据分析 Agent 这些项目，MVP 版本通常不会太难。模型接口接上，文档整理一遍，RAG 检索补进去，再挑几个业务同学平时就会问的问题，现场基本就能看到效果了。老板问制度，系统能给出一段像样的回答；业务同学问指标口径，Agent 也能顺着已有资料解释几句。这个时候团队兴奋很正常，因为它确实比过去的搜索框、报表系统、知识库页面更像一个能交流的工具。

只是后来我越来越发现，MVP 版本的顺利并不代表系统已经准备好进入业务现场，很多真正麻烦的地方，往往要等到数据开始实时变化、权限开始细分、文档开始频繁更新以后才会暴露出来。系统真正接入业务流程以后，麻烦就会变得非常具体。

用户只是提出一句问题，背后却要穿过关系型数据库、对象存储、搜索引擎、向量数据库、权限网关和业务代码。业务数据更新以后，索引可能滞后；权限策略调整以后，检索结果可能仍然包含历史内容；文档刚刚完成修订，Agent 可能继续引用旧版片段。到了这个阶段，问题表面上像模型回答不稳定，实际压力经常落在数据组织方式上。

所以我看到 OceanBase 这次发布 Lakebase、DataStudio、DataPilot，以及 PowerMem、PowerRAG 之后，我的关注点更偏向业务落地后的数据问题：Agent 进入业务以后，数据从哪里来，怎样保持最新，权限怎样跟着业务变化，非结构化内容怎样和结构化数据一起被检索，评测环境怎样隔离，长期记忆又怎样沉淀下来。

顺着这个视角再看 Lakebase 强调的多模态处理、湖库一体、开放计算、多模混合搜索和 Agent 友好，这几个方向就不只是产品功能列表，而是对应了前面提到的 AI 应用从演示走向上线时最容易卡住的几类工程问题。

我现在更愿意把这次发布放回业务落地里理解，Agent 进入生产环境以后，会更频繁地读取数据、写入状态、留下执行轨迹，数据库首先面对的压力，往往来自大量小应用、小数据空间和小型状态的管理。这个问题处理不好，后面的混合搜索、权限一致性、评测沙箱和长期记忆都会继续堆补丁，所以第一节我想先从小型数据空间的增长说起。

一、以前担心大型数据库，现在更担心小型空间太多

以前讨论数据库扩展，我脑子里首先出现的通常是大型数据表、大型数据库和高并发访问。订单越来越多，交易峰值越来越高，分析查询就会越来越复杂，大家就会围绕分区、扩容、容灾和索引优化安排工作。

当 Agent 进入业务系统以后，压力换了形态。单个空间的数据量未必庞大，应用数量、Agent 数量、状态空间数量却增长迅速。每个空间都要保留状态，都要隔离权限，还要在用户重新访问时迅速唤醒。

Vibe Coding 把小型数据空间膨胀的问题放大了。灵光几个月承载了 3000 多万个闪应用，妙思也支撑了上万个应用；这些应用平均只有百余行数据，大量应用创建后长期休眠，重新使用时仍然需要秒级响应。 这种负载和传统互联网高峰流量不太一样。每个空间单独观察都很轻量，数量积累起来以后，元数据管理、控制面操作、资源调度和隔离策略都会成为压力来源。

数据库表结构的选择很快会变成两难。给每个 Agent 创建独立物理数据表，隔离边界清楚，DDL 压力、存储开销和管理成本也会快速上涨。但是，如果把所有数据塞进一张通用大表，成本看似下降，后面处理标准 SQL、索引优化、字段治理和细粒度权限又会非常难受。很多团队早期喜欢使用 JSON 大字段承接动态 schema，短期确实方便，一旦业务开始要求排序、聚合和过滤，之前节省的工程量会换一种方式回来。

我现在会先追问一个非常具体的问题：海量小型数据空间能不能以低成本方式存在。逻辑表、逻辑数据库、共享资源池、按需唤醒、闲时资源归零，这些设计听起来没有模型推理那么热闹，却决定 Agent 平台能否从几十个应用扩展到几万个应用。大家经历过平台型业务就知道，真正拖慢系统演进的，常常是一批看起来不起眼的小型空间、小型配置和小型状态。

二、RAG 进入生产以后，首先暴露数据分散

我以前搭 RAG 原型时，也觉得拼装方式很合理。业务字段保存到关系型数据库，文档保存到对象存储，关键词检索使用 Elasticsearch，语义召回交给向量数据库，应用层再编写逻辑完成合并和重排。这种做法适合快速验证，因为每个组件都成熟，团队很快就能搭出一个演示系统。可一旦接入真实权限和实时数据，同步延迟马上会变成麻烦。

风控 Agent 查询规则时，既要确认规则状态、业务线、地区适用范围和访问权限，也要找到语义相近的历史案例。向量索引与主数据之间只要存在时间差，Agent 就可能引用已经删除或者失效的规则。普通知识问答里，这多半表现为质量波动；放到风控、安全、交易和合规场景里，它会变成事故前兆。

真实业务检索也很少只有语义相似度。大家询问“最近三十天华东区域里，和当前投诉描述相似的高风险案例”，里面至少包含时间范围、区域、业务类型、文本语义和风险标签。更稳妥的做法是先用结构化条件缩小候选范围，再结合全文搜索和向量搜索进行多路召回，必要时补充图关系或者空间位置检索，最后让模型处理少量高价值候选。这样结果更可控，Token 消耗也更容易管理。

前面这个风控例子，正好能解释我为什么会关注多模表和混合搜索。结构化字段、LOB、JSON、向量可以作为表字段统一入表，并保持同一事务、同一权限、同一版本、同一生命周期；混合搜索把关系过滤、全文搜索、向量搜索、图搜索和模型精排放进同一个召回过程。

如果只是先构建轻量知识库、个人助手、Agent 原型或者内部 RAG 应用，我会先研究 seekdb，官网为https://www.seekdb.ai/ 。seekdb 定位为 AI-Native Search Database，可以在单一引擎中统一 vector、text、structured、semi-structured 数据，并支持 hybrid search 和 database 内 AI 工作流。

我的理解是，seekdb 适合先把检索层收拢起来。我们先把文本、向量、标量过滤和半结构化数据放到同一个检索环境里，减少同步次数，也减少一致性窗口。等业务继续发展到多模态数据处理、统一权限、离在线计算和多团队协作时，再把 Lakebase 引入更完整的数据架构。这个节奏更贴近大多数团队的真实演进方式。

三、我理解 Lakebase，就是减少数据搬运

RAG 检索层收拢以后，下一个问题很快会出现：可检索的数据到底怎样加工出来。PDF、音频、视频、交易记录、日志和向量如果都在不同系统里来回同步，Agent 获得的信息仍然会滞后。在线数据库负责交易和状态，数据湖负责低成本存储，数仓负责分析加工，搜索系统负责检索召回，向量数据库负责语义匹配。每个系统单独观察都有合理性，可 Agent 需要实时理解业务，多套系统之间反复同步、转换和校验，迟早会变成延迟和运维压力。

我关注 Lakebase，主要因为它试图缩短原始数据变成可搜索、可分析、可服务内容的过程。底层通过对象存储承载结构化、半结构化、非结构化和开放湖格式数据；数据层通过多模表统一关系数据、向量、全文、图、JSON、LOB 等类型；计算层支持 OceanBase 的 OLTP、OLAP、AI 混合搜索，也支持 Spark ETL、Daft on Ray 等开放计算；统一 Catalog 负责元数据、血缘、权限和安全策略。

大家可以把这件事放到智驾业务里理解。车辆每天产生视频、图片、传感器、GPS 等数据，后续还要完成拆分、抽帧、场景识别、特征提取、极端工况发现、相似案例检索和模型迭代。如果每个环节都分散在不同系统，中间数据就要不断同步、转换、校验，整体流程会变得迟缓，也容易出错。Lakebase 在这类场景里的意义很直接，它让视频、图片、传感器数据经过加工以后，更快进入搜索、分析和在线服务。

证券行业也有类似处境。行情、交易、财务、客户数据属于结构化数据，研报、公告、合同、扫描件、会议纪要、新闻舆情和政策法规则更多属于非结构化数据。投研、合规和经营分析真正关心的事情，是把这些信息整合成可以检索、理解、追溯和复用的数据内容。结构化条件、全文内容、语义向量和业务口径放在同一个处理环境里，智能分析才会越过“文档问答”的浅层阶段。

我也很看重 Lakebase 的部署选择。新业务可以独立部署，直接搭一套 AI 数据平台；存量业务可以通过智能叠加层复用已有数据湖、数仓、OLTP、NoSQL 等系统，在较少迁移历史数据的前提下支撑向量搜索、多模态处理和 Agent 调用。 这个部署方式对企业更友好，因为存量系统通常没法推倒重来。画一张全新架构图很容易，把新能力稳定接进旧系统才考验工程能力。

四、Agent 会持续试错，测试数据也要支持分支

我以前观察 Agent 研发流程时，最容易低估的环节是评测环境。普通应用当然也需要测试环境，但是逻辑相对确定，重点观察的是输入输出是否符合预期。而 Agent 的变量更多，system prompt、工具描述、RAG 分块策略、Memory 抽取方式、模型版本和业务数据状态，任何一个因素变化，都可能影响最终行为。

更麻烦的是，Agent 还会写入中间状态、更新记忆、修改策略，甚至触发外部动作。你看，如果两个功能分支同时迭代，一个调整 tool description，另一个修改 memory 策略，它们又共享同一批测试数据，评测结果就很难解释。当效果提升以后，我们很难判断贡献来自哪里；而效果下降以后，我们也很难定位污染发生在哪个环节。

传统方案会复制一整套数据库、知识库、向量索引、Memory 和业务状态。低频研发还能接受，Agent 开发节奏变快以后，这个办法就会明显拖慢团队。十几个功能分支并行推进，每个分支都需要独立环境，完整复制数据会让环境创建成为瓶颈；多个分支共享环境，又会让错误写入污染后续测试，bad case 复现和修复都会让研发团队变得痛苦。

如果研发团队每天都要调整 Prompt、调整工具、调整记忆，那么数据沙箱就会从可选项变成刚需。Fork Database 把代码分支的思路扩展到数据层，每个 Agent 或每个评测任务都可以从基线数据库拉出独立沙箱，分支内部读写互不影响，验证失败后直接丢弃，验证通过后再决定合并方式。OceanBase 的 Fork Database 支持秒级创建、读写隔离和失败回滚，逻辑表层面还面向海量 Agent 提供独立数据边界和共享资源池。

我预计 Agent 工程会逐渐形成新的研发习惯。代码分支、数据分支、轨迹回放、评测集、bad case 修复、回归验证会一起出现。数据库会进入评测体系。低成本数据分支让高频试验可控，快速回滚让自动化改动保持安全边界。评测环境稳定以后，Agent 研发才不会被数据污染拖住。

五、Memory 应该像长期资产，PowerMem 和 seekdb M0 更适合长期运行

评测解决的是 Agent 怎样安全试错，Memory 解决的是试错之后哪些经验应该留下来。一个负责研发过程，一个负责长期运行。其实这个过渡其实很关键，因为 Agent 运行越久，历史越多，噪声也越多。如果我们只是把聊天记录塞进上下文窗口，或者定期生成一段摘要，早期确实省事，后面会越来越难控制。

我见过不少 Agent Memory 的早期实现，基本就是这两类：把聊天历史直接塞进上下文窗口，或者定期生成一段摘要。短期观察，回答会变得更连续。时间拉长以后，用户偏好、任务状态、业务事实、临时判断、错误尝试和过期信息混在一起，模型既要记住重要内容，又要避开无关历史，Memory 很容易从加分项变成噪声源。

长期运行的 Memory，我更愿意把它看成数据资产。它需要判断哪些内容值得保存，哪些内容应该合并，哪些内容已经过期，哪些经验可以跨任务复用。客服 Agent 每次回答时无需加载完整历史对话，它更需要知道当前用户最近是否反复反馈同类问题，是否存在未完成工单，哪些历史偏好仍然有效。Coding Agent 也无需记住所有终端输出，它更需要知道上一次调试失败原因、最终可行修复路径，以及项目里的约定边界。

PowerMem 更关注记忆怎样形成、更新和沉淀，它会从对话与执行轨迹中抽取事实，处理冲突，保留有效经验，也会让已经过时或者价值较低的内容逐渐淡出。seekdb 提供的是底层存储和检索能力，让这些记忆能够通过向量、全文和标量条件被准确找回。seekdb M0 则在这两部分能力之上做了进一步整合，形成面向云端的自进化记忆服务，因此它与 PowerMem、seekdb 在底层设计上是一脉相承的。正在关注 Agent 长期记忆、经验复用和持续进化的开发者，可以通过 PowerMem 官网继续了解：https://www.powermem.ai/ 。

这里有一组对比数据很值得关注：PowerMem + seekdb M0 在 AppWorld 公平蒸馏实验里，通过率达到 39%，Hermes 为 22%；平均完成步骤为 6.2，Hermes 为 10.4；Token 消耗从 2.56M 降到 1.74M。 我对这组数字的理解很简单：Memory 的目标是让 Agent 在合适的时候找到更有价值的经验。保存更多文本并不会自动带来更好效果，相关性、时效性和可控性才会影响最终路径。

再往上观察，DataPilot 和 OceanBase OSI 处理的是业务语义。业务同学询问“本月经营指标为什么波动”，难点已经超过自然语言转 SQL，系统还要识别业务对象、计算口径、指标关系和归因路径。Memory 解决用户和任务连续性，语义层解决企业业务口径。两层结合以后，Agent 才有机会沿着业务规则处理问题。

总结

如果我们只观察产品名，Lakebase、DataStudio、DataPilot、PowerMem、PowerRAG 会显得很复杂。可我把它们放回 Agent 生产化这件事里理解，逻辑就很清晰：先要有地方保存数据，再要把数据检索准确，再要把多模态数据加工出来，再要让 Agent 可以安全试错，最后还要把有效经验沉淀下来。

这次围绕 OceanBase 面向 AI 的产品家族重新梳理了一遍，我更确定了一件事：这些产品并不是分散的功能发布，它们对应的是 Agent 进入生产环境后会连续遇到的数据问题。

Agent 数量增长以后，我们先要处理大量小型数据空间的隔离、保留、唤醒和低成本扩展。Agent 进入生产任务以后，检索结果是否可信，取决于数据是否新鲜、权限是否一致、版本是否可追溯。非结构化数据、离线加工、在线查询、权限控制和模型调用之间需要更短流程，Lakebase 主要处理的就是这些连续成本。

继续往后，Agent 会持续试错和自我改进，Fork Database 这样的数据分支会进入生产级研发流程。长期运行的 Agent 也需要 PowerMem、seekdb M0 这样的记忆系统，以及 DataPilot、OSI 这样的业务语义系统。这样理解下来，Lakebase 更像一套给 Agent 准备的数据工作台。说得直白一点，企业要先把结构化数据、文档、日志、向量和权限规则组织到一套更稳定的流程里，Agent 后面查数据、做判断、生成结果时，才不会总是被旧版本、权限错位和来源不清这些问题拖住。

如果大家现在还在构建个人知识库、轻量 RAG 或 Agent 原型，我建议先研究 seekdb。它适合从混合搜索和轻量部署切进去。如果大家已经开始考虑长期记忆、多 Agent 协作、用户偏好沉淀和经验复用，可以把 PowerMem 放进备选清单。它更接近 Agent Memory 的长期资产层。等系统已经涉及多模态数据处理、权限控制、离在线计算、生产评测和业务语义，Lakebase、DataStudio、DataPilot 这些产品会逐渐成为基础设施。

AI 应用进入业务深水区以后，谁的数据更干净、更及时、更容易被模型使用，谁的应用就更容易站住。模型再强，也需要可靠的业务信息。数据库迟早要承担这部分责任，区别只在于我们提前准备，或者等生产问题暴露以后再补课。

对 OceanBase Lakebase、seekdb、PowerMem 这类 AI 数据库能力感兴趣的开发者，可以通过下方官方二维码联系 OceanBase 工作人员继续交流。无论是了解产品资料、申请试用，还是讨论 RAG、Agent 数据底座、混合搜索、多模态数据处理和长期记忆等落地问题，都可以通过官方渠道获得更直接的支持。