用户说一句“帮我做一个记账应用”，灵光就能生成页面、交互逻辑、后端代码和数据表结构，把它发布成一个可直接使用的闪应用。这个闪应用本身就是一个 Agent。
生成 Agent 越来越便宜，麻烦才刚开始。数据放哪？每个 Agent 字段都不一样，难道要建 3000 万张物理表？用户问“本月一共支出了多少”，谁来算？Agent 长期没人用，数据和记忆怎么低成本存着？
灵光目前承载约 3000 万个闪应用，也就是约 3000 万个用户生成的 Agent。注意，这不是 3000 万个数据库实例，也不是 3000 万个需要常驻连接和持久化的库。
它代表一种新的基础设施压力：空间数量极大，单个空间可能很小，Schema 动态生成、彼此隔离，用户再次调用时还得立刻恢复支撑。
物理表、JSON 大字段，都不是答案
老牌业务系统的库表结构相对稳定。用户生成的 Agent 完全不是这个特征：数量极大、Schema 持续变化、单 Agent 数据量通常不大、长期低频访问、被重新调用时需要及时响应。
最直觉的做法是每个 Agent 建一张物理表。原生 Schema、原生 SQL，听着很香。但物理表数量会随 Agent 数量线性增长。很多 Agent 只有几条、几十条记录，真实业务数据几 KB，而表边界、系统表和 Schema 元数据的开销可能远大于数据本身。
就算底层是分布式数据库，千万级以上的物理表也会给元数据管理和常驻资源带来持续压力。这不是加机器就能解决的问题——加机器解决的是吞吐，解决不了元数据体量。
另一种做法是把不同 Agent 的数据整体塞成 JSON。共享底层存储，动态 Schema 也装得下，但它只解决了“存下来”。金额汇总、日期过滤、排序、关联这些计算，要么平台逐个开发定制接口，要么把原始数据丢给模型处理，都难以沉淀成稳定可复用的数据能力。
灵光要的是第三条路：底层资源共享，但每个 Agent 看到的 Schema 和数据边界必须独立，同时保留关系数据库的计算能力。
逻辑表：Agent 看到的表，和底层真正建的表不是一回事
逻辑表把 Agent 看到的数据模型和底层数据组织解耦。从 Agent 的视角，它照样建表、写数据、执行查询；从数据库的视角，不需要为每张逻辑表建一张新物理表。
底层主要维护两类共享数据。
Schema 数据：用 Agent ID、版本号等标识，保存每个 Agent 自己的表结构定义。
行数据：用 Agent ID、版本号和记录 ID 划定范围，把每一条业务数据存成 JSON。
Agent 提交标准 SQL 后，JSON Table SDK 负责把逻辑表操作翻译成对共享数据的物理操作。查询时，SDK 先取到对应 Agent 的 Schema，再用 OceanBase 的 JSON_TABLE() 把 JSON 里的字段映射成带明确列名和数据类型的虚拟关系表，最后交给 SQL 引擎做过滤、聚合等计算。
一条逻辑 SQL 在系统内部大致走这四步：
创建逻辑表。灵光生成 CREATE TABLE 后，SDK 不建新物理表，只保存 Agent 的字段、类型和版本信息。
写入数据。Agent 执行 INSERT，SDK 把行数据转成 JSON，连同 Agent ID、版本号、记录 ID 一起写进共享数据表。
还原表结构。Agent 执行 SELECT 时，系统拿到对应 Schema，通过 JSON_TABLE() 把 JSON 映射为带类型的虚拟关系表。
执行确定性计算。OceanBase SQL 引擎在限定的 Agent 数据边界内完成过滤、聚合和部分表达式计算，再把结果返回给 Agent。
Agent 不需要理解 JSON_TABLE()，也不需要直接运维底层共享表。它用的是一套受控的标准 SQL 子集，JSON 存储与关系计算之间的转换由 SDK 和数据库共同完成。
一句话概括逻辑表的价值：Agent 拥有独立的数据模型和 SQL 体验，底层共享存储与计算资源。这不是给每个 Agent 模拟一套完整数据库实例，而是在共享基础设施上建立 Agent 级的数据虚拟化边界。
一个记账 Agent 的完整链路
拿记账闪应用举例。
用户用自然语言描述需求：做一个记录收入和支出的应用，包含日期、收支类型、项目、金额和备注，并且能统计每月支出。
灵光据此生成页面、后端逻辑和数据结构。Agent 发布后，用户录入一笔 58 元的餐饮支出，生成的后端代码通过灵光服务端数据库模块把这条记录写进数据库。
用户查询“本月支出”时，Agent 后端发起数据查询，由数据库完成日期过滤和金额汇总。下次再调用这个 Agent，原有记录仍在，可以继续查询、修改和新增。
整条链路里，终端用户和 Agent 前端都不直连 OceanBase。灵光负责在 Agent 生成阶段产出 Schema 和数据操作逻辑；Agent 运行后，由后端代码通过灵光服务端数据库模块访问数据库。
这不是一个运行期每次都让 Transformer 临时生成 SQL 的 NL2SQL 系统。
AI 可以生成页面和代码，也能生成类似这样的逻辑操作：
但金额累加、日期过滤和类型转换不能依赖 Transformer 推断。AI 可以生成 SQL，计算结果的确定性必须由数据库保证。
对灵光来说，难点还不只是存一笔账。Agent 是动态生成的：记账 Agent 需要金额和日期，打卡 Agent 需要完成状态，报名 Agent 需要关联人和报名信息。平台无法预先知道下一个 Agent 会生成什么 Schema，也不可能针对每种新结构在业务层单独开发一套数据 API。
每个需要持久化的 Agent，都需要一张“像数据库表一样”的数据空间：能定义字段和类型，能保存行数据，能执行受控的查询与计算。
隔离与限流：别让一个 Agent 拖垮共享资源池
海量 Agent 共用一套数据库基础设施，前提是每次访问都被限制在授权边界内，同时控制单个 Agent 对共享资源的消耗。
灵光的做法是数据库访问由服务端数据库模块统一承接。场景权限模块根据用户、Agent 和版本信息改写 SQL，补充对应的数据范围；JSON Table SDK 再把逻辑 SQL 转成物理 SQL，并检查查询是否携带必需的 Agent 边界。
访问采用预编译语句，压低 SQL 注入风险。SDK 通过 SQL 白名单逐步开放建表、增删改查、过滤、聚合和部分表达式能力，避免 AI 生成任意高风险 SQL。
这里有个坑：白名单不是一次开全就完事。生成式场景下 SQL 形态会持续漂移，白名单需要跟着业务能力演进逐步放开，否则要么误杀正常查询，要么放开过头。
对扫描范围大或资源消耗高的操作，还要限制单次扫描行数、执行时间和可用的 SQL 能力，防止单个 Agent 影响共享资源池里的其他 Agent。
逻辑表先把隔离落在数据访问层：每次查询都限定在指定用户、Agent 和版本范围内。OceanBase 正在把同一边界继续扩展到数据、索引和生命周期，让一个 Namespace 对应一个用户、Agent 或记忆库，其下的数据和记忆既能独立管理，又能共享底层资源池。
逻辑表适合“小而多”的长尾 Agent。当某个 Agent 的数据量、访问量或计算复杂度持续上升，可以迁移到物理表或隔离能力更强的数据空间。低频 Agent 用共享资源，高访问量 Agent 用独立资源，数据基础设施能随 Agent 成长而演进。
记忆也是数据，别把它当成另一套系统
灵光闪应用就是用户生成的 Agent。每个 Agent 不只保存场景数据，还要保存任务状态、会话上下文、历史事实和长期经验。
对 OceanBase 来说，这些不是彼此割裂的系统。记忆本质上也是数据，由文本、结构化字段、向量和相关元数据共同组成。
所以 OceanBase 把 Agent 的数据和记忆放在同一套基础设施里管理：逻辑表承载业务数据和运行状态，记忆能力负责上下文和长期经验。
Agent 会操作系统、调用工具并持续执行任务。订单、任务、配置、进度、工作流状态和工具返回结果，都需要事务、Schema、权限和确定性计算。逻辑表让每个 Agent 拥有自己的数据模型和访问边界，同时复用同一套数据库基础设施。
一个 Namespace 可以对应一个用户或 Agent，下面可以有多张逻辑表；同一 Namespace 内的数据可以关联和计算，不同 Namespace 之间保持隔离。
这意味着 Agent 数量增长时，逻辑数据空间可以随之增长，物理数据库和表的数量不必一比一增长。在 3000 万闪应用的体量下，“小而多”已经是灵光必须面对的数据形态。
Agent 需要记住用户偏好、历史决策、任务进展和已有经验。记忆能力包含两部分：记忆数据的持久化管理，以及记忆的检索与计算。
一条记忆可能同时包含结构化字段、文本和向量。只靠向量相似度不足以完成所有召回：结构化条件用来限定用户、Agent、时间和场景范围，全文搜索用于查找明确事实，向量搜索用于查找语义相近内容。OceanBase 通过混合搜索，把这些检索方式放在同一份数据上，统一管理 Agent 的上下文与长期记忆。
OceanBase 正在把记忆能力和逻辑表进一步融合，把“一个 Agent 的数据空间”扩展为“一个 Agent 的数据与记忆空间”。Namespace 可以对应用户、Agent 或记忆库，其下的逻辑表分别承载场景数据、状态和不同类型的记忆。业务数据和记忆不需要分散到多套数据库，授权、检索和生命周期也可以围绕同一个 Agent 边界管理。
索引和冷热分层，也要按 Agent 管
很多共享记忆系统靠用户 ID 或 Agent ID 区分数据，但底层索引仍然是共享的。一次检索可能先从共享索引召回候选结果，再过滤掉不属于当前 Agent 的内容。随着平台整体记忆体量增长，无关数据带来的计算和内存开销也会增加。
OceanBase 面向 Agent 的逻辑表设计，是让数据、索引和生命周期都围绕 Namespace 组织。Agent 检索记忆时，只访问属于自己的数据和索引；长期低频 Agent 的数据和索引可以整体下沉到共享存储，需要时再按需加载。
这对向量索引尤其重要。向量检索通常占用较多内存，如果能按 Agent 对低频数据和索引做淘汰、下沉和加载，资源消耗就能更多取决于活跃 Agent 数量，而不是平台历史上创建过的 Agent 总量。
对持续活跃、数据量或并发量不断上升的 Agent，数据可以从共享逻辑表迁移到物理表或独立资源空间。逻辑表、冷热分层和大表迁移，分别对应海量 Agent 从创建、沉默到成长的不同生命周期诉求。
验证逻辑表方案，别只看功能通不通
工程上判断这套方案是否真的成立，建议从几个可测的点入手。
元数据开销。统计创建 N 个逻辑表后系统表、Schema 元数据占用的空间，和创建同等数量物理表做对比。判定标准不是“能不能建”，而是 N 增长一个数量级时元数据开销是否近似线性且可控。
查询隔离。用两个 Agent 的相同字段名写入不同数据，交叉查询验证是否越界。校验命令层面，重点看带 Agent 边界的物理 SQL 是否出现在执行计划里，以及 EXPLAIN 输出中扫描范围是否被限制在目标 Agent 的数据分区内。
计算确定性。同一聚合 SQL 在逻辑表和物理表上执行，结果必须一致。金额汇总、日期过滤、类型转换这三类最容易出问题，尤其是 JSON 数字类型和数据库数值类型之间的隐式转换。
资源约束。构造一个扫描范围极大的查询，确认扫描行数限制、执行时间限制是否按预期触发，而不是把共享资源池拖慢。
能力边界：什么时候该迁走
逻辑表不是万能的。
它适配“小而多”的长尾 Agent。如果某个 Agent 的单表行数到了千万级、并发写入很高、或者需要复杂的跨表事务，继续放在共享逻辑表里就不合适了。这不是性能调优能绕过去的，而是资源隔离模型决定的。
迁移路径要提前留好。逻辑表、冷热分层、大小表迁移三件事配合起来，才能覆盖 Agent 从创建、沉默到成长的完整周期。低频 Agent 用共享资源，高访问量 Agent 用独立资源，这个演进能力比单点性能更重要。
另一个风险点是 Schema 版本管理。Agent 会迭代，字段会增删，逻辑表保存了版本信息，但历史数据的兼容性需要明确策略——是保留旧版本可查，还是做迁移。这一步没设计好，后面查询会踩坑。
数据库要能“存得大”，也要能管住“小而多”
灵光面对的挑战不是支撑 3000 万个数据库，而是在 3000 万个用户生成 Agent 的体量下，让每个需要持久化和计算的 Agent 拥有自己的数据与记忆空间。
OceanBase 通过共享底层资源、Agent 级逻辑表和受控 SQL 计算，让每个 Agent 的数据模型独立，底层资源不必独占；让 Agent 的上下文和长期记忆持续保存、检索和使用。
通过 JSON_TABLE() 和 SQL 引擎，JSON 不再只是存储格式。数据库可以根据 Agent 自己的 Schema，把半结构化数据映射成关系表，继续完成类型转换、过滤和聚合等计算。
对灵光来说，这意味着长尾 Agent 可以共享底层资源，又能在访问时保持清晰的 Agent 和版本边界。用户生成新 Agent 后，直接获得数据持久化和确定性计算能力，平台不需要为每个 Agent 单独准备一套数据库。
AI 时代的数据库规模，不一定只体现为单表行数或单库容量持续增长，也可能表现为千万级动态 Schema 和独立数据空间并存。数据库不仅要能“存得大”，也要能低开销管理“小而多”。
Agent 运行过程中会不断产生和使用场景数据、任务状态、工具结果、会话上下文、历史事实与长期经验，也会调用文档、图片、音视频和向量等不同形态的知识。这些内容共同构成 Agent 执行任务所需的数据与上下文，并随使用持续更新。
OceanBase 把这些数据放在同一套基础设施里管理，提供统一的事务与一致性、SQL 计算、混合搜索、授权边界和分布式可靠性。逻辑表管理海量 Agent 的数据空间，记忆能力管理上下文和长期经验；当 Agent 需要升级、测试或恢复时，数据版本与分支能力可以提供对应的数据环境。
在 OceanBase 内部，逻辑表解决“海量 Agent 如何各自拥有数据空间”，记忆能力与混合搜索解决“Agent 如何保存和调用记忆”。业务数据、状态、记忆和知识由同一套 OceanBase AI 数据库统一管理、检索和计算。
这是 OceanBase 从原生分布式数据库走向 AI 数据库的核心变化：在一体化架构中，让一份数据同时服务事务、分析、搜索、记忆和 AI 工作负载；原生分布式架构继续为这些能力进入生产系统提供安全性和规模化基础。
当 AI 把 Agent 的生成成本不断压低，数据与记忆空间本身需要成为基础设施的一等对象。数据库不仅要管理越来越多的数据，也要管理越来越多独立、动态、长期存在的 Agent，以及它们持续积累的记忆。
往期内容推荐
