Snowflake芝加哥峰会：Agent非产品，基础才是关键

我在 Snowflake World Tour 芝加哥站看到了什么，以及这对当下正在基于 Snowflake 构建的团队意味着什么。

在构建数据平台大约十年之后，我学会带着一个问题走进厂商活动：我的团队周一实际上会有什么不同做法？

10 月 5 日，我参加了 Snowflake World Tour 芝加哥站。主题是“智能体企业”，我承认我原本以为又会看到一轮在台上看起来很棒、在生产中却停滞不前的智能体演示。

但我得到的并不完全是这样。

当前常见的迷思是，AI 成熟度意味着更多智能体。为 HR 建一个聊天机器人，为财务再建一个，为运营再建一个，你就是在“做 AI”了。而我在一场又一场会议中听到的恰恰相反。

孤立的智能体无法扩展。一个受治理的基础（数据、上下文、模型和控制）才能把智能体变成企业可以信任的东西。

以下是我作为实践者对我参加的五场会议的解读，以及每一场如何帮助正在基于 Snowflake 构建的组织。

1. 开幕主题演讲：一个受治理的基础，而不是一堆智能体

Sridhar Ramaswamy 以一个我认同的框架开场：企业 AI 正在走过实验阶段。下一步是能够理解业务上下文、基于可信数据进行推理，并在真实工作流中采取行动的 AI。

他的观点是，你无法通过把智能体硬接到一个碎片化的技术栈上来实现这一点。Snowflake 的主张是一个受治理的基础，连接四个层次：

1. 数据与上下文（你的表、文档、语义模型）
2. 模型选择（不被锁定在某一个 LLM 提供商）
3. 应用（智能体实际执行工作的地方）
4. 一个协调并治理上述一切的控制平面

有三个主题让我印象深刻。

1. AI 的安全与成本控制

这被当作一个一等话题，而不是结尾的一张幻灯片。这很重要。以我的经验，扼杀 AI 推广的第一件事不是模型质量，而是 CFO 看到一张无法解释的账单，或者安全团队问“这个智能体能看到什么？”而没人能给出干净利落的回答。我最近在 你的 AI 账单有三个控制层。大多数团队只构建了一个中写过这一点。很高兴看到 Snowflake 也在着力解决同一个问题。

2. 一份数据副本，连接每个系统

零拷贝集成的故事越来越强。数据不再被复制到每一个 SaaS 工具和 AI 服务（并且每次离开都失去治理），而是留在同一个地方，由其他系统就地读取。更少的副本意味着更少需要照看的管道、更少的过期摘录，以及一套访问策略。

3. Cortex Sense

这是我最感兴趣的一项发布。Cortex Sense 旨在为智能体提供基于你尚未正式建模的数据的扎实上下文。大多数组织都有少数精心治理的语义模型，以及一条没人记录过的长尾表。智能体往往在那条长尾中产生幻觉。Cortex Sense 就是 Snowflake 针对这一缺口的答案。

主题演讲以与 Ensono 首席 AI 官 Jim Piazza 的炉边谈话收尾，谈的是 Ensono 如何从 AI 雄心走向大规模预测性运营。我的收获是：他们不是从“让我们构建一个智能体”开始的。他们是从一个受治理的运营数据集和一个可以衡量的结果开始的。

2. dbt Projects + Semantic Views：让数据为 AI 做好准备

如果说主题演讲是“为什么”，这场会议就是“怎么做”。核心观点：你的 dbt 项目就是 AI 就绪度的起点，因为你的业务逻辑和定义已经在那里了。

涵盖了三件事。

使用 Snowpark DataFrames 的 Python dbt 模型

Snowflake 上的 dbt Projects 让你可以在同一个项目中混合 SQL 模型和 Python DataFrame 模型。对于在 SQL 中很痛苦的转换（复杂解析、ML 特征准备、迭代逻辑），Snowpark DataFrame 模型要干净得多。

# models/marts/fct_customer_features.py

import snowflake.snowpark.functions as F
def model(dbt, session):
 dbt.config(materialized="table")
orders = dbt.ref("stg_orders")
features = (
 orders.group_by("customer_id")
 .agg(
 F.count("order_id").alias("order_count"),
 F.sum("order_amount").alias("lifetime_value"),
 F.max("order_date").alias("last_order_date"),
 )
 )
 return features

