当用户可以持续生成 Agent，规模问题就不再只是单个数据库有多大，而是千万级 Agent 能否各自拥有独立、可计算的数据与记忆空间，并在同一套基础设施上低成本、可控地长期运行。

这是我们选择 OceanBase 的重要原因。

—— 蚂蚁灵光

当 AI 可以持续生成 Agent，数据基础设施面对的规模问题，也从“一个系统里有多少数据”，变成“需要同时管理多少个独立的数据与记忆空间”。面向海量 Agent，OceanBase 提供统一的数据基础设施：通过逻辑表承载每个 Agent 的独立数据空间，通过记忆能力持续保存、检索和调用上下文、历史事实与经验。

用户只需说一句“帮我做一个记账应用”，蚂蚁灵光就可以生成页面、交互逻辑、后端代码和数据结构，并将它发布成一个可以直接使用的闪应用。这个闪应用，本身就是用户在灵光平台上生成的 Agent。

图片来自灵光官网截图

生成 Agent 正在变得越来越容易。但 Agent 被生成之后，数据问题才刚刚开始：用户产生的数据存在哪里？不同 Agent 拥有不同的字段，数据库是否要为每个 Agent 创建一张物理表？当用户查询“本月一共支出了多少钱”，计算由谁完成？Agent 长期无人使用时，数据和记忆又该如何低成本保存？

蚂蚁灵光已经承载约 3000 万个闪应用，也就是约 3000 万个由用户生成的 Agent。这个数字不是 3000 万个数据库实例，也不是 3000 万个需要持久化的数据库或并发连接。

它代表的是一种新的基础设施压力：平台需要面对数量极大的 Agent 数据与记忆空间。每个空间可能很小，但 Schema 动态生成、彼此需要隔离，并且要在用户再次调用 Agent 时继续提供数据服务。

OceanBase 与灵光采用的逻辑表方案，让需要持久化和计算能力的海量 Agent，在同一套数据库基础设施上拥有独立的 Schema、数据边界和 SQL 体验。OceanBase 同时将记忆作为数据库的原生管理对象，通过混合搜索完成检索与计算，统一承载 Agent 的业务数据、运行状态和长期记忆。

海量 Agent 带来的问题，不只是数据量增长。

一个用户可以拥有多个 Agent，一个 Agent 又可能拥有多张业务表、多个任务状态和自己的长期记忆。单个数据或记忆空间未必很大，但数量很多、相互隔离，访问频率和生命周期也存在明显差异。如果继续为每个 Agent 创建独立数据库或物理表，元数据和常驻资源会快速膨胀；如果把所有数据和记忆放进共享表和共享索引，检索又可能处理大量与当前 Agent 无关的内容。

因此，面向海量 Agent 的数据基础设施需要同时回答两个问题：

• 数据如何承载：每个 Agent 都要有自己的 Schema、业务数据和运行状态，但不需要独占一套物理数据库。逻辑表解决的是这个问题。

• 记忆如何管理：每个 Agent 都要能够保存并调用自己的上下文、历史事实和经验。OceanBase 将记忆持久化，并结合结构化过滤、全文和向量完成检索与计算。

灵光的 3000 万闪应用，本身就是海量用户生成 Agent 的真实实践。OceanBase 在同一套数据库中承载这些 Agent 的数据与记忆：通过逻辑表管理业务数据和运行状态，通过记忆能力保存和调用上下文与长期经验。

以一个记账闪应用，也就是记账 Agent 为例。

用户用自然语言描述需求：“做一个记录收入和支出的应用，包含日期、收支类型、项目、金额和备注，并且能够统计每月支出。”

灵光据此生成页面、后端逻辑和数据结构。Agent 发布后，用户录入一笔 58 元的餐饮支出。生成后的后端代码通过灵光服务端数据库模块，把这条记录写入数据库。

图片来自灵光官网截图

用户查询“本月支出”时，Agent 后端发起数据查询，由数据库完成日期过滤和金额汇总。下次调用这个 Agent 时，原有记录仍然存在，用户可以继续查询、修改和新增数据。

整个链路中，终端用户和 Agent 前端都不直接连接 OceanBase。灵光主要在 Agent 生成阶段产生 Schema 和数据操作逻辑；Agent 运行后，由后端代码通过灵光服务端数据库模块访问数据库。这不是一个运行期每次都让大模型临时生成 SQL 的 NL2SQL 系统。

AI 可以生成页面和代码，也可以生成类似下面的逻辑操作：

SELECT SUM(amount)
FROM transactions
WHERE type = 1
  AND record_date >= '2026-07-01';

但金额累加、日期过滤和类型转换，不能依赖大模型推断。AI 可以生成 SQL，计算结果仍然需要数据库保证确定性。

对灵光而言，难点还不只是保存一笔账。Agent 是动态生成的：记账 Agent 需要金额和日期，打卡 Agent 需要完成状态，报名 Agent 需要联系人和报名信息。平台无法预先知道下一个 Agent 会生成什么 Schema，也不可能针对每种新结构在业务层单独开发一套数据接口。

