OceanBase 4.4.2 LTS 系列解读四 | Agent 时代，数据库不该只是“存储”

转自：OceanBase

作者 | 姚莹莹，OceanBase 内核产品经理

全文共 4510 字，阅读约需 8 分钟

2026 年春天，一只红色龙虾席卷了整个开发者社区。

OpenClaw——这个 GitHub 星标突破 28 万的开源 AI Agent 框架，让“养虾”成为了技术圈的热词。AI 不再只是“能聊天的助手”，而是能接管电脑、自主干活的“数字员工”：自动整理文件、处理邮件、写代码调试、做调研报告，甚至在你开会的时候替你修完几个 Bug、发完一篇推文。

但当“养虾”的新鲜感退去，真正把 Agent 用到生产环境的人发现事情没那么简单。

“

一位开发者写道：我的三个 Agent 跑通了 100% 自动化，每天自动提交 50 次 commit。但当我让 Agent 去做需要查业务库 + 检索知识库 + 调大模型的复合任务时，整个链路脆得像纸——向量库查一次、业务库查一次、Embedding API 调一次、LLM API 调一次，四五跳调用链，任何一跳超时，全链路就崩。

”

这个问题值得细想。Agent 的能力上限，不只取决于它有多聪明，更取决于它获取和操作数据的速度、准确性和可靠性。换句话说，Agent 的瓶颈不在模型层，而在数据层。

过去三十年，数据库为“人”设计——DBA 写 SQL，应用通过 ORM 读写。现在，数据库的主要调用者变成了 AI。Agent 从“对话助手”变成“数字员工”，底层数据基础设施也得跟着变：从存储中心，变成知识与记忆中心。

AI Agent 对数据库提出的新要求

这种转变涉及几个相互关联的维度。

从“单纯查询”到“多模态混合搜索”

数据类型的扩展是最直接的变化。传统数据库处理结构化或半结构化数据，但 Agent 要处理的是更复杂的异构数据：

事实数据是传统的基于关系表的结构化业务数据，比如订单状态、库存余量，这是 Agent 决策的基础；
过程数据是动态的 SOP 和任务拓扑，不仅要存文字描述，还要存逻辑步骤，让 Agent 知道“先做什么，再做什么”；
情境记忆则包含用户意图、环境参数和长短期交互历史，让 Agent 更懂用户。

Agent 需要实时记录中间思考、当前目标和已完成步骤，实现实时状态管理。在单次或多轮会话中，Agent 还要维护连贯的对话上下文、用户意图的动态演变，以及当前交互积累的临时知识。数据库需要高效管理这些具有时效性的上下文数据，支持滑动窗口式的上下文裁剪和基于相关性的上下文召回。

更重要的是，Agent 的真正智能在于从历史交互中持续学习和进化，数据库需要承载用户偏好画像、历史决策模式、成功与失败的经验摘要等长期知识，并支持基于向量检索与结构化查询的混合召回。

高频微写，毫秒级响应

响应速度的要求也随之改变。Agent 的决策是一条链：感知、思考、行动、反思。这条链里，Agent 可能要跟数据库交互几十次甚至上百次——检索记忆、查工具结果、读中间状态、更新上下文。

延迟会累积。单次查询慢 50ms，20 轮迭代后就多了 1 秒。在 Agent 场景里，毫秒级响应不是优化项，而是决定产品可用性的硬门槛。一个响应慢 1 秒的 Agent，用户不会把它当“智能助手”，只会觉得它“卡”。

更重要的是，这种性能要求很难通过缓存或异步优化来解决——Agent 的每次查询都是上下文相关的，很难预测和预加载。

Agent 的数据访问模式也跟传统应用不一样。传统应用是批量报表或规整 CRUD，Agent 是高频、细粒度的“记忆碎片”读写——一段对话摘要、一个推理结论、一次工具返回值。数据单体小但访问密集，要求数据库在高并发小事务、热点索引命中率、写入即可见的一致性上都有极高水准。

OceanBase 基于 LSM-Tree 的存储引擎与分布式事务架构，天然适配这种“高频微写、即时可读”的工作负载，为 Agent 的流畅推理提供坚实的数据底座。

生产级的可靠性

可靠性标准也相应提高。Agent 进生产环境，就不是玩具了。金融风控、医疗问诊、政务审批——任何一次数据不一致或系统故障，后果都是真金白银或人身安全的损失。

