Agent与数据库的变革

对于一名熟悉业务的财务人员来说，“公司的活动总预算是多少？ ”或许是个再简单不过的问题。 但在某数据库厂商测试的企业级Agent场景中，AI给出的答案与真实情况相差了近15倍。 AI自主检索企业数据库，在众多包含“金额”字段的列中机械求和，最终得出一个高达2916万元的荒谬数字。 而在企业实际的财务口径下，真实的活动预算仅有198万元。 问题在于其根本不知道企业所谓的“活动预算”，究竟应该对应哪一个字段。

这个看起来有些荒诞的乌龙，却揭开了当下企业Agent落地普遍存在的矛盾，那就是模型越来越聪明，企业的数据系统却未必做好让AI自主工作的准备。 这也让企业开始重新审视自己的数据基础设施。 今年2月，Gartner在一项关于企业AI数据架构的研究中指出，数据准备不足已经成为AI应用的主要障碍，推动超过75%的组织优先投资AI就绪数据能力。 换句话说，当企业发现仅靠升级大模型无法解决业务问题时，开始把目光转向过去藏在后台的数据库。 AI落地的竞争，正在从模型能力延伸到数据底座。 这种需求，进一步推动了市场规模的增长。

中国信通院《数据库发展研究报告（2026年）》显示，2025年中国数据库市场规模约677.96亿元，预计2028年达到979.74亿元，年复合增长率13.06%。 市场规模持续扩大的同时，Agent带来的新需求，也在推动数据库厂商重新调整产品方向。 嗅觉敏锐的基础软件厂商们，动作也明显加快。 今年1月，火山引擎开源面向Agent的上下文数据库OpenViking，试图统一管理智能体的记忆、资源与技能调用； 3月，华为发布AI数据平台，主打知识检索与KV Cache加速；

5月，腾讯云为TDSQL-C引入分支（Branch）能力，并升级团队级Agent Memory； 6月与8月，OceanBase相继上线湖库一体架构与毫秒级快照克隆（Fork）功能； 10月，镜舟科技发布MIP企业级AI数据平台。 短短几个月，从交易数据库、实时分析到湖仓平台，不同技术路线的厂商密集推出新能力，产品边界也开始变得模糊。 一个事实是，当数据库的主要使用者从人逐渐扩展到Agent，沿用了数十年的数据库架构，正在发生重构。

为什么过去已经服务企业几十年的数据库系统，到了Agent时代突然需要大规模改造？ 事实上，过去四十年，数据库及其周边的数据系统主要是为“人”服务的，而且分工明确。 传统数据库存放订单、交易等结构化数据； 网盘和数据湖存储合同、录音、图片、视频等非结构化数据； 搜索引擎和向量库则负责按关键词或相似度“找东西”。 过去，员工在几套系统之间来回查找、核对，花半天出一份报表也无妨。 如今，换成了24小时不停工的Agent，几秒内就能连续查询多套系统、调用模型推理，甚至直接执行操作。 这时，传统数据库架构的局限便开始显现。

首先，是AI看得见数据，却看不懂业务。 开篇提到的2916万元错误预算，就是典型例子。 对于数据库而言，销售额、毛利率、活动预算都可以表示为字段与计算公式。 但企业的业务规则远比字段复杂。 比如计算销售额，是否需要扣除退款？ 统计上个月的订单，按下单时间还是付款时间？ 过去，人可以凭借业务经验补齐这些信息。 如今，Agent如果不知道规则，就可能生成一条语法完全正确、业务结果却完全错误的SQL。

Redis在2026年发布的《The State of Context Engineering》报告中，对1000多名IT及AI基础设施负责人进行了调查。 结果显示，97%的受访者认为上下文对AI至关重要，但55%的组织缺乏可靠的业务语义模型，47%缺乏关联业务实体的上下文关系图谱，仅4%的组织达到报告定义的最高上下文成熟度阶段。 这意味着，企业AI面临的难题，已经不只是理解自然语言，更是如何准确理解企业的业务规则，获得经过确认的业务上下文。 不过，即使AI理解了数据，也未必能够实时获得完整的数据。

Agent还要面对第二堵墙，即数据被分散在不同的系统中。 以智能汽车座舱为例。 当车主说出“我有点累了”，AI要给出合理建议，可能需要同时获取语音指令、车内视觉信息、车速及驾驶状态。 但这些数据往往来自不同系统，更新时间不一，AI获取的可能是不同时刻的信息； 反复跨系统检索，还会增加延迟。 对于需要实时交互甚至执行操作的Agent来说，几秒钟的滞后，就可能影响判断。 Redis的同一份报告发现，54%的受访组织认为孤立的向量存储正在影响Agent的实际效果，69%认为Agent难以可靠地理解跨系统数据关系。

