当数据库的两端，都不再是人

引言 “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)，把身份、权限、操作管控、敏感数据脱敏和智能路由全部集成到这一层网关上