Fivetran+dbt合并完成以Agents Schema定义AI代理数据上下文标准；阿里云Dragonwell Native Acceleration以AI驱动的JFR分析自动发现Spark 10倍性能优化；腾讯云三层Agent-Ready数据平台将DataBuddy智能体、WeData统一语义层与AI原生底座一体化

第十八期追踪到DataInfra领域三条重要动态：6月1日Fivetran与dbt Labs完成全股票合并——摄取（Fivetran确保数据完整、持续同步、可靠）与转换（dbt确保数据经定义、测试、治理的业务逻辑结构化）两大支柱合二为一，服务10万+全球数据团队，合并即日发布五项联合创新——dbt Core v2.0以Apache 2.0开源Fusion引擎的Rust运行时内核（这是dbt有史以来最大规模的一次Apache 2.0代码释放），10,000模型项目解析加速30倍，新Parquet制品替代大型JSON文件可被DuckDB直接查询，ADBC+Arrow生态简化适配器构建；dbt State作为管道缓存层仅构建变更内容，降低基础设施成本30%以上；dbt Wizard基于完整项目上下文（血缘/测试/契约/指标）自主编写重构调试SQL；Agents Schema以纯SQL表定义仓库或数据湖中的单一模式为AI代理共享上下文层——指标定义、语义模型、dbt血缘、业务文档存储在可被任何SQL代理直接查询的表中，通过GitHub Actions或元数据连接器从现有系统发布，兼容任何仓库/湖/摄取工具——此前AI代理获取结构化数据上下文没有开放标准，Agents Schema填补了这一空白，让”AI代理理解业务数据含义”从每个厂商各自实现走向基于开放标准的统一上下文层；阿里云6月5日发布Dragonwell Native Acceleration AI博客——AI驱动的性能分析系统针对Java/Scala应用的性能瓶颈自动识别，三个专用AI代理（逃逸分析代理判断对象是否逃逸函数作用域、异常分析代理判断异常是否在不可达路径上、优化机会分析代理发现人类容易忽视的优化点）与传统工具（JFR热点聚合工具聚合2,254个JFR文件提取Top N热点函数、AST函数查询工具精确返回目标函数完整定义和上下文）深度协作，在Apache Spark 4.0 TPC-DS验证中3小时21分钟分析400个热点函数，成功检测34个具有原生加速潜力的函数，UTF8String.numChars单函数提升1063%（10倍以上），BytesToBytesMap.safeLookup单函数提升59.74%，端到端Dragonwell 11 vs OpenJDK 11提升9.69%（AI发现优化贡献约4%）——此前性能优化依赖人看火焰图+代码审查的慢循环，AI+传统工具协作将瓶颈发现从”人工排查”走向”自动识别+JDK原生加速执行”；腾讯云6月5日在AI产业应用大会发布三层Agent-Ready数据平台——智能入口层DataBuddy（生产级数据智能体，自然语言驱动端到端完成数据建模/ETL/归因分析/报告生成，内置数据工程/数据分析/数据治理三大专家，5月内测以来超3000家企业申请，重复开发量降低80%，超90%常见故障可自动诊断修复，身份权限+执行隔离+Agent Guardrail+全链路审计纵深防护），统一控制面WeData（Agent-Native一体化数据智能平台，统一元数据/数据语义/编排/权限打通数据开发/机器学习/AI应用全流程，研发效率提升50%+，统一语义层让Agent”不仅查到更能理解”，细粒度权限人/Agent同一套审计链路），AI原生底座（TCLake+Spark+Ray+向量数据库统一存储计算，Serverless弹性底座多引擎协同）——此前数据平台为”人操作工具”设计，Agent-Ready平台让人和Agent基于同一套数据体系协同工作——三条动态共同指向AI与DataInfra从三个方向深度融合：数据转换层成为代理感知（Agents Schema定义AI代理如何消费结构化业务上下文），AI被应用于优化数据基础设施自身（Dragonwell以AI发现JDK级性能优化），数据平台为代理原生重构（腾讯云三层架构将”人使用工具”范式迁移为”Agent完成工作”范式）。

Fivetran+dbt合并完成：从摄取到转换的AI代理数据基础设施与Agents Schema开放标准

事件概述

