如果把实用主义做到极致，数据库和AI的结合可能就不再是纸上谈兵，而是真正能落地的解决方案。这是最近对阿里云新推出的AI原生数据库服务——AIDBS——进行了解后，最深的感受。 Gartner最近的判断其实挺扎心的：“2026年，超过60%的AI项目，会被企业亲手放弃。”问题出在哪儿？很多时候不在模型本身，而是在数据上——接不进来、处理不充分、语义对不上。某种意义上，这就是过去两年企业交的最贵学费：原来数据库的重要性，远超我们的预期。 过去，很多企业忙着堆叠所谓的“高质量数据库”，做接入、清洗、治理。这件事在半年前或许还行得通，但在今天，已经很难撑起AI应用的实际需求了。 一个关键的变化是：数据库的“使用者”正在发生根本性转变。Databricks收购Neon后披露的数据挺有说服力——其平台上大约80%的数据库实例，是由Agent自动创建的。这意味着，数据库正在从服务于“传统应用”，转向服务于“Agent”。而Agent和传统应用不一样，它有自主规划、高频访问、持续读写这些特征。这种工作模式要求数据库不能再是被动存储，而是要主动去适配Agent的行为，在真实的业务场景里释放数据价值。 “适配Agent”正在成为数据库的底层设计原则，这也意味着产品形态需要被重写。最近阿里云在「飞天发布时刻」栏目中推出的AI原生数据库服务——我们就叫它AIDBS——正是这一趋势下的产物。它把自己定位为企业级Data-Centric Agent的一站式开发与服务平台，目的是让数据能被Agent理解、编排、流动和监管。 它的架构预设了一个现实：企业数据长期分布在多云、混合云和本地环境中。同时，它也知道业务语义很难人工标注，DBA和治理资源长期不足。所以它试图把这些复杂性收敛到平台里。简单说，这是一款从一线真实需求出发的产品，强调落地和可用性，把实用主义推向了极致。 **接入只是第一步，让Agent读懂数据才是关键** 现在很少有企业是从零开始建数据库的。现实情况是，数据早就分散在不同环境里了——有多云部署的、有自建的，还有大量分布在多模态载体中的。对任何企业来说，要求“先迁移、再使用”的方案，都意味着高成本和高风险。 针对这个现实，阿里云给出的第一个答案，是“横向开放”。具体来说，AIDBS提供了一种全域资产管理模式：以阿里云为中心，打通企业自建库和其他云环境。目前已经支持40多种跨云、多模态数据源。换句话说，数据不需要“先搬家”，就能被统一接入和管理。 第二个答案是“纵向打深”。企业真正高价值的数据，往往大量存在于非结构化、多模态的形态里，比如钉钉、网盘、OSS、SharePoint，甚至网页链接。AIDBS通过统一的元数据管理体系（OneMeta），对全域、全模态数据进行自动采集和解析。不管是文档、图片还是音视频，它都能匹配合适的模型进行语义提取，并进一步结构化沉淀，形成企业级的统一数据语义底座。 这样一来，数据库的边界被打开了。但仅有“可接入”和“可解析”还不够。传统数据库其实并不算“懂”数据——把数据表原样丢给大模型，九成以上根本用不起来。表太多、字段太多、语义太多，Agent根本不知道该用哪张表，也不知道语义之间怎么关联。所以阿里云在语义层做了两项关键设计。 一是构建OneMeta业务元数据层，把最底层的物理元数据翻译成业务语义，覆盖对象、指标、口径，甚至行业知识。对Agent来说，它看到的不是“表”和“字段”，而是“华东区域季度销售额”“近30天复购率”这些可以直接理解的业务表达。 二是引入Agentic Native的自动化数据治理机制。从企业日常产生的SQL、代码、命名规范和样本数据中持续提取知识，让语义以“自下而上”的方式不断沉淀和更新。基于此，AIDBS构建了AI Ready服务层，通过Skill、MCP、API等方式，让数据可被Agent直接调用，解决企业Agent“找不到、用不了、用不准”数据的问题，同时降低维护成本。 这个能力已经在实际业务中得到验证。头部茶饮品牌古茗就是个典型例子。这家全国有上万家门店的茶饮企业，过去也建过静态元数据平台，但用了半年就没人碰了——因为那平台只“展示信息”，不“解决问题”。接入Meta Agent后，古茗换了思路：不让人去查它，而是让它主动出现在研发流程里。研发写SQL时，Meta Agent自动提示涉及哪些表、字段口径、有没有更合适的索引和同语义的现成视图；业务同学在BI平台拖字段时，自动告知字段的业务含义、最近谁改过、近30天取值分布，避免取错口径；做DDL审批时，自动计算血缘、影响面和风险等级，DBA不再需要逐条人工评估。这套机制下来，业务系统的语义准确率大幅提升，DDL审批工作量降了30%到40%。 **真正的实用主义，是让每种起点都能跑通** 有了具备业务语义的数据底座，下一步的关键就是如何高效开发应用。企业里的Agent需求多样且持续变化，单一开发路径很难适应复杂业务，也会限制数据价值的释放。 阿里云从一线经验中提炼出企业最常见的三种开发方式，对应不同起点的需求。 第一类是已经构建了大量Agent的企业。比如Dify这类可视化Agent工作流编排平台，去年在开发者圈子里很火，不少企业已经用它沉淀了丰富的Agent和工作流资产。但随着更灵活的Skill时代到来，一个问题随之出现：这些存量资产是否需要推倒重来？AIDBS的回答是：不需要。一方面，它可以托管Dify、RAGFlow等开发底座，为既有Agent补齐数据能力，让它们快速接入企业数据、跑通真实业务；另一方面，它还能把已有Agent转化为可复用的Skill。更厉害的是，它能读懂完整工作流，并自动生成对应Skill的使用方式和交互逻辑。比如一个“简历匹配”Skill，只需输入JD就能触发匹配，而且在Dify里能清晰看到调用过程和结果。 第二类是拥有数据和系统，但不确定该构建什么Agent的企业。这类企业经常的状态是：要么缺乏应用方向，要么得业务、技术和管理团队反复讨论才能确定Agent类型，然后再走预算、立项、交付流程。在AI时代，这个模式明显落后了。AI不仅能够执行任务，更能判断“哪些Agent值得构建”。AIDBS内置了智能化Agent开发功能——Proactive Agent。当AIDBS完成对企业底层资产的梳理后，平台实际上已经具备了业务轮廓的整体认知。在此基础上，AI可以主动激发创意——结合行业趋势洞察，参考同类企业实践，推荐匹配的应用场景。一旦选定方向，15分钟内就能通过Vibe Coding生成方案并完成验证。 第三类是坚持自建的企业。这类企业通常有成熟的技术团队和明确的架构偏好，不一定要用平台化的完整开发流程，更关注如何在自建体系中高效、灵活地使用企业数据。针对这个需求，AIDBS从两大维度提供支撑。一是专业能力，把阿里云数据库团队沉淀了十几年、经过验证的企业级能力（如安全控制、数据分析、资产管理、运维等）封装为100多个Data Skills，开发者直接开箱即用，能省去大量数据侧的开发工作。二是通道，面向Agent访问数据，AIDBS提供了Agent数据网关（Data Gateway），把身份、权限、操作管控、敏感数据脱敏和智能路由全部集成到这一层网关上，覆盖阿里云全系数据库产品和各类数据源。网关会给每个Agent颁发一个专属身份，Agent凭这个身份、在自己的权限范围内访问正确的数据，敏感字段自动脱敏，全流程可审计、可追溯。有了这两条，本地不需要囤一堆Skill，能力过网关即取即用，访问又始终可信可控——企业里每个人、每个Agent都能放心地把数据用起来。 这三种开发范式——定制化、智能化和AI原生——覆盖了从“已建Agent”到“不知道建什么”再到“完全自建”的企业常见起点。从中能看出一以贯之的理念：企业不用去适配平台，而是平台主动去适配企业。 **让Agent主动干活，深度参与企业业务** 数据接进来了，Agent也搭好了，但更现实的问题是：企业投入大量成本建的数据库，真的把价值释放出来了吗？答案往往是否定的。这里面有经验的缺失——不是每家企业都养得起资深的数据分析和数据科学团队；也有能力的错配——数据大多还停在“被动等查询”的状态，很少主动参与到业务里去。 鉴于企业自建应用周期长、门槛高，阿里云把成熟的数据应用能力产品化，直接交付给企业使用。这正是AIDBS智能应用层——Data Agent系列的出发点：提供一组开箱即用的垂类Agent，覆盖数据获取、分析和预测等核心场景。 在数据获取环节，DataBridge Agent可以从网页及多源系统中抓取数据，并自动整理为结构化格式，适用于企业知识库等典型场景。 在数据洞察环节，Analytics Agent能够理解业务目标，把复杂任务拆解为多步流程，逐步执行与校验；过程中沉淀的分析资产，还可以在企业内部共享复用，形成持续积累。 在预测与决策环节，Forecast Agent专注于解决不确定性问题。比如某车企计划推出一款投入巨大的新车型，目标市场是否买单难以判断。通过构建多情景模拟，把业务假设与市场数据结合起来推演，可以提前识别风险、评估收益。决策周期越长、试错成本越高的场景，它的价值就越明显。 这些能力不是纸上谈兵，已经在实际业务中得到验证。一位自媒体创业者Jack的“一人公司（OPC）”就是典型案例。他先用DataBridge Agent持续抓取公众号、雪球、股吧等平台的热点信息，然后让分析型Agent完成情绪标注和板块归类，最后用可视化方式呈现市场情绪变化趋势。在直播选品环节，他把带货指标输入系统，由Agent自动完成特征工程并计算“爆款评分”，筛选出如冻干水果、低卡燕麦棒等Top10商品；再通过DataBridge Agent抓取用户评价进行交叉验证，结果沉淀到数据库以备复用。在预测阶段，他用Forecast Agent做“市场情绪预演”，基于粉丝画像构建“虚拟粉丝Agent”，提前模拟一条内容、一个决策可能引发的群体态度。从信息获取、加工处理到辅助决策——过去需要小团队协同完成的工作，现在一个人配合一组Agent就能闭环。 类似实践的用户数和服务规模正在不断提升：目前大约10%的数据库实例通过该平台对外提供服务，Data Agent系列及其开发平台用户已超过1万，超过1000家企业已经启动或完成了AI数据能力底座升级。 归根结底，Agent能否深入业务、重构流程，取决于行业Know-How的沉淀与表达。阿里云所做的，正是把在数据库领域多年积累的经验，封装进一系列Data Agent产品中交付给企业。如果说Data Agent的目标是让数据在业务侧“主动起来”，那么在运维与安全侧，阿里云还在推动数据库走向自主管理与持续自治。 **解放人力，让数据库学会自己管自己** 过去，总有一群人围着数据库转。DBA、运维、安全团队每天盯着告警、慢SQL、权限和容量。一旦报警，就得连跳板机、查日志、逐步排查。这些工作重复、琐碎、高压，还缺乏创造性。系统稳定时没人管，一出问题，压力全落到数据库团队身上。 AIDBS正在试图改变这个局面。在这套体系里，数据库不再只是被Agent使用，也开始由Agent管理。以DAS Agent（数据库运维）为代表，它的目标是让数据库具备“主动发现问题、分析原因、给出方案并闭环”的能力。更进一步，DAS Agent与Meta Agent结合后，运维不再局限于CPU、内存、慢SQL这些指标，还能理解其背后的业务含义。比如，一张表对应哪个系统？某条SQL影响订单链路还是报表查询？问题持续会带来多大业务影响？ 前面提到的古茗实践，把这种组合拳的优势体现得很具体。过去，告警处理完全依赖人工响应，信息和钉钉通知不断堆积。古茗科技集团运维负责人刘星光说，高峰时一天上百条，信息疲劳让关键问题反而更难及时识别。大促等关键时刻尤其突出。比如一次活动前，订单系统CPU突然飙升，DBA从登录到定位，即便经验丰富也得十几到二十分钟，这段时间足以引发系统波动。但接入DAS Agent后，情况变了：告警不再直接推给人工，而是先由Agent处理。系统自动拉取慢日志，对比历史基线，识别异常模式；判断是否由促销新增SQL引发；评估影响范围，并给出可执行的优化建议。原本需要十几分钟的排查，现在通常几分钟就能定位问题。更重要的是，判断不仅更快，准确性也接近资深DBA，部分场景下甚至更客观。 这种变化带来的不只是“排障更快”。研发与数据库团队的协作方式被重塑了。过去DBA是上线前的最后关卡；现在研发在编写SQL时，Meta Agent就能提供字段口径、索引建议和风险提示，上线后由DAS Agent持续监控和分析。研发更自主了，DBA也不再是流程瓶颈。专家经验开始沉淀为组织资产——过去经验依赖个人，现在每次问题处理都会被记录并回流到知识库，逐步形成可复用的能力。成本与决策也更透明了：Meta Agent识别数据资产使用情况，DAS Agent分析实例负载与性能变化，两者结合后可以评估资源利用效率，识别紧张与闲置资源，以及需要优化或归档的数据表。 AIDBS的自治能力还延伸到了安全侧。当企业里有成千上万个Agent同时访问数据时，传统的人工审批已经撑不住了。为此，AIDBS的Agent数据网关（Data Gateway）对Agent数据访问进行实时治理：校验身份与权限、解析访问意图、匹配安全的执行方式。持续自治能力让数据库从人工驱动转向系统自驱，重复且高压的事务由系统承担，让人能专注于更有价值的工作，同时系统稳定性和可靠性也进一步提升。这，才是引入Agent的真正价值。 **结语** 回到开头Gartner的判断：绊倒企业的不是模型，而是数据库。关键在于，当数据库的使用者从人扩展到Agent，数据库需要完成怎样的演进。 阿里云通过AIDBS给出了一个经过业务验证的答案。首先是“接入”——连接40多款跨云、多模态数据源，企业无需迁移就能实现数据接入与流动。其次是“对齐”——OneMeta把物理元数据转化为业务语义，Agent Native把治理方式从集中规划转向持续自治。最后是“用好”——三种开发范式覆盖不同起点；内置的Data Agent家族让数据参与业务，实现数据库持续自治。 这些能力背后，真正指向的是同一件事：把原本由企业承担的复杂性收敛到平台侧，包括跨云迁移、集中治理的效率问题，以及运维与安全带来的持续成本。当行业还在争论“AI原生”到底该怎么定义的时候，阿里云其实已经给出了更现实的答案：降低Agent的使用门槛，减少企业侧的负担，让数据库从“存储数据”转向“参与业务执行”。把实用主义做到极致，或许才是Agent Native最本质、也最难被模仿的地方。