Agent,“重做”数据库

产业家·2026年11月06日 19:20
数据库不但要存,还要能“懂”。

当数据库的主要使用者从人逐渐扩展到Agent,沿用了数十年的数据库架构,正在发生重构。

“公司的活动总预算是多少?”对于一名熟悉业务的财务人员来说,这或许是个再简单不过的问题。但在某数据库厂商测试的企业级Agent场景中,AI给出的答案与真实情况相差了近15倍。

面对这句简单的自然语言指令,Agent自主检索企业数据库,在众多包含“金额”字段的列中机械求和,最终得出一个高达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

为什么过去已经服务企业几十年的数据库系统,到了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开始接管这些工作,数据库也不得不承担起一部分原本由人完成的职责。

数据库引擎切换:从AI回归业务本身

从语义层、多模检索到数据库Fork,厂商正在逐步补齐Agent所需的能力。

然而,当这些技术真正进入企业,一些产品演示中不明显的问题,反而开始暴露。

首先,是企业已经背负的技术债。

过去两年,为推进AI落地,不少企业陆续建设了向量数据库、知识库、数据湖和各类Agent平台。不同部门选择不同厂商,重复部署、接口不统一、权限分散等问题随之出现。

Salesforce旗下MuleSoft发布的《2026年连接性基准报告》显示,受访企业平均管理957个应用系统,但真正实现互联的仅占27%;即便是Agent转型较快的企业,这一比例也只有32%。更值得警惕的是,50%的AI Agent仍然孤立运行。

这意味着,即便腾讯、华为、火山、OceanBase、镜舟科技等厂商提供了更统一的数据能力,企业也不可能轻易推倒重来。

更现实的路径,是保留核心系统,通过统一查询、开放接口、增量迁移等方式逐步整合。如此一来,数据库厂商不仅要比拼产品能力,还要解决复杂的系统兼容与交付问题。谁能降低企业的改造成本,谁才更有机会拿下订单。

但即便系统打通了,Agent也未必真正懂业务。

因为数据库可以内置语义层,企业几十年积累的业务经验,却不会自动变成标准规则。比如,一家制造企业的老师傅判断设备故障,可能需要结合温度、振动、设备年限和维修经验。有些标准写在操作手册里,有些则只存在于个人经验中。

要让Agent具备类似的判断能力,就必须梳理这些隐性知识,明确适用条件、例外情况和判断依据,再转化为可执行、可校验的规则。更复杂的是,不同部门对同一指标可能有不同定义,业务变化后,规则也需要持续更新。

这已经不是简单的技术开发,更是一项需要业务专家、数据工程师和IT团队共同参与的知识工程。

爱分析2026年央国企Agent实践报告中,就提到一家世界500强基础设施央企。该企业此前已建设知识门户、知识地图等系统,积累近万份高质量工程技术文档。但引入Agent时,仍需重新梳理知识组织、检索机制、专业术语和安全要求,最终选择在原有系统上叠加AI能力,而非推倒重建。对于一家企业尚且如此,如果将Agent推广到几十个部门、数百项业务,规则维护、版本管理和跨部门协调的工作量只会更大。

IDC今年9月的研究也指出,Agent进入核心业务流程,需要业务专家、IT及部署团队长期参与数据治理、知识建设和流程重构,背后隐藏着可观的人力投入。

这意味着,数据库厂商未来不仅要交付软件,还可能需要参与业务知识治理。如何用标准化产品承接大量非标准化需求,将成为新的考验。

而当企业终于完成系统改造、理清业务规则,还有第三道难关,那就是如何管住成千上万个同时运行的Agent。

过去,数据库主要应对相对可预测的业务请求。如今,大量Agent可能同时发起高频查询、创建测试分支、修改数据,甚至相互调用。一旦缺乏约束,不仅可能造成算力与成本失控,还可能引发越权访问、数据误操作等风险。

尤其在金融、医疗等高敏感场景,数据库不仅需要控制访问权限,还要配合建立资源配额、操作审计、异常熔断等机制,确保Agent的每一步操作可控、可追溯。

回头来看,Agent给数据库带来的挑战,已经超出了传统技术升级的范畴。

存量系统改造,考验架构兼容与工程交付;业务知识治理,考验产品能力与行业经验的结合;多Agent运行,则考验权限管理、资源调度和持续运营能力。