6月1日，Fivetran与dbt Labs完成全股票合并，两家DataInfra领域最具定义性的公司合二为一——Fivetran是自动化数据摄取的领导者（确保数据完整、持续同步、可靠地从数百个源到达数据仓库），dbt Labs是数据转换的标准制定者（确保数据经定义、测试、治理的业务逻辑结构化）。合并后公司由Fivetran联合创始人George Fraser任CEO、dbt Labs联合创始人Tristan Handy任President，服务全球10万+数据团队，客户包括OpenAI、Zendesk、Coupa、HubSpot等。合并完成即日发布五项联合创新：dbt Core v2.0（alpha）、dbt State（preview）、dbt Wizard（beta）、Agents Schema（开源标准）、AI Connector Builder。

此次合并的技术逻辑清晰：AI代理正在成为企业数据的主要消费者，它们持续运行、并行操作、以机器速度工作，且许多组织希望大部分代理自主运行无需人工干预。这要求数据不仅要可靠、新鲜、治理完善，还要在语义上可被AI代理理解。Fivetran解决”数据如何到达”，dbt解决”数据如何被定义和信任”，两者组合构成AI代理的数据基础设施层。

技术解析

• dbt Core v2.0——Fusion引擎Rust运行时开源：dbt Core v2.0以Apache 2.0许可开源了Fusion引擎的Rust运行时内核——这是dbt有史以来最大规模的一次Apache 2.0代码释放。此前Fusion引擎以ELv2许可发布，与dbt Core（Python+Jinja，Apache 2.0）形成双引擎分叉。v2.0将两者统一到同一Rust基础：dbt Core v2.0包含核心语言特性和仓库适配器（Apache 2.0），Fusion在此基础上增加SQL理解、列级血缘、即时反馈和平台连接工作流（免费+付费）。性能提升：10,000模型项目解析加速30倍；新Parquet制品替代大型JSON文件，可被DuckDB或AI代理直接查询；ADBC+Arrow生态简化新适配器构建。v2.0的核心意义：结束dbt的”双引擎时代”，所有创新投资集中在一个引擎上。
• dbt State——管道缓存层：dbt State作为数据管道的缓存层，仅构建变更内容、跳过未变更部分。相比此前state-aware orchestration的build_after（比较模型上次成功执行时间），dbt State的lag_tolerance比较底层数据的新鲜度——当上游数据未变化时自动跳过下游模型构建，即使代码有微小修改（如添加注释）也不触发重构建（可检测忽略不影响转换逻辑的文件修改）。帮助公司降低基础设施成本30%以上。跨引擎、跨环境工作：dbt Core、Fusion、dbt平台及外部编排器均支持。
• dbt Wizard——代理式SQL开发：基于完整dbt项目上下文（血缘、测试、契约、定义指标）自主辅助模型编写、重构和调试。生成反映企业数据实际结构和定义的治理建议与可信SQL——不是通用SQL生成，而是基于dbt项目语义的精确SQL生成。这验证了Vol.7报道的”AI工具链竞争”趋势的深化：从”通用编码代理”走向”领域特定数据工程代理”。
• Agents Schema——AI代理结构化上下文的开放标准：Agents Schema定义仓库或数据湖中的单一模式（schema）为AI代理的共享上下文层。指标定义、语义模型、dbt血缘和业务文档存储在纯SQL表中，可被任何SQL代理直接查询。上下文可通过GitHub Actions、元数据连接器或自定义集成从现有系统发布。兼容任何仓库、数据湖、摄取工具或支持SQL的代理。核心设计：代理上下文是”数据”而非”API”——上下文存储在仓库内的SQL表中而非需要额外基础设施的独立服务中，组织可在现有安全和治理策略内操作，无需新基础设施或供应商锁定的代理系统。
• 与Vol.15-17的AI代理主线的衔接：Vol.15报道Snowflake Horizon Context定义AI理解数据的语义层（Collect→Enrich→Activate），Vol.15报道CoCo平台化为AI编码代理构建开发枢纽，Vol.17报道Databricks AI Search从纯向量走向向量+全文混合。Agents Schema从不同角度解决同一问题——“AI代理如何获得结构化的业务数据上下文”：Horizon Context是平台内语义层（Snowflake生态），AI Search是检索基础设施层（Databricks生态），Agents Schema是开放标准层（任何仓库/湖/代理可消费）。三者互补而非竞争。

行业影响

Fivetran+dbt合并的深层意义不是”又一个大并购”，而是数据摄取与转换两大支柱的整合标志着DataInfra从”工具组合”走向”平台整合”的结构性转变。当AI代理成为数据的主要消费者时，“摄取”和”转换”的边界模糊——代理需要的是从源头到语义的完整数据链路，而非碎片化的工具拼装。Fivetran确保数据完整到达，dbt确保数据可信定义，两者组合让代理在”数据在哪里”和”数据意味着什么”两个维度上都获得保障。