每个需要持久化的 Agent，都需要一张“像数据库表一样”的数据空间：能够定义字段和类型，保存行数据，并执行受控的查询与计算。

传统软件的数据库和表结构相对稳定。用户生成 Agent 呈现出的特征不同：Agent 数量极大，Schema 持续变化，单个 Agent 的数据量通常不大，大量 Agent 长期处于低频访问状态，但用户重新调用时又需要及时恢复服务。

最直接的做法，是为每个 Agent 创建一个数据库或一张物理表。这样能够获得原生的 Schema 和 SQL 能力，但物理表数量会随 Agent 数量一起增长。很多 Agent 可能只有几条、几十条记录，真正的业务数据只有几 KB，表定义、系统表和 Schema 元数据的开销却可能远大于数据本身。

即使底层使用分布式数据库，千万乃至更大数量级的物理表，也会给元数据管理和常驻资源带来持续压力。这个问题不是简单增加机器就能解决的。

另一种做法，是把不同 Agent 的数据全部保存成 JSON。这样可以共享底层存储资源，也能容纳动态 Schema，但只解决了“存下来”的问题。金额汇总、日期过滤、排序和关联等计算，要么由平台逐一开发定制接口，要么把原始数据交给模型处理，都难以形成稳定、可复用的数据能力。

灵光需要的是第三种路径：底层资源可以共享，但每个 Agent 看到的 Schema 和数据边界必须独立，同时还要保留关系数据库的计算能力。

逻辑表将 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 对共享资源的消耗。

在灵光的方案中，数据库访问由服务端数据库模块统一承接。业务权限模块根据用户、Agent 和版本信息改写 SQL，补充相应的数据范围；JSON Table SDK 再将逻辑 SQL 转换为物理 SQL，并检查查询是否携带必要的 Agent 边界。

数据库访问使用预编译语句，降低 SQL 注入风险。SDK 通过 SQL 白名单逐步开放建表、增删改查、过滤、聚合和部分表达式等能力，避免 AI 生成任意高风险 SQL。对于扫描范围大或资源消耗高的操作，系统还需要限制单次扫描行数、执行时间和可使用的 SQL 能力，防止一个 Agent 影响共享资源池中的其他 Agent。

在灵光 Agent 场景中，逻辑表先把隔离落实到数据访问层：每次查询都被限定在指定用户、Agent 和版本范围内。OceanBase 正在把同一边界继续扩展到数据、索引和生命周期，让一个 Namespace 对应一个用户、Agent 或记忆库，其下的数据和记忆既能独立管理，又能共享底层资源池。

逻辑表适合“小而多”的长尾 Agent。随着某个 Agent 的数据量、访问量或计算复杂度持续增长，可以迁移到物理表或具备更强资源隔离能力的数据空间。这样，低频 Agent 使用共享资源，高访问量 Agent 使用独立资源，数据基础设施可以随 Agent 成长而演进。

灵光面对的挑战，不是一个数据库中的数据量特别大，而是 Agent 和数据空间的数量发生了变化。

逻辑表方案让需要持久化与计算能力的长尾 Agent 共享一套数据库基础设施，物理表和常驻元数据不必随 Agent 数量同步增长。每个 Agent 仍然保留自己的 Schema、行数据和 SQL 交互方式，平台也不必为每种新生成的数据结构重复开发计算逻辑。

借助 JSON_TABLE() 和 SQL 引擎，JSON 不再只是一种存储格式。数据库可以按照 Agent 自己的 Schema，将半结构化数据映射成关系表，继续完成类型转换、过滤和聚合等计算。

对灵光来说，这意味着长尾 Agent 可以共享底层资源，又能在访问时保持清晰的 Agent 和版本边界。用户生成新的 Agent 后，可以直接获得数据持久化和确定性计算能力，不需要平台针对每个 Agent 单独准备一套数据库。

AI 时代的数据库规模，不一定只表现为单表行数或单库容量持续增长，也可能表现为千万级动态 Schema 和独立数据空间同时存在。数据库不仅要能“存得大”，也要能低成本管理“小而多”。

灵光闪应用就是用户生成的 Agent。每个 Agent 不只保存业务数据，还要保存任务状态、会话上下文、历史事实和长期经验。对 OceanBase 来说，这些并不是彼此割裂的系统：记忆本质上也是数据，由文本、结构化字段、向量和相关元数据共同构成。

因此，OceanBase 将 Agent 的数据与记忆放在同一套基础设施中管理：逻辑表承载业务数据和运行状态，记忆能力负责上下文与长期经验。

逻辑表：管理 Agent 的业务数据和运行状态

Agent 会操作业务系统、调用工具并持续执行任务。订单、任务、配置、进度、工作流状态和工具返回结果，都需要事务、Schema、权限和确定性计算。