代码在 Snowflake 内部运行，因此没有数据移动，也不需要管理单独的 Spark 集群。数据血缘保留在同一个 dbt DAG 中。

使用 dbt_semantic_view 包的 Snowflake Semantic Views。

这是我认为大多数团队利用不足的部分。Semantic Views 是 Cortex Analyst 和 Cortex Agents 用来理解你的指标和维度的东西。借助 `dbt_semantic_view` 包，你可以将它们定义和版本化为 dbt 模型，就放在它们所描述的表旁边。

-- models/semantic/sv_orders.sql
{{ config(materialized='semantic_view') }}
TABLES (
 orders AS {{ ref('fct_orders') }} PRIMARY KEY (order_id)
)
DIMENSIONS (
 orders.order_date AS order_date,
 orders.region AS region
)
METRICS (
 orders.total_revenue AS SUM(order_amount),
 orders.order_count AS COUNT(order_id)
)

为什么这很重要：当语义层存在于同一个仓库中、经过同样的 PR 审查、并与你的模型一起通过同样的 CI/CD 部署时，它就不再漂移。在我的 Cortex Agent 工作中，语义层过于单薄或陈旧一直是智能体给出错误答案的首要原因。把它纳入 dbt 之下正是我一直想要的修复。

Apache Ossie（孵化中）

前身是 Open Semantic Interchange (OSI)，现已在 Apache 孵化器中成为 Apache Ossie。它是一个厂商中立的语义元数据规范，因此指标定义不会被锁定在某一个 BI 工具或某一个平台内。这场会议涵盖了语义层生命周期最佳实践：定义一次、对它进行版本化、测试它，并让多个消费者（BI、智能体、笔记本）读取同一套定义。

CoCo 实时加速 dbt

演示中，Snowflake CoCo（Cortex Code）实时搭建 dbt 模型、编写测试并生成语义视图定义。我喜欢的一点是：人类保持在回路中，审查每一项更改，而不是接受一堵生成代码之墙。

3. 成为 AI 原生：Snowflake 自己的 CoCo 故事

这场会议是 Snowflake 以自身为案例研究：构建 CoCo 的团队如何工作，以及他们作为一个工程组织在成为 AI 原生方面学到了什么。

这个框架很务实：

• 先用 AI 来框定问题，而不是按老方式写规格说明
• 在代码和智能体中共创，让工程师和智能体在同一个回路中工作
• 自动化审查，让人类专注于判断，而不是格式
• 将一周交付周期作为默认节奏

对我来说，两个深入探讨是亮点。

智能体插件

插件将能力（工具、连接器、命令）打包，使代理无需重建即可扩展。对于平台团队而言，这意味着你只需构建一次“Snowflake 管理员”插件，每位工程师的代理都可以使用它。

代理技能

技能是可复用的指令包，教会代理你的团队如何做事：命名规范、RBAC 模式、部署规则。这正是部落知识变成代理能够一致遵循的东西的地方。我自己一直在写作和 Snowflake 管理任务中使用这种模式，这是我见过的代理输出质量提升最大的一次。

4. 代理化企业：CoCo + CoWork 在实际工作中

本次会议的主题是个人工作代理：能够将你的数据置于上下文中、跨结构化和非结构化来源工作，并在完整治理框架内运行的代理。Snowflake 将其概括为两个工具：

• 面向构建者的 Snowflake CoCo（代码、管道、SQL）
• 面向知识工作者的 Snowflake CoWork（分析、文档、日常任务）

HDR 的故事：从 ChatHDR 1.0 到 2.0

本次会议最精彩的部分是来自 HDR 的客户用例。他们讲述了 ChatHDR 1.0——他们的第一个内部助手——以及如何将其演进为 ChatHDR 2.0。

我欣赏的是他们对 1.0 版本的坦诚。那不是失败，而是教会他们用户真正需要什么的东西。这是我推荐给任何团队的模式：先发布一个范围狭窄的 v1，从中学习，然后根据真实需求重建。

代理化 GPA：目标、计划、行动

本次会议引入了一个关于这些代理如何工作的简单心智模型：GPA（目标、计划、行动）。

1. 目标：用户陈述一个结果，而非逐步指令
2. 计划：代理将其分解为步骤，并选择正确的工具和数据
3. 行动：代理在其所代表的用户的权限范围内执行