Agents Schema尤其值得关注——它试图定义AI代理消费结构化数据上下文的开放标准。此前AI代理获取业务上下文的方式是厂商特定的：Snowflake的Horizon Context、Databricks的Unity Catalog、Microsoft的Fabric IQ各有自己的语义层实现。Agents Schema将上下文定义为仓库内的SQL表而非独立服务，这意味着任何能查SQL的代理都能消费上下文，不需要理解特定厂商的API。如果Agents Schema获得广泛采纳，它可能成为AI代理数据消费层的”JDBC”——不是替代各厂商的语义层实现，而是提供跨厂商的上下文消费标准。

dbt Core v2.0将Fusion引擎的Rust运行时以Apache 2.0开源，结束了dbt的”双引擎时代”。此前ELv2许可的Fusion与Apache 2.0的dbt Core之间的功能差异和许可模糊一直是社区焦虑的来源。v2.0的核心运行时全部Apache 2.0意味着：社区贡献者在一个代码库上创新而非分叉，适配器构建者有一个稳定的接口规范，下游工具（包括AI代理）可以自由集成dbt的运行时。这是对”开源商业模式如何在AI时代维持”的一次重要实践——核心运行时开源，高级特性免费+付费。

相关链接

• Fivetran + dbt Labs Complete Merger to Create the Data Infrastructure for Trusted AI Agents
• Fivetran and dbt are one company now. Here’s what that means.
• dbt Core v2 is here: still open source, now rebuilt for what’s next
• Upgrading to v2.0

---

阿里云Dragonwell Native Acceleration AI：AI驱动的JFR分析自动发现Spark 10倍性能优化

事件概述

6月5日，阿里云发布Dragonwell Native Acceleration AI博客，介绍一个AI驱动的应用性能分析系统——自动识别Java/Scala应用中的优化机会，并使用Dragonwell的Native加速技术实施优化。以Apache Spark 4.0运行TPC-DS基准测试为验证场景：系统处理2,254个JFR（Java Flight Recorder）火焰图文件和280,000行代码，在3小时21分钟内分析400个热点函数，成功检测34个具有原生加速潜力的函数。在JMH单函数测试中，UTF8String.numChars提升1063%（10倍以上），BytesToBytesMap.safeLookup提升59.74%。在TPC-DS端到端测试中，Dragonwell 11 + Native加速相比OpenJDK 11提升9.69%（AI发现优化贡献约4%），Dragonwell 21 + Native加速相比OpenJDK 21提升5.7%（AI发现优化贡献约2.2%）。优化函数已发布在Dragonwell 21、11、8最新版本中，用户通过-XX:+UseAIExtension和-XX:AIExtensionUnit=spark_4.0参数即可启用。

技术解析

• AI与传统工具的协作架构：系统核心设计是确定性分析工作流，用程序实现而非Skill/Agent——因为每一步的触发条件和逻辑是固定的，代码实现更快更稳定，且避免不必要的LLM token消耗。两个传统工具承担AI不擅长的工作：①JFR热点聚合工具——将2,254个JFR文件聚合为全局热点摘要，提取Top N热点函数列表（消除LLM处理原始二进制数据的需求）；②AST函数查询工具——解析源代码构建抽象语法树，精确返回目标函数的完整定义和上下文（比grep更准确稳健）。三个AI代理承担AI擅长的工作：①逃逸分析代理——判断新创建的内部实例是否通过返回值或全局变量逃逸函数作用域（传统指针分析复杂，LLM基于代码语义快速判断）；②异常分析代理——判断异常抛出行为是否在不可达路径上（例如switch的default分支在生产环境是否真正可达，传统静态分析难以理解代码意图但LLM可以）；③优化机会分析代理——发现人类容易忽视的优化点（数组优化、消除符号扩展开销等）。
• Dragonwell Native加速的安全与必要性约束：安全约束——新创建的内部实例不能逃逸函数作用域（无对象逃逸），函数不能抛出异常（无异常）。优化必要性条件——汇编代码不能过短（否则JIT已足够优化），函数必须是计算密集型（IO操作和对象实例化无优化空间），存在其他优化机会（消除If分支、使用向量指令等）。这些约束确保Native加速不会引入安全风险且仅在确实有益时执行。
• 三级热度分析：线程热度（单线程执行热度，被并行稀释的高全局热度函数不是瓶颈）、进程热度（单进程/单query中的热度）、全局热度（所有query整体的热度）。三级热度交叉过滤消除”看起来热但实际不瓶颈”的函数——例如某函数全局热度13.71%但线程热度很低，说明执行时间被大量线程并行稀释，不是单线程性能瓶颈。
• 与Vol.17的”AI优化DataInfra”主线：Vol.17报道Instructed-Retriever-1（AI优化检索模型）、AliSQL DuckDB（AI优化查询分流）、AI Search（AI优化搜索基础设施）。本期Dragonwell Native Acceleration是AI优化DataInfra的另一个层面——不是优化DataInfra软件本身的功能，而是优化DataInfra软件运行的底层运行时（JVM）。当AI能自动发现JDK级别的性能优化机会时，“性能调优”从”资深工程师看火焰图”走向”AI自动分析+JDK原生加速执行”——性能优化的门槛从”需要JVM和框架源码的深度知识”降为”运行AI分析工具+启用加速参数”。