Agent 背后的数据系统必须经得起考验：ACID 事务保证原子性和一致性；高可用架构保证节点故障、网络分区时服务不中断；多租户隔离防止数据越权；细粒度权限控制约束 Agent 的行为边界。

这里有一个常被忽视的点：Agent 的“自主性”意味着它可能在你睡觉的时候还在执行操作。一旦出错，影响可能是批量的、持续的。所以 Agent 场景对可靠性的要求，实际上比传统应用更高——你不只是在保护数据，更是在约束一个“数字员工”的行为边界。

数据库即工具：一次调用完成闭环

交互方式也在发生根本变化。在 Agent 架构里，数据库不再是幕后的存储层，而是工具箱里的一等公民。Agent 自主决定何时查库、查什么、怎么查。

理想情况下，Agent 用一条 SQL 就能完成 Embedding 生成、向量检索、结构化查询、大模型调用——不需要中间穿插多个外部 API。调用链从“Agent → Embedding API → 向量库 → 业务库 → Rerank API → LLM API”六跳，缩短成“Agent → 数据库”一跳。

每减少一跳，就少一分网络开销、少一分故障概率、多一分可靠性。

现有方案的问题

面对这些需求，业界目前的做法主要有两类，但都有明显局限。

方案一：关系型数据库 + 外挂向量插件

这种做法的优势是兼容现有生态、改造成本低。但向量检索是“嫁接”而非“内生”——查询优化器感知不到向量索引的代价模型，没法在向量检索和关系型过滤之间做联合优化。

面对 Agent 场景的混合查询（语义相似度 + 结构化过滤 + 排序），往往变成“先向量召回、再逐条过滤”的串行模式，数据量一上来性能就崩。

本质上，这是在用 40 年前的数据库架构跑 2026 年的 AI 工作负载，瓶颈是结构性的，不是调优能解决的。

方案二：独立向量数据库

专用向量库 ANN 性能确实好，但它只解决了“语义检索”这一个环节。Agent 还要查业务数据、执行事务、跑复杂分析 SQL，这些它都干不了。最后企业得同时运维关系库和向量库两套系统，中间靠应用层做数据同步和结果拼接。每个系统的可用性、延迟、版本兼容、数据一致性都要单独管。Agent 一次简单查询，幕后可能是五六跳网络调用和多次格式转换，任何一个环节超时或异常，整条链路就挂。

这种“胶水架构”的脆弱性，在生产环境是没法接受的。它解决了“能用”的问题，但没解决“好用”和“可靠”的问题。对于真正要把 Agent 投入生产的团队来说，这不是技术选型，而是技术债务。

另一种思路：把能力做进内核

与其在架构层面打补丁，不如重新思考数据库本身应该具备什么能力。

向量是原生能力，不是插件

OceanBase 从内核层面支持向量数据类型和向量索引，不是外挂插件“嫁接”的。支持稠密向量和稀疏向量，内置多种距离算法。欧氏距离（L2）适合空间位置敏感的场景，余弦相似度（Cosine）适合关注方向而非幅值的语义匹配，内积（Inner Product）则常用于归一化后的 Embedding 检索。

索引层面提供内存和磁盘两类方案。对于延迟要求极高的在线检索场景，HNSW 图索引在百万级向量规模下可以获得亚毫秒级响应。对于数据量更大、成本更敏感的场景，IVF 索引通过聚类划分将检索范围收敛到少量簇内，大幅降低内存占用的同时保持较高的召回率。

量化压缩方面，标量量化（SQ）将浮点向量压缩为低精度整数表示，以较小的精度损失换取数倍的存储节省和检索加速。乘积量化（PQ）通过子空间分解与码本编码实现更高的压缩比，适用于超大规模向量集合。二进制量化（Binary）将向量映射为比特串，利用位运算实现极致的距离计算速度，适合对吞吐量要求极高的粗筛阶段。用户可以根据业务对召回率、查询性能与存储成本的不同侧重，灵活组合索引类型与量化策略。

这些向量索引能力和 LSM-Tree 存储引擎深度集成，确保在高并发写入场景下向量索引依然能够高效维护和实时可查。

混合搜索：一条 SQL 搞定

有了向量能力，下一步是让不同类型的检索能协同工作。

Agent 决策时，往往既要语义向量检索找相似知识，又要全文检索匹配专业术语，还要关系型条件过滤限定时间、权限、业务类别。这三类检索能力缺一不可，而将它们协同起来的混合搜索，正是 Agent 场景对数据库的核心要求。