“在权限范围内”这一部分才是关键所在。代表用户行事的代理绝不应看到超出该用户可见范围的内容。当这一点继承自 Snowflake RBAC 时，你就不必为每个新代理重建安全机制。

5. 为大规模 AI 提供动力的数据产品

最后一场会议回归到工程基础。代理的优劣取决于其底层的数据产品。本次会议涵盖了使用 CoCo 构建 SQL、Python、Spark 和 ML 管道，以及 Snowpark、面向 Apache Spark 的 Snowpark Connect、动态表和 dbt Projects。

动态表：洞察、dbt 和自适应刷新

有三点很突出：

• 动态表洞察：更好地了解刷新行为、延迟，以及某个表为何进行全量刷新而非增量刷新。最后这一点过去曾让我花了好几个小时调试。
• 动态表与 dbt：你可以将它们声明为 dbt 物化，这样新鲜度就变成了模型配置，而不是单独的编排作业。
• 自适应动态表：刷新行为会自适应工作负载，而不是由你手动选择增量还是全量，然后寄希望于它在数据增长时依然有效。

-- models/marts/dt_daily_revenue.sql

{{ config(
 materialized='dynamic_table',
 snowflake_warehouse='TRANSFORM_WH',
 target_lag='15 minutes',
 refresh_mode='AUTO'
) }}
SELECT
 order_date,
 region,
 SUM(order_amount) AS revenue
FROM {{ ref('fct_orders') }}
GROUP BY order_date, region

声明式 DCM

DCM Projects 将 Snowflake 对象的声明式、基础设施即代码管理原生引入平台。你描述期望状态，Snowflake 制定变更计划。我在另一篇文章中深入探讨了它与 Terraform 的对比（以及我会在何时选择哪一个）：https://medium.com/towards-data-engineering/snowflake-dcm-vs-terraform-which-one-actually-belongs-in-your-pipeline-cea37e311217?sk=dfb8c4b43a09d9a8479329be25635b84

使用代码包部署 Python

最后一块是用于部署 Python 的代码包：将你的 Python 代码和依赖项打包为一个单元，以便同一个构件从开发环境迁移到生产环境。如果你曾经在 Python UDF 或存储过程上为 stage 路径和 import 列表而头疼，你会对此很欣赏。

那么，这对在 Snowflake 上构建的组织意味着什么？

以下是我的真实收获，以我在自己项目中会怎么做的方式来陈述，而非一份处方。

在代理之前先投资语义层。dbt 中经过治理和版本化的 Semantic Views，对代理准确性的贡献将超过更换模型。

只保留一份数据。你避免的每一份副本，都是你不必去弥补的一个治理缺口。

将成本和安全视为第一天的设计。预算、配额和继承 RBAC 的代理应该出现在第一张架构图中，而不是事后事故复盘中。

标准化你的团队与代理协作的方式。技能和插件将个人的生产力技巧转化为团队范围的实践。

让新鲜度和部署变得声明式。动态表、DCM 和代码包都减少了那些在凌晨两点出问题的胶水代码。

这些都不光鲜。这恰恰是重点。真正从代理中获得价值的组织，是那些现在就在做这些不起眼的基础工作的组织。

概要

1. 主题演讲：Snowflake 的赌注是一个统一的治理基础（数据、上下文、模型、应用、控制平面），具备安全、成本控制、零拷贝集成，以及用于对未建模数据进行接地上下文的 Cortex Sense。
2. dbt + Semantic Views：dbt 中的 Python DataFrame 模型、通过 `dbt_semantic_view` 定义的 Semantic Views，以及用于开放语义定义的 Apache Ossie。
3. AI 原生工程：Snowflake 的 CoCo 团队依靠代理插件、代理技能、自动化审查和一周发布周期运行。
4. 代理化企业：面向构建者的 CoCo、面向知识工作者的 CoWork、HDR 从 ChatHDR 1.0 到 2.0 的历程，以及目标-计划-行动模型。
5. 面向 AI 的数据产品：动态表（洞察、dbt、自适应）、声明式 DCM 和 Python 代码包。

代理不是产品。基础才是。

你今年参加了 World Tour 的某一站吗？我很想听听你最先在测试哪项发布。

Snowflake World Tour 芝加哥 2026：代理不是产品。基础才是。最初发布于 Snowflake Builders Blog：数据工程师、应用开发者、AI 与数据科学 在 Medium 上，人们通过高亮和回应这个故事来继续对话。