Google重新设计数据架构，让AI不再在企业中屡屡失败
多年来，大型企业中的数据团队与AI团队始终各自为政，仿佛来自两个截然不同的国度。前者负责构建数据仓库、数据目录和数据管道，后者则专注于部署模型、API和智能体。两个世界之间的沟通，依赖的是手动导出、断断续续的流程，以及对"对方团队会搞定"这一盲目信念的寄托。结果可想而知：AI智能体进入生产环境后便应声崩溃——因为没有人为自主机器的读取、理解和行动准备好所需的数据。
在2026年Google Cloud Next大会上，Google精准地点出了这一崩溃的根源：数据平台与AI平台之间的割裂，是自主智能体企业级部署的最大瓶颈。Google的回应是智能体数据云（Agentic Data Cloud）——对其数据架构的深度重构。这并非在现有基础上叠加一层AI，而是从根基处重新设计，让智能体成为企业数据的一等公民。
这一雄心壮志的高度绝非一般意义上的迭代升级。我们谈论的不是几个新连接器，也不是几个支持自然语言的仪表板，而是一次结构性的重新设计——它迫使所有财富500强企业重新思考：在数据分散于AWS、Azure和Google Cloud之间的现实背景下，究竟该如何治理、提供和变现自己已经拥有的信息。
管理层宁愿视而不见的诊断
有一个数据令人不安：根据此次发布所附的研究报告，约70%的企业是在部署智能体之后才发现其数据基础设施存在缺陷，而非之前。这不是技术问题，而是一个披着技术外衣的领导力问题。
碎片化的、缺乏治理的、被困在不同云孤岛中的数据，并非一夜之间横空出世。它们是多年来仓促决策、企业并购整合不当，以及一种极为人性化的组织惯性所积累的结果——那就是推迟那场关于数据架构现状的艰难对话，理由是"业务还在正常运转"。直到有一天，它不再正常运转。
Google所呈现的架构由六个相互关联的组件构成，它们并非彼此独立，而是形成一套具有序列逻辑的系统。在底层，多云数据湖仓（Data Lakehouse Multinube）基于开放格式Apache Iceberg构建，允许BigQuery直接查询托管在AWS S3和Azure ADLS上的数据，无需移动或复制，从根本上消除了数据出口费用以及副本之间的一致性风险。在此基础上运行的是Apache Spark Lightning引擎——一个以C++实现的向量化执行层，其性能最高可达传统Spark的4.9倍。数据不仅可以被访问，还能以足够快的速度被处理，使智能体在连续循环中生成、执行和修正Spark代码成为可能，同时不会导致成本失控。
在这套执行基础设施之上，是上下文智能层：知识目录（Knowledge Catalog），即2026年4月10日发布的Dataplex Universal Catalog的演进版本。这一组件应当引起企业架构师的高度关注。该目录无需数据团队手动为数据资产建档。它会自动检查查询日志、分析表结构、解析Looker等工具的语义模型，并从非结构化文件中提取实体间的关联关系。最终输出的是一个动态的、自动维护的知识图谱，能够回答每个智能体在采取行动前都必须解答的问题：存在哪些数据？这些数据的确切含义是什么？这些数据是否可信？
当存储不再只是被动容器
在数据运营几何形态上带来最根本性变革的，是智能存储（Intelligent Storage）功能，目前处于预览阶段。过去，一个文件上传到Google Cloud Storage的存储桶后，在有人决定处理它之前始终处于静默状态。而有了这项功能，文件一旦进入存储桶，系统便会自动为其打标签、生成嵌入向量、提取相关实体，并将其关联到知识目录。PDF文档、合同、支持工单、音频录音——一切都在无需工程师干预的情况下变成可被搜索的数据资产。
对于那些一直在推迟非结构化数据准备项目的管理者来说——那些"需要六个月时间"来完成提取、OCR、索引和编目的项目——这一功能从根本上重构了时间与成本的等式，使其再也难以找到轻松推迟的理由。曾经需要专项执行赞助、独立预算和不确定交付日期的大型项目，如今变成了存储策略的自动结果。
深度研究智能体（Deep Research Agent）基于Gemini 3.1 Pro构建，完美诠释了整套基础设施的终极应用场景。它将知识目录和数据湖仓中的内部数据源与互联网上的公开来源相结合，生成结构化的研究计划，并在数分钟内交付附有可验证引用的分析报告。在竞争情报、生命科学或金融服务等领域，过去需要分析师耗费一到三周才能完成的工作，如今成为起点，而非终点。
数据智能体套件（Data Agents Kit）从开发者侧完成了整幅图景的拼接。它提供预配置的MCP工具和三个专用智能体：其一将自然语言指令转化为托管数据管道，并在BigQuery、dbt、Spark或Airflow之间自动选型；其二自动化数据科学模型的完整生命周期；其三专注于基础设施可观测性。模型上下文协议（MCP）充当互操作层，允许任何供应商的智能体——无论是Gemini、Claude还是自研模型——无需定制连接器即可访问数据资产。
多云不再是一句抱怨，而是一个架构决策
财富500强中没有任何一家企业是完全跑在Google Cloud上的。SAP、Salesforce、Workday和Oracle等系统因历史原因、合同约束和运营需要分散在AWS和Azure之间，这不是任何一位CTO发一份备忘录就能解决的问题。多年来，多云环境一直是企业拒绝推进大规模AI计划的惯用借口："我们首先需要整合数据。"
多云数据湖仓以具体的技术细节拆解了这一论点。通过Iceberg REST目录、多云互联互通以及智能缓存层，BigQuery可以以接近原生Google Cloud数据的延迟和成本，查询AWS S3和Azure ADLS中的数据。一名采购智能体可以在单次查询中，同时整合存储在S3中的合同数据、Azure中的库存数据和BigQuery中的交易记录，所有这些均在统一的Iceberg目录下完成，无需任何工程团队管理跨云ETL流程。
这对集成架构师而言具有战略层面的深远意义。对话的主题不再是"我们如何将所有数据迁移到单一云上"，而变成了"我们如何在现有数据分布的基础上治理一个统一的目录"。这完全是两种不同的对话。前者在大多数成熟组织中具有令人望而却步的政治和财务成本，后者则可以在不打破与其他供应商现有合同的前提下付诸执行。
从整体来看，Google所提出的是一种范式转变，其组织层面的影响远不止于技术架构本身。MCP作为智能体治理层，需要以当前管理API网关同等的严格纪律来维护：版本控制、身份验证、监控以及使用限额。知识目录不再只是一个文档化项目，而成为实时运营的核心依赖，这意味着需要服务级别协议、持续维护，以及一套数据团队尚未设计好的运营模型。
一个组织的文化，并不是会议室墙上的装裱标语，也不是CEO在年度峰会上的慷慨陈词。它是所有领导者在推迟比决断更安逸、委托比担当更安全、将一切归咎于技术债务比承认现实更容易的时刻，所积累下来的全部决策的总和。而数据架构，恰恰以外科手术般的精准，映照出权力的架构、恐惧的架构，以及管理层从未鼓起勇气去进行的那些对话的架构。