行业影响

Dragonwell Native Acceleration AI的深层意义不是”又一个AI辅助工具”，而是AI被应用于优化数据基础设施自身的运行时性能——从”AI使用数据基础设施”走向”AI优化数据基础设施”。

此前AI在DataInfra中的应用集中在使用侧：RAG检索数据、AI代理查询数据、AI编码代理构建管道。Dragonwell将AI应用于基础设施自身的性能优化——不是让AI帮用户更好地使用Spark，而是让AI帮Spark本身跑得更快。这个方向的重要性在于：数据基础设施的性能优化一直是高度专业化的领域——需要理解JVM内部机制、JIT编译行为、CPU缓存特性和框架源码细节。这类优化过去只能由极少数资深性能工程师完成，大多数团队选择忍受次优性能。AI+传统工具协作将瓶颈发现从”人工排查”走向”自动识别”，Native加速将优化执行从”重写代码”走向”启用JDK参数”。

三级热度分析的方法论也值得关注——它解决了一个常见的性能优化陷阱：“全局热点不等于性能瓶颈”。一个函数可能因为被大量线程调用而全局热度很高，但单线程执行时间很短，优化它对单线程性能提升有限。Dragonwell的三级过滤（线程/进程/全局）确保优化资源投向真正影响单线程性能瓶颈的函数。

阿里云在Dragonwell AI-Extension中已为ElasticSearch 8.17和Spark 4.0提供预构建的加速库，用户通过-XX:AIExtensionUnit=spark_4.0即可启用。下一步方向是构建端到端自动化管道——从性能采样、热点识别、AI分析、优化建议生成、自动打补丁到回归测试，实现”一键性能调优”。

相关链接

• AI-Powered Dragonwell Native Acceleration: Automatic Discovery of 10x Performance Improvement Opportunities
• Dragonwell 21 AI-Extension User Guide

---

腾讯云三层Agent-Ready数据平台：从”人使用工具”到”Agent完成工作”的范式迁移

事件概述

6月5日，腾讯云在AI产业应用大会发布三层Agent-Ready数据平台，宣布面向Agent升级全栈数据平台能力。腾讯云副总裁黄世飞表示，Agent正在成为数据平台的新型使用者——数据对象、价值链路和使用模式正在发生变化，Agent-Ready数据平台不仅要服务人的分析决策需求，更要服务Agent的数据理解、任务执行和业务协同需求，让人和Agent能够基于同一套数据体系协同工作。三层架构：智能入口层DataBuddy（生产级数据智能体，自然语言驱动端到端完成数据建模/ETL/归因分析/报告生成，内置数据工程/数据分析/数据治理三大专家，5月内测以来超3000家企业申请），统一控制面WeData（Agent-Native一体化数据智能平台，统一元数据/数据语义/编排/权限打通数据开发/机器学习/AI应用全流程，研发效率提升50%+），AI原生底座（TCLake+Spark+Ray+向量数据库统一存储与计算，Serverless弹性底座多引擎协同）。腾讯云同时发布Agent治理平台架构（多Agent统一接入/多组织统一治理/多场景统一交付），SkillHub社区收录7.8万个Skill、下载量突破3000万次。

技术解析

