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数据基础设施的定义。而不再只是硅谷已有标准的“跟随者”。