OceanBase 在同一引擎内融合了向量检索、全文检索与关系型查询三大能力，支持在一条 SQL 中同时执行多路检索并统一排序返回。Agent 可以在一次查询中同时发起向量相似度召回和关键词全文匹配，再叠加业务表的条件过滤，最终通过 RRF 等融合排序算法将多路结果归并为一个统一的排序列表。整个过程在数据库内完成，无需应用层分别调用向量库和搜索引擎后再手动拼接结果。

这种内核级的混合搜索带来了几个好处。查询优化器能够统一感知向量索引、全文索引和 B+ 树索引的代价模型，智能选择最优的执行路径，避免外挂方案中“先检索、再过滤”的串行瓶颈。所有检索操作共享同一事务上下文，数据一致性由内核保证，不会出现向量库与业务库之间数据不同步的问题。Agent 的调用链路从多跳网络请求收敛为一次数据库交互，端到端延迟大幅降低，系统稳定性也随之提升。

SQL 内置 AI 函数

混合搜索之外，AI 能力的封装也值得关注。

OceanBase 把 Embedding 生成（AI_EMBED）、大模型调用（AI_COMPLETE）、结果重排（AI_RERANK）都封装成 SQL 函数。Agent 只用 SQL 就能完成从数据查询到 AI 推理的全流程。

-- Agent 的一次完整 RAG 调用，一条 SQL 搞定 SELECT AI_COMPLETE('qwen-max',          CONCAT('基于以下资料回答问题：',                 (SELECT GROUP_CONCAT(content)                  FROM knowledge_base                  ORDER BY VECTOR_COSINE_DISTANCE(embedding,                            AI_EMBED('text-embedding-v3', '用户的问题'))                  LIMIT 5),                 '\n问题：用户的问题')) AS answer;

对 Agent 框架来说，OceanBase 就是一个“超级工具”——调用链从六跳缩短成一跳，可靠性随之提升。

生产级可靠性

技术能力之外，还有可靠性问题。

OceanBase 是金融核心场景里锤炼出来的分布式数据库，有完整的 ACID 事务、多副本高可用、多租户隔离、细粒度权限控制、在线弹性扩缩容。Agent 在 OceanBase 上跑，用的是跟银行核心系统同级别的可靠性保障。

LSM-Tree 存储引擎和分布式事务架构，天然适配“高频微写、即时可读”的 Agent 工作负载。

Agent 从实验室走向金融风控、医疗问诊、政务审批时，数据底座必须是经得起生产环境考验的成熟基础设施。OceanBase 在拥抱 AI 新能力的同时，用十余年积累的生产级可靠性为 Agent 的每一次决策兜底。

还可以做什么

沿着这个思路，还有一些能力值得探索。

AI 列是 OceanBase 即将推出的功能。它是一种声明式的智能衍生列，用户只需定义规则，数据流转、模型交互与结果维护全部交给数据库。

AI 列和普通列一样，能参与 SELECT、WHERE、GROUP BY、JOIN 等各种操作。对 Agent 来说，这种能力完全透明，不需要应用层“逐行调用、手动解析、反复回写”，可以避免大量数据搬运。

行级权限控制也是多 Agent 协作场景的刚需。不同 Agent 操作同一张表时，应该只能看到各自权限范围内的数据行，这需要数据库层面的细粒度访问控制。

海量逻辑表支持则面向规模化场景。当 Agent 平台从服务几十个企业客户扩展到服务数百万个人用户时，“海量小租户”成为常态——每个租户数据量不大，但租户数量庞大，且彼此之间必须严格隔离。逻辑表是实现 Agent 数据隔离的核心抽象，多个 Agent 看到的是“各自的表”，但物理上共享同一张表，通过数据库引擎保证隔离性。

结语

AI Agent 成为企业“数字员工”时，它们的工作台不该是一堆七零八落的工具，而是一张整合一切能力的工作桌。

OceanBase 正在成为那张桌子。

这个判断背后有一个更底层的趋势：数据库和 AI 的边界正在模糊。过去我们习惯把数据库当“存储”，把 AI 当“计算”；但在 Agent 架构里，数据本身就是智能的来源，存储和计算的分离只会增加延迟和复杂度。把向量检索、全文搜索、AI 推理都做到数据库内核里，不是“功能堆砌”，而是“架构回归”——让数据离计算更近，让智能离数据更近。