因此,数据库行业下一轮竞争,不只是比谁先推出多模表、语义层或毫秒级Fork,更要比谁能以更低的成本、更可控的方式,把这些技术真正带进企业核心业务。

而这,也正在改变数据库行业未来的产品形态、竞争边界与商业价值。

下一代数据库,谁来定义?

当数据库开始承担业务理解、上下文管理和Agent运行保障等职责,一个更深层的变化正在发生,即数据库行业原有的产品边界与价值分工,正在被重新划定。

这种变化,已经体现在数据库的产品形态上。

过去,交易型数据库、分析型数仓、数据湖、向量库、全文搜索引擎乃至BI平台,各有分工。如今,随着Agent对数据理解、实时分析和自主执行提出更高要求,这些原本独立的能力正在加速融合。

未来,数据库可能逐步形成“底层湖库一体多模引擎、中间层语义与上下文管理、上层Agent运行与评测环境”的三层架构。传统数据库与AI数据平台之间的界限,也将越来越模糊。

而比产品融合更值得关注的,是数据库自身的角色变化。

过去,数据库主要负责存储和查询数据,至于如何理解业务、判断对错,更多依赖人来完成。如今,数据库开始管理企业的业务规则、指标口径、历史经验与操作流程,为Agent提供可靠的决策依据。

换言之,数据库正在从被动存取数据的“仓库”,走向能够组织和管理企业上下文的“业务大脑”(Context Engine)。Agent能否真正理解一家企业,很大程度上取决于底层数据系统能否提供准确、完整的业务上下文。

这种角色变化,也在推动数据库运行模式的革新。随着多Agent协同、自主试错成为常态,传统单体大库难以满足海量、动态的应用需求。通过毫秒级Fork、按需分配资源、闲时自动释放,轻量化、弹性化的数据库服务有望成为新的发展方向。

那么,这场变化,对AI落地产业究竟意味着什么?

站在当下来看,数据库通过多模合一帮企业省去了跨库折腾与Token浪费,通过语义层锁死了业务口径的可追溯性,通过秒级沙箱砍掉了30%~50%的试错成本。这相当于给狂奔的AI铺设了安全的铁轨和红绿灯,让Agent真正敢于走进银行风控、医疗健康、汽车座舱和大型零售经营分析等核心生产系统。

除此之外,其正在重构ToB软件的交付链路与商业生态。

过去企业做一个AI应用,需要自己找集成商把数据库、网盘、向量库、知识库、BI报表和智能体框架一点点拼起来,链路极长且脆弱。如今,数据库厂商往上走,直接把繁琐的“系统集成工程”变成了开箱即用的“底座标准能力”。

更重要的是,也让中国数据库厂商在这场尚未定型的产业竞争中,迎来了新的机会。

回顾移动互联网时代,“双十一”等海量交易、高并发场景,推动了中国分布式数据库的发展。如今,Agent对实时处理、多模态融合和高并发运行提出了新的要求,也为中国厂商积累的技术能力提供了新的用武之地。

与部分海外厂商从数据湖、分析平台向实时交易延伸的路径不同,OceanBase、腾讯云、火山引擎等中国厂商,依托大规模交易、实时分析和互联网业务场景的长期积累,正在向AI原生数据底座拓展。

不同的技术路线正在走向同一个方向,也说明全球AI数据基础设施的竞争格局尚未定型。这个过程中,中国厂商也有机会凭借真实业务场景中的技术积累,参与下一代AI数据基础设施的定义。而不再只是硅谷已有标准的“跟随者”。

本文来自微信公众号 “产业家”(ID:chanyejiawang),作者:产业媒体,36氪经授权发布。

+1
1

好文章,需要你的鼓励

参与评论
评论千万条,友善第一条
后参与讨论
提交评论0/1000

36氪AI测评

选靠谱AI,看真实评测
查看
36氪AI测评官方交流社区
加入

36氪项目推荐

咨询项目审核和入驻
联系
36氪项目推荐订阅号
关注
36氪APP让一部分人先看到未来
36氪
鲸准
氪空间

推送和解读前沿、有料的科技创投资讯

一级市场金融信息和系统服务提供商

聚焦全球优秀创业者,项目融资率接近97%,领跑行业