• DataBuddy——生产级数据智能体工作台：自然语言驱动端到端完成大数据全链路任务，内置三大数据专家Agent：①数据工程专家——自动完成数据接入、数仓分层方案设计、ETL任务生成与编排、工作流调度，重复开发量降低80%；②数据分析专家——快速取数、分析报告、业务波动归因、可视化看板；③数据治理专家——质量诊断、指标开发、元数据补齐、质量监控。人机协作模式：具体数据开发/维护/治理工作交给AI，人负责方案把关、规范审核和风险审核。安全体系：身份权限+执行隔离+Agent Guardrail+全链路审计——纵深防护确保Agent所有操作在企业安全边界内可控可追溯。这比Vol.10报道的Hologres CLI & Skills（Agent-Ready数据仓库工具包）更进一步——Hologres CLI是”Agent操作数据仓库的接口”，DataBuddy是”Agent代替人完成数据工作的智能体”。
• WeData——Agent-Native统一控制面：四大统一能力——统一元数据（Data/AI共用一份Catalog）、统一语义层（让AI”不仅查到更能理解”）、统一编排调度（Data+ML+AI异构任务）、统一权限（人/Agent同一套审计链路）。Agent作为一等公民——任务一样可观测可审计，持久记忆+技能沉淀越用越懂业务，三阶段演进从辅助到自主到协同。统一语义层是面向Agent时代的核心能力升级：解决”Agent幻觉”的根因不是模型能力不足而是业务语义缺失——当Agent不知道”收入”在不同业务域的含义差异时，再强的推理能力也会产出错误结果。WeData的统一语义层与Vol.15报道的Snowflake Horizon Context和Fabric IQ解决的是同一问题——“AI如何理解业务数据含义”——但路径不同：Horizon Context从目录扩展（Collect→Enrich→Activate），Fabric IQ从BI工具扩展（语义模型→本体论→操作代理），WeData从统一平台扩展（统一元数据/语义/编排/权限）。
• AI原生底座——重构支撑Agent运行的四层智能：从存储体系、计算引擎、系统到数据分析四个层面智能升级。存储层：TCLake多模态数据统一存储底座，元数据注册与发现；计算层：Spark+Ray+向量数据库批/流/ML/LLM混合引擎，Serverless弹性资源池；系统层：存储用途与底层实现解耦，统一Volume抽象层重构存储体系；数据分析层：结构化与非结构化数据分析，智能分析洞察与报告生成。平台既服务Agent，也逐步演进为Agent——从”数据平台被Agent使用”到”数据平台本身成为Agent”的演进方向。
• 与Vol.10/17的阿里云主线对比：Vol.10报道Hologres CLI & Skills（Agent-Ready数据仓库工具包），Vol.17报道LoongSuite GenAI SemConv和SkillClaw×Nacos（AI代理可观测与技能治理）。腾讯云DataBuddy+WeData是另一个中国云厂商的”Agent-Ready数据平台”系统性回答——阿里云从”数据仓库Agent化”（Hologres CLI）和”AI代理基础设施”（LoongSuite+SkillClaw×Nacos）两个方向切入，腾讯云从”数据平台三层架构”（入口+控制面+底座）整体切入。两者共同指向中国云厂商在Agent-Ready数据基础设施上的系统性布局。

行业影响

腾讯云三层Agent-Ready数据平台的深层意义不是”又一个AI数据产品发布”，而是数据平台从”人使用工具”到”Agent完成工作”的范式迁移。腾讯云的演进总图清晰展示了这个路径：2023年上云→2024年湖仓化→2025年AI-Ready→2026年Agent-Ready。AI-Ready解决”数据为AI准备”（格式/质量/可访问性），Agent-Ready在此基础上补齐三层能力——服务Agent的底座（计算/存储/网络）、控制面（语义/权限/血缘/上下文）和入口（自然语言交互/端到端任务执行）。

DataBuddy的”生产级数据智能体”定位值得重视。此前的数据AI产品大多是”AI辅助人完成数据任务”（如自然语言转SQL、智能推荐图表），DataBuddy定位为”AI代替人完成数据任务，人负责把关”——这是从”AI Copilot”到”AI Agent”的质变。当重复开发量降低80%、90%常见故障可自动诊断修复时，数据工程师的角色从”写ETL和调管道”转向”审核AI方案和规范数据架构”——这与Vol.13报道的Lakebase数据库分支让DBA角色从”门控审查”转向”设计协作”方向一致。

