架构

数据仓库获得智能体控制面:Snowflake 的 thinking_effort、stage_mounts 与 dbt 的 Agents Schema

作者：IdeaBosque最后更新：2026年10月29日

2026 年 10 月 28 日,Snowflake 在 Cortex Agents 的 agent:run API 上发布了三项新控制:thinking_effort、instructions.system 与 stage_mounts(Snowflake 发布说明)。一个新的仓库运行时,如今把传统上留给智能体平台自身的三件事暴露了出来 —— 模型思考多用力、运行时执行哪些内部规则、以及智能体可以挂载哪些版本化产物。同一个月,Fivetran 与 dbt Labs 完成合并,"为可信 AI 智能体打造数据基础设施",合并后的平台带有 Agents Schema,让智能体获得仓库原生的上下文,而不是临时拼凑的抽取(Fivetran 新闻稿)。

本文梳理这三张 Snowflake 控制面、伴随而至的上下文层,以及它们没有关闭的边界:审批、跨工具策略与审计线仍属于仓库上方的编排层。对一个精简团队 —— 一个 Snowflake 账号、两名 dbt 开发者、智能体开始承接定时任务 —— 这些是你第一次能在数据仓库内部亲手设置的控制项,而分清它们约束什么、不约束什么,正是治理与形式主义的分界线。

关键要点

Snowflake 于 2026 年 10 月 28 日发布三项智能体控制 —— thinking_effort(从 minimal 到 xhigh,因模型而异的取值子集)、instructions.system(在运行时内部追加系统指令)与 stage_mounts(版本化暂存区挂载),全部落在 Cortex agent:run API 上(Snowflake 发布说明)。
stage_mounts 按版本而非分支绑定产物 —— 笔记本、Streamlit 应用、工作区与智能体均以版本化暂存区挂载;可写的 workspace_mounts 保持不变,版本仍为 live(Snowflake 发布说明)。
dbt 与 Fivetran 完成合并后推出 Agents Schema —— 合并平台的自我定位是"为可信 AI 智能体打造数据基础设施",把受治理的上下文行放到智能体消费它们的位置(Fivetran 新闻稿)。
dbt × Amazon Redshift 数据共享(dbt 于 10 月 9 日、AWS 于大数据博客先后发布文档)让多集群管道无需搬移一个字节 —— 受治理的共享加上 SVV_* 元数据 API 与 datasharing 配置,取代"先抽取再拷贝"(dbt 博客;AWS 大数据博客)。
这些旋钮约束的是推理力度、指令与挂载 —— 不是策略 —— 覆盖数据仓库、NetSuite、HubSpot 以及智能体触达的其余系统的审批、撤销与审计,仍留在编排层。

10 月 28 日发布了什么,以及每项控制落在哪一层

thinking_effort 是推理力度旋钮:取值范围从 minimal 到 xhigh,并带有因模型而异的取值子集,限制给定模型接受哪些值。实践中,它把模型算力从 API 侧默认值变成了仓库在每次运行中记录的每运行设置。读取新鲜度表的定时智能体,并不需要和对账发票明细的智能体相同的算力预算;在 10 月 28 日之前,这一区分住在调用模型的工作框架里,如今则作为运行的一次性声明参数由仓库执行。

instructions.system 在运行时内部追加系统指令。这是内部策略的插槽:你想附加到每一次智能体运行上的组织规则 —— 智能体可以汇总什么、必须把什么标记给人审、如何处理缺失的上下文 —— 随调用一同传递,而不是躺在谁的提示模板里。这里要诚实地说清楚:追加的指令不是一个权限系统。它们塑造运行时内部的行为;它们不撤销任何东西。

stage_mounts 是产物边界。agent:run API 现在接受版本化暂存区挂载 —— 笔记本、Streamlit 应用、工作区,以及智能体本身 —— 而可写的 workspace_mounts 保持不变,版本仍为 live。绑定到版本化暂存区的智能体,看到的是一组钉定的产物,而不是分支上此刻的任意状态。这与智能体栈中其他地方管线钉定、清单钉定出自同一种直觉,只是落在了产物真正所在的仓库边界上。

下图把三张控制面对照其上下两层展开 —— 上面是策略留驻的编排层,下面是正在到来的上下文与数据移动层。

上下文层先到了

控制项只能对照着某个东西才有意义,而那个东西先在上下文一侧到位。Fivetran 与 dbt Labs 完成合并时给出了明确的论题:合并后的公司存在的意义是"为可信 AI 智能体打造数据基础设施"(Fivetran 新闻稿)。Agents Schema 把这个论题带进了仓库 —— 受治理、被建模的行,智能体消费它们的方式,就像仪表盘消费指标表一样,而不是智能体对着一个 SQL 端点反复试错拼凑出的临时抽取。

数据移动的问题得到了同样的处理。dbt 现已支持 Amazon Redshift 数据共享,AWS 的大数据博客记录了多集群模式 —— SVV_* 元数据 API 与 datasharing 配置,在不复制一个字节的前提下构建多集群管道(dbt 博客;AWS 大数据博客)。对智能体而言,这就是"环境由受治理的共享组装 —— 血缘与访问规则仍然成立"与"环境由抽取组装 —— 每个副本都是新的访问问题"之间的区别。Dagster 围绕同一论题的自我重新定位("Data your team trusts. AI that runs on it.")从编排器一侧说了同一件事(Dagster)。

把三张面放在一起读,就得到同一个模式:上下文在它被建模的地方被治理,移动在它被共享的地方被治理,而推理力度、指令与挂载在运行发生的地方被治理。这是对一个问题"仓库优先"的回答,而这个问题此前一直由智能体平台用各自的定制代码来回答。

这些旋钮没有关上的门

这些控制项不约束的是跨系统的策略。一个读取仓库定价模型、查询 BigCommerce 库存、再把获批报价写回 NetSuite 的智能体,跨越了三条厂商边界和一条协议边界。Snowflake 的参数恰好只治理其中一条边界;发布说明里没有任何东西撤销 BigCommerce 的令牌,instructions.system 也产生不了 NetSuite 里的审计记录。审批、撤销以及那条跨工具审计线,必须留在编排层 —— 也就是把每个系统包装成带各自认证与日志的类型化工具的模块模式(MCP 模块代码标准)。

有一个诚实的边界要点明:发布说明记录的是参数,不是保证。agent:run 调用的审计行为 —— 记录什么、保留什么、可否查询 —— 我们审阅的说明中并没有给出,而且因模型而异的取值子集意味着,一个团队的 xhigh 是另一个团队的不可用设置。把这三项控制当作声明式输入,在你的账号上验证审计线,并把总开关(急停)留在数据仓库上方(AI 治理清单)。

精简团队视角

对一个刚开始把定时智能体跑到数据仓库上的中型市场团队,10 月 28 日改变了开局对话的五个地方。盘点哪些智能体在触碰数据仓库 —— 定时的优先。按工作负载有意识地设置 thinking_effort:新鲜度检查用 minimal,对账用更高力度,并把哪个任务用了哪档预算记录下来 —— 这份映射就是你按单位计成本的故事。把组织策略一次性放进 instructions.system,而不是散落在每份提示模板里各自维护。把定时智能体绑定到版本化暂存区挂载,让智能体读取的 Streamlit 仪表盘,是有人测过它的那个版本,而不是今天早上变了样的那个。并且把审批与撤销留在编排器的清单里 —— 数据仓库控制的是一次运行长什么样;编排器控制的是一次运行被允许做什么、留下了什么。