如果你让一名新同事修改公司的“收入”报表，光会写公式还不够。TA 得知道“收入”在公司里怎么算、这张表依赖哪些数据，以及改动会不会让整条流水线重新跑一遍。AI 代理也面临同样的问题：会写 SQL，不等于理解一家公司的数据。
9 月 16 日，Fivetran + dbt Labs 在 dbt Summit 2026 上宣布 dbt v2 与 dbt State 正式可用，同时推出或预告 Fivetran Context Layer、dbt Wizard、dbt Charts 和开放湖仓愿景。这组发布值得放在一起看。dbt 正把执行速度、增量计算、业务语义和存储选择重新拼成一套面向 AI 代理的数据基础设施。
dbt 是分析工程平台。它让数据团队用 SQL 把原始数据加工成可信的分析表，并像管理软件代码一样管理版本、测试和文档。本文数字与效果均来自 dbt 官方博客及其中的客户引语，尚缺独立测评与完整统计口径。
先让引擎跟上代理
dbt v2 是对原有引擎的 Rust 重写，源自此前的 dbt Fusion。原来的 Python 实现改称 dbt v1。变化不只是换一种编程语言：官方称，v2 解析一个包含 10,000 个模型的项目时，速度最高可达 v1 的 10 倍。
“模型”在这里不是 AI 模型，而是一段把数据加工成新表的 SQL 逻辑。大型公司的项目可能由成千上万个模型组成，修改一处之前，系统得先读懂它们之间的依赖。解析更快，意味着开发者和代理等待反馈的时间更短。
v2 还能在真正执行 SQL 前提示错误、检查列，并展示 lineage——也就是一张表从哪些上游数据一路加工而来的“家谱”。这对 AI 代理尤其重要：代理生成代码很快，也更需要在运行前知道哪里会坏、会影响谁。
目前 BigQuery、Databricks、DuckDB、Redshift 和 Snowflake 适配器已经正式可用；ClickHouse 与 Spark 仍在 beta，Athena、Fabric 和 Postgres 尚未推出。因此，“一个新引擎覆盖所有环境”还不是已经完成的事实。
不变的部分，就别再算一遍
更直接影响成本的是 dbt State。多数数据任务按固定时间运行，即使上游数据没有变化，也可能把相同结果重新计算一次。它像每天把整本账簿重抄一遍，只因为规定早上九点必须开工。
dbt State 改为读取模型 SQL 和数仓元数据，判断什么真的发生了变化，再对各节点选择构建、跳过、克隆或延后。这里的“状态感知增量构建”，说白了就是记录代码、依赖和仓库对象的状态，只重算受变化影响的部分。
它可以在 Airflow、Dagster、GitHub Actions、本地电脑和 Snowflake dbt projects 等环境运行，目前支持 Snowflake、BigQuery、Databricks 与 Redshift。官方称，dbt 平均每天构建超过 2200 万个模型，早期采用者通过减少重复工作，平均节省 15%—30% 的计算成本。
客户案例给出了更具体、但仍属厂商材料的数字：Virgin Media O2 称作业时间与 BigQuery 计算成本都下降了 25%；RxBenefits 称 Snowflake adaptive warehouse 上的定时作业成本下降 59%，60 天内复用超过 70 万个模型，并累计少跑了两周的查询时间。
真正与“代理就绪”相关的，不只是省钱。系统把“多久必须更新一次”和“哪些结果可以复用”写进基础设施后，无论命令来自资深工程师、新人还是 AI 代理，都不必全靠操作者记住复杂规则。代理获得的不只是执行权，还有成本边界。
代理还需要公司的共同语言
速度和护栏解决了“怎么跑”，却没有回答“收入到底指什么”。这正是语义层要处理的问题：统一定义“收入”“活跃用户”等业务指标及其关系，避免报表、分析师和 AI 各算一套。
Fivetran + dbt Labs 把 Fivetran Context Layer、dbt Wizard 和 dbt Charts 放进了同一叙事。按官方介绍，Context Layer 试图把 dbt 中的结构化信息与文档、Slack 讨论等非结构化知识汇合，供大模型和代理调用；Wizard 则希望让代理理解项目的依赖、测试与约束；Charts 把图表定义与 dbt 模型一同进行版本管理。它们分别处于 Private Beta、Public Preview 或 Public Beta，并非都已全面开放。
另一块拼图是开放湖仓。湖仓希望在较低成本的对象存储上，同时获得数据湖的开放性与数据仓库的查询、治理能力；“开放”则强调数据格式不被单一计算引擎锁死。官方提出的方向是让企业保存一份数据，再按任务选择计算引擎。这仍是一项产品愿景，不能等同于已经验证的跨平台自由。
为什么现在值得看
这轮发布透露出一个清晰变化：分析工程平台不再只服务于人写 SQL、定时报表的工作流。它开始把代理会遇到的三个问题放进核心产品——引擎能否快速理解代码，系统能否避免昂贵的误操作，代理能否获得公司认可的业务语义。
换句话说，dbt 押注的不是“让 AI 多写几段 SQL”，而是把原本散落在人脑、文档、调度脚本和数仓里的规则，整理成机器能够读取和执行的基础设施。所谓“agent-ready”目前仍是厂商提出的战略说法，但产品重组已经真实发生。
局限与未知
- 速度提升、成本节省、日构建量与客户案例都来自官方，缺少独立基准、样本规模和统一口径。
- Context Layer、Wizard、Charts 与开放湖仓仍有不同程度的预览或愿景成分，实际可用性和跨平台效果尚待观察。
- 授权表述存在冲突：一篇官方博客称 v1、v2 均采用 Apache 2.0，另一篇则称完整 v2 含可选付费功能，只有 dbt-oss 子集完全由 Apache 2 许可组件组成，因此不宜笼统称“dbt v2 全部开源”。