引言
“2026 年，超过 60％的 AI 项目，会被企业亲手放弃。”
这是 Gartner 的最新判断，问题往往不在模型，而在数据：数据接不进来，处理不充分，语义也无法对齐。
某种意义上，这也是过去两年企业付出的最贵学费：数据库的重要性，远超原本预期。
过去，许多企业忙于堆叠所谓“高质量数据库”，实现数据接入、清洗与治理。这在半年前，或许仍然奏效；但在今天，已难以支撑 AI 应用的实际需求。
变化的关键在于数据库的“使用者”正在发生转变。Databricks 在收购 Neon 后披露，其平台上约 80％的数据库实例由 Agent 自动创建。这意味着，数据库正从服务“传统应用”，转向服务“Agent”。
与传统应用不同，Agent 具备自主规划、高频访问、持续读写等特征。这种工作模式要求数据库不能只是被动存储，而是要主动适配 Agent 行为，在真实业务场景中释放数据价值。
"适配 Agent"将成为数据库的底层设计原则，这也意味着，产品形态需要被重写。日前，阿里云在「飞天发布时刻」栏目中推出 AI 原生数据库服务——以下简称 AIDBS。
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“找不到、用不了、用不准”数据的问题，并降低维护成本。
这一能力已经在实际业务中得到验证。
头部茶饮品牌古茗采用 AIDBS 中 Meta Agent（知识管理智能体）的实践，就是个典型注脚。这家在全国开着上万家门店的茶饮企业，过去也建过静态元数据平台，可用了半年就没人碰了——它只“展示信息”，不“解决问题”。
接入 Meta Agent 后，古茗换了思路：不让人去查它，而让它主动出现在研发流程里。研发写 SQL 时，Meta Agent 自动提示涉及哪些表、字段口径、有没有更合适的索引和同语义的现成视图；业务同学在 BI 平台拖字段时，自动告知字段的业务含义、最近谁改过、近 30 天取值分布，避免取错口径；做 DDL 审批时，自动算出血缘、影响面和风险等级，DBA 不再需要逐条人工评估。
得益于此，古茗业务系统的语义准确率大幅提升，DDL 审批的工作量下降了 30%-40%。这也表明，企业可在短时间内将数据资产推进至 AI Native 状态。
二、真正的实用主义，是让每种起点都能跑通
在具备业务语义的数据底座后，关键在于如何高效开发应用。
企业中的 Agent 需求多样且持续变化，单一开发路径难以适配复杂业务，也会限制数据价值的释放。
凭借深耕一线的经验，阿里云提炼出企业最常见的三类开发方式，对应不同起点与需求。
第一类：是已经构建了大量 Agent 的企业。
以去年在开发者圈层迅速走红的 Dify 为例，这类可视化 Agent 工作流编排平台（与 LangGraph 类似）已在不少企业中沉淀了丰富的 Agent 与工作流资产。
但随着更灵活的 Skill 时代到来，一个现实问题随之出现：这些存量资产是否需要推倒重来？AIDBS 给出的答案是：不需要。
一方面，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”到“不知道建什么”再到“完全自建“的企业常见起点。从中不难看出 AIDBS 一以贯之的理念：企业不用去适配平台，而是平台主动去适配企业。
三、让 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 最本质、也最难被模仿的地方。