另有21%的组织承认，其系统经常或通常使用过时、批量同步的数据进行关键决策。 更麻烦的是，跨系统查询还会增加计算、网络和Token开销。 麦肯锡2026年的调查显示，约20%的受访者表示，AI运营成本已限制其使用。 如何减少无效检索、避免向模型反复输入冗余数据，也成了一道成本题。 然而，相比看不懂、查不全，真正让传统数据库架构面临更大冲击的，是Agent不仅要查账，还开始自己建账、改账。 过去，企业运行的是少量、庞大且相对稳定的核心业务系统，数据库由专业团队维护。

如今，Agent可以自动创建记账、库存等小应用，还会频繁建立测试环境，修改数据、验证结果，失败后推倒重来。 传统的数据库管理模式由此变得不再经济。 如果给每个应用都创建完整的物理数据库，存储和管理成本难以承受； 如果共用一套表结构，数据隔离、权限控制和个性化计算又会变得复杂。 更不用说，让数以万计的Agent直接在生产数据库上试错，还将带来巨大的安全风险。 很明显，数据库服务的对象，正在从少量稳定运行的传统应用，扩展为海量、动态、短生命周期的AI应用。

至此，Agent时代数据库的三大改造方向逐渐清晰，一是“懂业务、知口径、可追溯”，解决数据理解问题； 二是“多模合一、实时关联、一次查全”，解决数据获取问题； 三是“即用、即建、即抛”，解决动态应用的运行与管理问题。 说到底，Agent要真正进入企业核心业务，数据库就必须帮助它跨过三道门槛：算得对、看得全，还要能够安全的动手。 而这，恰恰构成了当下数据库厂商重新改造产品的主要方向。

面对Agent提出的新要求，数据库厂商正在给出不同的答案。 首先，为了让Agent“懂业务、知口径、可追溯”，厂商开始给数据库补上一层业务语义能力。 今年6月，腾讯云升级WeData统一语义层，沉淀业务术语、指标口径和规则； 10月，镜舟科技发布MIP企业级AI数据平台，将语义层引入AI分析的执行链路； OceanBase则通过DataStudio提供语义建模能力，借助DataPilot支持自然语言分析。 这些动作背后，其实是在做同一件事：给Agent准备一本企业专属的“业务词典”和“计算说明书”。

比如，什么叫销售额、退款怎么算、哪些订单不能计入统计，都提前定义好。 Agent接到任务后，不再凭字段名称猜测，而是按照企业认可的业务规则查询、计算，并让结果有据可查。 仅仅知道规则还不够，Agent还需要记住历史经验。 今年1月，火山引擎开源上下文数据库OpenViking，统一组织记忆、资源和技能； 3月，华为发布AI数据平台，提供知识检索、KV Cache加速、记忆萃取与召回等能力。 二者虽然技术路径不同，但目标都是让Agent在执行任务时，不仅能找到数据，还能获取相关知识、历史记忆与业务上下文。

解决了“看得懂”，下一步就是“看得全”。 为此，厂商开始尝试打通这些系统之间的边界。 比如，火山引擎VikingDB支持图文多模态检索与属性过滤； OceanBase湖库一体架构、镜舟MirrorData则尝试将结构化业务数据与非结构化内容的检索、关联分析衔接起来。 通俗理解，就是打通过去三个数据房间之间的墙，让一套数据底座能够同时处理交易记录、合同文档和图片等不同类型的信息。 以电商售后为例。 买家上传一张手机碎屏照片申请退货，过去，工作人员可能需要分别查询图片库、客服记录和订单系统。

如今，通过多模态检索与业务数据关联，系统有机会在同一条查询链路中，找到相似的碎屏照片、筛选相关投诉，再关联订单，查出承运快递和退款金额。 这样一来，Agent不必反复在多个系统之间搬运数据，查询链路更短，也能减少延迟和额外开销。 最后，为了让Agent可以安全地动手，技术服务商们相继推出可以安全试错的环境。 5月，腾讯云为TDSQL-C引入Branch； 6月，华为云发布的TaurusDB for PostgreSQL存算分离版支持分支管理； 8月，OceanBase进一步增加Fork能力。

通俗理解，Agent可以快速从原有数据库创建一个相互隔离的数据分支。 就像在真实账本上盖了一张“透明草稿纸”，Agent可以在自己的分支上修改、测试，失败了直接丢弃，不影响原始数据，也不必每次都完整复制一套数据库。 OceanBase披露，其相关方案在特定场景下可降低30%～50%的总体拥有成本。 这意味着，数据库开始有条件支持大量Agent按需创建、使用和释放独立的数据环境。 回过头看，不难发现，尽管各家厂商的技术路径不同，改造方向却越来越一致，即通过语义层和上下文管理，让Agent理解业务；

通过多模态融合，减少跨系统检索； 通过数据库分支，让Agent能够低成本、安全地试错。 过去，数据库主要负责保存事实，至于如何理解事实、判断对错、采取行动，是人的工作； 如今，当Agent开始接管这些工作，数据库也不得不承担起一部分原本由人完成的职责。