逻辑表让每个 Agent 拥有自己的数据模型和访问边界，同时复用同一套数据库基础设施。一个 Namespace 可以对应一个用户或 Agent，下面可以包含多张逻辑表；同一 Namespace 内的数据可以关联和计算，不同 Namespace 之间保持边界。

这意味着，Agent 数量增长时，逻辑数据空间可以随之增长，物理数据库和表的数量不必一比一增长。在 3000 万闪应用的规模下，“小而多”已经成为灵光必须面对的数据形态，逻辑表直接回应了这一工程需求。

OceanBase 记忆能力：管理 Agent 的上下文和长期记忆

Agent 需要记住用户偏好、历史决策、任务进展和已有经验。记忆能力包含两个部分：一是记忆数据的持久化管理，二是记忆的检索与计算。

一条记忆可能同时包含结构化字段、文本和向量。仅靠向量相似度并不足以完成所有召回：结构化条件用于限定用户、Agent、时间和业务范围，全文搜索用于寻找明确事实，向量搜索用于寻找语义相近内容。OceanBase 通过混合搜索，把这些检索方式放在同一份数据之上，统一管理 Agent 的上下文与长期记忆。

OceanBase 正在把记忆能力与逻辑表进一步结合，将“一个 Agent 的数据空间”扩展为“一个 Agent 的数据与记忆空间”。

Namespace 可以对应用户、Agent 或记忆库，其下的逻辑表分别承载业务数据、状态和不同类型的记忆。业务数据和记忆不需要分散到多套数据库中，权限、检索和生命周期也可以围绕同一个 Agent 边界管理；面向 Agent 的新逻辑表设计，则继续把隔离范围从数据扩展到索引和冷热分层。

数据、索引与生命周期按 Agent 管理

很多共享记忆系统通过用户 ID 或 Agent ID 区分数据，但底层索引仍然共享。一次检索可能先从共享索引中召回候选结果，再过滤掉不属于当前 Agent 的内容。随着平台总体记忆规模增长，无关数据带来的计算和内存开销也会增加。

OceanBase 面向 Agent 的逻辑表设计，是让数据、索引和生命周期都围绕 Namespace 组织。Agent 检索记忆时，只访问属于自己的数据和索引；长期低频 Agent 的数据与索引可以整体下沉到共享存储，需要时再按需加载。

这对向量索引尤其重要。向量检索通常需要占用较多内存，如果可以按 Agent 对低频数据和索引进行淘汰、下沉和加载，资源消耗就能更多地取决于活跃 Agent 数量，而不是平台历史上创建过的 Agent 总量。

对于持续活跃、数据量或并发量不断增长的 Agent，数据则可以从共享逻辑表迁移到物理表或独立资源空间。逻辑表、冷热分层和大小表迁移，分别对应海量 Agent 从创建、沉默到成长的不同生命周期需求。

Agent 在运行过程中，会不断产生和使用业务数据、任务状态、工具结果、会话上下文、历史事实与长期经验，也会调用文档、图片、音视频和向量等不同形态的知识。这些内容共同构成 Agent 执行任务所需的数据与上下文，并随着使用持续更新。

OceanBase 将这些数据放在同一套基础设施中管理，提供统一的事务与一致性、SQL 计算、混合搜索、权限边界和分布式可靠性。逻辑表管理海量 Agent 的数据空间，记忆能力管理上下文和长期经验；当 Agent 需要升级、测试或恢复时，数据版本与分支能力可以提供相应的数据环境。

在 OceanBase 内部，逻辑表用于解决“海量 Agent 如何各自拥有数据空间”，记忆能力与混合搜索用于解决“Agent 如何保存和调用记忆”。业务数据、状态、记忆和知识由同一套 OceanBase AI 数据库统一治理、检索和计算。

这正是 OceanBase 从原生分布式数据库走向 AI 数据库的核心变化：在一体化架构中，让一份数据同时服务事务、分析、搜索、记忆和 AI 工作负载；原生分布式架构继续为这些能力进入生产系统提供可靠性和规模化基础。

灵光的挑战，不是支撑 3000 万个数据库，而是在 3000 万个用户生成 Agent 的规模下，让每个需要持久化和计算的 Agent 拥有自己的数据与记忆空间。

OceanBase 通过共享底层资源、Agent 级逻辑表和受控 SQL 计算，让每个 Agent 的数据模型可以独立，底层资源不必独占；通过原生记忆能力与混合搜索，让 Agent 的上下文和长期记忆能够持续保存、检索和使用。

借助 OceanBase，灵光可以在同一套基础设施上为海量 Agent 提供独立的数据与记忆空间：通过逻辑表承载业务数据和运行状态，通过记忆能力管理上下文与长期经验。

当 AI 将 Agent 的生成成本不断降低，数据与记忆空间本身需要成为基础设施的一等对象。数据库不仅要管理越来越多的数据，也要管理越来越多独立、动态、长期存在的 Agent，以及它们持续积累的记忆。

立即试用 OceanBase 企业版，体验国产数据库能力180 天免费试用，零门槛开通