三层架构的”入口+控制面+底座”模型对行业有参考价值。此前DataInfra厂商的Agent-Ready能力建设大多集中在单点（Databricks的MCP Server、Snowflake的CoCo、阿里云的Hologres CLI），腾讯云首次以三层架构系统化定义”Agent-Ready数据平台”的完整能力模型——入口解决”Agent如何与平台交互”，控制面解决”Agent如何理解业务语义和受治理约束”，底座解决”Agent如何获得弹性可靠的计算和存储”。当这三层能力齐备时，Agent从”能在数据平台上执行单步操作”进化到”能端到端完成数据工作流”。

相关链接

• 腾讯云面向Agent升级数据平台：DataBuddy、WeData与AI原生数据底座亮相
• Agentic AI深水区：腾讯云Data+AI融合新范式探索
• 腾讯云发布新一代Agent-Ready基础设施应对未来挑战

---

编者评

第十八期的三条动态，将AI与DataInfra的深度融合推进到三个不同层面——数据转换层、运行时层和平台层。

第一个层面是数据转换层成为代理感知：Agents Schema定义AI代理消费结构化上下文的开放标准。 此前AI代理获取业务数据上下文的方式是厂商特定的——Snowflake有Horizon Context，Databricks有Unity Catalog，Microsoft有Fabric IQ，各自有独立的语义层实现和API。Agents Schema将上下文定义为仓库内的SQL表，任何能查SQL的代理都能消费——不引入新基础设施，不产生供应商锁定，在现有安全和治理策略内操作。这个设计的精巧之处在于：它不试图替代各厂商的语义层实现（Horizon Context/Fabric IQ/Unity Catalog在各自生态内仍有深度优势），而是提供一个跨厂商的上下文消费标准——正如JDBC不替代各数据库的查询引擎，但提供了统一的连接标准。如果Agents Schema获得广泛采纳，AI代理的”数据上下文层”可能从”每个平台各自实现”走向”开放标准+平台增强”的双层架构。

第二个层面是AI被应用于优化数据基础设施自身：Dragonwell以AI发现JDK级性能优化。 此前AI在DataInfra中的应用集中在使用侧（RAG/查询/编码），Dragonwell将AI应用于基础设施自身的运行时性能——让Spark跑得更快不是通过优化Spark代码，而是通过AI发现JVM级别可以原生加速的函数。这个方向的重要性在于：性能优化的专业门槛极高（需要JVM内部机制+框架源码+CPU特性的深度知识），大多数团队选择忍受次优性能。AI+传统工具协作将瓶颈发现自动化、Native加速将优化执行参数化——“性能调优”从资深工程师的专属技能变为可自动化的工程流程。当Vol.17报道的”效率跃迁”主线（检索/查询/搜索效率）消除的是”功能层面的效率税”时，Dragonwell消除的是”运行时层面的性能税”——同一方向的不同深度。

第三个层面是数据平台为代理原生重构：腾讯云三层架构定义Agent-Ready平台的完整能力模型。 入口层（DataBuddy让Agent端到端完成数据工作）、控制面（WeData统一语义/权限/血缘让Agent受治理约束地理解业务）、底座（AI原生存储计算让Agent获得弹性可靠资源）——三层模型回答了”什么是Agent-Ready数据平台”的完整问题。此前的Agent-Ready能力建设大多集中在单点（MCP Server/CLI/语义层），腾讯云首次以系统化架构定义完整能力边界。DataBuddy的”AI代替人完成数据任务，人负责把关”定位尤其值得注意——当数据工程师的角色从”写ETL”转向”审核AI方案”时，人机协作的界面从”操作工具”变为”审核决策”，这是Vol.13报道的Lakebase数据库分支（DBA从门控审查转向设计协作）和Vol.15报道的CoCo（开发者从写SQL转向审核AI生成的SQL）趋势的又一例证。

将十八期主线串联，AI与DataInfra的深度融合正在形成三层图谱： 顶层是AI代理如何消费和理解数据（Agents Schema/Horizon Context/Fabric IQ/WeData语义层——解决”AI代理需要什么上下文”），中层是数据平台如何为代理原生重构（CoCo/DataBuddy/Lakebase分支——解决”AI代理如何与数据平台交互”），底层是AI如何优化数据基础设施自身（Instructed-Retriever-1/Dragonwell Native/AI Search/Liquid Clustering——解决”数据基础设施如何因AI更高效”）。三层从”AI使用DataInfra”走向”AI与DataInfra共生”——AI不仅是数据的消费者，也是数据的理解者、平台的重构者和基础设施的优化者。当这三个角色同时实现时，DataInfra从”为人设计的工具”走向”人机共生的智能基础设施”。